Re: [openstack-dev] [ux] Future of the OpenStack UX team

[Shamail]

Hi,

> On Feb 15, 2017, at 3:39 AM, Thierry Carrez  wrote:
> 
> Shamail Tahir wrote:
>> On Wed, Jan 4, 2017 at 9:43 AM, Thierry Carrez > > wrote:
>> 
>>Hi everyone,
>> 
>>Piet recently reached out to me to explain that he won't be able to
>>continue in his role as OpenStack UX team's PTL. Since he created the
>>team and spent a lot of time coordinating its activities, that raises
>>the question of the future of the OpenStack UX team.
>> 
>>The situation was discussed at the TC meeting yesterday[1] and the
>>general feeling was that there was a lot of value in a separate team
>>centralizing things like Persona definition and facilitating
>>properly-conducted UX surveys. That said, if nobody is able to dedicate
>>the time that effort needs, we could also disband the centralized team
>>and encourage every project to adopt the tools and techniques that were
>>built and introduced by the UX team in the past years.
>> 
>>So... What are your thoughts on those options ? Do we have a volunteer
>>(or more than one) to take over UX PTLship ?
>> 
>> Hi Thierry,
>> 
>> I had set up a doodle poll to gauge interest/establish a new meeting
>> time for the UX working group but we only had one additional response. 
>> How should we proceed since it seems there was low interest in
>> participation? 
> 
> Hi Shamail,
> 
> Thanks again for your help in wrangling volunteers in the UX area. Given
> the low interest I propose we keep the effort dormant until we can
> schedule a community discussion about UX at the Forum in Boston, where
> we might trigger more interest and volunteers.
> 
> What do you think ?
I agree as well.  I'll submit a session for the Forum on this topic.  Thank you!
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][l2gatewaty] how to create l2-gateway-create when 2 switches has the same name

[Moshe Levi]

Hi,

I am using the latest networking-l2gateway. 
I have the following physical switches defined in neutron physical_switches
+--+---+-+--+-+
| uuid | name  | tunnel_ip   | ovsdb_identifier 
| switch_fault_status |
+--+---+-+--+-+
| 6932481e-8316-40f7-834a-6a6deeb72534 | vtep0 | 99.99.99.99 | ovsdb2   
| NULL|
| ceb7cadb-28a8-476b-b959-2db253633854 | vtep0 | 1.1.1.1 | ovsdb1   
| NULL|
+--+---+-+--+-+

I want to create L2 gateway on ceb7cadb-28a8-476b-b959-2db253633854

According to the l2-gateway api [1] it seem that in the --device name can be 
name or identifiers, so I tried with the ovsdb_identifier, but when I run the 
l2-gateway-connection-create it complain that the ovsdb1 is not found see [2]. 
I also tried with uuid and got the same result. 
How should I create l2 gateway when I have same names in the physical switches 
tables?


[1] - 
https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api.rst
 
[2] - 
(neutron) l2-gateway-create --device name=ovsdb1,interface_names=eth7|8;eth8|8 
SW1
Created a new l2_gateway:
+---+-+
| Field | Value 

  |
+---+-+
| devices   | {"interfaces": [{"segmentation_id": ["8"], "name": "eth7"}, 
{"segmentation_id": ["8"], "name": "eth8"}], "id": 
"105d6abf-6257-4818-8451-fa6e0d6c7334", "device_name": "ovsdb1"} |
| id| 2ea12e77-3409-40b2-8535-6cf320fca4b2  

  |
| name  | SW1   

  |
| tenant_id | 0fa5309dd18a4861a5833e55d8a7f98c  

  |
+---+-+
(neutron) l2-gateway-connection-create SW1 private
L2 Gateway Device ovsdb1 could not be found.
Neutron server returns request_ids: ['req-f26351fb-fcf5-4d77-b2fe-8b58ac9057dc']


Thanks,
Moshe Levi



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Some findings while profiling instances boot

[Kevin Benton]

Thanks for the stats and the nice diagram. I did some profiling and I'm
sure it's the RPC handler on the Neutron server-side behaving like garbage.

There are several causes that I have a string of patches up to address that
mainly stem from the fact that l2pop requires multiple port status updates
to function correctly:

* The DHCP notifier will trigger a notification to the DHCP agents on the
network on a port status update. This wouldn't be too problematic on it's
own, but it does several queries for networks and segments to determine
which agents it should talk to. Patch to address it here:
https://review.openstack.org/#/c/434677/

* The OVO notifier will also generate a notification on any port data model
change, including the status. This is ultimately the desired behavior, but
until we eliminate the frivolous status flipping, it's going to incur a
performance hit. Patch here to put it asynced into the background so it
doesn't block the port update process:
https://review.openstack.org/#/c/434678/

* A wasteful DB query in the ML2 PortContext:
https://review.openstack.org/#/c/434679/

* More unnecessary  queries for the status update case in the ML2
PortContext: https://review.openstack.org/#/c/434680/

* Bulking up the DB queries rather than retrieving port details one by one.
https://review.openstack.org/#/c/434681/
https://review.openstack.org/#/c/434682/

The top two accounted for more than 60% of the overhead in my profiling and
they are pretty simple, so we may be able to get them into Ocata for RC
depending on how other cores feel. If not, they should be good candidates
for back-porting later. Some of the others start to get more invasive so we
may be stuck.

Cheers,
Kevin Benton

On Wed, Feb 15, 2017 at 12:25 PM, Jay Pipes  wrote:

> On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:
>
>> Hi there,
>>
>> We're trying to figure out why, sometimes, rpc_loop takes over 10
>> seconds to process an iteration when booting instances. So we deployed
>> devstack on a 8GB, 4vCPU VM and did some profiling on the following
>> command:
>>
>> nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec --nic
>> net-name=private --min-count 8 instance
>>
>
> Hi Daniel, thanks for posting the information here. Quick request of you,
> though... can you try re-running the test but doing 8 separate calls to
> nova boot instead of using the --min-count 8 parameter? I'm curious to see
> if you notice any difference in contention/performance.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Chen CH Ji]

Should be this one https://bugs.launchpad.net/nova/+bug/1664913 and
https://review.openstack.org/434179 ?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Corey Bryant 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   02/16/2017 05:37 AM
Subject:Re: [openstack-dev] [nova] scaling rabbitmq with cells v2
requires manual database update





On Wed, Feb 15, 2017 at 4:34 PM, Corey Bryant 
wrote:

  On Wed, Feb 15, 2017 at 4:26 PM, melanie witt  wrote:
   On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:
 This works but you have to specify all of the args (--cell_uuid,
 --name,
 --transport-url and --database_connection).  Otherwise you'll hit
 this: http://paste.ubuntu.com/24003055/

   Corey,

   Thanks for pointing that out.

   It looks like the command intended to have --transport-url and
   --database_connection as optional but missed defaulting them to None in
   the function parameter list.

   -melanie

  I think I figured it out.  I'll submit a patch in a little bit.



You're correct btw :)


--
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Joshua Harlow]

For the cookbooks, every core and non-core project that is supported has to
be tracked. In addition to that, each platform that is supported must be
tracked, for quirks and idiosyncrasies, because they always have them.

Then, there are the cross-project teams that do the packaging, as well as
the teams that do not necessarily ship releases that must be tracked, for
variances in testing methods, mirrors outside the scope of infra, external
dependencies, etc. It can be slightly overwhelming and overloading at times,
even to someone reasonably seasoned. Scale that process, for every ecosystem
in which one desires to exist, by an order of magnitude.

There’s definitely a general undercurrent to all of this, and it’s bigger
than any one person or team to solve. We definitely can’t “read the release
notes” for this.


Radical idea, have each project (not libraries) contain a dockerfile 
that builds the project into a deployable unit (or multiple dockerfiles 
for projects with multiple components) and then it becomes the projects 
responsibility for ensuring that the right code is in that dockerfile to 
move from release to release (whether that be a piece of code that does 
a configuration migration).


This is basically what kolla is doing (except kolla itself contains all 
the dockerfiles and deployment tooling as well) and though I won't 
comment on the kolla perspective if each project managed its own 
dockerfiles that wouldn't seem like a bad thing... (it may have been 
proposed before).


Such a thing could move the responsibility (of at least the packaging 
components and dependencies) onto the projects themselves. I've been in 
the boat of try to do all the packaging and tracking variances and I 
know it's a some kind of hell and shifting the responsibility on the 
projects themselves may be a better solution (or at least can be one 
people discuss).



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Samuel Cassiba]

> On Feb 15, 2017, at 08:49, Alex Schultz  wrote:
> 
> On Wed, Feb 15, 2017 at 9:02 AM, Samuel Cassiba  wrote:
>>> On Feb 15, 2017, at 02:07, Thierry Carrez  wrote:
>>> 
>>> Samuel Cassiba wrote:
 [...]
 *TL;DR* if you don't want to keep going -
 OpenStack-Chef is not in a good place and is not sustainable.
 [...]
>>> 
>>> Thanks for sharing, Sam.
>> 
>> Thanks for taking the time to read and respond. This was as hard to write as 
>> it was to read. As time went on, it became apparent that this retrospective 
>> needed to exist. It was not written lightly, and does not aim to point 
>> fingers.
>> 
>>> I think that part of the reasons for the situation is that we grew the
>>> number of options for deploying OpenStack. We originally only had Puppet
>>> and Chef, but now there is Ansible, Juju, and the various
>>> Kolla-consuming container-oriented approaches. There is a gravitational
>>> attraction effect at play (more users -> more contributors) which
>>> currently benefits Puppet, Ansible and Kolla, to the expense of
>>> less-popular community-driven efforts like OpenStackChef and
>>> OpenStackSalt. I expect this effect to continue. I have mixed feelings
>>> about it: on one hand it reduces available technical options, but on the
>>> other it allows to focus and raise quality…
>> 
>> You have a very valid point. One need only look at the trends over the 
>> cycles in the User Survey to see this shift in most places. Ansible wins due 
>> to sheer simplicity for new deployments, but there are also real business 
>> decisions that go behind automation flavors at certain business sizes. This 
>> leaves them effectively married to whichever flavor chosen. That shift 
>> impacts Puppet’s overall user base, as well, though they had and still have 
>> the luxury of maintaining sponsored support at higher numbers.
> 
> To chime in on the Puppet side, we've seen a decrease in contributors
> over the last several cycles and I have a feeling we'll be in the same
> boat in the near future.  The amount of modules that we have to try
> and manage versus the amount of folks that we have contributing is
> getting to an unmanageable state.  I believe the only way we've gotten
> to where we have been is due to the use within Fuel and TripleO.  As
> those projects evolve, it directly impacts the ability for the Puppet
> modules to remain relevant.  Some could argue that's just the way it
> goes and technologies evolve which is true.  But it's also a loss for
> many of the newer methods as they are losing all of the historical
> knowledge and understanding that went with it and why some patterns
> work better than others.  The software wheel, it's getting reinvented
> every day.

Thank you for your perspective from the Puppet side. The Survey data alone
paints a certain narrative, and not one I think people want. If OpenStack
deployment choice is down to a popularity contest, the direct result is
fewer avenues back into OpenStack.

Fewer people will think to pick OpenStack as a viable option if it simply
doesn’t support their design, which means less exposure for non-core
projects, less feedback for core projects, rinse, repeat. Developers can and
would coalesce around but a couple of the most popular options, which works
if that’s the way things are intending to go. With that, the OpenStack story
starts to tell less like an ecosystem and more like a distro, bordering on
echo chamber. I don’t think anyone signed up for that. On the other hand,
fewer deployment options allow for more singular focus. Without all that
choice clouding decision-making, one has no way to OpenStack but those few
methods that everyone uses.

>> Chef’s sponsored support has numbered far fewer. It casts an extremely 
>> negative image on OpenStack when someone looks for help at odd hours, or 
>> asks something somewhere that none of us have time to track. The answer to 
>> that is the point of making noise, to generate conversation about avenues 
>> and solutions. I could have kept my fingers aiming at LP, Gerrit and IRC in 
>> an attempt to bury my head in the sand. We’re way past the point of denial, 
>> perhaps too far, but as long as the results of the User Survey shows Chef, 
>> there are still users to support, for now. Operators and deployers will be 
>> looking to the source of truth, wherever that is, and right now that source 
>> of truth is OpenStack.
>> 
>>> There is one question I wanted to ask you in terms of community. We
>>> maintain in OpenStack a number of efforts that bridge two communities,
>>> and where the project could set up its infrastructure / governance in
>>> one or the other. In the case of OpenStackChef, you could have set up
>>> shop on the Chef community side, rather than on the OpenStack community
>>> side. Would you say that living on the OpenStack community side helped
>>> you or hurt you ? Did you get enough help / visibility to balance the
>>> constraints ? Do you think you would have been more, les

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Renat Akhmerov]

Very sad to hear all that.. Hopefully it’ll be sorted out one way or another.

Thanks Thomas!

Renat Akhmerov
@Nokia

> On 15 Feb 2017, at 23:42, Doug Hellmann  wrote:
> 
> Excerpts from Paul Belanger's message of 2017-02-15 09:51:22 -0500:
>> On Wed, Feb 15, 2017 at 01:43:46PM +0100, Thomas Goirand wrote:
>>> Hi there,
>>> 
>>> It's been a while since I planed on writing this message. I couldn't
>>> write it because the situation makes me really sad. At this point, it
>>> starts to be urgent to post it.
>>> 
>>> As for many other folks, Mirantis decided to end its contract with me.
>>> This happened when I was the most successful doing the job, with all of
>>> the packaging CI moved to OpenStack infra at the end of the OpenStack
>>> Newton cycle, after we were able to release Newton this way. I was
>>> hoping to start packaging on every commit for Ocata. That's yet another
>>> reason for me to be very frustrated about all of this. Such is life...
>>> 
>>> Over the last few months, I hoped for having enough strengths to
>>> continue my packaging work anyway, and get Ocata packages done. But
>>> that's not what happened. The biggest reason for this is that I know
>>> that this needs to be a full time job. And at this point, I still don't
>>> know what my professional future will be. A company, in Barcelona, told
>>> me I'd get hired to continue my past work of packaging OpenStack in
>>> Debian, but so far, I'm still waiting for a definitive answer, so I'm
>>> looking into some other opportunities.
>>> 
>>> All this to say that, unless someone wants to hire me for it (which
>>> would be the best outcome, but I fear this wont happen), or if someone
>>> steps in (this seems unlikely at this point), both the packaging-deb and
>>> the faith of OpenStack packages in Debian are currently compromised.
>>> 
>>> I will continue to maintain OpenStack Newton during the lifetime of
>>> Debian Stretch though, but I don't plan on doing anything more. This
>>> means that maybe, Newton will be the last release of OpenStack in
>>> Debian. If things continue this way, I probably will ask for the removal
>>> of all OpenStack packages from Debian Sid after Stretch gets released
>>> (unless I know that someone will do the work).
>>> 
>>> As a consequence, the following projects wont get packages even in
>>> Ubuntu (as they were "community maintained", which means done by me and
>>> later sync into Ubuntu...):
>>> 
>>> - congress
>>> - gnocchi
>>> - magnum
>>> - mistral
>>> - murano
>>> - sahara
>>> - senlin
>>> - watcher
>>> - zaqar
>>> 
>>> Hopefully, Canonical will continue to maintain the other 15 (more
>>> core...) projects in UCA.
>>> 
>>> Thanks for the fish,
>>> 
>>> Thomas Goirand (zigo)
>>> 
>>> P,S: To the infra folks: please keep the packaging CI as it is, as it
>>> will be useful for the lifetime of Stretch.
>>> 
>> Thanks for all your work. I'm glad we eventually stood up all the packaging
>> infrastructure.
>> 
>> Good luck on your future endeavors.
>> 
> 
> Yes, thank you for everything you've done, Thomas. You have done
> an immense amount of work to ensure that good quality OpenStack
> packages are available to a wide user base.
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] PTG schedule

[Lance Bragstad]

Hi all,

I tried to get most of our things shuffled around into some-what of a
schedule [0]. Everything that was on the list was eventually refactored
into the agenda.

I've broken the various topics out into their own etherpads and linked them
back to the main schedule. We should have the freedom to move things around
as we see fit. The only exceptions are the sessions that we've already
scheduled with other projects (cross-project policy, cross-project
federation, or our joint session with horizon). Moving them might be tough
since we've worked it around schedules from other projects and we've made
the room reservation [1].

I assume we'll need to make some adjustments before the end of the week. If
you see anything that conflicts with another session, please let me know.

Thanks!

[0] https://etherpad.openstack.org/p/keystone-pike-ptg
[1] https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core

[Hidekazu Nakamura]

+1

> -Original Message-
> From: Spencer, Christopher M [mailto:christopher.m.spen...@intel.com]
> Sent: Wednesday, February 15, 2017 11:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core
> 
> +1
> 
> 
> 
> From: Prashanth Hari 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, February 15, 2017 at 5:01 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core
> 
> 
> 
> +1
> 
> 
> 
> On Wed, Feb 15, 2017 at 6:27 AM, Antoine Cabot   > wrote:
> 
>   +1
> 
> 
> 
>   On Tue, Feb 14, 2017 at 5:57 PM, Jean-Émile DARTOIS
> mailto:jean-emile.dart...@b-com.com> >
> wrote:
> 
>   ​+1
> 
> 
> 
>   Jean-Emile
>   DARTOIS
> 
> 
> 
> {P}
> 
> Software Engineer
> Cloud Computing
> 
> {T}
> 
> +33 (0) 2 56 35 8260
> 
> {W}
> 
> www.b-com.com 
> 
> 
> 
> 
> 
>   De : Susanne Balle   >
>   Envoyé : mardi 14 février 2017 17:33
>   À : OpenStack Development Mailing List (not for usage
> questions)
>   Objet : Re: [openstack-dev] [Watcher] Nominating licanwei
> to Watcher Core
> 
> 
> 
>   +1
> 
> 
> 
>   On Tue, Feb 14, 2017 at 5:37 AM, Vincent FRANÇOISE
> mailto:vincent.franco...@b-com.com> >
> wrote:
> 
>   -BEGIN PGP SIGNED MESSAGE-
>   Hash: SHA1
> 
>   +1
> 
>   On 14/02/2017 11:27, ? ? wrote:
>   > His activity will help Watcher Team to make this
> project better.
>   -BEGIN PGP SIGNATURE-
>   Version: GnuPG v2.0.22 (GNU/Linux)
> 
> 
>   iQEcBAEBAgAGBQJYot3aAAoJEEb+XENQ/jVSvIEH/RsqFZZ7hZyA7ExieF7K4G
> mN
> 
>   d1f1vnPbOR3MgqQTbezixIPIwzrDw9dtpU6q8BRPARP6ja2tOPNoYHc1CZmxgw
> z9
> 
>   Mc5iVhvAaKuzL7KKpeROVkLkVUJ9bZnxNM/pkgiq0qXYoBaitgVdPVTIE6nBLd
> pV
> 
>   yHRkUG24pkojogIJGIbB2cJeKganJ+PrCB59buAof1NqEhujt00akfjHCKbc7W
> c/
> 
>   oSmx2VD3aRn8OcfAhQ1pQgRYpa6MRFBRbDUPejVyiGzFWTDreWA3cLVq2xpGEc
> CW
> 
>   ahcq2MNsZCiFegD4u9jYroULOALhdGBUctONbluaqbfZ7PhPPqQxSJGQq96hTC
> g=
>   =WsCi
>   -END PGP SIGNATURE-
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [zaqar] zaqar 4.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for zaqar for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/zaqar/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/ocata

Release notes for zaqar can be found at:

http://docs.openstack.org/releasenotes/zaqar/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to Watcher Core

[Hidekazu Nakamura]

+1

> -Original Message-
> From: Spencer, Christopher M [mailto:christopher.m.spen...@intel.com]
> Sent: Wednesday, February 15, 2017 11:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to
> Watcher Core
> 
> +1
> 
> 
> 
> From: Чадин Александр 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, February 15, 2017 at 6:14 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to
> Watcher Core
> 
> 
> 
> Strong +1
> 
> 
> 
>   On 15 Feb 2017, at 14:27, Antoine Cabot   > wrote:
> 
> 
> 
>   +1
> 
> 
> 
>   On Tue, Feb 14, 2017 at 5:56 PM, Jean-Émile DARTOIS
> mailto:jean-emile.dart...@b-com.com> >
> wrote:
> 
>   ​+1
> 
> 
> 
>   Jean-Emile
>   DARTOIS
> 
> 
> 
> {P}
> 
> Software Engineer
> Cloud Computing
> 
> {T}
> 
> +33 (0) 2 56 35 8260
> 
> {W}
> 
> www.b-com.com 
> 
> 
> 
> 
> 
>   De : Susanne Balle   >
>   Envoyé : mardi 14 février 2017 17:30
>   À : OpenStack Development Mailing List (not for usage
> questions)
>   Objet : Re: [openstack-dev] [Watcher] Nominating Prudhvi
> Rao Shedimbi to Watcher Core
> 
> 
> 
>   +1
> 
> 
> 
>   On Tue, Feb 14, 2017 at 9:31 AM, Prashanth Hari
> mailto:hvpr...@gmail.com> > wrote:
> 
>   +1
> 
> 
> 
>   On Tue, Feb 14, 2017 at 9:22 AM, Joe Cropper
> mailto:cropper@gmail.com> > wrote:
> 
>   +1 !
> 
> 
>   > On Feb 14, 2017, at 4:05 AM, Vincent
> FRANÇOISE   > wrote:
>   >
>   > Team,
>   >
>   > I would like to promote Prudhvi Rao
> Shedimbi to the core team. He's done
>   > a great work in reviewing many
> patchsets[1] and I believe that he has a
>   > good vision of Watcher as a whole.
>   >
>   > I think he would make an excellent
> addition to the team.
>   >
>   > Please vote
>   >
>   > [1]
> http://stackalytics.com/report/contribution/watcher/90
> 
>   >
>   > Vincent FRANCOISE
>   > B<>COM
>   >
>   >
> __
> 
>   > OpenStack Development Mailing List (not
> for usage questions)
>   > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  >
>   >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not
> for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  >
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  >
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  >
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe: openstack-de

Re: [openstack-dev] Ceilometer event-list empty

[Sam Huracan]

Hi Gordon,

I check mongodb has event collection, but it is empty
http://prntscr.com/e9b96w

I do not see any error in Ceilometer log.

Could you check my ceilometer.conf? http://paste.openstack.org/show/598925/




2017-02-16 2:09 GMT+07:00 gordon chung :

>
>
> On 15/02/17 12:06 AM, Sam Huracan wrote:
> > Hi,
> >
> > I'm unable to show event-list of ceilometer, meanwhile meter-list has
> > data. Ceilometer log does not any "ERROR".
> >
> > My ceilometer.conf: http://paste.openstack.org/show/598925/
> > My ceilometer version: http://prntscr.com/e8wob6
> >
> > I'm using OpenStack Mitaka.
> > But, with another system installing Gnocchi dispatcher, I can show
> > event-list.
>
> just to clarify, ceilometer event-list works if you have gnocchi enabled
> but doesn't work if you have everything pushing to mongodb?
>
> i would check mongodb and check your event collection to see if you have
> any data.
>
> if you don't, i would check to see if you have any errors in collector
> or notification agent
>
> if you do, it's probably something related to your policy. only events
> related to a user are returned or if the user is admin, it will return
> all events related to the project.
>
> --
> gord
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[gustavo panizzo]

On Wed, Feb 15, 2017 at 01:42:51PM +0100, Thomas Goirand wrote:
> Hi there,
> 

Its really sad news, for both You and OpenStack & Debian.

I wish you get a contract soon

On the OpenStack side, I wonder if as a community we could (and if it
make sense to do so)  maintain only a few projects, keystone, nova, 
cinder (lvm), neutron (lb + ovs), glance, horizon. 

thanks for your work. it is really appreciated.

> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
> 
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
> 
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
> 
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
> 
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).

> 
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
> 
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
> 
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
> 
> Thanks for the fish,
> 
> Thomas Goirand (zigo)
> 
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
> 

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Heidi Joy Tretheway]

Hi Dan, I’m hoping these answers help, and I’m open to continuing the 
conversation if you’d like. 

> 6 months or so ago we were presented with a new owl from the
> foundation... which had almost none of the same qualities as the
> original. Many of us took a survey about that and provided feedback,
> but I haven't found anyone who was really happy with it. Consensus was
> we liked the originals. Sometimes sticking with your roots is a good
> thing.
> 
You’re right that the new logo didn’t look anything like the original - and we 
heard your team when you said you didn’t like it. We didn’t force you to adopt 
it — instead, we took another swing at the illustration.

> I happened to be off yesterday but I was really discouraged to read
> that the team is now convinced we have to adopt your version of the
> owl: http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2017-
> 02-14-14.00.log.html
> 
Actually, we haven’t tried to convince the team to adopt the illustrator’s 
first edition of the owl - we’ve just tried to come to a compromise that fits 
with the style family of the rest of the mascots. I’ve asked the illustrators 
to try to base a new version on your original. That work is in progress. I 
don’t have that back from the illustrators yet. 

> This all sounds like we are being "steamrolled" into using the new owl
> because things have to align. I'm not asking that you use our owl on
> your website. But if you want to... then great. I think it is possible
> to show that things work together without forcing them all to have the
> same mascot styles:
> https://www.linuxfoundation.org/about

Nobody is being steamrolled. But for use on the foundation website - when used 
in conjunction with the rest of the mascots - we’d like to represent all 
projects with a similar style. I hope that means we’ll be able to represent 
TripleO graphically with an owl that matches the rest in style, but we're not 
going to force you to adopt one. I’ll keep working with the TripleO team until 
we can find a solution that makes your team happy. 
> 
> But I do think the OpenStack Foundation has overstated its case here
> and should reverse track a bit. Make it *clear* that projects can keep
> their own version of their mascots. In fact I think the foundation
> should encourage them to do so (keep the originals). The opposite seems
> be happening on several projects like TripleO and Ironic.
> 
We’ve been as clear as possible that projects can keep using their original 
mascot creations to use in their own ways. While I’d hope that you’d consider 
adopting the new logo, you don’t have to do so. 

Let me be clear also that while TripleO and Ironic originally had outstanding 
mascots with a lot of personality, that was not the case for most teams—which 
had none, or had a poor-quality rendering. So while 95% of the chatter on the 
ML has been about Ironic and TripleO not being happy about their logos, it’s 
not surprising because they started off with a very high bar, and we’ve paid 
special attention to those projects with existing mascots.

I’m doing my best to field a large volume of criticism and work with literally 
hundreds of individuals to deliver something that is very personal and 
important to many. I would just ask that you assume my good intent, and the 
good intent of my colleagues and the illustrators. There’s no vast conspiracy 
to steamroll anyone. My colleague even called it “a love letter to developers” 
in dedicating design resources to create logos where there were none, or make 
some of the lesser-developed logos look better. I can only apologize that we 
haven’t pleased everyone, but reiterate that we’ll continue to do our best to 
improve. 



 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to Watcher Core

[li.canwei2]

+1







李灿伟 licanwei








 NIV Nanjing I Dept./Wireless Product R＆D Institute/Wireless Product Operation









南京市雨花台区花神大道6号中兴通讯2期 
No.6 HuaShen Road, Yuhuatai District, Nanjing, P.R. China, 210012 
E: li.canw...@zte.com.cn 
www.zte.com.cn__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

At the high level all of this sounds like a fine grand plan: "Help
projects create mascots" with a common theme. On the ground level I can
tell you it feels a lot more like you are crushing the spirit of
creativity and motivation for some of us.

What's in a mascot? I dunno. Call it a force of motivation. Call it
team building. In fact, one of the first things I did as PTL of TripleO
was create a mascot for the project. Perhaps not officially... but
there was agreement among those in the project. And we liked the little
guy. And he grew on us. And we even iterated on him a bit and made him
better.



6 months or so ago we were presented with a new owl from the
foundation... which had almost none of the same qualities as the
original. Many of us took a survey about that and provided feedback,
but I haven't found anyone who was really happy with it. Consensus was
we liked the originals. Sometimes sticking with your roots is a good
thing.

I happened to be off yesterday but I was really discouraged to read
that the team is now convinced we have to adopt your version of the
owl: http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2017-
02-14-14.00.log.html

This all sounds like we are being "steamrolled" into using the new owl
because things have to align. I'm not asking that you use our owl on
your website. But if you want to... then great. I think it is possible
to show that things work together without forcing them all to have the
same mascot styles:
 https://www.linuxfoundation.org/about

But I do think the OpenStack Foundation has overstated its case here
and should reverse track a bit. Make it *clear* that projects can keep
their own version of their mascots. In fact I think the foundation
should encourage them to do so (keep the originals). The opposite seems
be happening on several projects like TripleO and Ironic.

P.S. vintage TripleO owl "beany babies" would be super cool

Dan


On Wed, 2017-02-15 at 13:26 -0800, Heidi Joy Tretheway wrote:
> Hi Dan, 
> I’m glad you asked! The value of creating a family of logos is in
> communicating that OpenStack projects work together. While the some
> of the designs of the existing mascots were great, none of them
> looked like they were part of the same family, and that sent a
> message to the market that the projects themselves didn’t necessarily
> work well together. 
> 
> Also, many teams told us they were happy to have design resources to
> make a logo—about three-quarters of projects didn’t have an existing
> logo, and many wanted one but didn’t have the ability to create their
> own. It’s nice to be able to support all projects in the big tent on
> an even footing.
> 
> All teams were encouraged to choose their own mascots; none was
> forced to select one, and projects with existing logos got the first
> right to keep their mascots, which we worked to blend together in a
> consistent style. We also allow projects with existing mascots to
> continue printing vintage swag, like stickers and T-shirts, out of
> respect for the great efforts of the developers who designed the
> originals. 
> 
> The new logos are used on official channels, like the website, and
> they help us better showcase the projects as a group and promote
> them. I’m working with a few projects that haven’t yet settled on a
> design to ensure we can at least reach a compromise, such as for
> TripleO in moving the design closer to the team’s original. (And on
> that note - I’m doing my best to answer each question individually,
> so I appreciate your patience.) 
> 
> In any design undertaking—and especially with this one, which touches
> 60+ project teams—there will be a lot of conflicting views. That’s
> OK, and we’ve done our best to listen to feedback and adapt to teams’
> preferences. I assure you this isn’t an effort to “corporatize” our
> fabulous open source community, but rather to make it feel more
> cohesive and connected. 
> 
> I hope that when you see all of the logos together—and especially
> when you hear more about why teams chose these mascots—that you’ll
> enjoy them as much as I do. (Fun fact: Why did QA chose a little
> brown bat as its mascot? Because that creature eats its weight in
> bugs every day!) It’s been a real pleasure working with the community
> on this project. 
> 
> —Heidi Joy
> 
> 
> > On Feb 15, 2017, at 12:52 PM, Dan Prince 
> > wrote:
> > 
> > The fact that the foundation is involved in "streamlining" team
> > logos
> > just kind of makes me a bit sad I guess. I mean, what value is this
> > really adding to the OpenStack projects?
> > 
> > Devs on many projects spend their own time on creating logos...
> > that
> > they like. I say let them be happy and have their own logos. No
> > harm
> > here I think. Move along and let us focus on the important things.
> > 
> > Dan
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..

Re: [openstack-dev] [all][logos] License for new project mascots

[Qiming Teng]

Thanks, Jeremy. It works now.

- Qiming

On Wed, Feb 15, 2017 at 05:22:59PM +, Jeremy Stanley wrote:
> On 2017-02-15 09:48:28 +0800 (+0800), Qiming Teng wrote:
> > A related question: uploading file to wiki.openstack.org has been
> > blocked? I'm getting the following error when trying to do so.
> > 
> > Action failed
> > 
> > Could not open lock file for
> > "mwstore://local-backend/local-public/2/22/OpenStack_Project_Senlin_horizontal.jpg".
> 
> It seems that in a recent upgrade we ended up with the images file
> tree on the server only readable by the user the Web server runs as
> rather than writeable. I was able to reproduce the same error
> myself, but after adjusting the filesystem permissions it seems to
> be working now. Sorry about that... Can you try again and let us
> know how you get on?
> 
> As an aside, the JPEG versions of those logos suffer from some
> pretty severe compression artifacting, so using the PNG versions (or
> better still converting the EPS versions to SVG) will probably look
> a lot better in the end.
> -- 
> Jeremy Stanley
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][panko] status of pankoclient

[Sheng Liu]

Hi jd__,

Thanks for clarifying, for the convenience to land Panko, we need to
provide a python client library, I have finished a basic python-pankoclient
in these two days, see[1]. which provides a Python API (`pankoclient`
module) and a OSC command tool. according to the OpenStack's tendency, may
all the project's own client's command tool will be move to OSC CLI in the
future. so I didn't add panko coomands. It provides three commands now:
"openstack event capabilities list", "openstack event list", "openstack
event show". To import the pankoclient library to openstack's big tent, I
have uploaded two patches of project-config and governance[2][3]. That need
your +1 :).

What do you guys think about this ?

[1] https://github.com/liu-sheng/python-pankoclient
[2] https://review.openstack.org/#/c/433425/
[3] https://review.openstack.org/#/c/433412/

2017-02-07 18:16 GMT+08:00 Julien Danjou :

> On Tue, Feb 07 2017, Sheng Liu wrote:
>
> Hi,
>
> > As we have moved events related APIs to Panko and deprecated Ceilometer's
> > API, the Panko will be the unique entry of event data. But I cannot find
> > pankoclient in git.openstack.org and launchpad, instead, there is a
> > pankoclient package in Pypi[1]. I am not sure who is the maintainer of
> the
> > pypi lib and what status it is, but it is not convenient to maintaince
> and
> > improve it if it only exist in Pypi. do we have any plan to add a
> > pankoclient in OpenStack's git repo?
>
> There's is no pankoclient right now. The one registered on PyPI was not
> registered by the Telemetry team but by HuachaoMao and I have no clue
> who is that. That does not sound nice.
>
> There's no plan to add any client right now, because nobody proposed to
> take charge of this job.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] python-tricircleclient repo officially created

[joehuang]

Hi, Victor,

Pretty cool! No need to type the boring curl  any more.

Best Regards
Chaoyi Huang (joehuang)

From: Morales, Victor [victor.mora...@intel.com]
Sent: 16 February 2017 0:19
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] python-tricircleclient repo officially 
created

Howdy,

I’m happy to announce that after OpenStack Governance has approved[1] and infra 
them processed the request[2],  the python-tricircleclient repository  has been 
created[3].  This client pretends to make things simpler for users who require 
multi region solutions which can be addressed by Tricircle.  Hopefully this 
project helps for the adoption and visibility of this solution.  Lastly,  this 
client is still under developing and requires all your expertise to improve it 
so feel free to add new capabilities and features that you consider necessary.

Regards,
Victor Morales
irc: electrocucaracha

[1] https://review.openstack.org/#/c/426419/
[2] https://review.openstack.org/#/c/426859/
[3] http://git.openstack.org/cgit/openstack/python-tricircleclient/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Thomas Goirand]

On 02/15/2017 07:11 PM, Ondrej Novy wrote:
> Hi,
> 
> 2017-02-15 13:42 GMT+01:00 Thomas Goirand  >:
> 
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. 
> 
> 
> as second most active openstack-pkg team contributor
> (http://blends.debian.net/liststats/uploaders_pkg-openstack.png) I think
> this not needs to be full time job, but we need more maintainers.

Definitively, we need more maintainers, but it's not happening.

> If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
> 
> 
> please don't ask anyone to remove __team maintained__ packages.

If the team stays inactive, for sure, I will ask for removal.

> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
> 
> done by team, not (only) you.
> 
> I know you done most of packaging work, but please don't say: I'm only
> one who did OS packaging. That's not fair to other contributors.

Yes, you've done some work, and many thanks for it, it has been very
useful. However the reality is: since I stopped after the Newton
release, absolutely no work has been done to package Ocata in Debian. At
this point in the OpenStack dev cycle, normally it should have been
fully uploaded *AND* tested against tempest.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [All][QA][Infra] PTG sessions on Debugging test job failures

[Clark Boylan]

Hello,

The Infra and QA teams will be having two sessions in the "projector"
rooms at the PTG to go over debugging of test job failures. Current plan
is to run a session on Tuesday for the Monday/Tuesday crowd and another
on Thursday for the Wednesday/Thursday/Friday crowd. Both sessions are
at 1:30pm in Macon on their respective days.

The current rough plan I have for the sessions is to talk about what we
log and how to read the logs. Go through some recent failures and how
they were diagnosed, then hopefully tackle one or two of the currently
uncategorized entries in elastic-recheck.

If you have an interest in learning more about how to debug test job
failures it would be great to see you there.

Thanks,
Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hierarchical quotas at the PTG?

[Matt Riedemann]

On 2/15/2017 1:40 PM, Lance Bragstad wrote:


Will there be a dedicated time finalized for this as we get closer to
next week?



I have no idea. I'm guessing someone will ping me when the time comes 
and I'll mosey on over. For whatever doesn't get covered, or needs to 
spill over, Nova is already going to have a block of time to talk about 
quota-related things (not just this) so we can pick it up there too 
later in the week.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Congress] PTG Friday activities

[Eric K]

Hi all,

Here are some options (thinrichs originally suggested) we could consider for
a Friday daytime outing for those interested.

Anyone interested?
Any other ideas?

Georgia Aquarium
- 1st or 2nd largest aquarium in the world.
- #1 on tripAdvisor
- $31.95+tax/adult (advanced online purchase)
http://www.georgiaaquarium.org
https://www.tripadvisor.com/Attraction_Review-g60898-d588792-Reviews-Georgia
_Aquarium-Atlanta_Georgia.html

Atlanta Botanical Garden
- #3 on tripAdvisor
- $21.95+tax/adult
http://atlantabg.org
https://www.tripadvisor.com/Attraction_Review-g60898-d104713-Reviews-Atlanta
_Botanical_Garden-Atlanta_Georgia.html


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] New mascot design

[Jay Faulkner]

Comments inline, in bold


From: Heidi Joy Tretheway 
Sent: Wednesday, February 15, 2017 2:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ironic] New mascot design

Hi Ironic team,

[TL;DR - we agree to Miles’ proposal for two images (one mascot, one logo) for 
different contexts. We’re looking for any final feedback on the stylized logo 
for use on the website, while the PixieBoots mascot remains yours for swag, 
etc.]

I’m doing my best to reply to all questions on this thread as Lucas requested: 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112212.html.
Please feel free to drop a note here if I’ve missed anything. I’m summarizing 
everything below:

Design issues:
—The bear looked angry in v1
Answer: We removed the angry expression and replaced it with a neutral 
expression
—The metal horns hand gesture is culturally inappropriate (rude in some 
countries) (from Ruby)
Answer: We removed this feature and replaced it, based on the team’s input, 
with the bear holding sticks (as drumsticks)
—What about a goat-like horned bear? (Joanna)
Answer: We removed horned references due to the cultural reference to 
cuckolding as the Ironic team pointed out
—The bear looks too much like a Russian meme with two hands up
Answer: We have a face-forward bear, not a side-view bear, and only one hand 
raised.
—The bear’s face decoration looked too much like the band Kiss
Answer: While this was intentional by the designer (for a more “metal” look), 
we removed this feature and replaced it with basic bear face coloring. Some 
folks (including Miles, Dmitry, Sam who added +1s) would like this back in. 
We’re happy to do it, we just need the team to agree on one direction.

I'm OK either way, but liked the "KISS" style face painting.

—Don’t like the style (reminds Lucas of church windows)
Answer: The design style for all of the mascots is set. It was shared in July 
when we started this project, and unfortunately the feedback window regarding 
design style has passed, as 95% of projects have now received their logos.
—Request to abbreviate the bear so it just shows head/top of torso/hand holding 
drumsticks (from Dmitry)
Answer: We can revisit that with the designers, however it doesn’t match the 
rest of the logo set, which is either face or full body of each mascot. We’re 
happy to try this, but as we’ve already been four rounds with the team, I’m 
soliciting ANY final feedback on this version before we finalize it.
[cid:389D8878-F39E-485B-B2CA-8B586ABD228C]

I'm OK with this. I think it'll be the closest we'll get to something everyone 
can agree on. +1 from me.


Outstanding questions:
—Can we use PixieBoots in the future?
Answer: Absolutely. You’re welcome to produce vintage swag like shirts and 
stickers with your original logo. Any team can use their old logo in this way. 
Put another way, if you’d like to call PixieBoots your mascot, but refer to the 
Ironic logo our illustrators have created as merely a logo, that’s fine. And 
you don’t have to use this logo if you don’t want to.
—Can we use (1) A stylized logo, matching the guidelines, for use in “official” 
settings and anywhere that it will be seen in other projects’ logos; and (2) 
Our existing PixieBoots mascot, for use in “official” settings (laptop 
stickers, T-shirts, chatbots, webcomic, etc.)? (suggested by Miles)
Answer: Great suggestion! Yes. Together with the answer above, that’s our 
intention—we’d like for you to be able to continue to use your beloved mascot 
in your own way, and we’d like the Ironic team to select some logo that is 
consistent with the rest of the community project logos, that we can use on 
official channels such as the website.
—What will we see at the PTG?
Answer: Out of respect for the team, we did not print stickers or signage for 
the Ironic team with any logo on it until the team reaches an agreement.
—What license will the mascot have?
Answer: It will be CC-BY-ND, which the foundation uses for most of our 
collateral. That allows you to use it (and we’ve provided ten versions to the 
PTLs of the projects with finalized mascots so they have a good amount of 
flexibility in logo use). It prevents, for example, a for-profit company from 
inserting its commercial logo into an element of the community-use mascots 
(which was a common request early in the design process). If you would like to 
make a derivative work, we can definitely find a way to compromise, just send 
me a note.
—What does the foundation want to achieve with this? (from Lucas)
Answer: We’re trying to communicate, by way of design, that the projects are 
cohesive and connected, while still preserving (via a team-selected mascot) the 
team’s individual identity. We’d also like to help those projects that don’t 
have design resources present themselves on an even footing with the others. 
The majority of projects didn’t have their own mascots when this process bega

[openstack-dev] [ironic] New mascot design

[Heidi Joy Tretheway]

Hi Ironic team, 

[TL;DR - we agree to Miles’ proposal for two images (one mascot, one logo) for 
different contexts. We’re looking for any final feedback on the stylized logo 
for use on the website, while the PixieBoots mascot remains yours for swag, 
etc.]

I’m doing my best to reply to all questions on this thread as Lucas requested: 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112212.html 
. 
Please feel free to drop a note here if I’ve missed anything. I’m summarizing 
everything below:

Design issues: 
—The bear looked angry in v1
Answer: We removed the angry expression and replaced it with a neutral 
expression
—The metal horns hand gesture is culturally inappropriate (rude in some 
countries) (from Ruby)
Answer: We removed this feature and replaced it, based on the team’s input, 
with the bear holding sticks (as drumsticks)
—What about a goat-like horned bear? (Joanna)
Answer: We removed horned references due to the cultural reference to 
cuckolding as the Ironic team pointed out
—The bear looks too much like a Russian meme with two hands up
Answer: We have a face-forward bear, not a side-view bear, and only one hand 
raised.
—The bear’s face decoration looked too much like the band Kiss
Answer: While this was intentional by the designer (for a more “metal” look), 
we removed this feature and replaced it with basic bear face coloring. Some 
folks (including Miles, Dmitry, Sam who added +1s) would like this back in. 
We’re happy to do it, we just need the team to agree on one direction.
—Don’t like the style (reminds Lucas of church windows)
Answer: The design style for all of the mascots is set. It was shared in July 
when we started this project, and unfortunately the feedback window regarding 
design style has passed, as 95% of projects have now received their logos. 
—Request to abbreviate the bear so it just shows head/top of torso/hand holding 
drumsticks (from Dmitry)
Answer: We can revisit that with the designers, however it doesn’t match the 
rest of the logo set, which is either face or full body of each mascot. We’re 
happy to try this, but as we’ve already been four rounds with the team, I’m 
soliciting ANY final feedback on this version before we finalize it. 


Outstanding questions: 
—Can we use PixieBoots in the future? 
Answer: Absolutely. You’re welcome to produce vintage swag like shirts and 
stickers with your original logo. Any team can use their old logo in this way. 
Put another way, if you’d like to call PixieBoots your mascot, but refer to the 
Ironic logo our illustrators have created as merely a logo, that’s fine. And 
you don’t have to use this logo if you don’t want to. 
—Can we use (1) A stylized logo, matching the guidelines, for use in “official” 
settings and anywhere that it will be seen in other projects’ logos; and (2) 
Our existing PixieBoots mascot, for use in “official” settings (laptop 
stickers, T-shirts, chatbots, webcomic, etc.)? (suggested by Miles)
Answer: Great suggestion! Yes. Together with the answer above, that’s our 
intention—we’d like for you to be able to continue to use your beloved mascot 
in your own way, and we’d like the Ironic team to select some logo that is 
consistent with the rest of the community project logos, that we can use on 
official channels such as the website.
—What will we see at the PTG?
Answer: Out of respect for the team, we did not print stickers or signage for 
the Ironic team with any logo on it until the team reaches an agreement. 
—What license will the mascot have?
Answer: It will be CC-BY-ND, which the foundation uses for most of our 
collateral. That allows you to use it (and we’ve provided ten versions to the 
PTLs of the projects with finalized mascots so they have a good amount of 
flexibility in logo use). It prevents, for example, a for-profit company from 
inserting its commercial logo into an element of the community-use mascots 
(which was a common request early in the design process). If you would like to 
make a derivative work, we can definitely find a way to compromise, just send 
me a note. 
—What does the foundation want to achieve with this? (from Lucas)
Answer: We’re trying to communicate, by way of design, that the projects are 
cohesive and connected, while still preserving (via a team-selected mascot) the 
team’s individual identity. We’d also like to help those projects that don’t 
have design resources present themselves on an even footing with the others. 
The majority of projects didn’t have their own mascots when this process began. 

What’s next? 
I’ll monitor this ML string for feedback. I tried to host a live call with your 
team to hash out the conflicting feedback, but nobody showed up. So instead, at 
the team’s request, I’ll rely on your thoughts via this email string, and do my 
best to move forward based on what appears to be the majority response. 

One final thought—please be open-mi

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Jeremy Stanley]

On 2017-02-15 16:54:17 -0500 (-0500), Dan Prince wrote:
> I was off earlier this week (and unfortunately couldn't attend the
> weekly meeting) but from the sound of it a very different conclusion
> has been reached within the TripleO community. Apparently, this was
> understood to mean that we *could not* keep our existing logo. And that
> is sad thing to do "just because" someone wants to have a common theme.
[...]

I think the upshot there is merely that www.openstack.org and
similar foundation-controlled Web properties won't use your
"classic" logo and will use the new one instead. But you can
certainly still use the old one yourself wherever you like on
community-controlled sites and other places as you see fit.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Ben Finney]

Thomas Goirand  writes:

> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb
> and the faith of OpenStack packages in Debian are currently
> compromised.

Thanks for your work, Thomas, and yes I hope someone hires you and other
skilled maintainers to continue OpenStack in Debian.

Nadia Eghbal's work documenting the state of critical infrastructure
https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.str97fkhj>
has led her to create a guide for seeking funding for crucial
free-software infrastructure
https://github.com/nayafia/lemonade-stand>.


For those parties who are profiting from OpenStack, or any other
free-software project, you need to read “Roads and Bridges”
http://www.fordfoundation.org/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure>
and *fund* the maintenance of this infrastructure.

Stories like Thomas's should gavlanise you to put sustained funding in
for the projects that provide your own lifeblood. Step up, join with
others, and make this right.

-- 
 \   “Pray, v. To ask that the laws of the universe be annulled in |
  `\ behalf of a single petitioner confessedly unworthy.” —Ambrose |
_o__)   Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

I was off earlier this week (and unfortunately couldn't attend the
weekly meeting) but from the sound of it a very different conclusion
has been reached within the TripleO community. Apparently, this was
understood to mean that we *could not* keep our existing logo. And that
is sad thing to do "just because" someone wants to have a common theme.

So I say lets keep it. And continue using it as is...

At least that is the way it is in some communities:

https://www.kernel.org/

And yes. They have stylized old tux as well... but at least they kept
the original too.

Dan

On Wed, 2017-02-15 at 21:12 +, Jeremy Stanley wrote:
> On 2017-02-15 15:52:30 -0500 (-0500), Dan Prince wrote:
> > The fact that the foundation is involved in "streamlining" team
> > logos
> > just kind of makes me a bit sad I guess. I mean, what value is this
> > really adding to the OpenStack projects?
> > 
> > Devs on many projects spend their own time on creating logos...
> > that
> > they like. I say let them be happy and have their own logos. No
> > harm
> > here I think. Move along and let us focus on the important things.
> 
> [...]
> 
> There's definitely nothing stopping various teams from using other
> logos if they want. The OpenStack Foundation doesn't govern the
> project, they merely want to have a consistent set of logos _they_
> can use on their own site when providing aggregate information about
> multiple teams and were hoping that they could gather enough
> feedback to be able to put together something that those teams would
> also be interested in reusing. It's in no way mandatory or exclusive
> of other art you may already have and feel a connection with.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[melanie witt]

On Wed, 15 Feb 2017 16:34:57 -0500, Corey Bryant wrote:

I think I figured it out.  I'll submit a patch in a little bit.


Great, post a link to the patch after you upload it and we'll review.

Also note earlier I forgot to mention --name should also be optional for 
the command (everything except --cell_uuid). I think you could also get 
fancy and require at least one of those things, otherwise it's just a no-op.


-melanie

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 4:34 PM, Corey Bryant 
wrote:

>
> On Wed, Feb 15, 2017 at 4:26 PM, melanie witt  wrote:
>
>> On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:
>>
>>> This works but you have to specify all of the args (--cell_uuid, --name,
>>> --transport-url and --database_connection).  Otherwise you'll hit
>>> this: http://paste.ubuntu.com/24003055/
>>>
>>
>> Corey,
>>
>> Thanks for pointing that out.
>>
>> It looks like the command intended to have --transport-url and
>> --database_connection as optional but missed defaulting them to None in the
>> function parameter list.
>>
>> -melanie
>
>
> I think I figured it out.  I'll submit a patch in a little bit.
>
>
>
You're correct btw :)


-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 4:26 PM, melanie witt  wrote:

> On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:
>
>> This works but you have to specify all of the args (--cell_uuid, --name,
>> --transport-url and --database_connection).  Otherwise you'll hit
>> this: http://paste.ubuntu.com/24003055/
>>
>
> Corey,
>
> Thanks for pointing that out.
>
> It looks like the command intended to have --transport-url and
> --database_connection as optional but missed defaulting them to None in the
> function parameter list.
>
> -melanie


I think I figured it out.  I'll submit a patch in a little bit.

-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] notification impact of moving the instance create to the conductor

[Matt Riedemann]

On 2/15/2017 11:07 AM, Balazs Gibizer wrote:

Hi,

It seems that the Move instance creation to conductor commit [1] changed
when and how the instance.delete notification is emitted for an
unscheduled instance. Unfortunately the legacy notification doesn't have
test coverage and the versioned notification coverage are still on
review [2] for this case.

Before [1] the instance.delete for an unscheduled instance is emitted
from here [3]. But after [1] the execution of the same delete operation
goes to a new direction [4] and never reaches [3].
Before [1] the new test coverage in [2] was passing but now after [1] is
merged the test_create_server_error fails as the instance.delete
notification is not emitted.

Is it an intentional change or a bug? If it is a bug could you give me
some pointers how to restore the original notification behavior?

Cheers,
gibi

[1] https://review.openstack.org/#/c/319379
[2] https://review.openstack.org/#/c/410297
[3] https://review.openstack.org/#/c/410297/9/nova/compute/api.py@1860
[4] https://review.openstack.org/#/c/319379/84/nova/compute/api.py@1790


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


This isn't intentional, it was just missed. So please create a bug for 
tracking this and we'll have to backport that to stable/ocata.


I think we could send the notification here [1] if we have a build 
request and delete it.


Or here [2] if the build request is already deleted and we have to 
delete the instance in the cell.


The thing that is tricking me here is we might also need to handle it in 
conductor here [3].


Needless to say we're going to want a utility method probably so we 
don't have to duplicate the same notify_start/delete/notify_end block of 
code all over compute API and conductor.


[1] 
https://github.com/openstack/nova/blob/93bf6ba5186a3663606aa843a2f247709173f073/nova/compute/api.py#L1759
[2] 
https://github.com/openstack/nova/blob/93bf6ba5186a3663606aa843a2f247709173f073/nova/compute/api.py#L1790
[3] 
https://github.com/openstack/nova/blob/93bf6ba5186a3663606aa843a2f247709173f073/nova/conductor/manager.py#L963


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[melanie witt]

On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:

This works but you have to specify all of the args (--cell_uuid, --name,
--transport-url and --database_connection).  Otherwise you'll hit
this: http://paste.ubuntu.com/24003055/


Corey,

Thanks for pointing that out.

It looks like the command intended to have --transport-url and 
--database_connection as optional but missed defaulting them to None in 
the function parameter list.


-melanie

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Heidi Joy Tretheway]

Hi Dan, 
I’m glad you asked! The value of creating a family of logos is in communicating 
that OpenStack projects work together. While the some of the designs of the 
existing mascots were great, none of them looked like they were part of the 
same family, and that sent a message to the market that the projects themselves 
didn’t necessarily work well together. 

Also, many teams told us they were happy to have design resources to make a 
logo—about three-quarters of projects didn’t have an existing logo, and many 
wanted one but didn’t have the ability to create their own. It’s nice to be 
able to support all projects in the big tent on an even footing.

All teams were encouraged to choose their own mascots; none was forced to 
select one, and projects with existing logos got the first right to keep their 
mascots, which we worked to blend together in a consistent style. We also allow 
projects with existing mascots to continue printing vintage swag, like stickers 
and T-shirts, out of respect for the great efforts of the developers who 
designed the originals. 

The new logos are used on official channels, like the website, and they help us 
better showcase the projects as a group and promote them. I’m working with a 
few projects that haven’t yet settled on a design to ensure we can at least 
reach a compromise, such as for TripleO in moving the design closer to the 
team’s original. (And on that note - I’m doing my best to answer each question 
individually, so I appreciate your patience.) 

In any design undertaking—and especially with this one, which touches 60+ 
project teams—there will be a lot of conflicting views. That’s OK, and we’ve 
done our best to listen to feedback and adapt to teams’ preferences. I assure 
you this isn’t an effort to “corporatize” our fabulous open source community, 
but rather to make it feel more cohesive and connected. 

I hope that when you see all of the logos together—and especially when you hear 
more about why teams chose these mascots—that you’ll enjoy them as much as I 
do. (Fun fact: Why did QA chose a little brown bat as its mascot? Because that 
creature eats its weight in bugs every day!) It’s been a real pleasure working 
with the community on this project. 

—Heidi Joy


> On Feb 15, 2017, at 12:52 PM, Dan Prince  wrote:
> 
> The fact that the foundation is involved in "streamlining" team logos
> just kind of makes me a bit sad I guess. I mean, what value is this
> really adding to the OpenStack projects?
> 
> Devs on many projects spend their own time on creating logos... that
> they like. I say let them be happy and have their own logos. No harm
> here I think. Move along and let us focus on the important things.
> 
> Dan


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 10:20 AM, Dan Smith  wrote:

> > The problem is there's no way to update an existing cell's transport_url
> > via nova-manage.
>
> There is:
>
> https://review.openstack.org/#/c/431582/


Dan,

This works but you have to specify all of the args (--cell_uuid, --name,
--transport-url and --database_connection).  Otherwise you'll hit this:
http://paste.ubuntu.com/24003055/

-- 
Regards,
Corey


>
>
> > It appears the only way to get around this is manually deleting the old
> > cell1 record from the db.
>
> No, don't do that :)
>
> > I'd like to hear more opinions on this but it really seems like this
> > should be a priority to fix prior to the Ocata final release.
>
> Already done!
>
> --Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Jeremy Stanley]

On 2017-02-15 15:52:30 -0500 (-0500), Dan Prince wrote:
> The fact that the foundation is involved in "streamlining" team logos
> just kind of makes me a bit sad I guess. I mean, what value is this
> really adding to the OpenStack projects?
> 
> Devs on many projects spend their own time on creating logos... that
> they like. I say let them be happy and have their own logos. No harm
> here I think. Move along and let us focus on the important things.
[...]

There's definitely nothing stopping various teams from using other
logos if they want. The OpenStack Foundation doesn't govern the
project, they merely want to have a consistent set of logos _they_
can use on their own site when providing aggregate information about
multiple teams and were hoping that they could gather enough
feedback to be able to put together something that those teams would
also be interested in reusing. It's in no way mandatory or exclusive
of other art you may already have and feel a connection with.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Ihar Hrachyshka]

Another potentially interesting devstack service that may help us to
understand our memory usage is peakmem_tracker. At this point, it's
not enabled anywhere. I proposed devstack-gate patch to enable it at:
https://review.openstack.org/#/c/434511/

On Wed, Feb 15, 2017 at 12:38 PM, Ihar Hrachyshka  wrote:
> Another potentially relevant info is, we saw before that oom-killer is
> triggered while 8gb of swap are barely used. This behavior is hard to
> explain, since we set kernel swappiness sysctl knob to 30:
>
> https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L432
>
> (and any value above 0 means that if memory is requested, and there is
> swap available to fulfill it, it will not fail to allocate memory;
> swappiness only controls willingness of kernel to swap process pages
> instead of dropping disk cache entries, it may affect performance, but
> it should not affect malloc behavior).
>
> The only reason I can think of for a memory allocation request to
> trigger the trap when swap is free is when the memory request is for a
> RAM-locked page (it can either be memory locked with mlock(2), or
> mmap(2) when MAP_LOCKED used). To understand if that's the case in
> gate, I am adding a new mlock_tracker service to devstack:
> https://review.openstack.org/#/c/434470/
>
> The patch that enables the service in Pike+ gate is:
> https://review.openstack.org/#/c/434474/
>
> Thanks,
> Ihar
>
> On Wed, Feb 15, 2017 at 5:21 AM, Andrea Frittoli
>  wrote:
>> Some (new?) data on the oom kill issue in the gate.
>>
>> I filed a new bug / E-R query yet for the issue [1][2] since it looks to me
>> like the issue is not specific to mysqld - oom-kill will just pick the best
>> candidate, which in most cases happens to be mysqld. The next most likely
>> candidate to show errors in the logs is keystone, since token requests are
>> rather frequent, more than any other API call probably.
>>
>> According to logstash [3] all failures identified by [2] happen on RAX nodes
>> [3], which I hadn't realised before.
>>
>> Comparing dstat data between the failed run and a successful on an OVH node
>> [4], the main difference I can spot is free memory.
>> For the same test job, the free memory tends to be much lower, quite close
>> to zero for the majority of the time on the RAX node. My guess is that an
>> unlucky scheduling of tests may cause a slightly higher peak in memory usage
>> and trigger the oom-kill.
>>
>> I find it hard to relate lower free memory to a specific cloud provider /
>> underlying virtualisation technology, but maybe someone has an idea about
>> how that could be?
>>
>> Andrea
>>
>> [0]
>> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/6f31320/logs/syslog.txt.gz#_Feb_14_00_32_28
>> [1] https://bugs.launchpad.net/tempest/+bug/1664953
>> [2] https://review.openstack.org/434238
>> [3]
>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Out%20of%20memory%3A%20Kill%20process%5C%22%20AND%20tags%3A%5C%22syslog.txt%5C%22
>> [4]
>> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/1dfb4b7/logs/dstat-csv_log.txt.gz
>>
>> On Mon, Feb 6, 2017 at 10:13 AM Miguel Angel Ajo Pelayo
>>  wrote:
>>>
>>> Jeremy Stanley wrote:
>>>
>>>
>>> > It's an option of last resort, I think. The next consistent flavor
>>> > up in most of the providers donating resources is double the one
>>> > we're using (which is a fairly typical pattern in public clouds). As
>>> > aggregate memory constraints are our primary quota limit, this would
>>> > effectively halve our current job capacity.
>>>
>>> Properly coordinated with all the cloud the providers, they could create
>>> flavours which are private but available to our tenants, where a 25-50% more
>>> RAM would be just enough.
>>>
>>> I agree that should probably be a last resort tool, and we should keep
>>> looking for proper ways to find where we consume unnecessary RAM and make
>>> sure that's properly freed up.
>>>
>>> It could be interesting to coordinate such flavour creation in the mean
>>> time, even if we don't use it now, we could eventually test it or put it to
>>> work if we find trapped anytime later.
>>>
>>>
>>> On Sun, Feb 5, 2017 at 8:37 PM, Matt Riedemann 
>>> wrote:

 On 2/5/2017 1:19 PM, Clint Byrum wrote:
>
>
> Also I wonder if there's ever been any serious consideration given to
> switching to protobuf? Feels like one could make oslo.versionedobjects
> a wrapper around protobuf relatively easily, but perhaps that's already
> been explored in a forum that I wasn't paying attention to.


 I've never heard of anyone attempting that.

 --

 Thanks,

 Matt Riedemann



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.or

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

The fact that the foundation is involved in "streamlining" team logos
just kind of makes me a bit sad I guess. I mean, what value is this
really adding to the OpenStack projects?

Devs on many projects spend their own time on creating logos... that
they like. I say let them be happy and have their own logos. No harm
here I think. Move along and let us focus on the important things.

Dan

On Tue, 2017-02-14 at 09:44 -0500, Emilien Macchi wrote:
> Heidi,
> 
> TripleO team discussed about the logo this morning during our weekly
> meeting.
> We understood that we had to change our existing logo because it
> doesn't meet OpenStack themes requirements, and that's fine.
> 
> Though we would like you to re-iterate on a new logo that would be a
> variation on the current logo that moves closer to the foundation.
> 
> Our existing logo is: http://tripleo.org/_static/tripleo_owl.svg
> 
> Please let us know if you can prepare a new logo close to this one,
> and I think we would find a middle ground here.
> 
> Thanks a lot,
> 
> On Tue, Feb 14, 2017 at 7:30 AM, Carlos Camacho Gonzalez
>  wrote:
> > I'll vote also for option 1 if we can keep it.
> > 
> > One thing, you can see how designers have iterated over ironic's
> > logo
> > http://lists.openstack.org/pipermail/openstack-dev/attachments/2017
> > 0201/a016f685/attachment.png
> > to fit the OpenStack illustration style.
> > 
> > Is it possible for designers to iterate over
> > http://tripleo.org/_static/tripleo_owl.svg to make it fit the
> > guidelines?
> > 
> > Cheers,
> > Carlos.
> > 
> > On Tue, Feb 14, 2017 at 12:34 PM, Lucas Alvares Gomes
> >  wrote:
> > > 
> > > Hi,
> > > 
> > > Just a FYI, we have had similar discussions about the proposed
> > > logo for
> > > Ironic, there's still many unanswered questions but, if you guys
> > > are
> > > interested this is the link to the ML thread:
> > > http://lists.openstack.org/pipermail/openstack-dev/2017-February/
> > > 111401.html
> > > 
> > > Cheers,
> > > Lucas
> > > 
> > > On Tue, Feb 14, 2017 at 2:38 AM, Emilien Macchi  > > om>
> > > wrote:
> > > > 
> > > > Team, I've got this email from Heidi.
> > > > 
> > > > I see 3 options :
> > > > 
> > > > 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.s
> > > > vg .
> > > > 
> > > > 2. Re-design a new logo that "meets" OpenStack "requirements".
> > > > 
> > > > 3. Pick-up the one proposed (see below).
> > > > 
> > > > 
> > > > Personally, I would vote for keeping our existing logo (1.)
> > > > unless
> > > > someone has time to create another one or if the team likes the
> > > > proposed
> > > > one.
> > > > 
> > > > The reason why I want to keep our logo is because our current
> > > > logo was
> > > > created by TripleO devs, we like it and we already have tee-
> > > > shirts and other
> > > > goodies with it. I don't see any good reason to change it.
> > > > 
> > > > Discussion is open and we'll vote as a team.
> > > > 
> > > > Thanks,
> > > > 
> > > > Emilien.
> > > > 
> > > > -- Forwarded message --
> > > > From: Heidi Joy Tretheway 
> > > > Date: Mon, Feb 13, 2017 at 8:27 PM
> > > > Subject: TripleO mascot - how can I help your team?
> > > > To: Emilien Macchi 
> > > > 
> > > > 
> > > > Hi Emilien,
> > > > 
> > > > I’m following up on the much-debated TripleO logo. I’d like to
> > > > help your
> > > > team reach a solution that makes them happy but still fits
> > > > within the family
> > > > of logos we’re using at the PTG and going forward. Here’s what
> > > > our
> > > > illustrators came up with, which hides an “O” shape in the owl
> > > > (face and
> > > > wing arcs).
> > > > 
> > > > https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3b
> > > > LfHFa?dl=0
> > > > At this point, I don’t have quorum from your team (I got a lot
> > > > of
> > > > conflicting feedback, most of which was “don’t like” but not
> > > > actionable for
> > > > the illustrators to make a revision). At the PTG, we’ll have
> > > > mascot stickers
> > > > and signage for all teams except for Ironic and TripleO, since
> > > > we’re still
> > > > waiting on your teams to make a final decision.
> > > > 
> > > > May I recommend that your team choose one person (or a small
> > > > group of no
> > > > more than three) to finalize this? I was able to work through
> > > > all of Swift’s
> > > > issues with just a quick 15-minute chat with John Dickinson and
> > > > I’d like to
> > > > believe we can solve this for TripleO as well.
> > > > 
> > > > We know some of your team has expressed concern over retiring
> > > > the
> > > > existing mascot. It’s not our intention to make anyone “get rid
> > > > of” a
> > > > beloved icon. Your team can certainly print it on vintage items
> > > > like shirts
> > > > and stickers. But for official channels like the website, we
> > > > need a logo to
> > > > represent TripleO that’s cohesive with the rest of the set.
> > > > 
> > > > Perhaps when you’re face to face with your team at the PTG, you
> > > > can
> > > > discuss 

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

On Tue, 2017-02-14 at 13:30 +0100, Carlos Camacho Gonzalez wrote:
> I'll vote also for option 1 if we can keep it.
> 
> One thing, you can see how designers have iterated over ironic's logo
> http://lists.openstack.org/pipermail/openstack-
> dev/attachments/20170201/a016f685/attachment.png to fit the OpenStack
> illustration style.
> 
> Is it possible for designers to iterate over
> http://tripleo.org/_static/tripleo_owl.svg to make it fit the
> guidelines?

There was a survey that came out after the last summit and I thought
many of us already asked them to do that... but yes. If they can it
might be acceptable. But I think we should get to decide if we like it
or not.

Dan

> 
> Cheers,
> Carlos.
> 
> On Tue, Feb 14, 2017 at 12:34 PM, Lucas Alvares Gomes  ail.com> wrote:
> >
> > Hi,
> >
> > Just a FYI, we have had similar discussions about the proposed logo
> for Ironic, there's still many unanswered questions but, if you guys
> are interested this is the link to the ML thread: http://lists.openst
> ack.org/pipermail/openstack-dev/2017-February/111401.html
> >
> > Cheers,
> > Lucas
> >
> > On Tue, Feb 14, 2017 at 2:38 AM, Emilien Macchi  > wrote:
> >>
> >> Team, I've got this email from Heidi.
> >>
> >> I see 3 options :
> >>
> >> 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg
> .
> >>
> >> 2. Re-design a new logo that "meets" OpenStack "requirements".
> >>
> >> 3. Pick-up the one proposed (see below).
> >>
> >>
> >> Personally, I would vote for keeping our existing logo (1.) unless
> someone has time to create another one or if the team likes the
> proposed one.
> >>
> >> The reason why I want to keep our logo is because our current logo
> was created by TripleO devs, we like it and we already have tee-
> shirts and other goodies with it. I don't see any good reason to
> change it.
> >>
> >> Discussion is open and we'll vote as a team.
> >>
> >> Thanks,
> >>
> >> Emilien.
> >>
> >> -- Forwarded message --
> >> From: Heidi Joy Tretheway 
> >> Date: Mon, Feb 13, 2017 at 8:27 PM
> >> Subject: TripleO mascot - how can I help your team?
> >> To: Emilien Macchi 
> >>
> >>
> >> Hi Emilien,
> >>
> >> I’m following up on the much-debated TripleO logo. I’d like to
> help your team reach a solution that makes them happy but still fits
> within the family of logos we’re using at the PTG and going forward.
> Here’s what our illustrators came up with, which hides an “O” shape
> in the owl (face and wing arcs).
> >>
> >> https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLfH
> Fa?dl=0
> >> At this point, I don’t have quorum from your team (I got a lot of
> conflicting feedback, most of which was “don’t like” but not
> actionable for the illustrators to make a revision). At the PTG,
> we’ll have mascot stickers and signage for all teams except for
> Ironic and TripleO, since we’re still waiting on your teams to make a
> final decision.
> >>
> >> May I recommend that your team choose one person (or a small group
> of no more than three) to finalize this? I was able to work through
> all of Swift’s issues with just a quick 15-minute chat with John
> Dickinson and I’d like to believe we can solve this for TripleO as
> well.
> >>
> >> We know some of your team has expressed concern over retiring the
> existing mascot. It’s not our intention to make anyone “get rid of” a
> beloved icon. Your team can certainly print it on vintage items like
> shirts and stickers. But for official channels like the website, we
> need a logo to represent TripleO that’s cohesive with the rest of the
> set.
> >>
> >> Perhaps when you’re face to face with your team at the PTG, you
> can discuss and hopefully render a final decision to either accept
> this as a logo, or determine a few people willing to make any final
> changes with me?
> >>
> >> Thanks in advance for your help!
> >>
> >>
> >> Heidi Joy Tretheway
> >> Senior Marketing Manager, OpenStack Foundation
> >> 503 816 9769 | Skype: heidi.tretheway
> >>  
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Emilien Macchi
> >>
> >>
> _
> _
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:uns
> ubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> _
> _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Ihar Hrachyshka]

Another potentially relevant info is, we saw before that oom-killer is
triggered while 8gb of swap are barely used. This behavior is hard to
explain, since we set kernel swappiness sysctl knob to 30:

https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L432

(and any value above 0 means that if memory is requested, and there is
swap available to fulfill it, it will not fail to allocate memory;
swappiness only controls willingness of kernel to swap process pages
instead of dropping disk cache entries, it may affect performance, but
it should not affect malloc behavior).

The only reason I can think of for a memory allocation request to
trigger the trap when swap is free is when the memory request is for a
RAM-locked page (it can either be memory locked with mlock(2), or
mmap(2) when MAP_LOCKED used). To understand if that's the case in
gate, I am adding a new mlock_tracker service to devstack:
https://review.openstack.org/#/c/434470/

The patch that enables the service in Pike+ gate is:
https://review.openstack.org/#/c/434474/

Thanks,
Ihar

On Wed, Feb 15, 2017 at 5:21 AM, Andrea Frittoli
 wrote:
> Some (new?) data on the oom kill issue in the gate.
>
> I filed a new bug / E-R query yet for the issue [1][2] since it looks to me
> like the issue is not specific to mysqld - oom-kill will just pick the best
> candidate, which in most cases happens to be mysqld. The next most likely
> candidate to show errors in the logs is keystone, since token requests are
> rather frequent, more than any other API call probably.
>
> According to logstash [3] all failures identified by [2] happen on RAX nodes
> [3], which I hadn't realised before.
>
> Comparing dstat data between the failed run and a successful on an OVH node
> [4], the main difference I can spot is free memory.
> For the same test job, the free memory tends to be much lower, quite close
> to zero for the majority of the time on the RAX node. My guess is that an
> unlucky scheduling of tests may cause a slightly higher peak in memory usage
> and trigger the oom-kill.
>
> I find it hard to relate lower free memory to a specific cloud provider /
> underlying virtualisation technology, but maybe someone has an idea about
> how that could be?
>
> Andrea
>
> [0]
> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/6f31320/logs/syslog.txt.gz#_Feb_14_00_32_28
> [1] https://bugs.launchpad.net/tempest/+bug/1664953
> [2] https://review.openstack.org/434238
> [3]
> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Out%20of%20memory%3A%20Kill%20process%5C%22%20AND%20tags%3A%5C%22syslog.txt%5C%22
> [4]
> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/1dfb4b7/logs/dstat-csv_log.txt.gz
>
> On Mon, Feb 6, 2017 at 10:13 AM Miguel Angel Ajo Pelayo
>  wrote:
>>
>> Jeremy Stanley wrote:
>>
>>
>> > It's an option of last resort, I think. The next consistent flavor
>> > up in most of the providers donating resources is double the one
>> > we're using (which is a fairly typical pattern in public clouds). As
>> > aggregate memory constraints are our primary quota limit, this would
>> > effectively halve our current job capacity.
>>
>> Properly coordinated with all the cloud the providers, they could create
>> flavours which are private but available to our tenants, where a 25-50% more
>> RAM would be just enough.
>>
>> I agree that should probably be a last resort tool, and we should keep
>> looking for proper ways to find where we consume unnecessary RAM and make
>> sure that's properly freed up.
>>
>> It could be interesting to coordinate such flavour creation in the mean
>> time, even if we don't use it now, we could eventually test it or put it to
>> work if we find trapped anytime later.
>>
>>
>> On Sun, Feb 5, 2017 at 8:37 PM, Matt Riedemann 
>> wrote:
>>>
>>> On 2/5/2017 1:19 PM, Clint Byrum wrote:


 Also I wonder if there's ever been any serious consideration given to
 switching to protobuf? Feels like one could make oslo.versionedobjects
 a wrapper around protobuf relatively easily, but perhaps that's already
 been explored in a forum that I wasn't paying attention to.
>>>
>>>
>>> I've never heard of anyone attempting that.
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __

Re: [openstack-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

[Ihar Hrachyshka]

On Fri, Feb 10, 2017 at 2:48 PM, Clark Boylan  wrote:
> On Fri, Feb 10, 2017, at 10:54 AM, Ihar Hrachyshka wrote:
>> Oh nice, I haven't seen that. It does give (virtualized) CPU model
>> types. I don't see a clear correlation between models and
>> failures/test times though. We of course miss some more details, like
>> flags being emulated, but I doubt it will give us a clue.
>
> Yes, this will still be the virtualized CPU. Also the lack of cpu flag
> info is a regression compared to the old method of collecting this data.
> If we think that info could be useful somehow we should find a way to
> add it back in. (Maybe just add back the cat /proc/cpuinfo step in
> devstack-gate).

To update, I posted a patch that logs /proc/cpuinfo using new ansible
data gathering playbook: https://review.openstack.org/#/c/433949/

>
>> It would be interesting to know the overcommit/system load for each
>> hypervisor affected. But I assume we don't have access to that info,
>> right?
>
> Correct, with the exception of infracloud and OSIC (if we ask nicely) I
> don't expect it will be very easy to get this sort of information from
> our clouds.
>
> For infracloud a random sample of a hypervisor shows that it has 24 real
> cores. In the vanilla region we are limited to 126 VM  instances with
> 8vcpu each. We have ~41 hypervisors which is just over 3 VM instances
> per hypervisor. 24realcpus/8vcpu = 3 VM instances without
> oversubscribing. So we are just barely oversubscribing if at all.

Ack, thanks for checking, we will need to find some other hypothesis then.

For the record, we discussed with Clark an idea of adding a synthetic
benchmark at the start of every job (before our software is actually
installed on the node), to get some easily comparable performance
numbers between runs that are guaranteed to be unaffected by OpenStack
installation; but Clark had his reservation because the test would be
synthetic and hence not real life, and because we already have
./stack.sh run time that can be used as a silly benchmark. Of course,
./stack.sh depends on lots of externalities, so it's not as precise as
a targeted benchmark would be, but Clark feels the latter would be of
limited use.

Apart from that, it's not clear where to go next. I doubt cpuinfo dump
will reveal anything insane in failing jobs, so other ideas are
welcome.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] What's new in StoryBoard?

[Kendall Nelson]

Hello All!

In your continued education about our new task tracking tool, we have a
new blog post! It's focus is on the new functionalities that Storyboard
provides [1]. We hope that all of these posts are helping you get more
comfortable with the tool.

If you missed any of our previous posts:
- Why Storyboard?[2]
- Mapping Launchpad to Storyboard [3]

And if you want to play around in a StoryBoard sandbox [4], check out the
real thing [5], read the docs [6], or attend a meeting [7], please do!

We are looking at moving teams over as soon as possible (more stand alone
projects first before larger ones with multi project bugs and features) so
if you think your project is ready, please let us know!

-Kendall Nelson (diablo_rojo) and the StoryBoard team

[1] https://storyboard-blog.io/things-that-storyboard-does-differently.html
[2] https://storyboard-blog.io/why-storyboard-for-openstack.html
[3] https://storyboard-blog.io/mapping-launchpad-to-storyboard.html
[4] https://storyboard-dev.openstack.org/
[5] https://storyboard.openstack.org/
[6] http://docs.openstack.org/infra/storyboard/
[7] https://wiki.openstack.org/wiki/StoryBoard
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA][all] Pike PTG Tempest Plugin Cross Project Session

[Matthew Treinish]

Hi Everyone,

I just wanted to advertise that we will be hosting a 1 hr cross project session
at the PTG next week. We have the Macon discussion room at the PTG reserved [1]
on Tuesday between 9:30a to 10:30a.

The intent of this session is for anyone who is producing or consuming tempest
plugins to discuss best practices, where there are gaps currently, and anything
we need to improve in the future.

We'll also be discussing the merits of and how to move forward with the proposed
community goal to split tempest plugins into separate repos:

https://review.openstack.org/369749

There was some opposition to this during the review period and it wasn't
accepted as a pike goal. I think to move forward having a face to face
discussion to address the concerns around this (especially with everyone who
has expressed issues with this) will be useful and productive.

I'm looking forward to seeing everyone next week.

Thanks,

Matt Treinish


[1] https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Some findings while profiling instances boot

[Jay Pipes]

On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:

Hi there,

We're trying to figure out why, sometimes, rpc_loop takes over 10
seconds to process an iteration when booting instances. So we deployed
devstack on a 8GB, 4vCPU VM and did some profiling on the following command:

nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec --nic
net-name=private --min-count 8 instance


Hi Daniel, thanks for posting the information here. Quick request of 
you, though... can you try re-running the test but doing 8 separate 
calls to nova boot instead of using the --min-count 8 parameter? I'm 
curious to see if you notice any difference in contention/performance.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

Option #1 keep it.

Dan

On Mon, 2017-02-13 at 21:38 -0500, Emilien Macchi wrote:
> Team, I've got this email from Heidi.
> 
> I see 3 options :
> 
> 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .
> 
> 2. Re-design a new logo that "meets" OpenStack "requirements".
> 
> 3. Pick-up the one proposed (see below).
> 
> 
> Personally, I would vote for keeping our existing logo (1.) unless
> someone has time to create another one or if the team likes the
> proposed one.
> 
> The reason why I want to keep our logo is because our current logo
> was created by TripleO devs, we like it and we already have tee-
> shirts and other goodies with it. I don't see any good reason to
> change it.
> 
> Discussion is open and we'll vote as a team.
> 
> Thanks,
> 
> Emilien. 
> 
> -- Forwarded message --
> From: Heidi Joy Tretheway 
> Date: Mon, Feb 13, 2017 at 8:27 PM
> Subject: TripleO mascot - how can I help your team?
> To: Emilien Macchi 
> 
> 
> Hi Emilien, 
> 
> I’m following up on the much-debated TripleO logo. I’d like to help
> your team reach a solution that makes them happy but still fits
> within the family of logos we’re using at the PTG and going forward.
> Here’s what our illustrators came up with, which hides an “O” shape
> in the owl (face and wing arcs). 
> 
> https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLfHFa?
> dl=0
> 
> At this point, I don’t have quorum from your team (I got a lot of
> conflicting feedback, most of which was “don’t like” but not
> actionable for the illustrators to make a revision). At the PTG,
> we’ll have mascot stickers and signage for all teams except for
> Ironic and TripleO, since we’re still waiting on your teams to make a
> final decision. 
> 
> May I recommend that your team choose one person (or a small group of
> no more than three) to finalize this? I was able to work through all
> of Swift’s issues with just a quick 15-minute chat with John
> Dickinson and I’d like to believe we can solve this for TripleO as
> well. 
> 
> We know some of your team has expressed concern over retiring the
> existing mascot. It’s not our intention to make anyone “get rid of” a
> beloved icon. Your team can certainly print it on vintage items like
> shirts and stickers. But for official channels like the website, we
> need a logo to represent TripleO that’s cohesive with the rest of the
> set. 
> 
> Perhaps when you’re face to face with your team at the PTG, you can
> discuss and hopefully render a final decision to either accept this
> as a logo, or determine a few people willing to make any final
> changes with me? 
> 
> Thanks in advance for your help!
> 
> 
>   Heidi Joy Tretheway
> Senior Marketing Manager, OpenStack Foundation503 816
> 9769 | Skype: heidi.tretheway  
> 
> 
> 
> 
> 
> 
> -- 
> Emilien Macchi
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Project mascot available

[Erlon Cruz]

On Tue, Feb 14, 2017 at 2:24 PM, Walter Boring  wrote:

> How does Horse translate to Cinder block?
> I don't get it.  Our original Cinder block made a lot of sense,
> considering the name of the project.
>
>
>  Horses uses horseshoes, which were created due the needs of the ancient
Roman empire which was the first to have roads made of ... blocks. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hierarchical quotas at the PTG?

[Lance Bragstad]

On Wed, Feb 15, 2017 at 1:11 PM, Matt Riedemann  wrote:

> On 2/15/2017 12:07 PM, Sajeesh Cimson Sasi wrote:
>
>> Hi Matt, Andrey,
>> CERN-BARC team was working on nested quota
>> implementation in Nova some 3 years back.But at that time, it was decided
>> to fix bugs in the existing quota driver rather than  adding more features.
>> After that , the Cinder team implemented nested quota in Cinder and at the
>> same time, there was a plan to implement a quota library called  Delimiter.
>> https://launchpad.net/delimiter
>>  Unfortunately things have not progressed
>> much.Actually,the main hurdle is the delay in having a concrete decision in
>> the approach that needs to be adopted.While it is accepted that, there
>> should be a common entity for quota management of various services like
>> Nova, Cinder, Neutron, it has not been finalized whether that common entity
>> should be a library or  a separate service itself.Both approaches are
>> having its own pros and cons. But the main point is that we need to take a
>> concrete decision in the approach that needs to be adopted, to make the
>> things move forward.So IMHO it would be nice to have a discussion on
>> hierarchical quotas at the PTG.
>>
>>  best regards,
>>
>>   sajeesh
>>
>
> Thanks for the details.
>
> I've posted hierarchical quotas as a discussion item in the Arch WG
> session at the PTG:
>
> https://etherpad.openstack.org/p/ptg-architecture-workgroup
>
>
As a result, I've also removed this from our keystone schedule (Wednesday -
Friday). Anyone who was planning on attending this specific keystone
session should attended the Arch WG session instead.

Will there be a dedicated time finalized for this as we get closer to next
week?


> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][taas] IRC Meeting Canceled (week of 2/20/2017)

[reedip banerjee]

Adding to the earlier email, we would be having the next Tap-as-a-Service
meeting on the 1st of March, 2017.

:)

On Wed, Feb 15, 2017 at 12:20 PM, Soichi Shigeta <
shigeta.soi...@jp.fujitsu.com> wrote:

>
>  Hi,
>
> Next week's TaaS IRC meeting is being canceled because of
>   the week of OpenStack PTG.
>
>   Regards,
>   Soichi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hierarchical quotas at the PTG?

[Matt Riedemann]

On 2/15/2017 12:07 PM, Sajeesh Cimson Sasi wrote:

Hi Matt, Andrey,
CERN-BARC team was working on nested quota 
implementation in Nova some 3 years back.But at that time, it was decided to 
fix bugs in the existing quota driver rather than  adding more features. After 
that , the Cinder team implemented nested quota in Cinder and at the same time, 
there was a plan to implement a quota library called  Delimiter.
https://launchpad.net/delimiter
 Unfortunately things have not progressed much.Actually,the 
main hurdle is the delay in having a concrete decision in the approach that 
needs to be adopted.While it is accepted that, there should be a common entity 
for quota management of various services like Nova, Cinder, Neutron, it has not 
been finalized whether that common entity should be a library or  a separate 
service itself.Both approaches are having its own pros and cons. But the main 
point is that we need to take a concrete decision in the approach that needs to 
be adopted, to make the things move forward.So IMHO it would be nice to have a 
discussion on hierarchical quotas at the PTG.

   best regards,

sajeesh


Thanks for the details.

I've posted hierarchical quotas as a discussion item in the Arch WG 
session at the PTG:


https://etherpad.openstack.org/p/ptg-architecture-workgroup

--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ceilometer event-list empty

[gordon chung]

On 15/02/17 12:06 AM, Sam Huracan wrote:
> Hi,
>
> I'm unable to show event-list of ceilometer, meanwhile meter-list has
> data. Ceilometer log does not any "ERROR".
>
> My ceilometer.conf: http://paste.openstack.org/show/598925/
> My ceilometer version: http://prntscr.com/e8wob6
>
> I'm using OpenStack Mitaka.
> But, with another system installing Gnocchi dispatcher, I can show
> event-list.

just to clarify, ceilometer event-list works if you have gnocchi enabled 
but doesn't work if you have everything pushing to mongodb?

i would check mongodb and check your event collection to see if you have 
any data.

if you don't, i would check to see if you have any errors in collector 
or notification agent

if you do, it's probably something related to your policy. only events 
related to a user are returned or if the user is admin, it will return 
all events related to the project.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] python-tricircleclient repo officially created

[Das, Anindita]

Awesome Victor!! Congratulations. ☺

Anindita

From: "Morales, Victor" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, February 15, 2017 at 10:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tricircle] python-tricircleclient repo officially 
created

Howdy,

I’m happy to announce that after OpenStack Governance has approved[1] and infra 
them processed the request[2],  the python-tricircleclient repository  has been 
created[3].  This client pretends to make things simpler for users who require 
multi region solutions which can be addressed by Tricircle.  Hopefully this 
project helps for the adoption and visibility of this solution.  Lastly,  this 
client is still under developing and requires all your expertise to improve it 
so feel free to add new capabilities and features that you consider necessary.

Regards,
Victor Morales
irc: electrocucaracha

[1] https://review.openstack.org/#/c/426419/
[2] https://review.openstack.org/#/c/426859/
[3] http://git.openstack.org/cgit/openstack/python-tricircleclient/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable][heat] Heat stable-maint additions

[Zane Bitter]

Traditionally Heat has given current and former PTLs of the project +2 
rights on stable branches for as long as they remain core reviewers. 
Usually I've done that by adding them to the heat-release group.


At some point the system changed so that the review rights for these 
branches are no longer under the team's control (instead, the 
stable-maint core team is in charge), and as a result at least the 
current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly 
others (Thomas Herve, Sergey Kraynev), haven't been added to the group. 
That's slowing down getting backports merged, amongst other things.


I'd like to request that we update the membership to be the same as 
https://review.openstack.org/#/admin/groups/152,members


Rabi Mishra
Rico Lin
Sergey Kraynev
Steve Baker
Steven Hardy
Thomas Herve
Zane Bitter

I also wonder if the stable-maint team would consider allowing the Heat 
team to manage the group membership again if we commit to the criteria 
above (all current/former PTLs who are also core reviewers) by just 
adding that group as a member of heat-stable-maint?


thanks,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptls] PTG Team Photos!

[Kendall Nelson]

Hello All!

We are excited to see you next week at the PTG and wanted to share that
we will be taking team photos! Provided is a google sheet signup for the
available time slots [1]. We will be providing time on Tuesday Morning/
Afternoon and Thursday Morning/Afternoon to come as a team to get your
photo taken. Slots are only ten minutes so its *important that everyone be
on time*! If you are unable to view/edit the spreadsheet let me know and I
will try to get you access or can fill in a slot for you.

The location we are taking the photos on the 3rd floor in the prefunction
space in front of the Grand Ballroom (across the hall from Fandangles).

See you next week!

Thanks,

-Kendall Nelson (diablo_rojo)

[1]
https://docs.google.com/spreadsheets/d/1bgwMDsUm37JgpksUJszoDWcoBMHciufXcGV3OYe5A-4/edit?usp=sharing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Upstream Training Team meeting at PTG - Are you coming?

[Ildiko Vancsa]

Hi,

We are forming a virtual upstream collaboration training team including 
everyone who’s either helping us out with maintaining and improving the 
training material and/or who are attending the course as coaches or mentors.

We are planning to meet at the PTG in person next week on Wednesday at lunch 
time. We picked this slot as our first face to face gathering as all of us have 
project related assignments to drive and sessions to attend that makes 
scheduling a meeting even more challenging.

If you are interested in what we are doing and how we are trying to make the on 
boarding process for new contributors a pleasant experience and would like to 
join our activities meet us there!

The meeting time is __Wednesday (February 22) lunch time__. I will share the 
meeting point next week before the meeting.

If you would like to have a mail reminder prior to the meeting next week please 
reach out to me.

Thanks and Best Regards,
Ildikó
IRC: ildikov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hierarchical quotas at the PTG?

[Sajeesh Cimson Sasi]

Hi Matt, Andrey,
CERN-BARC team was working on nested quota 
implementation in Nova some 3 years back.But at that time, it was decided to 
fix bugs in the existing quota driver rather than  adding more features. After 
that , the Cinder team implemented nested quota in Cinder and at the same time, 
there was a plan to implement a quota library called  Delimiter.
https://launchpad.net/delimiter
 Unfortunately things have not progressed much.Actually,the 
main hurdle is the delay in having a concrete decision in the approach that 
needs to be adopted.While it is accepted that, there should be a common entity 
for quota management of various services like Nova, Cinder, Neutron, it has not 
been finalized whether that common entity should be a library or  a separate 
service itself.Both approaches are having its own pros and cons. But the main 
point is that we need to take a concrete decision in the approach that needs to 
be adopted, to make the things move forward.So IMHO it would be nice to have a 
discussion on hierarchical quotas at the PTG.

   best regards, 

sajeesh

   
From: Andrey Volkov [avol...@mirantis.com]
Sent: 13 February 2017 15:33:54
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Hierarchical quotas at the PTG?

Hi Matt,

> But it's unclear to some (at least me) what those
> issues are.


I believe issues were resolved. I made a retrospective by working with
bugs and repository history what problems cinder encountered with quotas.

- First, hierarchical quotas were implemented in DbQuotaDriver but
  after some time were moved to separated driver. It's definitely
  worth to left choice for an operator to determine what quotas driver is
  better for their case.

- Second, in nested quotas implementation sum of subproject usages was
  saved in a parent node. I mean there is the special column (allocated)
  in quotas limits table contains calculated value. I believe that was
  done for the sake of performance. In implementation was proposed to
  nova there is the different approach which doesn't cache usages in DB,
  and performance testing for such approach was done.

- Third, an issue with getting project from keystone due policy. To get
  projects from keystone service user was used because ordinary user's
  rights may be not enough. Additional complexity was due subtle
  conditions for quotas management. The proposed approach in nova also
  uses service user but doesn't touch anything related to quotas
  management.

> Has anyone already planned on talking about hierarchical quotas at the
> PTG, like the architecture work group?

I would like to discuss following topics on PTG:

- Hierarchical quotas approach in nova.

- Storing quotas in keystone service and limits migration from nova.

- ?Quotas on flavor level.

It's my first PTG so I don't sure how it can be done, anyway,
I'll prepare some information to share with the community.

> Is there still a group working on that and can provide some guidance
> here?

There are a couple of developers in Mirantis interested in this theme,
as Boris mentioned some work was done.

Matt Riedemann writes:

> Operators want hierarchical quotas [1]. Nova doesn't have them yet and
> we've been hesitant to invest scarce developer resources in them since
> we've heard that the implementation for hierarchical quotas in Cinder
> has some issues. But it's unclear to some (at least me) what those
> issues are.
>
> Has anyone already planned on talking about hierarchical quotas at the
> PTG, like the architecture work group?
>
> I know there was a bunch of razzle dazzle before the Austin summit about
> quotas, but I have no idea what any of that led to. Is there still a
> group working on that and can provide some guidance here?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-operators/2017-January/012450.html

--
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Corey Bryant]

On Wed, Feb 15, 2017 at 7:42 AM, Thomas Goirand  wrote:

> Hi there,
>
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
>
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
>
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
>
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
>
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
>
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
>
>
Thanks for all of your work, Thomas.  Wishing you the best.

For others following along, we do have up-to-date versions of these
packages in Ocata for Ubuntu.  For a full reports of packages please see:
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html


> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.


> Thanks for the fish,
>
> Thomas Goirand (zigo)
>
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia][sdk] service name for octavia

[Morgan Fainberg]

On Wed, Feb 15, 2017 at 7:25 AM, Monty Taylor  wrote:

> On 02/15/2017 09:12 AM, Hayes, Graham wrote:
> > On 15/02/2017 15:00, Monty Taylor wrote:
> >> On 02/14/2017 07:08 PM, Qiming Teng wrote:
> >>> When reviewing a recent patch that adds openstacksdk support to
> octavia,
> >>> I found that octavia is using 'octavia' as its service name instead of
> >>> 'loadbalancing' or 'loadbalancingv2' or something similar.
> >>
> >> Please not loadbalancingv2. As dean says in his email, we should be
> >> using service_type not service_name for this. And service type should
> >> not contain a version (please ignore what cinder did for v2 and v3
> >> entries in the service catalog, it is a pattern that should not happen)
> >
> > +1000
> >
> >> All the services should have a version discovery endpoint on their
> >> unversioned endpoint. If there is a v1 and a v2, then a user looking for
> >> the loadbalancing service, if they want v2, should be able to get there
> >> through version discovery.
> >>
> >> Also, if you haven't used loadbalancing anywhere yet, can I suggest
> >> load-balancing instead to match object-store and key-manager?
> >>
> >>> The overall suggestion is to use a word/phrase that indicates what a
> >>> service do instead of the name of the project providing that service.
> >>>
> >>> Below is the list of the service types currently supported by
> >>> openstacksdk:
> >>>
> >>> 'alarming',# aodh
> >>> 'baremetal',   # ironic
> >>> 'clustering',  # senlin
> >>> 'compute', # nova
> >>> 'database',# trove
> >>> 'identity',# keystone
> >>> 'image',   # glance
> >>> 'key-manager', # barbican
> >>> 'messaging',   # zaqar
> >>> 'metering',# ceilometer
> >>> 'network', # neutron
> >>> 'object-store',   # swift
> >>> 'octavia',# <--- this is an exception
> >>> 'orchestration',  # heat
> >>> 'volume', # cinder
> >>> 'workflowv2', # mistral
>
> Also - while we're on the topic - can we fix that to just be workflow ^^ ?
>
>
> ++
Please change that to workflow if possible.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Some findings while profiling instances boot

[Daniel Alvarez Sanchez]

Hi there,

We're trying to figure out why, sometimes, rpc_loop takes over 10 seconds
to process an iteration when booting instances. So we deployed devstack on
a 8GB, 4vCPU VM and did some profiling on the following command:

nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec --nic
net-name=private --min-count 8 instance

(network private has port_security_enabled set to False to avoid the
overhead of setting up sgs)

Logs showed that sometimes, the network-vif-plugged event was sent by the
server ~12 seconds after the vif was detected by ovsdb monitor. Usually,
first and second events come faster while the rest take longer. Further
analysis showed that rpc_loop iterations take several seconds to complete
so, if the vif is detected while iteration X is running, it won't be
processed until iteration X+1.

As an example, I've attached a simplified sequence diagram [0] to show what
happened in a particular iteration of my debug (I have full logs and pstat
files for this session for those interested). In this example, iteration 76
is going to process two ports while some of the previous spawned machines
are being managed by libvirt and so on... At the beginning of iteration 76,
a new vif is detected by ovsdb monitor but it won't be processed until 12
seconds later in iteration 77.

Profiling files show that aggregated CPU time for neutron workers is 97
seconds, while CPU time for ovs agent is 2.1 seconds. Most of its time is
spent waiting for RPC so it looks like there's apparently some room for
optimization and multiprocessing here.

According to dstat.log, CPU is at ~90% and there's ~1GB of free RAM. I
can't tell whether the hypervisor was swapping or not since I didn't have
access to it.

system total-cpu-usage --memory-usage- -net/total->
 time |usr sys idl wai hiq siq| used  buff  cach  free| recv  send>
05-02 14:22:50| 89  11   0   0   0   0|5553M0  1151M 1119M|1808B 1462B>
05-02 14:22:51| 90  10   0   0   0   0|5567M0  1151M 1106M|1588B  836B>
05-02 14:22:52| 89  11   1   0   0   0|5581M0  1151M 1092M|3233B 2346B>
05-02 14:22:53| 89  10   0   0   0   0|5598M0  1151M 1075M|2676B 2038B>
05-02 14:22:54| 90  10   0   0   0   0|5600M0  1151M 1073M|  20k   14k>
05-02 14:22:55| 90   9   0   0   0   0|5601M0  1151M 1072M|  22k   16k>

Also, while having a look at server profiling, around the 33% of the time
was spent building SQL queries [1]. Mike Bayer went through this and
suggested having a look at baked queries and also submitted a sketch of his
proposal [2].

I wanted to share these findings with you (probably most of you knew but
I'm quite new to OpenStack so It's been a really nice exercise for me to
better understand how things work) and gather your feedback about how
things can be improved. Also, I'll be happy to share the results and
discuss further if you think it's worth during the PTG next week.

Thanks a lot for reading and apologies for such a long email!

Cheers,
Daniel
IRC: dalvarez

[0] http://imgur.com/WQqaiYQ
[1] http://imgur.com/6KrfJUC
[2] https://review.openstack.org/430973
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] 2017-02-22 weekly policy meeting cancelled

[Lance Bragstad]

Since a bunch of us are going to be at the PTG next week, we can hold
policy discussions face-to-face.

Our next policy meeting will take place on March 1st.

Safe travels!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] kolla-ansible 4.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for kolla-ansible for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla-ansible/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/ocata

Release notes for kolla-ansible can be found at:

http://docs.openstack.org/releasenotes/kolla-ansible/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia][sdk] service name for octavia

[Michael Johnson]

Funny,  I had posted a patch to fix the devstack plugin earlier the same day
you sent this e-mail.

https://review.openstack.org/#/c/433817/

I also found that it was using "octavia" for the service type and wanted to
fix it.

I had picked "loadbalancing" but I am fine with "load-balancing" as well.  I
will update the patch.

Michael


-Original Message-
From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] 
Sent: Tuesday, February 14, 2017 5:09 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [octavia][sdk] service name for octavia

When reviewing a recent patch that adds openstacksdk support to octavia, I
found that octavia is using 'octavia' as its service name instead of
'loadbalancing' or 'loadbalancingv2' or something similar.

The overall suggestion is to use a word/phrase that indicates what a service
do instead of the name of the project providing that service.

Below is the list of the service types currently supported by
openstacksdk:

'alarming',# aodh
'baremetal',   # ironic
'clustering',  # senlin
'compute', # nova
'database',# trove
'identity',# keystone
'image',   # glance
'key-manager', # barbican
'messaging',   # zaqar
'metering',# ceilometer
'network', # neutron
'object-store',   # swift
'octavia',# <--- this is an exception
'orchestration',  # heat
'volume', # cinder
'workflowv2', # mistral

While I believe this has been discussed about a year ago, I'm not sure if
there are things we missed so I'm brining this issue to a broader audience
for discussion.

Reference:

[1] Patch to python-openstacksdk:
https://review.openstack.org/#/c/428414
[2] Octavia service naming:
http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh#n52

Regards,
 Qiming


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PKG-Openstack-devel] The end of OpenStack packages in Debian?

[Silence Dogood]

I'd like to add that Thomas makes the best openstack packages by far.  He's
been a force of nature in packaging and his attention to detail is second
to none.

On Wed, Feb 15, 2017 at 11:28 AM, Haïkel  wrote:

> 2017-02-15 13:42 GMT+01:00 Thomas Goirand :
> > Hi there,
> >
> > It's been a while since I planed on writing this message. I couldn't
> > write it because the situation makes me really sad. At this point, it
> > starts to be urgent to post it.
> >
> > As for many other folks, Mirantis decided to end its contract with me.
> > This happened when I was the most successful doing the job, with all of
> > the packaging CI moved to OpenStack infra at the end of the OpenStack
> > Newton cycle, after we were able to release Newton this way. I was
> > hoping to start packaging on every commit for Ocata. That's yet another
> > reason for me to be very frustrated about all of this. Such is life...
> >
> > Over the last few months, I hoped for having enough strengths to
> > continue my packaging work anyway, and get Ocata packages done. But
> > that's not what happened. The biggest reason for this is that I know
> > that this needs to be a full time job. And at this point, I still don't
> > know what my professional future will be. A company, in Barcelona, told
> > me I'd get hired to continue my past work of packaging OpenStack in
> > Debian, but so far, I'm still waiting for a definitive answer, so I'm
> > looking into some other opportunities.
> >
> > All this to say that, unless someone wants to hire me for it (which
> > would be the best outcome, but I fear this wont happen), or if someone
> > steps in (this seems unlikely at this point), both the packaging-deb and
> > the faith of OpenStack packages in Debian are currently compromised.
> >
> > I will continue to maintain OpenStack Newton during the lifetime of
> > Debian Stretch though, but I don't plan on doing anything more. This
> > means that maybe, Newton will be the last release of OpenStack in
> > Debian. If things continue this way, I probably will ask for the removal
> > of all OpenStack packages from Debian Sid after Stretch gets released
> > (unless I know that someone will do the work).
> >
> > As a consequence, the following projects wont get packages even in
> > Ubuntu (as they were "community maintained", which means done by me and
> > later sync into Ubuntu...):
> >
> > - congress
> > - gnocchi
> > - magnum
> > - mistral
> > - murano
> > - sahara
> > - senlin
> > - watcher
> > - zaqar
> >
> > Hopefully, Canonical will continue to maintain the other 15 (more
> > core...) projects in UCA.
> >
> > Thanks for the fish,
> >
> > Thomas Goirand (zigo)
> >
> > P,S: To the infra folks: please keep the packaging CI as it is, as it
> > will be useful for the lifetime of Stretch.
> >
>
> I'm sad to hear that as a fellow packager.
> You've been a driving force for Debian packaging and improving
> OpenStack since its early days.
> Your work has helped many people to use OpenStack on Debian and
> derived effectively. I hope
> that you'll find asap a sponsorship or a dayjob to keep going.
>
> Regards,
> H.
>
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> Openstack-devel mailing list
> openstack-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][logos] License for new project mascots

[Jeremy Stanley]

On 2017-02-15 09:48:28 +0800 (+0800), Qiming Teng wrote:
> A related question: uploading file to wiki.openstack.org has been
> blocked? I'm getting the following error when trying to do so.
> 
> Action failed
> 
> Could not open lock file for
> "mwstore://local-backend/local-public/2/22/OpenStack_Project_Senlin_horizontal.jpg".

It seems that in a recent upgrade we ended up with the images file
tree on the server only readable by the user the Web server runs as
rather than writeable. I was able to reproduce the same error
myself, but after adjusting the filesystem permissions it seems to
be working now. Sorry about that... Can you try again and let us
know how you get on?

As an aside, the JPEG versions of those logos suffer from some
pretty severe compression artifacting, so using the PNG versions (or
better still converting the EPS versions to SVG) will probably look
a lot better in the end.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Women-of-openstack] [OpenStack Marketing] Community Voting for the OpenStack Summit Boston Now Open!

[Anne Gentle]

I'm seeing the same, and logging a bug here:

https://bugs.launchpad.net/openstack-org/+bug/1665041

Anne

On Wed, Feb 15, 2017 at 10:28 AM, Swarna Podila (Avi Networks) <
swa...@avinetworks.com> wrote:

> Sorry for the mass reply, but I am not able to access the Vote For
> Speakers link.  Attached is the screenshot of what I see; the text box
> there is not editable (as in, I cannot enter anything into it).  I click on
> "Log in as someone else”, it logs me out, but brings me back to this same
> page when I try to log back in.
>
>
> Best,
> Swarna.
>
> On Feb 15, 2017, 8:23 AM -0800, Erin Disney , wrote:
>
> Hi everyone,
>
> Session voting is now open for the May 2017 OpenStack Summit in Boston!
>
> VOTE HERE 
>
> Hurry, voting closes Tuesday, February 21st 11:59pm PST (Wednesday,
> February 22 at 7:59am UTC).
>
> Please Note: Based on community feedback, unique URLs to submissions have
> been added back for this Summit.
>
> Track Chairs will ultimately determine the final schedule. Community votes
> are meant to help inform the decision, but are not considered to be the
> deciding factor. Track chairs exercise judgment in their area of expertise
> and help ensure diversity. View full details of the session selection
> process here
> 
> .
>
> Continue to visit https://www.openstack.org/summit/boston-2017/ for all
> Summit-related information.
>
> REGISTER
> Register HERE
> 
>  before
> prices increase in early March.
>
> TRAVEL SUPPORT PROGRAM
> March 6 is the last day to submit applications. Please submit your
> applications HERE
>  by
> 11:59pm PST (March 7 at 7:59am UTC).
>
> VISA APPLICATION PROCESS
> If you require a visa to travel to the United States, please carefully
> read the instructions HERE
> . All visa
> invitation letter requests must be received by April 17.
>
> BECOME A SPONSOR
> If you are interested in sponsoring the Summit as well, it's not too late.
> Please email sum...@openstack.org no later than March 13th.
>
>
> Erin Disney
> OpenStack Marketing
> e...@openstack.org
>
> ___
> Marketing mailing list
> market...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing
>
>
> ___
> Women-of-openstack mailing list
> women-of-openst...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/women-of-openstack
>
>


-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] notification impact of moving the instance create to the conductor

[Balazs Gibizer]

Hi,

It seems that the Move instance creation to conductor commit [1] 
changed when and how the instance.delete notification is emitted for an 
unscheduled instance. Unfortunately the legacy notification doesn't 
have test coverage and the versioned notification coverage are still on 
review [2] for this case.


Before [1] the instance.delete for an unscheduled instance is emitted 
from here [3]. But after [1] the execution of the same delete operation 
goes to a new direction [4] and never reaches [3].
Before [1] the new test coverage in [2] was passing but now after [1] 
is merged the test_create_server_error fails as the instance.delete 
notification is not emitted.


Is it an intentional change or a bug? If it is a bug could you give me 
some pointers how to restore the original notification behavior?


Cheers,
gibi

[1] https://review.openstack.org/#/c/319379
[2] https://review.openstack.org/#/c/410297
[3] https://review.openstack.org/#/c/410297/9/nova/compute/api.py@1860
[4] https://review.openstack.org/#/c/319379/84/nova/compute/api.py@1790


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PKG-Openstack-devel] The end of OpenStack packages in Debian?

[Silence Dogood]

I hope they have gotten better.  Last time I tried to contribute to
Ubuntu's packaging effort they took over a ear to respond.

On Feb 15, 2017 11:56 AM, "Allison Randal"  wrote:

> On 02/15/2017 07:42 AM, Thomas Goirand wrote:
> > I will continue to maintain OpenStack Newton during the lifetime of
> > Debian Stretch though, but I don't plan on doing anything more. This
> > means that maybe, Newton will be the last release of OpenStack in
> > Debian. If things continue this way, I probably will ask for the removal
> > of all OpenStack packages from Debian Sid after Stretch gets released
> > (unless I know that someone will do the work).
>
> I'm happy to volunteer for this. TBH, my goal would be to minimize the
> delta on these packages to Ubuntu's versions of the packages, so we can
> maintain them collaboratively. But, there's certainly no need to drop
> the packages from Debian.
>
> > As a consequence, the following projects wont get packages even in
> > Ubuntu (as they were "community maintained", which means done by me and
> > later sync into Ubuntu...):
> >
> > - congress
> > - gnocchi
> > - magnum
> > - mistral
> > - murano
> > - sahara
> > - senlin
> > - watcher
> > - zaqar
>
> These are more "nice to have" packages, not really critical. We can ask
> around to see if anyone is using the packaged versions, but if not we
> should just drop them from Debian.
>
> > Hopefully, Canonical will continue to maintain the other 15 (more
> > core...) projects in UCA.
>
> Canonical doesn't have a large team for this work, but I imagine we can
> handle it just fine between their team and a few volunteers.
>
> Allison
>
> ___
> Openstack-devel mailing list
> openstack-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Alex Schultz]

On Wed, Feb 15, 2017 at 9:02 AM, Samuel Cassiba  wrote:
>
>> On Feb 15, 2017, at 02:07, Thierry Carrez  wrote:
>>
>> Samuel Cassiba wrote:
>>> [...]
>>> *TL;DR* if you don't want to keep going -
>>> OpenStack-Chef is not in a good place and is not sustainable.
>>> [...]
>>
>> Thanks for sharing, Sam.
>>
>
> Thanks for taking the time to read and respond. This was as hard to write as 
> it was to read. As time went on, it became apparent that this retrospective 
> needed to exist. It was not written lightly, and does not aim to point 
> fingers.
>
>> I think that part of the reasons for the situation is that we grew the
>> number of options for deploying OpenStack. We originally only had Puppet
>> and Chef, but now there is Ansible, Juju, and the various
>> Kolla-consuming container-oriented approaches. There is a gravitational
>> attraction effect at play (more users -> more contributors) which
>> currently benefits Puppet, Ansible and Kolla, to the expense of
>> less-popular community-driven efforts like OpenStackChef and
>> OpenStackSalt. I expect this effect to continue. I have mixed feelings
>> about it: on one hand it reduces available technical options, but on the
>> other it allows to focus and raise quality…
>
> You have a very valid point. One need only look at the trends over the cycles 
> in the User Survey to see this shift in most places. Ansible wins due to 
> sheer simplicity for new deployments, but there are also real business 
> decisions that go behind automation flavors at certain business sizes. This 
> leaves them effectively married to whichever flavor chosen. That shift 
> impacts Puppet’s overall user base, as well, though they had and still have 
> the luxury of maintaining sponsored support at higher numbers.
>

To chime in on the Puppet side, we've seen a decrease in contributors
over the last several cycles and I have a feeling we'll be in the same
boat in the near future.  The amount of modules that we have to try
and manage versus the amount of folks that we have contributing is
getting to an unmanageable state.  I believe the only way we've gotten
to where we have been is due to the use within Fuel and TripleO.  As
those projects evolve, it directly impacts the ability for the Puppet
modules to remain relevant.  Some could argue that's just the way it
goes and technologies evolve which is true.  But it's also a loss for
many of the newer methods as they are losing all of the historical
knowledge and understanding that went with it and why some patterns
work better than others.  The software wheel, it's getting reinvented
every day.

> Chef’s sponsored support has numbered far fewer. It casts an extremely 
> negative image on OpenStack when someone looks for help at odd hours, or asks 
> something somewhere that none of us have time to track. The answer to that is 
> the point of making noise, to generate conversation about avenues and 
> solutions. I could have kept my fingers aiming at LP, Gerrit and IRC in an 
> attempt to bury my head in the sand. We’re way past the point of denial, 
> perhaps too far, but as long as the results of the User Survey shows Chef, 
> there are still users to support, for now. Operators and deployers will be 
> looking to the source of truth, wherever that is, and right now that source 
> of truth is OpenStack.
>
>>
>> There is one question I wanted to ask you in terms of community. We
>> maintain in OpenStack a number of efforts that bridge two communities,
>> and where the project could set up its infrastructure / governance in
>> one or the other. In the case of OpenStackChef, you could have set up
>> shop on the Chef community side, rather than on the OpenStack community
>> side. Would you say that living on the OpenStack community side helped
>> you or hurt you ? Did you get enough help / visibility to balance the
>> constraints ? Do you think you would have been more, less or equally
>> successful if you had set up shop more on the Chef community side ?
>>
>
> We set up under Stackforge, later OpenStack, because the cookbooks evolved 
> alongside OpenStack, as far back as 2011, before my time in the cookbooks. 
> The earliest commits on the now EOL Grizzly branch were quite enlightening, 
> if only Stackalytics had the visuals. Maybe I’m biased, but that’s worth 
> something.
>
> You’re absolutely correct that we could have pushed more to set up the Chef 
> side of things, and in fact we made several concerted efforts to integrate 
> into the Chef community, up to and including having sponsored contributors, 
> even a PTL. When exploring the Chef side, we found that we faced as much or 
> more friction with the ecosystem, requiring more fundamental changes than we 
> could influence. Chef (the ecosystem) has many great things, but Chef doesn’t 
> OpenStack. Maybe that was the writing on the wall.
>
> I keep one foot in both Chef and OpenStack, to keep myself as informed as 
> time allows me. It’s clear that even Chef’s long-term cookbook 

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Allison Randal]

On 02/15/2017 07:42 AM, Thomas Goirand wrote:
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).

I'm happy to volunteer for this. TBH, my goal would be to minimize the
delta on these packages to Ubuntu's versions of the packages, so we can
maintain them collaboratively. But, there's certainly no need to drop
the packages from Debian.

> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
> 
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar

These are more "nice to have" packages, not really critical. We can ask
around to see if anyone is using the packaged versions, but if not we
should just drop them from Debian.

> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.

Canonical doesn't have a large team for this work, but I imagine we can
handle it just fine between their team and a few volunteers.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Doug Hellmann]

Excerpts from Paul Belanger's message of 2017-02-15 09:51:22 -0500:
> On Wed, Feb 15, 2017 at 01:43:46PM +0100, Thomas Goirand wrote:
> > Hi there,
> > 
> > It's been a while since I planed on writing this message. I couldn't
> > write it because the situation makes me really sad. At this point, it
> > starts to be urgent to post it.
> > 
> > As for many other folks, Mirantis decided to end its contract with me.
> > This happened when I was the most successful doing the job, with all of
> > the packaging CI moved to OpenStack infra at the end of the OpenStack
> > Newton cycle, after we were able to release Newton this way. I was
> > hoping to start packaging on every commit for Ocata. That's yet another
> > reason for me to be very frustrated about all of this. Such is life...
> > 
> > Over the last few months, I hoped for having enough strengths to
> > continue my packaging work anyway, and get Ocata packages done. But
> > that's not what happened. The biggest reason for this is that I know
> > that this needs to be a full time job. And at this point, I still don't
> > know what my professional future will be. A company, in Barcelona, told
> > me I'd get hired to continue my past work of packaging OpenStack in
> > Debian, but so far, I'm still waiting for a definitive answer, so I'm
> > looking into some other opportunities.
> > 
> > All this to say that, unless someone wants to hire me for it (which
> > would be the best outcome, but I fear this wont happen), or if someone
> > steps in (this seems unlikely at this point), both the packaging-deb and
> > the faith of OpenStack packages in Debian are currently compromised.
> > 
> > I will continue to maintain OpenStack Newton during the lifetime of
> > Debian Stretch though, but I don't plan on doing anything more. This
> > means that maybe, Newton will be the last release of OpenStack in
> > Debian. If things continue this way, I probably will ask for the removal
> > of all OpenStack packages from Debian Sid after Stretch gets released
> > (unless I know that someone will do the work).
> > 
> > As a consequence, the following projects wont get packages even in
> > Ubuntu (as they were "community maintained", which means done by me and
> > later sync into Ubuntu...):
> > 
> > - congress
> > - gnocchi
> > - magnum
> > - mistral
> > - murano
> > - sahara
> > - senlin
> > - watcher
> > - zaqar
> > 
> > Hopefully, Canonical will continue to maintain the other 15 (more
> > core...) projects in UCA.
> > 
> > Thanks for the fish,
> > 
> > Thomas Goirand (zigo)
> > 
> > P,S: To the infra folks: please keep the packaging CI as it is, as it
> > will be useful for the lifetime of Stretch.
> > 
> Thanks for all your work. I'm glad we eventually stood up all the packaging
> infrastructure.
> 
> Good luck on your future endeavors.
> 

Yes, thank you for everything you've done, Thomas. You have done
an immense amount of work to ensure that good quality OpenStack
packages are available to a wide user base.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 10:20 AM, Dan Smith  wrote:

> > The problem is there's no way to update an existing cell's transport_url
> > via nova-manage.
>
> There is:
>
> https://review.openstack.org/#/c/431582/
>
> > It appears the only way to get around this is manually deleting the old
> > cell1 record from the db.
>
> No, don't do that :)
>
> > I'd like to hear more opinions on this but it really seems like this
> > should be a priority to fix prior to the Ocata final release.
>
> Already done!
>
>
Awesome thanks!

-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Davanum Srinivas]

On Wed, Feb 15, 2017 at 10:41 AM, Tobias Urdin
 wrote:
> On 02/15/2017 01:46 PM, Thomas Goirand wrote:
>> Hi there,
>>
>> It's been a while since I planed on writing this message. I couldn't
>> write it because the situation makes me really sad. At this point, it
>> starts to be urgent to post it.
>>
>> As for many other folks, Mirantis decided to end its contract with me.
>> This happened when I was the most successful doing the job, with all of
>> the packaging CI moved to OpenStack infra at the end of the OpenStack
>> Newton cycle, after we were able to release Newton this way. I was
>> hoping to start packaging on every commit for Ocata. That's yet another
>> reason for me to be very frustrated about all of this. Such is life...
>>
>> Over the last few months, I hoped for having enough strengths to
>> continue my packaging work anyway, and get Ocata packages done. But
>> that's not what happened. The biggest reason for this is that I know
>> that this needs to be a full time job. And at this point, I still don't
>> know what my professional future will be. A company, in Barcelona, told
>> me I'd get hired to continue my past work of packaging OpenStack in
>> Debian, but so far, I'm still waiting for a definitive answer, so I'm
>> looking into some other opportunities.
>>
>> All this to say that, unless someone wants to hire me for it (which
>> would be the best outcome, but I fear this wont happen), or if someone
>> steps in (this seems unlikely at this point), both the packaging-deb and
>> the faith of OpenStack packages in Debian are currently compromised.
>>
>> I will continue to maintain OpenStack Newton during the lifetime of
>> Debian Stretch though, but I don't plan on doing anything more. This
>> means that maybe, Newton will be the last release of OpenStack in
>> Debian. If things continue this way, I probably will ask for the removal
>> of all OpenStack packages from Debian Sid after Stretch gets released
>> (unless I know that someone will do the work).
>>
>> As a consequence, the following projects wont get packages even in
>> Ubuntu (as they were "community maintained", which means done by me and
>> later sync into Ubuntu...):
>>
>> - congress
>> - gnocchi
>> - magnum
>> - mistral
>> - murano
>> - sahara
>> - senlin
>> - watcher
>> - zaqar
>>
>> Hopefully, Canonical will continue to maintain the other 15 (more
>> core...) projects in UCA.
>>
>> Thanks for the fish,
>>
>> Thomas Goirand (zigo)
>>
>> P,S: To the infra folks: please keep the packaging CI as it is, as it
>> will be useful for the lifetime of Stretch.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> Somebody please hire Thomas, he's amazing!

Heartily seconded!!

Thanks,
Dims

> Thank you for everything!
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Marketing] Community Voting for the OpenStack Summit Boston Now Open!

[Swarna Podila (Avi Networks)]

Sorry for the mass reply, but I am not able to access the Vote For Speakers 
link.  Attached is the screenshot of what I see; the text box there is not 
editable (as in, I cannot enter anything into it).  I click on "Log in as 
someone else”, it logs me out, but brings me back to this same page when I try 
to log back in.


Best,
Swarna.

On Feb 15, 2017, 8:23 AM -0800, Erin Disney , wrote:
> Hi everyone,
>
> Session voting is now open for the May 2017 OpenStack Summit in Boston!
>
> VOTE HERE
>
> Hurry, voting closes Tuesday, February 21st 11:59pm PST (Wednesday, February 
> 22 at 7:59am UTC).
>
> Please Note: Based on community feedback, unique URLs to submissions have 
> been added back for this Summit.
>
> Track Chairs will ultimately determine the final schedule. Community votes 
> are meant to help inform the decision, but are not considered to be the 
> deciding factor. Track chairs exercise judgment in their area of expertise 
> and help ensure diversity. View full details of the session selection process 
> here.
>
> Continue to visit https://www.openstack.org/summit/boston-2017/ for all 
> Summit-related information.
>
> REGISTER
> Register HERE before prices increase in early March.
>
> TRAVEL SUPPORT PROGRAM
> March 6 is the last day to submit applications. Please submit your 
> applications HERE by 11:59pm PST (March 7 at 7:59am UTC).
>
> VISA APPLICATION PROCESS
> If you require a visa to travel to the United States, please carefully read 
> the instructions HERE. All visa invitation letter requests must be received 
> by April 17.
>
> BECOME A SPONSOR
> If you are interested in sponsoring the Summit as well, it's not too late. 
> Please email sum...@openstack.org no later than March 13th.
>
>
> Erin Disney
> OpenStack Marketing
> e...@openstack.org
>
> ___
> Marketing mailing list
> market...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Amy Marrich]

+2

On Wed, Feb 15, 2017 at 9:41 AM, Tobias Urdin 
wrote:

> On 02/15/2017 01:46 PM, Thomas Goirand wrote:
> > Hi there,
> >
> > It's been a while since I planed on writing this message. I couldn't
> > write it because the situation makes me really sad. At this point, it
> > starts to be urgent to post it.
> >
> > As for many other folks, Mirantis decided to end its contract with me.
> > This happened when I was the most successful doing the job, with all of
> > the packaging CI moved to OpenStack infra at the end of the OpenStack
> > Newton cycle, after we were able to release Newton this way. I was
> > hoping to start packaging on every commit for Ocata. That's yet another
> > reason for me to be very frustrated about all of this. Such is life...
> >
> > Over the last few months, I hoped for having enough strengths to
> > continue my packaging work anyway, and get Ocata packages done. But
> > that's not what happened. The biggest reason for this is that I know
> > that this needs to be a full time job. And at this point, I still don't
> > know what my professional future will be. A company, in Barcelona, told
> > me I'd get hired to continue my past work of packaging OpenStack in
> > Debian, but so far, I'm still waiting for a definitive answer, so I'm
> > looking into some other opportunities.
> >
> > All this to say that, unless someone wants to hire me for it (which
> > would be the best outcome, but I fear this wont happen), or if someone
> > steps in (this seems unlikely at this point), both the packaging-deb and
> > the faith of OpenStack packages in Debian are currently compromised.
> >
> > I will continue to maintain OpenStack Newton during the lifetime of
> > Debian Stretch though, but I don't plan on doing anything more. This
> > means that maybe, Newton will be the last release of OpenStack in
> > Debian. If things continue this way, I probably will ask for the removal
> > of all OpenStack packages from Debian Sid after Stretch gets released
> > (unless I know that someone will do the work).
> >
> > As a consequence, the following projects wont get packages even in
> > Ubuntu (as they were "community maintained", which means done by me and
> > later sync into Ubuntu...):
> >
> > - congress
> > - gnocchi
> > - magnum
> > - mistral
> > - murano
> > - sahara
> > - senlin
> > - watcher
> > - zaqar
> >
> > Hopefully, Canonical will continue to maintain the other 15 (more
> > core...) projects in UCA.
> >
> > Thanks for the fish,
> >
> > Thomas Goirand (zigo)
> >
> > P,S: To the infra folks: please keep the packaging CI as it is, as it
> > will be useful for the lifetime of Stretch.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> Somebody please hire Thomas, he's amazing!
>
> Thank you for everything!
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Haïkel]

2017-02-15 13:42 GMT+01:00 Thomas Goirand :
> Hi there,
>
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
>
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
>
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
>
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
>
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
>
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
>
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
>
> Thanks for the fish,
>
> Thomas Goirand (zigo)
>
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
>

I'm sad to hear that as a fellow packager.
You've been a driving force for Debian packaging and improving
OpenStack since its early days.
Your work has helped many people to use OpenStack on Debian and
derived effectively. I hope
that you'll find asap a sponsorship or a dayjob to keep going.

Regards,
H.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] python-tricircleclient repo officially created

[Zhipeng Huang]

Thanks Victor ! : )

On Thu, Feb 16, 2017 at 12:19 AM, Morales, Victor 
wrote:

> Howdy,
>
> I’m happy to announce that after OpenStack Governance has approved[1] and
> infra them processed the request[2],  the python-tricircleclient repository
>  has been created[3].  This client pretends to make things simpler for
> users who require multi region solutions which can be addressed by
> Tricircle.  Hopefully this project helps for the adoption and visibility of
> this solution.  Lastly,  this client is still under developing and requires
> all your expertise to improve it so feel free to add new capabilities and
> features that you consider necessary.
>
> Regards,
> Victor Morales
> irc: electrocucaracha
>
> [1] https://review.openstack.org/#/c/426419/
> [2] https://review.openstack.org/#/c/426859/
> [3] http://git.openstack.org/cgit/openstack/python-tricircleclient/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Community Voting for the OpenStack Summit Boston Now Open!

[Erin Disney]

Hi everyone, 

Session voting is now open for the May 2017 OpenStack Summit in Boston!

VOTE HERE  

Hurry, voting closes Tuesday, February 21st 11:59pm PST (Wednesday, February 22 
at 7:59am UTC). 

Please Note: Based on community feedback, unique URLs to submissions have been 
added back for this Summit. 

Track Chairs will ultimately determine the final schedule. Community votes are 
meant to help inform the decision, but are not considered to be the deciding 
factor. Track chairs exercise judgment in their area of expertise and help 
ensure diversity. View full details of the session selection process here 
.
 

Continue to visit https://www.openstack.org/summit/boston-2017/ 
 for all Summit-related 
information.

REGISTER
Register HERE 

 before prices increase in early March.

TRAVEL SUPPORT PROGRAM
March 6 is the last day to submit applications. Please submit your applications 
HERE  by 
11:59pm PST (March 7 at 7:59am UTC). 

VISA APPLICATION PROCESS
If you require a visa to travel to the United States, please carefully read the 
instructions HERE . 
All visa invitation letter requests must be received by April 17.

BECOME A SPONSOR
If you are interested in sponsoring the Summit as well, it's not too late. 
Please email sum...@openstack.org no later than March 13th. 


Erin Disney
OpenStack Marketing
e...@openstack.org 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] python-tricircleclient repo officially created

[Morales, Victor]

Howdy,

I’m happy to announce that after OpenStack Governance has approved[1] and infra 
them processed the request[2],  the python-tricircleclient repository  has been 
created[3].  This client pretends to make things simpler for users who require 
multi region solutions which can be addressed by Tricircle.  Hopefully this 
project helps for the adoption and visibility of this solution.  Lastly,  this 
client is still under developing and requires all your expertise to improve it 
so feel free to add new capabilities and features that you consider necessary.

Regards,
Victor Morales
irc: electrocucaracha

[1] https://review.openstack.org/#/c/426419/
[2] https://review.openstack.org/#/c/426859/
[3] http://git.openstack.org/cgit/openstack/python-tricircleclient/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Ocata retrospective

[Matt Riedemann]

Like we did in Newton [1] I've started an etherpad for doing an Ocata 
retrospective [2].


I expect we'll go over some of this at the PTG next week so please leave 
some thoughts. I've started a few items but I'm sure more will roll in 
over time as I think about this and as others comment.


[1] https://etherpad.openstack.org/p/nova-newton-retrospective
[2] https://etherpad.openstack.org/p/nova-ocata-retrospective

--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Samuel Cassiba]

> On Feb 15, 2017, at 02:07, Thierry Carrez  wrote:
> 
> Samuel Cassiba wrote:
>> [...]
>> *TL;DR* if you don't want to keep going -
>> OpenStack-Chef is not in a good place and is not sustainable.
>> [...]
> 
> Thanks for sharing, Sam.
> 

Thanks for taking the time to read and respond. This was as hard to write as it 
was to read. As time went on, it became apparent that this retrospective needed 
to exist. It was not written lightly, and does not aim to point fingers.

> I think that part of the reasons for the situation is that we grew the
> number of options for deploying OpenStack. We originally only had Puppet
> and Chef, but now there is Ansible, Juju, and the various
> Kolla-consuming container-oriented approaches. There is a gravitational
> attraction effect at play (more users -> more contributors) which
> currently benefits Puppet, Ansible and Kolla, to the expense of
> less-popular community-driven efforts like OpenStackChef and
> OpenStackSalt. I expect this effect to continue. I have mixed feelings
> about it: on one hand it reduces available technical options, but on the
> other it allows to focus and raise quality…

You have a very valid point. One need only look at the trends over the cycles 
in the User Survey to see this shift in most places. Ansible wins due to sheer 
simplicity for new deployments, but there are also real business decisions that 
go behind automation flavors at certain business sizes. This leaves them 
effectively married to whichever flavor chosen. That shift impacts Puppet’s 
overall user base, as well, though they had and still have the luxury of 
maintaining sponsored support at higher numbers.

Chef’s sponsored support has numbered far fewer. It casts an extremely negative 
image on OpenStack when someone looks for help at odd hours, or asks something 
somewhere that none of us have time to track. The answer to that is the point 
of making noise, to generate conversation about avenues and solutions. I could 
have kept my fingers aiming at LP, Gerrit and IRC in an attempt to bury my head 
in the sand. We’re way past the point of denial, perhaps too far, but as long 
as the results of the User Survey shows Chef, there are still users to support, 
for now. Operators and deployers will be looking to the source of truth, 
wherever that is, and right now that source of truth is OpenStack.

> 
> There is one question I wanted to ask you in terms of community. We
> maintain in OpenStack a number of efforts that bridge two communities,
> and where the project could set up its infrastructure / governance in
> one or the other. In the case of OpenStackChef, you could have set up
> shop on the Chef community side, rather than on the OpenStack community
> side. Would you say that living on the OpenStack community side helped
> you or hurt you ? Did you get enough help / visibility to balance the
> constraints ? Do you think you would have been more, less or equally
> successful if you had set up shop more on the Chef community side ?
> 

We set up under Stackforge, later OpenStack, because the cookbooks evolved 
alongside OpenStack, as far back as 2011, before my time in the cookbooks. The 
earliest commits on the now EOL Grizzly branch were quite enlightening, if only 
Stackalytics had the visuals. Maybe I’m biased, but that’s worth something.

You’re absolutely correct that we could have pushed more to set up the Chef 
side of things, and in fact we made several concerted efforts to integrate into 
the Chef community, up to and including having sponsored contributors, even a 
PTL. When exploring the Chef side, we found that we faced as much or more 
friction with the ecosystem, requiring more fundamental changes than we could 
influence. Chef (the ecosystem) has many great things, but Chef doesn’t 
OpenStack. Maybe that was the writing on the wall.

I keep one foot in both Chef and OpenStack, to keep myself as informed as time 
allows me. It’s clear that even Chef’s long-term cookbook support community is 
ill equipped to handle OpenStack. The problem? We’re too complex and too far 
integrated, and none of them know OpenStack. Where does that leave us?

--
Best,

Samuel Cassiba

> --
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Tobias Urdin]

On 02/15/2017 01:46 PM, Thomas Goirand wrote:
> Hi there,
>
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
>
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
>
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
>
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
>
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
>
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
>
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
>
> Thanks for the fish,
>
> Thomas Goirand (zigo)
>
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Somebody please hire Thomas, he's amazing!

Thank you for everything!


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

[Kosnik, Lubosz]

About success of RDO we need to remember that this deployment utilizes 
Peacemaker and when I was working on this feature and even I spoke with Assaf 
this external application was doing everything to make this solution working.
Peacemaker was responsible for checking external and internal connectivity. To 
detect split brain. Elect master, even keepalived was running but Peacemaker 
was automatically killing all services and moving FIP.
Assaf - is there any change in this implementation in RDO? Or you’re still 
doing everything outside of Neutron?

Because if RDO success is build on Peacemaker it means that yes, Neutron needs 
some solution which will be available for more than RH deployments.

Lubosz

On Feb 15, 2017, at 3:22 AM, Anna Taraday 
mailto:akamyshnik...@mirantis.com>> wrote:

If I propose some concrete solution that will be discussion about one solution 
not about making things flexible.
At first I wanted to propose some PoC for other approach, but during my 
experiments I understood that we may have different approaches, but for all of 
them we need pluggable HA router in Neutron.

The thing that bothers me about L3 HA - it is complex. Yes, we fixed bunch of 
races and John did significant refactor, but it is still too complex. In the 
end we want to use L3 HA + DVR but DVR is pretty complex by itself. We would 
like to try to offload this complexity to external service to replace 
management of keepalived instances and networks withing Neutron. Router 
rescheduling is not really an alternative for L3 HA.

RDO with L3 HA is a great example of success, but we want to have ability to 
try something else that can suit other OpenStack deployments better.

I wrote this email to understand whether community have interest in something 
like this, so that it will be worth doing.

On Tue, Feb 14, 2017 at 10:20 PM Assaf Muller 
mailto:as...@redhat.com>> wrote:
On Fri, Feb 10, 2017 at 12:27 PM, Anna Taraday
mailto:akamyshnik...@mirantis.com>> wrote:
> Hello everyone!
>
> In Juno in Neutron was implemented L3 HA feature based on Keepalived (VRRP).
> During next cycles it was improved, we performed scale testing [1] to find
> weak places and tried to fix them. The only alternative for L3 HA with VRRP
> is router rescheduling performed by Neutron server, but it is significantly
> slower and depends on control plane.
>
> What issues we experienced with L3 HA VRRP?
>
> Bugs in Keepalived (bad versions) [2]
> Split brain [3]
> Complex structure (ha networks, ha interfaces) - which actually cause races
> that we were fixing during Liberty, Mitaka and Newton.
>
> This all is not critical, but this is a bad experience and not everyone
> ready (or want) to use Keepalived approach.
>
> I think we can make things more flexible. For example, we can allow user to
> use external services like etcd instead of Keepalived to synchronize current
> HA state across agents. I've done several experiments and I've got failover
> time comparable to L3 HA with VRRP. Tooz [4] can be used to abstract from
> concrete backend. For example, it can allow us to use Zookeeper, Redis and
> other backends to store HA state.
>
> What I want to propose?
>
> I want to bring up idea that Neutron should have some general classes for L3
> HA which will allow to use not only Keepalived but also other backends for
> HA state. This at least will make it easier to try some other approaches and
> compare them with existing ones.
>
> Does this sound reasonable?

I understand that the intention is to add pluggability upstream so
that you could examine the viability of alternative solutions. I'd
advise instead to do the research locally, and if you find concrete
benefits to an alternative solution, come back, show your work and
have a discussion about it then. Merging extra complexity in the form
of a plug point without knowing if we're actually going to need it
seems risky.

On another note, after years of work the stability issues have largely
been resolved and L3 HA is in a good state with modern releases of
OpenStack. It's not a authoritative solution in the sense that it
doesn't cover every possible failure mode, but it covers the major
ones and in that sense better than not having any form of HA, and as
you pointed out the existing alternatives are not in a better state.
The subtext in your email is that now L3 HA is technically where we
want it, but some users are resisting adoption because of bad PR or a
bad past experience, but not for technical reasons. If that is the
case, then perhaps some good PR would be a more cost effective
investment than investigating, implementing, stabilizing and
maintaining a different backend that will likely take at least a cycle
to get merged and another 1 to 2 cycles to iron out kinks. Would you
have a critical mass of developers ready to support a pluggable L3 HA
now and in the long term?

Finally, I can share that L3 HA has been the default in RDO-land for a
few cycles now and is being used widely and success

Re: [openstack-dev] [octavia][sdk] service name for octavia

[Monty Taylor]

On 02/15/2017 09:12 AM, Hayes, Graham wrote:
> On 15/02/2017 15:00, Monty Taylor wrote:
>> On 02/14/2017 07:08 PM, Qiming Teng wrote:
>>> When reviewing a recent patch that adds openstacksdk support to octavia,
>>> I found that octavia is using 'octavia' as its service name instead of
>>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>>
>> Please not loadbalancingv2. As dean says in his email, we should be
>> using service_type not service_name for this. And service type should
>> not contain a version (please ignore what cinder did for v2 and v3
>> entries in the service catalog, it is a pattern that should not happen)
> 
> +1000
> 
>> All the services should have a version discovery endpoint on their
>> unversioned endpoint. If there is a v1 and a v2, then a user looking for
>> the loadbalancing service, if they want v2, should be able to get there
>> through version discovery.
>>
>> Also, if you haven't used loadbalancing anywhere yet, can I suggest
>> load-balancing instead to match object-store and key-manager?
>>
>>> The overall suggestion is to use a word/phrase that indicates what a
>>> service do instead of the name of the project providing that service.
>>>
>>> Below is the list of the service types currently supported by
>>> openstacksdk:
>>>
>>> 'alarming',# aodh
>>> 'baremetal',   # ironic
>>> 'clustering',  # senlin
>>> 'compute', # nova
>>> 'database',# trove
>>> 'identity',# keystone
>>> 'image',   # glance
>>> 'key-manager', # barbican
>>> 'messaging',   # zaqar
>>> 'metering',# ceilometer
>>> 'network', # neutron
>>> 'object-store',   # swift
>>> 'octavia',# <--- this is an exception
>>> 'orchestration',  # heat
>>> 'volume', # cinder
>>> 'workflowv2', # mistral

Also - while we're on the topic - can we fix that to just be workflow ^^ ?



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Dan Smith]

> The problem is there's no way to update an existing cell's transport_url
> via nova-manage.

There is:

https://review.openstack.org/#/c/431582/

> It appears the only way to get around this is manually deleting the old
> cell1 record from the db.

No, don't do that :)

> I'd like to hear more opinions on this but it really seems like this
> should be a priority to fix prior to the Ocata final release.

Already done!

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia][sdk] service name for octavia

[Hayes, Graham]

On 15/02/2017 15:00, Monty Taylor wrote:
> On 02/14/2017 07:08 PM, Qiming Teng wrote:
>> When reviewing a recent patch that adds openstacksdk support to octavia,
>> I found that octavia is using 'octavia' as its service name instead of
>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>
> Please not loadbalancingv2. As dean says in his email, we should be
> using service_type not service_name for this. And service type should
> not contain a version (please ignore what cinder did for v2 and v3
> entries in the service catalog, it is a pattern that should not happen)

+1000

> All the services should have a version discovery endpoint on their
> unversioned endpoint. If there is a v1 and a v2, then a user looking for
> the loadbalancing service, if they want v2, should be able to get there
> through version discovery.
>
> Also, if you haven't used loadbalancing anywhere yet, can I suggest
> load-balancing instead to match object-store and key-manager?
>
>> The overall suggestion is to use a word/phrase that indicates what a
>> service do instead of the name of the project providing that service.
>>
>> Below is the list of the service types currently supported by
>> openstacksdk:
>>
>> 'alarming',# aodh
>> 'baremetal',   # ironic
>> 'clustering',  # senlin
>> 'compute', # nova
>> 'database',# trove
>> 'identity',# keystone
>> 'image',   # glance
>> 'key-manager', # barbican
>> 'messaging',   # zaqar
>> 'metering',# ceilometer
>> 'network', # neutron
>> 'object-store',   # swift
>> 'octavia',# <--- this is an exception
>> 'orchestration',  # heat
>> 'volume', # cinder
>> 'workflowv2', # mistral
>>
>> While I believe this has been discussed about a year ago, I'm not sure
>> if there are things we missed so I'm brining this issue to a broader
>> audience for discussion.
>>
>> Reference:
>>
>> [1] Patch to python-openstacksdk:
>> https://review.openstack.org/#/c/428414
>> [2] Octavia service naming:
>> http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh#n52
>>
>> Regards,
>>  Qiming
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

Hi all,

Cells v2 in Ocata requires manual database updates each time you scale
rabbitmq.  In my opinion this is a pretty significant regression.  Prior to
cells v2 (no cells) rabbitmq could be scaled without manual database
updates.

The problem is there's no way to update an existing cell's transport_url
via nova-manage.

If you run 'nova-manage cell_v2 create_cell --name cell1' a second time,
the database ends up with two cell1 db records.

It appears the only way to get around this is manually deleting the old
cell1 record from the db.

More details are in the bug at:  https://bugs.launchpad.net/bugs/1664759

I'd like to hear more opinions on this but it really seems like this should
be a priority to fix prior to the Ocata final release.

-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone]PKI token VS Fernet token

[Lance Bragstad]

In addition to what David said, have you played around with caching in
keystone [0]? After the initial implementation of fernet landed, we
attempted to make it the default token provider. We ended up reverting the
default back to uuid because we hit several issues. Around the Liberty and
Mitaka timeframe, we reworked the caching implementation to fix those
issues and improve overall performance of all token formats, especially
fernet.

We have a few different performance perspectives available, too. Some were
run nearly 2 years ago [1] and some are run today [2]. Since the Newton
release, we've made drastic improvements to the overall structure of the
token provider [3] [4] [5]. At the very least, it should make understanding
keystone's approach to tokens easier. Maintaining out-of-tree token
providers should also be easier since we cleaned up a lot of the interfaces
that affect developers maintaining their own providers.

We can try and set something up at the PTG. We are getting pretty tight for
time slots, but I'm sure we can find some time to work through the issues
you're seeing (also, feel free to hop into #openstack-keystone on freenode
if you want to visit prior to the PTG).


[0]
https://docs.openstack.org/developer/keystone/configuration.html#caching-layer
[1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
[2] https://github.com/lbragstad/keystone-performance
[3]
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default
[4]
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider
[5]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/token-provider-cleanup.html

On Wed, Feb 15, 2017 at 8:44 AM, David Stanek  wrote:

> On 15-Feb 18:16, 王玺源 wrote:
> > Hello everyone,
> >   PKI/PKIZ token has been removed from keystone in Ocata. But recently
> our
> > production team did some test about PKI and Fernet token (With Keystone
> > Mitaka). They found that in large-scale production environment, Fernet
> > token's performance is not as good as PKI. Here is the test data:
> >
> > https://docs.google.com/document/d/12cL9bq9EARjZw9IS3YxVmYsGfdauM
> 25NzZcdzPE0fvY/edit?usp=sharing
>
> This is nice to see. Thanks.
>
>
> >
> > From the data, we can see that:
> > 1. In large-scale concurrency test, PKI is much faster than Fernet.
> > 2. PKI token revoke can't immediately make the token invalid. So it has
> the
> > revoke issue.  https://wiki.openstack.org/wiki/OSSN/OSSN-0062
> >
> > But in our production team's opinion, the revoke issue is a small
> problem,
> > and can be avoided by some periphery ways. (More detail solution could be
> > explained by them in the follow email).
> > They think that the performance issue is the most important thing. Maybe
> > you can see that in some production environment, performance is the first
> > thing to be considered.
>
> I'd like to hear solutions to this if you have already come up with
> them. This issue, however, isn't the only one that led us to remove PKI
> tokens.
>
> >
> > So here I'd like to ask you, especially the keystone experts:
> > 1. Is there any chance to bring PKI/PKIZ back to Keystone?
>
> I would guess that, at least in the immediate future, we would not want
> to put it back into keystone until someone can fix the issues. Also
> ideally running the token provider in production.
>
>
> > 2. Has Fernet token improved the performance during these releases? Or
> any
> > road map so that we can make sure Fernet is better than PKI in all side.
> > Otherwise, I don't think that remove PKI in Ocata is the right way. Or
> > even, we can keep the PKI token in Keystone for more one or two cycles,
> > then remove it once Fernet is stable enough.
> > 3. Since I'll be in Atalanta next week, if it is possible, I'd like to
> > bring this topic to Keystone PTG. can I?
>
> Sure. We have a pretty packed calendar, but I'm sure you could steal a
> few minutes somewhere.
>
>
> >
> > It is a real production problem and I really need your feedback.
> >
>
> Have you tried playing with the crypt_strength[1]? If the slowness is
> the crypto (which it was in the past) then you can tune it a little bit.
> Another option might be to keep the same token flow and find a faster
> method for hashing a token.
>
> 1. http://git.openstack.org/cgit/openstack/keystone/tree/etc/
> keystone.conf.sample#n67
>
>
> --
> david stanek
> web: https://dstanek.com
> twitter: https://twitter.com/dstanek
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Paul Belanger]

On Wed, Feb 15, 2017 at 01:43:46PM +0100, Thomas Goirand wrote:
> Hi there,
> 
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
> 
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
> 
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
> 
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
> 
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
> 
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
> 
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
> 
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
> 
> Thanks for the fish,
> 
> Thomas Goirand (zigo)
> 
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
> 
Thanks for all your work. I'm glad we eventually stood up all the packaging
infrastructure.

Good luck on your future endeavors.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia][sdk] service name for octavia

[Monty Taylor]

On 02/14/2017 07:08 PM, Qiming Teng wrote:
> When reviewing a recent patch that adds openstacksdk support to octavia,
> I found that octavia is using 'octavia' as its service name instead of
> 'loadbalancing' or 'loadbalancingv2' or something similar.

Please not loadbalancingv2. As dean says in his email, we should be
using service_type not service_name for this. And service type should
not contain a version (please ignore what cinder did for v2 and v3
entries in the service catalog, it is a pattern that should not happen)

All the services should have a version discovery endpoint on their
unversioned endpoint. If there is a v1 and a v2, then a user looking for
the loadbalancing service, if they want v2, should be able to get there
through version discovery.

Also, if you haven't used loadbalancing anywhere yet, can I suggest
load-balancing instead to match object-store and key-manager?

> The overall suggestion is to use a word/phrase that indicates what a
> service do instead of the name of the project providing that service.
> 
> Below is the list of the service types currently supported by
> openstacksdk:
> 
> 'alarming',# aodh
> 'baremetal',   # ironic
> 'clustering',  # senlin
> 'compute', # nova
> 'database',# trove
> 'identity',# keystone
> 'image',   # glance
> 'key-manager', # barbican
> 'messaging',   # zaqar
> 'metering',# ceilometer
> 'network', # neutron
> 'object-store',   # swift
> 'octavia',# <--- this is an exception
> 'orchestration',  # heat
> 'volume', # cinder
> 'workflowv2', # mistral
> 
> While I believe this has been discussed about a year ago, I'm not sure
> if there are things we missed so I'm brining this issue to a broader
> audience for discussion.
> 
> Reference:
> 
> [1] Patch to python-openstacksdk:
> https://review.openstack.org/#/c/428414
> [2] Octavia service naming:
> http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh#n52
> 
> Regards, 
>  Qiming
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [docs] PTG Neutron Documentation Session

[John Davidge]

Hi Everyone,

The OpenStack Manuals team will be holding a PTG session to discuss the
current state and future of the Networking Guide[1] on:

Tuesday at 3:00pm - 3:40pm in the documentation room.

Anyone interested in helping with continued improvements and bug fixes is
encouraged to attend.

Thanks,

John

[1] https://docs.openstack.org/networking-guide/



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone]PKI token VS Fernet token

[David Stanek]

On 15-Feb 18:16, 王玺源 wrote:
> Hello everyone,
>   PKI/PKIZ token has been removed from keystone in Ocata. But recently our
> production team did some test about PKI and Fernet token (With Keystone
> Mitaka). They found that in large-scale production environment, Fernet
> token's performance is not as good as PKI. Here is the test data:
> 
> https://docs.google.com/document/d/12cL9bq9EARjZw9IS3YxVmYsGfdauM25NzZcdzPE0fvY/edit?usp=sharing

This is nice to see. Thanks.


> 
> From the data, we can see that:
> 1. In large-scale concurrency test, PKI is much faster than Fernet.
> 2. PKI token revoke can't immediately make the token invalid. So it has the
> revoke issue.  https://wiki.openstack.org/wiki/OSSN/OSSN-0062
> 
> But in our production team's opinion, the revoke issue is a small problem,
> and can be avoided by some periphery ways. (More detail solution could be
> explained by them in the follow email).
> They think that the performance issue is the most important thing. Maybe
> you can see that in some production environment, performance is the first
> thing to be considered.

I'd like to hear solutions to this if you have already come up with
them. This issue, however, isn't the only one that led us to remove PKI
tokens.

> 
> So here I'd like to ask you, especially the keystone experts:
> 1. Is there any chance to bring PKI/PKIZ back to Keystone?

I would guess that, at least in the immediate future, we would not want
to put it back into keystone until someone can fix the issues. Also
ideally running the token provider in production.


> 2. Has Fernet token improved the performance during these releases? Or any
> road map so that we can make sure Fernet is better than PKI in all side.
> Otherwise, I don't think that remove PKI in Ocata is the right way. Or
> even, we can keep the PKI token in Keystone for more one or two cycles,
> then remove it once Fernet is stable enough.
> 3. Since I'll be in Atalanta next week, if it is possible, I'd like to
> bring this topic to Keystone PTG. can I?

Sure. We have a pretty packed calendar, but I'm sure you could steal a
few minutes somewhere.


> 
> It is a real production problem and I really need your feedback.
> 

Have you tried playing with the crypt_strength[1]? If the slowness is
the crypto (which it was in the past) then you can tune it a little bit.
Another option might be to keep the same token flow and find a faster
method for hashing a token.

1. 
http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n67


-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][monasca][senlin] unreleased deliverables

[Doug Hellmann]

We have two deliverables, monasca-ceilometer and senlin-dashboard, that
have no releases at all this cycle. The deadline for preparing a release
for cycle-with-intermediary projects is tomorrow, 16 Feb.

If those deliverables are going to be considered part of the Ocata
release, please prepare tags for them. If they are not going to be
part of the Ocata release, please delete the relevant metadata file
in openstack/releases.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][telemetry][magnum][monasca][cinder][senlin][swift][tacker] missing stable/ocata branches

[Doug Hellmann]

We have several cycle-with-intermediary deliverables without
stable/ocata branches (see below).  Please submit the patch to
openstack/releases to create the branch as soon as possible.

Doug

DeliverableTeam Ocata Release   Type
Model
ceilometermiddleware   Telemetry1.0.0   library 
cycle-with-intermediary
magnum magnum   4.0.0   service 
cycle-with-intermediary
monasca-apimonasca  1.5.0   service 
cycle-with-intermediary
monasca-ceilometer monasca  Noneother   
cycle-with-intermediary
monasca-common monasca  1.4.0   other   
cycle-with-intermediary
monasca-persister  monasca  1.3.0   other   
cycle-with-intermediary
monasca-thresh monasca  1.2.0   other   
cycle-with-intermediary
python-brick-cinderclient-ext  cinder   0.3.0   library 
cycle-with-intermediary
python-magnumclientmagnum   2.4.0   library 
cycle-with-intermediary
senlin-dashboard   senlin   None
horizon-plugin  cycle-with-intermediary
swift  swift2.12.0  service 
cycle-with-intermediary
tacker-horizon tacker   0.6.0   
horizon-plugin  cycle-with-intermediary
tacker tacker   0.6.0   service 
cycle-with-intermediary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove] trove-dashboard 8.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for trove-dashboard for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/trove-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/trove-dashboard/log/?h=stable/ocata

Release notes for trove-dashboard can be found at:

http://docs.openstack.org/releasenotes/trove-dashboard/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core

[Spencer, Christopher M]

+1

From: Prashanth Hari 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, February 15, 2017 at 5:01 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core

+1

On Wed, Feb 15, 2017 at 6:27 AM, Antoine Cabot 
mailto:antoinecabo...@gmail.com>> wrote:
+1

On Tue, Feb 14, 2017 at 5:57 PM, Jean-Émile DARTOIS 
mailto:jean-emile.dart...@b-com.com>> wrote:

​+1



Jean-Emile
DARTOIS

{P}

Software Engineer
Cloud Computing

{T}

+33 (0) 2 56 35 8260

{W}

www.b-com.com


De : Susanne Balle mailto:sleipnir...@gmail.com>>
Envoyé : mardi 14 février 2017 17:33
À : OpenStack Development Mailing List (not for usage questions)
Objet : Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core

+1

On Tue, Feb 14, 2017 at 5:37 AM, Vincent FRANÇOISE 
mailto:vincent.franco...@b-com.com>> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

+1

On 14/02/2017 11:27, ? ? wrote:
> His activity will help Watcher Team to make this project better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYot3aAAoJEEb+XENQ/jVSvIEH/RsqFZZ7hZyA7ExieF7K4GmN
d1f1vnPbOR3MgqQTbezixIPIwzrDw9dtpU6q8BRPARP6ja2tOPNoYHc1CZmxgwz9
Mc5iVhvAaKuzL7KKpeROVkLkVUJ9bZnxNM/pkgiq0qXYoBaitgVdPVTIE6nBLdpV
yHRkUG24pkojogIJGIbB2cJeKganJ+PrCB59buAof1NqEhujt00akfjHCKbc7Wc/
oSmx2VD3aRn8OcfAhQ1pQgRYpa6MRFBRbDUPejVyiGzFWTDreWA3cLVq2xpGEcCW
ahcq2MNsZCiFegD4u9jYroULOALhdGBUctONbluaqbfZ7PhPPqQxSJGQq96hTCg=
=WsCi
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to Watcher Core

[Spencer, Christopher M]

+1

From: Чадин Александр 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, February 15, 2017 at 6:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to 
Watcher Core

Strong +1

On 15 Feb 2017, at 14:27, Antoine Cabot 
mailto:antoinecabo...@gmail.com>> wrote:

+1

On Tue, Feb 14, 2017 at 5:56 PM, Jean-Émile DARTOIS 
mailto:jean-emile.dart...@b-com.com>> wrote:
​+1

Jean-Emile
DARTOIS

{P}

Software Engineer
Cloud Computing

{T}

+33 (0) 2 56 35 8260

{W}

www.b-com.com


De : Susanne Balle mailto:sleipnir...@gmail.com>>
Envoyé : mardi 14 février 2017 17:30
À : OpenStack Development Mailing List (not for usage questions)
Objet : Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to 
Watcher Core

+1

On Tue, Feb 14, 2017 at 9:31 AM, Prashanth Hari 
mailto:hvpr...@gmail.com>> wrote:
+1

On Tue, Feb 14, 2017 at 9:22 AM, Joe Cropper 
mailto:cropper@gmail.com>> wrote:
+1 !

> On Feb 14, 2017, at 4:05 AM, Vincent FRANÇOISE 
> mailto:vincent.franco...@b-com.com>> wrote:
>
> Team,
>
> I would like to promote Prudhvi Rao Shedimbi to the core team. He's done
> a great work in reviewing many patchsets[1] and I believe that he has a
> good vision of Watcher as a whole.
>
> I think he would make an excellent addition to the team.
>
> Please vote
>
> [1] http://stackalytics.com/report/contribution/watcher/90
>
> Vincent FRANCOISE
> B<>COM
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Pike PTG Schedule

[Andrea Frittoli]

A quick update on this: I put together a small ethercalc for the QA
sessions, you can find it at
https://ethercalc.openstack.org/Pike-PTG-QA-Planning.

I felt 30min is too short for most sessions, also considering we will need
breaks every now and then, and some grace time for people to come and go,
so I allocated 2 x 30min slots to most sessions.

If you need a projector please book a room accordingly, and mark it on the
schedule so that folks know where to go.

Andrea


On Wed, Feb 15, 2017 at 2:22 PM Andrea Frittoli 
wrote:

> On Tue, Feb 14, 2017 at 3:00 PM Ken'ichi Ohmichi 
> wrote:
>
> Hi Andrea,
>
> Thanks for organizing QA sessions for PTG.
>
> 2017-02-13 16:16 GMT-08:00 Andrea Frittoli :
> > Hello team,
> >
> > I did some work on the etherpad [0] to organise the QA PTG schedule
> based on
> > the proposed sessions.
> > I separated discussion sessions from hands-on type of actives. I thing
> the
> > former will require a fixed schedule so folks may know when to pop-in to
> > attend; the latter may happen more ad-hoc based on who's there an not
> busy
> > in a session. We can have a final discussion on this in the QA meeting on
> > Thursday [1].
>
> It is a nice idea to separate discussion sessions from hands-on (code
> sprint) sessions.
> Now we have 9 discussion sessions which don't require arranging the
> time schedule with the other teams.
> So I feel it is nice to schedule them in the first day and schedule
> hands-on sessions(working items based on discussion sessions and 3
> original hands-on session) in the second day so that we get feedback
> and discuss them again during the second day.
> That is an idea, I am happy to see the other schedule idea :-)
>
>
> Thanks - that's a good idea.
> I would keep the "priorities" session at the end though.
>
>
>
> > I haven't fixed the exact schedule yet, I will do it soon; meanwhile
> please
> > let me know if you think your session will need more or less then 30'
> which
> > is the standard time I would allocate.
> > Discussions that overrun the planned time can go in a parking lot, which
> we
> > can pick up later at the PTG or during meetings.
> > Any session preparation work / existing material, previous discussions,
> > links and so can go in the respective etherpad.
> >
> > I think we have a good set of topics to discuss and code to write,
> enough to
> > keep us busy for more than the time we have.
> > Nonetheless, if you have more topic to propose please continue adding
> them
> > to the etherpad.
>
> Yes, it is nice to make us busy in PTG.
>
> Thanks
> Ken Ohmichi
>
> ---
>
> > [0] https://etherpad.openstack.org/p/qa-ptg-pike
> > [1]
> >
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_February_16th_2017_.281700_UTC.29
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Pike PTG Schedule

[Andrea Frittoli]

On Tue, Feb 14, 2017 at 3:00 PM Ken'ichi Ohmichi 
wrote:

> Hi Andrea,
>
> Thanks for organizing QA sessions for PTG.
>
> 2017-02-13 16:16 GMT-08:00 Andrea Frittoli :
> > Hello team,
> >
> > I did some work on the etherpad [0] to organise the QA PTG schedule
> based on
> > the proposed sessions.
> > I separated discussion sessions from hands-on type of actives. I thing
> the
> > former will require a fixed schedule so folks may know when to pop-in to
> > attend; the latter may happen more ad-hoc based on who's there an not
> busy
> > in a session. We can have a final discussion on this in the QA meeting on
> > Thursday [1].
>
> It is a nice idea to separate discussion sessions from hands-on (code
> sprint) sessions.
> Now we have 9 discussion sessions which don't require arranging the
> time schedule with the other teams.
> So I feel it is nice to schedule them in the first day and schedule
> hands-on sessions(working items based on discussion sessions and 3
> original hands-on session) in the second day so that we get feedback
> and discuss them again during the second day.
> That is an idea, I am happy to see the other schedule idea :-)
>

Thanks - that's a good idea.
I would keep the "priorities" session at the end though.


>
> > I haven't fixed the exact schedule yet, I will do it soon; meanwhile
> please
> > let me know if you think your session will need more or less then 30'
> which
> > is the standard time I would allocate.
> > Discussions that overrun the planned time can go in a parking lot, which
> we
> > can pick up later at the PTG or during meetings.
> > Any session preparation work / existing material, previous discussions,
> > links and so can go in the respective etherpad.
> >
> > I think we have a good set of topics to discuss and code to write,
> enough to
> > keep us busy for more than the time we have.
> > Nonetheless, if you have more topic to propose please continue adding
> them
> > to the etherpad.
>
> Yes, it is nice to make us busy in PTG.
>
> Thanks
> Ken Ohmichi
>
> ---
>
> > [0] https://etherpad.openstack.org/p/qa-ptg-pike
> > [1]
> >
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_February_16th_2017_.281700_UTC.29
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][CI] Dev CI environment for OVB

[Martin Magr]

Hey Sagi,

  attached is my public key, can you add it to tenant defaults, so I can
debug [1]?

Thanks in advance,
Martin

[1] https://review.openstack.org/#/c/433931/

On Tue, Sep 27, 2016 at 12:01 PM, Sagi Shnaidman 
wrote:

> Hi, all
>
> with Dereks help we set up OVB dev environment on rh1/rh2 clouds, which
> allow developers to run their patches in real CI environment and debug
> their issues there. In case you have a problem with your patch on CI and
> locally it works - you can reproduce and debug it on this environment.
> Please note, this is OVB environment only.
> Please use for regular patch tests the tripleo-quickstart project[1],
> which is more fits this purpose, this dev env is for CI issues only.
>
> If shortly, we have a special tenants on rh1/rh2, on which you can create
> your undercloud vm from infra image, then create your OVB environment
> there. Finally you're ready to run your patch there - clone your repo,
> inject the changes and run main CI script toci_gate_test.sh.
>
> The whole process is described in etherpad https://etherpad.openstack.org
> /p/tripleo-ci-devenvs where below you'll find a script that does
> everything for you (as all scripts should do usually).
>
> In case you need to test your patch, just send me your *public* keys
> *offline*, I'll add them to tenant defaults and you'll be able to run it.
>
> Thanks
>
> [1] https://github.com/openstack/tripleo-quickstart
> --
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Martin Mágr
Senior Software Engineer
Red Hat Czech


id_rsa.pub
Description: application/vnd.ms-publisher
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Jeremy Stanley]

On 2017-02-15 13:21:16 + (+), Andrea Frittoli wrote:
[...]
> According to logstash [3] all failures identified by [2] happen on RAX
> nodes [3], which I hadn't realised before.
[...]
> I find it hard to relate lower free memory to a specific cloud provider /
> underlying virtualisation technology, but maybe someone has an idea about
> how that could be?

That provider is, AFAIK, the only Xen-based environment in which we
test. Is it possible memory allocations in a Xen DomU incur
additional overhead compared to other popular hypervisors?
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Andrea Frittoli]

Some (new?) data on the oom kill issue in the gate.

I filed a new bug / E-R query yet for the issue [1][2] since it looks to me
like the issue is not specific to mysqld - oom-kill will just pick the best
candidate, which in most cases happens to be mysqld. The next most likely
candidate to show errors in the logs is keystone, since token requests are
rather frequent, more than any other API call probably.

According to logstash [3] all failures identified by [2] happen on RAX
nodes [3], which I hadn't realised before.

Comparing dstat data between the failed run and a successful on an OVH node
[4], the main difference I can spot is free memory.
For the same test job, the free memory tends to be much lower, quite close
to zero for the majority of the time on the RAX node. My guess is that an
unlucky scheduling of tests may cause a slightly higher peak in memory
usage and trigger the oom-kill.

I find it hard to relate lower free memory to a specific cloud provider /
underlying virtualisation technology, but maybe someone has an idea about
how that could be?

Andrea

[0]
http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/6f31320/logs/syslog.txt.gz#_Feb_14_00_32_28

[1] https://bugs.launchpad.net/tempest/+bug/1664953
[2] https://review.openstack.org/434238
[3]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Out%20of%20memory%3A%20Kill%20process%5C%22%20AND%20tags%3A%5C%22syslog.txt%5C%22

[4]
http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/1dfb4b7/logs/dstat-csv_log.txt.gz


On Mon, Feb 6, 2017 at 10:13 AM Miguel Angel Ajo Pelayo 
wrote:

Jeremy Stanley wrote:


> It's an option of last resort, I think. The next consistent flavor
> up in most of the providers donating resources is double the one
> we're using (which is a fairly typical pattern in public clouds). As
> aggregate memory constraints are our primary quota limit, this would
> effectively halve our current job capacity.

Properly coordinated with all the cloud the providers, they could create
flavours which are private but available to our tenants, where a 25-50%
more RAM would be just enough.

I agree that should probably be a last resort tool, and we should keep
looking for proper ways to find where we consume unnecessary RAM and make
sure that's properly freed up.

It could be interesting to coordinate such flavour creation in the mean
time, even if we don't use it now, we could eventually test it or put it to
work if we find trapped anytime later.


On Sun, Feb 5, 2017 at 8:37 PM, Matt Riedemann  wrote:

On 2/5/2017 1:19 PM, Clint Byrum wrote:


Also I wonder if there's ever been any serious consideration given to
switching to protobuf? Feels like one could make oslo.versionedobjects
a wrapper around protobuf relatively easily, but perhaps that's already
been explored in a forum that I wasn't paying attention to.


I've never heard of anyone attempting that.

-- 

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev