[openstack-dev] [charms] design summit sessions summary

[James Page]

Hi All

After some extended travel after the summit, I've finally got round to
writing a summary of the two design summit sessions we held in Barcelona
(see [0] and [1] for full notes).

1) Cross Charm Initiatives

We had general agreement to switch all charms to Python 3, dropping charm
support for Ubuntu 12.04 in the process in order to have a decent Python 3
baseline to work with from 14.04 onwards. This should be achievable this
cycle.

All charms will switch to using memcache locally for token caching, and
where possible API services will be run under Apache+mod_wsgi, inline with
changes in support policy being made across other projects.

The next charm release will be aligned to the Ocata release (February), and
then we'll resume the normal 3 month cadence from that point forward -
which means we have a slightly longer than normal cycle!

2) Testing REDUX

We had a number of discussion both in the fishbowl session and in the
workroom on Friday about re-aligning testing around bundles, rather than
individual charms - this is in alignment with a general shift in the wider
charm community, and some new tooling is appearing to support that
(Matrix).  I anticipate this will be a multi-cycle effort, but it should
make it much easier for the wider charm ecosystem to CI against core charm
changes going forward.

3) OpenStack LB

Currently all haproxy services are run on unit (i.e. embedded alongside
glance/cinder/neutron/nova etc...).  We discussed a plan to allow load
balancing to be placed separately from core services, supporting use of
multiple DMZ network topologies, and potentially easing lifecycle upgrades
from trusty->xenial (although that bit s part of a wider piece of work
around cross Ubuntu series upgrades for OpenStack).

I think that just about covers the high level items.

I really enjoyed the workroom time we had on Friday esp. helping the
developers from 6wind, Calico and CloudBase get started on the road to
making their charm integrations part of the Charms project - it was great
to see the start of the incubation process for growing and diversifying our
developer community!

Thank-you to all of those who participated!

Cheers

James

[0] https://etherpad.openstack.org/p/BCN-charms-fb-1
[1] https://etherpad.openstack.org/p/BCN-charms-fb-2
__
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] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
> On 08/11/2016 10:30, Thierry Carrez wrote:
> > Ash wrote:
> >> [...]
> >> Here's another take on the situation. If there are people who genuinely
> >> wish to see a CI pipeline that can support something like Go, perhaps
> >> you can establish a prerequisite of working with the Infra team on
> >> establishing the new pipeline. In my opinion, this seems to be the major
> >> gate. So, if there's a clear path identified, resources provided, and
> >> the Infra team is ultimately benefitted, then I'm not sure why there
> >> should be another rejection. Just a thought. I know this proposal
> >> continues to come up and I'm a big fan of seeing other languages
> >> supported, especially Go. But I also understand that it can break
> >> things. Personally, I would even volunteer to work on such an Infra effort.
> >>
> >> BTW, it is quite possible that another group might feel the same
> >> constraints. It's perfectly reasonable. But if we can overcome such
> >> obstacles, would the TC still have a concern?
> >
> > The TC isn't just one person. In complex situations like this where you
> > have to weigh the trade-off between opening up more choices and our
> > community's ability to digest/survive the change, there will always be a
> > wide variety of opinions. I won't claim to be able to predict how the
> > current membership would vote.
> 
> Yup - and the TC could possibly change half, (or even all) its members
> during time it takes to get this work done.
> 
> > That said, I think that if we can have more confidence that our
> > structure can handle it (from infra to release/stable/dep management)
> > and that the OpenStack community will share expertise and best practices
> > on Go and avoid reinventing the wheel in every project, I expect a
> > majority of TC members to take that leap of faith.
> 
> There was a bit of work done for the previous proposal, but the main
> objections were not to do with any of points raised in this email /
> blog. The objections were mainly cultural - about how it would impact
> the community (which *is* very important), and the exactly why it was
> needed for the projects who were asking.
> 
> > To me, the important part is that introducing Go should not be another
> > way for some of our community to be different, but another way for our
> > community to be one. It should do more to bind our community together
> > than to split it into more factions and silos.
> >
> 
> I would agree - but I would ask that we find a way forward that does not
> require huge amounts of up front work, for a gamble at the end of the
> process, where the work could be written off for any number of other
> reasons.
> 

I agree that we need to be careful about how much up-front work is
required. A plan to address some of these concerns seems like a
minimum level, with commitment to handle the immediate items like
infra resources for managing those changes. But it's hard to specify
the right levels in the abstract, because so much depends on the
situation, language, and teams involved.

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] [Magnum] New Core Reviewers

[Spyros Trigazis]

+1 for both

Cheers,
Spyros

On 8 November 2016 at 03:34, Yuanying OTSUKA  wrote:

> +1 for both.
>
> Best regards
> -yuanying
>
> 2016年11月8日(火) 4:23 Hongbin Lu :
>
>> +1!
>>
>> Both jvgrant and yatin contributed a lot to the Magnum project. It would
>> be great to have both of you in the core team.
>>
>> Best regards,
>> Hongbin
>>
>> > -Original Message-
>> > From: Adrian Otto [mailto:adrian.o...@rackspace.com]
>> > Sent: November-07-16 2:06 PM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: [openstack-dev] [Magnum] New Core Reviewers
>> >
>> > Magnum Core Team,
>> >
>> > I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum
>> > Core Reviewers. Please respond with your votes.
>> >
>> > Thanks,
>> >
>> > Adrian Otto
>> > ___
>> > ___
>> > 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] [searchlight] Propose Zhenyu Zheng for Searchlight core

[McLellan, Steven]

Sorry for the delay, I was out of town. This is now done. Welcome to the core 
team!

From: Zhenyu Zheng
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Monday, November 7, 2016 at 8:13 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [searchlight] Propose Zhenyu Zheng for Searchlight 
core

Thanks a lot, there will be still so much to learn from you guys.

On Tue, Nov 1, 2016 at 4:58 PM, Lei Zhang 
> wrote:
+1 for me

On Thu, Oct 20, 2016 at 5:13 PM, Brian Rosmaita 
> wrote:
+1 from me, I'll be happy to see Kevin on the core list.

On 10/19/16, 10:10 AM, "McLellan, Steven" 
> wrote:

Hi,

I'd like to propose Zhenyu Zheng (Kevin_Zheng on IRC) for Searchlight core. 
While he's most active on Nova, he's also been very active on Searchlight both 
in commits and reviews during the Newton release and into Ocata on Searchlight. 
Kevin's participated during the weekly meetings and during the week, and his 
reviews have been very high quality as well as numerous. This would also help 
move towards have greater cross-project participation, especially with Nova.

If anyone has any objections, let me know, otherwise I will add Kevin to the 
core list at the weekend.

Thanks!

Steve

__
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] [all] Embracing new languages in OpenStack

[Flavio Percoco]

On 08/11/16 13:04 +, Hayes, Graham wrote:

On 08/11/2016 10:30, Thierry Carrez wrote:

That said, I think that if we can have more confidence that our
structure can handle it (from infra to release/stable/dep management)
and that the OpenStack community will share expertise and best practices
on Go and avoid reinventing the wheel in every project, I expect a
majority of TC members to take that leap of faith.


There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.


I think part of the community-wide concerns that were raised originated from the
lack of an actual process for this evaluation to be done and the lack of up
front work, which is something that I'm trying to address here. This is a new
process and I think defining this expectations is the key to help with future
proposals.

I believe an early evaluation of the needs for a new language should still be
part of the process, though. Likely at the very beginning of the process, before
the up front work is even started.

Flavio

--
@flaper87
Flavio Percoco


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] [all] Embracing new languages in OpenStack

[Flavio Percoco]

On 08/11/16 16:20 +, Hayes, Graham wrote:

On 08/11/2016 15:55, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:

On 08/11/2016 10:30, Thierry Carrez wrote:

Ash wrote:

[...]
Here's another take on the situation. If there are people who genuinely
wish to see a CI pipeline that can support something like Go, perhaps
you can establish a prerequisite of working with the Infra team on
establishing the new pipeline. In my opinion, this seems to be the major
gate. So, if there's a clear path identified, resources provided, and
the Infra team is ultimately benefitted, then I'm not sure why there
should be another rejection. Just a thought. I know this proposal
continues to come up and I'm a big fan of seeing other languages
supported, especially Go. But I also understand that it can break
things. Personally, I would even volunteer to work on such an Infra effort.

BTW, it is quite possible that another group might feel the same
constraints. It's perfectly reasonable. But if we can overcome such
obstacles, would the TC still have a concern?


The TC isn't just one person. In complex situations like this where you
have to weigh the trade-off between opening up more choices and our
community's ability to digest/survive the change, there will always be a
wide variety of opinions. I won't claim to be able to predict how the
current membership would vote.


Yup - and the TC could possibly change half, (or even all) its members
during time it takes to get this work done.


That said, I think that if we can have more confidence that our
structure can handle it (from infra to release/stable/dep management)
and that the OpenStack community will share expertise and best practices
on Go and avoid reinventing the wheel in every project, I expect a
majority of TC members to take that leap of faith.


There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.


To me, the important part is that introducing Go should not be another
way for some of our community to be different, but another way for our
community to be one. It should do more to bind our community together
than to split it into more factions and silos.



I would agree - but I would ask that we find a way forward that does not
require huge amounts of up front work, for a gamble at the end of the
process, where the work could be written off for any number of other
reasons.



I agree that we need to be careful about how much up-front work is
required. A plan to address some of these concerns seems like a
minimum level, with commitment to handle the immediate items like
infra resources for managing those changes. But it's hard to specify
the right levels in the abstract, because so much depends on the
situation, language, and teams involved.

Doug


This. I think trying to define objective rules, procedures, and
checklists for what is at the end of the a subjective decision is
not a great idea.

Should the policy just be "If you want to add a new language, add an
item to the TC agenda. They will the discuss the overall proposal, and
may ask for more details in the following areas, the use case, or decide
that this is not a direction that the community should proceed towards."

Or, you know, a well written version of ^.


This feels a lot like what we have today. I think the set of requirements must
be written down and clear. The evaluation of the use case should still happen
and it'd be better for it to happen before the up-front work is done. There will
always be work to do up front for any new language being added to the community.

Also, for the evaluation of the use case, it'd be awesome to have the use case
presented to the mailing list before the item is even added to the TC agenda. I
liked the review that other members of the community did with the Swift
proposal.

Flavio

--
@flaper87
Flavio Percoco


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] [nova] Nova-MultiJob CI (non-voting) request to comment

[Znoinski, Waldemar]

Hi Lenny, Matt et al,

We've touched the same NFV features testing topic on live-migration meeting 
today and apart a ML [1] post we'd invite everybody to collaborate around nfv 
tests in etherpad [2].

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106949.html 
[2] https://etherpad.openstack.org/p/nfv-tests 

 >-Original Message-
 >From: Lenny Verkhovsky [mailto:len...@mellanox.com]
 >Sent: Sunday, November 6, 2016 7:50 AM
 >To: OpenStack Development Mailing List (not for usage questions)
 >
 >Subject: Re: [openstack-dev] [nova] Nova-MultiJob CI (non-voting) request
 >to comment
 >
 >Matt, Chris,
 >Thanks, your filtering suggestion will be added when possible.
 >
 >> -Original Message-
 >> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
 >> Sent: Friday, November 04, 2016 9:42 PM
 >> To: openstack-dev@lists.openstack.org
 >> Subject: Re: [openstack-dev] [nova] Nova-MultiJob CI (non-voting)
 >> request to comment
 >>
 >> On 11/4/2016 2:04 AM, Lenny Verkhovsky wrote:
 >> > It uses 2 physical servers with 2 compute nodes And runs migration
 >> > tests only.
 >> > Other Mellanox CI jobs run on a single allinone server, thus
 >> > migration tests
 >> are skipped.
 >> >
 >>
 >> I think this was mentioned at the summit. In general we have a major
 >> gap in multinode testing for NFV features like PCI so this would be a
 >> welcome addition. As noted elsewhere there are other ares of nova to
 >> expand the coverage for this, like I'd recommend any changes to
 >> nova/compute/* and nova/network/* to be tested under this. But
 >> starting small makes sense.
 >>
 >> --
 >>
 >> 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
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
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] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2016-11-07 15:53:51 -0800:
> >
> > Concretely - oslo.config is important because it shapes what the config
> > files look like. The implementation language of a particular service
> > shouldn't change what our config files look like, yeah?
> 
> Standards though exist for a reason (and ini files are pretty common 
> across languages and such); though of course oslo.config has some very 
> tight integration with openstack, the underlying ini concept it 
> eventually reads/writes really isn't that special (so hopefully such a 
> thing existing isn't that hard).
> 
> As a note gflags in go (which I think is the default option mechanism?) 
> is alot like oslo.config (in fact oslo.config came from a python version 
> of gflags way back when).
> 
> Personally though I'd prefer to just say (if I could) 'ini' file is the 
> standard format for options in openstack (and drop the mix of command 
> line options and configuration/ini file options).

Yes, I wish we hadn't invented our own parser, too. That being said, we
did.

> 
> >
> > Similarly keystoneauth - not because getting a token from keystone with
> > a username and password is necessarily hard- but because we're trying to
> > drive more service-service interactions through the catalog to reduce
> > the number of things an operator needs to configure directly - and also
> > because keystone has auth plugins that need to be supported in the new
> > language too. (it's a common fault in non-python client implementations
> > that non-password auth plugins are not covered at all)
> >
> > oslo.log has similar needs - the logging for an operator needs to be
> > able to be routed to the same places and be in the same format as the
> > existing things.
> 
> Pretty sure most systems have logging that is similar to java logging 
> (which afaik is where the python logging system came from/was inspired 
> from); oslo.log has some specific tie-ins to oslo.config (but see above 
> statement of using a ini file as the option mechanism).

Which is good from a developer perspective. From a deployer perspective,
the behavior embedded in oslo.log and controlled by the config options
is what we would want to reproduce, on top of a native logging system if
possible.

> 
> >
> > oslo.messaging and oslo.db have needs where they intersect with operator
> > config.
> 
> I hope we aren't restricting ourselves to much because of the 
> specialized libraries we have made that typically have (some level) of 
> equivalent in other languages. Though of course those languages and 
> libraries do not typically(?) have the tie-together that we have created 
> with our libraries (for better or worse).
> 
> -Josh
> 

__
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] Embracing new languages in OpenStack

[Jeremy Stanley]

On 2016-11-08 06:43:33 -0800 (-0800), Flavio Percoco wrote:
[...]
> I think part of the community-wide concerns that were raised
> originated from the lack of an actual process for this evaluation
> to be done and the lack of up front work, which is something that
> I'm trying to address here.
[...]

Part, yes. But also a big part of it was a concern that we would
divide the community over language preferences: some only
contributing to cross-project efforts for Python-based components,
some only for Golang-based components, and neither camp
communicating with the other. This can quickly devolve into an
adversarial us-vs-them relationship, further hampering any hope for
cooperation. Maybe settling on process and tooling up-front helps
minimize this inherently social problem, but I am unconvinced.

On the other hand, I don't know that indefinitely deferring
introduction of other languages actually solves this either. If
anything, those camps will still most likely exist... just one of
them will be entirely outside the official reaches of our community
and so even more isolated and bitter.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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-dev] [winstackers][hyperv] IRC Hyper-V team meeting

[Claudiu Belu]

Hello,

We will resume the weekly Hyper-V meetings on Wednesdays, 13:00 UTC, on the 
#openstack-meeting-3 IRC channel, starting with tomorrow.

Meeting details: https://wiki.openstack.org/wiki/Meetings/Hyper-V

Feel free to join!

Best regards,

Claudiu Belu

__
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] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 16:39, Flavio Percoco wrote:
> On 08/11/16 16:20 +, Hayes, Graham wrote:
>> On 08/11/2016 15:55, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
 On 08/11/2016 10:30, Thierry Carrez wrote:
> Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps
>> you can establish a prerequisite of working with the Infra team on
>> establishing the new pipeline. In my opinion, this seems to be the major
>> gate. So, if there's a clear path identified, resources provided, and
>> the Infra team is ultimately benefitted, then I'm not sure why there
>> should be another rejection. Just a thought. I know this proposal
>> continues to come up and I'm a big fan of seeing other languages
>> supported, especially Go. But I also understand that it can break
>> things. Personally, I would even volunteer to work on such an Infra 
>> effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.

 Yup - and the TC could possibly change half, (or even all) its members
 during time it takes to get this work done.

> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.

 There was a bit of work done for the previous proposal, but the main
 objections were not to do with any of points raised in this email /
 blog. The objections were mainly cultural - about how it would impact
 the community (which *is* very important), and the exactly why it was
 needed for the projects who were asking.

> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

 I would agree - but I would ask that we find a way forward that does not
 require huge amounts of up front work, for a gamble at the end of the
 process, where the work could be written off for any number of other
 reasons.

>>>
>>> I agree that we need to be careful about how much up-front work is
>>> required. A plan to address some of these concerns seems like a
>>> minimum level, with commitment to handle the immediate items like
>>> infra resources for managing those changes. But it's hard to specify
>>> the right levels in the abstract, because so much depends on the
>>> situation, language, and teams involved.
>>>
>>> Doug
>>
>> This. I think trying to define objective rules, procedures, and
>> checklists for what is at the end of the a subjective decision is
>> not a great idea.
>>
>> Should the policy just be "If you want to add a new language, add an
>> item to the TC agenda. They will the discuss the overall proposal, and
>> may ask for more details in the following areas, the use case, or decide
>> that this is not a direction that the community should proceed towards."
>>
>> Or, you know, a well written version of ^.
>
> This feels a lot like what we have today. I think the set of requirements must
> be written down and clear. The evaluation of the use case should still happen
> and it'd be better for it to happen before the up-front work is done. There 
> will
> always be work to do up front for any new language being added to the 
> community.

Yes - and that sentence covers the initial use case discussion, and
also allows for the more subjective criteria to be evaluated before the
up front work is started.

 >> more details in the following areas

In my mind this would point to a list like the one presented here.

> Also, for the evaluation of the use case, it'd be awesome to have the use case
> presented to the mailing list before the item is even added to the TC agenda. 
> I
> liked the review that other members of the community did with the Swift
> proposal.

Sure - I am assuming that projects will not be operating in a vacuum,
and will be taking about the proposal long before they put to the TC.

If that needs to be called out, it should be added.

> Flavio
>

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 15:55, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
>> On 08/11/2016 10:30, Thierry Carrez wrote:
>>> Ash wrote:
 [...]
 Here's another take on the situation. If there are people who genuinely
 wish to see a CI pipeline that can support something like Go, perhaps
 you can establish a prerequisite of working with the Infra team on
 establishing the new pipeline. In my opinion, this seems to be the major
 gate. So, if there's a clear path identified, resources provided, and
 the Infra team is ultimately benefitted, then I'm not sure why there
 should be another rejection. Just a thought. I know this proposal
 continues to come up and I'm a big fan of seeing other languages
 supported, especially Go. But I also understand that it can break
 things. Personally, I would even volunteer to work on such an Infra effort.

 BTW, it is quite possible that another group might feel the same
 constraints. It's perfectly reasonable. But if we can overcome such
 obstacles, would the TC still have a concern?
>>>
>>> The TC isn't just one person. In complex situations like this where you
>>> have to weigh the trade-off between opening up more choices and our
>>> community's ability to digest/survive the change, there will always be a
>>> wide variety of opinions. I won't claim to be able to predict how the
>>> current membership would vote.
>>
>> Yup - and the TC could possibly change half, (or even all) its members
>> during time it takes to get this work done.
>>
>>> That said, I think that if we can have more confidence that our
>>> structure can handle it (from infra to release/stable/dep management)
>>> and that the OpenStack community will share expertise and best practices
>>> on Go and avoid reinventing the wheel in every project, I expect a
>>> majority of TC members to take that leap of faith.
>>
>> There was a bit of work done for the previous proposal, but the main
>> objections were not to do with any of points raised in this email /
>> blog. The objections were mainly cultural - about how it would impact
>> the community (which *is* very important), and the exactly why it was
>> needed for the projects who were asking.
>>
>>> To me, the important part is that introducing Go should not be another
>>> way for some of our community to be different, but another way for our
>>> community to be one. It should do more to bind our community together
>>> than to split it into more factions and silos.
>>>
>>
>> I would agree - but I would ask that we find a way forward that does not
>> require huge amounts of up front work, for a gamble at the end of the
>> process, where the work could be written off for any number of other
>> reasons.
>>
>
> I agree that we need to be careful about how much up-front work is
> required. A plan to address some of these concerns seems like a
> minimum level, with commitment to handle the immediate items like
> infra resources for managing those changes. But it's hard to specify
> the right levels in the abstract, because so much depends on the
> situation, language, and teams involved.
>
> Doug

This. I think trying to define objective rules, procedures, and
checklists for what is at the end of the a subjective decision is
not a great idea.

Should the policy just be "If you want to add a new language, add an
item to the TC agenda. They will the discuss the overall proposal, and
may ask for more details in the following areas, the use case, or decide
that this is not a direction that the community should proceed towards."

Or, you know, a well written version of ^.



> __
> 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] [openstack-infra][nova][tempest][qa][infra] NUMA topology, cpu pinning, hugepages tempest tests upstream or plugin

[Znoinski, Waldemar]

I'd like to invite everybody to collaborate around nfv feature testing in 
OpenStack in etherpad [1].



[1] https://etherpad.openstack.org/p/nfv-tests


From: Znoinski, Waldemar [mailto:waldemar.znoin...@intel.com]
Sent: Tuesday, November 8, 2016 12:26 PM
To: openstack...@lists.openstack.org; openstack-dev@lists.openstack.org; 
openstack-in...@lists.openstack.org
Subject: [openstack-dev] [openstack-infra][nova][tempest][qa][infra] NUMA 
topology, cpu pinning, hugepages tempest tests upstream or plugin

Hi all,

Due to recent discussions around Enhanced Platform Awareness (EPA) and their 
testing in OpenStack thinking was started to take what Intel NFV 3rd party CI 
[1] runs at this moment and merge some/all into upstream Tempest. Currently 
intel-nfv-ci-tests is a Tempest plugin [2] [3] and it's running on all Nova 
changes , sample [4]. Merging them with upstream Tempest would give testing 
environments an option to turn them on with a flip of a switch in tempest.conf 
rather than pip install  + tempest run with all-plugin (to enable 
site_packages).

While some of them may be easier from technical stand point (hugepages) some of 
them may not be possible in cloud providers used by OpenStack Infra.

Both options: Tempest plugin, upstream Tempest have pros and cos and we'd like 
to get broader community to comment on that.
If you have any feedback, suggestions, ideas please follow up here.


[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI
[2] https://github.com/openstack/intel-nfv-ci-tests
[3] http://docs.openstack.org/developer/tempest/plugin-registry.html
[4] 
http://intel-openstack-ci-logs.ovh/51/393951/2/check/tempest-dsvm-intel-nfv-xenial/2982905/

thanks
wznoinsk

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
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] [release] New hacking 0.12.0

[Ian Cordasco]

 

-Original Message-
From: Ihar Hrachyshka 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 8, 2016 at 02:39:24
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [release] New hacking 0.12.0

>  
> > On 7 Nov 2016, at 21:47, Ken'ichi Ohmichi wrote:
> >
> > Hi,
> >
> > Today a new hacking 0.12.0 is released.
> > The release contains a new hacking rule:
> >
> > [H904] Delay string interpolations at logging calls.
> >
> > BTW, the hacking repo starts containing reno since this release but it
> > is not used yet.
> > Please check the git history (or
> > https://review.openstack.org/#/c/343824) if wanting to know the
>  
> Considering that the new check is off-by-default, and since we still have [1] 
> unsolved,  
> what’s the proper procedure to consume the new check? In neutron, we are 
> interested in  
> adopting it because then we would be able to drop our own custom check [2] 
> that validate  
> the code for the same issue. But we cannot use select= in tox.ini.

Flake8 adds an --enable-extensions option that allow you to specify the codes 
for the off-by-default plugins. That can also be added to your tox.ini

--  
Ian Cordasco


__
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] [kolla][release] Version numbers for kolla-ansible repository.

[Jeremy Stanley]

On 2016-11-08 19:07:07 +0530 (+0530), Swapnil Kulkarni wrote:
[...]
> I would love to get inputs from release team, though one of the recent
> repo split I remember is neutron and if I look at the history, old
> tags from git revisions are preserved. I think we can follow the same
> process for kolla and kolla-ansible split.

Yes, one lesson recently learned is that when the repo is imported,
any tags present will trigger release jobs. Odds are you want to
start with just noop jobs for the repo, or at least no jobs for the
pre-release, release or tag pipelines (and then add them after the
import is successful and you've looked it over).
-- 
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] [nova] Follow up on BCN review cadence discussions

[Dan Smith]

> I do imagine, however, that most folks who have been working
> on nova for long enough have a list of domain experts in their heads
> already. Would actually putting that on paper really hurt?

You mean like this?

https://wiki.openstack.org/wiki/Nova#Developer_Contacts

Those are pretty much the people I look to have sign off on a thing I'm
not completely familiar with before approving something. I'm sure it
could use some updating, of course.

This is linked from the MAINTAINERS file in our tree, by the way.

--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] Live migrations: Post-Copy and Auto-Converge features research

[Vlad Nykytiuk]

Daniel,

Thanks for your suggestions. 
Yes, there is a plan to do several more types of research in very similar areas.

Best
—
Vlad

> On Nov 8, 2016, at 12:37, Daniel P. Berrange  wrote:
> 
> On Mon, Nov 07, 2016 at 10:34:39PM +0200, Vlad Nykytiuk wrote:
>> Hi,
>> 
>> As you may know, currently QEMU supports several features that help live
>> migrations to operate more predictively. These features are: auto-converge
>> and post-copy. 
>> I made a research on performance characteristics of these two features, you
>> can find it by the following link:
>> https://rk4n.github.io/2016/08/10/qemu-post-copy-and-auto-converge-features/
>> 
> 
> Thanks for the report, it looks to affirm the results that I've got
> previously that show post-copy as the clear winner, and auto-converge
> a viable alternative if post-copy is not available.
> 
> I've got a few suggestions if you want to do further investigation
> 
> - Look at larger guests - a 1 vCPU guest with 2 GB of RAM is not
>   particularly difficult to migrate when you have 10 Gig-E networking
>   or even 1 Gig-E networking.  4 vCPU with 8 GB of RAM, with  4 guest
>   workers dirtying all 8 GB of RAM is a hard test. Even with autoconverge
>   such guests may not successfully complete in < 5 minutes.
> 
> - Measure the guest CPU performance eg time to write to 1 GB of RAM
>   While auto-converge can ensure completion, it has a really high and
>   prolonged impact on guest CPU performance, much worse than is
>   seen with post-copy.  For example, time to write to 1 GB will degrade
>   from 400 ms/GB, to as much as 7000 ms/GB during post-copy, and this
>   hit may last many minutes. For post-copy, there will be small spikes
>   at the start of each iteration of migration ( 400ms/GB -> 1000ms/GB),
>   and a big spike at the switch over (400ms/GB -> 7000ms/GB), but the
>   duration of the spikes is very short (less than a second), so is a
>   clear winner over auto-converge where the guest CPU performance
>   hit lasts many minutes.
> 
> - Measure the overall CPU utilization of QEMU as a whole. This will
>   show impact of using compression, which is is to burn massive
>   amounts of CPU time in the QEMU migration thread
> 
> I've published by previous results here:
> 
>  
> https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/
> 
> and the framework I used to collect all this data is distributed in
> QEMU git repo now.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
> 
> __
> 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] [requirements][kolla][security] pycrypto vs cryptography

[Gardiner Michael]

Hey Guys,

If FIPS 140-2 compliance is important you might want to look at something
like a PKCS#11 wrapper and let your PKCS#11 complaint module be the deciding
factor in meeting that compliance level.  There are wrappers for most
languages.  (We have our own python p11 implementation tailored to our Luna
HSMs here https://github.com/gemalto/pycryptoki but you should be able to
use a more generic project if you choose)  

There are other commonly used APIs such as OpenSSL, Java JCA/JCE and MS
CAPI/CNG but given that we're talking about python on linux a PKCS #11
approach is probably best.

Beyond just "140-2" there are different levels.  Pure software
implementations are limited to level 1. Level 2, 3, and 4 require hardware
and have more strict requirements as you go up the chain.  Someone asking
for FIPS 140-2 compliance will also generally have a minimum level that they
require.

I do work for a vendor of hardware security modules and so I have biases
towards our solutions but without getting into any of that I do believe if
you want to take FIPS into consideration you should stick to a broadly
adopted crypto API that allows you to switch out the back end module.  

Cheers,

Mike Gardiner
Systems Security Architect
Gemalto

-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: November-06-16 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [requirements][kolla][security] pycrypto vs
cryptography

On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
[...]
> > An orthogonal question I have received from one of our community 
> > members (Pavo on irc) is whether pycrypto (or if we move to
> > cryptography) provide FIPS-140-2 compliance.
> 
> My understanding is that if you need, for example, a FIPS-compliant 
> AES implementation under the hood, then this is dependent more on what 
> backend libraries you're using... e.g., 
> https://www.openssl.org/docs/fips.html
> https://www.openssl.org/docs/fipsvalidation.html

I should clarify, I was referring specifically to pyca/cryptography's
OpenSSL backend. In contrast the pycrypto maintainers seem to have copied
and forked a variety of algorithms (some of which seem to be based NIST/FIPS
reference implementations for C or backports from bits of Py3K stdlib but
have undergone subsequent modification), so very likely have not been put
through any sort of direct compliance validation:
https://github.com/dlitz/pycrypto/blob/master/src/AES.c
https://github.com/dlitz/pycrypto/blob/master/src/SHA512.c
et cetera...
--
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


smime.p7s
Description: S/MIME cryptographic 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] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2016-11-08 08:33:41 -0800:
> On 08/11/16 16:20 +, Hayes, Graham wrote:
> >On 08/11/2016 15:55, Doug Hellmann wrote:
> >> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
> >>> On 08/11/2016 10:30, Thierry Carrez wrote:
>  Ash wrote:
> > [...]
> > Here's another take on the situation. If there are people who genuinely
> > wish to see a CI pipeline that can support something like Go, perhaps
> > you can establish a prerequisite of working with the Infra team on
> > establishing the new pipeline. In my opinion, this seems to be the major
> > gate. So, if there's a clear path identified, resources provided, and
> > the Infra team is ultimately benefitted, then I'm not sure why there
> > should be another rejection. Just a thought. I know this proposal
> > continues to come up and I'm a big fan of seeing other languages
> > supported, especially Go. But I also understand that it can break
> > things. Personally, I would even volunteer to work on such an Infra 
> > effort.
> >
> > BTW, it is quite possible that another group might feel the same
> > constraints. It's perfectly reasonable. But if we can overcome such
> > obstacles, would the TC still have a concern?
> 
>  The TC isn't just one person. In complex situations like this where you
>  have to weigh the trade-off between opening up more choices and our
>  community's ability to digest/survive the change, there will always be a
>  wide variety of opinions. I won't claim to be able to predict how the
>  current membership would vote.
> >>>
> >>> Yup - and the TC could possibly change half, (or even all) its members
> >>> during time it takes to get this work done.
> >>>
>  That said, I think that if we can have more confidence that our
>  structure can handle it (from infra to release/stable/dep management)
>  and that the OpenStack community will share expertise and best practices
>  on Go and avoid reinventing the wheel in every project, I expect a
>  majority of TC members to take that leap of faith.
> >>>
> >>> There was a bit of work done for the previous proposal, but the main
> >>> objections were not to do with any of points raised in this email /
> >>> blog. The objections were mainly cultural - about how it would impact
> >>> the community (which *is* very important), and the exactly why it was
> >>> needed for the projects who were asking.
> >>>
>  To me, the important part is that introducing Go should not be another
>  way for some of our community to be different, but another way for our
>  community to be one. It should do more to bind our community together
>  than to split it into more factions and silos.
> 
> >>>
> >>> I would agree - but I would ask that we find a way forward that does not
> >>> require huge amounts of up front work, for a gamble at the end of the
> >>> process, where the work could be written off for any number of other
> >>> reasons.
> >>>
> >>
> >> I agree that we need to be careful about how much up-front work is
> >> required. A plan to address some of these concerns seems like a
> >> minimum level, with commitment to handle the immediate items like
> >> infra resources for managing those changes. But it's hard to specify
> >> the right levels in the abstract, because so much depends on the
> >> situation, language, and teams involved.
> >>
> >> Doug
> >
> >This. I think trying to define objective rules, procedures, and
> >checklists for what is at the end of the a subjective decision is
> >not a great idea.
> >
> >Should the policy just be "If you want to add a new language, add an
> >item to the TC agenda. They will the discuss the overall proposal, and
> >may ask for more details in the following areas, the use case, or decide
> >that this is not a direction that the community should proceed towards."
> >
> >Or, you know, a well written version of ^.
> 
> This feels a lot like what we have today. I think the set of requirements must
> be written down and clear. The evaluation of the use case should still happen
> and it'd be better for it to happen before the up-front work is done. There 
> will
> always be work to do up front for any new language being added to the 
> community.
> 
> Also, for the evaluation of the use case, it'd be awesome to have the use case
> presented to the mailing list before the item is even added to the TC agenda. 
> I
> liked the review that other members of the community did with the Swift
> proposal.
> 
> Flavio
> 

Right. I like the idea of having a list of expectations for what would
need to be done *eventually* to fully support a new language. Then when
there's a concrete request, the discussion can focus on whether those
things apply and if so what the timing needs to be.

Doug

__
OpenStack Development Mailing 

Re: [openstack-dev] [nova] Follow up on BCN review cadence discussions

[Stephen Finucane]

On Mon, 2016-11-07 at 11:50 +, Matthew Booth wrote:
> I'd like to follow up on the discussions we had in Barcelona around
> review cadence. I took a lot away from these discussions, and I
> thought they were extremely productive. I think the summary of the
> concerns was:
> 
>   Nova is a complex beast, very few people know even most of it well.
>   There are areas of Nova where mistakes are costly and hard to
> rectify later.
>   A large amount of good code does not merge quickly.
>   The pool of active core reviewers is very much smaller than the
> total pool of contributors.
>   The barrier to entry for Nova core is very high.
> 
> There was more, but I think most people agreed on the above.
> 
> Just before summit I pitched a subsystem maintainer model here:
>   http://lists.openstack.org/pipermail/openstack-dev/2016-September/1
> 04093.html
> 
> Reading over this again, I still think this is worth trialling: it
> pushes the burden of initial detailed review further out, whilst
> ensuring that a core will still check that no wider issues have been
> missed. Bearing in mind that the primary purpose is to reduce the
> burden on core reviewers of any individual patch, I think this will
> work best if we aggressively push initial review down as far as
> possible.
> 
> I'm still not sure what the best description of 'domain' is, though.
> Other projects seem to have defined this as: the reviewer should, in
> good faith, know when they're competent to give a +2 and when they're
> not. I suspect this is too loose for us, but I'm sure we could come
> up with something.
> 
> I'd expect the review burden of a maintainer of an active area of
> code to be as heavy as a core reviewer's, so this probably shouldn't
> be taken lightly. If we were to trial it, I'd also recommend starting
> with a small number of maintainers (about 3, perhaps), preferably
> technical-leaders of active sub-teams. Any trial should be the topic
> of a retrospective at the PTG.
> 
> I'd like to re-iterate that what I'd personally like to achieve is:
> 
>   "Good code should merge quickly."
> 
> There are likely other ways to achieve this, and if any of them are
> better than this one then I'm in favour. However, I think we can try
> this one with limited risk and initial up-front effort.

I'm just going to leave this here...

https://github.com/torvalds/linux/blob/master/MAINTAINERS
http://dpdk.org/browse/dpdk/tree/MAINTAINERS

We probably don't want to/can't go down the path of hard subtrees
(though we might be already simulating that with the various 'os-'
projects). I do imagine, however, that most folks who have been working
on nova for long enough have a list of domain experts in their heads
already. Would actually putting that on paper really hurt?

Stephen

__
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] Follow up on BCN review cadence discussions

[Matt Riedemann]

On 11/8/2016 11:39 AM, Dan Smith wrote:

I do imagine, however, that most folks who have been working
on nova for long enough have a list of domain experts in their heads
already. Would actually putting that on paper really hurt?


You mean like this?

https://wiki.openstack.org/wiki/Nova#Developer_Contacts

Those are pretty much the people I look to have sign off on a thing I'm
not completely familiar with before approving something. I'm sure it
could use some updating, of course.

This is linked from the MAINTAINERS file in our tree, by the way.

--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



Right, what Dan said. And yes I have a list of people in my head to look 
at certain things, especially around PCI, Rbd, live migration, xen, 
hyperv, etc. I pull them into reviews regularly when I feel the need. 
That's also an indirect way that I can gauge how some people handle 
reviews, and what they look for, which in turn gets them on my list of 
core candidates, assuming they are actively involved in the project.


I'd also like to say that I dislike the constant comparisons to the 
kernel. If people are going to make that comparison, then let's say the 
kernel overall is all of OpenStack, and there are subsystems, like 
nova/cinder/glance/etc, with their own subsystem maintainers, e.g. 
nova-core.


I'd also like to note that I personally don't think the bar to nova core 
is as high as some people make it out to be. There is a high standard, 
but meeting that standard isn't impossible. For me it means involvement, 
maintenance, willingness to own and fix problems, and helpful code 
reviews. I'll also say I notice people that -1 more often than people 
that +1. That doesn't mean I expect all nova core reviewers to know all 
parts of nova, I certainly don't. We have several cores that mostly only 
review certain parts of the code, the API being a good example. But they 
are definitely experts in that code and own a lot of it, and I trust 
them enough to show restraint when reviewing things they aren't experts 
on (so a +1 maybe, or +2 on obvious changes).


I'll also note that 'good code' is subjective. What someone thinks is a 
worthwhile and useful change might actually break some other part of the 
system, or break under a certain configuration. Obviously we don't have 
100% CI coverage, we never will. And not everyone has all of this in 
their head, that's already been noted. But I don't think it's fair to 
say that just because someone thinks 'this is the greatest thing since 
sliced bread so let's get it in with a single nova-core +2' is the right 
approach. That's my personal opinion.


So I'm still -1 on the subsystem cores idea. I think it would mean 
increased throughput but at the expense of fewer nova-cores reviewing a 
change with hopefully some context of the broader impact of said change.


--

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] [MassivelyDistributed] IRC Meeting postponed

[lebre . adrien]

Dear all, 

We are still looking for a final slot for our bi-weekly IRC meeting and thus we 
have to postpone our first meeting to a date to be determined (hopefully next 
week, i.e. Wednesday Nov the 16th).

I will come back to you with the final time as soon as possible. 

Meanwhile, you can give a look to the agenda (proposal) for this first meeting: 
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2016

Comments/remarks welcome
Best regards, 
ad_rien_

__
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] [release] New hacking 0.12.0

[Ihar Hrachyshka]

> On 8 Nov 2016, at 17:23, Ian Cordasco  wrote:
> 
>  
> 
> -Original Message-
> From: Ihar Hrachyshka 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: November 8, 2016 at 02:39:24
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [release] New hacking 0.12.0
> 
>> 
>>> On 7 Nov 2016, at 21:47, Ken'ichi Ohmichi wrote:
>>> 
>>> Hi,
>>> 
>>> Today a new hacking 0.12.0 is released.
>>> The release contains a new hacking rule:
>>> 
>>> [H904] Delay string interpolations at logging calls.
>>> 
>>> BTW, the hacking repo starts containing reno since this release but it
>>> is not used yet.
>>> Please check the git history (or
>>> https://review.openstack.org/#/c/343824) if wanting to know the
>> 
>> Considering that the new check is off-by-default, and since we still have 
>> [1] unsolved,  
>> what’s the proper procedure to consume the new check? In neutron, we are 
>> interested in  
>> adopting it because then we would be able to drop our own custom check [2] 
>> that validate  
>> the code for the same issue. But we cannot use select= in tox.ini.
> 
> Flake8 adds an --enable-extensions option that allow you to specify the codes 
> for the off-by-default plugins. That can also be added to your tox.ini

Indeed it works, thanks! Here is neutron patch for example: 
https://review.openstack.org/#/c/394817/

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

Re: [openstack-dev] [Congress] Error datasource create

[Tim Hinrichs]

Here's the pertinent error.  It looks like you have a typo in one of your
translators.

2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node InvalidParamException:
Params (field_translators, selector_type) are invalid.  Valid params:
('translation-type', 'table-name', 'parent-key', 'id-col', 'selector-type',
'field-translators', 'in-list', 'parent-col-name', 'objects-extract-fn',
'parent-key-desc')


If you push your Magnum datasource code to review, we can help you more
easily.  Let us know if you need help doing that.  Here's the quickstart
guide.
http://docs.openstack.org/contributor-guide/quickstart/first-timers.html

There are 2 kinds of testing you can do.

1. Run congress and magnum using Devstack (as it seems you're doing).
Manually add a couple of objects to Magnum and manually check that those
objects are showing up in Congress.

2. You can run unit tests on a Linux box with the following commands.
$ cd /path/to/congress
$ tox

You can run specific tests with ...
$ tox -epy34  // just run the Python34 tests
$ tox -epy34 congress.tests.datasources // just run the tests in the
congress/tests/datasources directory
$ tox -epy34 congress.tests.datasources.glancev2_driver  // just run the
tests in the file test_glancev2_driver.py
$ tox -epy34
congress.tests.datasources.glancev2_driver.test_update_from_datasource   //
just run the test_update_from_datasource test

Tim


On Tue, Nov 8, 2016 at 3:26 AM Ruben 
wrote:

> Hi everybody,
> really, I've not been able to create the datasource for magnum.
> Now, I've seen that I've these errors when I restart the congress server..
>
> "ERROR congress.dse2.dse_node [-] Error loading instance of module
> 'congress.datasources.magnum_driver.MagnumDriver'
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node Traceback (most
> recent call last):
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/dse2/dse_node.py", line 841, in
> create_datasource_service
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node service =
> getattr(module, class_name)(**kwargs)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/magnum_driver.py", line 49, in
> __init__
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  super(MagnumDriver, self).__init__(name, args=args)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 1282,
> in __init__
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  super(PollingDataSourceDriver, self).__init__(name, args=args)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 324,
> in __init__
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self.initialize_translators()
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 1324,
> in initialize_translators
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self.register_translator(translator)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 457,
> in register_translator
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self._validate_translator(translator, related_tables)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 446,
> in _validate_translator
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self._validate_by_translation_type(translator, related_tables)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 415,
> in _validate_by_translation_type
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self._get_translator_params(translation_type))
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 1066,
> in check_params
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node raise
> exception.InvalidParamException(err)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
> InvalidParamException: Params (field_translators, selector_type) are
> invalid.  Valid params: ('translation-type', 'table-name', 'parent-key',
> 'id-col', 'selector-type', 'field-translators', 'in-list',
> 'parent-col-name', 'objects-extract-fn', 'parent-key-desc')
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
> 2016-11-08 12:15:29.911 ERROR congress.harness [-] datasource magnum
> creation failed.
> 2016-11-08 12:15:29.911 TRACE congress.harness Traceback (most recent call
> last):
> 2016-11-08 12:15:29.911 TRACE congress.harness   File
> "/opt/stack/congress/congress/harness.py", line 167, in create_datasources
> 2016-11-08 12:15:29.911 TRACE congress.harness  

[openstack-dev] [tripleo] Please review, tripleo ci transition to the quickstart tool set

[Wesley Hayutin]

Greetings,

As discussed at the ocata summit, work is being done to update the set of
tools used in tripleo ci to tripleo-quickstart and
tripleo-quickstart-extras [1-2].  There is work, review, and validation
required prior to the transition.  A draft of the work items is available
[3], please if you have time review the etherpad and respond with any
questions, suggestions or concerns.

Thank you very much!

[1]
https://blueprints.launchpad.net/tripleo/+spec/use-tripleo-quickstart-and-tripleo-quickstart-extras-for-the-tripleo-ci-toolset
[2] https://review.openstack.org/#/c/386250/
[3] https://etherpad.openstack.org/p/tripleo-ci-transition-to-quickstart
__
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] [kolla][release] Version numbers for kolla-ansible repository.

[Doug Hellmann]

Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
> Hey folks,
> 
> As we split out the repository per our unanimous vote several months ago, we 
> have a choice to make (I think, assuming we are given latitude of  the 
> release team who is in the cc list) as to which version to call kolla-ansible.
> 
> My personal preference is to completely retag our newly split repo with all 
> old tags from kolla git revisions up to version 3.0.z.  The main rationale I 
> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think 
> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could 
> do that as well.
> 
> The reason the repository needs to be retagged in either case is to generate 
> release artifacts (tarballs, pypi, etc).
> 
> Would also like feedback from the release team on what they think is a best 
> practice here (we may be breaking new ground for the OpenStack release team, 
> maybe not – is there prior art here?)
> 
> For a diagram (mostly for the release team) of the repository split check out:
> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
> 
> Thanks!
> -steve

When you say "split," I'm going to assume that you mean the
openstack/kolla repo has the full history but that openstack/kolla-ansible
only contains part of the files and their history.

Assuming the history is preserved in openstack/kolla, then I don't
think you want new tags. The way to reproduce the 1, 2, or 3 versions
is to check out the existing tag in openstack/kolla. Having similar
tags in openstack/kolla-ansible will be confusing about which is
the actual tag that produced the build artifacts that were shipped
with those version numbers.  New versions tagged on master in
openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).

Do you maintain stable branches? Are those being kept in openstack/kolla
or openstack/kolla-ansible?

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] [openstack-infra] Please add a initial core member to meteos-core.

[Clark Boylan]

On Mon, Nov 7, 2016, at 11:25 PM, Hiroyuki Eguchi wrote:
> Hello Infra Team.
> 
> I've created new projects named meteos and python-meteosclient.
> Cloud you please add me (Hiroyuki Eguchi )
> as a initial core member of meteos-core ?

Done. Let us know if you have any issues, concerns, or questions.

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

[openstack-dev] [release] change in plan for releases repo data model updates

[Doug Hellmann]

At the summit we said we would move the data that tells us the type
and release model for each deliverable out of the governance
repository and into the releases repository where it is easier to
change over time, but that we needed to think more about what might
break by making that change. After giving it more consideration, I
think we have to use the option 2 we discussed instead (allow local
values to override the global values).

The list-repos command would not be able to filter on the type or
model values early in a cycle because not enough deliverable files
would even exist until the first milestone. That limitation would
make the command essentially useless until close to the end of each
cycle. Using option 2 means list-repos would continue to work all the
time.

Using option 2 also means that instead of us having to do extra
work to build and publish a single unified file for the project
navigator team, they can continue to use the same input data without
changes to their project at all.

I propose adding "type" and "model" fields, as we discussed, but
making them optional. If they are not present, the values can be
derived from the governance tags for the deliverable. Teams who
want to change either value can then make the update in the releases
repository with a separate patch to update the governance repo, and
not have releases blocked by the governance change.

Thoughts?
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] [tc][ux] UX team extra-ATCs expired

[Doug Hellmann]

UX team,

In the process of cleaning up expired ATCs in the governance repository, 
https://review.openstack.org/#/c/388170/ removed all of the names of extra-atcs 
for the UX project. If any of those folks would not otherwise be considered 
ATC, they can be added back with new expiration dates (and new members can also 
be added). Someone from the UX team just needs to propose a patch to 
openstack/governance with updated contact info and expiration dates.

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] [release] New hacking 0.12.0

[Ian Cordasco]

 

-Original Message-
From: Ihar Hrachyshka 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 8, 2016 at 11:19:42
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [release] New hacking 0.12.0

> > On 8 Nov 2016, at 17:23, Ian Cordasco wrote:
> >
> >
> >
> > -Original Message-
> > From: Ihar Hrachyshka  
> > Reply: OpenStack Development Mailing List (not for usage questions)  
> > Date: November 8, 2016 at 02:39:24
> > To: OpenStack Development Mailing List (not for usage questions)  
> > Subject: Re: [openstack-dev] [release] New hacking 0.12.0
> >
> >>
> >>> On 7 Nov 2016, at 21:47, Ken'ichi Ohmichi wrote:
> >>>
> >>> Hi,
> >>>
> >>> Today a new hacking 0.12.0 is released.
> >>> The release contains a new hacking rule:
> >>>
> >>> [H904] Delay string interpolations at logging calls.
> >>>
> >>> BTW, the hacking repo starts containing reno since this release but it
> >>> is not used yet.
> >>> Please check the git history (or
> >>> https://review.openstack.org/#/c/343824) if wanting to know the
> >>
> >> Considering that the new check is off-by-default, and since we still have 
> >> [1] unsolved,  
> >> what’s the proper procedure to consume the new check? In neutron, we are 
> >> interested  
> in
> >> adopting it because then we would be able to drop our own custom check [2] 
> >> that validate  
> >> the code for the same issue. But we cannot use select= in tox.ini.
> >
> > Flake8 adds an --enable-extensions option that allow you to specify the 
> > codes for the  
> off-by-default plugins. That can also be added to your tox.ini
>  
> Indeed it works, thanks! Here is neutron patch for example: 
> https://review.openstack.org/#/c/394817/  

To be fair, the bug you linked to in pycodestyle has also been fixed by the 
rewrite that Flake8 did when it released 3.0. The behaviour you wanted to reach 
for, now just works.

That said, there appear to be some performance regressions in Flake8 itself 
which I'm investigating. Ideally I can get things on the right path again and 
start focusing on updating hacking to take advantage of Flake8 3's new 
features. As I'm but one person, it'll probably take some time. (Especially 
since this all has to happen in my free time.)

--  
Ian Cordasco


__
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] cells v2 ocata summit sessions recap

[Matt Riedemann]

We had two design summit sessions for cells v2 at the Ocata summit in 
Barcelona. The full etherpads are here:


https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-scheduler
https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-quotas

In the first session we mostly talked about the work items needed to 
support multiple cells.


Scheduler interaction
-

Andrew Laski had the spec up for this and there was some POC code 
started, which Dan Smith is picking up. The main idea here is to create 
the BuildRequest in nova-api, then call a new conductor method which 
calls the scheduler to pick a host, and then conductor creates the 
instance in the cell mapped to that host, and then conductor deletes the 
BuildRequest. Once the instance is in that cell, it doesn't move out of 
that cell via reschedule/rebuild/migration/evacuate. We might add 
support for that later, but it's not something supported in the initial 
cells v2 scheduler work.


Cell0
-

Cell0 is the special database (using the same cell DB schema) where 
instances that failed to build go to die. In Newton this was optional 
but the API will pull instances from it when listing instances. However, 
we aren't populating it on schedule failure yet so that's work that 
needs to be done for Ocata. So far there are no patches up for this yet, 
but it will most likely be worked in with the scheduler interaction series.


The listing instances problem
-

In order to list instances we need to be able to page across cells, 
which is going to be expensive for multiple large cells. Long-term we 
want to use searchlight for this, but in the short term we're going to 
do a simple merge sort in python. We also need to get the fixes in to 
restrict the filter/sort keys for listing instances, Alex Xu and Kevin 
Zheng are working on that. There are open questions on the long-term 
plans of how things are going to work with searchlight, and Chris Dent 
said he was interested in working on that. As a start, the searchlight 
team has started reporting bugs against nova for gaps in the 
notifications that nova sends out compared to the REST API. Balazs 
Gibizer (gibi) who runs the notifications subteam in nova has already 
started triaging those bugs.


Testing
---

CI testing the multi-cell configuration should be relatively 
straight-forward with a multinode job. We can have one node contain the 
'control' bits like the API, conductor, scheduler, API/cell0/cell DBs, 
along with a nova-compute service, and then another node that is just 
running nova-compute. I've volunteered to work on that.


Dan and I have also started working on a series of changes to make 
cellsv2 required in the Ocata CI jobs:


https://review.openstack.org/#/q/topic:ocata-requires-cellsv2

This consists of a nova database migration that fails if you haven't 
created the cell0 database and run the simple_cell_setup command.


Upgrade
---

Today in non-cells deployments we say to upgrade conductors first, then 
API and finally computes. With cells v2 we want to do rolling upgrades 
of the cells, which means upgrading conductors and then computes in the 
cells, and finally the API. This allows you to only enable the latest 
features in the API when the cells are all upgraded and ready to handle 
those requests. This poses a bit of a problem for our CI tooling with 
devstack/grenade though as we upgrade and start nova-api first. That's 
going to require some changes as we get into the multi-cell testing 
mentioned above.


Quotas
--

In the second design summit session on cells v2 we spent the entire time 
talking about quotas, and thinking about ways to potentially redo the 
quotas design when moving those to the API database.


Melanie Witt has a spec up which proposes that instead of doing the 
reserve (API), do work, commit/rollback (compute) model, we move commits 
to the API and have a process of (1) do work and then (2) reserve and 
commit.


While talking about that in the session, there was some brainstorming on 
doing limit checks differently in the API. Basically, do away with 
reservations, do a quick DB query to check quota before an operation 
begins, and if it's OK go forward. There will be races as tenants reach 
the end of quota limits, but maybe this is OK. The upside is we 
shouldn't get out of sync (which has been a problem for operators to 
deal with), but there is a potential to race for the last usages which 
might lead to overconsumption of resources.


There are some open questions around the 'fast and loose' approach like 
are there things we need to count which aren't in the API database, and 
can we do this efficiently for things that nova doesn't track in it's 
database, like floating/fixed IPs in neutron?


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [nova] Follow up on BCN review cadence discussions

[Jay Pipes]

On Nov 8, 2016 1:13 PM, "Matt Riedemann"  wrote:
>
> On 11/8/2016 11:39 AM, Dan Smith wrote:
>>>
>>> I do imagine, however, that most folks who have been working
>>> on nova for long enough have a list of domain experts in their heads
>>> already. Would actually putting that on paper really hurt?
>>
>>
>> You mean like this?
>>
>> https://wiki.openstack.org/wiki/Nova#Developer_Contacts
>>
>> Those are pretty much the people I look to have sign off on a thing I'm
>> not completely familiar with before approving something. I'm sure it
>> could use some updating, of course.
>>
>> This is linked from the MAINTAINERS file in our tree, by the way.
>>
>> --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
>>
>
> Right, what Dan said. And yes I have a list of people in my head to look
at certain things, especially around PCI, Rbd, live migration, xen, hyperv,
etc. I pull them into reviews regularly when I feel the need. That's also
an indirect way that I can gauge how some people handle reviews, and what
they look for, which in turn gets them on my list of core candidates,
assuming they are actively involved in the project.
>
> I'd also like to say that I dislike the constant comparisons to the
kernel. If people are going to make that comparison, then let's say the
kernel overall is all of OpenStack, and there are subsystems, like
nova/cinder/glance/etc, with their own subsystem maintainers, e.g.
nova-core.
>
> I'd also like to note that I personally don't think the bar to nova core
is as high as some people make it out to be. There is a high standard, but
meeting that standard isn't impossible. For me it means involvement,
maintenance, willingness to own and fix problems, and helpful code reviews.
I'll also say I notice people that -1 more often than people that +1. That
doesn't mean I expect all nova core reviewers to know all parts of nova, I
certainly don't. We have several cores that mostly only review certain
parts of the code, the API being a good example. But they are definitely
experts in that code and own a lot of it, and I trust them enough to show
restraint when reviewing things they aren't experts on (so a +1 maybe, or
+2 on obvious changes).
>
> I'll also note that 'good code' is subjective. What someone thinks is a
worthwhile and useful change might actually break some other part of the
system, or break under a certain configuration. Obviously we don't have
100% CI coverage, we never will. And not everyone has all of this in their
head, that's already been noted. But I don't think it's fair to say that
just because someone thinks 'this is the greatest thing since sliced bread
so let's get it in with a single nova-core +2' is the right approach.
That's my personal opinion.
>
> So I'm still -1 on the subsystem cores idea. I think it would mean
increased throughput but at the expense of fewer nova-cores reviewing a
change with hopefully some context of the broader impact of said change.

Apologies in advance for the email formatting. I'm writing this from my
phone at an airport..

As I mentioned in Barcelona, I'm supportive of a trial of Mr. Booth's idea
with a commitment to gathering data about total review load, merge velocity
and some kind of metric to assess code quality impact. I think we need to
increase the amount of code being merged in specific areas of the Nova
codebase but recognize the inherent danger of opening things up too quickly
on a highly complex piece of source code.

In short, I'd like to get pre and post data and then give the +2 but not +W
concept a shot and see if things improve with regards to merge velocity in
certain areas.

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] [requirements][kolla][security] pycrypto vs cryptography

[Ian Cordasco]

-Original Message-
From: Rob C 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: November 7, 2016 at 07:39:57
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [requirements][kolla][security] pycrypto
vs cryptography

> Good question, I know issues around this have arisen before.
>
> I think the main points have been covered well already, for my part I will
> always lean toward the better supported or actively developed project.

At this point PyCrypto actively tells users that it's not supported or
developed. They've been pushing people towards Cryptogrpahy.

> I understand the desire to look for FIPS 140-2 compliance, however I'd
> caution about this being the only deciding factor, it makes software
> development messy as only specific implementations can be validated. If you
> want to update code to make improvements etc you can need a whole
> re-validation. I'm not saying that FIPS 140-2 doesn't have value but I know
> of software projects that have used known-bad implementations that had
> certification rather use an updated version with no issues - (like I said,
> it gets messy).
>
> The OpenSSL guys wrote a good article on FIPS validation, how they tackled
> it and some of the impact etc [1]
>
> -Rob
>
> [1] https://www.openssl.org/docs/fipsnotes.html

I would strongly suggest you read Rob's link. It's very enlightening
to know why, while FIPS may be a requirement, it's not necessarily
beneficial from a security standpoint. It's also ridiculously
expensive and restrictive.

I've CC'd one of the lead developers from the Cryptography project to
comment on this. I would hazard a guess that one could compile
Cryptography against a version of OpenSSL that is FIPS compliant, but
I doubt it'll be considered supported. I know Cryptography recently
dropped support for a few older versions of OpenSSL, and to work with
that you'd have to stick to an older version of Cryptography.

Can I ask why FIPS compliance is a requirement for Kolla? This seems
like an odd request for a deployment project.

> On Sun, Nov 6, 2016 at 4:44 PM, Jeremy Stanley wrote:
>
> > On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> > > On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
> > [...]
> > > > An orthogonal question I have received from one of our community
> > > > members (Pavo on irc) is whether pycrypto (or if we move to
> > > > cryptography) provide FIPS-140-2 compliance.
> > >
> > > My understanding is that if you need, for example, a FIPS-compliant
> > > AES implementation under the hood, then this is dependent more on
> > > what backend libraries you're using... e.g.,
> > > https://www.openssl.org/docs/fips.html
> > > https://www.openssl.org/docs/fipsvalidation.html

--
Ian Cordasco

__
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] Registration open for the Project Teams Gathering, Atlanta Feb 20-24, 2017

[Thierry Carrez]

Hi everyone,

The registration is now open for the first OpenStack Project Teams
Gathering event (which will take place in Atlanta, GA the week of
February 20, 2017). This event is geared toward existing upstream team
members, and will provide a venue for those project teams to meet,
discuss and organize the development work for the Pike release.

To learn more about the event (and find the registration link), please
check out the event page at:

http://www.openstack.org/ptg

The event will happen in the Sheraton hotel in downtown Atlanta. You can
find a link to book a room at the event hotel at a discounted rate on
the "Travel" tab in that page. On that same tab you can also find
details about our expanded Travel Support program and a link to apply.

If you have any question, please read the "FAQ" tab of the page! If you
still have questions, feel free to hit me on IRC or over email (or reach
out to foundation staff at p...@openstack.org).

See you there!

-- 
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

Re: [openstack-dev] [all] important changes to pep8 python jobs

[Paul Belanger]

On Thu, Nov 03, 2016 at 12:29:09PM -0400, Paul Belanger wrote:
> Greetings,
> 
> We (openstack-infra) are proposing a change to the current pep8[1] job for
> python jobs, and would like to bring your attention to it.
> 
> We'll be removing the extra-index-url field from pip.conf which forces the job
> to manually build any missing wheels as dependencies.  The reason for this, is
> to force a way for jobs to ensure the proper OS dependencies are installed.
> 
> There is a chance your project pep8 job may break, which is why we are sending
> out this email.  We encourage each project to be using bindep[2], binary
> dependency management tool, to ensure any OS packages are needed. If your
> project needs a specific binary to be installed to compile your project, 
> simply
> add it to the bindep.txt file in your project repo.
> 
> We'll be approving the change on Nov. 16, 2016 and send out another message as
> we move closer to the date.
> 
> If you have any questions, feel free to reply or use #openstack-infra on
> freenode.
> 
Greetings,

A quick reminder that we plan on making this change next week.

It was also suggested we create a job-template[3] for projects who wish to add
an experimental job to test a project. Feel free to propose a change to
project-config and use the 'check experimental' command to run the job.

> ---
> Paul Belanger
> 
> [1] https://review.openstack.org/391875
> [2] http://docs.openstack.org/infra/bindep/
> 

[3] https://review.openstack.org/#/c/395063/

__
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] Follow up on BCN review cadence discussions

[Chris Friesen]

On 11/08/2016 12:13 PM, Matt Riedemann wrote:


I'd also like to say that I dislike the constant comparisons to the kernel. If
people are going to make that comparison, then let's say the kernel overall is
all of OpenStack, and there are subsystems, like nova/cinder/glance/etc, with
their own subsystem maintainers, e.g. nova-core.


While there is some merit to that argument, it's not entirely accurate.  Nova is 
roughly 1/45th the size of the whole kernel source, but the kernel has roughly 
1600 separately-maintained subsystems.  The "arch/x86" subdirectory in the 
kernel source is almost half as big as nova, but there are also 
separately-maintained drivers with only a few hundred lines of code.


Something that was mentioned in the summit discussion (but I think it bears 
repeating) is that the thing that enables this sort of fine-grained 
maintainership in the kernel is that the contracts are better-defined between 
the various subsystems.  Generally a driver has a limited set of things that it 
needs to worry about getting right to interface with the rest of the system, and 
other than that it's got free rein in its own sandbox.


That said, I don't know that there's an easy solution to this in nova due to the 
fact that it's a distributed system with a central shared data store.  Enhancing 
a sched filter might require new data, which means modifying the DB model and 
the DB migrations, and updating the InstanceNUMATopology object and tweaking 
nova-api to request additional attrs, and it might have implications for 
upgrade, etc.


Chris

__
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] [Zun] Zun PTL election

[Hongbin Lu]

Hi all,

As discussed at the last team meeting, the Zun team will have a PTL election. 
Please note the following:
* The electorate for this election are the Foundation individual members that 
are also committers for one of the Zun project teams repositories 
(openstack/zun, openstack/python-zunclient, openstack/zun-ui).
* The electorate is requested to confirm their email address in gerrit, 
review.openstack.org > Settings > Contact Information > Preferred Email, prior 
to November 15, 2016 so that the emailed ballots are mailed to the correct 
email address.
* The election will be scheduled as following:
PTL nomination starts2016-11-15, 00:00 UTC
PTL nomination ends  2016-11-22, 23:45 UTC
PTL elections begins   2016-11-23, 00:00 UTC
PTL elections ends   2016-11-29, 23:45 UTC

After the PTL nomination ends and there are more than one candidates, Tony 
Breeds will hold an election for us (thanks Tony). Please feel free to reply to 
this email if there is any question.

Best regards,
Hongbin
__
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] [new][horizon] django_openstack_auth 2.4.2 release (newton)

[no-reply]

We are tickled pink to announce the release of:

django_openstack_auth 2.4.2: Django authentication backend for use
with OpenStack Identity

This release is part of the newton stable release series.

The source is available from:

http://git.openstack.org/cgit/openstack/django_openstack_auth/

Download the package from:

https://pypi.python.org/pypi/django_openstack_auth

Please report issues through launchpad:

https://bugs.launchpad.net/django-openstack-auth

For more details, please see below.

Changes in django_openstack_auth 2.4.1..2.4.2
-

08e9655 Removing token revoke / delete calls


Diffstat (except docs and test files)
-

openstack_auth/utils.py   |  1 +
openstack_auth/views.py   | 35 +--
3 files changed, 2 insertions(+), 49 deletions(-)




__
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][nova][cinder][horizon][all] properties / metadata for resources

[Matt Riedemann]

On 11/8/2016 7:14 PM, Adrian Turjak wrote:



On 09/11/16 11:12, Gage Hugo wrote:

This spec was discussed at the keystone meeting today and during the
conversation that continued afterwards, an idea of using the keystone
configuration to set a list of keys was mentioned.

The idea is that a cloud admin could define a list of keys that they
need for their setup within keystone's configuration file, then only
those keys will be valid for storing values in the project properties
table.  Then each call would check against the list of valid keys and
deny any calls that are sent with an invalid key.

This idea seems to help with the issue to avoid allowing anyone to
throw any arbitrary values into these project properties vs just a set
number of values.


That feels far more restricting than it needs to be...

If done like this, the list should be optional, as having to restarting
Keystone to register the new config if you decide you need to add
additional values is a terrible approach.

__
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



Agree, whitelisting this in config sounds like a really bad idea.

--

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] cells v2 ocata summit sessions recap

[Matt Riedemann]

On 11/8/2016 7:47 PM, melanie witt wrote:


I think the only resources that are unclear as to whether they are in
the API database are things like cores, ram, etc and I thought these
will end up being represented in the inventories or allocations table
once the resource providers work progresses further. And I didn't think
we need to account for floating/fixed IPs in neutron because we don't
currently track them anyway -- neutron checks quota itself and returns
403 if quota is exceeded.

-melanie



Yup, spot on. I went through some of those resources in the etherpad 
after I wrote this and came to the exact same conclusions. My notes are 
in the etherpad.


Welcome back from the EU, Mel. :)

--

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] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Matt Riedemann]

On 11/8/2016 4:12 PM, Gage Hugo wrote:

This spec was discussed at the keystone meeting today and during the
conversation that continued afterwards, an idea of using the keystone
configuration to set a list of keys was mentioned.

The idea is that a cloud admin could define a list of keys that they
need for their setup within keystone's configuration file, then only
those keys will be valid for storing values in the project properties
table.  Then each call would check against the list of valid keys and
deny any calls that are sent with an invalid key.

This idea seems to help with the issue to avoid allowing anyone to throw
any arbitrary values into these project properties vs just a set number
of values.



So...completely undiscoverable and cloud-specific? That doesn't sound 
very interoperable.


--

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] cells v2 ocata summit sessions recap

[melanie witt]

On Tue, 8 Nov 2016 14:25:08 -0600, Matt Riedemann wrote:

While talking about that in the session, there was some brainstorming on
doing limit checks differently in the API. Basically, do away with
reservations, do a quick DB query to check quota before an operation
begins, and if it's OK go forward. There will be races as tenants reach
the end of quota limits, but maybe this is OK. The upside is we
shouldn't get out of sync (which has been a problem for operators to
deal with), but there is a potential to race for the last usages which
might lead to overconsumption of resources.


Yes, with the counting approach we could have a tenant consume more 
resources than they have quota if racing near the end of quota limits 
(until claims are moved to the API). I think the commit quota 
immediately approach would also prevent getting out of sync but it has 
the downside that some quota reads/writes still have to be initiated by 
the compute host (resize and nova-net fixed_ips). The upside to the 
counting approach is that it eliminates the need to write quota usage 
for a failed resize. The nova-net fixed_ips are still an issue with the 
counting approach too but nova-net is deprecated and we could remove the 
quota read/writes from the compute host for them "soon." The counting 
approach is better than committing quota immediately in that it 
simplifies things a lot and is the only solution that has the potential 
to remove quota reads/writes from the compute host completely.



There are some open questions around the 'fast and loose' approach like
are there things we need to count which aren't in the API database, and
can we do this efficiently for things that nova doesn't track in it's
database, like floating/fixed IPs in neutron?


I think the only resources that are unclear as to whether they are in 
the API database are things like cores, ram, etc and I thought these 
will end up being represented in the inventories or allocations table 
once the resource providers work progresses further. And I didn't think 
we need to account for floating/fixed IPs in neutron because we don't 
currently track them anyway -- neutron checks quota itself and returns 
403 if quota is exceeded.


-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

[openstack-dev] [nova][neutron] When are subnets needed on a network to create ports?

[Matt Riedemann]

I've been looking at this nova bug:

https://bugs.launchpad.net/nova/+bug/1637118

And the neutronv2 API code in nova and need some help from the neutron 
team on how this should actually work.


The validation code that runs from nova-api when creating a server 
checks the requested/available networks to see if they have subnets and 
if not it's a failure. The original change that added that way back in 
icehouse was because you'd get a security group could not be applied 
failure when trying to create ports on a network with port security 
enabled but that didn't have subnets.


Now the code in nova that creates the port, which happens in 
nova-compute, handles this - it only fails if the network doesn't have 
subnets if the network has port security enabled. If the network doesn't 
have port security enabled, we don't care about subnets before creating 
the port.


However, that icehouse-era validation code that happens in the API side 
before casting to the compute is still there, and that's what the bug is 
saying is a problem.


So that sounds like a legitimate issue, but I wanted to get confirmation 
from the neutron team first before moving forward with a fix.


--

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] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Adrian Turjak]

On 09/11/16 11:12, Gage Hugo wrote:
> This spec was discussed at the keystone meeting today and during the
> conversation that continued afterwards, an idea of using the keystone
> configuration to set a list of keys was mentioned.
>
> The idea is that a cloud admin could define a list of keys that they
> need for their setup within keystone's configuration file, then only
> those keys will be valid for storing values in the project properties
> table.  Then each call would check against the list of valid keys and
> deny any calls that are sent with an invalid key.
>
> This idea seems to help with the issue to avoid allowing anyone to
> throw any arbitrary values into these project properties vs just a set
> number of values.

That feels far more restricting than it needs to be...

If done like this, the list should be optional, as having to restarting
Keystone to register the new config if you decide you need to add
additional values is a terrible approach.

__
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] [requirements][kolla][security] pycrypto vs cryptography

[Clint Byrum]

Excerpts from Ian Cordasco's message of 2016-11-08 16:11:26 -0500:
> Can I ask why FIPS compliance is a requirement for Kolla? This seems
> like an odd request for a deployment project.
> 

Guessing it's for the modules that need to communicate securely with
OpenStack itself.

__
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] important changes to pep8 python jobs

[Paul Belanger]

On Tue, Nov 08, 2016 at 02:58:38PM -0500, Paul Belanger wrote:
> On Thu, Nov 03, 2016 at 12:29:09PM -0400, Paul Belanger wrote:
> > Greetings,
> > 
> > We (openstack-infra) are proposing a change to the current pep8[1] job for
> > python jobs, and would like to bring your attention to it.
> > 
> > We'll be removing the extra-index-url field from pip.conf which forces the 
> > job
> > to manually build any missing wheels as dependencies.  The reason for this, 
> > is
> > to force a way for jobs to ensure the proper OS dependencies are installed.
> > 
> > There is a chance your project pep8 job may break, which is why we are 
> > sending
> > out this email.  We encourage each project to be using bindep[2], binary
> > dependency management tool, to ensure any OS packages are needed. If your
> > project needs a specific binary to be installed to compile your project, 
> > simply
> > add it to the bindep.txt file in your project repo.
> > 
> > We'll be approving the change on Nov. 16, 2016 and send out another message 
> > as
> > we move closer to the date.
> > 
> > If you have any questions, feel free to reply or use #openstack-infra on
> > freenode.
> > 
> Greetings,
> 
> A quick reminder that we plan on making this change next week.
> 
> It was also suggested we create a job-template[3] for projects who wish to add
> an experimental job to test a project. Feel free to propose a change to
> project-config and use the 'check experimental' command to run the job.
> 
We've actually went a head and added[4] the experimental job to both python-jobs
and python-db-jobs templates for JJB. So, if your project is using them, you can
now run 'check experimental' to see if pep8 still passes.  If not, this is a
good time to update bindep.txt with the missing dependencies.

> > ---
> > Paul Belanger
> > 
> > [1] https://review.openstack.org/391875
> > [2] http://docs.openstack.org/infra/bindep/
> > 
> 
> [3] https://review.openstack.org/#/c/395063/
> 
[4] https://review.openstack.org/#/c/395157/

__
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] [release] change in plan for releases repo data model updates

[Tony Breeds]

On Tue, Nov 08, 2016 at 12:28:28PM -0500, Doug Hellmann wrote:
> At the summit we said we would move the data that tells us the type
> and release model for each deliverable out of the governance
> repository and into the releases repository where it is easier to
> change over time, but that we needed to think more about what might
> break by making that change. After giving it more consideration, I
> think we have to use the option 2 we discussed instead (allow local
> values to override the global values).
> 
> The list-repos command would not be able to filter on the type or
> model values early in a cycle because not enough deliverable files
> would even exist until the first milestone. That limitation would
> make the command essentially useless until close to the end of each
> cycle. Using option 2 means list-repos would continue to work all the
> time.
> 
> Using option 2 also means that instead of us having to do extra
> work to build and publish a single unified file for the project
> navigator team, they can continue to use the same input data without
> changes to their project at all.
> 
> I propose adding "type" and "model" fields, as we discussed, but
> making them optional. If they are not present, the values can be
> derived from the governance tags for the deliverable. Teams who
> want to change either value can then make the update in the releases
> repository with a separate patch to update the governance repo, and
> not have releases blocked by the governance change.

+1  I like this pass through model.  I know it's a little strange having the TC
"gate" on changes to the release type but I think this works through this
nicely.  The only wart is defining who is responsible for updating the
governance repo when things change in the release repo.  Is it the project team
or the release team?

Yours Tony.


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] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Gage Hugo]

This spec was discussed at the keystone meeting today and during the
conversation that continued afterwards, an idea of using the keystone
configuration to set a list of keys was mentioned.

The idea is that a cloud admin could define a list of keys that they need
for their setup within keystone's configuration file, then only those keys
will be valid for storing values in the project properties table.  Then
each call would check against the list of valid keys and deny any calls
that are sent with an invalid key.

This idea seems to help with the issue to avoid allowing anyone to throw
any arbitrary values into these project properties vs just a set number of
values.

On Sun, Nov 6, 2016 at 6:25 PM, Matt Riedemann 
wrote:

> On 11/4/2016 7:15 PM, Steve Martinelli wrote:
>
>> The keystone team has a new spec being proposed for the Ocata release,
>> it essentially boils down to adding properties / metadata for projects
>> (for now) [1].
>>
>> We have somewhat had support for this, we have an "extras" column
>> defined in our database schema, whatever a user puts in a request that
>> doesn't match up with our API, those key-values are dumped into the
>> "extras" column. It's not a pleasant user experience, since you can't
>> really "unset" the data easily, or grab it, or update it. There's
>> actually been patches to keystoneclient for getting around this, but its
>> rather hacky and hardcodes a lot of values [2] [3]
>>
>> I've added nova and cinder here since the APIs that are being proposed
>> are more or less carbon copies of what is available through their APIs
>> (for server and volumes, respectively). What has been your project's
>> experience with handling metadata / properties? I assume that its been
>> there a while and you can't remove it. If you could go back and redo
>> things, would you do it another way? Would you take a more purist stance
>> and enforce more strict APIs, metadata be damned?
>>
>> I also added horizon because i'm curious about the impact this causes
>> when representing a resource.
>>
>> Personally, I am for the idea, we've had numerous requests from
>> operators about providing this support and I like to make them happy.
>>
>> [1] https://review.openstack.org/#/c/36/
>> [2] https://review.openstack.org/#/c/375239/
>> [3] https://review.openstack.org/#/c/296246/
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> If you're going to do it, restrict the case and characters in the keys
> because if you don't you can get fits in the backend database wrinkles. See
> this nova spec for details:
>
> https://specs.openstack.org/openstack/nova-specs/specs/newto
> n/approved/lowercase-metadata-keys.html
>
> --
>
> 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] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

Thanks Jeremy.

That is a hugely helpful piece of advice.  I will include  a link to your email 
to make sure I’m doing it correctly when I split the repo.

Regards,
-steve






On 11/8/16, 8:24 AM, "Jeremy Stanley"  wrote:

>On 2016-11-08 19:07:07 +0530 (+0530), Swapnil Kulkarni wrote:
>[...]
>> I would love to get inputs from release team, though one of the recent
>> repo split I remember is neutron and if I look at the history, old
>> tags from git revisions are preserved. I think we can follow the same
>> process for kolla and kolla-ansible split.
>
>Yes, one lesson recently learned is that when the repo is imported,
>any tags present will trigger release jobs. Odds are you want to
>start with just noop jobs for the repo, or at least no jobs for the
>pre-release, release or tag pipelines (and then add them after the
>import is successful and you've looked it over).
>-- 
>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] [openstack-infra] Please add a initial core member to meteos-core.

[Hiroyuki Eguchi]

Hi Clark.

> Done. Let us know if you have any issues, concerns, or questions.

Thank you for your help.

Regards,
Hiroyuki


Hiroyuki Eguchi



-Original Message-
From: Clark Boylan [mailto:cboy...@sapwetik.org] 
Sent: Wednesday, November 09, 2016 3:12 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-infra] Please add a initial core member 
to meteos-core.

On Mon, Nov 7, 2016, at 11:25 PM, Hiroyuki Eguchi wrote:
> Hello Infra Team.
> 
> I've created new projects named meteos and python-meteosclient.
> Cloud you please add me (Hiroyuki Eguchi ) as 
> a initial core member of meteos-core ?

Done. Let us know if you have any issues, concerns, or questions.

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

__
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] Weekly neutron-lib meeting canceled

[Henry Gessau]

See https://review.openstack.org/395034

We now have a slot in the main neutron project meeting.

If we do need extra meeting time for neutron-lib we can set up something based
on who wants to attend and when.

__
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] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

On 11/8/16, 9:08 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
>> Hey folks,
>> 
>> As we split out the repository per our unanimous vote several months ago, we 
>> have a choice to make (I think, assuming we are given latitude of  the 
>> release team who is in the cc list) as to which version to call 
>> kolla-ansible.
>> 
>> My personal preference is to completely retag our newly split repo with all 
>> old tags from kolla git revisions up to version 3.0.z.  The main rationale I 
>> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think 
>> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could 
>> do that as well.
>> 
>> The reason the repository needs to be retagged in either case is to generate 
>> release artifacts (tarballs, pypi, etc).
>> 
>> Would also like feedback from the release team on what they think is a best 
>> practice here (we may be breaking new ground for the OpenStack release team, 
>> maybe not – is there prior art here?)
>> 
>> For a diagram (mostly for the release team) of the repository split check 
>> out:
>> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
>> 
>> Thanks!
>> -steve
>
>When you say "split," I'm going to assume that you mean the
>openstack/kolla repo has the full history but that openstack/kolla-ansible
>only contains part of the files and their history.

Doug,

I’d like to maintain history for both the repos, and then selectively remove 
the stuff not neeeded for each repo (so they will then diverge).

>
>Assuming the history is preserved in openstack/kolla, then I don't
>think you want new tags. The way to reproduce the 1, 2, or 3 versions
>is to check out the existing tag in openstack/kolla. Having similar
>tags in openstack/kolla-ansible will be confusing about which is
>the actual tag that produced the build artifacts that were shipped
>with those version numbers.  New versions tagged on master in
>openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).

Ok that works.  I think the lesson there is we can’t change the past :)  I 
think we would want kolla-ansible 

>
>Do you maintain stable branches? Are those being kept in openstack/kolla
>or openstack/kolla-ansible?
Great question and something I hadn’t thought of.

Yes we maintain stable branches for liberty, mitaka, and newton.  I’m not sure 
if a stable branch for liberty is in policy for OpenStack.  Could you advice 
here?

I believe the result we want is to maintain the stable branches for 
liberty/mitaka/newton in kolla and then tag kolla-ansible Ocata as 4.0.0.  I 
don’t know if we need the 1/2/3 tags deleted in this case.  Could you advise?

Thanks for your help and contributions Doug :)

Regards
-steve

>
>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] Anyone want to meetup at KubeCon?

[Stephen McQuaid]

We have been developing a keystone authz webhook for easy integration.  If 
anyone is interested we can look at open-sourcing it

Stephen McQuaid
Sr. Software Engineer | Kubernetes & Openstack
GoDaddy

M: 484.727.8383 | O: 669.600.5852
smcqu...@godaddy.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

Re: [openstack-dev] [requirements][kolla][security] pycrypto vs cryptography

[Steven Dake (stdake)]

Ok,

Pavo has told me he has exceptions in place for everything related to Kolla.  
He says as long as we don’t use MD5, he is good to go for a 232 node deploy 
with more to follow (assuming Kolla works out of the box at that scale - we 
have only tested 123 node scale).

We do some basic PRNG to generate passwords, and some PKCS#11 (iirc) algos to 
generate passwords, and we also generate some ssh public/private keys.

Hope the security context helps.

Thanks everyone on his thread for providing guidance.  RobC++ on article.

Regards
-steve




On 11/8/16, 1:46 PM, "Clint Byrum"  wrote:

>Excerpts from Ian Cordasco's message of 2016-11-08 16:11:26 -0500:
>> Can I ask why FIPS compliance is a requirement for Kolla? This seems
>> like an odd request for a deployment project.
>> 
>
>Guessing it's for the modules that need to communicate securely with
>OpenStack itself.
>
>__
>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] [requirements][kolla][security] pycrypto vs cryptography

[Dave Walker]

Hey Steve,

All of the credential generation is optional right?  I mean, as far as
kolla is concerned - it doesn't *need* to generate the passwords... If
/etc/kolla/passwords.yml is created outside of kolla-genpwd, then kolla
isn't creating any credentials itself and the algorithm, entropy and policy
is transparent to kolla.

On 8 November 2016 at 21:50, Steven Dake (stdake)  wrote:

> Ok,
>
> Pavo has told me he has exceptions in place for everything related to
> Kolla.  He says as long as we don’t use MD5, he is good to go for a 232
> node deploy with more to follow (assuming Kolla works out of the box at
> that scale - we have only tested 123 node scale).
>
> We do some basic PRNG to generate passwords, and some PKCS#11 (iirc) algos
> to generate passwords, and we also generate some ssh public/private keys.
>
> Hope the security context helps.
>
> Thanks everyone on his thread for providing guidance.  RobC++ on article.
>
> Regards
> -steve
>
>
>
>
> On 11/8/16, 1:46 PM, "Clint Byrum"  wrote:
>
> >Excerpts from Ian Cordasco's message of 2016-11-08 16:11:26 -0500:
> >> Can I ask why FIPS compliance is a requirement for Kolla? This seems
> >> like an odd request for a deployment project.
> >>
> >
> >Guessing it's for the modules that need to communicate securely with
> >OpenStack itself.
> >
> >___
> ___
> >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] [Horizon] [Keystone] Inaugural weekly cross-project meeting summary

[Richard Jones]

Hi folks,

Today we had the first of what will be a regular cross-project meeting
series for Horizon and Keystone developers[1].

It was a very productive meeting, and we resolved to continue to keep
our ongoing notes and status summaries in the etherpad[2] while still
ensuring that BPs or bugs cover the actual work being done.

The new, official timeslot will be Thursday at 2000 UTC[3]


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon_keystone/2016/horizon_keystone.2016-11-08-20.01.html
[2] https://etherpad.openstack.org/p/ocata-keystone-horizon
[3] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

__
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][nova][cinder][horizon][all] properties / metadata for resources

[gordon chung]

On 04/11/16 08:15 PM, Steve Martinelli wrote:
>
> We have somewhat had support for this, we have an "extras" column
> defined in our database schema, whatever a user puts in a request that
> doesn't match up with our API, those key-values are dumped into the
> "extras" column. It's not a pleasant user experience, since you can't
> really "unset" the data easily, or grab it, or update it. There's
> actually been patches to keystoneclient for getting around this, but its
> rather hacky and hardcodes a lot of values [2] [3]

we've been storing metadata/attributes/properties in Ceilometer and 
Gnocchi. in Ceilometer, we just flattened the json and built keys based 
on that which allowed you to index and unset/set things. that said, it 
wasn't that great in Ceilometer because allowing it to be completely 
free-form just encouraged the practice of dumping useless information in it.

in Gnocchi, we support dynamically addign attributes as well but you 
must explicitly tell it to create add the attribute to the resource. i 
won't lie, i don't know exactly how the magic works (you'll have to ask 
sileht), but it basically creates columns/tables to the db based on the 
request.

cheers,
-- 
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] [nova][neutron] When are subnets needed on a network to create ports?

[Armando M.]

On 8 November 2016 at 18:35, Matt Riedemann 
wrote:

> I've been looking at this nova bug:
>
> https://bugs.launchpad.net/nova/+bug/1637118
>
> And the neutronv2 API code in nova and need some help from the neutron
> team on how this should actually work.
>

If I am not mistaken [1] is what we'd need on the nova side.

As for neutron, we implemented [2], which can be leveraged by [1] in order
to implement the non-backward compatible behavior of lifting the constraint
check should a port be required without an address.

Mind you, I said port intentionally, meaning that even with [1], bug
1637118 would still manifest itself (in other words, it would be the
expected behavior). Booting off unaddressed VMs is an advanced use case and
as such it requires to boot by specifying the port ID.

[1] https://blueprints.launchpad.net/neutron/+spec/vm-without-l3-address
[2] https://blueprints.launchpad.net/nova/+spec/vm-boot-with-
unaddressed-port



> The validation code that runs from nova-api when creating a server checks
> the requested/available networks to see if they have subnets and if not
> it's a failure. The original change that added that way back in icehouse
> was because you'd get a security group could not be applied failure when
> trying to create ports on a network with port security enabled but that
> didn't have subnets.
>
> Now the code in nova that creates the port, which happens in nova-compute,
> handles this - it only fails if the network doesn't have subnets if the
> network has port security enabled. If the network doesn't have port
> security enabled, we don't care about subnets before creating the port.
>
> However, that icehouse-era validation code that happens in the API side
> before casting to the compute is still there, and that's what the bug is
> saying is a problem.
>
> So that sounds like a legitimate issue, but I wanted to get confirmation
> from the neutron team first before moving forward with a fix.
>
> --
>
> 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] [Magnum] New Core Reviewers

[Kumari, Madhuri]

+1 for both.

-Original Message-
From: Adrian Otto [mailto:adrian.o...@rackspace.com] 
Sent: Tuesday, November 8, 2016 12:36 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Magnum] New Core Reviewers

Magnum Core Team,

I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum Core 
Reviewers. Please respond with your votes.

Thanks,

Adrian Otto
__
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] [all] Embracing new languages in OpenStack

[Ash]

On Tue, Nov 8, 2016 at 2:27 AM, Thierry Carrez 
wrote:

> Ash wrote:
> > [...]
> > Here's another take on the situation. If there are people who genuinely
> > wish to see a CI pipeline that can support something like Go, perhaps
> > you can establish a prerequisite of working with the Infra team on
> > establishing the new pipeline. In my opinion, this seems to be the major
> > gate. So, if there's a clear path identified, resources provided, and
> > the Infra team is ultimately benefitted, then I'm not sure why there
> > should be another rejection. Just a thought. I know this proposal
> > continues to come up and I'm a big fan of seeing other languages
> > supported, especially Go. But I also understand that it can break
> > things. Personally, I would even volunteer to work on such an Infra
> effort.
> >
> > BTW, it is quite possible that another group might feel the same
> > constraints. It's perfectly reasonable. But if we can overcome such
> > obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.
>
> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.
>
> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

I couldn't agree more. I don't like change for the sake of change (in any
aspect of my life). So in my mind this would have to be a way to better
bind us.

>
> --
> 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] [Horizon] Meeting at 20:00 UTC this Wednesday, 9nd November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 9nd November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

Richard
__
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] Do we have users of CryptsetupEncryptor and if so why?

[Lee Yarwood]

On 07-11-16 17:42:02, Lee Yarwood wrote:
> Hello all,
> 
> The following bug was recently discovered where encrypted volumes
> created prior to Newton use a slightly mangled passphrase :
> 
> The passphrase used to encrypt or decrypt volumes was mangled prior to Newton
> https://launchpad.net/bugs/1633518
> 
> This is currently being resolved for LUKS based volumes in the following
> change with the incorrect passphrase being removed and replaced :
> 
> encryptors: Workaround mangled passphrases
> https://review.openstack.org/#/c/386670/
> 
> Unfortunately we can't do the same for volumes using the plain format
> provided by the CryptsetupEncryptor class. While the above change does
> include a workaround it would be better if we could deprecate this
> format and encryptor for new volumes ASAP and move everyone to LUKS etc.
> 
> Before deprecating CryptsetupEncryptor I wanted to ask this list if we
> have any active users of this encryptor and if so why is it being used?
> Is there a specific use case where plain is better than LUKS and thus
> needs to stay around?
> 
> Thanks in advance,
> 
> Lee

CC'ing openstack-dev for some additional feedback.

-- 
Lee Yarwood
Senior Software Engineer
Red Hat

PGP : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

__
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] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

Thanks
__
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] consistency groups in ceph

[yang, xing]

You cannot remove a volume completely if there is still a group snapshot.  You 
can remove the volume from the group but you can’t delete the volume because it 
still has snapshot dependent on it.  So if you want to completely remove a 
volume that is in a group, you can delete the group snapshot first which will 
delete the individual snapshot.  After that you can remove the volume from the 
group and delete the volume.

More comments inline below.

Thanks,
Xing



From: Victor Denisov [vdeni...@mirantis.com]
Sent: Tuesday, November 8, 2016 12:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

One more question. What is the expected behavior if you remove a
volume completely?
[Xing] You cannot remove the volume completely (delete volume won't succeed) if 
there is still a group snapshot.

Should the group snapshot removed first? Should the volume snapshot be
removed from the group snapshot?
[Xing] Yes, you should delete the group snapshot first and that will delete the 
volume snapshot as well.

Should we keep the snapshot even if the image doesn't exist anymore?
[Xing] You cannot delete the image (volume) if there is still a snapshot.

Thanks,
Victor.

On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
> Hi Victor,
>
> Please see my answers inline below.
>
> In Newton, we added support for Generic Volume Groups.  See doc below.  CGs 
> will be migrated to Generic Volume Groups gradually.  Drivers should not 
> implement CGs any more.  Instead, it can add CG support using Generic Volume 
> Group interfaces.  I'm working on a dev doc to explain how to do this and 
> will send an email to the mailing list when I'm done.  The Generic Volume 
> Group interface is very similar to CG interface, except that the Generic 
> Volume Group requires an additional Group Type parameter to be created.  
> Using Group Type, CG can be a special type of Generic Volume Group.  Please 
> feel free to grab me on Cinder IRC if you have any questions.  My IRC handle 
> is xyang or xyang1.
>
> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Monday, October 31, 2016 11:29 PM
> To: openstack-dev@lists.openstack.org
> Cc: Jason Dillaman
> Subject: [openstack-dev] [cinder] consistency groups in ceph
>
> Hi,
>
> I'm working on consistency groups feature in ceph.
> My question is about what kind of behavior does cinder expect from
> storage backends.
> I'm particularly interested in what happens to consistency groups
> snapshots when I remove an image from the group:
>
> Let's imagine I have a consistency group called CG. I have images in
> the consistency group:
> Im1, Im2, Im3, Im4.
> Let's imagine we have snapshots of this consistency group:
>
> CGSnap1
> CGSnap2
> CGSnap3
>
> Snapshots of individual images in a consistency group snapshot I will call
> CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.
>
> Qustion 1:
> If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
> Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.
>
> Can CGSnap1 have less images than it already has: Im1, Im2, Im3.
>
> [Xing]  Once a snapshot is taken from a CG, it can no longer be changed.  It 
> is a point-in-time copy.  CGSnap1 cannot be modified.
>
> Question 2:
> If we remove image2 from the consistency group. Does it mean that
> snapshots of this image should be removed from all the CGSnaps.
>
> Example:
> We are removing Im2.
> CGSnaps look like this:
>
> CGSnap1 - CGSnap1Im1, CGSnap1Im2, CGSnap1Im3
> CGSnap2 - CGSnap2Im1, CGSnap2Im2, CGSnap2Im3, CGSnap3Im4
> CGSnap3 - CGSnap3Im1, CGSnap3Im2, CGSnap3Im3, CGSnap3Im4
>
> What happens to snapshots: CGSnap1Im2,CGSnap2Im2, CGSnap3Im2? Do we
> remove them, do we keep them. Is it important what we do to them at
> all?
>
> [Xing] If your CG contains 4 volumes when you take the snapshot of the CG, 
> the resulting CGSnap should be associated with 4 snapshots corresponding to 
> the 4 volumes.  If you add more volumes to the CG or remove volumes from CG 
> after CGSnap was taken, it should not affect CGSnap.  It will only affect CG 
> snapshots that you take in the future.
>
> Thanks,
> Victor.
>
> __
> 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] [Browbeat] Nominate Justin Kilpatrick as core.

[Sindhur Malleni]

+1. I think Justin's done some awesome work and would be a great addition
to the core team. Better get reviewing some patches Justin! ;)

On Fri, Oct 28, 2016 at 10:28 AM, Joe Talerico  wrote:

> Justin has been doing a great deal of work on the Browbeat-CI and
> stabilizing our code.
>
> I would like to nominate Justin as our first core who didn't begin as
> a core to the project!
>
> Joe
>



-- 
Sai Sindhur Malleni
Software Engineer
Red Hat Inc.
100 East Davie Street
Raleigh, NC, USA
Work: (919) 754-4557 | Cell: (919) 985-1055
__
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] [mistral] Promoting Dougal Matthews to the core team

[Renat Akhmerov]

Ok, thank you all!

Dougal, welcome to the core team! I’m hoping for fruitful collaboration with 
you :)

Renat Akhmerov
@Nokia

> On 8 Nov 2016, at 17:18, Anastasia Kuznetsova  
> wrote:
> 
> +1 from my side!
> 
> On Tue, Nov 8, 2016 at 11:34 AM, Gershenzon, Michal (Nokia - IL) 
> > wrote:
> +1
> 
> J
> 
>  
> 
> Michal Gershenzon
> Software Engineer, CloudBand
> Application & Analytics , Nokia
> Contact number: +972 9 793 3163
> 
>  
> 
> From: Deja, Dawid [mailto:dawid.d...@intel.com ] 
> Sent: Tuesday, November 08, 2016 10:21 AM
> To: openstack-dev@lists.openstack.org 
> 
> Subject: Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core 
> team
> 
>  
> 
> +1
> 
>  
> 
> It's good to have you on board Dougal!
> 
>  
> 
> Dawid Deja
> 
>  
> 
> On Tue, 2016-11-08 at 19:46 +1300, Lingxian Kong wrote:
> 
> +1 of course!
> 
> 
> 
> 
> Cheers,
> Lingxian Kong (Larry)
> 
>  
> 
> On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov  > wrote:
> 
> 
> Hi,
> 
>  
> 
> I’d like to promote Dougal Matthews to the Mistral core team. [1] shows 
> Dougal’s Mistral contribution summary for Newton cycle.
> 
>  
> 
> Here are the reasons why I would like to see Dougal in the core team:
> 
> He reviews a lot and provides valuable comments, especially when it comes to 
> discussing design of the new features
> He sent 18 patches in Newton cycle which may not be a big number but it was 
> his first full cycle in Mistral and I believe he can do more
> He is one of the most active team members in general and in IRC specifically, 
> always open for communication and easy to talk to
> He is an active user of Mistral which is very important for me since he’s 
> capable of providing valuable practical feedback on design, usability, 
> reliability etc.
> He seems to be very excited about working on Mistral
>  
> 
> Besides that I believe Dougal makes a good friendly atmosphere in our 
> development team daily in our IRC channel and our weekly IRC meetings.
> 
>  
> 
> Team, I would ask you to support me in this promotion.
> 
>  
> 
> Thanks
> 
>  
> 
> [1] 
> http://stackalytics.com/?module=mistral-group_id=d0ugal=newton=marks
>  
> 
>  
> 
> Renat Akhmerov
> 
> @Nokia
> 
>  
> 
> 
> __
> 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 
> 
> 
> 
> 
> 
> -- 
> Best regards,
> Anastasia Kuznetsova
> __
> 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] [mistral] Promoting Dougal Matthews to the core team

[Deja, Dawid]

+1

It's good to have you on board Dougal!

Dawid Deja

On Tue, 2016-11-08 at 19:46 +1300, Lingxian Kong wrote:
+1 of course!


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov 
> wrote:
Hi,

I’d like to promote Dougal Matthews to the Mistral core team. [1] shows 
Dougal’s Mistral contribution summary for Newton cycle.

Here are the reasons why I would like to see Dougal in the core team:

  *   He reviews a lot and provides valuable comments, especially when it comes 
to discussing design of the new features
  *   He sent 18 patches in Newton cycle which may not be a big number but it 
was his first full cycle in Mistral and I believe he can do more
  *   He is one of the most active team members in general and in IRC 
specifically, always open for communication and easy to talk to
  *   He is an active user of Mistral which is very important for me since he’s 
capable of providing valuable practical feedback on design, usability, 
reliability etc.
  *   He seems to be very excited about working on Mistral

Besides that I believe Dougal makes a good friendly atmosphere in our 
development team daily in our IRC channel and our weekly IRC meetings.

Team, I would ask you to support me in this promotion.

Thanks

[1] 
http://stackalytics.com/?module=mistral-group_id=d0ugal=newton=marks

Renat Akhmerov
@Nokia


__
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] [release] New hacking 0.12.0

[Ihar Hrachyshka]

> On 7 Nov 2016, at 21:47, Ken'ichi Ohmichi  wrote:
> 
> Hi,
> 
> Today a new hacking 0.12.0 is released.
> The release contains a new hacking rule:
> 
> [H904] Delay string interpolations at logging calls.
> 
> BTW, the hacking repo starts containing reno since this release but it
> is not used yet.
> Please check the git history (or
> https://review.openstack.org/#/c/343824) if wanting to know the

Considering that the new check is off-by-default, and since we still have [1] 
unsolved, what’s the proper procedure to consume the new check? In neutron, we 
are interested in adopting it because then we would be able to drop our own 
custom check [2] that validate the code for the same issue. But we cannot use 
select= in tox.ini.

[1] https://github.com/PyCQA/pycodestyle/issues/390
[2] https://review.openstack.org/#/c/394817/2/neutron/hacking/checks.py

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] [nova] hierarchy quota spec

[Andrey Volkov]

Hi,

I'd like community to look at hierarchy quota spec [1].
It uses a little different approach than previously proposed nested quota
spec [2]
and allows quota overbooking thing. I think it's possible to do this in
parallel with
cells-quota-api-db spec [3].

I'd happy to get some comments and suggestions about it.
There is PoC [3] for this spec where code can be viewed.

[1] https://review.openstack.org/#/c/394422/
[2]
https://review.openstack.org/#/c/160605/3/specs/liberty/approved/nested-quota-driver-api.rst
[3]
http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/ocata/approved/cells-quota-api-db.rst
[4] https://review.openstack.org/#/c/391072/

-- 
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

Re: [openstack-dev] [Openstack-operators] [MassivelyDistributed] bi-weekly meeting

[Thierry Carrez]

Thierry Carrez wrote:
> [...]
> That said, it's a balancing act and we may be past the point when
> scheduling pain takes over the need to spread meetings out. I'll do a
> quick pass to try to free up slots taken by dead meetings, and if we
> can't free enough slots we'll likely add a new meeting channel.

I did a quick pass and proposed to remove 6 meetings that happen in
heavily-demanded slots but did not occur for the last 3 months (or more):

https://review.openstack.org/#/q/topic:nov2016-cleanup

With those gone I would argue we don't need to add another meeting room.

-- 
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

Re: [openstack-dev] [Congress] Run unit test

[Ruben]

Hi everybody,
I've been able to restart the congress server, add the driver for magnum and 
create a datasource.
Now, how can I run the unit test for this driver? Which steps have I to do?

Ruben

- Messaggio originale -
Da: "Ruben" 
A: "Eric" 
Cc: openstack-dev@lists.openstack.org
Inviato: Domenica, 6 novembre 2016 17:48:24
Oggetto: Re: [openstack-dev] [Congress] Restart Congress server

Hi Eric,
also with the old congress.conf file there is the error.
I've used devstack with a single-process congress deployment.

To stop the congress server I make: screen -x stack and Ctrl-C in the congress 
window.
To restart the congress server I make: screen -x stack and sudo 
/usr/local/bin/congress-server --debug in the congress window.

Is it possible that I should rejoin the stack?

Ruben

- Original Message -
From: "Eric" 
To: openstack-dev@lists.openstack.org
Cc: "Ruben" 
Sent: Friday, November 4, 2016 7:23:50 PM
Subject: Re: [Congress] Restart Congress server

Hi Ruben,

Awesome to hear about your progress!

The error seems to be independent of adding a new driver.

Could you try using the unchanged congress.conf and restarting again to
see if the same problem shows up?

Also, could you give the command you¹re using the launch congress-server?

Mainly I want to understand whether you¹re using single-process congress
deployment or multi-process congress deployment. If multi-process, it¹s
possible that the datasources process was stopped but wasn¹t restarted.


If your screen listing (access by pressing Ctrl-A followed by ") shows
three congress windows like this, then you¹re running in multi-process
mode:
29 congress-api
$(L)
  30 congress-engine
  $(L)
  31 congress-datasources
  $(L)

To launch Congress, make sure all three are running properly.

A simpler alternative (but takes some time) is to deploy devstack from
scratch (saving your work somewhere of course) using the latest versions
(defaults to single process), which should reduce complications from
multiple processes and make everything easier for dev-testing.

All the best!



On 11/4/16, 4:53 AM, "Ruben"  wrote:

>Hi everyone,
>I've tried to write a datasource driver for Magnum and the unit test for
>it.
>So I've add this datasource driver in
>/opt/stack/congress/congress/datasources/ and the unit test in
>/opt/stack/congress/congress/tests/datasources/ to test it.
>Moreover, I've add the driver to /etc/congress/congress.conf, but when I
>try to restart Congress server I've some errors.
>
>
>"2016-11-04 12:13:00.390 TRACE congress.service self.service_id,
>service, table)
>2016-11-04 12:13:00.390 TRACE congress.service   File
>"/opt/stack/congress/congress/dse2/dse_node.py", line 468, in
>subscribe_table
>2016-11-04 12:13:00.390 TRACE congress.service {'table': table})
>2016-11-04 12:13:00.390 TRACE congress.service   File
>"/opt/stack/congress/congress/dse2/dse_node.py", line 355, in
>invoke_service_rpc
>2016-11-04 12:13:00.390 TRACE congress.service raise
>exception.NotFound(msg % service_id)
>2016-11-04 12:13:00.390 TRACE congress.service NotFound: service 'nova'
>could not be found
>2016-11-04 12:13:00.390 TRACE congress.service
>2016-11-04 12:13:00.537 DEBUG oslo_concurrency.lockutils [-] Acquired
>semaphore "singleton_lock" from (pid=24411) lock
>/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:212
>2016-11-04 12:13:00.538 DEBUG oslo_concurrency.lockutils [-] Releasing
>semaphore "singleton_lock" from (pid=24411) lock
>/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225"
>
>I don't know what to do to solve it and even if the driver I've written
>works.
>Maybe I make mistakes when I restart Congress server..
>What should I do to restart Congress server?
>What could I do to test the datasource and solve these problems?
>
>Ruben

__
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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Lingxian Kong]

thanks very much for the update!


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 12:36 PM, Michael Johnson 
wrote:

> Ocata LBaaS retrospective and next steps recap
> --
>
> This session lightly touched on the work in the newton cycle, but
> primarily focused on planning for the Ocata release and the LBaaS spin
> out of neutron and merge into the octavia project [1].  Notes were
> captured on the etherpad [1].
>
> The focus of work for Ocata in neutron-lbaas and octavia will be on
> the spin out/merge and not new features.
>
> Work has started on merging neutron-lbaas into the octavia project
> with API sorting/pagination, quota support, keystone integration,
> neutron-lbaas driver shim, and documentation updates.  Work is still
> needed for policy support, the API shim to handle capability gaps
> (example: stats are by listener in octavia, but by load balancer in
> neturon-lbaas), neutron api proxy, a database migration script from
> the neutron database to the octavia database for existing non-octavia
> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to
> the octavia API server.
>
> The room agreed that since we will have a shim/proxy in neutron for
> some time, updating the OpenStack client can be deferred to a future
> cycle.
>
> There is a lot of concern about Ocata being a short cycle and the
> amount of work to be done.  There is hope that additional resources
> will help out with this task to allow us to complete the spin
> out/merge for Ocata.
>
> We discussed the current state of the active/active topology patches
> and agreed that it is unlikely this will merge in Ocata.  There are a
> lot of open comments and work to do on the patches.  It appears that
> these patches may have been created against an old release and require
> significant updating.
>
> Finally there was a question about when octavia would implement
> metadata tags.  When we dug into the need for the tags we found that
> what was really wanted is a full implementation of the flavors
> framework [3] [4].  Some vendors expressed interest in finishing the
> flavors framework for Octavia.
>
> Thank you to everyone that participated in our design session and etherpad.
>
> Michael
>
> [1] https://specs.openstack.org/openstack/neutron-specs/specs/
> newton/kill-neutron-lbaas.html
> [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session
> [3] https://specs.openstack.org/openstack/neutron-specs/specs/
> mitaka/neutron-flavor-framework-templates.html
> [4] https://specs.openstack.org/openstack/neutron-specs/specs/
> liberty/neutron-flavor-framework.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
>
__
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] Live migrations: Post-Copy and Auto-Converge features research

[Daniel P. Berrange]

On Mon, Nov 07, 2016 at 10:34:39PM +0200, Vlad Nykytiuk wrote:
> Hi,
> 
> As you may know, currently QEMU supports several features that help live
> migrations to operate more predictively. These features are: auto-converge
> and post-copy. 
> I made a research on performance characteristics of these two features, you
> can find it by the following link:
> https://rk4n.github.io/2016/08/10/qemu-post-copy-and-auto-converge-features/
> 

Thanks for the report, it looks to affirm the results that I've got
previously that show post-copy as the clear winner, and auto-converge
a viable alternative if post-copy is not available.

I've got a few suggestions if you want to do further investigation

 - Look at larger guests - a 1 vCPU guest with 2 GB of RAM is not
   particularly difficult to migrate when you have 10 Gig-E networking
   or even 1 Gig-E networking.  4 vCPU with 8 GB of RAM, with  4 guest
   workers dirtying all 8 GB of RAM is a hard test. Even with autoconverge
   such guests may not successfully complete in < 5 minutes.

 - Measure the guest CPU performance eg time to write to 1 GB of RAM
   While auto-converge can ensure completion, it has a really high and
   prolonged impact on guest CPU performance, much worse than is
   seen with post-copy.  For example, time to write to 1 GB will degrade
   from 400 ms/GB, to as much as 7000 ms/GB during post-copy, and this
   hit may last many minutes. For post-copy, there will be small spikes
   at the start of each iteration of migration ( 400ms/GB -> 1000ms/GB),
   and a big spike at the switch over (400ms/GB -> 7000ms/GB), but the
   duration of the spikes is very short (less than a second), so is a
   clear winner over auto-converge where the guest CPU performance
   hit lasts many minutes.

 - Measure the overall CPU utilization of QEMU as a whole. This will
   show impact of using compression, which is is to burn massive
   amounts of CPU time in the QEMU migration thread

I've published by previous results here:

  
https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/

and the framework I used to collect all this data is distributed in
QEMU git repo now.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [mistral] Promoting Dougal Matthews to the core team

[Gershenzon, Michal (Nokia - IL)]

+1
☺

Michal Gershenzon
Software Engineer, CloudBand
Application & Analytics , Nokia
Contact number: +972 9 793 3163

From: Deja, Dawid [mailto:dawid.d...@intel.com]
Sent: Tuesday, November 08, 2016 10:21 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core 
team

+1

It's good to have you on board Dougal!

Dawid Deja

On Tue, 2016-11-08 at 19:46 +1300, Lingxian Kong wrote:
+1 of course!


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov 
> wrote:

Hi,

I’d like to promote Dougal Matthews to the Mistral core team. [1] shows 
Dougal’s Mistral contribution summary for Newton cycle.

Here are the reasons why I would like to see Dougal in the core team:

  *   He reviews a lot and provides valuable comments, especially when it comes 
to discussing design of the new features
  *   He sent 18 patches in Newton cycle which may not be a big number but it 
was his first full cycle in Mistral and I believe he can do more
  *   He is one of the most active team members in general and in IRC 
specifically, always open for communication and easy to talk to
  *   He is an active user of Mistral which is very important for me since he’s 
capable of providing valuable practical feedback on design, usability, 
reliability etc.
  *   He seems to be very excited about working on Mistral

Besides that I believe Dougal makes a good friendly atmosphere in our 
development team daily in our IRC channel and our weekly IRC meetings.

Team, I would ask you to support me in this promotion.

Thanks

[1] 
http://stackalytics.com/?module=mistral-group_id=d0ugal=newton=marks

Renat Akhmerov
@Nokia


__
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] [Openstack-operators] [MassivelyDistributed] bi-weekly meeting

[Thierry Carrez]

Blair Bethwaite wrote:
> Devil's advocate - what is "full enough"? Surely another channel is
> essentially free and having flexibility in available timing is of utmost
> importance?

See
http://docs.openstack.org/project-team-guide/open-community.html#public-meetings-on-irc

That said, it's a balancing act and we may be past the point when
scheduling pain takes over the need to spread meetings out. I'll do a
quick pass to try to free up slots taken by dead meetings, and if we
can't free enough slots we'll likely add a new meeting channel.

-- 
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

Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core team

[Anastasia Kuznetsova]

+1 from my side!

On Tue, Nov 8, 2016 at 11:34 AM, Gershenzon, Michal (Nokia - IL) <
michal.gershen...@nokia.com> wrote:

> +1
>
> J
>
>
>
> Michal Gershenzon
> Software Engineer, CloudBand
> Application & Analytics , Nokia
> Contact number: +972 9 793 3163
>
>
>
> *From:* Deja, Dawid [mailto:dawid.d...@intel.com]
> *Sent:* Tuesday, November 08, 2016 10:21 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the
> core team
>
>
>
> +1
>
>
>
> It's good to have you on board Dougal!
>
>
>
> Dawid Deja
>
>
>
> On Tue, 2016-11-08 at 19:46 +1300, Lingxian Kong wrote:
>
> +1 of course!
>
>
>
> Cheers,
> Lingxian Kong (Larry)
>
>
>
> On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov 
> wrote:
>
> Hi,
>
>
>
> I’d like to promote Dougal Matthews to the Mistral core team. [1] shows
> Dougal’s Mistral contribution summary for Newton cycle.
>
>
>
> Here are the reasons why I would like to see Dougal in the core team:
>
>- He reviews a lot and provides valuable comments, especially when it
>comes to discussing design of the new features
>- He sent 18 patches in Newton cycle which may not be a big number but
>it was his first full cycle in Mistral and I believe he can do more
>- He is one of the most active team members in general and in IRC
>specifically, always open for communication and easy to talk to
>- He is an active user of Mistral which is very important for me since
>he’s capable of providing valuable practical feedback on design, usability,
>reliability etc.
>- He seems to be very excited about working on Mistral
>
>
>
> Besides that I believe Dougal makes a good friendly atmosphere in our
> development team daily in our IRC channel and our weekly IRC meetings.
>
>
>
> Team, I would ask you to support me in this promotion.
>
>
>
> Thanks
>
>
>
> [1] http://stackalytics.com/?module=mistral-group_id=
> d0ugal=newton=marks
>
>
>
> Renat Akhmerov
>
> @Nokia
>
>
>
>
> __
> 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
>
>


-- 
Best regards,
Anastasia Kuznetsova
__
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] [Horizon] ui-cookiecutter

[Shuu Mutou]

Hi Horizoners,

Thanks for picking up ui-cookiecutter[1] and setting Ocata-2 milestone at 
summit[2].
Thai or Cindy? Thank you!!

I'm maintaining ui-cookiecutter, but I'm ready for transferring it as Horizon 
subproject.

Can I start to create subproject for ui-cookiecutter?
Or please let me know what I should do.

[1] https://github.com/shu-mutou/ui-cookiecutter
[2] https://etherpad.openstack.org/p/horizon-ocata-priorities

Regards,

Shu Muto


__
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] Embracing new languages in OpenStack

[Thierry Carrez]

Ash wrote:
> [...]
> Here's another take on the situation. If there are people who genuinely
> wish to see a CI pipeline that can support something like Go, perhaps
> you can establish a prerequisite of working with the Infra team on
> establishing the new pipeline. In my opinion, this seems to be the major
> gate. So, if there's a clear path identified, resources provided, and
> the Infra team is ultimately benefitted, then I'm not sure why there
> should be another rejection. Just a thought. I know this proposal
> continues to come up and I'm a big fan of seeing other languages
> supported, especially Go. But I also understand that it can break
> things. Personally, I would even volunteer to work on such an Infra effort. 
> 
> BTW, it is quite possible that another group might feel the same
> constraints. It's perfectly reasonable. But if we can overcome such
> obstacles, would the TC still have a concern? 

The TC isn't just one person. In complex situations like this where you
have to weigh the trade-off between opening up more choices and our
community's ability to digest/survive the change, there will always be a
wide variety of opinions. I won't claim to be able to predict how the
current membership would vote.

That said, I think that if we can have more confidence that our
structure can handle it (from infra to release/stable/dep management)
and that the OpenStack community will share expertise and best practices
on Go and avoid reinventing the wheel in every project, I expect a
majority of TC members to take that leap of faith.

To me, the important part is that introducing Go should not be another
way for some of our community to be different, but another way for our
community to be one. It should do more to bind our community together
than to split it into more factions and silos.

-- 
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

Re: [openstack-dev] [Openstack-operators] [MassivelyDistributed] bi-weekly meeting

[Blair Bethwaite]

Devil's advocate - what is "full enough"? Surely another channel is
essentially free and having flexibility in available timing is of utmost
importance?

On 8 Nov 2016 5:37 PM, "Tony Breeds"  wrote:

> On Mon, Nov 07, 2016 at 05:52:43PM +0100, lebre.adr...@free.fr wrote:
> > Dear all,
> >
> > We are still looking for an irc channel for our meeting:
> https://review.openstack.org/#/c/393899
> > There is no available channels for the slot we selected during our
> face-to-face meeting in Barcelona.
> >
> > If I'm correct, we have two possibilities:
> > - Determine another slot: the first available slot on Wednesday is at
> 17:00 UTC.
>
> Or you could look at 1400 on Wednesday
>
> > - Ask for the creation of a new IRC channel dedicated to our WG:
> something line #openstack-massively-distributed
>
> This is an option but you can't hold meetings in project specific channels
> as
> the meeting bot only works correctly in the #openstack-meeting rooms.
>
> We from time to time get asked to cerate a 5th meeting room.  Looking at
> [1] I
> don't feel like we're full enough to persue that.
>
> Yours Tony.
> [1] https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kICh
> ZumHLHzoMNF07c/edit?usp=sharing
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
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] [barbican] Nominating Arun Kant for barbican-core

[Rob C]

Congratulations Arun, you've put a lot of work in!

On Mon, Nov 7, 2016 at 10:05 PM, Fernando J Diaz  wrote:

> +1 Congrats Arun, welcome to Barbican Core.
>
>
> __
> 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] [openstack-infra][nova][tempest][qa][infra] NUMA topology, cpu pinning, hugepages tempest tests upstream or plugin

[Znoinski, Waldemar]

Hi all,

Due to recent discussions around Enhanced Platform Awareness (EPA) and their 
testing in OpenStack thinking was started to take what Intel NFV 3rd party CI 
[1] runs at this moment and merge some/all into upstream Tempest. Currently 
intel-nfv-ci-tests is a Tempest plugin [2] [3] and it's running on all Nova 
changes , sample [4]. Merging them with upstream Tempest would give testing 
environments an option to turn them on with a flip of a switch in tempest.conf 
rather than pip install  + tempest run with all-plugin (to enable 
site_packages).

While some of them may be easier from technical stand point (hugepages) some of 
them may not be possible in cloud providers used by OpenStack Infra.

Both options: Tempest plugin, upstream Tempest have pros and cos and we'd like 
to get broader community to comment on that.
If you have any feedback, suggestions, ideas please follow up here.


[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI
[2] https://github.com/openstack/intel-nfv-ci-tests
[3] http://docs.openstack.org/developer/tempest/plugin-registry.html
[4] 
http://intel-openstack-ci-logs.ovh/51/393951/2/check/tempest-dsvm-intel-nfv-xenial/2982905/

thanks
wznoinsk
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
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] [Congress] Error datasource create

[Ruben]

Hi everybody,
really, I've not been able to create the datasource for magnum.
Now, I've seen that I've these errors when I restart the congress server..

"ERROR congress.dse2.dse_node [-] Error loading instance of module 
'congress.datasources.magnum_driver.MagnumDriver'
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node Traceback (most recent 
call last):
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/dse2/dse_node.py", line 841, in 
create_datasource_service
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node service = 
getattr(module, class_name)(**kwargs)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/magnum_driver.py", line 49, in 
__init__
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node super(MagnumDriver, 
self).__init__(name, args=args)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1282, in 
__init__
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
super(PollingDataSourceDriver, self).__init__(name, args=args)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 324, in 
__init__
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
self.initialize_translators()
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1324, in 
initialize_translators
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
self.register_translator(translator)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 457, in 
register_translator
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
self._validate_translator(translator, related_tables)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 446, in 
_validate_translator
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
self._validate_by_translation_type(translator, related_tables)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 415, in 
_validate_by_translation_type
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
self._get_translator_params(translation_type))
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1066, in 
check_params
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node raise 
exception.InvalidParamException(err)
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node InvalidParamException: 
Params (field_translators, selector_type) are invalid.  Valid params: 
('translation-type', 'table-name', 'parent-key', 'id-col', 'selector-type', 
'field-translators', 'in-list', 'parent-col-name', 'objects-extract-fn', 
'parent-key-desc')
2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node 
2016-11-08 12:15:29.911 ERROR congress.harness [-] datasource magnum creation 
failed.
2016-11-08 12:15:29.911 TRACE congress.harness Traceback (most recent call 
last):
2016-11-08 12:15:29.911 TRACE congress.harness   File 
"/opt/stack/congress/congress/harness.py", line 167, in create_datasources
2016-11-08 12:15:29.911 TRACE congress.harness service = 
bus.create_datasource_service(ds)
2016-11-08 12:15:29.911 TRACE congress.harness   File 
"/opt/stack/congress/congress/dse2/dse_node.py", line 845, in 
create_datasource_service
2016-11-08 12:15:29.911 TRACE congress.harness raise 
exception.DataServiceError(msg % class_path)
2016-11-08 12:15:29.911 TRACE congress.harness DataServiceError: Error loading 
instance of module 'congress.datasources.magnum_driver.MagnumDriver'
2016-11-08 12:15:29.911 TRACE congress.harness 
2016-11-08 12:15:29.912 ERROR congress.service [-] Fatal Exception:
2016-11-08 12:15:29.912 TRACE congress.service Traceback (most recent call 
last):
2016-11-08 12:15:29.912 TRACE congress.service   File 
"/opt/stack/congress/congress/service.py", line 34, in wrapper
2016-11-08 12:15:29.912 TRACE congress.service return f(*args, **kw)
2016-11-08 12:15:29.912 TRACE congress.service   File 
"/opt/stack/congress/congress/service.py", line 51, in congress_app_factory
2016-11-08 12:15:29.912 TRACE congress.service 
datasources=flags_dict['datasources'])
2016-11-08 12:15:29.912 TRACE congress.service   File 
"/opt/stack/congress/congress/harness.py", line 93, in create2
2016-11-08 12:15:29.912 TRACE congress.service services['datasources'] = 
create_datasources(node)
2016-11-08 12:15:29.912 TRACE congress.service   File 
"/opt/stack/congress/congress/harness.py", line 167, in create_datasources
2016-11-08 12:15:29.912 TRACE congress.service service = 
bus.create_datasource_service(ds)
2016-11-08 12:15:29.912 TRACE congress.service   File 

Re: [openstack-dev] [nova] Live migrations: Post-Copy and Auto-Converge features research

[Vlad Nykytiuk]

Thanks, Pawel!

—
Vlad

> On Nov 8, 2016, at 09:53, Koniszewski, Pawel  
> wrote:
> 
> Adding operators list, as it might be interesting for them. Please note that 
> some of tested options are not available in nova, i.e., XBZRLE and 
> postcopy-after-precopy. Regarding postcopy, nova automatically decides 
> whether live migration should be switched to postcopy mode (only if 
> live_migration_permit_post_copy is set to True, by default it is set to 
> False), postcopy-after-precopy is an internal virsh command which is not 
> exposed through the libvirt API.
>  
> Kind Regards,
> Pawel Koniszewski
>   <>
>  <>From: Vlad Nykytiuk [mailto:vnykyt...@mirantis.com] 
> Sent: Monday, November 7, 2016 9:35 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [nova] Live migrations: Post-Copy and Auto-Converge 
> features research
>  
> Hi,
>  
> As you may know, currently QEMU supports several features that help live 
> migrations to operate more predictively. These features are: auto-converge 
> and post-copy. 
> I made a research on performance characteristics of these two features, you 
> can find it by the following link:
> https://rk4n.github.io/2016/08/10/qemu-post-copy-and-auto-converge-features/ 
> 
>  
> Hope you find it helpful.
>  
> Thanks
> —
> Vlad
>  
> __
> 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] [ptl][release] ocata release management communication

[Steven Dake (stdake)]

Doug,

As predecessor PTL for Kolla, I have followed your recommendations 1-4 
including this ack, although I am not sure its really necessary for me.  Note, 
I am not sure Michal (inc0 on irc) wants me to continue as release liaison or 
do the job himself, so that step has not yet been taken.  I will contact him in 
the next few days to make sure he either updates the release liaison to 
himself, asks for a volunteer, or expects me to continue to do that work.  If 
he expects me to continue with the work, I will do it at last for the Ocata 
cycle.

In any case, I won’t let the releases slip through the cracks as a result of a 
PTL transition.

Regards
-steve




On 11/1/16, 12:45 PM, "Doug Hellmann"  wrote:

>PTLs,
>
>As we did for the Mitaka and Newton cycles, I want to start this
>cycle by making sure the expectations for communications with the
>release team are clear to everyone so there is no confusion or
>miscommunication about any of the process or deadlines. This
>email is being sent to the openstack-dev mailing list as well as
>the PTLs of all official OpenStack projects individually, to
>improve the odds that all of the PTLs see it.  I will not be
>taking the extra step of CCing individual PTLs or liaisons for
>future emails.
>
>(If you were a PTL last cycle, you may want to skip ahead to the
>Things for you to do right now section at the end.)
>
>Volunteers filling PTL and liaison positions are responsible for
>ensuring communication between project teams happens smoothly. As
>a community, we rely on three primary communication
>strategies/tools for different purposes:
>
>1. Email, for announcements and for asynchronous communication.
>
>  We will be using the "[release]" topic tag on the openstack-dev
>  mailing list for important messages related to release
>  management.  Besides special announcements and instructions, I
>  will send the countdown emails I sent last cycle, with weekly
>  updates on focus, tasks, and upcoming dates. PTLs and release
>  liaisons should configure your mailing list subscription and
>  email client to ensure that those messages are visible (and
>  then read them) so that you are aware of all deadlines, process
>  changes, etc.
>
>2. IRC, for time-sensitive interactions.
>
>  There are far too many of you (56) to make it realistic for the
>  three members of the release team to track you down
>  individually when there is a deadline. We need you to do your
>  part by making yourself available by configuring your IRC
>  bouncer to listen in #openstack-release. You are, of course,
>  welcome to stay in channel all the time, but you need to be
>  there at least during deadline periods (the week before and
>  week of each deadline).
>
>3. Written documentation, for relatively stable information.
>
>  The release team has published the schedule for the Ocata cycle
>  to http://releases.openstack.org/ocata/schedule.html. Although
>  I will highlight dates in the countdown emails, you may want to
>  add important dates from the schedule to your calendar.
>
>  Some projects have also added their own project-specific
>  deadlines to that list. If you have something unique, please
>  feel free to update it by patching the openstack/releases
>  repository. There is no need to add a project-specific deadline
>  that is the same as the global deadline.
>
>The Ocata cycle overlaps with several major holidays, including
>the new year. If you are planning time off, please make sure your
>duties are being covered by someone else on the team. Its best to
>let the release team know in advance so we dont delay approval
>for release requests from someone we dont recognize, waiting for
>your +1.
>
>Please ensure that the release liaison for your project has the
>time and ability to handle the communication necessary to manage
>your release.  The release team is here to facilitate, but
>finishing the work of preparing the release is ultimately the
>responsibility of the project team. Failing to follow through on
>a needed process step may block you from successfully meeting
>deadlines or releasing.  Our release milestones and deadlines are
>date-based, not feature-based.  When the date passes, so does the
>milestone. If you miss it, you miss it. A few of you ran into
>problems in past cycles because of missed communications. My goal
>is to have all teams meet all deadlines during Ocata. We came
>very very close for Newton; please help by keeping up to date on
>deadlines.
>
>
>Things for you to do right now:
>
>1. Update your cross-project liaison on
>   https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
>2. Make sure your IRC nickname and email address listed in
>   
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>   are correct. The release team, foundation staff, and TC all
>   use those contact details to try to reach you at important
>   points during the cycle.  Please make sure they are correct,
>   

[openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

Hey folks,

As we split out the repository per our unanimous vote several months ago, we 
have a choice to make (I think, assuming we are given latitude of  the release 
team who is in the cc list) as to which version to call kolla-ansible.

My personal preference is to completely retag our newly split repo with all old 
tags from kolla git revisions up to version 3.0.z.  The main rationale I can 
think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think calling 
kolla-ansible 1.0 = newton would be somewhat confusing, but we could do that as 
well.

The reason the repository needs to be retagged in either case is to generate 
release artifacts (tarballs, pypi, etc).

Would also like feedback from the release team on what they think is a best 
practice here (we may be breaking new ground for the OpenStack release team, 
maybe not – is there prior art here?)

For a diagram (mostly for the release team) of the repository split check out:
https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89

Thanks!
-steve

__
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] [kolla][release] Version numbers for kolla-ansible repository.

[Swapnil Kulkarni]

On Tue, Nov 8, 2016 at 6:38 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> As we split out the repository per our unanimous vote several months ago, we
> have a choice to make (I think, assuming we are given latitude of  the
> release team who is in the cc list) as to which version to call
> kolla-ansible.
>
> My personal preference is to completely retag our newly split repo with all
> old tags from kolla git revisions up to version 3.0.z.  The main rationale I
> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think
> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could
> do that as well.
>
> The reason the repository needs to be retagged in either case is to generate
> release artifacts (tarballs, pypi, etc).
>
> Would also like feedback from the release team on what they think is a best
> practice here (we may be breaking new ground for the OpenStack release team,
> maybe not – is there prior art here?)
>
> For a diagram (mostly for the release team) of the repository split check
> out:
> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
>
> Thanks!
> -steve
>
>
> __
> 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
>


I would love to get inputs from release team, though one of the recent
repo split I remember is neutron and if I look at the history, old
tags from git revisions are preserved. I think we can follow the same
process for kolla and kolla-ansible split.



-coolsvap

__
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] Ocata End user and operator feedback recap

[Assaf Muller]

On Tue, Nov 8, 2016 at 12:57 AM, Oleg Bondarev  wrote:
>
>
> On Tue, Nov 8, 2016 at 12:22 AM, Carl Baldwin  wrote:
>>
>> Ocata End user and operator feedback recap
>> 
>>
>> The purpose of this session was to gather feedback from end users and
>> operators to help direct the efforts of developers during (at least) the
>> Ocata cycle. Feedback was captured on the etherpad [1]. There was a related
>> session in the operators' track [2] which may also be of interest.
>>
>> We began with a short discussion about client compatibility which was
>> deferred to the following session specifically about the client [3].
>>
>> There was a discussion about if Neutron will implement cells like Nova
>> has. There is currently no plan. I have heard this come up for the past
>> couple of summits but there is little concrete evidence of the scale issues
>> being encountered by operators. If you are running Neutron at scale, we
>> could use more of your input.
>>
>> There was some discussion about an issue around moving a floating ip from
>> one instance to another when keepalive is in use. We needed more information
>> to debug this. It should be sending a gratuitous arp. Another keepalive
>> issue was discussed. Too many SIGHUPs within a period of time can cause
>> failover resulting in disruption. I do not know if a bug was filed for this
>> to follow up. If this was you, please follow up with a link to the bug
>> report.
>
>
> https://bugs.launchpad.net/neutron/+bug/1639315 looks related

That covers keepalived not sending GARPs on SIGHUP. This will be
resolved via a workaround in Neutron with a patch by Jakub Libosvar
(Linked from the bug report). The other issue of keepalived hanging
when receiving frequent consecutive SIGHUPs (When a floating IP is
added/removed) will also be resolved via a workaround, but I don't see
a bug report yet. This will be handled by John Schwarz.

>
>>
>>
>> There was a short discussion about Horizon support for security groups on
>> a port. A bug was filed for this.
>>
>> Finally, there was some discussion about enabling end users to create
>> Neutron L3 routers which are backed by hardware resources. There is no such
>> thing yet but Neutron does have a new concept in development called "L3
>> flavors". This would enable a driver (to be written) which would allow this
>> sort of thing.
>>
>> Carl Baldwin
>>
>> [1]
>> https://etherpad.openstack.org/p/ocata-neutron-end-user-operator-feedback
>> [2] https://etherpad.openstack.org/p/newton-neutron-pain-points
>> [3] https://etherpad.openstack.org/p/ocata-neutron-client
>>
>> __
>> 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] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 10:30, Thierry Carrez wrote:
> Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps
>> you can establish a prerequisite of working with the Infra team on
>> establishing the new pipeline. In my opinion, this seems to be the major
>> gate. So, if there's a clear path identified, resources provided, and
>> the Infra team is ultimately benefitted, then I'm not sure why there
>> should be another rejection. Just a thought. I know this proposal
>> continues to come up and I'm a big fan of seeing other languages
>> supported, especially Go. But I also understand that it can break
>> things. Personally, I would even volunteer to work on such an Infra effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.

Yup - and the TC could possibly change half, (or even all) its members
during time it takes to get this work done.

> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.

There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.

> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

I would agree - but I would ask that we find a way forward that does not
require huge amounts of up front work, for a gamble at the end of the
process, where the work could be written off for any number of other
reasons.

__
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