Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

[Tripp, Travis S]

+1

From: Timur Sufiev 
Reply-To: OpenStack List 
Date: Friday, November 18, 2016 at 1:34 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

+1

On Fri, Nov 18, 2016 at 12:35 AM Thai Q Tran 
> wrote:
+1 from me. Kenji is also very active in the plugin space.

- Original message -
From: David Lyle >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Cc:
Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core
Date: Thu, Nov 17, 2016 11:51 AM

+1

On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama
> wrote:
> +1
>
> 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) 
> >:
>>
>> Big +1 from me
>>
>> > On 14 Nov 2016, at 00:24, Richard Jones 
>> > > wrote:
>> >
>> > Hi Horizon core team,
>> >
>> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
>> > solid Horizon contributor for some time, with thoughtful and helpful
>> > reviews showing good judgment and good knowledge of Horizion and
>> > related systems. Please respond with your votes by Friday.
>> >
>> >
>> > Thanks,
>> >
>> >Richard
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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


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

Re: [openstack-dev] [Zun] Zun PTL election

[Hongbin Lu]

Hi all,

I nominated myself to be the Zun PTL. As the founder of this project, it is my 
honor to work with all of you to build an innovative container service for 
OpenStack. Zun is a new project but already attracted a diverse set of 
contributors. I want to take this chance to thank our talent contributors for 
the great work. I also want to thank the general OpenStack community, in 
particular, a few TC members who helped us to found the project, provided 
suggestions to name the project, allocated resources for us in the Barcelona 
design summit, etc.. I believe we are heading to the right direction and our 
hard work will make OpenStack better in the future.

Best regards,
Hongbin

From: Hongbin Lu
Sent: November-08-16 7:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: 't...@bakeyournoodle.com'
Subject: [Zun] Zun PTL election

Hi all,

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

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

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

Re: [openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[John Dickinson]

On 18 Nov 2016, at 8:14, Dean Troyer wrote:

>> -Original Message-
>> From: Luke Hinds 
> [...]
>>> for non security related functions, but when it comes to government
>>> compliance and running OpenStack on public clouds (and even private for the
>>> Telcos / NFV), not meeting FIPS will in some cases block production getting
>>> a green light, or at least make it a big challenge to push through.
>
> Are there any know cases of this happening?  If so, can those be
> publicly documented to quantify how much this issue is hurting
> deployments?
>
> On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco  wrote:
>> Also, instead of creating bugs, I would suggest instead that we try to make 
>> this into a community goal. We would work with the TC and for P or Q, make 
>> it a goal to start migrating off of MD5 and have a goal for a cycle or two 
>> later to completely remove reliance on MD5.
>>
>> Doing this piecemeal via bugs will not be efficient and we'll need community 
>> buy-in.
>
> We would also need to get a reasonable scoping of the issue (which
> projects, how many instances, etc) to help decide if this is an
> achievable goal (in the sense of the 'community goals').
>
> As you noted, this will not be easy for Swift or Glance (others?), but
> if the impact to deployers can be quantified it makes it easier to
> spend energy here.

Swift does use md5 in two places: placement and integrity checking.

Placement:
MD5 is used in Swift's ring to balance the placement of data across the 
cluster. In pseudo code, we...

>>> h = hash(secret_prefix + name_of_thing + secret_suffix)
>>> lookup_index = h >> (32 - configurable_count)  # get the prefix bits
>>> list_of_drives = drive_table[lookup_index]  # get the drives this this is on

So what we're doing is using some bits at the beginning of the md5 output to 
splay the data across the system. Since md5 has even dispersion across the key 
space, this allows all the drives in the cluster to fill up evenly. This is key 
to Swift's availability, scaling, durability, and performance.

We've previously explored the idea of using some different algorithm for the 
ring hashing. We haven't for a few reasons, but primarily it's because md5 is 
"good enough" for our placement needs (fast enough, disperse enough) and is 
built in to the standard library. Also, because of the reason's below, we'll 
have to keep md5 around anyway, so there's been no big push to change this 
implementation and add a new dependency.


Integrity checking:
Swift uses md5 to detect bit flips and to do end-to-end integrity checking. We 
calculate and store the md5 of every object stored in swift and use that to 
detect if there are bit flips in the data. We have a background process that 
reads every bit of the object, computes the md5, and checks if that matches the 
stored md5. If not, the bad data is quarantined and durability is repaired from 
other data in the system. We also allow the end-user to send the expected md5 
on an object write via the etag header. If the data written to disk doesn't 
match the supplied etag, the request fails. We also return the md5 of the data 
in the etag on object read responses and use the deterministic nature of the 
hash for conditional header requests (if-match, etc).

It's highly unlikely that we will ever be able to remove md5 from this part of 
the system, even if only for legacy purposes. Even if we had a new API version 
(which we've never done before) that used a different hash function, we'd still 
have to support the v1 API. We'd also have to deal with the EB of data already 
stored in Swift clusters today. They are all hashed with md5, and we'd still 
need to use it for auditing all of the existing data.

Any "changes" in a hash library in Swift would likely be additions, not a 
replacement.

That being said, from my reading the BLAKE2* family of hash algorithms looks 
very interesting.



--John






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


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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> On 15/11/16 09:56, Monty Taylor wrote:
> > Hey everybody!
> >
> > At this past OpenStack Summit the results of the Interop Challenge were
> > shown on stage. It was pretty awesome - 17 different people from 17
> > different clouds ran the same workload. And it worked!
> >
> > However, one of the reasons it worked is because they all used the
> > Ansible modules we wrote that are based on the shade library that
> > contains the business logic needed to hide vendor differences in clouds.
> > That means that there IS a fantastic OpenStack interoperability story -
> > but only if you program in Python. That's less awesome.
> 
> So I don't want to criticise this effort, because I'm sure that it's 
> very valuable and worthy 
> 
> But it does make me sad that we've so thoroughly given up on the concept 
> of making the OpenStack APIs themselves interoperable that we're 
> building an API for our APIs (Yo dawg!) to work around it.
> 

One could argue that this is just the natural order of things in a world
where programmers are disciplined and practice separation of concerns.

Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
simply be for multi-cloud users.

IMO, it's actually just sad, and I'd like for every project's API to be
evolved for multi-cloud users. But seeing as I've seen so very little
of that actually happening, splitting it out seems like a reasonable
compromise.

> The problem is that to take advantage of the interoperability benefits 
> you'll be locked in to a single orchestration tool (Ansible/shade). If 
> you have a particular reason to use another tool (possibly, ahem, the 
> one that is an official part of OpenStack and already available in 2/3 
> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to 
> choose between whatever feature you wanted there and interoperability. 
> That's taking "there IS a fantastic OpenStack interoperability story - 
> but only if you program in Python" and kicking the can one step down the 
> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the 
> underlying APIs then *everyone* benefits.
> 

I know Monty said this, but I want to say it again: gRPC is just HTTP/2
+ protobufs. Meaning, it's available to virtually every programming
language in wide usage at this time (the limiting factor being protobuf
implementatoins):

https://github.com/google/protobuf/blob/master/docs/third_party.md

> I feel like the entire OpenStack project has, out of a desire not to be 
> opinionated, consistently failed both our users and operators by 
> encouraging all sorts of unnecessarily incompatible configurations. Not 
> to pick on any particular project but e.g. can anyone tell me why 
> Neutron doesn't automatically come, out of the box, with external 
> networks called "internet" and "openstack" so that users can create 
> floating IPs that talk to either the internet or just the control plane, 
> respectively, on any OpenStack cloud with a single Heat template (or 
> whatever) without having to paste UUIDs anywhere? What sane reason could 
> there be to even allow, let alone force, all operators to solve these 
> problems independently?
> 

Side note: As of right now, I'm pretty sure the only place where you
should have to use network UUID's pasted somewhere is Octavia.

Also, many OpenStack clouds are not on the internet, and do not want to
give instances access to the control plane. So your example perhaps
needs more thought.

> I'm sure the infra team can think of 100 pet annoyances like that. So 
> carry on, but maybe y'all could make a list somewhere of all the 
> interoperability problems that shade has had to work around and we could 
> try to make it a priority as a community to address them?
> 

Shade is the python expression of those annoyances. Oaktree would be
exposing that as a gRPC API.

__
OpenStack Development Mailing 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
> On 17/11/16 19:01, Monty Taylor wrote:
> > On 11/17/2016 05:24 PM, Zane Bitter wrote:
> >> On 15/11/16 09:56, Monty Taylor wrote:
> >>> Hey everybody!
> >>>
> >>> At this past OpenStack Summit the results of the Interop Challenge were
> >>> shown on stage. It was pretty awesome - 17 different people from 17
> >>> different clouds ran the same workload. And it worked!
> >>>
> >>> However, one of the reasons it worked is because they all used the
> >>> Ansible modules we wrote that are based on the shade library that
> >>> contains the business logic needed to hide vendor differences in clouds.
> >>> That means that there IS a fantastic OpenStack interoperability story -
> >>> but only if you program in Python. That's less awesome.
> >>
> >> So I don't want to criticise this effort, because I'm sure that it's
> >> very valuable and worthy 
> >>
> >> But it does make me sad that we've so thoroughly given up on the concept
> >> of making the OpenStack APIs themselves interoperable that we're
> >> building an API for our APIs (Yo dawg!) to work around it.
> >
> > Tell me about it. I share your sadness. In fact, that sadness has been
> > my main state for several years now.
> >
> >> The problem is that to take advantage of the interoperability benefits
> >> you'll be locked in to a single orchestration tool (Ansible/shade). If
> >> you have a particular reason to use another tool (possibly, ahem, the
> >> one that is an official part of OpenStack and already available in 2/3
> >> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
> >> choose between whatever feature you wanted there and interoperability.
> >> That's taking "there IS a fantastic OpenStack interoperability story -
> >> but only if you program in Python" and kicking the can one step down the
> >> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
> >> underlying APIs then *everyone* benefits.
> >
> > I seem to have communicated something very poorly if that's the take
> > away you've gotten. Today, if you want cross-cloud interop, you pretty
> > much need to use shade/ansible. That's not cool - because it's limiting
> > to people wanting to work in python and people wanting to orchestrate in
> > ansible. It should absolutely not be necessary to want to use those
> > tools to get the interop story.
> >
> > So one of the main reasons to do this is precisely to provide that story
> > to everyone - whether they're doing Juju and go, or puppet and ruby, or
> > just programming in Fog or whatnot.
> 
> So, say that I want to create my servers in Heat so that I can use Heat 
> software deployments for orchestration. How would I go about e.g. making 
> sure that the servers are always connected to the networks I expect on a 
> variety of different clouds? Would Oaktree figure out the networks and 
> pass them in to the stack when creating it? (I don't believe shade has 
> Heat support yet, but we should definitely add it & I don't foresee any 
> great obstacle.) Or would Heat have to add Oaktree resource types?
>

If you're wanting to use Heat, you are a) already cutting off a large
quantity of interoperable clouds because many do not have Heat, and b)
you already have provider templates to deal with the inconsistencies
across clouds.

And Shade has had Heat support in some for or another for a long time:

9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import 
heatclient.client

To answer your other question, I don't think that's actually desirable or
realistic for interop expectations. If networking were one-size-fits-all
we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
nova-network). We have Neutron so you can construct what you need inside
the cloud. Shade just normalizes the "how do I get to the instances from
outside the cloud" part, which has several different variants.

> It sounds to me like the former approach would require all of the same 
> work in the template that you'd need to handle it now (using 
> conditionals), and the only real difference is that instead of providing 
> your own environment file for each cloud you do a bit of oaktree 
> integration and that figures it out for you instead.
> 
> Adding Oaktree resource types to Heat to paper over isn't really a 
> solution from my point of view.
> 

Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
Mostly just to avoid needing to grok Keystone and all of its glory.

__
OpenStack Development Mailing 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] Stepping down from core

[Assaf Muller]

On Thu, Nov 17, 2016 at 1:42 PM, Carl Baldwin  wrote:
> Neutron (and Openstack),
>
> It is with regret that I report that my work situation has changed such that
> I'm not able to keep up with my duties as a Neutron core reviewer, L3
> lieutenant, and drivers team member. My participation has dropped off
> considerably since Newton was released and I think it is fair to step down
> and leave an opening for others to fill. There is no shortage of talent in
> Neutron and Openstack and I know I'm leaving it in good hands.
>
> I will be more than happy to come back to full participation in Openstack
> and Neutron in the future if things change again in that direction. This is
> a great community and I've had a great time participating and learning with
> you all.
>
> Well, I don't want to drag this out. I will still be around on IRC and will
> be happy to help out where I am able. Feel free to ping me.

I wish you happiness and fulfillment in your upcoming work.

This is a great loss to the Neutron community. The Routed Networks
work you led was a testament to your technical prowess and influence
that you've demonstrated consistently throughout the years. You've
made massive marks on Neutron and any project or community is lucky to
have you. Come back soon :)

>
> Carl
>
> __
> OpenStack Development Mailing 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] [docs][upgrades] time to add official docs for upgrading services?

[Doug Hellmann]

Excerpts from Steve Martinelli's message of 2016-11-17 20:36:46 -0500:
> In the keystone docs we have notes about how to upgrade between releases
> [1], so does the nova team [2].
> 
> Is it time we create an official guides to [3] for this subject?
> 
> [1] http://docs.openstack.org/developer/keystone/upgrading.html
> [2] http://docs.openstack.org/developer/nova/upgrade.html
> [3] http://docs.openstack.org/

Maybe, instead of creating a separate project-specific guide for
every topic (install, upgrade, config, API, etc.), it would make
sense to have developer, deployer, and user facing guides and create
separate chapters in each for topics relevant to the audiences?

Doug

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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 17/11/16 19:01, Monty Taylor wrote:

On 11/17/2016 05:24 PM, Zane Bitter wrote:

On 15/11/16 09:56, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.


So I don't want to criticise this effort, because I'm sure that it's
very valuable and worthy 

But it does make me sad that we've so thoroughly given up on the concept
of making the OpenStack APIs themselves interoperable that we're
building an API for our APIs (Yo dawg!) to work around it.


Tell me about it. I share your sadness. In fact, that sadness has been
my main state for several years now.


The problem is that to take advantage of the interoperability benefits
you'll be locked in to a single orchestration tool (Ansible/shade). If
you have a particular reason to use another tool (possibly, ahem, the
one that is an official part of OpenStack and already available in 2/3
of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
choose between whatever feature you wanted there and interoperability.
That's taking "there IS a fantastic OpenStack interoperability story -
but only if you program in Python" and kicking the can one step down the
road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
underlying APIs then *everyone* benefits.


I seem to have communicated something very poorly if that's the take
away you've gotten. Today, if you want cross-cloud interop, you pretty
much need to use shade/ansible. That's not cool - because it's limiting
to people wanting to work in python and people wanting to orchestrate in
ansible. It should absolutely not be necessary to want to use those
tools to get the interop story.

So one of the main reasons to do this is precisely to provide that story
to everyone - whether they're doing Juju and go, or puppet and ruby, or
just programming in Fog or whatnot.


So, say that I want to create my servers in Heat so that I can use Heat 
software deployments for orchestration. How would I go about e.g. making 
sure that the servers are always connected to the networks I expect on a 
variety of different clouds? Would Oaktree figure out the networks and 
pass them in to the stack when creating it? (I don't believe shade has 
Heat support yet, but we should definitely add it & I don't foresee any 
great obstacle.) Or would Heat have to add Oaktree resource types?


It sounds to me like the former approach would require all of the same 
work in the template that you'd need to handle it now (using 
conditionals), and the only real difference is that instead of providing 
your own environment file for each cloud you do a bit of oaktree 
integration and that figures it out for you instead.


Adding Oaktree resource types to Heat to paper over isn't really a 
solution from my point of view.



I feel like the entire OpenStack project has, out of a desire not to be
opinionated, consistently failed both our users and operators by
encouraging all sorts of unnecessarily incompatible configurations. Not
to pick on any particular project but e.g. can anyone tell me why
Neutron doesn't automatically come, out of the box, with external
networks called "internet" and "openstack" so that users can create
floating IPs that talk to either the internet or just the control plane,
respectively, on any OpenStack cloud with a single Heat template (or
whatever) without having to paste UUIDs anywhere? What sane reason could
there be to even allow, let alone force, all operators to solve these
problems independently?

I'm sure the infra team can think of 100 pet annoyances like that. So
carry on, but maybe y'all could make a list somewhere of all the
interoperability problems that shade has had to work around and we could
try to make it a priority as a community to address them?


Absolutely happy to. Some are in these slides:

http://inaugust.com/talks/real-slim-shade.html

(http://inaugust.com/talks/real-slim-shade.html#/32 is a good slide to
start with)

But I'd be happy to list out a set of issues in a form that doesn't
involve watching me give a talk.




With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to 

Re: [openstack-dev] [all] [Rally] broken jobs

[Andrey Kurilin]

yse, I think you are right.

On Fri, Nov 18, 2016 at 4:04 PM, gordon chung  wrote:

> this seems related to fact we use datetime type in mysql which requires
> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
> required mysql.
>
> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
> > Hi stackers,
> >
> > I hate to report such things, but most of rally jobs are broken now due
> > to uncompatibility aodh service with ubuntu-trusty nodes.
> >
> > If you find failed rally jobs with
> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
> > not help.
> >
> > I'm working on two changes now for Rally jobs which should unblock and
> > fix gates:
> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time
> ago.
> > - Disable telemetry services in those jobs which do not need them.
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> 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
>



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

Re: [openstack-dev] [neutron-lbaas][octavia] About playing Neutron LBaaS

[Michael Johnson]

Hi Yipei,

A note, that you probably want to use the tags [neutron-lbaas] and
[octavia] instead of [tricicle] to catch the LBaaS team attention.

Since you are using the octavia driver, can you please include a link
to your o-cw.log?  This will tell us why the load balancer create
failed.

Also, I see that your two servers are on the lb-mgmt-net, this may
cause some problems with the load balancer when you add them as
members.  The lb-mgmt-net is intended to only be used for
communication between the octavia controller processes and the octavia
amphora (service VMs).  Since you didn't get as far as adding members
I'm sure this is not the root cause of the problem you are seeing.
The o-cw log will help us determine the root cause.

Michael


On Thu, Nov 17, 2016 at 11:48 PM, Yipei Niu  wrote:
> Hi, all,
>
> Recently I try to configure and play Neutron LBaaS in one OpenStack instance
> and have some trouble when creating a load balancer.
>
> I install devstack with neutron networking as well as LBaaS in one VM. The
> detailed configuration of local.conf is pasted in the link
> http://paste.openstack.org/show/589669/.
>
> Then I boot two VMs in the OpenStack instance, which can be reached via ping
> command from the host VM. The detailed information of the two VMs are listed
> in the following table.
>
> +--+-+++-+--+
> | ID   | Name| Status | Task State |
> Power State | Networks |
> +--+-+++-+--+
> | 4cf7527b-05cc-49b7-84f9-3cc0f061be4f | server1 | ACTIVE | -  |
> Running | lb-mgmt-net=192.168.0.6  |
> | bc7384a0-62aa-4987-89b6-8b98a6c467a9 | server2 | ACTIVE | -  |
> Running | lb-mgmt-net=192.168.0.12 |
> +--+-+++-+--+
>
> After building up the environment, I try to create a load balancer based on
> the guide in https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun. When
> executing the command "neutron lbaas-loadbalancer-create --name lb1
> private-subnet", the state of the load balancer remains "PENDING_CREATE" and
> finally becomes "ERROR". I checked q-agt.log and q-svc.log, the detailed
> info is pasted in http://paste.openstack.org/show/589676/.
>
> Look forward to your valuable comments. Thanks a lot!
>
> Best regards,
> Yipei
>
> __
> OpenStack Development Mailing 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] Obtaining version information for Docker container

[Joshua Harlow]

So just something that I can share about what we are putting in our 
images, since they are getting built from jenkins we shove in pretty 
much all the jenkins build information into it:


$ IMG=""
$ docker run $IMG cat /jenkins.json
{
"Project": "glance",
"Project git": "https://github.com/openstack/glance.git;,
"Project ref": "stable/liberty",
"Deploy git": 
"g...@github.secureserver.net:cloudplatform/openstack-deploy.git",

"Deploy ref": "master",
"Docker repo (for push)": "docker-cloud-ostack-local",
"Requirement git": "git://git.openstack.org/openstack/requirements",
"Requirement ref": "stable/liberty",
"Python venv": "python2.7",
"Unit test path": "./glance/tests/unit",
"Kolla git": "https://github.com/openstack/kolla.git;,
"Kolla ref": "stable/newton",
"Kolla image namespace": 
"docker-cloud-ostack-local.artifactory.secureserver.net",

"Maintainers": "Cloud Platform [ELS] (cl...@godaddy.com)",
"Job name": "glance",
"Job build id": "55",
"Job build number": "55",
"Job build url": 
"http://jenkins-master.cloud.dev.phx3.gdg:8080/job/glance/55/;,

"Job started at": "Tue Nov 15 16:45:40 MST 2016",
"Project details": {
"version": "11.0.2.dev18",
"name": "glance",
"author": "OpenStack",
"fullname": "glance-11.0.2.dev18",
"url": "http://www.openstack.org/;
}
}

That's what we are currently shoving in, which includes the project data 
also and various other useful goodies that help identify where the image 
came from and where it was built and when.


Steven Dake (stdake) wrote:

Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider
audience. I don’t have a clear solution to obtaining version manifests
for container content or the upstream container version. Perhaps someone
in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be
run with docker exec to obtain a proper version manifest of both 1 and 2
(formatted in YAML or plaintext). This could be placed in the base
container image to enable a general diagnostic and certificate of origin
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn "
>
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake >
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a
running container or image.
you know , the version info is wrapped by the container, it is not easy
to get them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by calling docker exec...
but how to get the one, Is there any way, 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


__
OpenStack Development Mailing 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] [architecture] Reminder: Arch-WG Meeting today, and -- repo

[Clint Byrum]

Apologies for last week, it completely slipped my mind while I was
traveling.

The EU meeting time is now 2000 UTC, which is very early in the morning
for most of Asia.

I'll try to be better about running the APAC friendly time slot.

Excerpts from Zhipeng Huang's message of 2016-11-18 17:07:21 +0800:
> i attended the Asia friendly meeting several times but found no one was on
> it, is the EU one also Asia friendly ?
> 
> On Fri, Nov 18, 2016 at 4:57 PM, Thierry Carrez 
> wrote:
> 
> > Clint Byrum wrote:
> > > Just a friendly reminder that we have a meeting today at 19:00 UTC.
> > > Please come join us and add anything you'd like to talk about to the
> > > Agenda:
> > >
> > > https://wiki.openstack.org/wiki/Meetings/Arch-WG
> > >
> > > On another note, we have a repository now to facilitate our processes:
> > >
> > > https://review.openstack.org/#/q/project:openstack/arch-wg
> > >
> > > I've added two cores beside myself, Thierry and Dean, as they've been
> > > the most active thus far. If anyone else would like to help review
> > > things, just please raise your hand at the meeting and we'll talk about
> > > it.
> > >
> > > We'll be filling the repo with a structure and some docs for
> > participation
> > > soon. In the mean time, come to our meeting and submit things you'd like
> > > to work with us on to improve the architecture of OpenStack.
> >
> > Note that we proposed to move the EU-time meeting one hour later to
> > avoid conflicting with dinner time in Europe and encourage more
> > participation. Feel free to chime in on:
> >
> > https://review.openstack.org/#/c/399206/
> >
> > --
> > 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
> >
> 
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

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

Re: [openstack-dev] [kolla] Obtaining version information for Docker container

[Pete Birley]

I've been thinking about this a bit as well, and think that we should
consider using the docker label schema (http://label-schema.org/rc1/) as a
solution for #1, it would be possible to add labeling to kolla-build to add
these labels simply. This solution is gaining traction in the docker
community, and integrates well with external tools e.g.
https://microbadger.com. One of the maintainers of this project (Adrian
Mouat) works in the same room as me and I've cc'd him in case he has any
additional insight or perspective that may be useful.

Unfortunately this does not provide a solution to the 2nd problem, and
currently it is not possible to query labels from within a container. I
think Steve's suggestion of a simple shell tool to query the containers
package manager(s) and produce a report is probably the right way to go:
but we should draw up a specification that scoped what data we collected in
such a manifest as if we simply do the equivalent of 'rpm -qa' then I think
Paul's point is valid and we don't gain much from the exercise.

Cheers

Pete

On Fri, Nov 18, 2016 at 11:51 AM, Steven Dake (stdake) 
wrote:

> Zhu,
>
> This isn’t the first time this question has been asked :)
>
> Since this is a technical matter, I’ve copied openstack-dev for a wider
> audience.  I don’t have a clear solution to obtaining version manifests for
> container content or the upstream container version.  Perhaps someone in
> our broader community may have an answer.
>
> The best I’ve got is we could add a general shell command that can be run
> with docker exec to obtain a proper version manifest of both 1 and 2
> (formatted in YAML or plaintext).  This could be placed in the base
> container image to enable a general diagnostic and certificate of origin
> tool.
>
> Perhaps someone has a better solution?
>
> Regards
> -steve
>
>
> From: "zhu.z...@zte.com.cn" 
> Date: Friday, November 18, 2016 at 1:56 AM
> To: Steven Dake 
> Subject: 
>
> Hello，nice to meet you. I am a contributor of Kolla.
> Excuse me, I have a question to bother you.
> The question is that how to get openstack component version from a running
> container or image.
> you know , the version info is wrapped by the container, it is not easy to
> get them
> there are two type of versions
> one: version in a image, two: version in a running container
> two is easy, for example , we can get it by calling docker exec...
> but how to get the one, Is there any way, 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
>
>


-- 

[image: Port.direct] 

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
OpenStack Development Mailing 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] Source build gates are now voting

[Mauricio Lima]

great!

2016-11-18 14:51 GMT-03:00 Michał Jastrzębski :

> Hello,
>
> Since we split ansible, we can now afford to have some voting gates,
> for start - source build gates for 3 major distros are now voting.
>
> Cheers,
> Michal
>
> __
> OpenStack Development Mailing 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] [kolla] Source build gates are now voting

[Michał Jastrzębski]

Hello,

Since we split ansible, we can now afford to have some voting gates,
for start - source build gates for 3 major distros are now voting.

Cheers,
Michal

__
OpenStack Development Mailing 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][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?

[Morales, Victor]

Thant’s remind me when we tried to improve cloud-init.  Basically, the 
discovery process checks sequentially where the instance is being landed(EC2, 
GoogleCompute, OpenStack).  This process could be done in parallel and reduce 
the time to boot.

Regards, 
Victor Morales




On 11/16/16, 11:31 AM, "Mathieu Gagné"  wrote:

>On Wed, Nov 16, 2016 at 11:52 AM, Clint Byrum  wrote:
>>
>> IMO the HTTP metadata service and the way it works is one of the worst
>> ideas we borrowed from EC2. Config drive (which I didn't like when I
>> first saw it, but now that I've operated clouds, I love) is a simpler
>> system and does not present any real surface area to the users.
>>
>
>Cannot agree more with you on that one.
>
>--
>Mathieu
>
>__
>OpenStack Development Mailing 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] Obtaining version information for Docker container

[Fox, Kevin M]

Steve, (And the rest of kolla)

This raises a question I've had for a while and wanted to talk through.

Right now, kolla versions containers based on the kolla version (packaging 
version).

In most package managers dpkg/rpm/etc, the versioning is done in a very 
different way.

The software being shipped gets the version number, and a packaging version 
number is appended with a dash. so,
14.0.3-1
If the packaging is buggy but the software doesn't have a new release, it gives 
a nice place to fix that:
14.0.3-2

This lets the user very quickly see what the upstream software number is, which 
is what is most cared about.

Its flexible enough to use complicated packaging versions too .  For example, 
redhats kernel package:
kernel-3.10.0-327.13.3 (version 3.10.0 kernel, 327.13.3 version of the package)

I think containers are a slightly more unique case as not only the primary 
software release is in there, but also all its dependencies. so there is a case 
where the primary software doesn't change, the packaging stuff doesn't change, 
but the dependencies get updated.
So, I think my proposal is to tag on a build number at the end. so something 
like:
14.0.3-1-1
then a pure dependency security update (openssl upgraded for example) would 
produce
14.0.3-1-2

If we tag everything this way, it should be easy for someone to know, for 
example, what version of nova the package was, and if there is a more up to 
date version of the package then what is currently running on their system. It 
would allow folks to apply the common pattern for packaging that is already 
commonly understood. We might even might be able to automate the 
scanning/update process in kolla to assist with that at some point.

What do you think?

Thanks,
Kevin



From: Steven Dake (stdake) [std...@cisco.com]
Sent: Friday, November 18, 2016 3:51 AM
To: zhu.z...@zte.com.cn
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] Obtaining version information for Docker 
container

Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider 
audience.  I don’t have a clear solution to obtaining version manifests for 
container content or the upstream container version.  Perhaps someone in our 
broader community may have an answer.

The best I’ve got is we could add a general shell command that can be run with 
docker exec to obtain a proper version manifest of both 1 and 2 (formatted in 
YAML or plaintext).  This could be placed in the base container image to enable 
a general diagnostic and certificate of origin tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn" 
>
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake >
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a running 
container or image.
you know , the version info is wrapped by the container, it is not easy to get 
them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by calling docker exec...
but how to get the one, Is there any way, 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] Stepping down from core

[Morales, Victor]

Hey Carl,

These are sad news, thanks for those years helping to make OpenStack better, 
best of the wishes for your future assignments.

Thanks,
Victor Morales

From: Carl Baldwin >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, November 17, 2016 at 12:42 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such that 
I'm not able to keep up with my duties as a Neutron core reviewer, L3 
lieutenant, and drivers team member. My participation has dropped off 
considerably since Newton was released and I think it is fair to step down and 
leave an opening for others to fill. There is no shortage of talent in Neutron 
and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack and 
Neutron in the future if things change again in that direction. This is a great 
community and I've had a great time participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and will be 
happy to help out where I am able. Feel free to ping me.

Carl
__
OpenStack Development Mailing 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] Managing cluster drivers as individual distro packages

[Drago Rosson]

If we were to go with (2), what should happen to the common code?

From: Spyros Trigazis >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, November 18, 2016 at 8:34 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [magnum] Managing cluster drivers as individual distro 
packages

Hi all,

In magnum, we implement cluster drivers for the different combinations
of COEs (Container Orchestration Engines) and Operating Systems. The
reasoning behind it is to better encapsulate driver-specific logic and to allow
operators deploy custom drivers with their deployment specific changes.

For example, operators might want to:
* have only custom drivers and not install the upstream ones at all
* offer user only some of the available drivers
* create different combinations of  COE + os_distro
* create new experimental/staging drivers

It would be reasonable to manage magnum's cluster drivers as different
packages, since they are designed to be treated as individual entities. To do
so, we have two options:

1. in-tree:  remove the entrypoints from magnum/setup.cfg to not install them
by default. This will require some plumbing to manage them like separate python
packages, but allows magnum's development team to manage the official drivers
inside the service repo.

2. separate repo: This option sounds cleaner, but requires more refactoring and
will separate more the drivers from service, having significant impact in the
development process.

Thoughts?

Spyros
__
OpenStack Development Mailing 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] Stepping down from core

[Jakub Libosvar]

Sad to see you stepping down. Thanks for making Neutron better and good 
luck in your new adventures!


Jakub

On 17/11/2016 19:42, Carl Baldwin wrote:

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such
that I'm not able to keep up with my duties as a Neutron core reviewer,
L3 lieutenant, and drivers team member. My participation has dropped off
considerably since Newton was released and I think it is fair to step
down and leave an opening for others to fill. There is no shortage of
talent in Neutron and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in
Openstack and Neutron in the future if things change again in that
direction. This is a great community and I've had a great time
participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and
will be happy to help out where I am able. Feel free to ping me.

Carl


__
OpenStack Development Mailing 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] Subscribe to release-announces to get future OpenStack release announcements !

[Thierry Carrez]

Hi everyone,

As OpenStack produces more deliverables (and some projects do frequent
intermediary releases within the cycle), release announcements have been
creating a lot of noise on the openstack-announce and openstack-dev
mailing-lists, sometimes creating distraction away from more important
announcements, or discouraging people to subscribe.

In order to cut that noise while preserving that information, the
release team proposed[1] to create a specific mailing-list for release
announcements, distinct from openstack-announce (now limited to key
announcements) and openstack-dev (now limited to development discussion).

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106579.html

So if you are interested in directly receiving release announcements in
the future, please subscribe to:

http://lists.openstack.org/cgi-bin/mailman/listinfo/release-announce

To reduce noise, the list is set up by default to send only one email
per day (digest mode) with all the release announcements of that day. If
you would like to switch to receiving release announces immediately (one
email per announcement), just switch the "Set Digest Mode" option to
"Off" in your subscription options.

This list will start to be used for release announcements starting
Monday, November 21.


PS: if you're not currently subscribed to openstack-announce, please
consider joining it. Starting next week, it will only be used for major
announcements for the OpenStack Community (one release announce email
per cycle at the end of the release, urgent security advisories,
election announcements, etc...) and be very low-traffic again. You can
find it here:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

Regards,

-- 
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] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[Ian Cordasco]

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

Date: November 18, 2016 at 10:15:44
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [security] FIPS Compliance (Was: 
[requirements][kolla][security] pycrypto vs cryptography)

> > -Original Message-
> > From: Luke Hinds  
> [...]
> >> for non security related functions, but when it comes to government
> >> compliance and running OpenStack on public clouds (and even private for the
> >> Telcos / NFV), not meeting FIPS will in some cases block production getting
> >> a green light, or at least make it a big challenge to push through.
>  
> Are there any know cases of this happening? If so, can those be
> publicly documented to quantify how much this issue is hurting
> deployments?

I too would be very interested in learning about these.

>  
> On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco wrote:
> > Also, instead of creating bugs, I would suggest instead that we try to make 
> > this into  
> a community goal. We would work with the TC and for P or Q, make it a goal to 
> start migrating  
> off of MD5 and have a goal for a cycle or two later to completely remove 
> reliance on MD5.  
> >
> > Doing this piecemeal via bugs will not be efficient and we'll need 
> > community buy-in.  
>  
> We would also need to get a reasonable scoping of the issue (which
> projects, how many instances, etc) to help decide if this is an
> achievable goal (in the sense of the 'community goals').
>  
> As you noted, this will not be easy for Swift or Glance (others?), but
> if the impact to deployers can be quantified it makes it easier to
> spend energy here.

Well it is easy for Glance (I even did a PoC sometime back). The problem with 
Glance, presently, is primarily the v1 API (the fact that it's deprecated and 
uses devices like Content-MD5 for metadata). After that we could absolutely 
return MD5 and SHA2 for a cycle or three. We would just need people integrating 
with Glance to them pick up the work.

If I remember correctly, Nova does some validation of the image based on hash 
value, and I would guess that the patch to use SHA2 when available would be 
somewhat easy. After that, it's the users writing integrations that we need to 
worry about. That's the biggest unknown piece of this puzzle to me. How many 
people integrate directly with Glance and how many of those rely on MD5 being 
the hash algorithm to determine the integrity of the image?

--  
Ian Cordasco


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

Re: [openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[Dean Troyer]

> -Original Message-
> From: Luke Hinds 
[...]
>> for non security related functions, but when it comes to government
>> compliance and running OpenStack on public clouds (and even private for the
>> Telcos / NFV), not meeting FIPS will in some cases block production getting
>> a green light, or at least make it a big challenge to push through.

Are there any know cases of this happening?  If so, can those be
publicly documented to quantify how much this issue is hurting
deployments?



On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco  wrote:
> Also, instead of creating bugs, I would suggest instead that we try to make 
> this into a community goal. We would work with the TC and for P or Q, make it 
> a goal to start migrating off of MD5 and have a goal for a cycle or two later 
> to completely remove reliance on MD5.
>
> Doing this piecemeal via bugs will not be efficient and we'll need community 
> buy-in.

We would also need to get a reasonable scoping of the issue (which
projects, how many instances, etc) to help decide if this is an
achievable goal (in the sense of the 'community goals').

As you noted, this will not be easy for Swift or Glance (others?), but
if the impact to deployers can be quantified it makes it easier to
spend energy here.

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

Re: [openstack-dev] [Neutron] Stepping down from core

[Singh, Aradhana1]

Thank you for your guidance and support Carl. Appreciate it.
All the best for future endeavors.

Regards,
Aradhana
From: Carl Baldwin [mailto:c...@ecbaldwin.net]
Sent: Thursday, November 17, 2016 12:43 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such that 
I'm not able to keep up with my duties as a Neutron core reviewer, L3 
lieutenant, and drivers team member. My participation has dropped off 
considerably since Newton was released and I think it is fair to step down and 
leave an opening for others to fill. There is no shortage of talent in Neutron 
and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack and 
Neutron in the future if things change again in that direction. This is a great 
community and I've had a great time participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and will be 
happy to help out where I am able. Feel free to ping me.

Carl
__
OpenStack Development Mailing 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] [git-upstream] [Duplicate Changes] How to view only commits applied since last import

[Darragh Bailey - mailing lists]

On 18/11/16 15:27, Darragh Bailey - mailing lists wrote:
> 


> At this point, now you'll see X, X' & X'', and Y, Y' & Y''. Obviously
> this cause a bit of confusion when listing the changes using:
> 
>  git log --oneline --graph E~1..local/mitaka
> 
> you see something like the following (see [1] for how I created this):
> 
> *   899cb6e [O] Merging Y2 into N
> |\
> | * 3c08f48 [Y] Adding tmp7wtzvo69  <--- really Y''
> | * db8d2c3 [X] Adding tmpnxot0u9s
> | * 97cc90c [I] Adding tmps2xhxp2f
> * |   9ea35c3 [N] Merging Y1 into Y
> |\ \
> | * | f361e9f [Y] Adding tmp7wtzvo69  <--- really Y'
> | * | 90d58eb [X] Adding tmpnxot0u9s
> | |/
> | * ed973e6 [G] Adding tmpb443aabz
> | * 74cd9b8 [E] Adding tmpwcrm4bxi
> * 3cc85cf [Y] Adding tmp7wtzvo69  <--- original Y
> * e93f6cb [X] Adding tmpnxot0u9s

I forgot to add the reference for how I generated that tree:

git clone git://git.openstack.org/openstack/git-upstream
cd git-upstream
cat < test.yaml
- tree:
- [A, []]
- [E, [A]]
- [G, [E]]
- [I, [G]]
- [X, [A]]
- [Y, [X]]
- [X1, [G]]
- [Y1, [X1]]
- [N, [Y, =Y1]]
- [X2, [I]]
- [Y2, [X2]]
- [O, [N, =Y2]]

  branches:
head: [local/mitaka, O]
upstream: [stable/mitaka, I]
EOF
tox -e build-tree -- test.yaml
cd .git-test-trees/test

--
Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown

__
OpenStack Development Mailing 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] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[Ian Cordasco]

 

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

Date: November 18, 2016 at 08:43:42
To: OpenStack Development Mailing List (not for usage questions) 

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

> Hi,
>  
> I missed this thread, so top posting with a related topic..
>  
> We discussed FIPS 140-2 yesterday in the OSSP irc meeting.
>  
> I recently tried running OpenStack on a FIPS 140-2 enabled kernel in
> CentOS, and all of instances of MD5 use (mainly hashlib.md5) were rejected
> resulting in the various python scripts bailing out with a stack trace. As
> someone pointed out already, MD5 is considered weak, and does not meet the
> FIPS list of secure crypto. I understand some projects might well use MD5
> for non security related functions, but when it comes to government
> compliance and running OpenStack on public clouds (and even private for the
> Telcos / NFV), not meeting FIPS will in some cases block production getting
> a green light, or at least make it a big challenge to push through.
>  
> With this in mind, perhaps all projects should seriously consider migrating
> to more up to date methods such as sha256 or bcrypt, and start to
> depreciate MD5 use.
>  
> I proposed raising bugs on launchpad for each instance discovered, so that
> if anything, we at least have an idea of the extent of work needed to reach
> the needed level of compliance for FIPS 140-2.
>  
> Thoughts welcome?

Well, are they or aren't they? ;)

So, specifically talking to MD5, this is a thing I've been trying to convince 
Glance to move away from for a while. The problem we have is that we need a 
strong migration path. I suspect part of the use of MD5 initially in Glance is 
due to its age (although we already knew MD5 was weak when Glance became its 
own project) and partially due to the fact that lots of operators used Swift as 
a Glance storage mechanism.

As for deprecating MD5 in favor of other hash algorithms, I don't think we 
should just jump to the a new algorithm (SHA2 or bcrypt) because, for one 
thing, only one of those you mentioned is FIPS compliant iirc (SHA2). For 
another, is a hash really what we want to judge the integrity of all data? Are 
there not better mechanisms for this? Blake2 would be good and has variations 
that are optimized for different hardware types (but it's almost certain not 
FIPS).

On top of that, what does the migration path look like for services that use 
the MD5 sum to verify properties and integrity internally and return that using 
the `Content-MD5` header? There's no replacement for that header in the 
7230-7235 update of HTTP/1.1 and while we could make something up like 
`Content-SHA2` it probably will be confusing to users. (And no, using 
X-prefixed headers is no longer valid per RFCs and hasn't been for *years*.)

In short, I want to see us moving off MD5, but it will not be easy. I would bet 
that Glance and Swift will both be very resistant to this kind of change. We've 
had enough problems in Glance improving the usability of the *visibility* image 
attribute that I doubt we'd ever be able to migrate it to SHA2.

Also, instead of creating bugs, I would suggest instead that we try to make 
this into a community goal. We would work with the TC and for P or Q, make it a 
goal to start migrating off of MD5 and have a goal for a cycle or two later to 
completely remove reliance on MD5.

Doing this piecemeal via bugs will not be efficient and we'll need community 
buy-in.

--  
Ian Cordasco


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

[openstack-dev] [watcher] Barcelona summit summary

[Susanne Balle]

Hi



We had a super productive summit with many very active participants. Thanks
to everybody who participated.



Detailed minutes are available at:
https://etherpad.openstack.org/p/watcher-ocata-design-session



We had a talk and 4 Watcher sessions during the summit.



- The *first session* was a Fishbowl session where we discussed the list of
strategies available in Watcher as well as went over Watcher and its
charter for new people interested in Watcher.


- On Thursday, Jean-Emile (jed56), Joe (jwcroppe) and myself (sballe) gave *a
talk on “Watcher, the Infrastructure Optimization service for OpenStack:
Plans for the O-release and beyond”.* We had more than 50 people attending
the session.


- During the *second Watcher session*, we did a Watcher Newton
retrospective for the Newton release.


   - The great accomplishment was that we got Watcher accepted into the big
   tent in May.
   - AT described a use case around NFV placement where there is a need
   to optimize a small clouds at the edge.
   - We talked about needing more people to do reviews both on spec and on
   code.

- During the *third Watcher session*, we validated Ocata priorities &
assignees. We discussed all the blueprints in details and ensured that our
load for Ocata is reasonable and inline with previous releases..


   - As part of this session we discussed the deprecation of the Ceilometer
   APIs and the impact on Watcher. While no final decision was taken around
   this topic the team felt that supporting Monasca as a backend for telemetry
   was a good strategy given the scalability issue with the current version of
   Ceilometer and Gnocchi’s early stages.

- The *fourth session* was a community meetup. We discussed
multi-datacenter(multi-region) workload optimization, how to bridge to non
OpenStack public cloud and container Clouds, etc.



Thanks again to everyone for a great summit.

Regards,

Susanne
__
OpenStack Development Mailing 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] [git-upstream] [Duplicate Changes] How to view only commits applied since last import

[Darragh Bailey - mailing lists]

On 17/11/16 12:47, Paul Bourke wrote:
> Hi Darragh / git-upstream community,
> 
> I've been looking at a way to easily view a log of what commits made
> since the last upstream import when managing a branch with git-upstream.
> Right now this can be hard to do - something like 'git log
> upstream/master..HEAD' shows a lot of duplicate commits reasons I don't
> understand well enough to explain.


As mentioned I thought it might be worth addressing this piece
separately, and then hopefully re-factor what's here to be added to the
git-upstream docs.


To start with, lets step through what things look like, and then I'll
try explain why git-upstream merges history in this way.



Assuming there are two local changes being carried locally that have not
yet been accepted upstream. These were initally added to a local/mitaka
branch and two imports were subsequently performed and the changes have
not yet landed on stable/mitaka:


   X---Y---NO local/mitaka
  /   //
 /   X'--Y'   /   (rebase of X & Y onto G)
/   //
   /   /   X''--Y''
  /   /   /
-E---G---Iupstreams stable/mitaka branch


When syncing latest from upstream stable/mitaka was initially at G, and
this resulted git-upstream replaying X' being onto G and then creating a
merge commit N which has exactly the same contents as the tree at X'.


When you look at the history of N you'll see:

 X---Y---N
/   /
   /   X'--Y'
  /   /
-E---G

And then looking at O shows


   X---Y---NO local/mitaka
  /   //
 /   X'--Y'   /
/   //
   /   /   X''--Y''
  /   /   /
-E---G---I


At this point, now you'll see X, X' & X'', and Y, Y' & Y''. Obviously
this cause a bit of confusion when listing the changes using:

 git log --oneline --graph E~1..local/mitaka

you see something like the following (see [1] for how I created this):

*   899cb6e [O] Merging Y2 into N
|\
| * 3c08f48 [Y] Adding tmp7wtzvo69  <--- really Y''
| * db8d2c3 [X] Adding tmpnxot0u9s
| * 97cc90c [I] Adding tmps2xhxp2f
* |   9ea35c3 [N] Merging Y1 into Y
|\ \
| * | f361e9f [Y] Adding tmp7wtzvo69  <--- really Y'
| * | 90d58eb [X] Adding tmpnxot0u9s
| |/
| * ed973e6 [G] Adding tmpb443aabz
| * 74cd9b8 [E] Adding tmpwcrm4bxi
* 3cc85cf [Y] Adding tmp7wtzvo69  <--- original Y
* e93f6cb [X] Adding tmpnxot0u9s


If this is limited further to:

 git log --oneline --graph stable/mitaka..local/mitaka

*   899cb6e [O] Merging Y2 into N
|\
| * 3c08f48 [Y] Adding tmp7wtzvo69  <--- really Y''
| * db8d2c3 [X] Adding tmpnxot0u9s
*   9ea35c3 [N] Merging Y1 into Y
|\
| * f361e9f [Y] Adding tmp7wtzvo69  <--- really Y'
| * 90d58eb [X] Adding tmpnxot0u9s
* 3cc85cf [Y] Adding tmp7wtzvo69
* e93f6cb [X] Adding tmpnxot0u9s  <--- original Y

This looks like the same 2 changes have been applied three times, and in
a way, they have.

This obviously can be confusing. Hence you're proposed change to provide
a way to display only the interesting commits so instead would see:

* 899cb6e [O] Merging Y2 into N
* 3c08f48 [Y] Adding tmp7wtzvo69  <--- really Y''
* db8d2c3 [X] Adding tmpnxot0u9s


> Thanks in advance for anything that might help cut through some of the
> confusion.
> 
> Cheers,
> -Paul

Back to the question as to why git-upstream does it this way:

Looked at possibility of merges, just land patches against the tree and
then on a regular basis attempt to merge in the latest from upstream.

* It's possible (if a little awkward at the moment) to extract
information on how many local patches are being carried. Merging would
meant that you wouldn't see the same patches from the series duplicated,
but you would have multiple commits in your local history that are
likely not identifiable as cherry-picks of the final accepted change
upstream (how many patches are accepted without any changes?)

* Re-applying changes allows for conflicts with changes to be resolved
in the relevant patch. Otherwise the conflicts are resolved inside a
merge commit can be quite hard to review. Subsequently when the changes
are accepted upstream, and then merged in on the next sync the conflicts
generated will frequently be different since the change accepted
upstream will be slightly different. Using a patch series approach
allows to automatically drop the duplicate changes, and re-apply an
update series, using a manual merge commit with conflict resolution
means likely someone is going to have to spend more time resolving
conflicts.

* Want to avoid rebasing published branches. As far as developers inside
a company are concerned, the local branches are published history, and
for them to co-operate when issues need to be fixed for internal
testing/releases to continue, rewriting history is likely going to make
life more difficult. Rebasing a published branch can work, and I know
some linux kernel developers have 

Re: [openstack-dev] [devstack] Specify OpenvSwitch version in local.conf

[Geza Gemes]

On 11/18/2016 07:33 AM, zhi wrote:

hi, all.

I have a quick question about devstack.

Can I specify OpenvSwitch version in local.conf when during the 
installation of devstack? I want to OVS 2.6.0 in my devstack. Can I 
specify it?



Thanks
Zhi Chang


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


Hi,

On Ubuntu and Fedora (I didn't try elsewhere) stack.sh installs the 
latest (except if there is any pinning) version available according to 
apt/yum. So if you have it available in the configured repos then you'll 
have it. Otherwise if you have a package (e.g. locally built) installed 
newer than the available it will also not downgrade it.


Cheers,

Geza

__
OpenStack Development Mailing 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] [docs][upgrades] time to add official docs for upgrading services?

[Barrett, Carol L]

Yes, I think it’s time to create a specific guide for this. It’s a topic of 
high interest for Operators (current and future) and helping them to understand 
how to plan their deployment for upgradability (ideally non-disruptive 
upgrades) would be very valuable.
Carol

From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: Thursday, November 17, 2016 5:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
; openstack-d...@lists.openstack.org
Subject: [openstack-dev] [docs][upgrades] time to add official docs for 
upgrading services?

In the keystone docs we have notes about how to upgrade between releases [1], 
so does the nova team [2].

Is it time we create an official guides to [3] for this subject?

[1] http://docs.openstack.org/developer/keystone/upgrading.html
[2] http://docs.openstack.org/developer/nova/upgrade.html
[3] http://docs.openstack.org/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Stepping down from core

[Anita Kuno]

On 2016-11-17 01:42 PM, Carl Baldwin wrote:

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such
that I'm not able to keep up with my duties as a Neutron core reviewer, L3
lieutenant, and drivers team member. My participation has dropped off
considerably since Newton was released and I think it is fair to step down
and leave an opening for others to fill. There is no shortage of talent in
Neutron and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack
and Neutron in the future if things change again in that direction. This is
a great community and I've had a great time participating and learning with
you all.

Well, I don't want to drag this out. I will still be around on IRC and will
be happy to help out where I am able. Feel free to ping me.

Carl




Thank you, Carl.

Anita.

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

[openstack-dev] [new][documentation] openstack-doc-tools 1.2.1 release

[no-reply]

We are frolicsome to announce the release of:

openstack-doc-tools 1.2.1: Tools for OpenStack Documentation

The source is available from:

http://git.openstack.org/cgit/openstack/openstack-doc-tools

Download the package from:

https://tarballs.openstack.org/openstack-doc-tools/

Please report issues through launchpad:

http://bugs.launchpad.net/openstack-manuals

For more details, please see below.

1.2.1
^


Bug Fixes
*

* Fix doc-tools-check-languages, it used a wrong way of passing
  arguments to tox and failed therefore with tox 2.5.0.


Other Notes
***

* The configuration items for autohelp are now in the openstack-
  manuals repository.

* Use jinja templating system to generate configuration reference
  tables.

* Unsupport OpenStackClient in CLI Reference in favor of docs in the
  OSC project itself.

* autohelp.py update will create the flagmappings file if it doesn't
  exist yet.

Changes in openstack-doc-tools 1.2.0..1.2.1
---

5d48d97 Fix doc-tools-check-languages
99c3a4d Properly pass arguments for language building
3fdbbc3 Typo mistake
0f01f52 Updated from global requirements
209dcd0 [cli-reference] remove sahara CLI support
51e3476 Updated from global requirements
67691c3 Don't include openstack/common in flake8 exclude list
1312d4b Updated from global requirements
1dadc93 Add prefix "$" for command examples
c8f4375 [config-ref] support URIOpt/HostnameOpt to auto config doc tool
858b941 [config-ref] support IPOpt into auto config doc tool
699e82d Enable release notes translation
c99bb68 Mitaka is an old release now
8a8411e Improve the README file of the sitemap generator
92a4fb6 Move SitemapItem class into generator.spiders.sitemap_file
e508296 Updated from global requirements
1057a48 [config-ref] Remove heading and trailing blanks from help
dfa602d Remove unnecessary white space
03a5618 Update flake8 ignore list
52d9c52 Change assertTrue(isinstance()) by optimal assert
ff558eb Move release notes to be handled by reno
dfe5988 [cli-ref] cleanup osc cli reference tools


Diffstat (except docs and test files)
-

README.rst | 12 
RELEASE_NOTES.rst  |  2 +-
autogenerate_config_docs/autohelp.py   |  8 --
.../notes/conf-in-manuals-f2d57e04ee35741f.yaml|  4 ---
.../notes/switch-to-jinja-4b8d143f872a2495.yaml|  3 --
.../notes/update-can-create-097dd0790567eeb5.yaml  |  3 --
bin/doc-tools-check-languages  | 30 ++--
bin/doc-tools-update-cli-reference | 12 +---
os_doc_tools/commands.py   | 32 +++---
os_doc_tools/resources/clients.yaml|  2 --
.../notes/conf-in-manuals-f2d57e04ee35741f.yaml|  4 +++
.../notes/fix-langs-tox-c3ead8fa02de31fc.yaml  |  5 
.../notes/switch-to-jinja-4b8d143f872a2495.yaml|  3 ++
.../unsupport-osc-cli-ref-191b42b312f1ce89.yaml|  4 +++
.../notes/update-can-create-097dd0790567eeb5.yaml  |  3 ++
releasenotes/source/conf.py|  3 ++
requirements.txt   |  6 ++--
sitemap/README.rst | 30 
sitemap/generator/items.py | 21 --
sitemap/generator/spiders/sitemap_file.py  | 15 --
sitemap/test/generator/test_pipelines.py   |  4 +--
test-requirements.txt  |  2 +-
tox.ini|  6 ++--
23 files changed, 93 insertions(+), 121 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e6c0afd..d5a8501 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-pbr>=1.6 # Apache-2.0
+pbr>=1.8 # Apache-2.0
@@ -8 +8 @@ lxml>=2.3 # BSD
-oslo.config>=3.14.0 # Apache-2.0
+oslo.config!=3.18.0,>=3.14.0 # Apache-2.0
@@ -11 +11 @@ demjson # GLGPLv3+
-PyYAML>=3.1.0 # MIT
+PyYAML>=3.10.0 # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index 3cac23e..52ebe21 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ pylint==1.4.5 # GPLv2
-reno>=1.8.0 # Apache2
+reno>=1.8.0 # Apache-2.0



__
OpenStack Development Mailing 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] Fwd: Re: [requirements][kolla][security] pycrypto vs cryptography

[Jeremy Stanley]

On 2016-11-18 14:38:22 + (+), Luke Hinds wrote:
[...]
> I proposed raising bugs on launchpad for each instance discovered, so that
> if anything, we at least have an idea of the extent of work needed to reach
> the needed level of compliance for FIPS 140-2.
[...]

It's come up plenty over the years and I think a lot of the easier
cases have already been fixed. Places where you'll have more trouble
are the ones like https://launchpad.net/bugs/1348339 (inherited from
Swift's use of MD5 for etags).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron] Stepping down from core

[Miguel Lavalle]

Carl,

Sad to see this happening. I've learned a lot from you. Good luck

Cheers

On Thu, Nov 17, 2016 at 12:42 PM, Carl Baldwin  wrote:

> Neutron (and Openstack),
>
> It is with regret that I report that my work situation has changed such
> that I'm not able to keep up with my duties as a Neutron core reviewer, L3
> lieutenant, and drivers team member. My participation has dropped off
> considerably since Newton was released and I think it is fair to step down
> and leave an opening for others to fill. There is no shortage of talent in
> Neutron and Openstack and I know I'm leaving it in good hands.
>
> I will be more than happy to come back to full participation in Openstack
> and Neutron in the future if things change again in that direction. This is
> a great community and I've had a great time participating and learning with
> you all.
>
> Well, I don't want to drag this out. I will still be around on IRC and
> will be happy to help out where I am able. Feel free to ping me.
>
> Carl
>
> __
> OpenStack Development Mailing 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][git]How to backport commit after repo split

[Jeremy Stanley]

On 2016-11-17 23:10:50 -0500 (-0500), Juan L. Negron wrote:
> At some point, it would be good if the kolla-ansible repo is added
> as a submodule of the kolla one to simplify things.

This already came up here this week in a related thread on the repo
split, and then again at the Kolla meeting. I won't reiterate the
reasons for avoiding Git submodules, but suggest reviewing the
meeting log:

http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-11-16-16.01.log.html#l-108

-- 
Jeremy Stanley

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

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

[Luke Hinds]

Hi,

I missed this thread, so top posting with a related topic..

We discussed FIPS 140-2 yesterday in the OSSP irc meeting.

I recently tried running OpenStack on a FIPS 140-2 enabled kernel in
CentOS, and all of instances of MD5 use (mainly hashlib.md5) were rejected
resulting in the various python scripts bailing out with a stack trace. As
someone pointed out already, MD5 is considered weak, and does not meet the
FIPS list of secure crypto. I understand some projects might well use MD5
for non security related functions, but when it comes to government
compliance and running OpenStack on public clouds (and even private for the
Telcos / NFV), not meeting FIPS will in some cases block production getting
a green light, or at least make it a big challenge to push through.

With this in mind, perhaps all projects should seriously consider migrating
to more up to date methods such as sha256 or bcrypt, and start to
depreciate MD5 use.

I proposed raising bugs on launchpad for each instance discovered, so that
if anything, we at least have an idea of the extent of work needed to reach
the needed level of compliance for FIPS 140-2.

Thoughts welcome?

Luke

On Wed, Nov 9, 2016 at 1:56 PM, Ian Cordasco  wrote:

> Apparently Paul's email didn't make it through, so I'm forwarding it
> to y'all since it pertinent information.
>
> -Original Message-
> From: Paul Kehrer 
> Reply: Paul Kehrer 
> Date: November 8, 2016 at 23:39:32
> To: Ian Cordasco , OpenStack Development
> Mailing List (not for usage questions)
> 
> Subject:  Re: [openstack-dev] [requirements][kolla][security] pycrypto
> vs cryptography
>
> > Cryptography will build just fine against a FIPS OpenSSL (1.0.0 or
> newer, although we’re
> > in the process of dropping < 1.0.1 support in the next several months).
> It is a supported
> > configuration, but enabling FIPS mode (if it’s not on by default) is not
> something cryptography
> > currently exposes (FIPS_mode_set). Rob and Ian’s points about the value
> of FIPS are
> > generally in line with my own opinions. In the absence of an audit
> requirement I’d recommend
> > looking for well-vetted and widely used libraries above trying to meet a
> specific compliance
> > regime.
> >
> > -Paul
> >
> > On 11/9/16, 5:11 AM, "Ian Cordasco" wrote:
> >
> > -Original Message-
> > From: Rob C
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >
> > Date: November 7, 2016 at 07:39:57
> > To: OpenStack Development Mailing List (not for usage questions)
> >
> > Subject: Re: [openstack-dev] [requirements][kolla][security] pycrypto
> > vs cryptography
> >
> > > Good question, I know issues around this have arisen before.
> > >
> > > I think the main points have been covered well already, for my part I
> will
> > > always lean toward the better supported or actively developed project.
> >
> > At this point PyCrypto actively tells users that it's not supported or
> > developed. They've been pushing people towards Cryptogrpahy.
> >
> > > I understand the desire to look for FIPS 140-2 compliance, however I'd
> > > caution about this being the only deciding factor, it makes software
> > > development messy as only specific implementations can be validated.
> If you
> > > want to update code to make improvements etc you can need a whole
> > > re-validation. I'm not saying that FIPS 140-2 doesn't have value but I
> know
> > > of software projects that have used known-bad implementations that had
> > > certification rather use an updated version with no issues - (like I
> said,
> > > it gets messy).
> > >
> > > The OpenSSL guys wrote a good article on FIPS validation, how they
> tackled
> > > it and some of the impact etc [1]
> > >
> > > -Rob
> > >
> > > [1] https://www.openssl.org/docs/fipsnotes.html
> >
> > I would strongly suggest you read Rob's link. It's very enlightening
> > to know why, while FIPS may be a requirement, it's not necessarily
> > beneficial from a security standpoint. It's also ridiculously
> > expensive and restrictive.
> >
> > I've CC'd one of the lead developers from the Cryptography project to
> > comment on this. I would hazard a guess that one could compile
> > Cryptography against a version of OpenSSL that is FIPS compliant, but
> > I doubt it'll be considered supported. I know Cryptography recently
> > dropped support for a few older versions of OpenSSL, and to work with
> > that you'd have to stick to an older version of Cryptography.
> >
> > Can I ask why FIPS compliance is a requirement for Kolla? This seems
> > like an odd request for a deployment project.
> >
> > > On Sun, Nov 6, 2016 at 4:44 PM, Jeremy Stanley wrote:
> > >
> > > > On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> > > > > On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
> > > > [...]
> > > > > > An orthogonal question I have 

[openstack-dev] [magnum] Managing cluster drivers as individual distro packages

[Spyros Trigazis]

Hi all,

In magnum, we implement cluster drivers for the different combinations
of COEs (Container Orchestration Engines) and Operating Systems. The
reasoning behind it is to better encapsulate driver-specific logic and to
allow
operators deploy custom drivers with their deployment specific changes.

For example, operators might want to:
* have only custom drivers and not install the upstream ones at all
* offer user only some of the available drivers
* create different combinations of  COE + os_distro
* create new experimental/staging drivers

It would be reasonable to manage magnum's cluster drivers as different
packages, since they are designed to be treated as individual entities. To
do
so, we have two options:

1. in-tree:  remove the entrypoints from magnum/setup.cfg to not install
them
by default. This will require some plumbing to manage them like separate
python
packages, but allows magnum's development team to manage the official
drivers
inside the service repo.

2. separate repo: This option sounds cleaner, but requires more refactoring
and
will separate more the drivers from service, having significant impact in
the
development process.

Thoughts?

Spyros
__
OpenStack Development Mailing 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] custom rules - security groups

[Iago Santos Pardo]

Actually for our case we want to manage it in a different way.

From: Ihar Hrachyshka [ihrac...@redhat.com]
Sent: 18 November 2016 14:41
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]

> On 18 Nov 2016, at 13:58, Iago Santos Pardo  wrote:
>
> Hello,
>
> We are using Neutron with the linuxbridge plugin and security groups enabled 
> and we have some custom rules in iptables running on the compute nodes. When 
> the agent rebuilds the firewall it changes the rules order, putting the 
> neutron chains on the top. Is there any way to preserve the rules order and 
> tell neutron to ignore our rules or stuck them on the top?

Can’t you express the needed behaviour with security groups API itself?

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] [all] [Rally] broken jobs

[gordon chung]

this seems related to fact we use datetime type in mysql which requires 
5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the 
required mysql.

On 18/11/16 07:50 AM, Andrey Kurilin wrote:
> Hi stackers,
>
> I hate to report such things, but most of rally jobs are broken now due
> to uncompatibility aodh service with ubuntu-trusty nodes.
>
> If you find failed rally jobs with
> http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
> not help.
>
> I'm working on two changes now for Rally jobs which should unblock and
> fix gates:
> - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time ago.
> - Disable telemetry services in those jobs which do not need them.
>
>
> --
> Best regards,
> Andrey Kurilin.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
gord

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

Re: [openstack-dev] [Neutron] Stepping down from core

[Neil Jerram]

On Thu, Nov 17, 2016 at 6:44 PM Carl Baldwin  wrote:

> Neutron (and Openstack),
>
> It is with regret that I report that my work situation has changed such
> that I'm not able to keep up with my duties as a Neutron core reviewer, L3
> lieutenant, and drivers team member. My participation has dropped off
> considerably since Newton was released and I think it is fair to step down
> and leave an opening for others to fill. There is no shortage of talent in
> Neutron and Openstack and I know I'm leaving it in good hands.
>

That is sad news; I've really enjoyed working with you.  But best wishes
for whatever is next!

 Neil
__
OpenStack Development Mailing 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]

[Ihar Hrachyshka]

> On 18 Nov 2016, at 13:58, Iago Santos Pardo  wrote:
> 
> Hello, 
> 
> We are using Neutron with the linuxbridge plugin and security groups enabled 
> and we have some custom rules in iptables running on the compute nodes. When 
> the agent rebuilds the firewall it changes the rules order, putting the 
> neutron chains on the top. Is there any way to preserve the rules order and 
> tell neutron to ignore our rules or stuck them on the top?

Can’t you express the needed behaviour with security groups API itself?

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] [neutron]

[ZZelle]

Hello,

AFAIK, it's not possible.

I did a similar thing by extending neutron iptables driver in order to set
"pre-rules".

Best regards,


Cédric/ZZelle

On Fri, Nov 18, 2016 at 1:58 PM, Iago Santos Pardo <
iago.santos.pa...@cern.ch> wrote:

> Hello,
>
> We are using Neutron with the linuxbridge plugin and security groups
> enabled and we have some custom rules in iptables running on the compute
> nodes. When the agent rebuilds the firewall it changes the rules order,
> putting the neutron chains on the top. Is there any way to preserve the
> rules order and tell neutron to ignore our rules or stuck them on the top?
>
> Thank you so much.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron]

[Iago Santos Pardo]

Hello, 

We are using Neutron with the linuxbridge plugin and security groups enabled 
and we have some custom rules in iptables running on the compute nodes. When 
the agent rebuilds the firewall it changes the rules order, putting the neutron 
chains on the top. Is there any way to preserve the rules order and tell 
neutron to ignore our rules or stuck them on the top?

Thank you so much.
__
OpenStack Development Mailing 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] [git-upstream] [Additional Branches] How to view only commits applied since last import

[Darragh Bailey - mailing lists]

On 17/11/16 12:47, Paul Bourke wrote:
> Hi Darragh / git-upstream community,



 My current understanding is we have a branch, that consists of a mixture
> of upstream commits from previous imports, and custom commits. We want
> to show a list of commits added since the last import. However, if those
> commits also contain commits from another non upstream branch, we want
> to exclude those? This makes sense with the example of say a packaging
> branch, but what if commits came from say a feature branch? Does it also
> make sense to ignore those?

Probably worth explaining additional branches a bit more in the docs
(where did I say that before?)

For any feature branch that is contributing to the tree and touching the
same files as the upstream project, definitely they should be included,
and git will do so by default.

The packaging branch item stems from when we were carrying packaging
related files that would never go upstream, and were actually from a
completely separate history with it's own root, and own upstream as we
did have some previously tracking ubuntu packaging repos to pull in the
packaging files from there.

However I think can regard the additional branches as just being an edge
case that if they get excluded from the listed output, it's not the
worst case.

If it makes sense down the road to include them, or just ensure
something is included about them, hopefully I'll have had a chat with
some more git experts and might know how to do so.


A quick off the top of my head guess.

Given the graph mentioned in the other email:

   A
  / \
-M---X---N---O  local/mitaka
/   /
   /   X'---(rebase/cherry-pick of X onto G)
  /   /
-E---F---G  upstream stable/mitaka branch


Adding '--not M..N^1' might do the right thing in only excluding a range
rather than everything behind it, though would need to check with a
scenario that if another commit existed between X and N, that this
wouldn't accidentally exclude A as well.


> Thanks in advance for anything that might help cut through some of the
> confusion.
> 
> Cheers,
> -Paul


In any case, I think don't worry about the additional branches for now,
just let them be excluded, as they way they are merged in only works if
they are unrelated history. Since any feature branches wouldn't be
merged in this way, they would get included the same way any other
commit that is merged to the tree currently does, just that there will
be more of them listed.

--
Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown



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] [OpenStack-docs] [OpenStack-operators] [docs][upgrades] time to add official docs for upgrading services?

[Steve Martinelli]

On Thu, Nov 17, 2016 at 11:04 PM, darren chan 
wrote:

> Good timing, I was about to send a follow-up email about this spec.
>
> I agree, this content needs to be more visible, which is why the spec
> proposed to move upgrade notes to the Upgrades chapter in the Operations
> Guide. However, it seems like the general consensus is to keep content in
> project repos because it is more likely to be maintained there.
>
> Considering the Ocata development cycle is pretty short, we've already
> established our docs deliverables, and other projects are still developing
> upgrade notes, would links to the upgrade notes in the Ops Guide suffice in
> the interim? We can then propose and plan a better solution for Pike, such
> as in-tree official guides?
>
> Thoughts?
>
>
The project teams will always use the maintenance argument. But I
understand your concern, and in my initial draft to the mailing list i was
going to voice a similar statement. Maybe wait until teams have fleshed out
their various supported upgrade strategies?



> Darren
>
>
> On Friday, 18 November 2016, 13:33, Lana Brindley <
> openst...@lanabrindley.com> wrote:
>
>
> Isn't that more or less what this is?
>
> https://review.openstack.org/#/c/394261/
>
>
Yup! Thanks for reading my mind docs team :)
__
OpenStack Development Mailing 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] [Rally] broken jobs

[Andrey Kurilin]

Hi stackers,

I hate to report such things, but most of rally jobs are broken now due to
uncompatibility aodh service with ubuntu-trusty nodes.

If you find failed rally jobs with http://paste.openstack.org/show/589707/
in devstacklogs, recheck will not help.

I'm working on two changes now for Rally jobs which should unblock and fix
gates:
- Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time ago.
- Disable telemetry services in those jobs which do not need them.


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] [git-upstream] How to view only commits applied since last import

[Darragh Bailey - mailing lists]

Hi Paul


This might be a bit long, noticed a few more items to be added to the
documentation for git-upstream. Good thing documentation is the major
item for the next release ;-)

After an initial attempt at writing one response, I've decided to break
it up a bit into a couple of emails, because there a few topics in here
and one of them is pretty lengthy and the others follow somewhat
independent issues.

For this one I'll stick to just the 2nd and 4th paragraphs since they
are related.

And apologies in advance for anyone that didn't need to see such a dive
into git log behaviour here. :-)


On 17/11/16 12:47, Paul Bourke wrote:
> Hi Darragh / git-upstream community,
> 
> I've been looking at a way to easily view a log of what commits made
> since the last upstream import when managing a branch with git-upstream.
> Right now this can be hard to do - something like 'git log
> upstream/master..HEAD' shows a lot of duplicate commits reasons I don't
> understand well enough to explain.


I'll go into that in a little more detail with a separate response, to
help anyone else reading or in the future searching. Definitely should
have been documented before now... O_o


> Darragh had suggested using the --dense option will help here, so 'git
> log --dense upstream/master..HEAD -- .' seems to generally give the
> right result. I've put up a patch to add this as a git-upstream command
> in the form of "carrying" at https://review.openstack.org/#/c/381669/.
> However, it seems there are in fact cases where the above command will
> show incorrect commits, and I'm struggling a bit to fully grok this.

Unfortunately explanation is going to be a bit lengthy, and there are
pieces of git here I'm not fully sure I understand what it's doing, and
plan to ask the git-users google group for a bit more info. Possibly may
require going to the git mailing list to get a complete picture
(g...@vger.kernel.org).


Until recently, I didn't fully grok the git-log(1) manpage,
https://www.kernel.org/pub/software/scm/git/docs/git-log.html,
specifically the section about "History Simplification", naturally I
didn't realise that until I understood what it was saying better.

Mainly to do with how TREESAME and !TREESAME apply to simplifying the
history walked and displayed.


TREESAME means that the resulting git tree is identical and you can have
multiple commits referencing the same TREE SHA1 in git. It's one of the
ways it avoids duplicating the same information, identical directories
result in the same SHA1, so each commit to a git tree only adds blobs
(for files) and tree (for directory) objects for what is different.
!TREESAME basically means there was something different between the two
directories or trees in the repo, and as git allows for path limiting,
this can be applied to any subdirectory in a git repository as well.


In the review I was referencing a particular scenario that we've come
across locally (see the url above):

1) Dev uploads a patch 'A' for review against branch tracking latest
from stable/mitaka (presumably also sent it upstream)
2) Nightly sync jobs run and bring down all the patches that landed in
the stable branch upstream over the last 24 hours
2.1) Git upstream is able to replay the current local changes without
conflict, dropping those that landed upstream automatically
2.2) Git-upstream merges the result into the tracking branch, and it now
becomes the new head (assuming it passes a gate check locally)
3) Following day or so, reviewer approves patch 'A' to land and it
merges without conflict.

See following for the actual test scenario, it's a bit more complex than
what I've discribed and the letters used differ:

https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/tests/searchers/scenarios/changes_upload_prior_to_import.yaml


If git-upstream didn't do a special type of merge, and just produced a
new branch each time, we'd have to re-target patch 'A' to the new
branch, alternatively we could also have triggered a rebase of any
outstanding changes to avoid the particular git graph this produces.
Both of these seemed like unnecessary confusion and make-work for
developers/reviewers just trying to focus on landing changes.


The result is a git graph like the following (hope this displays correctly):

   A
  / \
-M---X---N---O  local/mitaka
/   /
   /   X'---(rebase/cherry-pick of X onto G)
  /   /
-E---F---G  upstream stable/mitaka branch


M = the merge commit created by git-upstream for the previous sync
X = local change not yet upsteam
X' = replay of the local change X onto the latest stable/mitaka
N = most recent merge commit created by git-upstream
A is the commit created locally by a developer to fix a issue affecting
local deployments (and may need to be reworked for upstream)
O = merge commit created in Gerrit by approval of 'A'

When git-upstream created N, it made 

Re: [openstack-dev] [All] Finish test job transition to Ubuntu Xenial

[Jakub Libosvar]

On 18/11/2016 12:17, Jakub Libosvar wrote:

On 07/11/2016 23:04, Clark Boylan wrote:

On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:

How can you do this? First double check your job logs to see where your
tests are running. The first few lines of your job console logs should
say "[Zuul] Building remotely on ubuntu-xenial" if running on Xenial.
Any changes to master should not run on Trusty and instead should run on
Xenial.


Point of clarification here, stable/newton and master jobs should both
be transitioned to Xenial.


I noticed gate-grenade-dsvm-ubuntu-xenial job is run on stable Newton
branch for devstack. It basically means Mitaka devstack is used to
deploy on Xenial but Xenial is not among supported distros in Mitaka [1].

What is recommended way of upgrade for Ubuntu users running Mitaka on
Trusy? Is it: upgrade Ubuntu to Xenial first, then upgrade Mitaka to
Newton?

I see three ways how to solve this problem:
1) Implement support to devstack Mitaka.
2) Use FORCE value for grenade Newton (I sent experimental patch [2]).
3) Run Trusty only for upgrades Mitaka->Newton.

Any thoughts or comments?
I see it was resolved by 
https://bugs.launchpad.net/openstack-gate/+bug/1642543

Sorry for the noise.



Thanks,
Jakub

[1]
https://github.com/openstack-dev/devstack/blob/stable/mitaka/stack.sh#L188
[2] https://review.openstack.org/#/c/399526/



Clark


__

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




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



__
OpenStack Development Mailing 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] Usefulness of Weekly Meeting

[Ihar Hrachyshka]

> On 16 Nov 2016, at 15:12, Matt Riedemann  wrote:
> 
> On 11/16/2016 7:53 AM, Ian Cordasco wrote:
>> 
>> 
>> -Original Message-
>> From: Ian Cordasco 
>> Reply: Ian Cordasco 
>> Date: November 16, 2016 at 07:06:27
>> To: OpenStack Development Mailing List (not for usage questions) 
>> 
>> Subject:  Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting
>>> -Original Message-
>>> From: Tony Breeds
>>> Reply: OpenStack Development Mailing List (not for usage questions) ,
>>> OpenStack Development Mailing List (not for usage questions)
>>> Date: November 15, 2016 at 16:55:36
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting
>>> 
 On Tue, Nov 15, 2016 at 10:25:26AM -0800, Ian Cordasco wrote:
> Hi all,
> 
> So the stable-maintenance team (and liaisons to it) have had a meeting
> scheduled for a while now. Recently, however, we've had trouble
> getting more than one person to attend meetings when we have them.
 
 I need to apologise for letting this happen.
>>> 
>>> I'd like to emphasize that I don't see this as any one person's fault. I 
>>> just was thinking
>>> aloud about whether or not we find much use. We're not exactly a high 
>>> activity team and
>>> we do communicate very well via this very medium.
>>> 
 The current arrangement with 2
 meetings US/EU and US/AU means that I can only attend the US/AU timeslot, 
 and I
 failed to set someone to run the US/EU meeting. I'd like to propose that we
 switch the arrantment to:
 
 US/AU: #openstack-meeting-4 2100 UTC Monday (same time as now different 
 room)
 AU/EU: #openstack-meeting-4 1000 UTC Monday
>>> 
>>> This sounds fine to me. It might even be less confusing than having two 
>>> separate days and
>>> channels too.
>>> 
 Alternate weeks, although we *could* run both meetings on the same day 
 every
 2nd week if people wanted.
 
> I wonder if it would be more useful to less frequent meetings (perhaps
> every other week) and if we need to reschedule them to better serve
> those who plan to attend.
 
 As always it's a question of less often is harder to form a habit. I'd 
 like to
 request we try the new schedule until the PTG and then re-evaluate.
>>> 
>>> That sounds fine with me. I just wanted to gather some other feedback. :)
>> 
>> I submitted https://review.openstack.org/398363 so that folks can see how 
>> this translates to their calendar using the generated ics files.
>> 
>> Cheers!
>> --
>> Ian Cordasco
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> FWIW I'm fine with doing fewer meetings or just shifting the meetings to a 
> time that is more accommodating for Tony. As noted, we do a pretty good job 
> already of communicating via the mailing list when we need to. The stable 
> team meetings have never been well attended even when I was running them 
> regularly.

+1. I also don’t feel like there is a lot of daily work for the team that would 
require weekly sync in IRC. We use mailing lists effectively enough. We are no 
longer broken on a daily basis because of all the safety measures applied. I 
feel like an email or async irc discussion with others is good enough for my 
level of involvement.

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

[openstack-dev] [nova] placement/resource providers update 2

[Chris Dent]

Last week I made an update[0] on the state of things in the resource
provider/placement API universe. That seemed pretty useful, so here's
another one. Even though most people were productively involved in
reviewing specs before yesterday's deadline, some placement related
specs and code merged, and there was good review progress on pending
changes.

Below I give a summary of how things changed since last week and what
still remains. I've left out some of the descriptive text in some
sections where it would have been duplciated from last week. See last
week[0] for more info.

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107171.html

# Stuff What Merged

\o/

* Improved 404 responses (1 of 2):
   https://review.openstack.org/#/c/387674/

* Proper handling of max_unit in resource tracker and placement API
  (2 of 2):
   https://review.openstack.org/#/c/395971/

* First bit of aggregates (1 of 3):
   https://review.openstack.org/#/c/362863/

* Cleaning up the newton resource providers spec to reflect reality:
   https://review.openstack.org/#/c/366888/

* Spec of the HTTP API on narrowing list of resource providers
   https://review.openstack.org/#/c/385618/

* Initial docs for placement service:
   https://review.openstack.org/#/c/396761/

# Leftovers from Newton

Things that need reaction to reviews:

* Improved 404 responses (1 merged, 1 pending):
   https://review.openstack.org/#/c/392321/

Things that are ready to review:

* Increased gabbi test coverage (stack of 3):
   https://review.openstack.org/#/c/396363/

* Aggregates support in placement api (stack of 2):
   https://review.openstack.org/#/c/355263/
   Review of this stack identified a race condition which has been
   fixed but now we're not sure how/if to test it.

* Demo inventory update script:
   https://review.openstack.org/#/c/382613/
   This one might be considered a WIP because how it chooses to do
   things (rather simply and dumbly) may not be in line with expecations.

* CORS support in placement API:
   https://review.openstack.org/#/c/392891/

There are still quite a few things to pick up on the leftovers
etherpad[1]. It may be time to filter the etherpad for relevance.

[1] https://etherpad.openstack.org/p/placement-newton-leftovers

# Filtering compute nodes with the placement API

One spec related to this (see above) has merged, with caveats that
the details of the API are subject to change during implementation.

* Spec for modifying the scheduler to query the api:
   https://review.openstack.org/#/c/300178/

* Code that satisfies those two specs (stack of 2):
   https://review.openstack.org/#/c/386242/

# Custom Resource Classes

The code for this proceeds apace. Since placement is a priority,
the specs related to this and nested resource providers are
still in play.

* The spec
   https://review.openstack.org/#/c/312696/

* Code to make them work in the api (stack of 5):
   https://review.openstack.org/#/c/386844/

# Nested Resource Providers

* The spec
   https://review.openstack.org/#/c/386710/

* Code to implement the object and HTTP API changes (stack of 4):
   https://review.openstack.org/#/c/377138/

# Allocations for generic PCI devices

* Code (stack of 3):
   https://review.openstack.org/#/c/396963/

# Important stuff not in other categories

This section is for lose ends that don't fit in elsewhere. Stuff
we're going to need to figure out at some point.

## Placement DB

No new discussion or progress on this. The etherpad[2] and related
code changes[3] remain the same. The todo here is to resolve the
questions on the etherpad and make an explicit plan.

[2] https://etherpad.openstack.org/p/placement-optional-db-spec
[3] https://review.openstack.org/#/c/362766/ (this is -2d pending
resolution of the stuff on the etherpad)

## Placement Docs

Matt R made a great start[4] to this setting the foundation for
the rest of us to build on. The major portion left as a TODO is
docs of the API. Because, for the time being, the API is relatively
simple, it has been decided that creating the docs by hand is okay.

So the todo here is: get started on the api-ref docs.

[4] https://review.openstack.org/#/c/396761/ which resulted in
http://docs.openstack.org/developer/nova/placement.html

## Placement Upgrade/Installation issues

In his response[5] to this message Matt R pointed out todos for this
topic:

* get the placement-api enabled by default in the various bits of
  ocata CI 
* ensure that microversions are being used on both sides of the

  placement API transactions (that's true in pending changes to
  both the API and the resource tracker)

[5] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107177.html

# End

Thanks for reading. If you think this is useful or could be more useful
please let me know.

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: 

Re: [openstack-dev] [kolla] Obtaining version information for Docker container

[Paul Bourke]

If I'm understanding the requirement correctly, we want to know which 
version of an OpenStack component is installed in an image? If so why 
not just run something like:


# docker run kolla/oraclelinux-source-keystone:3.0.0 pip show keystone
Name: keystone
Version: 10.0.0.0rc2.dev290
[...]

Or equivalent for yum/apt. I'm not sure there's a need to implement 
anything beyond what is offered by package management tools.


On 18/11/16 11:51, Steven Dake (stdake) wrote:

Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider
audience.  I don’t have a clear solution to obtaining version manifests
for container content or the upstream container version.  Perhaps
someone in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be
run with docker exec to obtain a proper version manifest of both 1 and 2
(formatted in YAML or plaintext).  This could be placed in the base
container image to enable a general diagnostic and certificate of origin
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn "
>
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake >
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a
running container or image.
you know , the version info is wrapped by the container, it is not easy
to get them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by calling docker exec...
but how to get the one, Is there any way, 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



__
OpenStack Development Mailing 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][git]How to backport commit after repo split

[Steven Dake (stdake)]

You mean contributing doc?  Sounds like a winner to me.  I am really concerned 
about how to sort out back ports as it relates to the repository split, and 
documenting a best practice here makes a lot of sense (once we figure out what 
that simple best practice is - which I think is covered in this thread).

Regards
-steve




On 11/17/16, 8:19 PM, "Jeffrey Zhang"  wrote:

>Yes. it works. Maybe we should add this into develop doc.
>
>thanks Paul.
>
>On Thu, Nov 17, 2016 at 11:00 PM, Paul Bourke  wrote:
>> Seen as both repos stem from the same codebase, we should be able to just
>> cherry-pick changes as usual. If a fix comprises of a change to both kolla
>> and kolla-ansible, it will just mean two cherry-picks. Will need to wait
>> till the relevant pieces are removed from both repos to confirm this but I
>> think it will work.
>>
>> Here's an example using a recent change that just merged into kolla-ansible:
>>
>> git clone https://github.com/openstack/kolla
>> cd kolla
>> git remote add kolla-ansible https://github.com/openstack/kolla-ansible
>> git fetch kolla-ansible
>> git checkout stable/newton
>> git cherry-pick -x 43517f48f5ab2b9d8fb22dc2a619b8d9f4f494d0
>>
>> -Paul
>>
>>
>> On 17/11/16 14:02, Jeffrey Zhang wrote:
>>>
>>> We have split kolla repo into two repos. the dockerfile related code
>>> remains in kolla repo which builds images. and the ansible playbook
>>> related code is moved into kolla-ansible which deploy the images.
>>>
>>> But it brings a new challenge. How to backport the kolla-ansible
>>> change to kolla in stable branch? i.e. cross-repository backport.
>>>
>>> Does any guy have a solution for this case?
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>
>
>-- 
>Regards,
>Jeffrey Zhang
>Blog: http://xcodest.me
>
>__
>OpenStack Development Mailing 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] [kolla] Obtaining version information for Docker container

[Steven Dake (stdake)]

Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider 
audience.  I don’t have a clear solution to obtaining version manifests for 
container content or the upstream container version.  Perhaps someone in our 
broader community may have an answer.

The best I’ve got is we could add a general shell command that can be run with 
docker exec to obtain a proper version manifest of both 1 and 2 (formatted in 
YAML or plaintext).  This could be placed in the base container image to enable 
a general diagnostic and certificate of origin tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn" 
>
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake >
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a running 
container or image.
you know , the version info is wrapped by the container, it is not easy to get 
them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by calling docker exec...
but how to get the one, Is there any way, 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] [All] Finish test job transition to Ubuntu Xenial

[Jakub Libosvar]

On 07/11/2016 23:04, Clark Boylan wrote:

On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:

How can you do this? First double check your job logs to see where your
tests are running. The first few lines of your job console logs should
say "[Zuul] Building remotely on ubuntu-xenial" if running on Xenial.
Any changes to master should not run on Trusty and instead should run on
Xenial.


Point of clarification here, stable/newton and master jobs should both
be transitioned to Xenial.


I noticed gate-grenade-dsvm-ubuntu-xenial job is run on stable Newton 
branch for devstack. It basically means Mitaka devstack is used to 
deploy on Xenial but Xenial is not among supported distros in Mitaka [1].


What is recommended way of upgrade for Ubuntu users running Mitaka on 
Trusy? Is it: upgrade Ubuntu to Xenial first, then upgrade Mitaka to Newton?


I see three ways how to solve this problem:
1) Implement support to devstack Mitaka.
2) Use FORCE value for grenade Newton (I sent experimental patch [2]).
3) Run Trusty only for upgrades Mitaka->Newton.

Any thoughts or comments?

Thanks,
Jakub

[1] 
https://github.com/openstack-dev/devstack/blob/stable/mitaka/stack.sh#L188

[2] https://review.openstack.org/#/c/399526/



Clark


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




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

Re: [openstack-dev] [neutron] rally failure in the gate

[Andrey Kurilin]

Hi stackers!

Imo, there is a better solution - just turn off telemetry services[*] :)
Neutron jobs do not runs any ceilometer scenarios, so enabling all
telemetry services looks redundant and takes some time while preparing
environment (installing devstack).


[*] - https://review.openstack.org/#/c/399212

On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka 
wrote:

>
> > On 17 Nov 2016, at 20:32, Armando M.  wrote:
> >
> > Hi folks,
> >
> > Please do not recheck rally failures.
> >
> > There was a breaking change introduced by aodh [0] that prevented rally
> to work on trusty. We are switching to xenial as we speak anyway [1], so
> the glitch should be short lived.
>
> To give an update, the switch to Xenial occurred, and I see jobs passing
> just fine 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
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] rally failure in the gate

[Ihar Hrachyshka]

> On 17 Nov 2016, at 20:32, Armando M.  wrote:
> 
> Hi folks,
> 
> Please do not recheck rally failures.
> 
> There was a breaking change introduced by aodh [0] that prevented rally to 
> work on trusty. We are switching to xenial as we speak anyway [1], so the 
> glitch should be short lived.

To give an update, the switch to Xenial occurred, and I see jobs passing just 
fine 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] [Neutron] Stepping down from core

[Ihar Hrachyshka]

> On 17 Nov 2016, at 19:42, Carl Baldwin  wrote:
> 
> Neutron (and Openstack),
> 
> It is with regret that I report that my work situation has changed such that 
> I'm not able to keep up with my duties as a Neutron core reviewer, L3 
> lieutenant, and drivers team member. My participation has dropped off 
> considerably since Newton was released and I think it is fair to step down 
> and leave an opening for others to fill. There is no shortage of talent in 
> Neutron and Openstack and I know I'm leaving it in good hands.
> 
> I will be more than happy to come back to full participation in Openstack and 
> Neutron in the future if things change again in that direction. This is a 
> great community and I've had a great time participating and learning with you 
> all.
> 
> Well, I don't want to drag this out. I will still be around on IRC and will 
> be happy to help out where I am able. Feel free to ping me.

It’s sad to see you step down Carl. You are aways welcome back whenever your 
work situation changes.

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] [api]

[milanisko k]

No prob!
Just needed a hint preferably before we'd merge the new API endpoint spec
for the inspector [1]
Cheers,
milan

[1]
https://review.openstack.org/#/c/375045/10/specs/list-introspection-statuses.rst

pá 18. 11. 2016 v 11:26 odesílatel Chris Dent 
napsal:

> On Fri, 18 Nov 2016, milanisko k wrote:
>
> > Sorry Ed,
> > was a bank holiday in here yesterday.
> > Did the API WG conclude on a preferred operator name?
>
> After bouncing it around a few times 'nin' seemed to fit better and
> Ed proposed a guideline:
>
>  https://review.openstack.org/#/c/399131/
>
> Thanks _very_ much for getting this started.
>
> --
> Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
> freenode: cdent tw:
> @anticdent__
> OpenStack Development Mailing 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] Stepping down from core

[Hirofumi Ichihara]

Hi Carl,

Your great work always helped Neutron community.
Thank you so much for all your help.

Hirofumi

On 2016/11/18 3:42, Carl Baldwin wrote:

Neutron (and Openstack),

It is with regret that I report that my work situation has changed 
such that I'm not able to keep up with my duties as a Neutron core 
reviewer, L3 lieutenant, and drivers team member. My participation has 
dropped off considerably since Newton was released and I think it is 
fair to step down and leave an opening for others to fill. There is no 
shortage of talent in Neutron and Openstack and I know I'm leaving it 
in good hands.


I will be more than happy to come back to full participation in 
Openstack and Neutron in the future if things change again in that 
direction. This is a great community and I've had a great time 
participating and learning with you all.


Well, I don't want to drag this out. I will still be around on IRC and 
will be happy to help out where I am able. Feel free to ping me.


Carl


__
OpenStack Development Mailing 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]

[Chris Dent]

On Fri, 18 Nov 2016, milanisko k wrote:


Sorry Ed,
was a bank holiday in here yesterday.
Did the API WG conclude on a preferred operator name?


After bouncing it around a few times 'nin' seemed to fit better and
Ed proposed a guideline:

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

Thanks _very_ much for getting this started.

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] Stepping down from core

[Martin Hickey]

Hi Carl,

It was a pleasure working with you. All the best in your new venture.

Regards,
Martin




From:   Carl Baldwin 
To: OpenStack Development Mailing List

Date:   17/11/2016 18:43
Subject:[openstack-dev] [Neutron] Stepping down from core



Neutron (and Openstack),

It is with regret that I report that my work situation has changed such
that I'm not able to keep up with my duties as a Neutron core reviewer, L3
lieutenant, and drivers team member. My participation has dropped off
considerably since Newton was released and I think it is fair to step down
and leave an opening for others to fill. There is no shortage of talent in
Neutron and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack
and Neutron in the future if things change again in that direction. This is
a great community and I've had a great time participating and learning with
you all.

Well, I don't want to drag this out. I will still be around on IRC and will
be happy to help out where I am able. Feel free to ping me.

Carl
__
OpenStack Development Mailing 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] Stepping down from core

[Miguel Angel Ajo Pelayo]

Sad to see you go Carl,

   Thanks for so many years of hard work, as Brian said, OpenStack /
Neutron is better thanks to your contributions through the last years.

My best wishes for you.


On Fri, Nov 18, 2016 at 9:51 AM, Vikram Choudhary  wrote:

> It was really a good experience working with you Carl. Best of luck for
> your future endeavour!
>
> Thanks
> Vikram
>
> On Fri, Nov 18, 2016 at 12:38 PM, Trinath Somanchi <
> trinath.soman...@nxp.com> wrote:
>
>> Carl -
>>
>>
>>
>> You are an asset to Neutron community. Missing you as core is a hard
>> thing.
>>
>>
>>
>> I wish a grand U turn again at your work towards Neutron.
>>
>>
>>
>> Wishing you all the best.
>>
>>
>>
>> /Trinath
>>
>>
>>
>> *From:* Carl Baldwin [mailto:c...@ecbaldwin.net]
>> *Sent:* Friday, November 18, 2016 12:13 AM
>> *To:* OpenStack Development Mailing List > .org>
>> *Subject:* [openstack-dev] [Neutron] Stepping down from core
>>
>>
>>
>> Neutron (and Openstack),
>>
>>
>>
>> It is with regret that I report that my work situation has changed such
>> that I'm not able to keep up with my duties as a Neutron core reviewer, L3
>> lieutenant, and drivers team member. My participation has dropped off
>> considerably since Newton was released and I think it is fair to step down
>> and leave an opening for others to fill. There is no shortage of talent in
>> Neutron and Openstack and I know I'm leaving it in good hands.
>>
>>
>>
>> I will be more than happy to come back to full participation in Openstack
>> and Neutron in the future if things change again in that direction. This is
>> a great community and I've had a great time participating and learning with
>> you all.
>>
>>
>>
>> Well, I don't want to drag this out. I will still be around on IRC and
>> will be happy to help out where I am able. Feel free to ping me.
>>
>>
>>
>> Carl
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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]

[milanisko k]

Sorry Ed,
was a bank holiday in here yesterday.
Did the API WG conclude on a preferred operator name?

Cheers,
milan

st 16. 11. 2016 v 15:43 odesílatel Ed Leafe  napsal:

On Nov 16, 2016, at 7:42 AM, Ian Cordasco  wrote:

> If you're including me as a vote for nin, you should also consider me as
a vote for not_in. Otherwise, count me as half a vote for either. I still
think not_in is just ever-so slightly better than nin.

It is on the agenda for the API working group’s meeting tomorrow (Thursday)
at 1600 UTC in #openstack-meeting-3
(http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161117T16)

Please join the meeting tomorrow if you are able!

-- Ed Leafe






__
OpenStack Development Mailing 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] [architecture] Reminder: Arch-WG Meeting today, and -- repo

[Zhipeng Huang]

i attended the Asia friendly meeting several times but found no one was on
it, is the EU one also Asia friendly ?

On Fri, Nov 18, 2016 at 4:57 PM, Thierry Carrez 
wrote:

> Clint Byrum wrote:
> > Just a friendly reminder that we have a meeting today at 19:00 UTC.
> > Please come join us and add anything you'd like to talk about to the
> > Agenda:
> >
> > https://wiki.openstack.org/wiki/Meetings/Arch-WG
> >
> > On another note, we have a repository now to facilitate our processes:
> >
> > https://review.openstack.org/#/q/project:openstack/arch-wg
> >
> > I've added two cores beside myself, Thierry and Dean, as they've been
> > the most active thus far. If anyone else would like to help review
> > things, just please raise your hand at the meeting and we'll talk about
> > it.
> >
> > We'll be filling the repo with a structure and some docs for
> participation
> > soon. In the mean time, come to our meeting and submit things you'd like
> > to work with us on to improve the architecture of OpenStack.
>
> Note that we proposed to move the EU-time meeting one hour later to
> avoid conflicting with dinner time in Europe and encourage more
> participation. Feel free to chime in on:
>
> https://review.openstack.org/#/c/399206/
>
> --
> 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
>



-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [architecture] Reminder: Arch-WG Meeting today, and -- repo

[Thierry Carrez]

Clint Byrum wrote:
> Just a friendly reminder that we have a meeting today at 19:00 UTC.
> Please come join us and add anything you'd like to talk about to the
> Agenda:
> 
> https://wiki.openstack.org/wiki/Meetings/Arch-WG
> 
> On another note, we have a repository now to facilitate our processes:
> 
> https://review.openstack.org/#/q/project:openstack/arch-wg
> 
> I've added two cores beside myself, Thierry and Dean, as they've been
> the most active thus far. If anyone else would like to help review
> things, just please raise your hand at the meeting and we'll talk about
> it.
> 
> We'll be filling the repo with a structure and some docs for participation
> soon. In the mean time, come to our meeting and submit things you'd like
> to work with us on to improve the architecture of OpenStack.

Note that we proposed to move the EU-time meeting one hour later to
avoid conflicting with dinner time in Europe and encourage more
participation. Feel free to chime in on:

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

-- 
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] [Neutron] Stepping down from core

[Vikram Choudhary]

It was really a good experience working with you Carl. Best of luck for
your future endeavour!

Thanks
Vikram

On Fri, Nov 18, 2016 at 12:38 PM, Trinath Somanchi  wrote:

> Carl -
>
>
>
> You are an asset to Neutron community. Missing you as core is a hard
> thing.
>
>
>
> I wish a grand U turn again at your work towards Neutron.
>
>
>
> Wishing you all the best.
>
>
>
> /Trinath
>
>
>
> *From:* Carl Baldwin [mailto:c...@ecbaldwin.net]
> *Sent:* Friday, November 18, 2016 12:13 AM
> *To:* OpenStack Development Mailing List  openstack.org>
> *Subject:* [openstack-dev] [Neutron] Stepping down from core
>
>
>
> Neutron (and Openstack),
>
>
>
> It is with regret that I report that my work situation has changed such
> that I'm not able to keep up with my duties as a Neutron core reviewer, L3
> lieutenant, and drivers team member. My participation has dropped off
> considerably since Newton was released and I think it is fair to step down
> and leave an opening for others to fill. There is no shortage of talent in
> Neutron and Openstack and I know I'm leaving it in good hands.
>
>
>
> I will be more than happy to come back to full participation in Openstack
> and Neutron in the future if things change again in that direction. This is
> a great community and I've had a great time participating and learning with
> you all.
>
>
>
> Well, I don't want to drag this out. I will still be around on IRC and
> will be happy to help out where I am able. Feel free to ping me.
>
>
>
> Carl
>
> __
> OpenStack Development Mailing 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] [Horizon] Proposing Kenji Ishii for core

[Timur Sufiev]

+1

On Fri, Nov 18, 2016 at 12:35 AM Thai Q Tran  wrote:

> +1 from me. Kenji is also very active in the plugin space.
>
>
> - Original message -
> From: David Lyle 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc:
> Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core
> Date: Thu, Nov 17, 2016 11:51 AM
>
> +1
>
> On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama
>  wrote:
> > +1
> >
> > 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) :
> >>
> >> Big +1 from me
> >>
> >> > On 14 Nov 2016, at 00:24, Richard Jones 
> wrote:
> >> >
> >> > Hi Horizon core team,
> >> >
> >> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> >> > solid Horizon contributor for some time, with thoughtful and helpful
> >> > reviews showing good judgment and good knowledge of Horizion and
> >> > related systems. Please respond with your votes by Friday.
> >> >
> >> >
> >> > Thanks,
> >> >
> >> >Richard
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][horizon] XStatic-JSEncrypt 2.3.1.1 release

[no-reply]

We are frolicsome to announce the release of:

XStatic-JSEncrypt 2.3.1.1: JSEncrypt 2.3.1 (XStatic packaging
standard)

Download the package from:

https://pypi.python.org/pypi/XStatic-JSEncrypt

For more details, please see below.

Changes in XStatic-JSEncrypt 2.3.1.0..2.3.1.1
-

27ddd97 Update JSEncrypt to 2.3.1.1


Diffstat (except docs and test files)
-

xstatic/pkg/jsencrypt/__init__.py   |2 +-
xstatic/pkg/jsencrypt/data/jsencrypt.js | 3851 +++
2 files changed, 3852 insertions(+), 1 deletion(-)




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