Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

[Alex Xu]

2015-11-13 17:36 GMT+08:00 John Garbutt :

> On 6 November 2015 at 15:32, John Garbutt  wrote:
> > Hi,
> >
> > I propose we add Alex Xu[1] to nova-core.
> >
> > Over the last few cycles he has consistently been doing great work,
> > including some quality reviews, particularly around the API.
> >
> > Please respond with comments, +1s, or objections within one week.
>
> Big thank you to everyone who helped mentor Alex over the last year or
> so, and to all those who voted.
>


Yeah, really really appreciate all peoples who mentor and encourage me! I
really learned a lot of things from you!

Also thanks all the votes! I will continue try my best to help on Nova, and
continue to learn from you.

Thanks
Alex


>
> Alex, welcome to nova-core!
>
> Thanks,
> johnthetubaguy
>
> > Many thanks,
> > John
> >
> > [1]http://stackalytics.com/?module=nova-group_id=xuhj=all
>
> __
> OpenStack Development Mailing 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] Proposal to add Sylvain Bauza to nova-core

[John Garbutt]

On 6 November 2015 at 15:32, John Garbutt  wrote:
> Hi,
>
> I propose we add Sylvain Bauza[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the Scheduler.
>
> Please respond with comments, +1s, or objections within one week.

Big thank you to everyone who helped mentor Sylvain over the last year
or so, and to all those who voted.

Sylvain, welcome to nova-core!

Thanks,
johnthetubaguy

> Many thanks,
> John
>
> [1] 
> http://stackalytics.com/?module=nova-group_id=sylvain-bauza=all

__
OpenStack Development Mailing 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] Last sync from oslo-incubator

[Thierry Carrez]

Davanum Srinivas wrote:
> A long time ago, oslo-incubator had a lot of code, we have made most
> of the code to oslo.* libraries. There's very little code left and
> we'd like to stop hosting common code in oslo-incubator repository. We
> encourage everyone to adopt the code they have in their repos under
> openstack/common into their own namespace/packaging as we will be
> getting rid of any remaining python modules in oslo-incubator.
> [...]

So this is pretty funny, since oslo-incubator was actually created
exactly 3 years ago today. Three years ago we clearly stated that common
code between OpenStack projects should ultimately become libraries and
no longer be copy-pasted. It took us 3 years to get to the point where
almost all the code has been graduated.

Some would say it's a long time, but considering this is a
cross-project, technical-debt-reduction effort that typically falls
short of resources in a tragedy of the commons, I prefer to see it as a
great achievement for us as a community.

Thanks to all the people that drove Oslo from where it was to where it
is today, including (but not limited to) Mark McLoughlin, Doug Hellmann
and Davanum Srinivas.

-- 
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] [puppet] ::db classes

[Yanis Guenane]

On 11/11/2015 03:50 PM, Clayton O'Neill wrote:
> I discovered this issue last night and opened a bug on it (
> https://bugs.launchpad.net/puppet-tuskar/+bug/1515273).
>
> This effects most of the modules, and the short version of it is that the
> defaults in all the ::db classes are wrong for max_pool_size
> and max_overflow.  We’re setting test to 10 and 20, but oslo_db actually
> has no internal default.
>
> The two options I see for fixing this are to either put in place the old
> traditional:
>
> if $option_name {
>   # ensure value
> } else {
>   # ensure absent
> }
>
> and do that for at least the two values with the wrong defaults, or
> preferably, change the defaults for all of these parameters to use the
> service default fact.
>
> I prefer the latter approach.  I know there has been some discussion on
> Trello about how much we want to be using the service default fact, but as
> near as I can tell, the concerns seem to mostly about not accidentally
> reverting intentionally different values and breaking existing installs.
>
> This scenario seems to be the ideal candidate for just not setting a value
> unless the deployer has specifically asked for something special.
>
Hi Clayton,

Those values have been initially used because they were part of
puppet-neutron[1], so in order to be consistent with the value in other
modules, 10 and 20 have been picked for max_pool_size and max_overflow.

Base on the quick calculation you put up on IRC yesterday I can see how
this can be troublesome in some cases.

As for the solution, I tend to prefer the latter proposal and go with
the $::os_service_default fact.

Thanks for bringing it up,

[1]
https://github.com/openstack/puppet-neutron/commit/7b54f896aa1a5303c7c79206f13c46149447c9df


--
Yanis Guenane

__
OpenStack Development Mailing 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][upgrade] Grenade multinode partial upgrade

[Ihar Hrachyshka]

Armando M.  wrote:




On 12 November 2015 at 20:24, Sean M. Collins  wrote:
On Thu, Nov 12, 2015 at 05:55:51PM EST, Ihar Hrachyshka wrote:
> I also believe that the first step to get the job set is making neutron  
own

> its grenade future, by migrating to grenade plugin maintained in neutron
> tree.

I'd like to see what Sean Dague thinks of this - my worry is that if we
start pulling things into Neutron we lose valuable insight from people
who know a lot about Grenade.

Not to mention, Sean and I have had conversations about trying to get
Neutron as the default for DevStack - we can't just take our ball and go
in our own corner.

Agreed. (I feel like) we had a good discussion at the summit about this:  
we clearly have key pieces that are and will stay within the realm of  
both devstack and grenade.


Agreed that it’s worth clarifying with grenade folks what should be  
included in grenade plugin, and what belongs to core grenade; and where  
multinode ‘partial’ job stands in this regard.


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] [glance] [nova] Image Signature Verification

[Daniel P. Berrange]

On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote:
> Hello,
> 
> There has recently been additional discussion about the best way to handle
> image signature verification in glance and nova [1].  There are two
> options being discussed for the signature (the examples below using
> 'RSA-PSS' as the type, and SHA-256 as the hash method):
> 
> 1. The signature is of the glance checksum of the image data (currently a
> hash which is hardcoded to be MD5)
> signature = RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))
> 
> 2. The signature of the image data directly
> signature = RSA-PSS(SHA-256(IMAGE-CONTENT))
> 
> The 1st option is what is currently in glance's liberty release [2].  This
> approach was chosen with the understanding that the glance checksum would
> be updated to be configurable [3].  Although the 2nd option was initially
> proposed, the glance community opposed it during the pre-Liberty virtual
> mini-summit in May 2015 (due to the performance impact of doing two hashes
> of the image data--one for the 'checksum' and the other for the
> signature), and it was decided to proceed with the 1st option during the
> Liberty summit [4].
> 
> During the Mitaka Summit, making the glance checksum configurable was
> discussed during a design session [5].  It was decided that instead of
> making the 'checksum' image field configurable, it would be preferable to
> compute a separate, configurable (on a per-image basis, with a site-wide
> default) hash, and then use that hash when MD5 wasn't sufficient (such as
> in the case of signature verification). This second hash would be computed
> at the same time the MD5 'checksum' was computed.
> 
> Which brings us to the nova spec which is under discussion [1], which is
> to add the ability to verify signatures in nova.  The nova community has
> made it clear that the promise of providing a configurable hash in glance
> is not good enough--they never want to support any signatures that use MD5
> in any way, shape, or form; nor do they want to rely on asking glance for
> what hash option was used.  To that end, the push is to use the 2nd option
> to verify signatures in nova from the start.

As well as not wanting MD5, I believe that computing signatures based
on a configurable checksum in glance provides a bad user experiance.
The user generating the signature of their image, now has to have a
way to query glance to find out what checksum it used, in order to
generate their signature. Further if the glance admin ever wants to
change their checksum algorithm, they'd break all existing signatures
by doing so. These are just as important reasons why I want Nova
to use the 2nd option and compute signatures directly on the image
content.

> Since the glance community no longer seems opposed to the idea of
> computing two hashes (the second hash being optional, of course), the 2nd
> option has now become valid from the glance perspective.  This would
> require modifying the existing implementation in glance to verify a
> signature of the image data, rather than verifying a checksum of the image
> data, but would have no additional performance hit beyond the cost to
> compute the second hash.  Note that the image data would still only be
> read once -- the checksum update (for the MD5 hash) and the signature
> verification update (for the signature hash) would occur in the same loop.
> Although this would mean that signatures generated using option 1 would no
> longer verify, since signatures generated using option 1 are based on an
> MD5 hash (and were waiting for the checksum configurability before
> becoming a viable cryptographic option anyway), this does not pose a
> significant issue.

A second point about the current proposal from Nova's POV is that
we do not like the image property names currently used. In Liberty
Nova standardized on the property naming scheme it uses to have 3
naming prefixes

  https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166

 - 'hw_' - properties that affect virtual hardware configuration
 - 'os_' - properties that affect guest OS setup / configuration
 - 'img_' - properties that affect handling of images by the host

The signature properties are obviously all related to the handling
of images by the host, so from Nova's POV we should have an 'img_'
prefix on all their names.

We probably should have alerted glance devs to this naming convention
before now to avoid this problem, but I guess we forgot. It would be
great if glance devs could bear this preferred naming convention in
mind if there are any future cases where there is a property that
needs to be used by both Nova & Glance code.

Anyway since the change in the way we calculate signatures on images
is a non-backwards compatible change for users of the current glance
impl, changing these property names at this point is reasonable todo.

Glance could use the property name to determine whether it is
getting an old or new style signature. ie if the 

Re: [openstack-dev] Linux kernel IPv4 configuration during the neutron installation

[JinXing F]

Yes,I don't understand why Neutron needs enable ip_forward and disable RPF.
And I also don't understand where the neutron need this config during the
instance connect to the extrernal network.

I read the neutron code, found when the L3 agent creating, it needs the
ip_forward config,but i'm not find the RPF config in the neutron code.

Thank you very much!


2015-11-11 18:25 GMT+08:00 JinXing F :

> Hi, guys:
>
> during the neutron installation guide, I found that we need to config
> the linux kernel as bellow:
>
> net.ipv4.ip_forward=1
>
> net.ipv4.conf.all.rp_filter=0
>
> net.ipv4.conf.default.rp_filter=0
>
>
> the first one is the ip address translation between LAN and WLAN, the
> second and third command is used for "Reverse Path Filtering".
>
> I cann't understand the purpose of the config in the neutron.
>
> 1. If the instance in compute node connect with exteral network,what's the
> function of the three config?
>
> 2. The instance connect with each others, what's the function of the three
> config?
>
>
> I am very confused about this config.Please explain the answer to me.
>
> 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] [neutron][vpnaas] VPNaaS project status

[Elena Ezhova]

Thanks for everything you've done for VPNaaS, Paul! Your help and guidance
was (and is) always very helpful.

On Thu, Nov 12, 2015 at 5:56 PM, Paul Michali  wrote:

> Neutron community,
>
> During the past several releases, while leading the VPNaaS project, I've
> seen many great enhancements and features added to the VPNaaS project by
> the community, including support for StrongSwan, Libreswan, completion of
> the project split out, functional and rally tests, endpoint groups,
> multiple local subnets, vendor drivers, etc.
>
> There is still work needed (certificate support the most important,
> followed by documentation and scale testing), but there is a solid (in my
> bias and subjective opinion :) foundation in place for people to play with
> this capability.
>
> As I mentioned to Armando at the summit, it's time for me to move on to
> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
> wrapping up work on the project over the next few weeks. I'll still try to
> review VPNaaS commits as much as possible, and be available to advise in
> this area.
>
> Towards that end, I've updated the VPNaaS wiki page (
> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are
> outstanding work that can be done in this area, from important to wish
> items.  Meetings have transitioned to on-demand, and future meetings can
> either be done as an on-demand topic in the Neutron IRC meeting, or as an
> on-demand special meeting.
>
> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my
> opinion of importance, priority, relevance, etc.
>
> Regards,
>
> PCM (pc_m)
>
> __
> OpenStack Development Mailing 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] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

[Julia Aranovich]

Hi fuelers,

Currently Fuel UI team is working on blueprint [1] to give Fuel UI user an
ability to launch provisioning of environment nodes separately from
deployment (without choosing particular nodes for now).

In the process we were faced with the following issues. Some of them block
the blueprint:

   - deployment constantly failed on environment with pre-provisioned nodes
   [2]
   - node pending_addition flag is reset to False for provisioned nodes
   [3]. This causes a lot of UX problems: provisioned node roles, disks,
   interfaces can not be reconfigured, node can not be deleted from
   environment, just can be marked as pending deletion (that requires
   environment deployment)
   - completed provisioning task has Null message. So, there is no to show
   the user after provisioning finished [4]
   - no notification comes on UI after provisioned finished [5]
   - fake provisioning task is also should be fixed: environment nodes stay
   in 'provisioning' status after provisioning finished [6]. This breaks fake
   Fuel UI workflow and brings difficulties in Fuel UI development.

Could you please consider/fix the tickets and help to unblock the blueprint
targeted for the current release.

Also, you can check how provisioning works in Fuel UI on #547 custom 8.0
ISO.

Thank you!
Julia

[1]
https://blueprints.launchpad.net/fuel/+spec/support-separate-provisioning-and-deployment-in-ui
[2] https://bugs.launchpad.net/fuel/+bug/1515903
[3] https://bugs.launchpad.net/fuel/+bug/1515898
[4] https://bugs.launchpad.net/fuel/+bug/1515895
[5] https://bugs.launchpad.net/fuel/+bug/1515891
[6] https://bugs.launchpad.net/fuel/+bug/1515893
__
OpenStack Development Mailing 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][qos][fwaas] service groups vs. traffic classifiers

[Ihar Hrachyshka]

Paul Carver  wrote:


On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote:

All I am saying is that IF we merge some classifier API into neutron
core and start using it for core, non-experimental, features, we cannot
later move to some newer version of this API [that you will iterate on]
without leaving a huge pile of compatibility code that would not exist
in the first place if only we thought about proper API in advance. If
that’s what you envision, fine; but I believe it will make adoption of
the ‘evolving’ API a lot slower than it could otherwise be.


I don't think I disagree at all. But we don't have a classifier API in  
neutron core (unless we consider security groups to be it) and I don't  
think anyone is saying that the classifier in networking-sfc should be  
merged straight into core as-is. In fact I think we're saying exactly the  
opposite, that *a* classifier will sit in networking-sfc, outside of core  
neutron, until *some* classifier is merged into core neutron.




That’s why I raised service groups spec in this thread: it seems it’s  
planned to be added into core, with all compatibility guarantees; and was  
planned for adoption for the new fwaas API (as per summit sessions). At  
least I haven’t found anything in their spec that would suggest it’s  
experimental.


It may mean that at the moment when you arrive to some classifier API that  
you can claim the best we can get, there can be a rival classifier API in  
the core tree already.


The point of networking-sfc isn't the classifier. A classifier is simply  
a prerequisite. So by all means let's work on defining and merging into  
core neutron a classifier that we can consider non-experimental and  
stable for all features to share and depend on, but we don't want SFC to  
be non-functional while we wait for that to happen. We can call the  
networking-sfc classifier experimental a slap a warning on that it'll be  
replaced with the core neutron classifier once such a thing has been  
implemented.


__
OpenStack Development Mailing 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] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer

[Yanis Guenane]

Congrats Rich !


On 11/04/2015 05:10 PM, Emilien Macchi wrote:
>
> On 11/03/2015 03:56 PM, Matt Fischer wrote:
>> Sorry I replied to this right away but used the wrong email address and
>> it bounced!
>>
>>> I've appreciated all of richs v3 contributions to keystone. +1 from me.
> 2 positives votes from our core-reviewer team.
> No negative vote at all.
>
> I guess that's a 'yes', welcome Rich, you're the first
> puppet-keystone-core member!
>
> Note: anyone else core-reviewer on Puppet modules is also core on
> puppet-keystone by the way.
>
> Congrats Rich!
>
>> On Tue, Nov 3, 2015 at 4:38 AM, Sofer Athlan-Guyot > > wrote:
>>
>> He's very good reviewer with a deep knowledge of keystone and puppet.
>> Thank you Richard for your help.
>>
>> +1
>>
>> Emilien Macchi > > writes:
>>
>> > At the Summit we discussed about scaling-up our team.
>> > We decided to investigate the creation of sub-groups specific to our
>> > modules that would have +2 power.
>> >
>> > I would like to start with puppet-keystone:
>> > https://review.openstack.org/240666
>> >
>> > And propose Richard Megginson part of this group.
>> >
>> > Rich is leading puppet-keystone work since our Juno cycle. Without his
>> > leadership and skills, I'm not sure we would have Keystone v3 support
>> > in our modules.
>> > He's a good Puppet reviewer and takes care of backward compatibility.
>> > He also has strong knowledge at how Keystone works. He's always
>> > willing to lead our roadmap regarding identity deployment in
>> > OpenStack.
>> >
>> > Having him on-board is for us an awesome opportunity to be ahead of
>> > other deployments tools and supports many features in Keystone that
>> > real deployments actually need.
>> >
>> > I would like to propose him part of the new puppet-keystone-core
>> > group.
>> >
>> > Thank you Rich for your work, which is very appreciated.
>>
>> --
>> Sofer Athlan-Guyot
>>
>> 
>> __
>> OpenStack Development Mailing 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
--
Yanis Guenane

__
OpenStack Development Mailing 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] Proposal to add Sylvain Bauza to nova-core

[Sylvain Bauza]

Le 13/11/2015 10:36, John Garbutt a écrit :

On 6 November 2015 at 15:32, John Garbutt  wrote:

Hi,

I propose we add Sylvain Bauza[1] to nova-core.

Over the last few cycles he has consistently been doing great work,
including some quality reviews, particularly around the Scheduler.

Please respond with comments, +1s, or objections within one week.

Big thank you to everyone who helped mentor Sylvain over the last year
or so, and to all those who voted.

Sylvain, welcome to nova-core!


Thanks to all of you for being very helpful and providing me very good 
insights. I'm very humble to become a nova-core and I look forward 
helping the project as much as I can.


-Sylvain


Thanks,
johnthetubaguy


Many thanks,
John

[1] http://stackalytics.com/?module=nova-group_id=sylvain-bauza=all

__
OpenStack Development Mailing 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] Proposal to add Alex Xu to nova-core

[John Garbutt]

On 6 November 2015 at 15:32, John Garbutt  wrote:
> Hi,
>
> I propose we add Alex Xu[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the API.
>
> Please respond with comments, +1s, or objections within one week.

Big thank you to everyone who helped mentor Alex over the last year or
so, and to all those who voted.

Alex, welcome to nova-core!

Thanks,
johnthetubaguy

> Many thanks,
> John
>
> [1]http://stackalytics.com/?module=nova-group_id=xuhj=all

__
OpenStack Development Mailing 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] [api] consolidate IRC change with #openstack-sdk?

[Jay Pipes]

Cool with me.

On 11/13/2015 07:58 AM, Sean Dague wrote:

The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)

-Sean



__
OpenStack Development Mailing 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][upgrade] new 'all things upgrade' subteam

[Rossella Sblendido]

Hi Ihar,

same for me, all options are ok!

cheers,

Rossella

On 11/12/2015 11:00 PM, Martin Hickey wrote:


Hi Ihar,

Any of those options would suit me, thanks.

Cheers,
Martin




From:   Ihar Hrachyshka 
To: "OpenStack Development Mailing List (not for usage questions)"
 
Date:   12/11/2015 21:39
Subject:Re: [openstack-dev] [neutron][upgrade] new 'all things
 upgrade'   subteam



Artur  wrote:


My TZ is UTC +1:00.
Do we have any favorite day? Maybe Tuesday?


I believe Tue is already too packed with irc meetings to be considered (we

have, for the least, main neutron meetings and neutron-drivers meetings
there).

We have folks in US and Central Europe and Russia and Japan… I believe the

best time would be somewhere around 13:00 to 15:00 UTC (that time would
still be ‘before midnight' for Japan; afternoon for Europe, and morning for

US East Coast).

I have checked neutron meetings at [1], and I see that we have 13:00 UTC
slots free for all days; 14:00 UTC slot available for Thu; and 15:00 UTC
slots for Mon and Fri (I don’t believe we want to have it on Fri though).
Also overall Mondays are all free.

Should I create a doodle for those options? Or are there any alternative
suggestions?

[1]:
http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings

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 Development Mailing 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] [freezer] Proposal to add Pierre-Arthur Mathieu to freezer-core

[Marzi, Fausto]

Hi All,

I'd like to propose Pierre as core in Freezer.

Pierre dedication was amazing on code review, documentation, architectural 
decision and overall greatly improving the quality of the Freezer Project.
Freezer wouldn't be to the point where it is without Pierre.

Please respond with comments, +1s, or objections within one week.

Many thanks,
Fausto

__
OpenStack Development Mailing 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] [stable] Making stable maintenance its own OpenStack project team

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2015-11-13 15:10:24 +0100:
> So.. quick summary of this thread so far.
> 
> (-)
> * Not enough work to warrant a designated "team", now that the work is
> decentralized and the cats are mostly herding themselves
> * The change is unlikely to bring a meaningful improvement to the
> situation, or sudden new resources
> 
> (+)
> * An empowered team could tackle new coordination tasks, like engaging
> more directly in converging stable branch rules across teams, or
> producing tools
> * Release management doesn't overlap anymore with stable branch, so
> having them under that PTL is limiting and inefficient
> * Reinforcing the branding (by giving it its own team) may encourage
> more organizations to affect new resources to it
> 
> In summary, I think this is worth a try. If the team fails, at least it
> will be on its own rather than as the 5th squeaky wheel of release
> management (where lack of leadership and focus could be rightly blamed
> for failure).
> 
> For this to succeed, we need someone to own the effort and push it
> forward, and a number of people caring enough about it to attend regular
> meetings about it and to lurk on #openstack-stable. I'm fine helping the
> team in the spin-off effort but I don't want to lead it (I proved I was
> unable to make it my top priority in the past, so I think the team
> deserves a more focused lead).
> 
> Erno has volunteered to lead. Ihar, Alan (Pevec) and myself don't have
> enough time to lead but are happy to help. Anyone else interested to
> join that initial group ? Flavio ? Matt ?
> 
> Once we have a list of key members we should set up a meeting to discuss
> the details.
> 

I'm willing to help with the initial team setup, working out the
details, transitioning ownership of docs, etc. I'm not sure how much
time I'll have to devote to other stable-related activities this cycle,
but may have more in the future.

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] [freezer] Proposal to add Eldar Nugaev to freezer-core

[Marzi, Fausto]

Hi All,

I'd like to propose Eldar as core in Freezer, as his help, dedication and 
contribution was incredible for the last 6 months.

Eldar not only worked on improving performances overall, but also on making our 
code more portable, abstracted and implemented outstanding features like the 
parallel backup upload engine.

Please respond with comments, +1s, or objections within one week.

Many thanks,
Fausto
__
OpenStack Development Mailing 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] [midonet] Announcing new mailing list topic: MidoNet

[Sandro Mathys]

Hello everyone,

This is just a heads up that Thierry Carrez was so kind as to add a
new topic to the openstack-dev mailing list for the MidoNet dev team.
We currently use our own mailing list [1] but plan to move our
discussions here rather sooner than later.

Last chance to adjust your filters! ;)

Cheers,
Sandro

[1] https://lists.midonet.org/listinfo/midonet-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] [fuel] Using upstream packages & modules

[Alexander Kostrikov]

Hi, Alex!
Good to know someone is doing that.

One question about Your initiative:
Are You going to reimplement all MOS HA features?
Seems first implementation of 'upstream on Fuel' will be HA-less.


On Thu, Nov 12, 2015 at 1:51 AM, Alex Schultz  wrote:

> On Tue, Nov 10, 2015 at 11:10 AM, Vladimir Kuklin 
> wrote:
> > Alex
> >
> > Thanks for your very detailed answer - it clarified things a bit. So, if
> you
> > would allow me to rephrase it - you are actually conducting a research on
> > what is the actual gap between our downstream/fork and upstream
> > UCA/puppet-openstack. This seems to be a very promising initiative. Are
> you
> > going to come up with some external-user readable report soon?
> >
> > Also, regarding multiple distros support.  I think, we need to come up
> with
> > an approach of making 'release manager' piece of Nailgun data driven and
> > just allow a user to run any distribution he or she wants. Just register
> a
> > set of repos with packages and run it. Actually, we already have it - we
> > need to make base-image generation for RPM more flexible and any RPM/DEB
> > based distro should work ok with it.
> >
> > The remaining piece is to actually support distro-specific things, e.g.
> > CentOS/RHEL networking configuration, e.g. l23 network stored config
> puppet
> > providers. But this is a distro-supporter/community burden.
> >
> >
>
> Yes I hope to have something together by the end of the week.  I've
> managed to get a controller and compute/cinder nodes up (and passing
> basic OSTF tests) with what appears to be some minor adjustments to
> the fuel-library code.  The one thing that gets dropped because of
> lack of upstream support is nova floating network ranges. There's a
> pending review that'll get that back in but I also don't know how
> important it would be to support for this type of configuration.
> Another issue is the upstream murano module is still a work in
> progress so that won't work right now either. Hopefully that'll get
> sorted out in time for the official release of the liberty puppet
> modules.
>
> As I've been working through this, I've noticed that it would be
> possible to use fuel-plugins to only apply UCA packages to specific
> nodes via a plugin role. An interesting follow on to this effort would
> be to use MOS packages for controllers and UCA for Compute or vice
> versa.  But that should probably be more an academic exercise rather
> than production one.
>
> -Alex
>
> >
> > On Tue, Nov 10, 2015 at 6:25 PM, Alex Schultz 
> wrote:
> >>
> >> Hey Vladimir,
> >>
> >> On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin 
> >> wrote:
> >> > Alex
> >> >
> >> > That's great to hear that. But be aware - making all of the components
> >> > work
> >> > exactly the way they work within MOS is actually identical to
> >> > upstreaming
> >> > MOS. We are using some components of different versions to satisfy
> many
> >> > requirements for our Reference Architecutre implementation. It will
> not
> >> > be
> >> > so easy to base them upon existing 3rd party distributions. For
> example,
> >> > `read timeout` for SQL requests is crucial for our HA as it handles
> >> > cases
> >> > when an SQL node dies while serving the request. And you will find
> >> > myriads
> >> > of them. And as we do not control things in upstream, we will always
> >> > have
> >> > some downstream divergence.
> >> >
> >>
> >> Yes, I'm aware that it'll be an effort to make it work identically to
> >> MOS.  Currently that's not my goal. My goal is to get it working at
> >> all and be able to document the deficiencies when using upstream
> >> packages/modules vs MOS provided ones.  Once we have documented these
> >> differences we will be able to make decisions as to what efforts
> >> should be made if we choose to address the differences.  The read
> >> timeout thing seems to be an issue with what mysql python driver is
> >> used so that could easily be configurable based on a packages or a
> >> configuration option.
> >>
> >> > I guess, the optimal solution is to figure out the actual divergence
> >> > between
> >> > upstream and downstream and try to push things upstream as hard as we
> >> > can,
> >> > while retaining overrides for some packages and manifests on top of
> >> > upstream
> >> > versions. Do not get me wrong, but it seems there is exactly 0 (zero)
> >> > ways
> >> > you can get Fuel working with upstream packages unless they support
> >> > exactly
> >> > the same feature set and fix the same bugs in various components that
> >> > Fuel
> >> > expect them to support or fix. By 'working' I mean passing the same
> set
> >> > of
> >> > at least smoke and destructive tests, let alone passing scale tests.
> >> >
> >>
> >> So I think this is where we are currently backwards in the way we're
> >> doings. As we hope to push Fuel as a community project, we need to be
> >> more open to supporting the 

Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing ongate.

[Hongbin Lu]

I am going to share something that might be off the topic a bit.

Yesterday, I was pulled to the #openstack-infra channel to participant a 
discussion, which is related to the atomic image download in Magnum. It looks 
the infra team is not satisfied with the large image size. In particular, they 
need to double the timeout to accommodate the job [1] [2], which made them 
unhappy. Is there a way to reduce the image size? Or even better, is it 
possible to build the image locally instead of downloading it?

[1] https://review.openstack.org/#/c/242742/
[2] https://review.openstack.org/#/c/244847/

Best regards,
Hongbin

From: Kai Qiang Wu [mailto:wk...@cn.ibm.com]
Sent: November-13-15 12:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing ongate.


Right now, we seems can not reduce devstack runtime. ANd @Ton, yes, download 
image time seems OK in jenkins job, it found about 4~5 mins

But bay-creation time is interesting topic, it seems something related with 
heat or VM setup time consumption. But needs some investigation.



Thanks

Best Wishes,

Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

Follow your heart. You are miracle!

[Inactive hide details for "Ton Ngo" ---13/11/2015 01:13:47 pm---Thanks Eli for 
the analysis.  I notice that the time to downloa]"Ton Ngo" ---13/11/2015 
01:13:47 pm---Thanks Eli for the analysis. I notice that the time to download 
the image is only around 1:15 mins

From: "Ton Ngo" >
To: "OpenStack Development Mailing List \(not for usage questions\)" 
>
Date: 13/11/2015 01:13 pm
Subject: Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing on 
gate.





Thanks Eli for the analysis. I notice that the time to download the image is 
only around 1:15 mins out of some 21 mins to set up devstack. So it seems 
trying to reduce the size of the image won't make a significant improvement in 
the devstack time. I wonder how the image size affects the VM creation time for 
the cluster. If we can look at the Heat event stream, we might get an idea.
Ton,


[Inactive hide details for Egor Guz ---11/12/2015 05:25:15 PM---Eli, First of 
all I would like to say thank you for your effort]Egor Guz ---11/12/2015 
05:25:15 PM---Eli, First of all I would like to say thank you for your effort 
(I never seen so many path sets ;)),

From: Egor Guz >
To: 
"openstack-dev@lists.openstack.org" 
>
Date: 11/12/2015 05:25 PM
Subject: Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing on 
gate.




Eli,

First of all I would like to say thank you for your effort (I never seen so 
many path sets ;)), but I don’t think we should remove “tls_disabled=True” 
tests from gates now (maybe in L).
It’s still vey commonly used feature and backup plan if TLS doesn’t work for 
some reasons.

I think it’s good idea to group tests per pipeline we should definitely follow 
it.

―
Egor

From: "Qiao,Liyong" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 11, 2015 at 23:02
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [Magnum][Testing] Reduce Functional testing on gate.

hello all:

I will update some Magnum functional testing status, functional/integration 
testing
is important to us, since we change/modify the Heat template rapidly, we need to
verify the modification is correct, so we need to cover all templates Magnum 
has.
and currently we only has k8s testing(only test with atomic image), we need to
add more, like swarm(WIP), mesos(under plan), also , we may need to support COS 
image.
lots of work need to be done.

for the functional testing time costing, we discussed during the Tokyo summit,
Adrian expected that we can reduce the timing cost to 20min.

I did some analyses on the functional/integrated testing on gate pipeline.
the stages will be follows:
take k8s functional testing for example, we did follow testing case:

1) baymodel creation
2) 

[openstack-dev] [telemetry][aodh][ceilometer][gnocchi] the story of telemetry

[gord chung]

hi,

you may have noticed that changes are in motion and an extra telemetry 
tag being floated around. the following is your coles|cliff|spark notes 
on what you need to know.



-- background --
three years ago, the ceilometer project was created to tackle the 
billing of cloud environments. over time, people realised 'data is data 
is data' and anything can be derived from it and ceilometer's scope 
creeped. unfortunately, the scope creep in the developer space could not 
keep up with the scope creep in the user space and caused confusion. it 
also made it difficult to pinpoint issues as the 'ceilometer' term now 
covered so much space.



-- what happened --
in the past few cycles, the ceilometer project has been componentised 
into smaller, discrete projects to tackle specific functionality within 
the telemetry use case domain.



-- where we are now --
to avoid the overloaded term of ceilometer, the Telemetry project[1] was 
created to encapsulate the collective of resulting projects contributing 
to portions of this domain. to clarify the purpose of each individually 
managed project, the following are projects under the Telemetry managed 
domain:


- Aodh - an alarming service[2]
- Ceilometer - a data collection service[3]
- Gnocchi - a resource indexing and metric storage service[4]


-- what's with the name --
the generic name of Telemetry is not to assert authority over this 
space, we are just a collective who have interest and contribute to 
parts of this domain. each of the Aodh, Ceilometer, and Gnocchi teams 
are interested and open in collaborating[5] and building up this domain.



-- what happens next --
for now, as the projects are closely collaborating, they will share 
design and meeting space until they are deemed too large to share.


from a consumer pov, nothing should really change. the services are 
already packaged and separated into Aodh, Ceilometer, Gnocchi and the 
documentation already references Telemetry[6]


Going forward the teams will continue to improve each of the services[7] 
and help others extend them[5].


as always, anyone is welcome to contribute or provide feedback on each 
of the projects:

- irc: #openstack-telemetry on Freenode for questions
- ml: [telemetry] subject for general topics, [aodh], [ceilometer], 
or [gnocchi] for project specific topics



if there are any questions, please let us know so we can make transition 
go smoothly.



[1] https://wiki.openstack.org/wiki/Telemetry
[2] http://docs.openstack.org/developer/aodh
[3] http://docs.openstack.org/developer/ceilometer
[4] http://docs.openstack.org/developer/gnocchi
[5] https://wiki.openstack.org/wiki/Telemetry#Externally_Managed
[6] http://docs.openstack.org/admin-guide-cloud/telemetry.html
[7] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078461.html


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

[openstack-dev] [designate] Records for floating addresses are not removed when an instance is removed

[Jaime Fernández]

When removing an instance (with one floating address assigned) in Horizon,
designate-sink only receives an event for instance removal. As a result,
only the instance is removed but the floating addresses records are not
removed.
I'm not sure if it's a bug in openstack (I guess that it should also notify
about the unassignment of floating addresses) or it should be considered in
the nova notification handler (
https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py#L72
).
However, it is not possible to add metadata in the floating IP records to
save the instance_id and remove them easily when an instance is removed.
What's the best approach to remove the floating address records of an
instance that is being removed?
__
OpenStack Development Mailing 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] [freezer] Proposal to add Pierre-Arthur Mathieu to freezer-core

[Ramirez Garcia, Guillermo]

+1 :)

From: Marzi, Fausto
Sent: Friday, November 13, 2015 4:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [freezer] Proposal to add Pierre-Arthur Mathieu to 
freezer-core

Hi All,

I’d like to propose Pierre as core in Freezer.

Pierre dedication was amazing on code review, documentation, architectural 
decision and overall greatly improving the quality of the Freezer Project.
Freezer wouldn’t be to the point where it is without Pierre.

Please respond with comments, +1s, or objections within one week.

Many thanks,
Fausto


__
OpenStack Development Mailing 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][qos][fwaas] service groups vs. traffic classifiers

[Ihar Hrachyshka]

German  wrote:


Ihar,

The Service Group API will be added to FWaaS only and remain experimental  
in M. If the community finds it useful for other areas it can be added to  
Neutron core once it is matures. I think incubating it inside FWaaS will  
give us the velocity to iterate quickly and once it matures a strong API  
for adoption in the wider Neutron.


On the other hand if classifiers mature more quickly/provide the same  
functionality more elegantly we can quickly pivot to that. Since we are  
trying to address an immediate need I would like to experiment with  
Service Groups inside FWaaS first and then use that to shape the  
classifier API discussion. Also, as Sean suggested, we might use the  
classifier data models under the hood — so despite being a different API  
at first we might arrive at the same shared implementation…


Thanks for clarification! If we are aware of compatibility issues and use  
API in experimental features only, I think that’s indeed a better approach.  
From the first sight at the service group spec, I haven’t seen any marks  
of its experimental nature, hence was asking.


Thanks again,
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] [nova] Backlog Specs: a way to send requirements to the developer community

[Matt Riedemann]

On 11/12/2015 12:48 PM, Steve Gordon wrote:

- Original Message -

From: "John Garbutt" 
To: maishsk+openst...@maishsk.com


[SNIP]


On 14 May 2015 at 19:52, Maish Saidel-Keesing  wrote:

Can we please have this as a default template and the default way to allow
Operators to submit a feature request for EVERY and ALL the OpenStack
projects ??


+1

Thats exactly how backlog specs came about.

I ran a cross project session at the last summit to try and
standardise how all the different projects deal with specs.
https://etherpad.openstack.org/p/kilo-crossproject-specs

 From that, we agreed to introduce "Backlog" specs to hold ideas and
problem statements, and un-targeted or un-assigned specs. We intended
to roughly match what keystone was already doing, although our intent
appears to have diverged a little.

This is the first design summit where we have the "concept" in place,
and I would love your help road testing this.

If an operator working session agreed on a problem statement, or set
of problem statements, putting those up as backlog specs reviews would
be a great way to get feedback from the developer community.


On Thu, May 14, 2015 at 8:47 PM, John Garbutt 

You can read more about Nova's backlog specs here:
http://specs.openstack.org/openstack/nova-specs/specs/backlog/


Let me give more detail. To quote the above page:

"
If you have a problem that needs solving, but you are not currently
planning on implementing it, this is the place we can store your
ideas.
These specifications have the problem description completed, but all
other sections are optional.
"

So, you can have all details in the spec, or you can have only the
problem statement complete. Its up to you as a submitter how much
detail you want to provide. I would recommend adding rough ideas into
the alternatives section, and leaving everything else blank except the
problem statement.

We are trying to use a single process for "parked" developer ideas and
operator ideas, so they are on an equal footing.

The reason its not just a "bug" or similar, is so we are able to
review the idea with the submitter, to ensure we have a good enough
problem description, so a developer can pick up and run with the idea,
and turn it into a more complete spec targeted at a specific release.
In addition, we are ensuring that the problem description is in scope.

With that extra detail, do you think this could work?

Thanks,
John


Hi all,

I get the impression from the feedback on a recently submitted item [1] and 
also a read of a clarification that was made to the backlog page [2] that this 
is no longer the way the backlog works? Specifically, a proposed or desired 
solution is now required and the page now talks about it being a place for the 
project team to record decisions only (originally it seemed more focused on 
recording ideas).

 From an NFV/Telco working group perspective we have been trying to convince 
folks for some time to stop leading with pre-defined solutions and focus more - 
at least in the first instance - on documenting their use cases in a way that 
they could be shared with the relevant OpenStack project teams via their 
respective RFE/backlog processes. It seems to me though based on my experiences 
having actually tried to submit one of these ideas as a dry run there is not in 
fact a working process for recording these as originally advertised [3][4][5]? 
Am I misinterpreting the intent of the change here?

Thanks,

Steve

[1] https://review.openstack.org/#/c/224325/
[2] 
http://git.openstack.org/cgit/openstack/nova-specs/commit/doc/source/specs/backlog/index.rst?id=525af38a5ce27bed70d950234e94a48584820943
[3] 
http://git.openstack.org/cgit/openstack/nova-specs/tree/doc/source/specs/backlog/index.rst?id=41bf5302e7ff2b9305b0e8a459e9fe715fba0c38
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064284.html
[5] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064180.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



I don't expect a backlog spec to have a detailed technical solution to 
the problem, but I would expect a clear use case, and if there are high 
level ideas on possible solutions those could be stated, with known 
pros/cons if there are any.


If we aren't going to have backlog specs, what are other teams doing?  I 
think Neutron is doing something like bug reports with RFE in the title 
or tag?  Do those get acted on?


Another reason backlog specs came about was because back at the Intel 
meetup we were looking at really old bugs (over a year or two) which 
were more like performance or other large functional issues, that 
couldn't just be resolved with a simple bug fix. So the 

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

[Eichberger, German]

Ihar,

The Service Group API will be added to FWaaS only and remain experimental in M. 
If the community finds it useful for other areas it can be added to Neutron 
core once it is matures. I think incubating it inside FWaaS will give us the 
velocity to iterate quickly and once it matures a strong API for adoption in 
the wider Neutron.

On the other hand if classifiers mature more quickly/provide the same 
functionality more elegantly we can quickly pivot to that. Since we are trying 
to address an immediate need I would like to experiment with Service Groups 
inside FWaaS first and then use that to shape the classifier API discussion. 
Also, as Sean suggested, we might use the classifier data models under the hood 
— so despite being a different API at first we might arrive at the same shared 
implementation…

Thanks,
German



On 11/13/15, 1:12 AM, "Ihar Hrachyshka"  wrote:

>Paul Carver  wrote:
>
>> On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote:
>>> All I am saying is that IF we merge some classifier API into neutron
>>> core and start using it for core, non-experimental, features, we cannot
>>> later move to some newer version of this API [that you will iterate on]
>>> without leaving a huge pile of compatibility code that would not exist
>>> in the first place if only we thought about proper API in advance. If
>>> that’s what you envision, fine; but I believe it will make adoption of
>>> the ‘evolving’ API a lot slower than it could otherwise be.
>>
>> I don't think I disagree at all. But we don't have a classifier API in  
>> neutron core (unless we consider security groups to be it) and I don't  
>> think anyone is saying that the classifier in networking-sfc should be  
>> merged straight into core as-is. In fact I think we're saying exactly the  
>> opposite, that *a* classifier will sit in networking-sfc, outside of core  
>> neutron, until *some* classifier is merged into core neutron.
>>
>
>That’s why I raised service groups spec in this thread: it seems it’s  
>planned to be added into core, with all compatibility guarantees; and was  
>planned for adoption for the new fwaas API (as per summit sessions). At  
>least I haven’t found anything in their spec that would suggest it’s  
>experimental.
>
>It may mean that at the moment when you arrive to some classifier API that  
>you can claim the best we can get, there can be a rival classifier API in  
>the core tree already.
>
>> The point of networking-sfc isn't the classifier. A classifier is simply  
>> a prerequisite. So by all means let's work on defining and merging into  
>> core neutron a classifier that we can consider non-experimental and  
>> stable for all features to share and depend on, but we don't want SFC to  
>> be non-functional while we wait for that to happen. We can call the  
>> networking-sfc classifier experimental a slap a warning on that it'll be  
>> replaced with the core neutron classifier once such a thing has been  
>> implemented.
>
>__
>OpenStack Development Mailing 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] [freezer] Proposal to add Eldar Nugaev to freezer-core

[Ramirez Garcia, Guillermo]

+1 :)

From: Marzi, Fausto
Sent: Friday, November 13, 2015 4:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [freezer] Proposal to add Eldar Nugaev to freezer-core

Hi All,

I’d like to propose Eldar as core in Freezer, as his help, dedication and 
contribution was incredible for the last 6 months.

Eldar not only worked on improving performances overall, but also on making our 
code more portable, abstracted and implemented outstanding features like the 
parallel backup upload engine.

Please respond with comments, +1s, or objections within one week.

Many thanks,
Fausto

__
OpenStack Development Mailing 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][bugs] Weekly Status Report

[Markus Zoeller]

Below are the stats of the week "Mitaka R-21".
Changes to the previous week are shown in parantheses behind the current
numbers. For example, "28 (+9)" means we have 28 bugs in that category
with an increase of 9 bugs comparing to the previous week.


Stats
=

New bugs which are *not* assigned to any subteam

count: 28 (+9)
query: http://bit.ly/1WF68Iu

New bugs which are *not* triaged

subteam: libvirt 
count: 14 (0)
query: http://bit.ly/1Hx3RrL
subteam: volumes 
count: 12 (+1)
query: http://bit.ly/1NU2DM0
subteam: compute
count: 5 (?)
query: http://bit.ly/1O72RQc
subteam: network : 
count: 4 (0)
query: http://bit.ly/1LVAQdq
subteam: db : 
count: 4 (0)
query: http://bit.ly/1LVATWG
subteam: 
count: 83 (+16)
query: http://bit.ly/1RBVZLn

High prio bugs which are *not* in progress
--
count: 39 (0)
query: http://bit.ly/1MCKoHA

Critical bugs which are *not* in progress
-
count: 0 (0)
query: http://bit.ly/1kfntfk

Readings

* https://wiki.openstack.org/wiki/BugTriage
* https://wiki.openstack.org/wiki/Nova/BugTriage
* 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078252.html


Markus Zoeller/Germany/IBM@IBMDE wrote on 11/06/2015 05:54:59 PM:

> From: Markus Zoeller/Germany/IBM@IBMDE
> To: "OpenStack Development Mailing List" 

> Date: 11/06/2015 05:56 PM
> Subject: [openstack-dev] [nova][bugs] Weekly Status Report
> 
> Hey folks,
> 
> below is the first report of bug stats I intend to post weekly.
> We discussed it shortly during the Mitaka summit that this report
> could be useful to keep the attention of the open bugs at a certain
> level. Let me know if you think it's missing something.
> 
> Stats
> =
> 
> New bugs which are *not* assigned to any subteam
> 
> count: 19
> query: http://bit.ly/1WF68Iu
> 
> 
> New bugs which are *not* triaged
> 
> subteam: libvirt 
> count: 14 
> query: http://bit.ly/1Hx3RrL
> subteam: volumes 
> count: 11
> query: http://bit.ly/1NU2DM0
> subteam: network : 
> count: 4
> query: http://bit.ly/1LVAQdq
> subteam: db : 
> count: 4
> query: http://bit.ly/1LVATWG
> subteam: 
> count: 67
> query: http://bit.ly/1RBVZLn
> 
> 
> High prio bugs which are *not* in progress
> --
> count: 39
> query: http://bit.ly/1MCKoHA
> 
> 
> Critical bugs which are *not* in progress
> -
> count: 0
> query: http://bit.ly/1kfntfk
> 
> 
> Readings
> 
> * https://wiki.openstack.org/wiki/BugTriage
> * https://wiki.openstack.org/wiki/Nova/BugTriage
> * 
> 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078252.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

[openstack-dev] [fuel] Advanced PXE provisioning notes

[Vladimir Eremin]

Forgot about tags, sorry.

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Nov 13, 2015, at 5:13 PM, Vladimir Eremin  wrote:
> 
> Hi folks,
> 
> As you know, to speed up provisioning stage we could use HTTP for downloading 
> kernel and initramfs. There are 3 options to do this: lpxelinux, iPXE (which 
> is successor/fork of gPXE) and GRUB 2, which we were assessed during my work 
> in Yandex and I’d like to share some experience.
> 
> In this note I leave UEFI/iPXE embedding for IPv6 out of scope. Yandex has 
> chosen with iPXE embedding mostly because it’s well-known already and there 
> was less problem to embed iPXE to custom-build hardware than mess with UEFI.
> 
> lpxelinux is a HTTP/FTP enabled variant of usual pxelinux (since syslinux 
> 5.10), so it’s required no chainloading (so no mess with DHCP-server) and no 
> boot config re-design. To provide HTTP URI instead of TFTP, two variants may 
> be used:
> 
> * replace entries in boot config like LINUX from relative path like 
> boot/mykernel to absolute URL like http://boot-server/boot/mykernel
> * provide pxelinux.pathprefix DHCP option [1] contains URL prefix like 
> http://boot-server/
> 
> This is most convenient variant to speed up pxelinux setup. Unfortunately, 
> lpxelinux hasn't built for Ubuntu Trusty, so it should be rebuilt from Debian 
> Sid.
> 
> 
> iPXE is advanced boot loader with many features like IPv6, HTTP and scripting 
> language. Actually, it allows to pass hardware-related information to 
> provisioning server.
> 
> Boot script should be compiled into iPXE, or you will need to set up your 
> DHCP-server [2] to serve different options for different loaders. This option 
> will require to re-write provisioning logic.
> It also support UEFI, so it could be used for IPv6 provisioning.
> 
> I recommend this variant for advanced IPv6 + HTTP provisioning.
> 
> 
> GRUB2 is most advanced option. Unfortunately, it’s still has a bug with IPv6 
> [3], so there is no point to overcomplicate the setup.
> 
> 
> Note that UNDI API is provided correctly by most of modern NIC’s. However, 
> some cards like Mellanox ConnectX and weird Intels is not working correctly. 
> To fix it, iPXE could be built with vendor-specific driver [4]. There is no 
> workaround for lpxelinux.
> 
> [1] http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options
> [2] http://ipxe.org/howto/chainloading
> [3] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458
> [4] http://ipxe.org/appnote/hardware_drivers
> 
> -- 
> With best regards,
> Vladimir Eremin,
> Fuel Deployment 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] [api] consolidate IRC change with #openstack-sdk?

[Dean Troyer]

On Fri, Nov 13, 2015 at 6:58 AM, Sean Dague  wrote:

> I'd like to propose we drop the channel entirely and make #openstack-sdk
> the home of API working group conversations. That's where all the
> openstackclient, openstackclientconfig, and sdk conversations are
> happening. It's where the end consumers of any API WG effort are, so are
> incredibly good sounding boards for things we are doing. There is
> already a large overlap between the two channels, so just pushing
> forward on that means more critical mass for conversations around the
> whole space of a more usable API for users.
>

As part of another project crashing in -sdks I am fine with this. ;)  I
like the idea of some consolidation, ever since Keystone left -dev it's
been REALLY quite there too.

dt

-- 

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

[openstack-dev] [all][glance][api][infra][defcore] last call for feedback on image import

[Brian Rosmaita]

There was a lot of great pre-summit discussion on the Glance spec for image 
import refactoring, and more lively discussion at the summit, but it's been 
very quiet since I posted patch set 5 last week.

Please take a few minutes to look over the revised spec and let the Glance 
community know what you think.  The proposal is pretty ambitious, so we need to 
start working on it very soon.

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

thanks!
brian
__
OpenStack Development Mailing 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] [fuel] Using upstream packages & modules

[Alex Schultz]

On Fri, Nov 13, 2015 at 10:17 AM, Alexander Kostrikov
 wrote:
> Hi, Alex!
> Good to know someone is doing that.
>
> One question about Your initiative:
> Are You going to reimplement all MOS HA features?
> Seems first implementation of 'upstream on Fuel' will be HA-less.
>

My first pass included the MOS HA features as we will still be
leveraging the MOS packages for these items (mysql/haproxy).  My PoC
allows for a different set of OpenStack packages to be set as the
preferred package to use over the current MOS packages which are the
Fuel default. I think eventually we'll need to reevaluate how we can
split out the MOS packages for these features and allow a user to
select which package set to use and still have it 'work'.


Thanks,
-Alex

>
> On Thu, Nov 12, 2015 at 1:51 AM, Alex Schultz  wrote:
>>
>> On Tue, Nov 10, 2015 at 11:10 AM, Vladimir Kuklin 
>> wrote:
>> > Alex
>> >
>> > Thanks for your very detailed answer - it clarified things a bit. So, if
>> > you
>> > would allow me to rephrase it - you are actually conducting a research
>> > on
>> > what is the actual gap between our downstream/fork and upstream
>> > UCA/puppet-openstack. This seems to be a very promising initiative. Are
>> > you
>> > going to come up with some external-user readable report soon?
>> >
>> > Also, regarding multiple distros support.  I think, we need to come up
>> > with
>> > an approach of making 'release manager' piece of Nailgun data driven and
>> > just allow a user to run any distribution he or she wants. Just register
>> > a
>> > set of repos with packages and run it. Actually, we already have it - we
>> > need to make base-image generation for RPM more flexible and any RPM/DEB
>> > based distro should work ok with it.
>> >
>> > The remaining piece is to actually support distro-specific things, e.g.
>> > CentOS/RHEL networking configuration, e.g. l23 network stored config
>> > puppet
>> > providers. But this is a distro-supporter/community burden.
>> >
>> >
>>
>> Yes I hope to have something together by the end of the week.  I've
>> managed to get a controller and compute/cinder nodes up (and passing
>> basic OSTF tests) with what appears to be some minor adjustments to
>> the fuel-library code.  The one thing that gets dropped because of
>> lack of upstream support is nova floating network ranges. There's a
>> pending review that'll get that back in but I also don't know how
>> important it would be to support for this type of configuration.
>> Another issue is the upstream murano module is still a work in
>> progress so that won't work right now either. Hopefully that'll get
>> sorted out in time for the official release of the liberty puppet
>> modules.
>>
>> As I've been working through this, I've noticed that it would be
>> possible to use fuel-plugins to only apply UCA packages to specific
>> nodes via a plugin role. An interesting follow on to this effort would
>> be to use MOS packages for controllers and UCA for Compute or vice
>> versa.  But that should probably be more an academic exercise rather
>> than production one.
>>
>> -Alex
>>
>> >
>> > On Tue, Nov 10, 2015 at 6:25 PM, Alex Schultz 
>> > wrote:
>> >>
>> >> Hey Vladimir,
>> >>
>> >> On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin 
>> >> wrote:
>> >> > Alex
>> >> >
>> >> > That's great to hear that. But be aware - making all of the
>> >> > components
>> >> > work
>> >> > exactly the way they work within MOS is actually identical to
>> >> > upstreaming
>> >> > MOS. We are using some components of different versions to satisfy
>> >> > many
>> >> > requirements for our Reference Architecutre implementation. It will
>> >> > not
>> >> > be
>> >> > so easy to base them upon existing 3rd party distributions. For
>> >> > example,
>> >> > `read timeout` for SQL requests is crucial for our HA as it handles
>> >> > cases
>> >> > when an SQL node dies while serving the request. And you will find
>> >> > myriads
>> >> > of them. And as we do not control things in upstream, we will always
>> >> > have
>> >> > some downstream divergence.
>> >> >
>> >>
>> >> Yes, I'm aware that it'll be an effort to make it work identically to
>> >> MOS.  Currently that's not my goal. My goal is to get it working at
>> >> all and be able to document the deficiencies when using upstream
>> >> packages/modules vs MOS provided ones.  Once we have documented these
>> >> differences we will be able to make decisions as to what efforts
>> >> should be made if we choose to address the differences.  The read
>> >> timeout thing seems to be an issue with what mysql python driver is
>> >> used so that could easily be configurable based on a packages or a
>> >> configuration option.
>> >>
>> >> > I guess, the optimal solution is to figure out the actual divergence
>> >> > between
>> >> > upstream and downstream and try to push things upstream as hard as we
>> >> > can,
>> >> > 

Re: [openstack-dev] [fuel] Advanced PXE provisioning notes

[Vladimir Eremin]

Hi Sean,

Yes, iPXE could be one-to-rule-them-all replacement, because of HTTP, IPv6 and 
UEFI support.

lpxelinux is good, but for one-line enhancements.

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Nov 13, 2015, at 6:17 PM, Sean Collins  wrote:
> 
> Excellent info, thanks.
> 
> Do you think long term iPXE is the way to go? IPv6 support would be a big 
> motivation - but it sounds like it would take some work to accomplish.
> 
> On Fri, Nov 13, 2015 at 10:02 AM, Vladimir Eremin  > wrote:
> Forgot about tags, sorry.
> 
> --
> With best regards,
> Vladimir Eremin,
> Fuel Deployment Engineer,
> Mirantis, Inc.
> 
> 
> 
> > On Nov 13, 2015, at 5:13 PM, Vladimir Eremin  > > wrote:
> >
> > Hi folks,
> >
> > As you know, to speed up provisioning stage we could use HTTP for 
> > downloading kernel and initramfs. There are 3 options to do this: 
> > lpxelinux, iPXE (which is successor/fork of gPXE) and GRUB 2, which we were 
> > assessed during my work in Yandex and I’d like to share some experience.
> >
> > In this note I leave UEFI/iPXE embedding for IPv6 out of scope. Yandex has 
> > chosen with iPXE embedding mostly because it’s well-known already and there 
> > was less problem to embed iPXE to custom-build hardware than mess with UEFI.
> >
> > lpxelinux is a HTTP/FTP enabled variant of usual pxelinux (since syslinux 
> > 5.10), so it’s required no chainloading (so no mess with DHCP-server) and 
> > no boot config re-design. To provide HTTP URI instead of TFTP, two variants 
> > may be used:
> >
> > * replace entries in boot config like LINUX from relative path like 
> > boot/mykernel to absolute URL like http://boot-server/boot/mykernel 
> > 
> > * provide pxelinux.pathprefix DHCP option [1] contains URL prefix like 
> > http://boot-server/ 
> >
> > This is most convenient variant to speed up pxelinux setup. Unfortunately, 
> > lpxelinux hasn't built for Ubuntu Trusty, so it should be rebuilt from 
> > Debian Sid.
> >
> >
> > iPXE is advanced boot loader with many features like IPv6, HTTP and 
> > scripting language. Actually, it allows to pass hardware-related 
> > information to provisioning server.
> >
> > Boot script should be compiled into iPXE, or you will need to set up your 
> > DHCP-server [2] to serve different options for different loaders. This 
> > option will require to re-write provisioning logic.
> > It also support UEFI, so it could be used for IPv6 provisioning.
> >
> > I recommend this variant for advanced IPv6 + HTTP provisioning.
> >
> >
> > GRUB2 is most advanced option. Unfortunately, it’s still has a bug with 
> > IPv6 [3], so there is no point to overcomplicate the setup.
> >
> >
> > Note that UNDI API is provided correctly by most of modern NIC’s. However, 
> > some cards like Mellanox ConnectX and weird Intels is not working 
> > correctly. To fix it, iPXE could be built with vendor-specific driver [4]. 
> > There is no workaround for lpxelinux.
> >
> > [1] http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options 
> > 
> > [2] http://ipxe.org/howto/chainloading 
> > [3] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458 
> > 
> > [4] http://ipxe.org/appnote/hardware_drivers 
> > 
> >
> > --
> > With best regards,
> > Vladimir Eremin,
> > Fuel Deployment 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] Last sync from oslo-incubator

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2015-11-13 07:44:26 -0500:
> Hear Hear! Thierry. Many many thanks to everyone who made this possible.
> 
> -- Dims

Indeed, as Thierry said, it has truly been a group effort, spanning
many cycles and involving many, many contributors.

Thank you to everyone to contributed, via planning, analysis,
patches, documentation, and reviews, to make the Oslo libraries
real!

Doug

> 
> On Fri, Nov 13, 2015 at 4:44 AM, Thierry Carrez  wrote:
> > Davanum Srinivas wrote:
> >> A long time ago, oslo-incubator had a lot of code, we have made most
> >> of the code to oslo.* libraries. There's very little code left and
> >> we'd like to stop hosting common code in oslo-incubator repository. We
> >> encourage everyone to adopt the code they have in their repos under
> >> openstack/common into their own namespace/packaging as we will be
> >> getting rid of any remaining python modules in oslo-incubator.
> >> [...]
> >
> > So this is pretty funny, since oslo-incubator was actually created
> > exactly 3 years ago today. Three years ago we clearly stated that common
> > code between OpenStack projects should ultimately become libraries and
> > no longer be copy-pasted. It took us 3 years to get to the point where
> > almost all the code has been graduated.
> >
> > Some would say it's a long time, but considering this is a
> > cross-project, technical-debt-reduction effort that typically falls
> > short of resources in a tragedy of the commons, I prefer to see it as a
> > great achievement for us as a community.
> >
> > Thanks to all the people that drove Oslo from where it was to where it
> > is today, including (but not limited to) Mark McLoughlin, Doug Hellmann
> > and Davanum Srinivas.
> >
> > --
> > 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

Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Ryan Hallisey]

+1 Nice work Michal.

-Ryan

- Original Message -
From: "Sam Yaple" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, November 13, 2015 1:15:05 PM
Subject: Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core 
Reviewer (nihilfer on IRC)

Michal does great patches and is very receptive to feedback. +1 for me. 

We may need to call him Michal2 though. Might get confusing to have multiple 
Michals on the team. 

Sam Yaple 

On Thu, Nov 12, 2015 at 9:23 AM, Paul Bourke < paul.bou...@oracle.com > wrote: 


+1 


On 12/11/15 08:41, Steven Dake (stdake) wrote: 



Hey folks, 

Its been awhile since we have had a core reviewer nomination, but I 
really feel like Michal has the right stuff. If you look at the 30 day 
stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in 
a 30 day period. He is beating 2/3rds of our core reviewer team on all 
stats. I think his reviews, while could use a little more depth, are 
solid and well considered. That said he participates on the mailing 
list more then others and has been very active in IRC. He has come up 
to speed on the code base in quick order and I expect if he keeps pace, 
the top reviewers in Kolla will be challenged to maintain their spots :) 
Consider this proposal as a +1 vote from me. 

As a reminder, our core review process requires 3 core reviewer +1 
votes, with no core reviewer –1 (veto) votes within a 1 week period. If 
your on the fence, best to abstain :) I'll close voting November 20th, 
or sooner if there I a veto vote or a unanimous vote. 

Regards 
-steve 

http://stackalytics.com/report/contribution/kolla-group/30 


__ 
OpenStack Development Mailing 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] [neutron][vpnaas] VPNaaS project status

[Al Miller]

Paul, I echo the prior comments.  Your hard work and persistence in getting the 
recent new features written, as well as your review suggestions are very much 
appreciated!

Thanks,

Al


From: Paul Michali [mailto:p...@michali.net]
Sent: Thursday, November 12, 2015 8:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Neutron community,

During the past several releases, while leading the VPNaaS project, I've seen 
many great enhancements and features added to the VPNaaS project by the 
community, including support for StrongSwan, Libreswan, completion of the 
project split out, functional and rally tests, endpoint groups, multiple local 
subnets, vendor drivers, etc.

There is still work needed (certificate support the most important, followed by 
documentation and scale testing), but there is a solid (in my bias and 
subjective opinion :) foundation in place for people to play with this 
capability.

As I mentioned to Armando at the summit, it's time for me to move on to other 
areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
up work on the project over the next few weeks. I'll still try to review VPNaaS 
commits as much as possible, and be available to advise in this area.

Towards that end, I've updated the VPNaaS wiki page 
(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
outstanding work that can be done in this area, from important to wish items.  
Meetings have transitioned to on-demand, and future meetings can either be done 
as an on-demand topic in the Neutron IRC meeting, or as an on-demand special 
meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
opinion of importance, priority, relevance, etc.

Regards,

PCM (pc_m)
__
OpenStack Development Mailing 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] [fuel] Advanced PXE provisioning notes

[Sean M. Collins]

[sorry for the weirdness - this was cross-posted to two lists]

On Fri, Nov 13, 2015 at 11:30:53AM EST, Vladimir Eremin wrote:
> Hi Sean,
> 
> Yes, iPXE could be one-to-rule-them-all replacement, because of HTTP, IPv6 
> and UEFI support.
> 

OK - based on your research it sounds like iPXE would be a good
investment long term, just based on those three features. 

-- 
Sean M. Collins

__
OpenStack Development Mailing 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][api] New API Guidelines Ready for Cross Project Review

[Everett Toews]

Hi All,

The following API guidelines are ready for cross project review. They will be 
merged on Nov. 20 if there's no further feedback.

1. Add introduction for API micro version guideline
https://review.openstack.org/#/c/187112/

2. Add description of pagination parameters
https://review.openstack.org/#/c/190743/

3. A guideline for errors
https://review.openstack.org/#/c/167793/

Cheers,
Everett


__
OpenStack Development Mailing 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] [puppet] A note about composite namevar integration for puppet-keystone module.

[Sofer Athlan-Guyot]

Hi,

A lot of changes has taken place under the hood of those three providers
in the keystone module:
 - keystone_user;
 - keystone_tenant;
 - keystone_user_role;

This note will highlight the changes.  This has two goals:
 - make a broader range of puppet users aware of the change and the new
   syntax now available to them (the old syntax is of course still
   supported and not planned for deprecation);
 - give ideas to puppet developer when creating a provider;

For those not interested in the details, you can have a quick overview
of the new syntax available to puppet user here [1].  Related is the
complete review of the default domain behavior there [2].

For the other read on.

First thing first, what is composite namevar ?

In short, it's the ability in puppet to define a Type with several
"keys" not, just the resource's name (think isnamevar).  That's it for
the short definition.

Now, why this change has taken place at all?

With the arrival of domain scope in Keystone V3, two main problems
appeared. First how to have the domain specified and second and related
to the first how to get the default domain for retro-compatibility with
Keystone v2.  I won't write about the latter here.  A full description
of the choices made for the past, current and future is there [2].

For the former, a strict title scheme was chosen.  For instance to create
"user_one" in domain "domain_one" you had to do this:

keystone_user { 'user_one::domain_one': ensure => present }

For user_role this scheme was chosen for domain scope:

keystone_user_role { 'user_one::domain_one@::domain_one':
  ensure => present,
  roles  => ['admin']
}

and this one for project scope:

keystone_user_role { 'user_one::domain_one@project_one::domain_one':
  ensure => present,
  roles  => ['admin']
}

The basic problem was that, you couldn't have meaningless name[4], with a
syntax like this:

keystone_user { 'meanlinglesstitle':
  name   => 'user_one',
  domain => 'domain_one',
  ensure => present, 
}

or in a more natural way:

keystone_user { 'user_one':
  domain => 'domain_one',
  ensure => present, 
}


So to be able to have the three ways, we turn to composite namevar.  A
puppet feature that let you have several "keys" to identify a resource,
not just its name.

It leads to the syntax described in [1], which offer far more
flexibility in the naming scheme.

On the coding side, it leads to some big refactor.  For instance all the
default_domain handling is done in one place only.  The resource's name
can now be fully calculated at puppet compile catalog time, removing the
need to wait for a full keystone installation to try and guess the
default domain.  The parsing of the name is done in the type definition
file only.  The dependencies between the resource have a predictable
name (think autorequire).

Now, for the puppet coder thinking about making a new resource
Type/Provider where the name has to be parsed or the natural key of the
resource is a composite one, the composite namevar solution is a
something to linger on.  The detail of the implementation in keystone
are there [3].  See for instance the /lib/puppet/type/keystone_user.rb
and lib/puppet/provider/keystone_user/openstack.rb files.  Beware
though, that a bug in pending on the puppetlab side if you use prefetch
in your resource definition.  The detail there [5].  It is solved in the
module in [6]

That's all folks,

[1] https://review.openstack.org/244846
[2] https://etherpad.openstack.org/p/keystone_no_domain
[3] https://review.openstack.org/226919
[4] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074185.html
[5] https://tickets.puppetlabs.com/browse/PUP-5302
[6] 
https://review.openstack.org/#/c/226919/47/lib/puppet_x/keystone/composite_namevar/helpers/utilities.rb
-- 
Sofer Athlan-Guyot

__
OpenStack Development Mailing 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][upgrade] Grenade multinode partial upgrade

[Sean M. Collins]

On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
> Ok, I top responded with the details of the job, honestly I think it's
> just a project-config change to get up and running, and then hacking at
> the bugs that fall out.

Thanks - that was super helpful. 

I'm thinking of working on the following on Monday:

1) capture that somewhere in the upgrade docs we're putting together in 
neutron's devref

2) Adding the stanza to project-config to get grenade running for
Neutron

3) Take a look at the patches that Armando linked a couple emails back
in this thread.

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [designate] Records for floating addresses are not removed when an instance is removed

[Matt Fischer]

You can do it like we did for juno Designate as covered in our Vancouver
talk start about 21 minutes:

https://www.youtube.com/watch?v=N8y51zqtAPA

We've not ported the code to Kilo or Liberty yet but the approach may still
work.


On Fri, Nov 13, 2015 at 9:49 AM, Jaime Fernández  wrote:

> When removing an instance (with one floating address assigned) in Horizon,
> designate-sink only receives an event for instance removal. As a result,
> only the instance is removed but the floating addresses records are not
> removed.
> I'm not sure if it's a bug in openstack (I guess that it should also
> notify about the unassignment of floating addresses) or it should be
> considered in the nova notification handler (
> https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py#L72
> ).
> However, it is not possible to add metadata in the floating IP records to
> save the instance_id and remove them easily when an instance is removed.
> What's the best approach to remove the floating address records of an
> instance that is being removed?
>
> __
> OpenStack Development Mailing 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] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Jeff Peeler]

> On 12/11/15 08:41, Steven Dake (stdake) wrote:
>
> Hey folks,
>
> Its been awhile since we have had a core reviewer nomination, but I
> really feel like Michal has the right stuff. If you look at the 30 day
> stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in
> a 30 day period. He is beating 2/3rds of our core reviewer team on all
> stats. I think his reviews, while could use a little more depth, are
> solid and well considered. That said he participates on the mailing
> list more then others and has been very active in IRC. He has come up
> to speed on the code base in quick order and I expect if he keeps pace,
> the top reviewers in Kolla will be challenged to maintain their spots :)
> Consider this proposal as a +1 vote from me.
>
> As a reminder, our core review process requires 3 core reviewer +1
> votes, with no core reviewer –1 (veto) votes within a 1 week period. If
> your on the fence, best to abstain :) I'll close voting November 20th,
> or sooner if there I a veto vote or a unanimous vote.
>
> Regards
> -steve
>
> http://stackalytics.com/report/contribution/kolla-group/30

+1!

__
OpenStack Development Mailing 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][api] New API Guidelines Ready for Cross Project Review

[Ed Leafe]

On Nov 13, 2015, at 12:55 PM, Everett Toews  wrote:

>> Specifically this patch, or the ones dependent on it? Because this specific 
>> patch doesn't actually say anything.
> 
> Specifically this patch. Just looking to initially move forward in some small 
> way on this.

I can see this generating a lot of controversy! :)

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] [freezer] Proposal to add Eldar Nugaev to freezer-core

[Vanni, Fabrizio]

+1 ;)

From: Marzi, Fausto
Sent: 13 November 2015 16:39
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [freezer] Proposal to add Eldar Nugaev to freezer-core

Hi All,

I'd like to propose Eldar as core in Freezer, as his help, dedication and 
contribution was incredible for the last 6 months.

Eldar not only worked on improving performances overall, but also on making our 
code more portable, abstracted and implemented outstanding features like the 
parallel backup upload engine.

Please respond with comments, +1s, or objections within one week.

Many thanks,
Fausto
__
OpenStack Development Mailing 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] [freezer] Proposal to add Pierre-Arthur Mathieu to freezer-core

[Vanni, Fabrizio]

+1 ;)

From: Marzi, Fausto
Sent: 13 November 2015 16:45
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [freezer] Proposal to add Pierre-Arthur Mathieu to 
freezer-core

Hi All,

I'd like to propose Pierre as core in Freezer.

Pierre dedication was amazing on code review, documentation, architectural 
decision and overall greatly improving the quality of the Freezer Project.
Freezer wouldn't be to the point where it is without Pierre.

Please respond with comments, +1s, or objections within one week.

Many thanks,
Fausto

__
OpenStack Development Mailing 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] [puppet] about $::os_service_default

[Cody Herriges]

Yanis Guenane wrote:
> 
> On 11/03/2015 02:57 PM, Emilien Macchi wrote:
>> I'm seeing a lot of patches using the new $::os_service_default.
>>
>> Please stop trying to using it at this time. The feature is not stable
>> yet and we're testing it only for puppet-cinder module.
>> I've heard Yanis found something that is not backward compatible with
>> logging, but he's away this week so I suggest we wait next week.
>>
>> In the meantime, please do not use $::os_service_default outside
>> puppet-cinder.
>>
>> Thanks a lot,
> After a deeper investigation, the issue with logging[1] is only true if
> a user is using the puppet-openstack to only configure the component and
> not relying on it to install the RDO/UCA packages.
> 
> On RDO, the file /usr/lib/systemd/system/openstack-cinder-api.service is
> provided. It specifies :
> 
>   ExecStart=/usr/bin/cinder-api --config-file
> /usr/share/cinder/cinder-dist.conf \
> --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log
> 
> On Ubuntu, the file /etc/init/cinder-api.conf is provided. It specfies :
> 
>   exec start-stop-daemon --start --chuid cinder --exec /usr/bin/cinder-api \
>  -- --config-file=/etc/cinder/cinder.conf
> --log-file=/var/log/cinder/cinder-api.log
> 
> In my understanding, this means that when using packages none of log-dir
> and log-file will ever be taken in account.
> 
> So the only use case moving those values to $::os_service_default might
> impact are for the people relying directly on the python package.
> 
> This raises two questions I'd like to ask :
> 
>   * Do lot of people use puppet-openstack modules relying on the python
> package directly ?
>   * Should we be opinionated here ? If user relies on the python
> packages, we can consider that an advanced use-case and expect the user
> to know exactly what she needs to configure. Plus we do not handle the
> use case where we want a file for cinder-volume.log and cinder-backup.log.
> 
> [1]
> https://trello.com/c/XLJJJBF0/71-move-modules-to-the-os-service-default-pattern
> 

My opinion is that installing directly from python pip is not currently
officially supported in the modules and specifically trying to take that
use case into account when we do not support it either leaves us in a
place where we have to go full in on supporting them or put the modules
in a state that thoroughly frustrates and misleads users.

If we were going to put priority on which packaging systems to support
next; I'd prefer docker over pip.


-- 
Cody



signature.asc
Description: OpenPGP 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] [openstack][devstack]Openstack devstack installation failing.

[Abhishek Shrivastava]

Hi Folks,

I have been trying to install devstack on Ubuntu 14.04 for the last 5 times
but I am still getting the following error message while it is Initializing
tempest:

*ERROR (ConnectionRefused): Unable to establish connection to
http://127.0.0.1:8774/v2.1/ *

So, if anyone can help me resolve this issue please do reply.

-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte 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] [all][api] New API Guidelines Ready for Cross Project Review

[Everett Toews]

> On Nov 13, 2015, at 12:01 PM, John Dickinson  wrote:
> 
> 
> 
> On 13 Nov 2015, at 9:42, Everett Toews wrote:
> 
>> Hi All,
>> 
>> The following API guidelines are ready for cross project review. They will 
>> be merged on Nov. 20 if there's no further feedback.
>> 
>> 1. Add introduction for API micro version guideline
>> https://review.openstack.org/#/c/187112/
> 
> Specifically this patch, or the ones dependent on it? Because this specific 
> patch doesn't actually say anything.

Specifically this patch. Just looking to initially move forward in some small 
way on this.

Everett


__
OpenStack Development Mailing 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] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Sam Yaple]

Michal does great patches and is very receptive to feedback. +1 for me.

We may need to call him Michal2 though. Might get confusing to have
multiple Michals on the team.

Sam Yaple

On Thu, Nov 12, 2015 at 9:23 AM, Paul Bourke  wrote:

> +1
>
>
> On 12/11/15 08:41, Steven Dake (stdake) wrote:
>
>> Hey folks,
>>
>> Its been awhile since we have had a  core reviewer nomination, but I
>> really feel like Michal has the right stuff.  If you look at the 30 day
>> stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in
>> a 30 day period.  He is beating 2/3rds of our core reviewer team on all
>> stats.  I think his reviews, while could use a little more depth, are
>> solid and well considered.  That said he participates on the mailing
>> list more then others and has been very active in IRC.  He has come up
>> to speed on the code base in quick order and I expect if he keeps pace,
>> the top reviewers in Kolla will be challenged to maintain their spots :)
>>   Consider this proposal as a +1 vote from me.
>>
>> As a reminder, our core review process requires 3 core reviewer +1
>> votes, with no core reviewer –1 (veto) votes within a 1 week period.  If
>> your on the fence, best to abstain :)  I'll close voting November 20th,
>> or sooner if there I a veto vote or a unanimous vote.
>>
>> Regards
>> -steve
>>
>> http://stackalytics.com/report/contribution/kolla-group/30
>>
>>
>> __
>> OpenStack Development Mailing 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] [neutron][vpnaas] VPNaaS project status

[Paul Michali]

Thanks folks.

I have gone through all of the "open" VPN bugs and commented/updated them.
The Wiki was updated with references to some of the LP bugs of particular
interest.

Regards,

PCM (pc_m)

On Fri, Nov 13, 2015 at 3:42 AM Elena Ezhova  wrote:

> Thanks for everything you've done for VPNaaS, Paul! Your help and guidance
> was (and is) always very helpful.
>
> On Thu, Nov 12, 2015 at 5:56 PM, Paul Michali  wrote:
>
>> Neutron community,
>>
>> During the past several releases, while leading the VPNaaS project, I've
>> seen many great enhancements and features added to the VPNaaS project by
>> the community, including support for StrongSwan, Libreswan, completion of
>> the project split out, functional and rally tests, endpoint groups,
>> multiple local subnets, vendor drivers, etc.
>>
>> There is still work needed (certificate support the most important,
>> followed by documentation and scale testing), but there is a solid (in my
>> bias and subjective opinion :) foundation in place for people to play with
>> this capability.
>>
>> As I mentioned to Armando at the summit, it's time for me to move on to
>> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
>> wrapping up work on the project over the next few weeks. I'll still try to
>> review VPNaaS commits as much as possible, and be available to advise in
>> this area.
>>
>> Towards that end, I've updated the VPNaaS wiki page (
>> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think
>> are outstanding work that can be done in this area, from important to wish
>> items.  Meetings have transitioned to on-demand, and future meetings can
>> either be done as an on-demand topic in the Neutron IRC meeting, or as an
>> on-demand special meeting.
>>
>> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to
>> my opinion of importance, priority, relevance, etc.
>>
>> Regards,
>>
>> PCM (pc_m)
>>
>> __
>> OpenStack Development Mailing 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][api] New API Guidelines Ready for Cross Project Review

[John Dickinson]

On 13 Nov 2015, at 9:42, Everett Toews wrote:

> Hi All,
>
> The following API guidelines are ready for cross project review. They will be 
> merged on Nov. 20 if there's no further feedback.
>
> 1. Add introduction for API micro version guideline
> https://review.openstack.org/#/c/187112/

Specifically this patch, or the ones dependent on it? Because this specific 
patch doesn't actually say anything.

>
> 2. Add description of pagination parameters
> https://review.openstack.org/#/c/190743/
>
> 3. A guideline for errors
> https://review.openstack.org/#/c/167793/
>
> Cheers,
> Everett
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


signature.asc
Description: OpenPGP 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

Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing ongate.

[Gregory Haynes]

Excerpts from Hongbin Lu's message of 2015-11-13 16:05:24 +:
> I am going to share something that might be off the topic a bit.
> 
> Yesterday, I was pulled to the #openstack-infra channel to participant a 
> discussion, which is related to the atomic image download in Magnum. It looks 
> the infra team is not satisfied with the large image size. In particular, 
> they need to double the timeout to accommodate the job [1] [2], which made 
> them unhappy. Is there a way to reduce the image size? Or even better, is it 
> possible to build the image locally instead of downloading it?
> 
> [1] https://review.openstack.org/#/c/242742/
> [2] https://review.openstack.org/#/c/244847/
> 
> Best regards,
> Hongbin

I am not sure how much of the current job is related to image
downloading (a previous message suggested maybe it isn't much?). If it
is an issue though - we have a tool for making images (DIB[1]) which is
already used by many OpenStack projects and it would be great if support
was added for it to make images that are useful to Magnum. DIB is also
pretty good at making images which are as small as possible, so it might
be a good fit.

I looked at doing this a while ago, and IIRC the atomic images were just
an lvm with a partition for a rootfs and a partition for a docker
overlay fs. The docs look like more options could be supported, but
regardless this seems like something DIB could do if someone was willing
to invest the effort.

Cheers,
Greg

1: http://docs.openstack.org/developer/diskimage-builder/

__
OpenStack Development Mailing 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][Testing] Reduce Functional testingongate.

[Ton Ngo]

We discussed this topics at the last design summit and a BP has been opened
to track the effort:
https://blueprints.launchpad.net/magnum/+spec/ubuntu-image-build
Ton,



From:   Gregory Haynes 
To: openstack-dev 
Date:   11/13/2015 10:03 AM
Subject:Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing
ongate.



Excerpts from Hongbin Lu's message of 2015-11-13 16:05:24 +:
> I am going to share something that might be off the topic a bit.
>
> Yesterday, I was pulled to the #openstack-infra channel to participant a
discussion, which is related to the atomic image download in Magnum. It
looks the infra team is not satisfied with the large image size. In
particular, they need to double the timeout to accommodate the job [1] [2],
which made them unhappy. Is there a way to reduce the image size? Or even
better, is it possible to build the image locally instead of downloading
it?
>
> [1] https://review.openstack.org/#/c/242742/
> [2] https://review.openstack.org/#/c/244847/
>
> Best regards,
> Hongbin

I am not sure how much of the current job is related to image
downloading (a previous message suggested maybe it isn't much?). If it
is an issue though - we have a tool for making images (DIB[1]) which is
already used by many OpenStack projects and it would be great if support
was added for it to make images that are useful to Magnum. DIB is also
pretty good at making images which are as small as possible, so it might
be a good fit.

I looked at doing this a while ago, and IIRC the atomic images were just
an lvm with a partition for a rootfs and a partition for a docker
overlay fs. The docs look like more options could be supported, but
regardless this seems like something DIB could do if someone was willing
to invest the effort.

Cheers,
Greg

1: http://docs.openstack.org/developer/diskimage-builder/

__
OpenStack Development Mailing 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] [puppet] about $::os_service_default

[Matt Fischer]

This work is already being done by Clayton (and to a lesser extent me).
>From the openstack modules POV it mainly involves moving the packaging code
into a separate place [1][2] and then integrating with puppet-os_docker[3].
This os_docker work is only done for designate and heat and of course
requires os_docker which is not official and is rather specific to us.

As long as the external hooks are in place folks could plugin their own
venv, docker, tarball, or whatever way to install code.

[1] -
https://github.com/openstack/puppet-designate/commit/5a37cc81276cb8f8ee6dca9b9b532930e6ac86de
[2] -
https://github.com/openstack/puppet-heat/commit/dca9fe942b99b9c30e31167e4736058767738f21
[3] - https://github.com/twc-openstack/puppet-os_docker



On Fri, Nov 13, 2015 at 11:13 AM, Cody Herriges  wrote:

> Yanis Guenane wrote:
> >
> > On 11/03/2015 02:57 PM, Emilien Macchi wrote:
> >> I'm seeing a lot of patches using the new $::os_service_default.
> >>
> >> Please stop trying to using it at this time. The feature is not stable
> >> yet and we're testing it only for puppet-cinder module.
> >> I've heard Yanis found something that is not backward compatible with
> >> logging, but he's away this week so I suggest we wait next week.
> >>
> >> In the meantime, please do not use $::os_service_default outside
> >> puppet-cinder.
> >>
> >> Thanks a lot,
> > After a deeper investigation, the issue with logging[1] is only true if
> > a user is using the puppet-openstack to only configure the component and
> > not relying on it to install the RDO/UCA packages.
> >
> > On RDO, the file /usr/lib/systemd/system/openstack-cinder-api.service is
> > provided. It specifies :
> >
> >   ExecStart=/usr/bin/cinder-api --config-file
> > /usr/share/cinder/cinder-dist.conf \
> > --config-file /etc/cinder/cinder.conf --logfile
> /var/log/cinder/api.log
> >
> > On Ubuntu, the file /etc/init/cinder-api.conf is provided. It specfies :
> >
> >   exec start-stop-daemon --start --chuid cinder --exec
> /usr/bin/cinder-api \
> >  -- --config-file=/etc/cinder/cinder.conf
> > --log-file=/var/log/cinder/cinder-api.log
> >
> > In my understanding, this means that when using packages none of log-dir
> > and log-file will ever be taken in account.
> >
> > So the only use case moving those values to $::os_service_default might
> > impact are for the people relying directly on the python package.
> >
> > This raises two questions I'd like to ask :
> >
> >   * Do lot of people use puppet-openstack modules relying on the python
> > package directly ?
> >   * Should we be opinionated here ? If user relies on the python
> > packages, we can consider that an advanced use-case and expect the user
> > to know exactly what she needs to configure. Plus we do not handle the
> > use case where we want a file for cinder-volume.log and
> cinder-backup.log.
> >
> > [1]
> >
> https://trello.com/c/XLJJJBF0/71-move-modules-to-the-os-service-default-pattern
> >
>
> My opinion is that installing directly from python pip is not currently
> officially supported in the modules and specifically trying to take that
> use case into account when we do not support it either leaves us in a
> place where we have to go full in on supporting them or put the modules
> in a state that thoroughly frustrates and misleads users.
>
> If we were going to put priority on which packaging systems to support
> next; I'd prefer docker over pip.
>
>
> --
> Cody
>
>
> __
> OpenStack Development Mailing 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] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Harm Weites]

+1 :)

Jeff Peeler schreef op 2015-11-13 19:51:

On 12/11/15 08:41, Steven Dake (stdake) wrote:

Hey folks,

Its been awhile since we have had a core reviewer nomination, but I
really feel like Michal has the right stuff. If you look at the 30 day
stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits 
in

a 30 day period. He is beating 2/3rds of our core reviewer team on all
stats. I think his reviews, while could use a little more depth, are
solid and well considered. That said he participates on the mailing
list more then others and has been very active in IRC. He has come up
to speed on the code base in quick order and I expect if he keeps 
pace,
the top reviewers in Kolla will be challenged to maintain their spots 
:)

Consider this proposal as a +1 vote from me.

As a reminder, our core review process requires 3 core reviewer +1
votes, with no core reviewer –1 (veto) votes within a 1 week period. 
If

your on the fence, best to abstain :) I'll close voting November 20th,
or sooner if there I a veto vote or a unanimous vote.

Regards
-steve

http://stackalytics.com/report/contribution/kolla-group/30


+1!

 
 
 
___

OpenStack Development Mailing 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][neutron][upgrade] Grenade multinode partial upgrade

[Sean Dague]

On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
>> Ok, I top responded with the details of the job, honestly I think it's
>> just a project-config change to get up and running, and then hacking at
>> the bugs that fall out.
> 
> Thanks - that was super helpful. 
> 
> I'm thinking of working on the following on Monday:
> 
> 1) capture that somewhere in the upgrade docs we're putting together in 
> neutron's devref
> 
> 2) Adding the stanza to project-config to get grenade running for
> Neutron
> 
> 3) Take a look at the patches that Armando linked a couple emails back
> in this thread.

I don't think that any of the patches listed there are needed. This was
part of the reason I -2ed that direction in the last cycle. It required
a separate special code path for partial upgrade setup which was very
synthetic (and honestly kind of confusing to debug).

The new approach means if you did upgrade for the all-in-one case, and
you did multinode setup with worker processes on the subnode, you just
make a config where you do them both at the same time, and you have
partial upgrade.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][qos][fwaas] service groups vs. traffic classifiers

[Sean M. Collins]

On Fri, Nov 13, 2015 at 01:53:49AM EST, Paul Carver wrote:
> On 11/3/2015 1:03 PM, Sean M. Collins wrote:
> >Anyway, the code is currently up on GitHub - I just threw it on there
> >because I wanted to scratch my hacking itch quickly.
> >
> >https://github.com/sc68cal/neutron-classifier
> >
> 
> Sean,
> 
> How much is needed to turn your models into something runnable to the extent
> of populating a database? I'm not really all that proficient with SQL
> Alchemy or SQL in general so I can't really visualize what the polymorphism
> statements in your model actually create.

Yep - the doc links are still not well organized, but when I was writing
the code I had the same issue, so I stuck a lot of debugging stuff in so
I could see the CREATE statements.

https://github.com/sc68cal/neutron-classifier/blob/master/doc/source/usage.rst

It's a little basic right now, it's just one classifier added to a
chain - I'm going to take that and build it out more to show the full
classifier chain that would be created in the DB for something like a
security group or a firewall rule, so you see all the classifiers being
created. Bear with me :)

> I'd like to create a few classifier rules and see what gets populated into
> the database and also to understand complicated of an SQL query is SQL
> Alchemy generating in order to reassemble each rule from its polymorphic
> representation in the database.


Yeah. Right now my unit tests are super hacky, since I'm creating a DB
engine and session and passing them into the API. It's dumb and ugly but
I'm still reading through oslo_db's dev docs and some of how Neutron
creates the database session and packs it into a context so it can be
passed around, so my code doesn't make you want to claw your eyes out.

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [puppet] about $::os_service_default

[Clayton O'Neill]

What Matt said.

I think we don’t need to explicitly support people that aren’t using
distribution packages, we just want to try to avoid making harder things
harder.  I don’t see a need to go out of our way to support it.  Anyone
that isn’t using distro packages should be able to figure out how to set
logdir on their own.

On Fri, Nov 13, 2015 at 1:46 PM, Matt Fischer  wrote:

> This work is already being done by Clayton (and to a lesser extent me).
> From the openstack modules POV it mainly involves moving the packaging code
> into a separate place [1][2] and then integrating with puppet-os_docker[3].
> This os_docker work is only done for designate and heat and of course
> requires os_docker which is not official and is rather specific to us.
>
> As long as the external hooks are in place folks could plugin their own
> venv, docker, tarball, or whatever way to install code.
>
> [1] -
> https://github.com/openstack/puppet-designate/commit/5a37cc81276cb8f8ee6dca9b9b532930e6ac86de
> [2] -
> https://github.com/openstack/puppet-heat/commit/dca9fe942b99b9c30e31167e4736058767738f21
> [3] - https://github.com/twc-openstack/puppet-os_docker
>
>
>
> On Fri, Nov 13, 2015 at 11:13 AM, Cody Herriges 
> wrote:
>
>> Yanis Guenane wrote:
>> >
>> > On 11/03/2015 02:57 PM, Emilien Macchi wrote:
>> >> I'm seeing a lot of patches using the new $::os_service_default.
>> >>
>> >> Please stop trying to using it at this time. The feature is not stable
>> >> yet and we're testing it only for puppet-cinder module.
>> >> I've heard Yanis found something that is not backward compatible with
>> >> logging, but he's away this week so I suggest we wait next week.
>> >>
>> >> In the meantime, please do not use $::os_service_default outside
>> >> puppet-cinder.
>> >>
>> >> Thanks a lot,
>> > After a deeper investigation, the issue with logging[1] is only true if
>> > a user is using the puppet-openstack to only configure the component and
>> > not relying on it to install the RDO/UCA packages.
>> >
>> > On RDO, the file /usr/lib/systemd/system/openstack-cinder-api.service is
>> > provided. It specifies :
>> >
>> >   ExecStart=/usr/bin/cinder-api --config-file
>> > /usr/share/cinder/cinder-dist.conf \
>> > --config-file /etc/cinder/cinder.conf --logfile
>> /var/log/cinder/api.log
>> >
>> > On Ubuntu, the file /etc/init/cinder-api.conf is provided. It specfies :
>> >
>> >   exec start-stop-daemon --start --chuid cinder --exec
>> /usr/bin/cinder-api \
>> >  -- --config-file=/etc/cinder/cinder.conf
>> > --log-file=/var/log/cinder/cinder-api.log
>> >
>> > In my understanding, this means that when using packages none of log-dir
>> > and log-file will ever be taken in account.
>> >
>> > So the only use case moving those values to $::os_service_default might
>> > impact are for the people relying directly on the python package.
>> >
>> > This raises two questions I'd like to ask :
>> >
>> >   * Do lot of people use puppet-openstack modules relying on the python
>> > package directly ?
>> >   * Should we be opinionated here ? If user relies on the python
>> > packages, we can consider that an advanced use-case and expect the user
>> > to know exactly what she needs to configure. Plus we do not handle the
>> > use case where we want a file for cinder-volume.log and
>> cinder-backup.log.
>> >
>> > [1]
>> >
>> https://trello.com/c/XLJJJBF0/71-move-modules-to-the-os-service-default-pattern
>> >
>>
>> My opinion is that installing directly from python pip is not currently
>> officially supported in the modules and specifically trying to take that
>> use case into account when we do not support it either leaves us in a
>> place where we have to go full in on supporting them or put the modules
>> in a state that thoroughly frustrates and misleads users.
>>
>> If we were going to put priority on which packaging systems to support
>> next; I'd prefer docker over pip.
>>
>>
>> --
>> Cody
>>
>>
>> __
>> OpenStack Development Mailing 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Matt Riedemann]

On 11/12/2015 7:40 AM, Alan Pevec wrote:

This is a call to stable-maint teams for Nova, Keystone, Glance,
Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review
open stable/juno changes[2] and approve/abandon them as appropriate.


CCing CPLs listed in
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch

I got only ACK from Erno for Glance, anyone other project ready?



[2] 
https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z


AFAICT there are at least two blockers for 2014.2.4:
- horizon - django_openstack_auth issue Tony mentions in
https://review.openstack.org/172826
- nova - gate-grenade-dsvm-ironic-sideways failures e.g. in
https://review.openstack.org/227800


Cheers,
Alan

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



Nova is good to go.

--

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] [stable][all] Keeping Juno "alive" for longer.

[Jesse Pretorius]

On 9 November 2015 at 14:42, Sean Dague  wrote:

>
> So lets figure out where the snags are. I'm pretty uninterested in
> threads that just scream LTS without a list of upgrade bugs that have
> been filed to describe why rapid upgrade isn't the right long term
> solution.


I agree with this wholeheartedly. Simpler, more reliable and more online
upgrades are the targeted solution.

As adoption of OpenStack grows, distributors are going to have to play a
much larger role in driving their own end-user concerns by committing their
own resources to make those concerns become a reality.
__
OpenStack Development Mailing 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][upgrade] Grenade multinode partial upgrade

[Armando M.]

On 13 November 2015 at 11:46, Sean Dague  wrote:

> On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> > On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
> >> Ok, I top responded with the details of the job, honestly I think it's
> >> just a project-config change to get up and running, and then hacking at
> >> the bugs that fall out.
> >
> > Thanks - that was super helpful.
> >
> > I'm thinking of working on the following on Monday:
> >
> > 1) capture that somewhere in the upgrade docs we're putting together in
> neutron's devref
> >
> > 2) Adding the stanza to project-config to get grenade running for
> > Neutron
> >
> > 3) Take a look at the patches that Armando linked a couple emails back
> > in this thread.
>
> I don't think that any of the patches listed there are needed. This was
> part of the reason I -2ed that direction in the last cycle. It required
> a separate special code path for partial upgrade setup which was very
> synthetic (and honestly kind of confusing to debug).
>

I don't disagree. I didn't meant to imply 'resume the patches', I was only
providing the backdrop.


>
> The new approach means if you did upgrade for the all-in-one case, and
> you did multinode setup with worker processes on the subnode, you just
> make a config where you do them both at the same time, and you have
> partial upgrade.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [fuel] Using alternative OpenStack packages with Fuel

[Alex Schultz]

Hey folks,

Based on my previous email, I promised to send out a note this week
about this topic.  My original email also included testing out the
development version of the upstream puppet modules. I was able to get
an environment working with the master branches of the OpenStack
Puppet modules but ran into further issues.  To simplify the
discussions, I've decided to split the topics into using upstream
packages and using upstream modules.  Below is the preliminary results
for the upstream package topic.  I plan on publicly posting (somewhere
TBD) both sets of results as well as additional instructions. I look
forward to comments.

Using alternative OpenStack packages with Fuel
--

Fuel[0] is an open source deployment and management tool for
OpenStack.  Current versions of Fuel provide the ability to deploy and
configure OpenStack clouds utilizing Debian based packages on Ubuntu
based systems.  But if you wanted to use a different set of packages
for your cloud?  Well Fuel can be configured to deploy those packages
instead of the packages currently used.

The Plugin
--

Fuel provides a plugin framework than can be used to inject additional
steps in the deployment process.  In addition to deployment tasks,
plugins can be used to create additional roles that can be assigned to
nodes.  With this framework, we were able to create a proof of concept
plugin[1] that can be used to configure specific nodes to use the
Ubuntu Cloud Archive[2] packages as their preferred OpenStack package
repository.

The plugin creates a new role that can be applied to specific nodes to
indicate that the UCA packages should be used.  The plugin sets a
puppet fact called os_package_type[3] which is will be consumed by the
upstream OpenStack Puppet modules to indicate which packages to
install and configure.  The Debian based packages which are the
default for Fuel have some minor differences from the UCA packages.
Our plugin overrides the default os_package_type to specify that we
want to use 'ubuntu' packages.

In addition to specifying the os_package_type, the plugin also pins a
specific set of packages that must be used with Fuel. Currently, the
haproxy package that is used with Fuel differs from a version provided
by Ubuntu based systems. At time of writing, this package needs to be
used so the plugin ensures this package set gets installed.  The last
configuration this plugin performs is to setup the UCA package
repository on the host system and sets the priority of this repository
to be higher than the default repository so that the UCA packages are
installed.

The plugin creates a role[4] that must be assigned the system(s) that
the user would like to use the UCA package set with.  Since a role is
provided, this would allow the end user fine grained control over
which packages are used for the node.  With this flexibility, a user
could use Debian based packages for Controller nodes and UCA based
packages for Compute nodes or vice versa.

Fuel Flexibility


With this proof of concept, Fuel shows its potential as a deployment
and management system for OpenStack. With the plugin, we are also able
to add additional configurations around what version of the packages
we would like to use. We are able to specify the Kilo or Liberty
packages[5] (and future Mikita, etc).  Since Fuel is leveraging
upstream OpenStack Puppet manifests, it should be able to support two
different packages versions for a given version of Fuel.  With the
plugin for a given environment, we would be able to test a future
version of the packages with the same version of fuel-library.

In addition to providing Ubuntu package installation support, as we
work on additional RedHat family support we would able to provide a
similar mechanism for RDO packages or another distribution's packages.
Because of the options provided by a plugin, we could even support
CentOS packages for Controllers and RDO packages for Compute nodes.

Issues
--

In order to get the plugin and alternate package set, a few items
needed to be addressed in fuel-library. A patch[6] was created to
address these issues.

 * The Debian based packages assume that python-mysqldb should be used
for the mysql driver. As such, we add an additional parameter to our
database connection string called read_timeout for our HA
configuration. Unfortunately the Ubuntu based packages assume that
python-pymysql should be used for the mysql drive.  In order to allow
for the Ubuntu based packages, we prepared a patch to remove the
read_timeout from the mysql database connection strings used.
 * The Debian based packages provide a heat-docker package which
provides docker files for Heat. Since there appears to be no such
package with the Ubuntu package set, we only install it when the
Debian based packages are installed.
 * During testing we found due to Bug 1499620[7] that there is a
version of the Ubuntu based packages have an issues with 

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 05:15:18PM +1100, Tony Breeds wrote:
> Hello all,
> 
> I'll start by acknowledging that this is a big and complex issue and I
> do not claim to be across all the view points, nor do I claim to be
> particularly persuasive ;P
> 
> Having stated that, I'd like to seek constructive feedback on the idea of
> keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.

For the record this thread, conversations I've had in private and the fact
noone else has stepped up .

Juno is no more long live Kilo!

Tony.


pgpYcub1aMMVn.pgp
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] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Martin André]

+1!

On Sat, Nov 14, 2015 at 4:32 AM, Harm Weites  wrote:

> +1 :)
>
> Jeff Peeler schreef op 2015-11-13 19:51:
>
>> On 12/11/15 08:41, Steven Dake (stdake) wrote:
>>>
>>> Hey folks,
>>>
>>> Its been awhile since we have had a core reviewer nomination, but I
>>> really feel like Michal has the right stuff. If you look at the 30 day
>>> stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in
>>> a 30 day period. He is beating 2/3rds of our core reviewer team on all
>>> stats. I think his reviews, while could use a little more depth, are
>>> solid and well considered. That said he participates on the mailing
>>> list more then others and has been very active in IRC. He has come up
>>> to speed on the code base in quick order and I expect if he keeps pace,
>>> the top reviewers in Kolla will be challenged to maintain their spots :)
>>> Consider this proposal as a +1 vote from me.
>>>
>>> As a reminder, our core review process requires 3 core reviewer +1
>>> votes, with no core reviewer –1 (veto) votes within a 1 week period. If
>>> your on the fence, best to abstain :) I'll close voting November 20th,
>>> or sooner if there I a veto vote or a unanimous vote.
>>>
>>> Regards
>>> -steve
>>>
>>> http://stackalytics.com/report/contribution/kolla-group/30
>>>
>>
>> +1!
>>
>>___
>> OpenStack Development Mailing 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] Regarding OVN project and integration with SFC

[Cathy Zhang]

Hi Russell,

Has the OVN code been released in Liberty? If not when is it planned for 
release?
Will it replace existing OVS Driver and OVS Agent or it will provide an 
alternative path of
programming the OVS? It is on the networking-sfc project roadmap to support OVN 
integration with SFC.
We would like to work with you on adding an OVN driver and Agent to integrate 
with the networking-sfc API.
How would you like to proceed with this integration work?

Thanks,
Cathy
__
OpenStack Development Mailing 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] [horizon][keystone]

[Lin Hua Cheng]

David,

FYI, I've submitted a patch to enable registering Identity Providers in
horizon:

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

The next logical step for this is to look at the IdP mapping.

I can follow-up on the work by Anton to add that support for horizon.

Can you send me the code and documents you may have related to this?

Thanks,
Lin



On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick 
wrote:

>
>
> On 07/10/2015 18:29, Adam Young wrote:
> > On 10/07/2015 11:51 AM, Adam Young wrote:
> >> Send me what you have, and I will post it as a Work in progress review
> >> against Horizon.  That way at least it will be available for others to
> >> look at and potentially adopt.
> >
> > Review has been posted here
> > https://review.openstack.org/232114
> >
>
> thanks Adam
>
> >
> > I made a best guess as far as where it it should be placed in the source
> > tree.  I have not tested the code.
> >
> > David and I have both signed the CLA. I am fairly certon Anton did not.
> > It would be easiest for OpenStack to accept this code if he did, as
> > there would be no question about copyright or licensing.
>
> Legally speaking it is not necessary, since any code produced by
> students as part of their degree course does not belong to them.
> However, it would be courteous of us to ask him, so I have done this.
>
> >
> > David also provided me with a PDF version of Anton's dissertation. I do
> > not know what the status of that document, but it would be a great
> > resource to anyone that wants to take this code and get it integrated
> > into Horizon.
>
> This can be made publicly available after the exam board next month.
> Until then I will give out personal copies for private study.
>
> regards
>
> David
>
> >
> > This does not look like a radical stretch.  It would be a decent
> > opportunity for anyone looking to get involved with OpenStack to step
> > into something immediately.
> >
> >
> >
> >
> >>
> >>
> >>
> >> On 10/07/2015 11:37 AM, David Chadwick wrote:
> >>> Hi Douglas
> >>>
> >>> we are happy for you (or someone else) to submit the code in 3 names:
> >>> theirs, mine and Anton's. Then this third person can do all the work
> >>> necessary to get it approved. In this way it is legitimate, since the
> >>> third person will have contributed to the overall effort.
> >>>
> >>> I dont have any spare time yet for another month or so. After that I
> >>> could submit it, but having never done it before for Horizon, there
> will
> >>> be a big learning curve. And I might not have time to learn it
> >>>
> >>> regards
> >>>
> >>> David
> >>>
> >>> On 07/10/2015 16:05, Douglas Fish wrote:
>  Hi David,
>    This sounds like a great set of code, I'm sure we are going to
>  realize
>  we want it sooner or later! Unfortunately I can't consume code in this
>  way (I can't propose code written by somebody else) and I can't spend
>  significant time on it right now.
>    Would you or Anton be willing to propose whatever code and
>  documentation
>  you have to Horizon? It doesn't have to be complete; it doesn't need
> to
>  have grammar cleaned up or anything like that. You could mark it as a
>  "Work in progress", and make it clear in the commit message that you
>  aren't planning further work on this, so the patch is available for
>  adoption. That way somebody else may be able to pick this up and
>  work on
>  it in the future, but Anton could get credit for the work he has done.
> 
>  Doug Fish
> 
>   - Original message -
>   From: David Chadwick 
>   To: OpenStack Development Mailing List
>   
>   Cc:
>   Subject: [openstack-dev] [horizon][keystone]
>   Date: Tue, Oct 6, 2015 2:13 PM
> Dear All
> 
>   One of my students, Anton Brida, has developed an Attribute
>  Mapping GUI
>   for Horizon as part of his MSc project. Attribute mappings are an
>   essential, though complex, part of federated Keystone.
>  Currently they
>   can only be created as JSON objects in the config file. The
>  Horizon code
>   allows them to be dynamically created via an easy to use GUI.
> 
>   Since Anton has now left the university for full time
>  employment, he is
>   not able to go through the process of submitting his code to
>  the next
>   release of Horizon. His design however was submitted to
>  InVision and
>   commented on by various people at the time of the development.
> 
>   I am now looking for someone who would like to take a copy of
>  this code
>   and go through the process of submitting this to the next
>  release of
>   Horizon. I have a copy of Anton's MSc dissertation as well which
>   explains the work that he has done.
> 
> 

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Henry Fourie]

Ihar,
   See inline.
- Louis

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, November 12, 2015 1:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

Henry Fourie  wrote:

> Ihar,
>Networking-sfc installs flows on br-int and br-tun for steering 
> traffic to the SFC port-pairs. On each bridge additional tables are 
> used for an egress forwarding pipeline (from the service VM port) and 
> an ingress pipeline (to the service VM port). Rpc operations between 
> the OVS driver and agents is used to initiate the flow installation.
>
> We'd like to work with you on defining the L2 extensions.

Hi Henry,

thanks for taking time to specify your needs. Could you please update the 
etherpad [1] with these details?

LF> Will do.

Speaking of new ovs tables you need, how do you reference to them?
LF> br-int has one new table SF_SELECTOR in the ingress pipeline that is used 
steer traffic to the correct service VM
by matching on the NSP (Network Service Path) of the MPLS (NSH) header.
br-tun has two new tables in the egress pipeline: GRP_SELECTOR used to select a 
Group Table by matching on the NSP of the MPLS (NSH) header
and a set of Group Tables to perform load distribution for a port-pair group.
  
 Is there any ordering guarantees for flows you will need to set that should be 
provided in scope of that public API of the agent?
LF> No.

 I wonder whether just pushing flows into the existing tables at random points 
in time can be unstable and break the usual flow assumed by the main agent loop.
LF> No not expect any issues.

Am I making sense?

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion

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 Development Mailing 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] Linux kernel IPv4 configuration during the neutron installation

[Akihiro Motoki]

Could you share the exact place of the installation guide?
I would like to check it.

Are you talking about the network node?

I think these settings are required when you configure a network node
without network namespace.

If we use network namespace in a network node, I don't think we need
these settings in a host of a network node.
ip_forward=1 is set automatically in a router network namespace.

I checked my Juno production environment  with network namespace, I
see the following in a host level.
It uses Ubuntu 14.04.

$ cat /proc/sys/net/ipv4/ip_forward
0
$ cat /proc/sys/net/ipv4/conf/all/rp_filter
1
$ cat /proc/sys/net/ipv4/conf/default/rp_filter
1

Akihiro

2015-11-13 18:51 GMT+09:00 JinXing F :
> Yes,I don't understand why Neutron needs enable ip_forward and disable RPF.
> And I also don't understand where the neutron need this config during the
> instance connect to the extrernal network.
>
> I read the neutron code, found when the L3 agent creating, it needs the
> ip_forward config,but i'm not find the RPF config in the neutron code.
>
> Thank you very much!
>
>
> 2015-11-11 18:25 GMT+08:00 JinXing F :
>>
>> Hi, guys:
>>
>> during the neutron installation guide, I found that we need to config
>> the linux kernel as bellow:
>>
>> net.ipv4.ip_forward=1
>>
>> net.ipv4.conf.all.rp_filter=0
>>
>> net.ipv4.conf.default.rp_filter=0
>>
>>
>> the first one is the ip address translation between LAN and WLAN, the
>> second and third command is used for "Reverse Path Filtering".
>>
>> I cann't understand the purpose of the config in the neutron.
>>
>> 1. If the instance in compute node connect with exteral network,what's the
>> function of the three config?
>>
>> 2. The instance connect with each others, what's the function of the three
>> config?
>>
>>
>> I am very confused about this config.Please explain the answer to me.
>>
>> 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] Linux kernel IPv4 configuration during the neutron installation

[JinXing F]

This installation guide is:
http://docs.openstack.org/juno/install-guide/install/yum/content/neutron-network-node.html#treeDiv

In Centos 7,controle node and network node in one machine.my output is:
[root@controller-59 ~]# cat /proc/sys/net/ipv4/ip_forward
1
[root@controller-59 ~]# cat /proc/sys/net/ipv4/conf/all/rp_filter
0
[root@controller-59 ~]# cat /proc/sys/net/ipv4/conf/default/rp_filter
0


2015-11-13 18:01 GMT+08:00 Akihiro Motoki :

> Could you share the exact place of the installation guide?
> I would like to check it.
>
> Are you talking about the network node?
>
> I think these settings are required when you configure a network node
> without network namespace.
>
> If we use network namespace in a network node, I don't think we need
> these settings in a host of a network node.
> ip_forward=1 is set automatically in a router network namespace.
>
> I checked my Juno production environment  with network namespace, I
> see the following in a host level.
> It uses Ubuntu 14.04.
>
> $ cat /proc/sys/net/ipv4/ip_forward
> 0
> $ cat /proc/sys/net/ipv4/conf/all/rp_filter
> 1
> $ cat /proc/sys/net/ipv4/conf/default/rp_filter
> 1
>
> Akihiro
>
> 2015-11-13 18:51 GMT+09:00 JinXing F :
> > Yes,I don't understand why Neutron needs enable ip_forward and disable
> RPF.
> > And I also don't understand where the neutron need this config during the
> > instance connect to the extrernal network.
> >
> > I read the neutron code, found when the L3 agent creating, it needs the
> > ip_forward config,but i'm not find the RPF config in the neutron code.
> >
> > Thank you very much!
> >
> >
> > 2015-11-11 18:25 GMT+08:00 JinXing F :
> >>
> >> Hi, guys:
> >>
> >> during the neutron installation guide, I found that we need to
> config
> >> the linux kernel as bellow:
> >>
> >> net.ipv4.ip_forward=1
> >>
> >> net.ipv4.conf.all.rp_filter=0
> >>
> >> net.ipv4.conf.default.rp_filter=0
> >>
> >>
> >> the first one is the ip address translation between LAN and WLAN, the
> >> second and third command is used for "Reverse Path Filtering".
> >>
> >> I cann't understand the purpose of the config in the neutron.
> >>
> >> 1. If the instance in compute node connect with exteral network,what's
> the
> >> function of the three config?
> >>
> >> 2. The instance connect with each others, what's the function of the
> three
> >> config?
> >>
> >>
> >> I am very confused about this config.Please explain the answer to me.
> >>
> >> 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] [HA] weekly High Availability meetings on IRC start next Monday

[Sergii Golovatiuk]

Hi,

United Kingdom/London has UTC+1 in summer. Thus I use Ghana/Accra which is
pure UTC all year.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Fri, Nov 13, 2015 at 1:23 AM, Adam Spiers  wrote:

> Sergii Golovatiuk  wrote:
> > > > [2] declares meetings at 9am UTC which might be tough for US based
> > > folks. I
> > > > might be wrong here as I don't know the location of HA experts.
> > > >
> > > >  [2] http://eavesdrop.openstack.org/#High_Availability_Meeting
> > >
> > > Yes, I was aware of this :-/  The problem is that the agenda for the
> > > first meeting will focus on hypervisor HA, and the interested parties
> > > who met in Tokyo are all based in either Europe or Asia (Japan and
> > > Australia).  It's hard but possible to find a time which accommodates
> > > two continents, but almost impossible to find a time which
> > > accommodates three :-/
> > >
> > >
> > I ran into issues setting event in UTC. Use Ghana/Accra in google
> calendar
> > as it doesn't have UTC time zone
>
> Speaking on behalf of my home town, United Kingdom/London would also
> work ;-)
>
> But even easier, just add this URL to your Google Calendar:
>
>   http://eavesdrop.openstack.org/calendars/high-availability-meeting.ics
>
> or if you want to really spam your calendar, you can add all OpenStack
> meetings in one go :-)
>
>   http://eavesdrop.openstack.org/irc-meetings.ical
>
> __
> OpenStack Development Mailing 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] [puppet] about $::os_service_default

[Yanis Guenane]

On 11/03/2015 02:57 PM, Emilien Macchi wrote:
> I'm seeing a lot of patches using the new $::os_service_default.
>
> Please stop trying to using it at this time. The feature is not stable
> yet and we're testing it only for puppet-cinder module.
> I've heard Yanis found something that is not backward compatible with
> logging, but he's away this week so I suggest we wait next week.
>
> In the meantime, please do not use $::os_service_default outside
> puppet-cinder.
>
> Thanks a lot,
After a deeper investigation, the issue with logging[1] is only true if
a user is using the puppet-openstack to only configure the component and
not relying on it to install the RDO/UCA packages.

On RDO, the file /usr/lib/systemd/system/openstack-cinder-api.service is
provided. It specifies :

  ExecStart=/usr/bin/cinder-api --config-file
/usr/share/cinder/cinder-dist.conf \
--config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log

On Ubuntu, the file /etc/init/cinder-api.conf is provided. It specfies :

  exec start-stop-daemon --start --chuid cinder --exec /usr/bin/cinder-api \
 -- --config-file=/etc/cinder/cinder.conf
--log-file=/var/log/cinder/cinder-api.log

In my understanding, this means that when using packages none of log-dir
and log-file will ever be taken in account.

So the only use case moving those values to $::os_service_default might
impact are for the people relying directly on the python package.

This raises two questions I'd like to ask :

  * Do lot of people use puppet-openstack modules relying on the python
package directly ?
  * Should we be opinionated here ? If user relies on the python
packages, we can consider that an advanced use-case and expect the user
to know exactly what she needs to configure. Plus we do not handle the
use case where we want a file for cinder-volume.log and cinder-backup.log.

[1]
https://trello.com/c/XLJJJBF0/71-move-modules-to-the-os-service-default-pattern

--
Yanis Guenane

__
OpenStack Development Mailing 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

> Speaking of your "hacky" patch: yes and no. It makes the gate passing,
> it doesn't change the code itself. For most people, this will work fine.
>
> The right way to do it, would be to create a juno branch for doa and
> cap requirements there.
>
> How to do this? Is there a procedure to request a branch?

Let's not go there, I've approved "hacky" one.

Cheers,
Alan

__
OpenStack Development Mailing 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][upgrade] Grenade multinode partial upgrade

[Sean Dague]

On 11/13/2015 04:08 AM, Ihar Hrachyshka wrote:
> Armando M.  wrote:
> 
>>
>>
>> On 12 November 2015 at 20:24, Sean M. Collins  wrote:
>> On Thu, Nov 12, 2015 at 05:55:51PM EST, Ihar Hrachyshka wrote:
>> > I also believe that the first step to get the job set is making
>> neutron own
>> > its grenade future, by migrating to grenade plugin maintained in
>> neutron
>> > tree.
>>
>> I'd like to see what Sean Dague thinks of this - my worry is that if we
>> start pulling things into Neutron we lose valuable insight from people
>> who know a lot about Grenade.
>>
>> Not to mention, Sean and I have had conversations about trying to get
>> Neutron as the default for DevStack - we can't just take our ball and go
>> in our own corner.
>>
>> Agreed. (I feel like) we had a good discussion at the summit about
>> this: we clearly have key pieces that are and will stay within the
>> realm of both devstack and grenade.
> 
> Agreed that it’s worth clarifying with grenade folks what should be
> included in grenade plugin, and what belongs to core grenade; and where
> multinode ‘partial’ job stands in this regard.

Ok, I top responded with the details of the job, honestly I think it's
just a project-config change to get up and running, and then hacking at
the bugs that fall out.

Much like with devstack, I think that neutron core service configuration
/ upgrade should stay in the tree. We want more people familiar with it,
and I really do want to get us over to Neutron by default some day
(hopefully not too far off). I'm quite hopefully of the work Sean
Collins is doing there.

The advanced services should all be in plugins. I think we fully removed
them from base grenade testing last cycle.

There are lots of coupling in the set of projects that need to cooperate
to get computes on the network, so debugging and fixing those issues
often depends on understanding the whole collection. Having the code
that does that and the ability to bugfix in one place means we can turn
around breaks faster. It also means that everyone in the ecosystem
becomes familiar with all of that by default.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][upgrade] Grenade multinode partial upgrade

[Ihar Hrachyshka]

Sean Dague  wrote:


On 11/13/2015 04:08 AM, Ihar Hrachyshka wrote:

Armando M.  wrote:


On 12 November 2015 at 20:24, Sean M. Collins  wrote:
On Thu, Nov 12, 2015 at 05:55:51PM EST, Ihar Hrachyshka wrote:

I also believe that the first step to get the job set is making

neutron own

its grenade future, by migrating to grenade plugin maintained in

neutron

tree.


I'd like to see what Sean Dague thinks of this - my worry is that if we
start pulling things into Neutron we lose valuable insight from people
who know a lot about Grenade.

Not to mention, Sean and I have had conversations about trying to get
Neutron as the default for DevStack - we can't just take our ball and go
in our own corner.

Agreed. (I feel like) we had a good discussion at the summit about
this: we clearly have key pieces that are and will stay within the
realm of both devstack and grenade.


Agreed that it’s worth clarifying with grenade folks what should be
included in grenade plugin, and what belongs to core grenade; and where
multinode ‘partial’ job stands in this regard.


Ok, I top responded with the details of the job, honestly I think it's
just a project-config change to get up and running, and then hacking at
the bugs that fall out.

Much like with devstack, I think that neutron core service configuration
/ upgrade should stay in the tree. We want more people familiar with it,
and I really do want to get us over to Neutron by default some day
(hopefully not too far off). I'm quite hopefully of the work Sean
Collins is doing there.

The advanced services should all be in plugins. I think we fully removed
them from base grenade testing last cycle.

There are lots of coupling in the set of projects that need to cooperate
to get computes on the network, so debugging and fixing those issues
often depends on understanding the whole collection. Having the code
that does that and the ability to bugfix in one place means we can turn
around breaks faster. It also means that everyone in the ecosystem
becomes familiar with all of that by default.


Cool, thanks for clarification. I was under impression that all projects  
should adopt plugins, not just those considered not part of core. Also glad  
to hear it’s a matter of infra patch for a new job. I think we’ll roll it  
from here.


Thanks
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] [api] consolidate IRC change with #openstack-sdk?

[Sean Dague]

The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Flavio Percoco]

On 10/11/15 16:11 +0100, Alan Pevec wrote:

Hi,

while we continue discussion about the future of stable branches in
general and stable/juno in particular, I'd like to execute the current
plan which was[1]

2014.2.4 (eol) early November, 2015. release manager: apevec

Iff there's enough folks interested (I'm not) in keep Juno alive
longer, they could resurrect it but until concrete plan is done let's
be honest and stick to the agreed plan.

This is a call to stable-maint teams for Nova, Keystone, Glance,
Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review
open stable/juno changes[2] and approve/abandon them as appropriate.
Proposed timeline is:
* Thursday Nov 12 stable/juno freeze[3]
* Thursday Nov 19 release 2014.2.1



General ack from a stable-maint point of view! +1 on the above

Flavio


Cheers,
Alan

[1] 
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fjuno_releases_.2812_months.29

[2] 
https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z

[3] documented  in
https://wiki.openstack.org/wiki/StableBranch#Stable_release_managers
TODO add in new location
http://docs.openstack.org/project-team-guide/stable-branches.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


--
@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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Gary Kotton]

On 11/13/15, 3:23 PM, "Flavio Percoco"  wrote:

>On 10/11/15 16:11 +0100, Alan Pevec wrote:
>>Hi,
>>
>>while we continue discussion about the future of stable branches in
>>general and stable/juno in particular, I'd like to execute the current
>>plan which was[1]
>>
>>2014.2.4 (eol) early November, 2015. release manager: apevec
>>
>>Iff there's enough folks interested (I'm not) in keep Juno alive

+1 I do not see any reason why we should still invest time and effort
here. Lets focus on stable/kilo

>>longer, they could resurrect it but until concrete plan is done let's
>>be honest and stick to the agreed plan.
>>
>>This is a call to stable-maint teams for Nova, Keystone, Glance,
>>Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review
>>open stable/juno changes[2] and approve/abandon them as appropriate.
>>Proposed timeline is:
>>* Thursday Nov 12 stable/juno freeze[3]
>>* Thursday Nov 19 release 2014.2.1
>>
>
>General ack from a stable-maint point of view! +1 on the above
>
>Flavio
>
>>Cheers,
>>Alan
>>
>>[1] 
>>https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fjuno
>>_releases_.2812_months.29
>>
>>[2] 
>>https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%
>>28project:openstack/nova+OR+project:openstack/keystone+OR+project:opensta
>>ck/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+pro
>>ject:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/cei
>>lometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z
>>
>>[3] documented  in
>>https://wiki.openstack.org/wiki/StableBranch#Stable_release_managers
>>TODO add in new location
>>http://docs.openstack.org/project-team-guide/stable-branches.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
>
>-- 
>@flaper87
>Flavio Percoco


__
OpenStack Development Mailing 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] [stable] Making stable maintenance its own OpenStack project team

[Thierry Carrez]

So.. quick summary of this thread so far.

(-)
* Not enough work to warrant a designated "team", now that the work is
decentralized and the cats are mostly herding themselves
* The change is unlikely to bring a meaningful improvement to the
situation, or sudden new resources

(+)
* An empowered team could tackle new coordination tasks, like engaging
more directly in converging stable branch rules across teams, or
producing tools
* Release management doesn't overlap anymore with stable branch, so
having them under that PTL is limiting and inefficient
* Reinforcing the branding (by giving it its own team) may encourage
more organizations to affect new resources to it

In summary, I think this is worth a try. If the team fails, at least it
will be on its own rather than as the 5th squeaky wheel of release
management (where lack of leadership and focus could be rightly blamed
for failure).

For this to succeed, we need someone to own the effort and push it
forward, and a number of people caring enough about it to attend regular
meetings about it and to lurk on #openstack-stable. I'm fine helping the
team in the spin-off effort but I don't want to lead it (I proved I was
unable to make it my top priority in the past, so I think the team
deserves a more focused lead).

Erno has volunteered to lead. Ihar, Alan (Pevec) and myself don't have
enough time to lead but are happy to help. Anyone else interested to
join that initial group ? Flavio ? Matt ?

Once we have a list of key members we should set up a meeting to discuss
the details.

-- 
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] [Fuel] API services available on public VIP

[Vladimir Kuklin]

Adam

I think, the answer is realtively simple - if user does not want to expose
those APIs, he can easily configure his infra to filter this traffic. We
just need to mention this in Ops Guide.

On Fri, Nov 13, 2015 at 4:02 PM, Adam Heczko  wrote:

> Hello fuelers,
>
> today I'd like to raise a questions about Fuel deployment practice related
> to Public (external) network.
> Current approach is to expose by default over public IP openstack API
> endpoints like nova, cinder, glance, neutron etc. These API services are
> exposed through HAProxy with TLS support, so this approach seems to be
> relatively secure.
> OTOH industry practice is to don't expose over public IPs too much and
> rather rely on user action / decision to expose API access to the public.
> I'd like to ask for your opinions regarding this topic and approach taken
> by Fuel.
>
> Thank you,
>
> --
> Adam Heczko
> Security 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Advanced PXE provisioning notes

[Vladimir Eremin]

Hi folks,

As you know, to speed up provisioning stage we could use HTTP for downloading 
kernel and initramfs. There are 3 options to do this: lpxelinux, iPXE (which is 
successor/fork of gPXE) and GRUB 2, which we were assessed during my work in 
Yandex and I’d like to share some experience.

In this note I leave UEFI/iPXE embedding for IPv6 out of scope. Yandex has 
chosen with iPXE embedding mostly because it’s well-known already and there was 
less problem to embed iPXE to custom-build hardware than mess with UEFI.

lpxelinux is a HTTP/FTP enabled variant of usual pxelinux (since syslinux 
5.10), so it’s required no chainloading (so no mess with DHCP-server) and no 
boot config re-design. To provide HTTP URI instead of TFTP, two variants may be 
used:

* replace entries in boot config like LINUX from relative path like 
boot/mykernel to absolute URL like http://boot-server/boot/mykernel
* provide pxelinux.pathprefix DHCP option [1] contains URL prefix like 
http://boot-server/

This is most convenient variant to speed up pxelinux setup. Unfortunately, 
lpxelinux hasn't built for Ubuntu Trusty, so it should be rebuilt from Debian 
Sid.


iPXE is advanced boot loader with many features like IPv6, HTTP and scripting 
language. Actually, it allows to pass hardware-related information to 
provisioning server.

Boot script should be compiled into iPXE, or you will need to set up your 
DHCP-server [2] to serve different options for different loaders. This option 
will require to re-write provisioning logic.
It also support UEFI, so it could be used for IPv6 provisioning.

I recommend this variant for advanced IPv6 + HTTP provisioning.


GRUB2 is most advanced option. Unfortunately, it’s still has a bug with IPv6 
[3], so there is no point to overcomplicate the setup.


Note that UNDI API is provided correctly by most of modern NIC’s. However, some 
cards like Mellanox ConnectX and weird Intels is not working correctly. To fix 
it, iPXE could be built with vendor-specific driver [4]. There is no workaround 
for lpxelinux.

[1] http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options
[2] http://ipxe.org/howto/chainloading
[3] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458
[4] http://ipxe.org/appnote/hardware_drivers

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment 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] [api] consolidate IRC change with #openstack-sdk?

[Everett Toews]

Please note that should be #openstack-sdks (plural) !

> On Nov 13, 2015, at 6:58 AM, Sean Dague  wrote:
> 
> The #openstack-api IRC channel is quite quiet most days. As such it's
> not something that people are regularly checking in on, or often forget
> about (I know I've been guilty of that). Plus we don't always have the
> right people in a conversation to make a decision.
> 
> I'd like to propose we drop the channel entirely and make #openstack-sdk
> the home of API working group conversations. That's where all the
> openstackclient, openstackclientconfig, and sdk conversations are
> happening. It's where the end consumers of any API WG effort are, so are
> incredibly good sounding boards for things we are doing. There is
> already a large overlap between the two channels, so just pushing
> forward on that means more critical mass for conversations around the
> whole space of a more usable API for users.
> 
> This came up at the last API WG meeting, but those are pretty low quorum
> events, so this is a thing we should definitely decide over ML instead.
> 
> Please express your feelings here and lets make it happen. :)

A little bit of data to inform the decision. I threw together a quick n' dirty 
spreadsheet [1] to see what the user overlap is like.

16 of the 39 in #openstack-api are already in #openstack-sdks.

I'm actually not super opinionated on it. But I suppose I'd lean towards 
folding it in.

Would like to hear what others in the API WG think.

Everett

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

Re: [openstack-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply?

[Ihar Hrachyshka]

Thierry Carrez  wrote:


Carl Baldwin wrote:

- StableBranch page though requires that we don’t merge non-critical bug
fixes there: "Only critical bugfixes and security patches are acceptable”


Seems a little premature for Kilo.  It is little more than 6 months old.


Some projects may want to continue backporting reasonable (even though
non-critical) fixes to older stable branches. F.e. in neutron, I think  
there

is will to continue providing backports for the branch.


+1  I'd like to reiterate my support for backporting appropriate and
sensible bug fixes to Kilo.


"Stable" always had two conflicting facets: it means working well, and
it means changing less. In the first stage of stable maintenance the
focus is on "working well", with lots of backports for issues discovered
in the initial release. But after some time you caught all of the major
issues and the focus shifts to "changing less". This is what the support
phases are about, gradually shifting from one facet to another.


OK, I guess we are currently bound by stable policy [1], and without  
changing the document, we cannot proceed with non-critical backports. At  
this point I am not clear how huge interest from distributions to maintain  
the older (N-2) branches will be.


[1]:  
http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases




That said, that can certainly be revisited. I suppose as long as extra
care is taken in selecting appropriate fixes for older branches, we can
get the best of both worlds.



I will talk to team members whether they feel strongly about it, and if so,  
I’ll propose some policy change that would allow projects to extend the  
scope of backports for older stable branches.



Note that we'll likely spin out the stable branch maintenance team into
its own project team (outside of the release management team), now that
its focus is purely on defining a common stable branch policy and making
sure it's respected across a wide range of project-specific maintenance
teams. So that new team could definitely change the common rules there
:) More on that soon.

Cheers,

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

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

[Steve Martinelli]

As a -sdks regular, I wouldn't mind some of the API folks crashing the
channel :)

If it makes sense, then why not. There are already some folks that are
involved in both efforts (Everett).

Steve



From:   Sean Dague 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2015/11/13 07:59 AM
Subject:[openstack-dev] [api] consolidate IRC change with
#openstack-sdk?



The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)

 -Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][neutron][upgrade] Grenade multinode partial upgrade

[Sean Dague]

On 11/12/2015 02:41 PM, Korzeniewski, Artur wrote:
> Hi Sean,
> 
> I’m interested in introducing to Neutron the multinode partial upgrade
> job in Grenade.
> 
>  
> 
> Can you explain how multinode is currently working in Grenade and how
> Nova is doing the partial upgrade?

We're hopefully a couple of days out from making this voting. Here is
how it works conceptually:

Grenade itself knows how to upgrade 1 node. For simplicity sake we've
left it that way. Putting a real orchestration layer into Grenade would
be... potentially challenging. However Grenade implicitly runs stack.sh
today to make developer's life easier.

Devstack-gate knows how to setup a 2 nodes, and has the rest of the
multinode logic. Under a grenade multinode environment we:

* Allocate 2 nodes

* Setup all the source trees and configs correctly on all the nodes
(which includes less services on the workers) -
https://github.com/openstack-infra/devstack-gate/blob/92d130938406e4b42cdb1fe3e6fa62f3a2466024/devstack-vm-gate.sh#L206-L222

* Then we give Grenade a post-stack.sh script which includes the logic
to run stack.sh on all the subnodes at the right time -
https://github.com/openstack-infra/devstack-gate/blob/92d130938406e4b42cdb1fe3e6fa62f3a2466024/devstack-vm-gate.sh#L587-L597

* We run grenade

* It runs stack.sh on the main node, runs stack.sh on the subnode
because of post-stack.sh, then proceeds to run:

   - tempest smoke
   - creating of long running resources
   - shutsdown the controller / upgrades / restarts
   - verifies the long running resources are still there
   - runs tempest smoke
   - success

It completely ignores the subnode after post-stack.sh, which means that
will continue soldiering on as the stable version.

That means support for a new partial upgrade scenario is really only 2
things:

1. generic multinode support for the collection of services you want
(i.e. a definition of what's in the subnode).
2. support in grenade (or via a plugin) for upgrading the entire
controller node.

Fortunately, I believe Neutron already has #1 and #2 because of existing
jobs, so getting a multinode grenade job should just be a matter of a
project-config stanza. No additional code needs to be written. I'm sure
there might be some bugs (there always are), but getting rolling
shouldn't be too bad.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] Last sync from oslo-incubator

[Davanum Srinivas]

Hear Hear! Thierry. Many many thanks to everyone who made this possible.

-- Dims

On Fri, Nov 13, 2015 at 4:44 AM, Thierry Carrez  wrote:
> Davanum Srinivas wrote:
>> A long time ago, oslo-incubator had a lot of code, we have made most
>> of the code to oslo.* libraries. There's very little code left and
>> we'd like to stop hosting common code in oslo-incubator repository. We
>> encourage everyone to adopt the code they have in their repos under
>> openstack/common into their own namespace/packaging as we will be
>> getting rid of any remaining python modules in oslo-incubator.
>> [...]
>
> So this is pretty funny, since oslo-incubator was actually created
> exactly 3 years ago today. Three years ago we clearly stated that common
> code between OpenStack projects should ultimately become libraries and
> no longer be copy-pasted. It took us 3 years to get to the point where
> almost all the code has been graduated.
>
> Some would say it's a long time, but considering this is a
> cross-project, technical-debt-reduction effort that typically falls
> short of resources in a tragedy of the commons, I prefer to see it as a
> great achievement for us as a community.
>
> Thanks to all the people that drove Oslo from where it was to where it
> is today, including (but not limited to) Mark McLoughlin, Doug Hellmann
> and Davanum Srinivas.
>
> --
> 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



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

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

[openstack-dev] [Fuel] API services available on public VIP

[Adam Heczko]

Hello fuelers,

today I'd like to raise a questions about Fuel deployment practice related
to Public (external) network.
Current approach is to expose by default over public IP openstack API
endpoints like nova, cinder, glance, neutron etc. These API services are
exposed through HAProxy with TLS support, so this approach seems to be
relatively secure.
OTOH industry practice is to don't expose over public IPs too much and
rather rely on user action / decision to expose API access to the public.
I'd like to ask for your opinions regarding this topic and approach taken
by Fuel.

Thank you,

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

[openstack-dev] [stable][neutron] upper constraints for stable/liberty

[Ihar Hrachyshka]

Hi Sachi and all,

I was recently looking into how stable/liberty branches are set for neutron  
in terms of requirements caps, and I realized that we don’t have neither  
version caps nor upper constraints applied to unit test jobs in  
stable/liberty gate. We have -constraints targets defined in tox.ini, but  
they are not running in gate.


I believe this situation leaves us open to breakages by any random library  
releases out there. Am I right? If so, I would like to close the breakage  
vector for projects I care (all neutron stadium).


I suggest we do the following:

- unless there is some specific reason for that, stop running unconstrained  
jobs in neutron/master;
- enable voting for constraints jobs in neutron/liberty; once proved to  
work fine, stop running unconstrained jobs in neutron/liberty;
- for neutron-*aas, introduce constraints targets in tox.ini, enable jobs  
in gate; make them vote there/remove old jobs;
- after that, backport constraints targets to stable/liberty; make them  
vote there/remove old jobs.


Does the plan make sense?

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