Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi, keystone devs,

Thank you for your many comments about my patch [1].

I modified this patch in reference to your comments.
I want to get many opinions about this new Patch Set.

Could you review it?
[1]: https://review.openstack.org/#/c/261188/

Thank you,

On Tue, 31 May 2016 20:46:36 +0900
koshiya maho  wrote:

> Hi, keystone devs,
> 
> Thank you for your many opinions about request id mapping.
> I fixed this patch [1] by the way that Brant and Cao gave me suggestions [2].
> Could you review it?
> 
> [1] https://review.openstack.org/#/c/261188/
> [2] http://paste.openstack.org/show/495040/
> 
> Thank you,
> 
> On Wed, 20 Apr 2016 16:37:31 -0700
> Morgan Fainberg  wrote:
> 
> > On Wed, Apr 13, 2016 at 6:07 AM, David Stanek  wrote:
> > 
> > > On Wed, Apr 13, 2016 at 3:26 AM koshiya maho 
> > > wrote:
> > >
> > >>
> > >> My request to all keystone cores to give their suggestions about the 
> > >> same.
> > >>
> > >>
> > > I'll test this a little and see if I can see how it breaks.
> > >
> > > Overall I'm not really a fan of this design. It's just a hack to add
> > > attributes where they don't belong. Long term I think this will be hard to
> > > maintain.
> > >
> > >
> > >
> > If we want to return a response object we should return a response object.
> > Returning a magic list with attributes (or a dict with attributes, etc)
> > feels very, very wrong.
> > 
> > I'm not going to block this design, but I wish we had something a bit
> > better.
> > 
> > --Morgan
> 
> --
> Maho Koshiya
> E-Mail : koshiya.m...@po.ntts.co.jp
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



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

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Edward Leafe]

On Jul 13, 2016, at 9:38 PM, Cheng, Yingxin  wrote:

>>Thinking about that a bit, it would seem that a host aggregate could also 
>> be represented as a namespace:name tag. That makes sense, since the fact 
>> that a host belongs to a particular aggregate is a qualitative aspect of 
>> that host.
>> 
> 
> Thanks for the feedback!
> 
> We’ve thought about the relationship between capability tags and host 
> aggregates carefully. And we decide not to blend it with host aggregates, for 
> several reasons below:
> 1. We want to manage capabilities in only ONE place, either in host 
> aggregates, compute_node records or with resource_provider records.
> 2. Compute services may need to attach discovered capabilities to its host. 
> It is inconvenient if we store caps with host aggregates, because 
> nova-compute needs to create/search host aggregates first, it can’t directly 
> attach caps.
> 3. Other services may need to attach discovered capabilities to its 
> resources. So the best place is to its related resource pool, not aggregates, 
> nor compute_node records. Note the relationship between resource pools and 
> host aggregates are N:N.
> 4. It’s logically correct to store caps with resource_providers, because caps 
> are actually owned by nodes or resource pools.
> 5. Scheduling will be faster if resource-providers are directly attached with 
> caps.
> 
> However, for user-defined caps, it still seems easier to manage them with 
> aggregates. We may want to manage them in a way different from pre-defined 
> caps. Or we can indirectly manage them through aggregates, but they are 
> actually stored with compute-node resource-providers in placement db.

Oh, I think you misunderstood me. Capabilities definitely belong with resource 
providers, not host aggregates, because not all RPs are hosts.

I'm thinking that host aggregates themselves are equivalent to capabilities for 
hosts. Imagine we have 10 hosts, and put 3 of them in an aggregate. How is that 
different than if we give those three a tag with the 'host_agg' namespace, and 
with tag named for the agg?

I'm just thinking out loud here. There might be opportunities to simplify a lot 
of the code between capability tags and host aggregates in the future, since it 
looks like host aggs are a structural subset of RP capability tags.

-- Ed Leafe







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

[openstack-dev] [tricircle]cancellation of weekly meeting of Jul.13

[joehuang]

Due to flight delay, this weekly meeting
of the Tricircle project will be canceled.

Sent from HUAWEI AnyOffice
发件人：黄朝意
收件人：openstack-dev,
时间：2016-07-06 14:15:43
主题:[openstack-dev][tricircle]agenda of weekly meeting of Jul.6


Hi, team,


IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every 
Wednesday starting from UTC 13:00.



The agenda of this weekly meeting is:

# bugs review: https://bugs.launchpad.net/tricircle

# bump to Nova 2.1: https://review.openstack.org/#/c/324226/

# L2/L3 networking with the help of 'Add Unicast Flooding Vteps to Provider 
Network': https://review.openstack.org/#/c/282180/

# todo list review https://etherpad.openstack.org/p/TricircleToDo


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

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

Re: [openstack-dev] [nova][qa] When do we need tests for microversions in Tempest?

[Ken'ichi Ohmichi]

Hi Matt,


2016-07-14 11:55 GMT+09:00 Matt Riedemann :
> There are several changes in Tempest right now trying to add response schema
> validation for the 2.26 microversion which added server tags to the server
> GET response. This is needed for anything testing a microversion >=2.26,
> which several people are trying to add.
>
> We have a similar issue with the 2.3 microversion which is really a bug, but
> only exposed in jobs that have run_validation=True which is only in a
> non-voting job right now.
>
> I've mostly been debating this in this change:
>
> https://review.openstack.org/#/c/233176/
>
> I've added an item to the nova midcycle meetup agenda to talk about the plan
> for handling microversion testing in tempest for nova changes, specifically
> around API response validation.
>
> I agree that nova doesn't test response schema validation in tree, so doing
> it in tempest is good.
>
> But I'm not sure that we need a new set of tempest tests for every
> microversion change in nova, e.g. if it's only touching the API and
> database, like server tags, we can test that in nova.

I think it is nice to implement every microversion tests in Tempest
for preparing the base/minimum microversion bump in the future.
On API microversions mechanism, we have defined the minimum
microversion(now version 2.1) can be increased.
Every microversion test will provide an option when we want to bump it
to verify a new minimum microversion is stable by Tempest as an
integrated test.

> It's also not great having several changes in flight at the same time to
> tempest trying to add the same 2.26 response schema because it wasn't added
> the at the same time the 2.26 API merged.
>
> I also wonder what it means if someone configures max_microversion in
> tempest.conf to something we don't test, like say 2.11, what blows up? For
> example, we know that we don't have response validation for 2.3 so some
> tests are broken when you run with ssh validation and microversion>=2.3.

Ideally, the response schema also should be implemented on Tempest.
but it is difficult to catch up because the microversion bumping is
fast on Nova side.
The max_microversion option is useful to operate the same Tempest to
master/stable branches which are different microversions.

Thanks
Ken Ohmichi

---

> So I'm thinking we should:
>
> 1. Always add a schema change to Tempest if a microversion changes a
> response.
>
> 2. Only add tests to Tempest for a microversion change if it can't be tested
> within nova, e.g. you actually need to create a server, or use other
> services like glance/cinder/neutron.
>
> mtreinish and sdague will be at the nova midcycle so hopefully they can
> represent for the QA team.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova][qa] When do we need tests for microversions in Tempest?

[Matthew Treinish]

On Wed, Jul 13, 2016 at 09:55:33PM -0500, Matt Riedemann wrote:
> There are several changes in Tempest right now trying to add response schema
> validation for the 2.26 microversion which added server tags to the server
> GET response. This is needed for anything testing a microversion >=2.26,
> which several people are trying to add.
> 
> We have a similar issue with the 2.3 microversion which is really a bug, but
> only exposed in jobs that have run_validation=True which is only in a
> non-voting job right now.
> 
> I've mostly been debating this in this change:
> 
> https://review.openstack.org/#/c/233176/
> 
> I've added an item to the nova midcycle meetup agenda to talk about the plan
> for handling microversion testing in tempest for nova changes, specifically
> around API response validation.
> 
> I agree that nova doesn't test response schema validation in tree, so doing
> it in tempest is good.
> 
> But I'm not sure that we need a new set of tempest tests for every
> microversion change in nova, e.g. if it's only touching the API and
> database, like server tags, we can test that in nova.

I largely agree with this, we don't need 100% coverage of every microversion.
Especially if it's just an API that's just extra metadata in the DB.

> 
> It's also not great having several changes in flight at the same time to
> tempest trying to add the same 2.26 response schema because it wasn't added
> the at the same time the 2.26 API merged.

I agree it's not ideal, but it's not like there is a huge burden on rebasing,
no more than for developers having to bump their microversions because another
bp landed and took the microversion they were using.


> 
> I also wonder what it means if someone configures max_microversion in
> tempest.conf to something we don't test, like say 2.11, what blows up? For
> example, we know that we don't have response validation for 2.3 so some
> tests are broken when you run with ssh validation and microversion>=2.3.

We can easily add a job that changes the min microversion config flag in tempest
to something higher than 2.1. This will ensure we send a higher microversion
everywhere and will catch these issues sooner. But, I'm not sure we want to do
that on a normal check/gate job.

> 
> So I'm thinking we should:
> 
> 1. Always add a schema change to Tempest if a microversion changes a
> response.

The problem with this is we shouldn't land a schema change by itself in tempest.
Until we have something using the schema we have no verification that they
actually work. We can and will land incorrect schemas if we did this. That's why
there is a pretty strong policy of only landing code that is run in CI somewhere
for Tempest.

> 
> 2. Only add tests to Tempest for a microversion change if it can't be tested
> within nova, e.g. you actually need to create a server, or use other
> services like glance/cinder/neutron.

+1

-Matt Treinish

> 
> mtreinish and sdague will be at the nova midcycle so hopefully they can
> represent for the QA team.
>


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

[openstack-dev] [nova][qa] When do we need tests for microversions in Tempest?

[Matt Riedemann]

There are several changes in Tempest right now trying to add response 
schema validation for the 2.26 microversion which added server tags to 
the server GET response. This is needed for anything testing a 
microversion >=2.26, which several people are trying to add.


We have a similar issue with the 2.3 microversion which is really a bug, 
but only exposed in jobs that have run_validation=True which is only in 
a non-voting job right now.


I've mostly been debating this in this change:

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

I've added an item to the nova midcycle meetup agenda to talk about the 
plan for handling microversion testing in tempest for nova changes, 
specifically around API response validation.


I agree that nova doesn't test response schema validation in tree, so 
doing it in tempest is good.


But I'm not sure that we need a new set of tempest tests for every 
microversion change in nova, e.g. if it's only touching the API and 
database, like server tags, we can test that in nova.


It's also not great having several changes in flight at the same time to 
tempest trying to add the same 2.26 response schema because it wasn't 
added the at the same time the 2.26 API merged.


I also wonder what it means if someone configures max_microversion in 
tempest.conf to something we don't test, like say 2.11, what blows up? 
For example, we know that we don't have response validation for 2.3 so 
some tests are broken when you run with ssh validation and 
microversion>=2.3.


So I'm thinking we should:

1. Always add a schema change to Tempest if a microversion changes a 
response.


2. Only add tests to Tempest for a microversion change if it can't be 
tested within nova, e.g. you actually need to create a server, or use 
other services like glance/cinder/neutron.


mtreinish and sdague will be at the nova midcycle so hopefully they can 
represent for the QA team.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Neutron] MultiTenant support for VLAN-Aware-VM

[Armando M.]

On 13 July 2016 at 16:51, Kevin Benton  wrote:

> Sub ports are just regular ports from a logical model perspective, right?
> If so, there should be no problem attaching the port to a shared network or
> RBAC granted network.
>

True, but I don't believe it until I test it :)

On Jul 13, 2016 7:15 PM, "Armando M."  wrote:
>
>>
>>
>> On 13 July 2016 at 15:32, Cathy Zhang  wrote:
>>
>>> Hi Everyone,
>>>
>>> We have been discussing on multi-tenant VNF for service chain on the OVN
>>> mailing alias.
>>> We are thinking about leveraging the vlan-aware-VM for supporting this.
>>>
>>> AFAIK, with current nova, we cannot create a multi-tenant  VNF.
>>> Currently, nova checks whether the neutron port belongs to the same
>>> tenant as the VM itself.
>>> You attach a network interface (neutron port) to a VM using nova
>>> interface-attach, if the port and the VM are in different tenants, an error
>>> is given.
>>>
>>> With the introduction of the trunk-port/sub-port feature of Neutron, the
>>> sub-ports of a VM are allowed to associate with different networks. But it
>>> seems these networks need to all belong to the same tenant if we read the
>>> vlan-aware-vm spec correctly (
>>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html
>>> ).
>>>
>>> Is our understanding correct? Does it work properly if these networks
>>> belong to different tenants?
>>>
>>
>> At the moment this area is still WIP, but we're focusing on the single
>> tenant use case. RBAC may help us down the road to address what you need,
>> but it's premature to speculate on how the implementation looks like.
>>
>> Cheers,
>> Armando
>>
>>
>>>
>>> Thanks,
>>> Cathy
>>>
>>> -Original Message-
>>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad
>>> Sunavala
>>> Sent: Tuesday, July 12, 2016 7:59 PM
>>> To: d...@openvswitch.org
>>> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>>>
>>> >I was thinking this could be handled with child / sub-ports.  We do
>>> >this today for containers in VMs.  We can have a single VIF for a VM
>>> >that is connected to multiple networks that are owned by separate
>>> >tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>>> >would be used to differentiate the traffic for each networking in/out
>>> >of that VIF.  I had started adding the ability to use MPLS for this in
>>> >my prototype for this reason, as that was what networking-sfc had
>>> defined.
>>> I have a quick question on the above. (multi-tenancy).Yes, I know the
>>> containers can be in different networks of the same tenant.How does it work
>>> when the containers are in different tenants ?
>>> Below is the latest spec for vlan-aware-vms
>>> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
>>>
>>> The trick is to create neutron ports (for the subports) and then link
>>> them to the trunk port using neutron trunk-subport-add TRUNK \
>>>  PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]
>>>
>>> In the above command all the neutron ports (trunk  ports and subports)
>>> must be in the same tenant.As far as I know, a tenant will not see neutron
>>> ports from another tenant.Or will this command allow neutron ports from
>>> different tenants to be attached ?
>>> E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1
>>> (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The
>>> trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The
>>> above command will be neutron trunk-subport-add T1 \   A  vlan 1 \
>>>  B vlan 2 Is my understanding correct? thanks,Farhad.
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/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

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Cheng, Yingxin]

On 7/14/16, 05:42, "Ed Leafe"  wrote:
On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin  wrote:
> 4. Capabilities are managed/grouped/abstracted by namespaces, and 
scheduler can make decisions based on either cap_names or cap_namespaces
> 5. Placement service DON’T have any specific knowledge of a capability, 
it only know the its name, namespaces, its relationship to resource providers. 
They are used for scheduling, capability management and report.

Thinking about that a bit, it would seem that a host aggregate could also 
be represented as a namespace:name tag. That makes sense, since the fact that a 
host belongs to a particular aggregate is a qualitative aspect of that host.


Thanks for the feedback!

We’ve thought about the relationship between capability tags and host 
aggregates carefully. And we decide not to blend it with host aggregates, for 
several reasons below:
1. We want to manage capabilities in only ONE place, either in host aggregates, 
compute_node records or with resource_provider records.
2. Compute services may need to attach discovered capabilities to its host. It 
is inconvenient if we store caps with host aggregates, because nova-compute 
needs to create/search host aggregates first, it can’t directly attach caps.
3. Other services may need to attach discovered capabilities to its resources. 
So the best place is to its related resource pool, not aggregates, nor 
compute_node records. Note the relationship between resource pools and host 
aggregates are N:N.
4. It’s logically correct to store caps with resource_providers, because caps 
are actually owned by nodes or resource pools.
5. Scheduling will be faster if resource-providers are directly attached with 
caps.

However, for user-defined caps, it still seems easier to manage them with 
aggregates. We may want to manage them in a way different from pre-defined 
caps. Or we can indirectly manage them through aggregates, but they are 
actually stored with compute-node resource-providers in placement db. 


-- 
Regards
Yingxin 

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

[openstack-dev] Openstack-CEPH-Developer Opportunity-Bangalore, India

[Janardhan Husthimme]

Hello Openstack community,


I am looking for hiring Openstack & CEPH developers for my team in Bangalore, 
if anyone keen to explore, do unicast me at 
jhusthi...@walmartlabs.com.


Sorry folks for using this forum, thought of dropping a note.



Thanks,

Janardhan

__
OpenStack Development Mailing 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] [Gluon] Project Creation and Weekly Team Meeting starts on 07/13/2016 at 1800UTC Wednesdays

[HU, BIN]

Hello team,

We had a great kick-off meeting today. You can find our raw log here:

http://eavesdrop.openstack.org/meetings/gluon/2016/gluon.2016-07-13-18.04.log.txt

Cheers
Bin

From: HU, BIN
Sent: Wednesday, July 06, 2016 10:02 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: [Gluon] Project Creation and Weekly Team Meeting starts on 07/13/2016 
at 1800UTC Wednesdays

Hello team,

I am gladly to announce that we have created a new, although unofficial, 
project Gluon. Congratulations.

Our team wiki is [1], and general meeting page is [2] that intends to archive 
the history of all meetings. Because the project was just created, both [3] and 
[4] are still under construction. More information will come soon.

I am also pleased to announce that we will start our team weekly meeting on 
07/13/2016 at 1800UTC Wednesdays.

Please see [3] for details of meeting logistics, and [4] for tentative agenda. 
Feel free to propose other items for agenda.

Thanks
Bin

[1] https://wiki.openstack.org/wiki/Gluon
[2] https://wiki.openstack.org/wiki/Meetings/Gluon
[3] http://eavesdrop.openstack.org/#Gluon_Meeting
[4] https://wiki.openstack.org/wiki/Meetings/Gluon/Agenda-20160713

__
OpenStack Development Mailing 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][networking-sfc] meeting topics for 7/14/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
The following link shows the topics I have for this week's project meeting 
discussion. Feel free to add more.
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
Thanks,
Cathy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] MultiTenant support for VLAN-Aware-VM

[Kevin Benton]

Sub ports are just regular ports from a logical model perspective, right?
If so, there should be no problem attaching the port to a shared network or
RBAC granted network.
On Jul 13, 2016 7:15 PM, "Armando M."  wrote:

>
>
> On 13 July 2016 at 15:32, Cathy Zhang  wrote:
>
>> Hi Everyone,
>>
>> We have been discussing on multi-tenant VNF for service chain on the OVN
>> mailing alias.
>> We are thinking about leveraging the vlan-aware-VM for supporting this.
>>
>> AFAIK, with current nova, we cannot create a multi-tenant  VNF.
>> Currently, nova checks whether the neutron port belongs to the same
>> tenant as the VM itself.
>> You attach a network interface (neutron port) to a VM using nova
>> interface-attach, if the port and the VM are in different tenants, an error
>> is given.
>>
>> With the introduction of the trunk-port/sub-port feature of Neutron, the
>> sub-ports of a VM are allowed to associate with different networks. But it
>> seems these networks need to all belong to the same tenant if we read the
>> vlan-aware-vm spec correctly (
>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html
>> ).
>>
>> Is our understanding correct? Does it work properly if these networks
>> belong to different tenants?
>>
>
> At the moment this area is still WIP, but we're focusing on the single
> tenant use case. RBAC may help us down the road to address what you need,
> but it's premature to speculate on how the implementation looks like.
>
> Cheers,
> Armando
>
>
>>
>> Thanks,
>> Cathy
>>
>> -Original Message-
>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad
>> Sunavala
>> Sent: Tuesday, July 12, 2016 7:59 PM
>> To: d...@openvswitch.org
>> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>>
>> >I was thinking this could be handled with child / sub-ports.  We do
>> >this today for containers in VMs.  We can have a single VIF for a VM
>> >that is connected to multiple networks that are owned by separate
>> >tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>> >would be used to differentiate the traffic for each networking in/out
>> >of that VIF.  I had started adding the ability to use MPLS for this in
>> >my prototype for this reason, as that was what networking-sfc had
>> defined.
>> I have a quick question on the above. (multi-tenancy).Yes, I know the
>> containers can be in different networks of the same tenant.How does it work
>> when the containers are in different tenants ?
>> Below is the latest spec for vlan-aware-vms
>> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
>>
>> The trick is to create neutron ports (for the subports) and then link
>> them to the trunk port using neutron trunk-subport-add TRUNK \
>>  PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]
>>
>> In the above command all the neutron ports (trunk  ports and subports)
>> must be in the same tenant.As far as I know, a tenant will not see neutron
>> ports from another tenant.Or will this command allow neutron ports from
>> different tenants to be attached ?
>> E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1
>> (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The
>> trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The
>> above command will be neutron trunk-subport-add T1 \   A  vlan 1 \
>>  B vlan 2 Is my understanding correct? thanks,Farhad.
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/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] [craton] Craton developer meeting Thurs July 14 at 1700 UTC

[Jim Baker]

Please join us this Thursday for our weekly Craton developer video meeting.
To better accommodate people from Europe, we have moved the time for this
and subsequent Thursday meetings to 1700 UTC.

Topics to be discussed in this week's call include:

   - Inventory fabric. Recently we have decided this term best describes
   our inventory approach for Craton: a seamless wrapping of both Craton's
   source of truth information about inventory, such as config variables about
   hosts; and externally sourced data, using virtualization (much like
   symbolic links in a filesystem). There's still a lot of work to do to
   complete this vision.
   - Summary of discussion on proposed work with upstream TaskFlow to look
   at using containers for jobs. For Craton, our reference implementation is
   against OpenStack Ansible. Instead of using TaskFlow workers to in turn run
   an Ansible playbook, the idea is to run a container. This moves, and
   hopefully simplifies, the packaging problem for playbooks and any
   dependencies. If Craton has similar qualities to Hadoop map/reduce, then
   containers offers even more than packing jars and using ClassLoader
   approaches :)
   - Outstanding issues, as currently tracked here:
   https://waffle.io/rackerlabs/craton

Video conference calls are held on Vidyo:
https://vc.rackspace.com/flex.html?roomdirect.html=OpmgbcmKWcXB31Tbl7VHgTrytb0

(Please note, these meetings will be recorded and posted to YouTube, so if
you do not wish to be recorded, please do not attend the meeting.)

- Jim
__
OpenStack Development Mailing 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] MultiTenant support for VLAN-Aware-VM

[Armando M.]

On 13 July 2016 at 15:32, Cathy Zhang  wrote:

> Hi Everyone,
>
> We have been discussing on multi-tenant VNF for service chain on the OVN
> mailing alias.
> We are thinking about leveraging the vlan-aware-VM for supporting this.
>
> AFAIK, with current nova, we cannot create a multi-tenant  VNF.
> Currently, nova checks whether the neutron port belongs to the same tenant
> as the VM itself.
> You attach a network interface (neutron port) to a VM using nova
> interface-attach, if the port and the VM are in different tenants, an error
> is given.
>
> With the introduction of the trunk-port/sub-port feature of Neutron, the
> sub-ports of a VM are allowed to associate with different networks. But it
> seems these networks need to all belong to the same tenant if we read the
> vlan-aware-vm spec correctly (
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html
> ).
>
> Is our understanding correct? Does it work properly if these networks
> belong to different tenants?
>

At the moment this area is still WIP, but we're focusing on the single
tenant use case. RBAC may help us down the road to address what you need,
but it's premature to speculate on how the implementation looks like.

Cheers,
Armando


>
> Thanks,
> Cathy
>
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad
> Sunavala
> Sent: Tuesday, July 12, 2016 7:59 PM
> To: d...@openvswitch.org
> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>
> >I was thinking this could be handled with child / sub-ports.  We do
> >this today for containers in VMs.  We can have a single VIF for a VM
> >that is connected to multiple networks that are owned by separate
> >tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
> >would be used to differentiate the traffic for each networking in/out
> >of that VIF.  I had started adding the ability to use MPLS for this in
> >my prototype for this reason, as that was what networking-sfc had defined.
> I have a quick question on the above. (multi-tenancy).Yes, I know the
> containers can be in different networks of the same tenant.How does it work
> when the containers are in different tenants ?
> Below is the latest spec for vlan-aware-vms
> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
>
> The trick is to create neutron ports (for the subports) and then link them
> to the trunk port using neutron trunk-subport-add TRUNK \
>  PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]
>
> In the above command all the neutron ports (trunk  ports and subports)
> must be in the same tenant.As far as I know, a tenant will not see neutron
> ports from another tenant.Or will this command allow neutron ports from
> different tenants to be attached ?
> E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1
> (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The
> trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The
> above command will be neutron trunk-subport-add T1 \   A  vlan 1 \
>  B vlan 2 Is my understanding correct? thanks,Farhad.
> ___
> dev mailing list
> d...@openvswitch.org
> http://openvswitch.org/mailman/listinfo/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] [Nova] Regarding fix for 1454165

[Chris Friesen]

On 07/13/2016 04:12 PM, Sean Wilcox wrote:

With this bug fix the resize_instance definition was effectively changed that is
passed into the virt drivers finish_migration() function, IMHO.


Agreed.


Is it really true that changing memory and/or cpu isn't a resize at all?


No, it's definitely a resize.  It's just not a disk resize.

> If so  it seems

the definition of the resize_instance parameter for finish_migration should be
changed.


Totally agree...it would make much more sense to call it "resize_disk".  Do you 
want to make the change, or shall I?


Chris

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

[openstack-dev] [new][winstackers] os-win 1.1.0 release (newton)

[no-reply]

We are pleased to announce the release of:

os-win 1.1.0: Windows / Hyper-V library for OpenStack projects.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-win

With package available at:

https://pypi.python.org/pypi/os-win

Please report issues through launchpad:

http://bugs.launchpad.net/os-win

For more details, please see below.

Changes in os-win 1.0.0..1.1.0
--

5e78a0b Updated from global requirements
eb6923f Adds method for returning DNS Zone properties
baab117 iSCSI tgt utils: remove workaround needed by old WMI lib
b5d6089 Add instance job terminate timeout
88cd6e4 Hyper-V: Added checking secure VMs status
660d2b5 Updated from global requirements
bcc5ce2 Properly handle stopping VM jobs
efb4821 Add utils for managing DNS operations
433d1e4 Fix for VM's not getting IP due to missing SG rules
2d6e43c Updated from global requirements


Diffstat (except docs and test files)
-

os_win/_utils.py   |  54 -
os_win/constants.py|  20 ++
os_win/exceptions.py   |  16 ++
.../storage/target/test_iscsi_target_utils.py  |  67 ++
os_win/utils/compute/vmutils.py|   3 +
os_win/utils/compute/vmutils10.py  |   9 +
os_win/utils/dns/__init__.py   |   0
os_win/utils/dns/dnsutils.py   | 184 +++
os_win/utils/jobutils.py   |  81 +--
os_win/utils/network/networkutils.py   |   4 -
os_win/utils/storage/target/iscsi_target_utils.py  |  12 +-
os_win/utils/win32utils.py |  12 +-
os_win/utilsfactory.py |   9 +
requirements.txt   |   6 +-
test-requirements.txt  |   2 +-
23 files changed, 811 insertions(+), 130 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 70eb018..4b827b8 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10 +10 @@ oslo.concurrency>=3.8.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
@@ -12 +12 @@ oslo.log>=1.14.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
@@ -18 +18 @@ PyMI>=1.0.0;sys_platform=='win32' # Apache 2.0 License
-wmi;sys_platform=='win32'  # MIT
+wmi;sys_platform=='win32' # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index 92d4dd8..8289eb5 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11 +11 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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] [daisycloud-core] Core Discussions

[jason]

Jaivish,
I also thought about that . As we have more and more development activities
on the go ,we really need to look into this.
I will not available at meeting but I would like to elect  Wei (
kong.w...@zte.com.cn) to become the  core member, because he has good
experience on testing, ci and open source development in other fields of
OpenStack, for example, he built the daisycloud zuul tester,and he has
successfully lead another team finished a BP of a cinder driver. But we
still need to have a consensus on if he can be the core.  And I believe we
are all open to see if someone else has the qualifications to become core
too. So let's discuss about that on the coming IRC meeting and mailing list
as much as possible.
On Jul 12, 2016 7:05 PM, "Jaivish Kothari" 
wrote:

> Hello Jason,
>
> I think daisycloud team should have more core members, i think making
> initial members to be core would be one option that would help in review
> process as other projects in openstack do.
> Also along with it making patches to be merged only when atleast 2 cores
> have +2 votes on it would be a good option.
> What do you think?
>
>
> Regards,
> Jaivish Kothari
>
>
__
OpenStack Development Mailing 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] MultiTenant support for VLAN-Aware-VM

[Cathy Zhang]

Hi Everyone,

We have been discussing on multi-tenant VNF for service chain on the OVN 
mailing alias. 
We are thinking about leveraging the vlan-aware-VM for supporting this. 

AFAIK, with current nova, we cannot create a multi-tenant  VNF.
Currently, nova checks whether the neutron port belongs to the same tenant as 
the VM itself.  
You attach a network interface (neutron port) to a VM using nova 
interface-attach, if the port and the VM are in different tenants, an error is 
given.

With the introduction of the trunk-port/sub-port feature of Neutron, the 
sub-ports of a VM are allowed to associate with different networks. But it 
seems these networks need to all belong to the same tenant if we read the 
vlan-aware-vm spec correctly 
(http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html).
 

Is our understanding correct? Does it work properly if these networks belong to 
different tenants? 

Thanks,
Cathy

-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad Sunavala
Sent: Tuesday, July 12, 2016 7:59 PM
To: d...@openvswitch.org
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

>I was thinking this could be handled with child / sub-ports.  We do 
>this today for containers in VMs.  We can have a single VIF for a VM 
>that is connected to multiple networks that are owned by separate 
>tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever) 
>would be used to differentiate the traffic for each networking in/out 
>of that VIF.  I had started adding the ability to use MPLS for this in 
>my prototype for this reason, as that was what networking-sfc had defined.
I have a quick question on the above. (multi-tenancy).Yes, I know the 
containers can be in different networks of the same tenant.How does it work 
when the containers are in different tenants ?
Below is the latest spec for vlan-aware-vms 
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

The trick is to create neutron ports (for the subports) and then link them to 
the trunk port using neutron trunk-subport-add TRUNK \   
PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]

In the above command all the neutron ports (trunk  ports and subports) must be 
in the same tenant.As far as I know, a tenant will not see neutron ports from 
another tenant.    Or will this command allow neutron ports from different 
tenants to be attached ?
E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1 
(network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The 
trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The 
above command will be neutron trunk-subport-add T1 \   A  vlan 1 \   B 
vlan 2 Is my understanding correct? thanks,Farhad.
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Regarding fix for 1454165

[Sean Wilcox]

With this bug fix the resize_instance definition was effectively changed 
that is

passed into the virt drivers finish_migration() function, IMHO.

Is it really true that changing memory and/or cpu isn't a resize at 
all?  If so it seems
the definition of the resize_instance parameter for finish_migration 
should be changed.


Opinions/Thoughts?

Thanks,

--
Sean Wilcox
3032729711
x79711


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

Re: [openstack-dev] [Cinder][CI] Rule of recheck keywords has been updated

[Anita Kuno]

On 07/13/2016 05:36 PM, Sean McGinnis wrote:
> Thanks for sending this out!
> 
> It would be appreciated if all CI maintainers get this updated to follow
> the recommendations soon. It would really help us have consistency
> across systems.
> 
> Sean

Clarifying this is a Cinder decision, so all Cinder Ci maintainers.

Thank you,
Anita.

> 
>> Hello Cinder Third-Party CI Maintainers,
>>
>> The rule of recheck keywords has been discussed in today's IRC meeting [1].
>> And the wiki [2] of tested-3rdParty-drivers has been updated.
>> # The diff is [3].
>>
>> Please check the update and update your CI.
>> It would be appreciated if you could also update the "Recheck trigger" 
>> information in your CI's wiki.
>> You can find your CI's wiki pages at [4].
>>
>> [1] 
>> http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-07-13-16.00.log.html
>> [2] 
>> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_trigger_my_CI_to_rerun_on_gerrit_comments.3F
>> [3] 
>> https://wiki.openstack.org/w/index.php?title=Cinder/tested-3rdParty-drivers=3690=128050=126774
>> [4] https://wiki.openstack.org/wiki/ThirdPartySystems
>>
>> Best regards,
>> Watanabe.isao
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Ed Leafe]

On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin  wrote:

> 4. Capabilities are managed/grouped/abstracted by namespaces, and scheduler 
> can make decisions based on either cap_names or cap_namespaces
> 5. Placement service DON’T have any specific knowledge of a capability, it 
> only know the its name, namespaces, its relationship to resource providers. 
> They are used for scheduling, capability management and report.

Thinking about that a bit, it would seem that a host aggregate could also be 
represented as a namespace:name tag. That makes sense, since the fact that a 
host belongs to a particular aggregate is a qualitative aspect of that host.


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

Re: [openstack-dev] [Cinder][CI] Rule of recheck keywords has been updated

[Sean McGinnis]

Thanks for sending this out!

It would be appreciated if all CI maintainers get this updated to follow
the recommendations soon. It would really help us have consistency
across systems.

Sean

> Hello Cinder Third-Party CI Maintainers,
> 
> The rule of recheck keywords has been discussed in today's IRC meeting [1].
> And the wiki [2] of tested-3rdParty-drivers has been updated.
> # The diff is [3].
> 
> Please check the update and update your CI.
> It would be appreciated if you could also update the "Recheck trigger" 
> information in your CI's wiki.
> You can find your CI's wiki pages at [4].
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-07-13-16.00.log.html
> [2] 
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_trigger_my_CI_to_rerun_on_gerrit_comments.3F
> [3] 
> https://wiki.openstack.org/w/index.php?title=Cinder/tested-3rdParty-drivers=3690=128050=126774
> [4] https://wiki.openstack.org/wiki/ThirdPartySystems
> 
> Best regards,
> Watanabe.isao
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Ed Leafe]

On Jul 11, 2016, at 6:08 AM, Alex Xu  wrote:

> For example, the capabilities can be defined as:
> 
> COMPUTE_HW_CAP_CPU_AVX
> COMPUTE_HW_CAP_CPU_SSE
> 
> COMPUTE_HV_CAP_LIVE_MIGRATION
> COMPUTE_HV_CAP_LIVE_SNAPSHOT
> 
> 
> ( The COMPUTE means this is coming from Nova. HW means this is hardware 
> related Capabilities. HV means this is
>  capabilities of Hypervisor. But the catalog of Capabilities can be discussed 
> separated. This propose focus on the
>  ResourceTags. We also have another idea about not using 'PREFIX' to manage 
> the Tags. We can add attributes to the
>  Tags. Then we have more control on the Tags. This will describe separately 
> in the bottom. )

I was ready to start ranting about using horribly mangled names to represent 
data, and then saw your comment about attributes for tags. Yes, a thousand 
times yes to attributes! There can be several standards, such as ‘compute’ or 
‘networking’ that we use for some basic cross-cloud compatibility, but making 
them flexible is a must for adoption.

I can update the qualitative request spec to add ResourceProviderTags as a 
possible implementation.


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

Re: [openstack-dev] [Murano][user-guide][docs] Add section 'Murano applications guide' to the End User Guide

[Sergey Slypushenko]

Hi Lana!

Thank for your reply! It looks like, the spec is definitely needed in this
case. I'll send it on review asap.

 Regards,
Serg

On Wed, Jul 13, 2016 at 2:31 AM, Lana Brindley 
wrote:

> Hi Serg!
>
> I've cc'd Joseph into this mail, to make sure he sees it. Joseph looks
> after the User Guides speciality team within docs.
>
> To answer your question, a spec really is the best way to start with this
> content, it will probably also help you pick up some interested helpers.
> Once that's approved, go right ahead and start with patches :)
>
> L
>
> On 13/07/16 03:14, Sergey Slypushenko wrote:
> > Hi, folks!
> >
> > I'm working on user guide about developing and using custom Murano
> applications. As far as I'm concerned End User Guide [1] would be a perfect
> fit for this document. Mainly because, it demonstarates one more way to
> regular cloud users, how they can consume services provided by OpenStack
> cloud.
> >
> > Looking through latest version of End User Guide, I surprisingly found
> that there are no references to Murano project in it. So, I submitted this
> patchset [2]. It suppose to be a placeholder to put Murano related user
> guides in it. For the very begging, I just make reference on existed docs,
> like it is done for Heat object templates [3] now. We already have been
> working on more content for this section. So, what is proper way to move
> forward? I see, some options here:
> >
> >   * Submit a spec from this activity to docs-specs
> >   * Prepare whole Murano user guide and send it in a single patchset
> >   * Land initial patchset and continue work on providing more content
> >
> > Personally, I'd prefer the latest option, but i'm not very familiar with
> recognized flow. So, what do you think, folks?
> >
> > Best Regards,
> > Serg Slipushenko
> >
> > [1] http://docs.openstack.org/user-guide/
> > [2] https://review.openstack.org/#/c/340474/
> > [3] http://docs.openstack.org/user-guide/hot.html
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [new][oslo] mox3 0.17.0 release (newton)

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2016-07-13 17:22:32 +:
> On 2016-07-13 17:10:20 +0200 (+0200), Markus Zoeller wrote:
> > Whoever chooses the wording in these announcements, you're a genius!
> 
> You too can be a genius--add some more--there's only ~20 at the
> moment so they repeat pretty often:
> 
>  http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py?id=da89264#n33
>  >

Indeed, I've worn out my thesaurus. Please send synonyms.

Doug

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

[openstack-dev] [nova] Let's kill quota classes (again)

[Matt Riedemann]

We got a bug that the os-quota-class-sets API isn't documented:

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

That's probably because we hate it and no one understands it.

See this previous thread about trying to sort this out from the long 
long ago:


https://lists.launchpad.net/openstack/msg12200.html

We tried killing it before, but it turns out, it's actually used by 
something!


http://lists.openstack.org/pipermail/openstack-dev/2014-May/036031.html

But we didn't have integration testing in Tempest for default quotas at 
that time (we added those tests in when we reverted the delete of the 
API back in Juno).


I got looking at this because of the quota_class attribute in the nova 
RequestContext:


https://github.com/openstack/nova/blob/93cc5e3ffd2867bdb39a707a230c1efc6ed2f5f4/nova/context.py#L138-L141

That led me to markmc's thread about that only being there for the 
turnstile project and some old API rate limiting stuff that Rackspace 
was doing out of tree (it appears to set a type of middleware for a 
quota class for rate limiting).


Anyway, super duper out of tree stuff that is probably not even used 
anymore (Vek - if you're reading, please speak up).


I'll also point out that API rate limiting as a paste config was only in 
the v2 API and that code was all dropped and the API rate limiting stuff 
wasn't carried over for the v2.1 API, for good reason, see:


http://lists.openstack.org/pipermail/openstack-operators/2016-June/010692.html

You can still create unique quota classes via the os-quota-class-sets 
API (it does a create if the update operation fails), but as far as I 
can tell you can't really use those in any meaningful way.


We really just have the 'default' quota class with a buttload of code 
and plumbing to use that, which sucks, because it's all very complicated.


So I think I'm going to start a pet project of rooting this stuff out 
again, starting with nova.context.RequestContext.quota_class, unless 
anyone has a good reason we should keep this in tree.


I think we should also add a microversion to the API in Ocata to disable 
the ability to create new quota classes, so that update is only update, 
and a 404 for anything else.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [Cinder][CI] Rule of recheck keywords has been updated

[Watanabe, Isao]

Hello Cinder Third-Party CI Maintainers,

The rule of recheck keywords has been discussed in today's IRC meeting [1].
And the wiki [2] of tested-3rdParty-drivers has been updated.
# The diff is [3].

Please check the update and update your CI.
It would be appreciated if you could also update the "Recheck trigger" 
information in your CI's wiki.
You can find your CI's wiki pages at [4].

[1] 
http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-07-13-16.00.log.html
[2] 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_trigger_my_CI_to_rerun_on_gerrit_comments.3F
[3] 
https://wiki.openstack.org/w/index.php?title=Cinder/tested-3rdParty-drivers=3690=128050=126774
[4] https://wiki.openstack.org/wiki/ThirdPartySystems

Best regards,
Watanabe.isao



__
OpenStack Development Mailing 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] Status of the OpenStack port to Python 3

[Denis Makogon]

Hello to All.


I have free capacity to work on porting code to Py3. So, if any PTL is
running out of team capacity i can help to work on project to enable Py3
support.

Kind regards,
Denys Makogon


2016-07-06 13:01 GMT+03:00 Flavio Percoco :

> On 24/06/16 12:17 -0400, Sean Dague wrote:
>
>> On 06/24/2016 11:48 AM, Doug Hellmann wrote:
>>
>>> Excerpts from Dmitry Tantsur's message of 2016-06-24 10:59:14 +0200:
>>>
 On 06/23/2016 11:21 PM, Clark Boylan wrote:

> On Thu, Jun 23, 2016, at 02:15 PM, Doug Hellmann wrote:
>
>> Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:
>>
>>> On 06/23/2016 06:11 PM, Doug Hellmann wrote:
>>>
 I'd like for the community to set a goal for Ocata to have Python
 3 functional tests running for all projects.

 As Tony points out, it's a bit late to have this as a priority for
 Newton, though work can and should continue. But given how close
 we are to having the initial phase of the port done (thanks
 Victor!),
 and how far we are from discussions of priorities for Ocata, it
 seems very reasonable to set a community-wide goal for our next
 release cycle.

 Thoughts?

 Doug

>>>
>>> +1
>>>
>>> Just think about it for a while. If we get Nova to work with Py3, and
>>> everything else is working, including all functional tests in
>>> Tempest,
>>> then after Otaca, we could even start to *REMOVE* Py2 support after
>>> Otaca+1. That would be really awesome to stop all the compat layer
>>> madness and use the new features available in Py3.
>>>
>>
>> We'll need to get some input from other distros and from deployers
>> before we decide on a timeline for dropping Python 2. For now, let's
>> focus on making Python 3 work. Then we can all rejoice while having
>> the
>> discussion of how much longer to support Python 2. :-)
>>
>>
>>> I really would love to ship a full stack running Py3 for Debian
>>> Stretch.
>>> However, for this, it'd be super helful to have as much visibility as
>>> possible. Are we setting a hard deadline for the Otaca release? Or is
>>> this just a goal we only "would like" to reach, but it's not really a
>>> big deal if we don't reach it?
>>>
>>
>> Let's see what PTLs have to say about planning, but I think if not
>> Ocata then we'd want to set one for the P release. We're running
>> out of supported lifetime for Python 2.7.
>>
>
> Keep in mind that there is interest in running OpenStack on PyPy which
> is python 2.7. We don't have to continue supporting CPython 2.7
> necessarily but we may want to support python 2.7 by way of PyPy.
>

 PyPy folks have been working on python 3 support for some time already:
 http://doc.pypy.org/en/latest/release-pypy3.3-v5.2-alpha1.html
 It's an alpha, but by the time we consider dropping Python 2 it will
 probably be released :)

>>>
>>> We're targeting Python >=3.4, right now.  We'll have to decide as
>>> a community whether PyPy support is a sufficient reason to keep
>>> support for "older" versions (either 2.x or earlier versions of 3).
>>> Before we can have that discussion, though, we need to actually run on
>>> Python 3, so let's focus on that and evaluate the landscape of other
>>> interpreters when the porting work is done.
>>>
>>
>> +1, please don't get ahead of things until there is real full stack
>> testing running on python3.
>>
>> It would also be good if some of our operators were running on python 3
>> and providing feedback that it works in the real world before we even
>> talk about dropping. Because our upstream testing (even the full stack
>> testing) only can catch so much.
>>
>> So next steps:
>>
>> 1) full stack testing of everything we've got on python3 - (are there
>> volunteers to get that going?)
>> 2) complete Nova port to enable full stack testing on python3 for iaas
>> base
>> 3) encourage operators to deploy with python3 in production
>> 4) gather real world feedback, develop rest of plan
>>
>
>
> Just one to +1 the above steps. I'd be very hesitant to make any plan
> until we
> are able to get not only nova but all the projects in the
> starter-kit:compute[0]
> running pn python3 (and w/ a full stack test).
>
> [0]
> https://governance.openstack.org/reference/tags/starter-kit_compute.html
>
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

[Jimmy McCrory]

+1, would make a great addition.

On Wed, Jul 13, 2016 at 12:47 PM, Carter, Kevin  wrote:

> +1 from me too. It'll be great to have him on the core team.
>
> On Tue, Jul 12, 2016 at 1:33 PM, Truman, Travis
>  wrote:
> > Jean-Philippe has been providing great code reviews and patches for some
> > time. His recent commitment to running bug triage every week shows his
> > willingness to step up and take responsibilities within the community.
> He’s
> > also found an opportunity to innovate by introducing an improved bug
> triage
> > process. He can often be found in #openstack-ansible as evrardjp
> providing
> > support to deployers in a welcoming and friendly manner.
> >
> > In short, just the kind of contribution our community desires from core
> > reviewers.
> >
> > Thanks for all that you do for the community Jean-Philippe,
> > Travis Truman
> >
> >
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] [designate] Designate News Round Up

[Hayes, Graham]

Hi All,

Just a quick update on a few things!

Mid Cycle
=

The Mid Cycle is confirmed for 22-26th of August.

It will be in Dublin, in the city center.

The address is

64 Mount Street Lower,
Dublin 2.
D02 TH77
Ireland

I will be updating the page on the wiki with local hotels
over the next day or so, so keep an eye on

https://wiki.openstack.org/wiki/Sprints/DesignateNewtonSprint

This is a shared office space, so we will need to let people in
as they arrive - my phone number is +353 87 377 8315

Docs Sprint
===

Today's docs sprint went well, we have a few reviews outstanding, so if
everyone could have a look at the following:

# https://review.openstack.org/#/c/341622/
# https://review.openstack.org/#/c/341614/
# https://review.openstack.org/#/c/341583/
# https://review.openstack.org/#/c/341672/


Project Mascot
==

The foundation has kindly offered to create mascots for each project.

Can everyone put ideas in the etherpad:

https://etherpad.openstack.org/p/designate-mascot

And if you see an idea you like, stick a "+" beside it.

We will take the top few ideas and pass them to the foundation.

Thanks!

- Graham

__
OpenStack Development Mailing 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-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

[Carter, Kevin]

+1 from me too. It'll be great to have him on the core team.

On Tue, Jul 12, 2016 at 1:33 PM, Truman, Travis
 wrote:
> Jean-Philippe has been providing great code reviews and patches for some
> time. His recent commitment to running bug triage every week shows his
> willingness to step up and take responsibilities within the community. He’s
> also found an opportunity to innovate by introducing an improved bug triage
> process. He can often be found in #openstack-ansible as evrardjp providing
> support to deployers in a welcoming and friendly manner.
>
> In short, just the kind of contribution our community desires from core
> reviewers.
>
> Thanks for all that you do for the community Jean-Philippe,
> Travis Truman
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

[Steve Lewis]

On Tue, Jul 12, 2016 at 11:33 AM, Truman, Travis 
wrote:

> In short, just the kind of contribution our community desires from core
> reviewers.
>

I'm happy to add my +1.

-- 
SteveL
__
OpenStack Development Mailing 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-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

[Jesse Pretorius]

From: "Truman, Travis" 
>
Subject: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe Evrard 
for core in openstack-ansible and all openstack-ansible-* roles

Jean-Philippe has been providing great code reviews and patches for some time. 
His recent commitment to running bug triage every week shows his willingness to 
step up and take responsibilities within the community. He’s also found an 
opportunity to innovate by introducing an improved bug triage process. He can 
often be found in #openstack-ansible as evrardjp providing support to deployers 
in a welcoming and friendly manner.

In short, just the kind of contribution our community desires from core 
reviewers.

Very much agreed. +1 from me!


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

[openstack-dev] [app-catalog] App Catalog IRC meeting Thursday July 14th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for July 14th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about our plan to implement GLARE as
a back-end for the Community App Catalog, and what we'll need to merge
in the next few weeks to make this a reality.

Hope to see you there tomorrow!

__
OpenStack Development Mailing 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] [new][oslo] mox3 0.17.0 release (newton)

[Jeremy Stanley]

On 2016-07-13 17:10:20 +0200 (+0200), Markus Zoeller wrote:
> Whoever chooses the wording in these announcements, you're a genius!

You too can be a genius--add some more--there's only ~20 at the
moment so they repeat pretty often:

http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py?id=da89264#n33
 >
-- 
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] [all][oslo] pbr potential breaking change coming

[Jeremy Stanley]

On 2016-07-13 13:25:44 +0200 (+0200), Markus Zoeller wrote:
> For some reason the gate docs job didn't find the issue (wrong json
> format) which got fixed with change [1]. It doesn't even emit a warning.
> Locally, the execution of "tox -e docs" does find the issue. Can we make
> the gate docs job aware of such json format issues?
[...]

It looks like your "docs" tox env is doing some additional checks[1]
with the json.tool module. The gate-{name}-docs CI jobs don't call
`tox -e docs` but `tox -evenv -- python setup.py build_sphinx`
directly[2]. Changing that has been discussed[3][4] (and
rejected/withdrawn) by the TC in the past.

I agree with Andreas that if you want additional checking of this
you probably need it in a different job. The same goes for tests of
your config/policy generation and API guide/reference builds. The
goal of gate-{name}-docs is to make sure that the setup.py
build_sphinx entrypoint works across all covered projects (per the
CTI[5]) without requiring any extra nonstandard magic.

[1] http://git.openstack.org/cgit/openstack/nova/tree/tox.ini?id=df0aa8a#n97
[2] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh
[3] 
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-30-20.01.log.html#l-27
[4] https://review.openstack.org/119875
[5] http://governance.openstack.org/reference/cti/python_cti.html#documentation
-- 
Jeremy Stanley

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

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Jeremy Stanley]

On 2016-07-13 13:35:18 +0200 (+0200), Markus Zoeller wrote:
[...]
> it cannot be used in "gerrty" though, or can it?
[...]

It's probably one or two more lines of code to also print the Gerrit
query such that it could be pasted into Gertty ^O (or make use of
`gertty --open` to trigger opening that query URL directly into a
running Gertty session?).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Jeremy Stanley]

On 2016-07-13 09:56:37 +0200 (+0200), Sahid Orentino Ferdjaoui wrote:
[...]
> Gerrit comments are lost when the patch get merged, we may want to
> provide some stats from these tags in future that's why I think commit
> message is better.

It's not true at all that Gerrit comments are lost when the patch
gets merged. You can continue to query comments in Gerrit for merged
changes, or even selectively limit to, e.g., status:merged or
status:abandoned or whatever when generating your stats.

> Also if we only change commit messages, all of the gate is
> re-executed ?
[...]

It depends on your project configuration in Gerrit and Zuul as to
whether votes are reset and which jobs are (re)run. We're also
hoping to be able to detect commit message edits explicitly in a
future version of Zuul and be able to have specific handling for
that too (right now you're limited to deciding which jobs run based
on filename patterns appearing in the diff instead).
-- 
Jeremy Stanley

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

Re: [openstack-dev] The future of OpenStack documentation

[Doug Hellmann]

Excerpts from Matt Kassawara's message of 2016-07-13 09:52:45 -0600:
> The configuration reference essentially uses a script to parse help strings
> from code in project repositories. Occasionally, the documentation team
> augments content beyond what the automation provides. However, these
> content augmentations, the script, and schedule for running the script
> belong to the documentation team. Moving control of these items to projects
> would likely yield a more robust configuration reference, particularly
> regarding nuances of each project.

oslo.config already includes support for showing option values in
sphinx-processed documentation. See
http://docs.openstack.org/developer/oslo.config/sphinxext.html for
instructions on the directives, and
http://docs.openstack.org/developer/oslo.messaging/opts.html for an
example of what it looks like rendered into HTML. You could experiment
with this the existing developer documentation and if project teams
agree it makes sense we could start setting up a separate reference
guide in each repo.

OTOH, sometimes configuring an application actually requires dealing
with a deliverable that is spread across multiple repositories.
Which is why at the summit we discussed updating the config generator
to produce a format that is easier to parse (YAML, probably) and
then use those files to produce the central config reference guide
(or multiple guides).  With a periodic job to propose patches to
the guide repo, it could stay very close to up to date more or less
automatically. Some of the other things I've been doing this cycle
have delayed me starting on this, but I'm happy to share my ideas
in more detail with anyone who wants to pick it up and work on it.

> Speaking of help strings, I see a conflict between providing sufficient
> content and preventing bloat of example configuration files. At the last
> summit, I suggested implementing two types of help strings... one long and
> one short. The configuration reference pulls the long string and the
> configuration file generator pulls the short string. If this idea makes
> sense, moving the configuration reference to project repositories would
> potentially enable each project to implement such changes at its own pace.
> 
> On Wed, Jul 13, 2016 at 8:11 AM, Markus Zoeller  > wrote:
> 
> > On 11.07.2016 00:02, Steve Martinelli wrote:
> > > I personally like this solution, it seems much more scalable. This
> > follows
> > > the same pattern of the API docs (moving the content to project repos),
> > > which puts the onus back on the project team to maintain and create
> > > documentation. I'm also hoping this results in less duplication between
> > the
> > > guides and the keystone developer docs (the latter of which start to
> > stray
> > > from "developer" docs and begin to look like "user" docs.
> >
> > After reading this, the "configuration reference" comes to my mind.
> > Having the api-ref and the config-ref at one place, near the code, seems
> > logical to me. Nova put a lot of effort into providing valuable help
> > text for the config options in the last months. We should also make sure
> > that it will result in a good manual, which could be easier if it's
> > in-tree, near the code.
> >
> > --
> > Regards, Markus Zoeller (markus_z)
> >
> > > The folks that contribute to the keystone guides today would still be
> > very
> > > welcomed to continue to contribute once/if the switch is made.
> > >
> > > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara 
> > wrote:
> > >
> > >> Currently, OpenStack provides central documentation (primarily in the
> > >> openstack-manuals repository) for operators and users. The single
> > location
> > >> and consistent structure eases audiences of various technical expertise
> > >> into OpenStack, typically operators and users rather than developers.
> > >> Although I'm not a fan of the word "product", increasingly less
> > technical
> > >> audiences are learning about OpenStack and tend to compare it with other
> > >> cloud infrastructure products. Such audiences expect a coherent,
> > relatively
> > >> mature product to easily evaluate, usually via proof-of-concept. Upon
> > >> deciding to implement OpenStack, the central documentation attempts to
> > >> gracefully lead them toward a production deployment that meets or
> > exceeds
> > >> requirements and expectations.
> > >>
> > >> However, since I began contributing to OpenStack documentation around
> > the
> > >> Havana release, I am seeing many projects, particularly core projects,
> > >> trending toward more independence from other projects including central
> > >> documentation. For operator and user documentation, a couple of projects
> > >> contribute to the central documentation repository, some projects
> > >> contribute to their own repositories, and an alarmingly large number of
> > >> projects simply do not contribute such documentation and assume that all
> > >> 

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Ricardo Carrillo Cruz]

I concur, in infra we install roles from git repos.
Those are defined in a yaml that are then feeded to ansible-galaxy tool:

http://git.openstack.org/cgit/openstack-infra/system-config/tree/roles.yaml

Regards

2016-07-13 17:58 GMT+02:00 David Moreau Simard :

> On Wed, Jul 13, 2016 at 9:06 AM, Wesley Hayutin 
> wrote:
> > We also considered ansible-galaxy and any of the ansible roles found in
> > github/redhat-openstack/ansible-role could be moved into galaxy.  Galaxy
> did
> > not end up meeting our requirements for installing the roles and we
> ended up
> > using python setuptools.  Some roles have specific config and playbooks
> that
> > need to be copied to a standard location and galaxy just did not do that
> > very well.
>
> What special requirements do you have around that ?
> I'm able to install roles both from git (zuul-cloner) and from
> ansible-galaxy just fine.
>
> - ansible-role-requirements.yml [1]
> - ansible-galaxy install [2]
> - ansible.cfg role path [3]
>
> Stuff doesn't necessarily need to be "uploaded" to galaxy.
> ansible-galaxy is really a glorified wrapper around git :)
>
> [1]:
> https://github.com/rdo-infra/weirdo/blob/master/ansible-role-requirements.yml
> [2]: https://github.com/rdo-infra/weirdo/blob/master/tox.ini#L26
> [3]:
> https://github.com/rdo-infra/weirdo/blob/master/playbooks/ansible.cfg#L9
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[David Moreau Simard]

On Wed, Jul 13, 2016 at 9:06 AM, Wesley Hayutin  wrote:
> We also considered ansible-galaxy and any of the ansible roles found in
> github/redhat-openstack/ansible-role could be moved into galaxy.  Galaxy did
> not end up meeting our requirements for installing the roles and we ended up
> using python setuptools.  Some roles have specific config and playbooks that
> need to be copied to a standard location and galaxy just did not do that
> very well.

What special requirements do you have around that ?
I'm able to install roles both from git (zuul-cloner) and from
ansible-galaxy just fine.

- ansible-role-requirements.yml [1]
- ansible-galaxy install [2]
- ansible.cfg role path [3]

Stuff doesn't necessarily need to be "uploaded" to galaxy.
ansible-galaxy is really a glorified wrapper around git :)

[1]: 
https://github.com/rdo-infra/weirdo/blob/master/ansible-role-requirements.yml
[2]: https://github.com/rdo-infra/weirdo/blob/master/tox.ini#L26
[3]: https://github.com/rdo-infra/weirdo/blob/master/playbooks/ansible.cfg#L9

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] The future of OpenStack documentation

[Matt Kassawara]

The configuration reference essentially uses a script to parse help strings
from code in project repositories. Occasionally, the documentation team
augments content beyond what the automation provides. However, these
content augmentations, the script, and schedule for running the script
belong to the documentation team. Moving control of these items to projects
would likely yield a more robust configuration reference, particularly
regarding nuances of each project.

Speaking of help strings, I see a conflict between providing sufficient
content and preventing bloat of example configuration files. At the last
summit, I suggested implementing two types of help strings... one long and
one short. The configuration reference pulls the long string and the
configuration file generator pulls the short string. If this idea makes
sense, moving the configuration reference to project repositories would
potentially enable each project to implement such changes at its own pace.

On Wed, Jul 13, 2016 at 8:11 AM, Markus Zoeller  wrote:

> On 11.07.2016 00:02, Steve Martinelli wrote:
> > I personally like this solution, it seems much more scalable. This
> follows
> > the same pattern of the API docs (moving the content to project repos),
> > which puts the onus back on the project team to maintain and create
> > documentation. I'm also hoping this results in less duplication between
> the
> > guides and the keystone developer docs (the latter of which start to
> stray
> > from "developer" docs and begin to look like "user" docs.
>
> After reading this, the "configuration reference" comes to my mind.
> Having the api-ref and the config-ref at one place, near the code, seems
> logical to me. Nova put a lot of effort into providing valuable help
> text for the config options in the last months. We should also make sure
> that it will result in a good manual, which could be easier if it's
> in-tree, near the code.
>
> --
> Regards, Markus Zoeller (markus_z)
>
> > The folks that contribute to the keystone guides today would still be
> very
> > welcomed to continue to contribute once/if the switch is made.
> >
> > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara 
> wrote:
> >
> >> Currently, OpenStack provides central documentation (primarily in the
> >> openstack-manuals repository) for operators and users. The single
> location
> >> and consistent structure eases audiences of various technical expertise
> >> into OpenStack, typically operators and users rather than developers.
> >> Although I'm not a fan of the word "product", increasingly less
> technical
> >> audiences are learning about OpenStack and tend to compare it with other
> >> cloud infrastructure products. Such audiences expect a coherent,
> relatively
> >> mature product to easily evaluate, usually via proof-of-concept. Upon
> >> deciding to implement OpenStack, the central documentation attempts to
> >> gracefully lead them toward a production deployment that meets or
> exceeds
> >> requirements and expectations.
> >>
> >> However, since I began contributing to OpenStack documentation around
> the
> >> Havana release, I am seeing many projects, particularly core projects,
> >> trending toward more independence from other projects including central
> >> documentation. For operator and user documentation, a couple of projects
> >> contribute to the central documentation repository, some projects
> >> contribute to their own repositories, and an alarmingly large number of
> >> projects simply do not contribute such documentation and assume that all
> >> audiences involve developers. These differences lead to an increasingly
> >> negative overall experience for the audiences that OpenStack needs to
> >> increase adoption/growth and maintain the existing deployment base.
> >>
> >> As a contributor to central documentation and one or more other projects
> >> including neutron, I see the problems from both sides and don't
> >> particularly blame either party for them. Some politics, some technical,
> >> some a lack of resources, and some just a general misunderstanding about
> >> documentation. However, I think we need to develop a solution that works
> >> for both parties and ultimately benefits our audiences.
> >>
> >> One potential solution essentially involves moving operator and user
> >> documentation into project repositories (similar to developer
> >> documentation) and using infrastructure to coherently present it on
> >> docs.openstack.org which achieves the following goals:
> >>
> >> 1) Project developers can contribute documentation and code in the same
> >> patch, thus avoiding two different review queues and reviewers with
> >> different motivations and guidelines.
> >> 2) Project developers can either work directly or via liaison with one
> or
> >> more documentation team members to improve documentation components
> during
> >> development or after merging technically accurate content.
> >> 3) Rather 

Re: [openstack-dev] [new][oslo] mox3 0.17.0 release (newton)

[Markus Zoeller]

On 13.07.2016 16:01, no-re...@openstack.org wrote:
> We are tickled pink to announce the release of:
> 

Whoever chooses the wording in these announcements, you're a genius!


-- 
Regards, Markus Zoeller (markus_z)

> mox3 0.17.0: Mock object framework for Python
> 
> This release is part of the newton release series.
> 
> With source available at:
> 
> http://git.openstack.org/cgit/openstack/mox3
> 
> With package available at:
> 
> https://pypi.python.org/pypi/mox3
> 
> Please report issues through launchpad:
> 
> http://bugs.launchpad.net/python-mox3
> 
> For more details, please see below.
> 
> Changes in mox3 0.16.0..0.17.0
> --
> 
> 2b58961 Updated from global requirements
> 
> 
> Diffstat (except docs and test files)
> -
> 
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> Requirements updates
> 
> 
> diff --git a/test-requirements.txt b/test-requirements.txt
> index ad30fa2..df05b72 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -20 +20 @@ six>=1.9.0 # MIT
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> 
> 
> 
> __
> OpenStack Development Mailing 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] [release][ptl][all] newton-2 milestone deadline 14 July

[Doug Hellmann]

PTLs and release liaisons, please remember that 14 July is the
deadline for proposing your second milestone tags for deliverables
using the cycle-with-milestone release model during newton. Milestones
are date-based, so if missing the deadline means missing the
milestone.

Doug

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

[openstack-dev] [new][oslo] oslotest 2.7.0 release (newton)

[no-reply]

We are pleased to announce the release of:

oslotest 2.7.0: Oslo test framework

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/oslotest

Please report issues through launchpad:

http://bugs.launchpad.net/oslotest

For more details, please see below.

Changes in oslotest 2.6.0..2.7.0


a0eb134 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index bfdb9ba..cecb61e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13 +13 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] stevedore 1.16.0 release (newton)

[no-reply]

We are overjoyed to announce the release of:

stevedore 1.16.0: Manage dynamic plugins for Python applications

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/stevedore

Please report issues through launchpad:

https://bugs.launchpad.net/python-stevedore

For more details, please see below.

Changes in stevedore 1.15.0..1.16.0
---

1218ab6 Fix NamedExtensionManager fails when loading failing extension in order
da83cd8 Remove irrelated output item
e3d08ce Fix broken link about setuptools entry points
6f81f6f NamedExtensionManager: call a callback when some names cannot be found
f33b810 Updated from global requirements


Diffstat (except docs and test files)
-

README.rst   |  2 +-
stevedore/named.py   | 20 +++-
test-requirements.txt|  2 +-
6 files changed, 62 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index d59feb9..977194a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@ Pillow>=2.4.0 # PIL License
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] oslosphinx 4.6.0 release (newton)

[no-reply]

We are jubilant to announce the release of:

oslosphinx 4.6.0: OpenStack Sphinx Extensions and Theme

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/oslosphinx

Please report issues through launchpad:

http://bugs.launchpad.net/oslosphinx

For more details, please see below.

Changes in oslosphinx 4.5.0..4.6.0
--

e2ded8e Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 506a68b..3ee4d7d 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ hacking<0.11,>=0.10.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] taskflow 2.3.0 release (newton)

[no-reply]

We are jazzed to announce the release of:

taskflow 2.3.0: Taskflow structured state management library.

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/taskflow

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

For more details, please see below.

Changes in taskflow 2.2.0..2.3.0


0b198de Updated from global requirements
185830b remove unused LOG
6ca905c Fixes: typo error in comments
ec99a02 Updated from global requirements
7422194 Fix some misspellings in the function name and descriptions
21aa375 Updated from global requirements
599b270 Add tests to verify kwargs behavior on revert validation
6e21e31 Make tests less dependent on transient state
0766397 Use the full 'get_execute_failures' vs the shortname


Diffstat (except docs and test files)
-

requirements.txt   |  2 +-
taskflow/engines/action_engine/actions/retry.py|  3 -
taskflow/engines/action_engine/compiler.py |  8 +--
taskflow/engines/action_engine/engine.py   | 12 ++--
taskflow/engines/action_engine/executor.py |  3 -
taskflow/engines/action_engine/process_executor.py |  2 +-
taskflow/engines/base.py   |  2 +-
taskflow/examples/99_bottles.py|  2 +-
taskflow/jobs/backends/impl_zookeeper.py   |  2 +-
taskflow/jobs/base.py  |  2 +-
taskflow/patterns/graph_flow.py|  2 +-
taskflow/persistence/backends/impl_memory.py   |  2 +-
taskflow/persistence/models.py |  3 -
taskflow/storage.py|  2 +-
taskflow/types/failure.py  |  8 +--
taskflow/types/notifier.py |  4 +-
taskflow/types/tree.py |  2 +-
test-requirements.txt  |  2 +-
22 files changed, 73 insertions(+), 65 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index af3db31..73819aa 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -44 +44 @@ automaton>=0.5.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index e57fda1..6606911 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -38 +38 @@ eventlet!=0.18.3,>=0.18.2 # MIT
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] tooz 1.41.0 release (newton)

[no-reply]

We are jazzed to announce the release of:

tooz 1.41.0: Coordination library for distributed systems.

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/tooz

Please report issues through launchpad:

http://bugs.launchpad.net/python-tooz/

For more details, please see below.

Changes in tooz 1.40.0..1.41.0
--

3541e7c File driver: properly handle Windows paths
6716456 Updated from global requirements
7ea400a Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt|  2 +-
setup.cfg   | 46 +++--
tooz/drivers/file.py| 17 +-
4 files changed, 85 insertions(+), 30 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 826db66..a9cecef 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ futurist>=0.11.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.14.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

[openstack-dev] [new][oslo] oslo.vmware 2.11.0 release (newton)

[no-reply]

We are delighted to announce the release of:

oslo.vmware 2.11.0: Oslo VMware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.vmware

With package available at:

https://pypi.python.org/pypi/oslo.vmware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.vmware

For more details, please see below.

Changes in oslo.vmware 2.10.0..2.11.0
-

421b41c Updated from global requirements
04ad3d8 Add a py35 tox venv for upcoming py35 support
7b04a56 Updated from global requirements
c202eff Remove unnecessary properties from image-meta
029bc0a Updated from global requirements
a4a74ab Updated from global requirements


Diffstat (except docs and test files)
-

oslo_vmware/image_transfer.py| 8 +---
requirements.txt | 4 ++--
setup.cfg| 1 +
test-requirements.txt| 2 +-
tox.ini  | 2 +-
6 files changed, 14 insertions(+), 10 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index c952316..4f4f3a6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
@@ -18 +18 @@ lxml>=2.3 # BSD
-suds-jurko>=0.6 # LGPL
+suds-jurko>=0.6 # LGPLv3+
diff --git a/test-requirements.txt b/test-requirements.txt
index a40ffab..b8c2e46 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -25 +25 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-reno>=1.6.2 # Apache2
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] oslo.reports 1.12.0 release (newton)

[no-reply]

We are eager to announce the release of:

oslo.reports 1.12.0: oslo.reports library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.reports

With package available at:

https://pypi.python.org/pypi/oslo.reports

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.reports

For more details, please see below.

Changes in oslo.reports 1.11.0..1.12.0
--

4b37e30 Updated from global requirements
96fa66c Updated from global requirements
30cfeab Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt  | 2 +-
test-requirements.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 62f078c..67f73ae 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index ff73ef3..a180841 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
@@ -13 +13 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.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

[openstack-dev] [new][oslo] oslo.rootwrap 4.4.0 release (newton)

[no-reply]

We are gleeful to announce the release of:

oslo.rootwrap 4.4.0: Oslo Rootwrap

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.rootwrap

With package available at:

https://pypi.python.org/pypi/oslo.rootwrap

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.rootwrap

For more details, please see below.

Changes in oslo.rootwrap 4.3.0..4.4.0
-

3a70d2e Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index e4b24c3..65bf3d1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ testtools>=1.4.0 # MIT
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] oslo.service 1.13.0 release (newton)

[no-reply]

We are eager to announce the release of:

oslo.service 1.13.0: oslo.service library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.service

With package available at:

https://pypi.python.org/pypi/oslo.service

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.service

For more details, please see below.

Changes in oslo.service 1.12.0..1.13.0
--

3f39b9b Updated from global requirements
6421273 Updated from global requirements
84b53e6 Updated from global requirements
e7317d7 Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt  | 4 ++--
test-requirements.txt | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 87352e2..83d22d4 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ monotonic>=0.6 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
@@ -11 +11 @@ oslo.concurrency>=3.8.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d0b8e20..de31b9a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] oslo.policy 1.12.0 release (newton)

[no-reply]

We are jazzed to announce the release of:

oslo.policy 1.12.0: Oslo Policy library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.policy

With package available at:

https://pypi.python.org/pypi/oslo.policy

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.policy

For more details, please see below.

Changes in oslo.policy 1.11.0..1.12.0
-

cbb0824 Updated from global requirements
d0d39a4 Updated from global requirements
202340c Fix mispelled method name in setup.cfg
a7a51bc Updated from global requirements
7e114b6 Updated from global requirements
123c155 Imported Translations from Zanata


Diffstat (except docs and test files)
-

releasenotes/source/locale/en_GB/LC_MESSAGES/releasenotes.po | 9 ++---
requirements.txt | 4 ++--
setup.cfg| 2 +-
test-requirements.txt| 4 ++--
4 files changed, 11 insertions(+), 8 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7204ac2..09e1525 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ requests>=2.10.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
@@ -9 +9 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index f4844ab..eb9c954 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +7 @@ oslotest>=1.10.0 # Apache-2.0
-requests-mock>=0.7.0 # Apache-2.0
+requests-mock>=1.0 # Apache-2.0
@@ -16 +16 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-reno>=1.6.2 # Apache2
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] oslo.serialization 2.11.0 release (newton)

[no-reply]

We are glad to announce the release of:

oslo.serialization 2.11.0: Oslo Serialization library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.serialization

With package available at:

https://pypi.python.org/pypi/oslo.serialization

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.serialization

For more details, please see below.

Changes in oslo.serialization 2.10.0..2.11.0


7ad9a95 Updated from global requirements
5ee90fc Updated from global requirements
1ec85e9 Use {} instead of dict()


Diffstat (except docs and test files)
-

oslo_serialization/jsonutils.py | 4 ++--
requirements.txt| 2 +-
test-requirements.txt   | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 6872a60..54901dd 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -13 +13 @@ msgpack-python>=0.4.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 0a065c6..0a0d3bf 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ netaddr!=0.7.16,>=0.7.12 # BSD
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] oslo.versionedobjects 1.13.0 release (newton)

[no-reply]

We are glad to announce the release of:

oslo.versionedobjects 1.13.0: Oslo Versioned Objects library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.versionedobjects

With package available at:

https://pypi.python.org/pypi/oslo.versionedobjects

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.versionedobjects

For more details, please see below.

Changes in oslo.versionedobjects 1.12.0..1.13.0
---

b6410fe Updated from global requirements
c6eaf00 Imported Translations from Zanata
e80ab96 JSON schema get_schema implementation for common fields
cf2838f Updated from global requirements
92e7ac7 JSON schema generation for versioned objects
cf28125 Extend test_hashes to allow extra info gathering
f5fdfc2 Updated from global requirements
238fd19 Improved error message for Object.coerce
1500618 Imported Translations from Zanata


Diffstat (except docs and test files)
-

oslo_versionedobjects/base.py  | 44 ++
oslo_versionedobjects/fields.py| 42 +-
oslo_versionedobjects/fixture.py   |  4 +-
.../LC_MESSAGES/oslo_versionedobjects-log-error.po | 18 --
.../LC_MESSAGES/oslo_versionedobjects-log-error.po | 18 --
requirements.txt   |  4 +-
test-requirements.txt  |  2 +-
10 files changed, 255 insertions(+), 15 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 52bdb85..7813946 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ oslo.concurrency>=3.8.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
@@ -10 +10 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 64d87df..b30d301 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] oslo.privsep 1.10.0 release (newton)

[no-reply]

We are content to announce the release of:

oslo.privsep 1.10.0: OpenStack library for privilege separation

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.privsep

With package available at:

https://pypi.python.org/pypi/oslo.privsep

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.privsep

For more details, please see below.

Changes in oslo.privsep 1.9.0..1.10.0
-

e46eebf Updated from global requirements
b5e1c13 Updated from global requirements
021c911 Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt  | 4 ++--
test-requirements.txt | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e77185a..1397b11 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,2 +7,2 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 634e4c1..b3deaba 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



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

Re: [openstack-dev] The future of OpenStack documentation

[Markus Zoeller]

On 11.07.2016 00:02, Steve Martinelli wrote:
> I personally like this solution, it seems much more scalable. This follows
> the same pattern of the API docs (moving the content to project repos),
> which puts the onus back on the project team to maintain and create
> documentation. I'm also hoping this results in less duplication between the
> guides and the keystone developer docs (the latter of which start to stray
> from "developer" docs and begin to look like "user" docs.

After reading this, the "configuration reference" comes to my mind.
Having the api-ref and the config-ref at one place, near the code, seems
logical to me. Nova put a lot of effort into providing valuable help
text for the config options in the last months. We should also make sure
that it will result in a good manual, which could be easier if it's
in-tree, near the code.

-- 
Regards, Markus Zoeller (markus_z)

> The folks that contribute to the keystone guides today would still be very
> welcomed to continue to contribute once/if the switch is made.
> 
> On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara  wrote:
> 
>> Currently, OpenStack provides central documentation (primarily in the
>> openstack-manuals repository) for operators and users. The single location
>> and consistent structure eases audiences of various technical expertise
>> into OpenStack, typically operators and users rather than developers.
>> Although I'm not a fan of the word "product", increasingly less technical
>> audiences are learning about OpenStack and tend to compare it with other
>> cloud infrastructure products. Such audiences expect a coherent, relatively
>> mature product to easily evaluate, usually via proof-of-concept. Upon
>> deciding to implement OpenStack, the central documentation attempts to
>> gracefully lead them toward a production deployment that meets or exceeds
>> requirements and expectations.
>>
>> However, since I began contributing to OpenStack documentation around the
>> Havana release, I am seeing many projects, particularly core projects,
>> trending toward more independence from other projects including central
>> documentation. For operator and user documentation, a couple of projects
>> contribute to the central documentation repository, some projects
>> contribute to their own repositories, and an alarmingly large number of
>> projects simply do not contribute such documentation and assume that all
>> audiences involve developers. These differences lead to an increasingly
>> negative overall experience for the audiences that OpenStack needs to
>> increase adoption/growth and maintain the existing deployment base.
>>
>> As a contributor to central documentation and one or more other projects
>> including neutron, I see the problems from both sides and don't
>> particularly blame either party for them. Some politics, some technical,
>> some a lack of resources, and some just a general misunderstanding about
>> documentation. However, I think we need to develop a solution that works
>> for both parties and ultimately benefits our audiences.
>>
>> One potential solution essentially involves moving operator and user
>> documentation into project repositories (similar to developer
>> documentation) and using infrastructure to coherently present it on
>> docs.openstack.org which achieves the following goals:
>>
>> 1) Project developers can contribute documentation and code in the same
>> patch, thus avoiding two different review queues and reviewers with
>> different motivations and guidelines.
>> 2) Project developers can either work directly or via liaison with one or
>> more documentation team members to improve documentation components during
>> development or after merging technically accurate content.
>> 3) Rather than attempting to document all projects with little (if any)
>> assistance from those projects, the primary role of the documentation team
>> becomes managing overall organization/presentation of documentation and
>> assisting projects with their contributions.
>>
>> We're seeing decent adoption of moving API documentation into project
>> repositories, so I want to initiate some discussion about moving additional
>> documentation (or other options) prior to mid-cycles (including ops) and
>> the next summit.
>>
>> Matt
>>
>> __
>> OpenStack Development Mailing 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 

[openstack-dev] [new][oslo] oslo.db 4.8.0 release (newton)

[no-reply]

We are satisfied to announce the release of:

oslo.db 4.8.0: Oslo Database library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.db

With package available at:

https://pypi.python.org/pypi/oslo.db

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.db

For more details, please see below.

4.8.0
^


New Features


* enginefacade decorators can now be used for class and instance
  methods, which implicitly receive the first positional argument.
  Previously, it was required that all decorated functions receive a
  context value as the first argument.


Deprecation Notes
*

* The configuration option "sqlite_db" is now deprecated and will be
  removed in the future. Please use configuration option "connection"
  or "slave_connection" to connect to the database.

Changes in oslo.db 4.6.0..4.8.0
---

fc3c23a Updated from global requirements
462296b Add support for LONGTEXT, MEDIUMTEXT to JsonEncodedType
0a1bae9 Deprecate config option sqlite_db for removal
16886e5 Catch empty value DBDuplicate errors
1d7e7e4 Updated from global requirements
8e3b356 api: use sane default in wrap_db_retry()
21491e1 Imported Translations from Zanata
e59c2b5 exc_filters: catch and translate non existent table on drop
e0db469 exception: make message mandatory in DbMigrationError and deprecates it
8a5fbb7 Make it possible to use enginefacade decorators with class methods
ef97c25 Updated from global requirements
4c82261 tests: fix order of assertEqual in exc_filter
c4f025d exc_filters: catch and translate non existent constraint on drop
1579c7c Replace tempest-lib dependency with os-testr
b8ffab6 Imported Translations from Zanata
a2da070 Fix typos in comments and docstring
c0005aa Updated from global requirements
9b9170f Updated from global requirements
a71fe96 Fix typo: 'olso' to 'oslo'
34a3da3 Repair boolean CHECK constraint detection
2938f28 api: do not log a traceback if error is not expected
e351f44 Fix imports in doc
044cf85 Allow testing of MySQL and PostgreSQL scenario locally
4bbadac Add support for custom JSON serializer
663092d api: always enable retry_on_request
7574ab7 Remove oslo-incubator related stuff
3ac4f3f Updated from global requirements
268987f Updated from global requirements
4afa0ce Remove direct dependency on babel
976bcdf Imported Translations from Zanata
3816739 Add debtcollector to requirements
30f061d Fix unit tests failures, when psycopg2 is not installed
f5a8fb3 Fix server_default comparison for BigInteger
c9e0bcd Remove unused sqlite_fk in _init_connection_args call
531ed45 Updated from global requirements
59b845d Correct docstring
46767e5 Updated from global requirements
b283e7d Updated from global requirements
419a42f Updated from global requirements
af0b3d3 Updated from global requirements
b45a20b Updated from global requirements
08f4911 Raise DbMigrationError for invalid version
b1de3f7 Add new filter for DBDataError exception
4048c8f Fix spelling mistake
f98cb90 Let enginefacade._TransactionContextManager look for context
09c531b Remove  sqlalchemy < 1.0.0 compatible layer
045a6fb Update reno for stable/mitaka
6c9cc58 Updated from global requirements
e9cbc6e Add tests for float interval values in wrap_db_retry()


Diffstat (except docs and test files)
-

CONTRIBUTING.rst   |  27 ++
oslo_db/api.py |  34 +-
oslo_db/exception.py   |  41 +++
.../locale/en_GB/LC_MESSAGES/oslo_db-log-error.po  |  11 +-
.../locale/en_GB/LC_MESSAGES/oslo_db-log-info.po   |   8 +-
.../en_GB/LC_MESSAGES/oslo_db-log-warning.po   |   8 +-
oslo_db/locale/en_GB/LC_MESSAGES/oslo_db.po|  17 +-
oslo_db/locale/es/LC_MESSAGES/oslo_db-log-error.po |  11 +-
oslo_db/locale/es/LC_MESSAGES/oslo_db-log-info.po  |   8 +-
.../locale/es/LC_MESSAGES/oslo_db-log-warning.po   |   8 +-
oslo_db/locale/es/LC_MESSAGES/oslo_db.po   |  11 +-
oslo_db/locale/fr/LC_MESSAGES/oslo_db-log-error.po |  11 +-
oslo_db/locale/fr/LC_MESSAGES/oslo_db-log-info.po  |   8 +-
.../locale/fr/LC_MESSAGES/oslo_db-log-warning.po   |   8 +-
oslo_db/locale/fr/LC_MESSAGES/oslo_db.po   |  11 +-
oslo_db/locale/oslo_db-log-error.pot   |  51 ---
oslo_db/locale/oslo_db-log-info.pot|  29 --
oslo_db/locale/oslo_db-log-warning.pot |  44 ---
oslo_db/locale/oslo_db.pot |  83 -
oslo_db/options.py |   3 +
oslo_db/sqlalchemy/compat/__init__.py  |  25 --
oslo_db/sqlalchemy/compat/handle_error.py  | 341 -
oslo_db/sqlalchemy/enginefacade.py |  16 +-
oslo_db/sqlalchemy/engines.py  |  11 +-
oslo_db/sqlalchemy/exc_filters.py  |  50 ++-
oslo_db/sqlalchemy/migration.py  

[openstack-dev] [new][oslo] oslo.log 3.12.0 release (newton)

[no-reply]

We are thrilled to announce the release of:

oslo.log 3.12.0: oslo.log library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.log

With package available at:

https://pypi.python.org/pypi/oslo.log

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.log

For more details, please see below.

3.12.0
^^

New Features

* The log_config_append configuration option is now mutable and the
  logging settings it controls are reconfigured when the configuration
  file is reread. This can be used to, for example, change logger or
  handler levels.

Changes in oslo.log 3.11.0..3.12.0
--

c426a42 Replace "LOG.exception(_" with "LOG.exception(_LE"
5082d92 Updated from global requirements
8fde280 Reload log_config_append config on SIGHUP
e4c651b Imported Translations from Zanata
e3bd7e6 Updated from global requirements
fc490c0 log: Introduce _iter_loggers
15ef585 Imported Translations from Zanata
1bea3a5 Updated from global requirements
68bde95 Updated from global requirements


Diffstat (except docs and test files)
-

oslo_log/_options.py   |   1 +
oslo_log/locale/de/LC_MESSAGES/oslo_log.po |  60 +
oslo_log/locale/en_GB/LC_MESSAGES/oslo_log.po  |  55 
oslo_log/locale/oslo_log.pot   |  63 -
oslo_log/log.py|  38 ++-
.../notes/reload_log_config-743817192b1172b6.yaml  |   5 +
.../locale/en_GB/LC_MESSAGES/releasenotes.po   |  63 +
requirements.txt   |   4 +-
test-requirements.txt  |   4 +-
11 files changed, 488 insertions(+), 105 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 26c3390..9bac65f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ six>=1.9.0 # MIT
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
@@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c2d83c8..4c9bc0c 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -21 +21 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
@@ -23 +23 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-reno>=1.6.2 # Apache2
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] oslo.concurrency 3.12.0 release (newton)

[no-reply]

We are chuffed to announce the release of:

oslo.concurrency 3.12.0: Oslo Concurrency library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.concurrency

With package available at:

https://pypi.python.org/pypi/oslo.concurrency

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.concurrency

For more details, please see below.

Changes in oslo.concurrency 3.11.0..3.12.0
--

f7821d9 Updated from global requirements
68df6b2 Imported Translations from Zanata
f13a21c Updated from global requirements


Diffstat (except docs and test files)
-

.../locale/en_GB/LC_MESSAGES/releasenotes.po   | 30 ++
requirements.txt   |  4 +--
test-requirements.txt  |  4 +--
3 files changed, 34 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 51b3c76..864afc1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ iso8601>=0.1.11 # MIT
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
@@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 8418f39..e431107 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13,2 +13,2 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-reno>=1.6.2 # Apache2
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] oslo.i18n 3.8.0 release (newton)

[no-reply]

We are overjoyed to announce the release of:

oslo.i18n 3.8.0: Oslo i18n library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.i18n

With package available at:

https://pypi.python.org/pypi/oslo.i18n

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.i18n

For more details, please see below.

Changes in oslo.i18n 3.7.0..3.8.0
-

16f40a6 Updated from global requirements
6bc0cfc Don't include openstack/common in flake8 exclude list
82e8a63 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 4 ++--
tox.ini   | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 758c7d5..80bdbbb 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +7 @@ hacking<0.11,>=0.10.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
@@ -15 +15 @@ coverage>=3.6 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.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

[openstack-dev] [new][oslo] oslo.middleware 3.15.0 release (newton)

[no-reply]

We are thrilled to announce the release of:

oslo.middleware 3.15.0: Oslo Middleware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.middleware

With package available at:

https://pypi.python.org/pypi/oslo.middleware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

For more details, please see below.

Changes in oslo.middleware 3.14.0..3.15.0
-

6ca6c88 Updated from global requirements
45e90c6 Updated from global requirements
b07c27d Updated from global requirements
7e519d0 Deprecate using String as valid value for allowed_origin.
399e940 Deprecate multiple config block parsing.


Diffstat (except docs and test files)
-

oslo_middleware/cors.py | 10 +-
requirements.txt|  4 ++--
test-requirements.txt   |  2 +-
4 files changed, 13 insertions(+), 29 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 01c7f22..b80e5c6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ Jinja2>=2.8 # BSD License (3 clause)
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
@@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d913843..5f53419 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ oslotest>=1.10.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] oslo.context 2.6.0 release (newton)

[no-reply]

We are chuffed to announce the release of:

oslo.context 2.6.0: Oslo Context library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.context

With package available at:

https://pypi.python.org/pypi/oslo.context

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.context

For more details, please see below.

Changes in oslo.context 2.5.0..2.6.0


740b817 Handle openstack.request_id in from_environ
d3af1d0 Add is_admin_project to context
4db9262 Updated from global requirements
f0de0c6 Add oslo.context name attributes matching ids


Diffstat (except docs and test files)
-

oslo_context/context.py|  45 +++-
test-requirements.txt  |   4 +-
3 files changed, 174 insertions(+), 92 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 1db9871..79fca04 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-reno>=1.6.2 # Apache2
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] oslo.config 3.13.0 release (newton)

[no-reply]

We are thrilled to announce the release of:

oslo.config 3.13.0: Oslo Configuration API

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.config

With package available at:

https://pypi.python.org/pypi/oslo.config

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.config

For more details, please see below.

Changes in oslo.config 3.12.0..3.13.0
-

335b184 Add Python 3.5 classifier and venv
d174a4e Enabling your project for mutable-config
7539018 Add namespace to _list_opts() in test
a08ec74 decode subprocess output so doc build works on python3
7111070 Updated from global requirements
4f97c6f Updated from global requirements


Diffstat (except docs and test files)
-

setup.cfg   |   1 +
test-requirements.txt   |   4 +-
tox.ini |   2 +-
7 files changed, 128 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 4789fb0..d444b33 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -21 +21 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
@@ -23 +23 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-reno>=1.6.2 # Apache2
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] oslo.cache 1.11.0 release (newton)

[no-reply]

We are psyched to announce the release of:

oslo.cache 1.11.0: Cache storage for Openstack projects.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.cache

With package available at:

https://pypi.python.org/pypi/oslo.cache

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.cache

For more details, please see below.

Changes in oslo.cache 1.10.0..1.11.0


86bcd66 Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt  | 2 +-
test-requirements.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 28e46dd..b1defe2 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10 +10 @@ oslo.log>=1.14.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.14.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 42f2881..0510e84 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8,2 +8,2 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-reno>=1.6.2 # Apache2
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing 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][oslo] automaton 1.3.0 release (newton)

[no-reply]

We are satisfied to announce the release of:

automaton 1.3.0: Friendly state machines for python.

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/automaton

Please report issues through launchpad:

http://bugs.launchpad.net/automaton

For more details, please see below.

Changes in automaton 1.2.0..1.3.0
-

4008814 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 0036b56..2c695bc 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11 +11 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] futurist 0.15.0 release (newton)

[no-reply]

We are eager to announce the release of:

futurist 0.15.0: Useful additions to futures, from the future.

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/futurist

Please report issues through launchpad:

http://bugs.launchpad.net/futurist

For more details, please see below.

Changes in futurist 0.14.0..0.15.0
--

4ca63cb Don't include openstack/common in flake8 exclude list
c7c67ca Updated from global requirements
dc08625 Begin adding our own thread pool executor


Diffstat (except docs and test files)
-

futurist/_futures.py  |  80 ++-
futurist/_thread.py   | 146 ++
futurist/_utils.py|   2 +
test-requirements.txt |   2 +-
tox.ini   |   2 +-
5 files changed, 193 insertions(+), 39 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 6e6d300..68ed7a0 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -14 +14 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] mox3 0.17.0 release (newton)

[no-reply]

We are tickled pink to announce the release of:

mox3 0.17.0: Mock object framework for Python

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/mox3

Please report issues through launchpad:

http://bugs.launchpad.net/python-mox3

For more details, please see below.

Changes in mox3 0.16.0..0.17.0
--

2b58961 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index ad30fa2..df05b72 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -20 +20 @@ six>=1.9.0 # MIT
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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][oslo] debtcollector 1.6.0 release (newton)

[no-reply]

We are pumped to announce the release of:

debtcollector 1.6.0: A collection of Python deprecation patterns and
strategies that help you collect your technical debt in a non-
destructive manner.

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/debtcollector

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

For more details, please see below.

Changes in debtcollector 1.5.0..1.6.0
-

d46b64a Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index d1f9b5d..16f75c6 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



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

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

[Ivan Kolodyazhny]

Thanks for the update, Matt.

I will join our meeting next week.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Tue, Jul 12, 2016 at 4:25 PM, Matt Riedemann 
wrote:

> On 7/12/2016 6:29 AM, Ivan Kolodyazhny wrote:
>
>> Hi team,
>>
>> Do we have any decision on this issue? I've found few patches but both
>> of them are -1'ed.
>>
>> From Cinder perspective, it blocks us to release new os-brick with
>> features, which are needed for other projects like Cinder and
>> python-brick-cinderclient-ext.
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Wed, Jun 22, 2016 at 5:47 PM, Matt Riedemann
>> > wrote:
>>
>> On 6/21/2016 10:12 PM, Angus Lees wrote:
>>
>> On Wed, 22 Jun 2016 at 05:59 Matt Riedemann
>> 
>> >
>> >> wrote:
>>
>> Angus, what should we be looking at from the privsep side
>> for debugging
>> this?
>>
>>
>> The line above the screen-n-cpu.txt.gz failure you linked to is:
>> 2016-06-21 16:21:30.994
>> <
>> http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/new/screen-n-cpu.txt.gz?level=TRACE#_2016-06-21_16_21_30_994
>> >1840
>> WARNING oslo.privsep.daemon [-] privsep log:
>> /usr/local/bin/nova-rootwrap: Unauthorized command: privsep-helper
>> --config-file /etc/nova/nova.conf --privsep_context
>> os_brick.privileged.default --privsep_sock_path
>> /tmp/tmpV5w2VC/privsep.sock (no filter matched)
>>
>>  .. so nova-rootwrap is rejecting the privsep-helper command line
>> because no filter matched.  This indicates the nova
>> compute.filters file
>> has not been updated, or is incorrect.
>>
>>
>> As was later pointed out by mtreinish, grenade is attempting to
>> run the
>> newton code against mitaka configs, and this includes using mitaka
>> rootwrap filters.   Unfortunately, the change to add privsep to
>> nova's
>> rootwrap filters wasn't approved until the newton cycle (so that
>> all the
>> os-brick privsep-related changes could be approved together), and
>> so
>> this doesn't Just Work.
>>
>> Digging in further, it appears that there *is* a mechanism in
>> grenade to
>> upgrade rootwrap filters between major releases, but this needs
>> to be
>> explicitly updated for each project+release and hasn't been for
>> nova+mitaka->newton.  I'm not sure how this is *meant* to work,
>> since
>> the grenade "theory of upgrade" doesn't mention when configs
>> should be
>> updated - the only mechanism provided is an "exception ... used
>> sparingly."
>>
>>
>> As noted in the review, my understanding of the config changes is
>> deprecation of options across release boundaries so that you can't
>> drop a config option that would break someone from release to
>> release without it being deprecated first. So deprecate option foo
>> in mitaka, people upgrading from liberty to mitaka aren't broken,
>> but they get warnings in mitaka so that when you drop the option in
>> newton it's not a surprise and consumers should have adjusted during
>> mitaka.
>>
>> For rootwrap filters I agree this is more complicated.
>>
>>
>> Anyway, I added an upgrade step for nova mitaka->newton that
>> updates
>> rootwrap filters appropriately(*).  Again, I'm not sure what this
>> communicates to deployers compared to cinder (which *did* have the
>> updated rootwrap filter merged in mitaka, but of course that
>> update
>> still needs to be installed at some point).
>> (*) https://review.openstack.org/#/c/332610
>>
>>  - Gus
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> Alternatively Walter had a potential workaround to fallback to
>> rootwrap for os-brick:
>>
>> https://review.openstack.org/#/c/329586/
>>
>> So we could maybe use that for newton. But os-vif doesn't have
>> anything like that, so we'd have to see what kind of (immediately
>> deprecated) workaround could happen for os-vif in newton and then
>> drop that in ocata.
>>
>> I'm told danpb is out until tomorrow though so we'll probably need
>> to wait to talk to him about options 

[openstack-dev] [storlets] IRC meeting times

[eran]

Hi,
I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
That's:
16:00 JST
10:00 IST

Any objections?
Thanks!
Eran



__
OpenStack Development Mailing 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][DVR] - No IRC Meeting today

[Brian Haley]

Hi Folks,

Sorry for the late notice, but we will not have a DVR sub-team meeting today 
since neither Swami nor myself will be there to chair it.


We will resume our meetings next week on July 20th.

If you have any questions please ping us on IRC or send an email to the list.

https://wiki.openstack.org/wiki/Meetings/Neutron-DVR

Thanks,

-Brian

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

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Wesley Hayutin]

On Wed, Jul 13, 2016 at 8:54 AM, Michal Pryc  wrote:

> John,
>
> On Tue, Jul 12, 2016 at 9:39 PM, John Trowbridge  wrote:
>
>> Howdy folks,
>>
>> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
>> is being used as a CI tool in RDO. This came about organically, because
>> we needed to use RDO CI to self-gate quickstart (it relies on having a
>> baremetal virthost). It displaced another ansible based CI tool there
>> (khaleesi) and most(all?) of the extra functionality from that tool
>> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
>> roles that are able to plugin to quickstart.[1]
>>
>>
> Here is small sum of frameworks/tools to give you an idea what we are
> currently using to test RHOS components.
>
> To create Triple-O undercloud/overcloud we are using the:
>
> https://github.com/redhat-openstack/ansible-ovb
>
> And then to install RHOSP on existing Triple-O:
>
> https://github.com/redhat-openstack/ansible-rhosp
>
> Then to run CI in such environment we use octario which is our main tool
> to run different flavors of tests and it's separate CI tool to be ready
> with different provisioning frameworks.
>
> https://github.com/redhat-openstack/octario/
>
>
> In the simplistic environment to run simple tests we are using InfraRed to
> provision simple instance (without Triple-O):
>
> https://github.com/rhosqeauto/InfraRed
>
> And then we run octario in such environment to run actual tests.
>
> Ideally if the provisioning parts were common and we could reuse them.
> Currently we need to use yet another set of tools to be able to patch rpm's
> prior to running tests.
>

+1, agree
I think this part has been addressed w/
https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart


>
> There was an idea planted by dsariel to move some of the playbooks into
> ansible-galaxy roles (possibly other teams had such idea as well), which I
> can see it's another +1 for going with tools currently developed by Wes as
> they are pretty separate and could be converted into ansible-galaxy, to be
> available across different use-cases, but then it would need to be well
> defined so the roles are not multiplied and we won't end up having similar
> roles.
>
>
We also considered ansible-galaxy and any of the ansible roles found in
github/redhat-openstack/ansible-role could be moved into galaxy.  Galaxy
did not end up meeting our requirements for installing the roles and we
ended up using python setuptools.  Some roles have specific config and
playbooks that need to be copied to a standard location and galaxy just did
not do that very well.


>
> best
> Michal Pryc
>
>
>
>> We are still left with two different tool sets, where one should suffice
>> (and focus CI efforts in one place).
>>
>> I see two different ways to resolve this.
>>
>> 1. Actively work on making the tripleo-ci scripts consumable external to
>> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
>> upstream CI for packstack and puppet, so it is not totally far-fetched
>> to add support for TripleO jobs.
>>
>> Pros:
>> - All CI development just happens directly in tripleo-ci and RDO just
>> inherits that work.
>>
>> Cons:
>> - This is totally untried, and therefore a totally unknown amount of work.
>> - It is all or nothing in that there is no incremental path to get the
>> CI scripts working outside of CI.
>> - We have to rewrite a bunch of working ansible code in bash which IMO
>> is the wrong direction for a modern CI system.
>>
>>
>> 2. Actively work on making tripleo-ci consume the ansible work in
>> tripleo-quickstart and the external role ecosystem around it.
>>
>> Pros:
>> - This could be done incrementally, replacing a single function from
>> tripleo.sh with an invocation of tripleo-quickstart that performs that
>> function instead.
>> - We would be able to pull in a lot of extra functionality via these
>> external roles for free(ish).
>>
>> Cons:
>> - Similarly unknown amount of work to completely switch.
>> - CI development would be done in multiple repos, though each would have
>> discrete and well defined functionality.
>>
>>
>> Personally, I don't think we should do anything drastic with CI until
>> after we release Newton, so we don't add any risk of impacting new
>> features that haven't landed yet. I do think it would be a good goal for
>> Ocata to have a CI system in TripleO that is consumable outside of
>> TripleO. In any case, this email is simply to garner feedback if other's
>> think this is a worthy thing to pursue and opinions on how we can get
>> there.
>>
>>
>> [1]
>>
>> https://github.com/redhat-openstack?utf8=%E2%9C%93=ansible-role-tripleo
>> (note not all of these are actively used/developed)
>> [2] https://github.com/rdo-infra/weirdo
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> 

Re: [openstack-dev] [kolla] New specs process - a dicussion

[Steven Dake (stdake)]

Josh,

We did have the discussion at summit.  We aren't even going to have a "big
spec".  We are going to run as bare minimal of a spec as possible.  The
reason I brought up spec additions is because Kolla has become so large,
managing the project using current techniques is not optimal.  I don't
like process but in the future, the PTL will need an easy on-ramp to
managing Kolla output.

I agree with all of the risks you point out related to usage of specs.  I
am hopeful we can make this is a super lightweight process without the
nitpicking that occurs in other projects.  That said, the rollcall vote
specs I expect to be as painful as they currently are (by design).

Regards
-steve


On 7/12/16, 4:03 PM, "Joshua Harlow"  wrote:

>Something for consideration to make the specs process not to painful and
>one that I think (?) glance pioneered is to have a 'bigger spec' and a
>'smaller spec' template.
>
>https://github.com/openstack/glance-specs/blob/master/specs/lite-specs.rst
> 
>(smaller)
>
>https://github.com/openstack/glance-specs/blob/master/specs/template.rst
>(bigger)
>
>Just my 2 cents, don't bog down people to much with just big specs and
>nit picking and trying to develop the whole feature in the spec (cause
>that will off-put new people and senior people and ...).
>
>-Josh
>
>Michał Jastrzębski wrote:
>> Hey guys,
>>
>> Since our project matured, we decided that we should have a discussion
>> regarding our spec process.
>>
>> https://etherpad.openstack.org/p/kolla-N-midcycle-specs
>>
>> Currently we do specs for most critical things, and they require
>>majority vote.
>>
>> We want to introduce another way, to enable non-nuclear specs.
>> To summarize our discussion so far:
>>
>> 1. Specs will require only 2 * +2 by default
>> 2. Specs sit at minimum 2 weeks in gerrit before first +2 arrives, so
>> other people will have time to look at it
>> 3. Any core can require a rollcall vote - then it becomes rollcall vote
>> 4. If nobody calls for rollcall vote, after 2 weeks spec can be merged
>> with normal 2 * +2
>>
>> Thoughts?
>> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Michal Pryc]

John,

On Tue, Jul 12, 2016 at 9:39 PM, John Trowbridge  wrote:

> Howdy folks,
>
> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> is being used as a CI tool in RDO. This came about organically, because
> we needed to use RDO CI to self-gate quickstart (it relies on having a
> baremetal virthost). It displaced another ansible based CI tool there
> (khaleesi) and most(all?) of the extra functionality from that tool
> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> roles that are able to plugin to quickstart.[1]
>
>
Here is small sum of frameworks/tools to give you an idea what we are
currently using to test RHOS components.

To create Triple-O undercloud/overcloud we are using the:

https://github.com/redhat-openstack/ansible-ovb

And then to install RHOSP on existing Triple-O:

https://github.com/redhat-openstack/ansible-rhosp

Then to run CI in such environment we use octario which is our main tool to
run different flavors of tests and it's separate CI tool to be ready with
different provisioning frameworks.

https://github.com/redhat-openstack/octario/


In the simplistic environment to run simple tests we are using InfraRed to
provision simple instance (without Triple-O):

https://github.com/rhosqeauto/InfraRed

And then we run octario in such environment to run actual tests.

Ideally if the provisioning parts were common and we could reuse them.
Currently we need to use yet another set of tools to be able to patch rpm's
prior to running tests.

There was an idea planted by dsariel to move some of the playbooks into
ansible-galaxy roles (possibly other teams had such idea as well), which I
can see it's another +1 for going with tools currently developed by Wes as
they are pretty separate and could be converted into ansible-galaxy, to be
available across different use-cases, but then it would need to be well
defined so the roles are not multiplied and we won't end up having similar
roles.


best
Michal Pryc



> We are still left with two different tool sets, where one should suffice
> (and focus CI efforts in one place).
>
> I see two different ways to resolve this.
>
> 1. Actively work on making the tripleo-ci scripts consumable external to
> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> upstream CI for packstack and puppet, so it is not totally far-fetched
> to add support for TripleO jobs.
>
> Pros:
> - All CI development just happens directly in tripleo-ci and RDO just
> inherits that work.
>
> Cons:
> - This is totally untried, and therefore a totally unknown amount of work.
> - It is all or nothing in that there is no incremental path to get the
> CI scripts working outside of CI.
> - We have to rewrite a bunch of working ansible code in bash which IMO
> is the wrong direction for a modern CI system.
>
>
> 2. Actively work on making tripleo-ci consume the ansible work in
> tripleo-quickstart and the external role ecosystem around it.
>
> Pros:
> - This could be done incrementally, replacing a single function from
> tripleo.sh with an invocation of tripleo-quickstart that performs that
> function instead.
> - We would be able to pull in a lot of extra functionality via these
> external roles for free(ish).
>
> Cons:
> - Similarly unknown amount of work to completely switch.
> - CI development would be done in multiple repos, though each would have
> discrete and well defined functionality.
>
>
> Personally, I don't think we should do anything drastic with CI until
> after we release Newton, so we don't add any risk of impacting new
> features that haven't landed yet. I do think it would be a good goal for
> Ocata to have a CI system in TripleO that is consumable outside of
> TripleO. In any case, this email is simply to garner feedback if other's
> think this is a worthy thing to pursue and opinions on how we can get
> there.
>
>
> [1]
>
> https://github.com/redhat-openstack?utf8=%E2%9C%93=ansible-role-tripleo
> (note not all of these are actively used/developed)
> [2] https://github.com/rdo-infra/weirdo
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

[Alexey Khivin]

Thank You Renat, Moshe, Stan and all!


ср, 6 июл. 2016 г. в 7:01, Renat Akhmerov :

> Great! Alex, enjoy using yaqluator :)
>
> Renat Akhmerov
> @Nokia
>
> On 05 Jul 2016, at 23:16, Elisha, Moshe (Nokia - IL) <
> moshe.eli...@nokia.com> wrote:
>
> Thank you all for assisting.
>
> When I tested Mistral I used an older version of Mistral (meaning an older
> version of yaql).
>
> I have verified that latest Mistral is working as expected.
> I have upgraded the yaql library in yaqluator to 1.1.0 and it is now
> working as expected.
>
> Thanks!
>
> From: Dougal Matthews 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, 5 July 2016 at 17:53
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>
>
>
> On 5 July 2016 at 08:32, Renat Akhmerov  wrote:
>
>> Stan, thanks for clarification. What’s the latest stable version that
>> we’re supposed to use? global-requirements.txt has yaql>=1.1.0, I wonder
>> if it’s correct.
>>
>
> It is also worth looking at the upper-constraints.txt. It has 1.1.1 which
> is the latest release. So it all seems up to date.
>
>
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376
>
> I think the problem is that this external project isn't being updated.
> Assuming they have not deployed anything that isn't committed, then they
> are running YAQL 1.0.2 which is almost a year old.
>
> https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3
>
>
>>
>> Renat Akhmerov
>> @Nokia
>>
>> On 05 Jul 2016, at 12:12, Stan Lagun  wrote:
>>
>> Hi!
>>
>> The issue with join is just a yaql bug that is already fixed. The problem
>> with yaqluator is that it doesn't use the latest yaql library.
>>
>> Another problem is that it does't sets options correctly. As a result it
>> is possible to bring the site down with a query that produces endless
>> collection
>>
>> Sincerely yours,
>> Stan Lagun
>> Principal Software Engineer @ Mirantis
>>
>> 
>>
>> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
>> moshe.eli...@nokia.com> wrote:
>>
>>> Hi,
>>>
>>> Thank you for the kind words, Alexey.
>>>
>>> I was able to reproduce your bug and I have also found the issue.
>>>
>>> The problem is that we did not create the parser with the engine_options
>>> used in the yaql library by default when using the CLI.
>>> Specifically, the "yaql.limitIterators" was missing… I am not sure that
>>> this settings should have this affect but maybe the Yaql guys can comment
>>> on that.
>>>
>>> If we will change yaqluator to use this setting it will mean that
>>> yaqluator will not be consistent with Mistral because Mistral is using YAQL
>>> without this engine option (If I use your example in a workflow, Mistral
>>> returns exactly like the yaqluator returns)
>>>
>>>
>>> Workflow:
>>>
>>> ---
>>> version: '2.0'
>>>
>>> test_yaql:
>>>   tasks:
>>> test_yaql:
>>>   action: std.noop
>>>   publish:
>>> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>>>
>>>
>>> Workflow result:
>>>
>>>
>>> [root@s53-19 ~(keystone_admin)]# mistral task-get-published
>>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
>>> {
>>> "output_expr": [
>>> [
>>> 1,
>>> 3
>>> ]
>>> ]
>>> }
>>>
>>>
>>> As Matthews pointed out, the yaqluator is indeed OpenSource and
>>> contributions are welcomed.
>>>
>>> [1]
>>> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>>>
>>>
>>>
>>> From: Dougal Matthews 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> Date: Monday, 27 June 2016 at 16:44
>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>
>>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>>>
>>> On 27 June 2016 at 14:30, Alexey Khivin  wrote:
>>>
 Hello, Moshe

 Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
 tool!

 But suddenly I was said that the expression
 [1,2].join([3], true, [$1, $2])
 evaluated to [[1,3]] on the yaqluator

 A the same time this expression evaluated right when I using raw yaql
 interpreter.

 Could we fix this issue?

 By the way, don't you want to make yaqluator opensource? If you would
 transfer yaqluator to Openstack Foundation, then  community will be able to
 fix such kind of bugs

>>>
>>> It looks like it is open source, there is a link in the footer:
>>> https://github.com/ALU-CloudBand/yaqluator
>>>
>>>

 Thank you!
 Best regards, Alexey Khivin




 

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Wesley Hayutin]

On Tue, Jul 12, 2016 at 3:39 PM, John Trowbridge  wrote:

> Howdy folks,
>
> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> is being used as a CI tool in RDO. This came about organically, because
> we needed to use RDO CI to self-gate quickstart (it relies on having a
> baremetal virthost). It displaced another ansible based CI tool there
> (khaleesi) and most(all?) of the extra functionality from that tool
> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> roles that are able to plugin to quickstart.[1]
>
> We are still left with two different tool sets, where one should suffice
> (and focus CI efforts in one place).
>
> I see two different ways to resolve this.
>
> 1. Actively work on making the tripleo-ci scripts consumable external to
> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> upstream CI for packstack and puppet, so it is not totally far-fetched
> to add support for TripleO jobs.
>

I think we have to at least point out that RDO is not the only other target
for a CI tool.
There are a few more groups that would benefit from the leadership of the
upstream CI system.  Without
calling out specific groups, I'm thinking of the various OpenStack network
teams, performance teams,
test teams, etc.. that rely on setting up TripleO as the base for their
work. To make things a bit more complicated
there is not a single source of requirements for the various groups that
would benefit from a robust,
flexible upstream TripleO CI tool set.  I'm not convinced that the current
bash scripts can be
reworked or wrapped in a way that can be flexible enough to handle what is
an essentially
unknown set of requirements.

IMHO we require a tool set that is pluggable, composable and flexible
enough such that
other development, and CI teams that rely on TripleO as the base for their
work feel comfortable extending
and replacing parts of the CI tool set to fit their needs.



>
> Pros:
> - All CI development just happens directly in tripleo-ci and RDO just
> inherits that work.
>
> Cons:
> - This is totally untried, and therefore a totally unknown amount of work.
> - It is all or nothing in that there is no incremental path to get the
> CI scripts working outside of CI.
> - We have to rewrite a bunch of working ansible code in bash which IMO
> is the wrong direction for a modern CI system.
>
>
> 2. Actively work on making tripleo-ci consume the ansible work in
> tripleo-quickstart and the external role ecosystem around it.
>
> Pros:
> - This could be done incrementally, replacing a single function from
> tripleo.sh with an invocation of tripleo-quickstart that performs that
> function instead.
> - We would be able to pull in a lot of extra functionality via these
> external roles for free(ish).
>
> Cons:
> - Similarly unknown amount of work to completely switch.
> - CI development would be done in multiple repos, though each would have
> discrete and well defined functionality.
>
>
> Personally, I don't think we should do anything drastic with CI until
> after we release Newton, so we don't add any risk of impacting new
> features that haven't landed yet. I do think it would be a good goal for
> Ocata to have a CI system in TripleO that is consumable outside of
> TripleO. In any case, this email is simply to garner feedback if other's
> think this is a worthy thing to pursue and opinions on how we can get
> there.
>

+1 here.  I agree there should be enough time for thoughtful conversation
without
disrupting higher priority work.

Thanks for sending this out John!


>
>
> [1]
>
> https://github.com/redhat-openstack?utf8=%E2%9C%93=ansible-role-tripleo
> (note not all of these are actively used/developed)
> [2] https://github.com/rdo-infra/weirdo
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Markus Zoeller]

On 13.07.2016 09:56, Sahid Orentino Ferdjaoui wrote:
> On Tue, Jul 12, 2016 at 06:45:03PM +0200, Markus Zoeller wrote:
>> On 12.07.2016 17:39, Sahid Orentino Ferdjaoui wrote:
>>> On Tue, Jul 12, 2016 at 09:59:12AM +0200, Markus Zoeller wrote:
 After closing the old (>18months) bug reports nobody is working on a few
 days ago [1], it became clear that the "in progress" reports are the
 majority [2]. After asking Gerrit how long it usually takes to get a fix
 merged [3], this is the result:

 number of merged bug fixes within the last 365 days: 689
 merged within ~1m : 409 (~59%)
 merged within ~2m : 102 (~14%)
 merged within ~3m :  57 (~ 8%)
 merged > 3month   : 121 (~17%)

 Note: This doesn't reflect the time a patch might be marked as
 "WIP". It also doesn't add up to 100% as I rounded down the
 percentages.

 This made me thinking about ways to increase the review throughput of
 bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
 *assume* that the fixes in the ">3m" area had inherent problems or
 waited for basic structural changes, but that's just guesswork.

 The proposal is this:
 * have a TBD list with max 10 items on it (see list possibilities below)
 * add new items during nova meeting if slots are free
 * Change owners must propose their changes as meeting agenda items
 * drop change from list in nova meeting if progress is not satisfying
>>>
>>> Considering a raw list of patches would be difficult to maintain, it's
>>> time consuming and Nova has contributors working on different areas
>>> which are sometimes really differents. How to order this list and how
>>> to consider a patch is satisfying the progress policy.
>>
>> I'm not sure if I understand the concerns correctly. The list
>> possibilities below seem to be easy to maintain. My assumption is, that
>> minimizing the "wait time" (reviewers wait for new patchsets OR change
>> owners wait for new reviews) can increase the throughput. It makes the
>> commitment of change owners and reviewers necessary though.
>> I don't think that the list needs specific ordering rules. As I want to
>> target bug fixes with this proposal, the ordering is given by the impact
>> of the bugs.
> 
> How I see that you want to concentrate reviewers to be on 10 patches
> every weeks but here the bottleneck would be the authors, no?
> 
> I think we have a pretty good flow, most of the bug fixes which need
> to get attention are reviewed quickly.
> 

To be precise, the 10 patches on this list is just an upper bound. It is
*not* said that this should be merged within 1 week. *If* a new slot
gets freed because one of the changes merged, *then* a new change can be
added *if* the authors commit themselves to push new ps quickly.
By bringing the changes into the spotlight, there is a little pressure
to not be *that person* who stalls the flow.
I agree that the flow is already good. The numbers from above show that
almost 60% of the fixes merge within 4 weeks, which is good. Trying to
increase that is a good thing too, IMO.

>>> To make things working we should find some automations and have one
>>> list by areas which is probably the purpose of tags in gerrit.
>>
>> This could result in silo mentality and discussions why list A gets
>> preferred over list B. That's why I want to avoid having multiple lists.
>> It's about fixing issues in Nova, not fixing issues in
>> .
> 
> I don't think that could result in silo mentality and I remember a
> initiative in the same way but with etherpad and so difficult to
> maitain.
> 

Yes, the etherpad is hard to maintain and makes the the review-workflow
a little more cumbersome IMO. What were the reasons the last initiative
didn't work out?

>>> Since we don't have such feature on our gerrit yet, a possible
>>> solution would be to introduce a tag in commit messages which reflects
>>> the subteam or area related. Then a simple script could parse reviews
>>> in progress to print them somewhere.
>>
>> Changing the commit message creates a new patchset which triggers the
>> gate checks again, that's why I thought making comments with a keyword
>> which can be queried is less trouble.
> 
> Gerrit comments are lost when the patch get merged, we may want to
> provide some stats from these tags in future that's why I think commit
> message is better. Also if we only change commit messages, all of the
> gate is re-executed ?

Personally, after the patch got merged and the bug fixed, I don't have
any interest in it anymore. I don't want to spent efforts on things
which might never happen. Important fixes will have a reno as usual, so
users will be notified anyway.
IIRC, each new ps will result in a new gate check. But that's a
technical discussion which doesn't bring any benefit from my point of view.

>>> So each subteams can have a view of the work in progress which could
>>> make things 

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Andreas Jaeger]

On 2016-07-13 13:35, Markus Zoeller wrote:
> On 12.07.2016 20:31, Jeremy Stanley wrote:
>> On 2016-07-12 10:46:54 -0700 (-0700), Augustina Ragwitz wrote:
>> [...]
>>> I like #3 but I worry about the comments getting spammy if things are
>>> dropped from and added to the list repeatedly. Would tagging the bugs in
>>> Launchpad work? We can easily remove tags in Launchpad, it's a
>>> query-able list, and the reviewer would immediately have some context.
>>
>> This sounds like another case for reviewday and/or a custom Gerrit
>> review dashboard dynamically updated like Neutron does...
>>
>> http://status.openstack.org/reviews/
>> https://review.openstack.org/298779
>>
> 
> The Neutron dashboard is pretty cool. IIUC the link to Gerrit and the
> query to use are generated/updated automatically after each merged
> commit. I have to leave Gerrit for it and it cannot be used in "gerrty"
> though, or can it?

Yes, you have to leave gerrit for it to get the link to the updated
dashboard. I'm not aware of a direct integration into gertty.

> Nevertheless, it's a good alternative which can support the whole idea,
> thanks for bringing that up.


Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

[Hugh Saunders]

+1 JP :)

On Tue, 12 Jul 2016 at 19:34 Truman, Travis 
wrote:

> Jean-Philippe has been providing great code reviews and patches for some
> time. His recent commitment to running bug triage every week shows his
> willingness to step up and take responsibilities within the community. He’s
> also found an opportunity to innovate by introducing an improved bug triage
> process. He can often be found in #openstack-ansible as *evrardjp *providing
> support to deployers in a welcoming and friendly manner.
>
> In short, just the kind of contribution our community desires from core
> reviewers.
>
> Thanks for all that you do for the community Jean-Philippe,
> Travis Truman
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Markus Zoeller]

On 12.07.2016 20:31, Jeremy Stanley wrote:
> On 2016-07-12 10:46:54 -0700 (-0700), Augustina Ragwitz wrote:
> [...]
>> I like #3 but I worry about the comments getting spammy if things are
>> dropped from and added to the list repeatedly. Would tagging the bugs in
>> Launchpad work? We can easily remove tags in Launchpad, it's a
>> query-able list, and the reviewer would immediately have some context.
> 
> This sounds like another case for reviewday and/or a custom Gerrit
> review dashboard dynamically updated like Neutron does...
> 
> http://status.openstack.org/reviews/
> https://review.openstack.org/298779
> 

The Neutron dashboard is pretty cool. IIUC the link to Gerrit and the
query to use are generated/updated automatically after each merged
commit. I have to leave Gerrit for it and it cannot be used in "gerrty"
though, or can it?
Nevertheless, it's a good alternative which can support the whole idea,
thanks for bringing that up.

-- 
Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing 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][oslo] pbr potential breaking change coming

[Andreas Jaeger]

On 2016-07-13 13:25, Markus Zoeller wrote:
> For some reason the gate docs job didn't find the issue (wrong json
> format) which got fixed with change [1]. It doesn't even emit a warning.
> Locally, the execution of "tox -e docs" does find the issue. Can we make
> the gate docs job aware of such json format issues?

Just move that change from docs to pep8 target,
Andreas

> References:
> [1] https://review.openstack.org/#/c/339295/1


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Markus Zoeller]

On 13.07.2016 10:09, Andreas Jaeger wrote:
> On 2016-07-12 09:59, Markus Zoeller wrote:
>> After closing the old (>18months) bug reports nobody is working on a few
>> days ago [1], it became clear that the "in progress" reports are the
>> majority [2]. After asking Gerrit how long it usually takes to get a fix
>> merged [3], this is the result:
>>
>> number of merged bug fixes within the last 365 days: 689
>> merged within ~1m : 409 (~59%)
>> merged within ~2m : 102 (~14%)
>> merged within ~3m :  57 (~ 8%)
>> merged > 3month   : 121 (~17%)
>>
>> Note: This doesn't reflect the time a patch might be marked as
>> "WIP". It also doesn't add up to 100% as I rounded down the
>> percentages.
>>
>> This made me thinking about ways to increase the review throughput of
>> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
>> *assume* that the fixes in the ">3m" area had inherent problems or
>> waited for basic structural changes, but that's just guesswork.
>>
>> The proposal is this:
>> * have a TBD list with max 10 items on it (see list possibilities below)
>> * add new items during nova meeting if slots are free
>> * Change owners must propose their changes as meeting agenda items
>> * drop change from list in nova meeting if progress is not satisfying
>>
>> List possibilities:
>> 1) etherpad of doom? maintained by (?|me)
>> + easy to add/remove from everyone
>> - hard to query
>> 2) gerrit: starred by (?|me)
>> + easy to add/remove from the list maintainer
>> + easy to query
>> - No additions/removals when the list maintainer is on vacation
>> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX
>> + easy to add/remove from everyone
>> + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX)
>> - once removed with a comment "DROPTOP10BUGFIX", a repeated
>>   addition is not practical anymore.
>> 4) gerrit: tag a change
>> + easy to add/remove from everyone
>> + easy to query
>> - not yet available in our setup
> 
> You could also use a specific topic for these - instead of the bug/XXX,
> use TOP10BUG.
> 
> Another suggestion: Check what neutron has done with their review board
> that is available from http://status.openstack.org/reviews/ as "Gerrit
> Dashboard links" - a dashboard that takes into account the launchpad bug
> status and is generated using a script (see
> https://review.openstack.org/298779 ),
> 
> Andreas
> 

Yep, another possible way to support the idea by tooling. What's more
important is the commitment of reviewers/authors I guess. If that
commitment isn't there, tooling won't help.

-- 
Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing 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][oslo] pbr potential breaking change coming

[Markus Zoeller]

On 23.06.2016 12:21, Andreas Jaeger wrote:
> On 06/23/2016 10:43 AM, Markus Zoeller wrote:
>> On 21.06.2016 15:01, Doug Hellmann wrote:
>>> A while back pbr had a feature that let projects pass "warnerror"
>>> through to Sphinx during documentation builds, causing any warnings in
>>> that build to be treated as an error and fail the build. This lets us
>>> avoid things like links to places that don't exist in the docs, bad but
>>> renderable rst, typos in directive or role names, etc.
>>>
>>> Somewhat more recently, but still a while ago, that feature "broke"
>>> with a Sphinx release that was not API compatible. Sachi King has
>>> fixed this issue within pbr, and so the next release of pbr will
>>> fix the broken behavior and start correctly passing warnerror again.
>>> That may result in doc builds breaking where they didn't before.
>>>
>>> The short-term solution is to turn of warnerrors (look in your
>>> setup.cfg), then fix the issues and turn it back on. Or you could
>>> preemptively fix any existing warnings in your doc builds before the
>>> release, but it's simple enough to turn off the feature if there isn't
>>> time.
>>>
>>> Josh, Sachi, & other Oslo folks, I think we should hold off on
>>> releasing until next week to give folks time. Is that OK?
>>>
>>> Doug
>>>
>>> PS - Thanks, Sachi, I know that bug wasn't a ton of fun to fix!
>> [...]
>>
>> Thanks for the heads up. I checked Nova, and every sphinx-build command
>> we use in our "tox.ini" file already uses the -W flag to treat warnings
>> as errors. I guess we're safe with that?
>>
> 
> Infra calls the docs job using
> tox -e venv -- python setup.py build_sphinx
> 
> And that's where the change comes in...
> 
> So, your docs environment is not used as is in the gate,
> 
> Andreas
> 

For some reason the gate docs job didn't find the issue (wrong json
format) which got fixed with change [1]. It doesn't even emit a warning.
Locally, the execution of "tox -e docs" does find the issue. Can we make
the gate docs job aware of such json format issues?

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

-- 
Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [Fuel] Mitaka stable branch

[Vladimir Kuklin]

Bogdan, Vladimir

*Regarding upgrades of Fuel Master Node and environments. *

First, regarding Fuel Master Node upgrades and enablement of usage of 9.0
LCM features with older clusters. It is assumed that we test usability of
Fuel Mitaka code with already deployed clusters, e.g. 8.0, 7.0 and so on.
Whenever an issue arise, we fix it. This would allow us to reuse newest
features to be able to enable LCM and newest orchestration and integration
capabilities with older clusters by essentially, calling old serializers
code within extensions pipeline, applying some pre- and postprocessing to
the serialized data. Here is an example of how it is done (Work in
progress):

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

This is an extension that first runs new LCM serializer which data is not
compatible with 9.0, but part of which we need for LCM engine (e.g.
'cluster context'), then we simply run 8.0 Serializer, add cluster info
into serialized data and then we just update 'upload_configuration' and
related tasks by simply copying them from Mitaka code of Fuel Library. I
proof-tested this by adding Sahara into already installed 8.0 cluster with
BVT scenario and it seems to be working.

*Regarding environments upgrades*

Having completed item #1 we should be able to run new orchestration against
old clusters, so that we can upgrade environments to newer versions,
esentially, by rolling reinstallation of control plane and resource nodes,
which means that as soon as new version of installed software (including
OpenStack, LMA toolchaing and other stuff) works fine with the feature-set
specified within the old cluster configuration, it should be OK to do so,
but this basically becomes a matter of building consistent upgrade path for
the particular environment.

*Conclusion*

Let's add bugfixing for management of old clusters and pre-9.0 clusters LCM
support into our RoadMap and we should be safe to go.

On Wed, Jul 13, 2016 at 12:23 PM, Bogdan Dobrelya 
wrote:

> On 07/13/2016 11:08 AM, Vladimir Kozhukalov wrote:
> >
> >
> > Few Q:
> > - Is the stable/mitaka the only stable branch in the scope of the
> > changes?
> >
> > ​Yes, this announce is only about Mitaka branch. All other stable
> > branches are to be treated as usual, i.e. no feature backports, bug
> > fixes only following "master first" policy, etc.
> >
> >
> > - As the master and stable/mitaka will diverge, the former might
> contain
> > backwards incompatible changes, ending up the upgrade paths from
> > stable/mitaka to future >=10.x releases will likely be *blocked* for
> its
> > life time. Any plans how to address that?
> >
> > - What about upgrade paths availability from the stable/* branches
> to:
> >   a) stable/mitaka
> >   b) future >=10.x releases?
> >
> > ​Fortunately, Fuel now has nice built-in LCM that allows to run
> > complicated custom scenarios (including reconfigurations/upgrades of
> > existent OpenStack clusters). Vladimir Kuklin is working hard on making
> > this LCM capabilities applicable to cases stable/* -> stable/mitaka. I
> > believe later we'll be able to implement stable/mitaka -> Newton, etc.
>
> That's OK for the upgrade process, while I'm not sure in the very
> upgrade *possibility* if we allowed backwards incompatible changes make
> it to the Newton. How would users upgrade from stable/mitaka to anything
> wich might be backwards incompatible and might break things? And
> features backported and being developed in both branches may conflict as
> well. All of this makes the upgrade barely possible, so any ideas how
> could we address that?
>
> >
> > Let's try to imagine we removed old role based serializers from Nailgun
> > in Newton release. The question is how are we going, for example, to
> > add/remove nodes to/from Kilo/Liberty clusters. The answer would be we
> > could add custom task graph and task based deployment engine to modify
> > old clusters. I'd like Vladimir Kuklin to give some additional details.
> >
> >
> >
> >
> > >
> >
>  __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> > --
> > Best regards,
> > Bogdan Dobrelya,
> > Irc #bogdando
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> 

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Lee Yarwood]

On 12-07-16 09:59:12, Markus Zoeller wrote:
> After closing the old (>18months) bug reports nobody is working on a few
> days ago [1], it became clear that the "in progress" reports are the
> majority [2]. After asking Gerrit how long it usually takes to get a fix
> merged [3], this is the result:
> 
> number of merged bug fixes within the last 365 days: 689
> merged within ~1m : 409 (~59%)
> merged within ~2m : 102 (~14%)
> merged within ~3m :  57 (~ 8%)
> merged > 3month   : 121 (~17%)
> 
> Note: This doesn't reflect the time a patch might be marked as
> "WIP". It also doesn't add up to 100% as I rounded down the
> percentages.
> 
> This made me thinking about ways to increase the review throughput of
> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
> *assume* that the fixes in the ">3m" area had inherent problems or
> waited for basic structural changes, but that's just guesswork.
> 
> The proposal is this:
> * have a TBD list with max 10 items on it (see list possibilities below)
> * add new items during nova meeting if slots are free
> * Change owners must propose their changes as meeting agenda items
> * drop change from list in nova meeting if progress is not satisfying
> 
> List possibilities:
> 1) etherpad of doom? maintained by (?|me)
> + easy to add/remove from everyone
> - hard to query
> 2) gerrit: starred by (?|me)
> + easy to add/remove from the list maintainer
> + easy to query
> - No additions/removals when the list maintainer is on vacation
> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX
> + easy to add/remove from everyone
> + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX)
> - once removed with a comment "DROPTOP10BUGFIX", a repeated
>   addition is not practical anymore.
> 4) gerrit: tag a change
> + easy to add/remove from everyone
> + easy to query
> - not yet available in our setup
> 
> Personally I prefer 3, as it doesn't rely on a single person and the
> tooling is ready for that. It could be sufficient until one of the next
> infra Gerrit updates brings us 4. I'd like to avoid 1+2.
> 
> My hope is, that a focused list helps us to get (few) things done faster
> and increase the overall velocity. Is this a feasible proposal from your
> point of view? Which concerns do you have?
> 
> References:
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098792.html
> [2] http://45.55.105.55:3000/dashboard/db/openstack-bugs
> [3]
> https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py

Thanks for bringing this up Markus! IMHO tags against either in-progress
launchpad bugs and/or gerrit reviews would work best here.

Cheers,

Lee
-- 
Lee Yarwood
Senior Software Engineer
Red Hat

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

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

Re: [openstack-dev] [nova] Can not rebuild boot-from-volume instance

[Lee Yarwood]

On 12-07-16 15:12:24, zehua wrote:
> Hi, all
> I booted a new instance from a volume and then attached an other volume to it,
> and created image for the instance whos block_device_mapping like this:
> 
> 
> | block_device_mapping | [{"guest_format": null, "boot_index": 0, 
> "delete_on_termination": false,
> |   | "no_device": null, "snapshot_id": 
> "61c18329-420d-4765-ab5a-c626d9b1ebcd",
> |   | "device_name": "/dev/vda", "disk_bus": "virtio", 
> "image_id": null, 
> |   | "source_type": "snapshot", "device_type": "disk", 
> "volume_id": null,
> |   | "destination_type": "volume", "volume_size": 20}, 
> {"guest_format": null,
> |   | "boot_index": null, "delete_on_termination": false, 
> "no_device": null,   
> |   | "snapshot_id": "438cd325-3fcd-4769-a3e9-c0a9aeaa2437", 
> "device_name":
> |   | "/dev/vdb", "disk_bus": null, "image_id": null, 
> "source_type": "snapshot",
> |   | "device_type": null, "volume_id": null, 
> "destination_type": "volume",
> |   | "volume_size": 10}]
> 
> There’s no problem when use the snapshot image to boot a new instance, that 
> mergs
> block_device_mapping in image and one provied manually.
> But rebuilding instance from the image ignores the block_device_mapping 
> attribute. Should we
> replace all origin volumes by new volumes provided byimage 
> block_device_mapping attribute
> according to device name?

I *think* the following change is attempting to do this, however I'm
still not sure that this is the correct behaviour during a rebuild :

Replace root volume during rebuild
https://review.openstack.org/#/c/305079/

Lee
-- 
Lee Yarwood
Senior Software Engineer
Red Hat

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

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

[openstack-dev] [Freezer] Freezer Mascot

[Mathieu, Pierre-Arthur]

Hi,

We should select a Mascot for Freezer project.

Please add your suggestions in the etherpad below:
https://etherpad.openstack.org/p/freezer_mascot

We need to select 3-5 leading suggestions, send them to OpenStack 
representative for evaluation.
We will then conduct the final vote.
Please go over the etherpad, and add +1 for the suggestions you like most.

Thanks,
- Pierre



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

Re: [openstack-dev] [ironic] why do we need setting network driver per node?

[milanisko k]

> 1. we agreed on  whether the 'network_interface' was, or was not, an
interface that was similar to the existing power, deploy, ... interfaces so
that it fit into the driver composition work
with the network interface being environment- (binding a node to a
particular Switch type) rather than HW-dependent, I've got an impression it
is directed a bit against the driver composition spec in these two points:

* "Make vendors in charge of defining a set of supported interface
implementations and the default implementation to be used." [1]
* "The list of hardware interfaces is still hardcoded in the Python code
and cannot be extended by plugins."[2]

Therefore having network_interface part of hardware_type might effectively
prevent competition  (mixing and matching switches with nodes) if HW vendor
X decides to blacklist Switch vendor Y by not including Y's Switches in
X.supported_network_interfaces list.

Moreover if the default-interface logic is "For *hardware types* setting
_interface field to None means using the *vendor* default
defined in the *hardware type*. If the *vendor* default is None, the
interface will be disabled."[3] the HW vendor will have difficulties to
express they don't care what switch their node is supposed to be connected
to; should they list all possible switch vendors from within the tree in
supported_network_interfaces? What about out of tree vendors? Wouldn't this
lead to the driver naming the driver reform spec is supposed to prevent
(e.g  to have X_node_Y_switch, X_node_Z_switch in enabled_hardware_types)?

I'd therefore suggest against network_interface being part of the
hardware_type.

Cheers,
milan

[1] section "With this spec we are going to achieve the following goals:"
first bullet,
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#introduction
[2] second bullet in the list:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#configuration
[3] second bullet in the list:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#database-and-rest-api


út 12. 7. 2016 v 18:58 odesílatel Loo, Ruby  napsal:

> Thanks Devananda and Dmitry and Sam!
>
>
>
> From my point of view, I wanted to make sure that:
>
>
>
> 1. we agreed on  whether the 'network_interface' was, or was not, an
> interface that was similar to the existing power, deploy, ... interfaces so
> that it fit into the driver composition work
>
> 2. we agreed on having or not having the default_network_interface
> configuration option, and whether/how it fit into the driver composition
> work.
>
>
>
> I think, because I haven't heard anyone disagree (yet), that the
> network_interface fits into the driver composition work and that we want
> the configuration option. It looks like we are trying to figure out *how*
> it fits into the driver composition work and hardware_types. To that end, I
> thought I'd put up a patch [1] that I hope captures everyone's suggestions.
> Maybe we can move to that patch to comment.
>
>
>
> As far as the multi-tenant networking patches [2] go, as long as we're
> good with the above, I think we're good to continue. The details wrt how
> the network_interface and default configuration option is integrated with
> hardware_types can be worked out.
>
>
>
> If you think otherwise, please let me know :)
>
>
>
> --ruby
>
>
>
> [1] https://review.openstack.org/#/c/341084/
>
>
>
> [2] https://review.openstack.org/#/c/285852/
>
>
>
>
>
> On 2016-07-12, 8:02 AM, "Dmitry Tantsur"  wrote:
>
>
>
> Thanks for writing this up, minor comments inline.
>
>
>
> On 07/11/2016 10:57 PM, Devananda van der Veen wrote:
>
> We spent the majority of today's weekly IRC meeting [1] discussing the
> finer
>
> points of this question. I agreed to post a summary of those to the list
> (it's
>
> below the break).
>
>
>
> tldr;
>
>
>
> * we don't know if network_interface should behave like other hardware
>
> interfaces, but...
>
> * we need to come to an agreement on it this week, so we can proceed with
> the
>
> network integration work.
>
>
>
>
>
> 
>
>
>
>
>
> There was a proposal from sambetts towards the end of the meeting, which
> I've
>
> edited for clarity (please correct if I misunderstood any of your points).
> This
>
> seems to capture/address most of the points above and proposes a way
> forward,
>
> while keeping within the intent of our driver composition reform spec. It
> was
>
> the only clear suggestion during the meeting.
>
>
>
> - in-tree hardware_types declare supported_network_interfaces to be empty
> [4]
>
> and declare no default_network_interface
>
>
>
> We need supported_network_interfaces, otherwise you won't be able to
>
> check compatibility. I think we should introduce a constant to use like
>
> that:
>
>
>
>   class MyHwType:
>
> supported_network_interfaces = ironic.network.ALL_INTERFACES
>
>
>
> - we 

Re: [openstack-dev] [Fuel] New version of fuel-devops (2.9.21)

[Dennis Dmitriev]

Hi Bogdan,

thanks for the question!

On 07/12/2016 10:26 AM, Bogdan Dobrelya wrote:
> On 07/12/2016 09:24 AM, Bogdan Dobrelya wrote:
>> Thank you for a hard work, that's a really great tool.
>>
>> Anyone who is interested, please note that fuel-devops, despite of the
>> name, may be used outside of Fuel and OpenStack as a really fast and
>> easy way to spin up VMs for a dev envs. Almost like a Vagrant, although
>> it gives you advanced templates [1] which is more flexible at least for
>> networking perhaps.
>>
>> By the way, fuel-devops folks, do you plan to add docs [2] for advanced
>> templating as well?
>>
Some docs with template examples are located in [1].
After merging a couple of important patches [2] [3] , we plan to improve
the auto documentation and get the complete manual for all the options,
then it can be placed to /fuel-docs/.

[1]
https://github.com/openstack/fuel-devops/tree/master/doc/source/template_examples
[2] https://review.openstack.org/#/c/333224/
[3] https://review.openstack.org/#/c/338496/

> Sorry, here is the correct docs link [3] :-)
>
>> [1]
>> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/template-based-virtual-devops-environments.html
>> [2]
>> https://git.openstack.org/cgit/openstack/fuel-ccp-installer/tree/utils/jenkins/default30-kargo.yaml
> [3] http://docs.openstack.org/developer/fuel-docs/devdocs/devops.html
>
>>
>> On 07/11/2016 08:39 PM, Dennis Dmitriev wrote:
>>> Hi All,
>>>
>>> We are going to update the 'fuel-devops' framework on our product CI to
>>> the version 2.9.21.
>>>
>>> Changes since 2.9.20:
>>>
>>> * For devops:
>>>
>>>   - Scripts for export and import systest environments, based on
>>> external libvirt snapshots [1]
>>>   - Disable creation of nwfilters by default [2]
>>>   - Get rid from log.yaml file, logger and it's settings were moved into
>>> scripts [3]
>>>   - Do not use database ids in bridge and interface names, that allows
>>> to use several different virtual environments with different set of
>>> requirements on the same host [4] [5] [6]
>>>
>>> * For QA automation:
>>>
>>>   - 'ipaddr' was replaced with 'netaddr'  [7]
>>>   - Use keystoneauth1 package for authorization to Nailgun [8]
>>>   - Move the method execute_through_host() from fuel-qa to SSHClient [9]
>>>   - Methods that allow to change boot order and close tray for Node [10]
>>>   - Lots of SSHClient improvements [11] [12] [13] [14] [15]
>>>   - Improvements for compatibility with python3
>>>
>>> List of all changes can be found on github [16].
>>>
>>> [1] https://review.openstack.org/#/c/280573/
>>> [2] https://review.openstack.org/#/c/313082/
>>> [3] https://review.openstack.org/#/c/320366/
>>> [4] https://review.openstack.org/#/c/327082/
>>> [5] https://review.openstack.org/#/c/336057/
>>> [6] https://review.openstack.org/#/c/339811/
>>> [7] https://review.openstack.org/#/c/299428/
>>> [8] https://review.openstack.org/#/c/314505/
>>> [9] https://review.openstack.org/#/c/319920/
>>> [10] https://review.openstack.org/#/c/331660/
>>> [11] https://review.openstack.org/#/c/331120/
>>> [12] https://review.openstack.org/#/c/327656/
>>> [13] https://review.openstack.org/#/c/327180/
>>> [14] https://review.openstack.org/#/c/326462/
>>> [15] https://review.openstack.org/#/c/338161/
>>> [16] - https://github.com/openstack/fuel-devops/compare/2.9.20...release/2.9
>>>
>>
>

-- 
Regards,
Dennis Dmitriev
QA Engineer,
Mirantis Inc. http://www.mirantis.com
e-mail/jabber: dis.x...@gmail.com


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

[openstack-dev] [Fuel][QA] Changes in requirements.txt in the fuel-qa repository

[Dennis Dmitriev]

Hi all,

Recently there was a change in the fuel-qa requirements [1], that can be
found in patches for 6.1, 7.0, 8.0, mitaka and master [2] [3] [4] [5] [6].

The goal is to split the requirements for system tests from requirements
for fuel-devops, which is mostly the part of the system configuration
than the separated package at the moment.
This allows to update packages for fuel-qa on every run of system tests
automatically, without manual tracking changes in [1].

* To setup a virtual environment, please use [7] instead of [1].  In the
[7] is the link to the fuel-devops source with necessary tag.

* To update requirements for fuel-qa system tests, there are two ways:

   - Install necessary packages from [1]  (it will be an additional 'pip
install' in your deploy script)
   - Run fuel-qa/utils/jenkin/system_tests.sh  with the key -N or export
the variable UPDATE_REQUIREMENTS='yes' . In this case, the script
system_tests.sh will try to install packages from [1] every run (pip
install [1] , without --upgrade), that will keep the requirements for
fuel-qa tests up-to-date automatically.   Also, there is a requirement
for fuel-devops as a package [8], which is also used by
system_tests.sh.  Fuel-devops is not packaged yet, so [8] cannot be used
for install the package, only for control that the necessary version of
the package is installed.

*Please* check your CI scripts that create virtual environments for
fuel-qa tests and update the requirements installation commands as soon
as possible!

[1]
https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements.txt

[2] https://review.openstack.org/#/c/334552/
[3] https://review.openstack.org/#/c/340319/
[4] https://review.openstack.org/#/c/340332/
[5] https://review.openstack.org/#/c/340323/
[6] https://review.openstack.org/#/c/340325/
[7]
https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements-devops-source.txt
[8]
https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements-devops.txt


-- 
Regards,
Dennis Dmitriev
QA Engineer,
Mirantis Inc. http://www.mirantis.com
e-mail/jabber: dis.x...@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] [Fuel] Mitaka stable branch

[Bogdan Dobrelya]

On 07/13/2016 11:08 AM, Vladimir Kozhukalov wrote:
> 
> 
> Few Q:
> - Is the stable/mitaka the only stable branch in the scope of the
> changes?
> 
> ​Yes, this announce is only about Mitaka branch. All other stable
> branches are to be treated as usual, i.e. no feature backports, bug
> fixes only following "master first" policy, etc.
> 
> 
> - As the master and stable/mitaka will diverge, the former might contain
> backwards incompatible changes, ending up the upgrade paths from
> stable/mitaka to future >=10.x releases will likely be *blocked* for its
> life time. Any plans how to address that?
> 
> - What about upgrade paths availability from the stable/* branches to:
>   a) stable/mitaka
>   b) future >=10.x releases?
> 
> ​Fortunately, Fuel now has nice built-in LCM that allows to run
> complicated custom scenarios (including reconfigurations/upgrades of
> existent OpenStack clusters). Vladimir Kuklin is working hard on making
> this LCM capabilities applicable to cases stable/* -> stable/mitaka. I
> believe later we'll be able to implement stable/mitaka -> Newton, etc.

That's OK for the upgrade process, while I'm not sure in the very
upgrade *possibility* if we allowed backwards incompatible changes make
it to the Newton. How would users upgrade from stable/mitaka to anything
wich might be backwards incompatible and might break things? And
features backported and being developed in both branches may conflict as
well. All of this makes the upgrade barely possible, so any ideas how
could we address that?

> 
> Let's try to imagine we removed old role based serializers from Nailgun
> in Newton release. The question is how are we going, for example, to
> add/remove nodes to/from Kilo/Liberty clusters. The answer would be we
> could add custom task graph and task based deployment engine to modify
> old clusters. I'd like Vladimir Kuklin to give some additional details.
> 
>  
> 
> 
> >
> __
> > OpenStack Development Mailing 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,
> Bogdan Dobrelya,
> Irc #bogdando
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [Fuel] Mitaka stable branch

[Vladimir Kozhukalov]

>
> Few Q:
> - Is the stable/mitaka the only stable branch in the scope of the changes?
>
​Yes, this announce is only about Mitaka branch. All other stable branches
are to be treated as usual, i.e. no feature backports, bug fixes only
following "master first" policy, etc.

>
> - As the master and stable/mitaka will diverge, the former might contain
> backwards incompatible changes, ending up the upgrade paths from
> stable/mitaka to future >=10.x releases will likely be *blocked* for its
> life time. Any plans how to address that?
>
> - What about upgrade paths availability from the stable/* branches to:
>   a) stable/mitaka
>   b) future >=10.x releases?
>
> ​Fortunately, Fuel now has nice built-in LCM that allows to run
complicated custom scenarios (including reconfigurations/upgrades of
existent OpenStack clusters). Vladimir Kuklin is working hard on making
this LCM capabilities applicable to cases stable/* -> stable/mitaka. I
believe later we'll be able to implement stable/mitaka -> Newton, etc.

Let's try to imagine we removed old role based serializers from Nailgun in
Newton release. The question is how are we going, for example, to
add/remove nodes to/from Kilo/Liberty clusters. The answer would be we
could add custom task graph and task based deployment engine to modify old
clusters. I'd like Vladimir Kuklin to give some additional details.



>
> >
> __
> > OpenStack Development Mailing 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,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] [vitrage] Vitrage Mascot Selection

[Afek, Ifat (Nokia - IL)]

Hi,

As we discussed in the IRC meeting today, we should select a Mascot for Vitrage 
project. 

Please add your suggestions in the etherpad below:
https://etherpad.openstack.org/p/vitrage-mascot

We need to select 3-5 leading suggestions, send them to OpenStack 
representative for evaluation, and then we can vote and select Vitrage mascot. 
Please go over the etherpad, and add +1 for the suggestions you like most.

Thanks,
Ifat.


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

Re: [openstack-dev] [Fuel] Mitaka stable branch

[Bogdan Dobrelya]

On 07/13/2016 10:17 AM, Vladimir Kozhukalov wrote:
> Dear colleagues,
> 
> I'd like to announce some of our plans on how we are going to
> support/develop Fuel Mitaka stable branch. The plan is as follows:
> 
> 0) We have been working hard and have fixed a lot of bugs in Mitaka
> branch as for late. This week we are going to announce 9.0.1 release
> which is stable and production ready.
> 
> 1) We are planning to backport onto stable Mitaka branch some (NOT all)
> features that are more or less regression safe. All such features will
> be thoroughly tested so to avoid lack of stability. Given this we expect
> master and stable branches will soon diverge a lot and thus it will soon
> be impossible to just cherry-pick  majority of features and bug fixes
> from master to stable and instead they often are to be re-implemented.
> It will likely require to spend twice as much time as we usually spend
> for every change that is to be landed both in master and stable.
> 
> 2) We are planning to make stable Mitaka branch even more stable and
> continue to fix bugs (even medium and low). We are not planning to
> always follow Stable Branches policy [1] and backport onto stable Mitaka
> branch only those bugs that are already merged to master. Some bugs will
> be first merged to stable and then ported to master. It is just for
> conveniece and development velocity. Since master and stable will
> diverge significantly, it won't make much sense to follow "master first"
> policy. But still all bugs that make sense both for master and for
> stable must be fixed in both these branches.
> 
> 3) Since Mitaka branch is expected to stay stable all the time, we are
> planning to set release tags (9.x) on stable branch approximately every
> month or so. We won't be forced to spend months on code freezing and
> stabilizing and thus we will be able to release features frequently (not
> all features but those are to be backported onto stable branch).

Few Q:
- Is the stable/mitaka the only stable branch in the scope of the changes?

- As the master and stable/mitaka will diverge, the former might contain
backwards incompatible changes, ending up the upgrade paths from
stable/mitaka to future >=10.x releases will likely be *blocked* for its
life time. Any plans how to address that?

- What about upgrade paths availability from the stable/* branches to:
  a) stable/mitaka
  b) future >=10.x releases?

> 
> 
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> 
> 
> Vladimir Kozhukalov
> 
> 
> __
> OpenStack Development Mailing 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,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

[Numan Siddique]

Adding the proper tags in subject

On Wed, Jul 13, 2016 at 1:22 PM, Numan Siddique  wrote:

> Hi Neutrinos,
>
> Presently, In the OVN ML2 driver we have 2 ways to sync neutron DB and OVN
> DB
>  - At neutron-server startup, OVN ML2 driver syncs the neutron DB and OVN
> DB if sync mode is set to repair.
>  - Admin can run the "neutron-ovn-db-sync-util" to sync the DBs.
>
> Recently, in the v2 of networking-odl ML2 driver (Please see (1) below
> which has more details). (ODL folks please correct me if I am wrong here)
>
>   - a journal thread is created which does the CRUD operations of neutron
> resources asynchronously (i.e it sends the REST APIs to the ODL controller).
>   - a maintenance thread is created which does some cleanup periodically
> and at startup does full sync if it detects ODL controller cold reboot.
>
>
> Few question I have
>  - can OVN ML2 driver take same or similar approach. Are there any
> advantages in taking this approach ? One advantage is neutron resources can
> be created/updated/deleted even if the OVN ML2 driver has lost connection
> to the ovsdb-server. The journal thread would eventually sync these
> resources in the OVN DB. I would like to know the communities thoughts on
> this.
>
>  - Are there are other ML2 drivers which might have to handle the DB
> sync's (cases where the other controllers also maintain their own DBs) and
> how they are handling it ?
>
>  - Can a common approach be taken to sync the neutron DB and controller
> DBs ?
>
>
>
> ---
>
> (1)
> Sync threads created by networking-odl ML2 driver
> --
> ODL ML2 driver creates 2 threads (threading.Thread module) at init
>  - Journal thread
>  - Maintenance thread
>
> Journal thread
> 
> The journal module creates a new journal table by name
> “opendaylightjournal”  -
> https://github.com/openstack/networking-odl/blob/master/networking_odl/db/models.py#L23
>
> Journal thread will be in loop waiting for the sync event from the ODL ML2
> driver.
>
>  - ODL ML2 driver resource (network, subnet, port) precommit functions
> when called by the ML2 plugin adds an entry in the “opendaylightjournal”
> table with the resource data and sets the journal operation state for this
> entry to “PENDING”.
>  - The corresponding resource postcommit function of the ODL ML2 plugin
> when called, sets the sync event flag.
>  - A timer is also created which sets the sync event flag when it expires
> (the default value is 10 seconds).
>  - Journal thread wakes up, looks into the “opendaylightjournal” table
> with the entries with state “pending” and runs the CRUD operation on those
> resources in the ODL DB. Once done, it sets the state to “completed”.
>
> Maintenance thread
> --
> Maintenance thread does 3 operations
>  - JournalCleanup - Delete completed rows from journal table
> “opendaylightjournal”.
>  - CleanupProcessing - Mark orphaned processing rows to pending.
>  - Full sync - Re-sync when detecting an ODL "cold reboot”.
>
>
>
> Thanks
> Numan
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Mitaka stable branch

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to announce some of our plans on how we are going to
support/develop Fuel Mitaka stable branch. The plan is as follows:

0) We have been working hard and have fixed a lot of bugs in Mitaka branch
as for late. This week we are going to announce 9.0.1 release which is
stable and production ready.

1) We are planning to backport onto stable Mitaka branch some (NOT all)
features that are more or less regression safe. All such features will be
thoroughly tested so to avoid lack of stability. Given this we expect
master and stable branches will soon diverge a lot and thus it will soon be
impossible to just cherry-pick  majority of features and bug fixes from
master to stable and instead they often are to be re-implemented. It will
likely require to spend twice as much time as we usually spend for every
change that is to be landed both in master and stable.

2) We are planning to make stable Mitaka branch even more stable and
continue to fix bugs (even medium and low). We are not planning to always
follow Stable Branches policy [1] and backport onto stable Mitaka branch
only those bugs that are already merged to master. Some bugs will be first
merged to stable and then ported to master. It is just for conveniece and
development velocity. Since master and stable will diverge significantly,
it won't make much sense to follow "master first" policy. But still all
bugs that make sense both for master and for stable must be fixed in both
these branches.

3) Since Mitaka branch is expected to stay stable all the time, we are
planning to set release tags (9.x) on stable branch approximately every
month or so. We won't be forced to spend months on code freezing and
stabilizing and thus we will be able to release features frequently (not
all features but those are to be backported onto stable branch).


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


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

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Andreas Jaeger]

On 2016-07-12 09:59, Markus Zoeller wrote:
> After closing the old (>18months) bug reports nobody is working on a few
> days ago [1], it became clear that the "in progress" reports are the
> majority [2]. After asking Gerrit how long it usually takes to get a fix
> merged [3], this is the result:
> 
> number of merged bug fixes within the last 365 days: 689
> merged within ~1m : 409 (~59%)
> merged within ~2m : 102 (~14%)
> merged within ~3m :  57 (~ 8%)
> merged > 3month   : 121 (~17%)
> 
> Note: This doesn't reflect the time a patch might be marked as
> "WIP". It also doesn't add up to 100% as I rounded down the
> percentages.
> 
> This made me thinking about ways to increase the review throughput of
> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
> *assume* that the fixes in the ">3m" area had inherent problems or
> waited for basic structural changes, but that's just guesswork.
> 
> The proposal is this:
> * have a TBD list with max 10 items on it (see list possibilities below)
> * add new items during nova meeting if slots are free
> * Change owners must propose their changes as meeting agenda items
> * drop change from list in nova meeting if progress is not satisfying
> 
> List possibilities:
> 1) etherpad of doom? maintained by (?|me)
> + easy to add/remove from everyone
> - hard to query
> 2) gerrit: starred by (?|me)
> + easy to add/remove from the list maintainer
> + easy to query
> - No additions/removals when the list maintainer is on vacation
> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX
> + easy to add/remove from everyone
> + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX)
> - once removed with a comment "DROPTOP10BUGFIX", a repeated
>   addition is not practical anymore.
> 4) gerrit: tag a change
> + easy to add/remove from everyone
> + easy to query
> - not yet available in our setup

You could also use a specific topic for these - instead of the bug/XXX,
use TOP10BUG.

Another suggestion: Check what neutron has done with their review board
that is available from http://status.openstack.org/reviews/ as "Gerrit
Dashboard links" - a dashboard that takes into account the launchpad bug
status and is generated using a script (see
https://review.openstack.org/298779 ),

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?

[Sahid Orentino Ferdjaoui]

On Tue, Jul 12, 2016 at 06:45:03PM +0200, Markus Zoeller wrote:
> On 12.07.2016 17:39, Sahid Orentino Ferdjaoui wrote:
> > On Tue, Jul 12, 2016 at 09:59:12AM +0200, Markus Zoeller wrote:
> >> After closing the old (>18months) bug reports nobody is working on a few
> >> days ago [1], it became clear that the "in progress" reports are the
> >> majority [2]. After asking Gerrit how long it usually takes to get a fix
> >> merged [3], this is the result:
> >>
> >> number of merged bug fixes within the last 365 days: 689
> >> merged within ~1m : 409 (~59%)
> >> merged within ~2m : 102 (~14%)
> >> merged within ~3m :  57 (~ 8%)
> >> merged > 3month   : 121 (~17%)
> >>
> >> Note: This doesn't reflect the time a patch might be marked as
> >> "WIP". It also doesn't add up to 100% as I rounded down the
> >> percentages.
> >>
> >> This made me thinking about ways to increase the review throughput of
> >> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
> >> *assume* that the fixes in the ">3m" area had inherent problems or
> >> waited for basic structural changes, but that's just guesswork.
> >>
> >> The proposal is this:
> >> * have a TBD list with max 10 items on it (see list possibilities below)
> >> * add new items during nova meeting if slots are free
> >> * Change owners must propose their changes as meeting agenda items
> >> * drop change from list in nova meeting if progress is not satisfying
> > 
> > Considering a raw list of patches would be difficult to maintain, it's
> > time consuming and Nova has contributors working on different areas
> > which are sometimes really differents. How to order this list and how
> > to consider a patch is satisfying the progress policy.
> 
> I'm not sure if I understand the concerns correctly. The list
> possibilities below seem to be easy to maintain. My assumption is, that
> minimizing the "wait time" (reviewers wait for new patchsets OR change
> owners wait for new reviews) can increase the throughput. It makes the
> commitment of change owners and reviewers necessary though.
> I don't think that the list needs specific ordering rules. As I want to
> target bug fixes with this proposal, the ordering is given by the impact
> of the bugs.

How I see that you want to concentrate reviewers to be on 10 patches
every weeks but here the bottleneck would be the authors, no?

I think we have a pretty good flow, most of the bug fixes which need
to get attention are reviewed quickly.

> > To make things working we should find some automations and have one
> > list by areas which is probably the purpose of tags in gerrit.
> 
> This could result in silo mentality and discussions why list A gets
> preferred over list B. That's why I want to avoid having multiple lists.
> It's about fixing issues in Nova, not fixing issues in
> .

I don't think that could result in silo mentality and I remember a
initiative in the same way but with etherpad and so difficult to
maitain.

> > Since we don't have such feature on our gerrit yet, a possible
> > solution would be to introduce a tag in commit messages which reflects
> > the subteam or area related. Then a simple script could parse reviews
> > in progress to print them somewhere.
> 
> Changing the commit message creates a new patchset which triggers the
> gate checks again, that's why I thought making comments with a keyword
> which can be queried is less trouble.

Gerrit comments are lost when the patch get merged, we may want to
provide some stats from these tags in future that's why I think commit
message is better. Also if we only change commit messages, all of the
gate is re-executed ?

> > So each subteams can have a view of the work in progress which could
> > make things moving faster.
> > 
> > The point would be to order the lists by importance but we can expect
> > the lists relatively small.
> > 
> >> List possibilities:
> >> 1) etherpad of doom? maintained by (?|me)
> >> + easy to add/remove from everyone
> >> - hard to query
> >> 2) gerrit: starred by (?|me)
> >> + easy to add/remove from the list maintainer
> >> + easy to query
> >> - No additions/removals when the list maintainer is on vacation
> >> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX
> >> + easy to add/remove from everyone
> >> + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX)
> >> - once removed with a comment "DROPTOP10BUGFIX", a repeated
> >>   addition is not practical anymore.
> >> 4) gerrit: tag a change
> >> + easy to add/remove from everyone
> >> + easy to query
> >> - not yet available in our setup
> >>
> >> Personally I prefer 3, as it doesn't rely on a single person and the
> >> tooling is ready for that. It could be sufficient until one of the next
> >> infra Gerrit updates brings us 4. I'd like to avoid 1+2.
> >>
> >> My hope is, that a focused list helps us to get (few) things done faster
> >> and increase the overall