Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Oleg Bondarev]

+1!

On Fri, Dec 16, 2016 at 11:05 AM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:

> +1
> --
> -
> Andreas
> IRC: andreas_s
>
>
>
> On Fr, 2016-12-16 at 00:14 +0100, Armando M. wrote:
> > Hi neutrinos,
> >
> >
> > Miguel Lavalle has been driving the project forward consistently and
> > reliably. I would like to propose him to be entrusted with +2/+A
> > rights in the areas he's been most prolific, which are L3 and DHCP.
> >
> >
> > At the same time, I'd like to propose Brian Haley as our next Chief L3
> > Officer. Both of them have worked with Carl Baldwin extensively and
> > that can only be a guarantee of quality.
> >
> >
> > Cheers,
> > Armando
> >
> >
> > [1] https://review.openstack.org/#/c/411531/
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Oleg Bondarev]

+1

On Fri, Dec 16, 2016 at 10:04 AM, reedip banerjee 
wrote:

> +1 for both Ryan and Nate :)
>
> On Fri, Dec 16, 2016 at 10:03 AM, Vikram Choudhary 
> wrote:
>
>> +1 for Ryan!
>>
>> On Dec 16, 2016 7:23 AM, "Sridar Kandaswamy (skandasw)" <
>> skand...@cisco.com> wrote:
>>
>>> +1. From the neutron-fwaas perspective, Nate has been instrumental in
>>> driving our integration with neutron on the agent extension framework,
>>> neutron-lib as well as on CI.
>>>
>>> Thanks
>>>
>>> Sridar
>>>
>>> From: Kevin Benton 
>>> Reply-To: OpenStack List 
>>> Date: Thursday, December 15, 2016 at 5:00 PM
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate
>>> Johnston as service LTs
>>>
>>> +1
>>>
>>> On Dec 15, 2016 19:03, "Armando M."  wrote:
>>>
 Hi neutrinos,

 I would like to propose Ryan and Nate as the go-to fellows for
 service-related patches.

 Both are core in their repos of focus, namely neutron-dynamic-routing
 and neutron-fwaas, and have a good understanding of the service framework,
 the agent framework and other bits and pieces. At this point, entrusting
 them with the responsibility is almost a formality.

 Cheers,
 Armando

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

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for 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] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Andreas Scheuring]

+1
-- 
-
Andreas 
IRC: andreas_s



On Fr, 2016-12-16 at 00:14 +0100, Armando M. wrote:
> Hi neutrinos,
> 
> 
> Miguel Lavalle has been driving the project forward consistently and
> reliably. I would like to propose him to be entrusted with +2/+A
> rights in the areas he's been most prolific, which are L3 and DHCP. 
> 
> 
> At the same time, I'd like to propose Brian Haley as our next Chief L3
> Officer. Both of them have worked with Carl Baldwin extensively and
> that can only be a guarantee of quality.
> 
> 
> Cheers,
> Armando 
> 
> 
> [1] https://review.openstack.org/#/c/411531/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[reedip banerjee]

Congrats Abhishek ...

On Fri, Dec 16, 2016 at 6:42 AM, Abhishek Raut  wrote:

> Thank you!
>
> From: "Armando M." 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, December 15, 2016 at 2:57 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] Proposing Abhishek Raut as
> neutronclient core
>
>
>
> On 15 December 2016 at 09:50, Akihiro Motoki  wrote:
>
>> +1
>>
>
> Welcome to the team Abhishek!
>
>
>>
>> 2016-12-14 10:22 GMT+09:00 Armando M. :
>>
>>> Hi folks,
>>>
>>> Abhishek Raut's recent involvement in OSC and python-neutronclient has
>>> helped moving a few efforts along in the right direction. I would like to
>>> suggest we double down on core firepower for the neutronclient repo
>>> alongside Akihiro [1].
>>>
>>> This not only will help speed up our transition to OSC CLI, but also
>>> improve the number of folks who can effectively liasion with the OSC team,
>>> and look after the needs of neutron's client repo.
>>>
>>> Many thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/410485/
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[reedip banerjee]

+1 for both Ryan and Nate :)

On Fri, Dec 16, 2016 at 10:03 AM, Vikram Choudhary 
wrote:

> +1 for Ryan!
>
> On Dec 16, 2016 7:23 AM, "Sridar Kandaswamy (skandasw)" <
> skand...@cisco.com> wrote:
>
>> +1. From the neutron-fwaas perspective, Nate has been instrumental in
>> driving our integration with neutron on the agent extension framework,
>> neutron-lib as well as on CI.
>>
>> Thanks
>>
>> Sridar
>>
>> From: Kevin Benton 
>> Reply-To: OpenStack List 
>> Date: Thursday, December 15, 2016 at 5:00 PM
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate
>> Johnston as service LTs
>>
>> +1
>>
>> On Dec 15, 2016 19:03, "Armando M."  wrote:
>>
>>> Hi neutrinos,
>>>
>>> I would like to propose Ryan and Nate as the go-to fellows for
>>> service-related patches.
>>>
>>> Both are core in their repos of focus, namely neutron-dynamic-routing
>>> and neutron-fwaas, and have a good understanding of the service framework,
>>> the agent framework and other bits and pieces. At this point, entrusting
>>> them with the responsibility is almost a formality.
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/411536/
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [meteos] Meteos Released !!

[Hiroyuki Eguchi]

Hi all,

I'm pleased to announce the release of Meteos.

Meteos is Machine Learning as a Service (MLaaS) in Apache Spark.

Meteos allows users to analyze huge amount of data and predict a value by data 
mining and machine learning algorithms.
Meteos create a workspace of Machine Learning via sahara spark plugin and 
manage some resources and jobs regarding Machine Learning.

Everyone can participate in this project as a user, developer, reviewer in the 
same way as another OpenStack projects.

Please give it a try.
If you find any requests and comments, please feel free to feedback.

See the following documents to find the relevant information:

[Wiki]
https://wiki.openstack.org/wiki/Meteos

[Installation Document]
https://wiki.openstack.org/wiki/Meteos/Devstack

[Examples]
Predict a Sales Figures by using LinearRegression Model
https://wiki.openstack.org/wiki/Meteos/ExampleLinear

Make a Decision to buy a stock by using DecisionTree Model
https://wiki.openstack.org/wiki/Meteos/ExampleDecisionTree

Recommend a Movie by using Recommendation Model
https://wiki.openstack.org/wiki/Meteos/ExampleRecommend

Search Synonyms by using Word2Vec Model
https://wiki.openstack.org/wiki/Meteos/ExampleWord2Vec


Thanks.
Hiroyuki Eguchi
__
OpenStack Development Mailing List (not for 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] proposing Ryan Tidwell and Nate Johnston as service LTs

[Vikram Choudhary]

+1 for Ryan!

On Dec 16, 2016 7:23 AM, "Sridar Kandaswamy (skandasw)" 
wrote:

> +1. From the neutron-fwaas perspective, Nate has been instrumental in
> driving our integration with neutron on the agent extension framework,
> neutron-lib as well as on CI.
>
> Thanks
>
> Sridar
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Thursday, December 15, 2016 at 5:00 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate
> Johnston as service LTs
>
> +1
>
> On Dec 15, 2016 19:03, "Armando M."  wrote:
>
>> Hi neutrinos,
>>
>> I would like to propose Ryan and Nate as the go-to fellows for
>> service-related patches.
>>
>> Both are core in their repos of focus, namely neutron-dynamic-routing and
>> neutron-fwaas, and have a good understanding of the service framework, the
>> agent framework and other bits and pieces. At this point, entrusting them
>> with the responsibility is almost a formality.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/411536/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] Weekly wrap-up

[Richard Jones]

Hi folks,

No Horizon meeting next week! I'll be around the week after (28th
December) so if anyone else is around we can totally have a meeting
then.

Things that have happened this week, including in the team meeting[1]

Ocata-2 was tagged!

xstatic-angular-bootstrap 2.2.0.0 was released, which promptly broke
Ocata-2 (and Ocata-1, you're welcome). We knew it was coming, and Rob
Cresswell had a compatibility patch in place ready to go, so master
was back to working within half an hour of the upper-constraints patch
enabling 2.2.0.0! If you notice anything busted in Horizon related to
bootstrap please file a bug!

I'd like to remind everyone that we have a blueprint in play which
describes our approach to API microversions[2]. Rob has a patch which
will land imminently that implements the core of the design. Please
hold off implementing your own version settings/checks! We've seen a
few microversion-related patches appear recently, and that's great to
see, we just need to make sure we're all heading in the same
direction.

I've put up the first patch using ui-router which rather dramatically
alters the Swift UI[3], so I'd like some feedback on it please.

We've got about five(ish) weeks until Feature Freeze[4], folks, so all
the help we can get on the priority patches[5] (reviews or coding
help) is appreciated!


I hope you all get to have some time off, and have an enjoyable holiday,

   Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-14-20.00.html
[2] https://blueprints.launchpad.net/horizon/+spec/microversion-support
[3] https://review.openstack.org/#/c/350523
[4] https://releases.openstack.org/ocata/schedule.html
[5] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open

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

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Thu, Dec 15, 2016 at 04:02:41PM +1100, Joshua Hesketh wrote:
> On Thu, Dec 15, 2016 at 12:48 AM, Ian Cordasco 
> wrote:
> 
> > -Original Message-
> > From: Joshua Hesketh 
> > Reply: OpenStack Development Mailing List (not for usage questions) <
> > openstack-dev@lists.openstack.org>
> > Date: December 14, 2016 at 06:56:22
> > To: OpenStack Development Mailing List ,
> > openstack-infra 
> > Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> > Tagging liberty as EOL
> >
> > > The repos listed[0] have had stable/liberty branch removed and replaced
> > > with a liberty-eol tag. Any open reviews have been abandoned.
> > >
> > > Please let me know if there are any mistakes or latecomers to the list.
> > >
> > > Cheers,
> > > Josh
> > >
> > > [0]
> > > https://gist.githubusercontent.com/tbreeds/
> > 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> >
> > Glance was late to the party, but it should have had its liberty branches
> > EOL'd as well.
> >
> 
> 
> Tony's comment on https://review.openstack.org/#/c/410536/ implies there
> may be some steps to do first. I'll wait on confirmation from Tony before
> retiring the branch.

I don't know how to answer that question :(

Due to a failure in the release pipline [1] some of the release jobs haven't
been done.  The point of https://review.openstack.org/#/c/410536/ was to make
it posisble to generate the docs from liberty with the end-game being an 11.0.2
retagging (or an 11.0.3 release) release that works through the pipeline and
generates all the artifacts.  Sadly it isn't working as that chnage is failing
in the same way as the release-pipeline [2].

So if infra can re-run the indiviual jobs or at the very least drop a
glance-11.0.2.tar.gz into tarballs.openstack.org then I think we can retire the
liberty branch of glance.

If that can't be done then we need to work out what *can* be done

Yours Tony.

[1] 
http://lists.openstack.org/pipermail/release-job-failures/2016-December/000324.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108899.html


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] Upgrade readiness check notes

[Matt Riedemann]

A few of us have talked about writing a command to tell when you're 
ready to upgrade (restart services with new code) for Ocata because we 
have a few things landing in Ocata which are going from optional to 
required, namely cells v2 and the placement API service.


We already have the 030 API DB migration for cells v2 which went into 
the o-2 milestone today which breaks the API DB schema migrations if you 
haven't run at least 'nova-manage cell_v2 simple_cell_setup'.


We have noted a few times in the placement/resource providers 
discussions the need for something similar for the placement API, but 
because that spans multiple databases (API and cell DBs), and because it 
involves making sure the service is up and we can make REST API requests 
to it, we can't do it in just a DB schema migration.


So today dansmith, jaypipes, sdague, edleafe and myself jumped on a call 
to go over some notes / ideas being kicked around in an etherpad:


https://etherpad.openstack.org/p/nova-ocata-ready-for-upgrade

We agreed on writing a new CLI outside of nova-manage called nova-status 
which can perform the upgrade readiness check for both cells v2 and the 
placement API.


For cells v2 it's really going to check basically the same things as the 
030 API DB schema migration.


For the placement API, it's going to do at least two things:

1. Try and make a request to / on the placement API endpoint from the 
service catalog. This will at least check that (a) the placement 
endpoint is in the service catalog, (b) nova.conf is configured with 
credentials to make the request and (c) the service is running and 
accepting requests.


2. Count the number of resource_providers in the API DB and compare that 
to the number of compute_nodes in the cell DB and if there are fewer 
resource providers than compute nodes, it's an issue which we'll flag in 
the upgrade readiness CLI. This doesn't necessarily mean you can't 
upgrade to Ocata, it just means there might be fewer computes available 
for scheduling once you get to Ocata, so the chance of rebuilds and 
NoValidHost increases until the computes are upgraded to Ocata and 
configured to use the placement service to report 
inventories/usage/allocations for RAM, CPU and disk.


That 2nd point is important because we also agreed to make the filter 
scheduler NOT fallback to querying the compute_nodes table if there are 
no resource providers available from the placement API. That means when 
the scheduler gets a request to build or move a server, it's going to 
query the placement API for possible resource providers to serve the 
CPU/RAM/disk requirements for the build request spec and if nothing is 
available it'll result in a NoValidHost failure. That is a change in 
direction from a fallback plan we originally had in the spec here:


https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/resource-providers-scheduler-db-filters.html#other-deployer-impact

We're changing direction on that because we really want to make the 
placement service required in Ocata and not delay it's usage for another 
release, because as long as it's optional people are going to avoid 
deploying and using it, which pushes us further out from forward 
progress around the scheduler, placement service and resource tracker.


Regarding where this new CLI lived, and how it's deployed, and when it's 
called, we had discussed a few options there, even talking about 
splitting it out into it's own pip-installable package. We have a few 
options but we aren't going to be totally clear on that until we get the 
POC code written and then try to integrate it into grenade, so we're 
basically deferring that discussion/decision for now. Wherever it is, we 
know it needs to be run with the Ocata code (since that's where it's 
going to be available), and after running the simple_cell_setup 
command), and it needs to be run before restarting services with the 
Ocata code. I'm not totally sure if it needs to be run after the DB 
migrations or not, maybe Dan can clarify, but we'll sort it out for sure 
when we integrate with grenade.


Anyway, the POC is started here:

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

I've got the basic framework in place and there is a patch on top that 
does the cells v2 check. I plan on working on the placement API checks 
tomorrow.


If you've read this far, congratulations. This email is really just 
about communicating that things are happening because we have talked 
about the need for this a few times, but hadn't hashed it out yet.


--

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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Wed, Dec 14, 2016 at 08:28:46PM -0800, Sumit Naiksatam wrote:
> On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
>  wrote:
> > The repos listed[0] have had stable/liberty branch removed and replaced with
> > a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
> 
> Hi Joshua, Apologies for chiming in late, but we request that the
> openstack/group-based-policy repo’s stable/liberty branch be _not_
> removed/EOL’ed and the currently open patches not be abandoned. We
> have consumers of this branch and we do backport bug fixes. Thanks in
> advance!

As Josh pointed out you're not in the list due to the problems we had retiring
kilo.

I do have a request for you though.  Currently your gate (both kilo and
liberty) relies on devstack and requirements and probably isn't testing what
you thin it is.  Can you please update project-config with a gate config that
will work on this branches *without* the need to keep liberty (and kilo) alive
in those repos.

If you need help feel free to reach out.

Yours Tony.


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

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Dec. 16 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Daisy CI Progress
3) OpenStack Version management
4) AoB

B.R.,
Zhijiang



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

[openstack-dev] [zaqar] Next meeting in 2017

[Fei Long Wang]

Hi team,

Due to most of the team members will be on vacation in the next couple
of weeks, so we will cancel the next 3 meetings. And the first meeting
of 2017 will be 10th of Jan.

And I also proposed the new meeting time based on our poll, see
https://review.openstack.org/411564 If the patch is merged before 10th
Jan, then we will follow the new meeting time. Thanks.

Merry Christmas and Happy New Year!

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for 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] proposing Ryan Tidwell and Nate Johnston as service LTs

[Sridar Kandaswamy (skandasw)]

+1. From the neutron-fwaas perspective, Nate has been instrumental in driving 
our integration with neutron on the agent extension framework, neutron-lib as 
well as on CI.

Thanks

Sridar

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Thursday, December 15, 2016 at 5:00 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston 
as service LTs

+1

On Dec 15, 2016 19:03, "Armando M." 
> wrote:
Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for service-related 
patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and 
neutron-fwaas, and have a good understanding of the service framework, the 
agent framework and other bits and pieces. At this point, entrusting them with 
the responsibility is almost a formality.

Cheers,
Armando

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

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

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

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Vasudevan, Swaminathan (PNB Roseville)]

+1

From: Armando M. [mailto:arma...@gmail.com]
Sent: Thursday, December 15, 2016 3:15 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and 
Brian Haley as L3 Lt

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and reliably. 
I would like to propose him to be entrusted with +2/+A rights in the areas he's 
been most prolific, which are L3 and DHCP.

At the same time, I'd like to propose Brian Haley as our next Chief L3 Officer. 
Both of them have worked with Carl Baldwin extensively and that can only be a 
guarantee of quality.

Cheers,
Armando

[1] https://review.openstack.org/#/c/411531/
__
OpenStack Development Mailing List (not for 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] proposing Ryan Tidwell and Nate Johnston as service LTs

[Vasudevan, Swaminathan (PNB Roseville)]

+1

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, December 15, 2016 5:00 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston 
as service LTs

+1

On Dec 15, 2016 19:03, "Armando M." 
> wrote:
Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for service-related 
patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and 
neutron-fwaas, and have a good understanding of the service framework, the 
agent framework and other bits and pieces. At this point, entrusting them with 
the responsibility is almost a formality.

Cheers,
Armando

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

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

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Abhishek Raut]

Thank you!

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, December 15, 2016 at 2:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient 
core



On 15 December 2016 at 09:50, Akihiro Motoki 
> wrote:
+1

Welcome to the team Abhishek!


2016-12-14 10:22 GMT+09:00 Armando M. 
>:
Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has helped 
moving a few efforts along in the right direction. I would like to suggest we 
double down on core firepower for the neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also improve 
the number of folks who can effectively liasion with the OSC team, and look 
after the needs of neutron's client repo.

Many thanks,
Armando

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

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



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


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

Re: [openstack-dev] [release][ptl][all] self-service branch management

[joehuang]

Hello, Doug,

This is great. One question about the branch patches. In the past, when a new 
branch was created, we often have to update the devstack plugin to pull the 
code from correct branch. So if self-service branch management is available, 
will the devstack plugin will be updated with one patch too?

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 14 December 2016 21:45
To: openstack-dev
Subject: [openstack-dev] [release][ptl][all] self-service branch management

[Sending again due to mail delivery issues.]

The release team is pleased to announce that the branch automation
work is now complete, and that teams can now manage feature and
stable branch creation through the openstack/releases repository.

Creating a branch is very similar to creating a release: Edit the
appropriate file in the releases repo to add the branch information,
let the release team review it, and then when the patch is approved
the bots make your branch. New branches come with patches to update
.gitreview, reno, and constraint settings where needed.

For the complete details about how to format a branch request, see
the README.rst file in the repo [1].

Thanks, as always, to the Infra team for their help in implementing
this automation.

Doug

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

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

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

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Kevin Benton]

+1

On Dec 15, 2016 18:18, "Armando M."  wrote:

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and
reliably. I would like to propose him to be entrusted with +2/+A rights in
the areas he's been most prolific, which are L3 and DHCP.

At the same time, I'd like to propose Brian Haley as our next Chief L3
Officer. Both of them have worked with Carl Baldwin extensively and that
can only be a guarantee of quality.

Cheers,
Armando

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

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

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Kevin Benton]

+1

On Dec 15, 2016 19:03, "Armando M."  wrote:

> Hi neutrinos,
>
> I would like to propose Ryan and Nate as the go-to fellows for
> service-related patches.
>
> Both are core in their repos of focus, namely neutron-dynamic-routing and
> neutron-fwaas, and have a good understanding of the service framework, the
> agent framework and other bits and pieces. At this point, entrusting them
> with the responsibility is almost a formality.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/411536/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] [ci] recheck impact on CI infrastructure

[Emilien Macchi]

On Thu, Dec 15, 2016 at 12:22 PM, Sven Anderson  wrote:
> Hi all,
>
> while I was waiting again for the CI to be fixed and didn't want to
> torture it with additional rechecks, I wanted to find out, how much of
> our CI infrastructure we waste with rechecks. My assumption was that
> every recheck is a waste of resources based on a false negative, because
> it renders the previous build useless. So I wrote a small script[1] to
> calculate how many rechecks are made on average per built patch-set. It
> calculates the number of patch-sets of merged changes that CI was
> testing (some patch-sets are not, because they were updated before CI
> started testing), the number of rechecks issued on these patch-sets, and
> a value "CI-factor", which is the factor by which the rechecks increased
> the the CI runs, that is, without rechecks it would be 1, if every
> tested patch-set would have exactly one recheck it would be 2.

I see 2 different topics here.

# One is not related to $topic but still worth mentioning:
"while I was waiting again for the CI to be fixed"

This week has been tough, and many of us burnt our time to resolve
different complex problems in TripleO CI, mostly related to external
dependencies (qemu upgrade, centos 7.3 upgrade, tripleo-ci infra,
etc).
Resolving these problems is very challenging and you'll notice that
only a few of us actually work on this task, while a lot of people
continue to push their features "hoping" that it will pass CI
sometimes and if not, well, we'll do 'recheck'.
That is a way of working I would say. I personally can't continue to
code if the project I'm working on has broken CI.

In a previous experience, I've been working in a team where everyone
stopped regular work when CI was broken and focus on fixing it.
I'm not saying everyone should stop their tasks and help, but this
"wait and see" comment doesn't actually help us to move forward.
People need to get more involved in CI and be more helpful. I know
it's difficult, but it's something anyone can learn, like you would
learn how to write Python code for example.


# The second one is about the actual $topic and your stats.
Yes we have been thinking about a way to optimize the way we restart
CI jobs and this is under discussion:
https://review.openstack.org/#/c/411450/

As you can see, there is some pushback from Clark who is infra-core,
so we might want to continue the discussion here and see how it goes.


On the long-term, our goal is to have more consistency in the way we
test TripleO and get more adoption in the tools we're developing for
CI, so they are more consumable from anyone in our community. Also we
hope to have more people involved when things are broken, and not
always the same folks spending days and evenings to "extinguish
fires". We are working hard on CI stabilization and consolidation with
multinode scenarios and OVB improvements, but it takes time and
iterations.

Any help is highly welcome here.


> The results were not as bad as my feeling, we are below 2 for most of
> the projects I tested. :-) But still, on THT for instance we use 71%
> more resources because of the false negatives. I made monthly
> breakdowns, so you can see a positive trend at least.
>
>
> Here the results:
>
> Project: tripleo-heat-templates
>
>  month  patches  rechecks  CI-factor
>  1  221   102   1.46
>  2  282   300   2.06
>  3  588   567   1.96
>  4  220   253   2.15
>  5  333   242   1.73
>  6  459   325   1.71
>  7  612   390   1.64
>  8  694   442   1.64
>  9  717   440   1.61
> 10  474   316   1.67
> 11  358   189   1.53
> 12  16880   1.48
>  total 5126  3646   1.71
>
> Project: tripleo-common
>
>  month  patches  rechecks  CI-factor
>  1   73291.4
>  2   5948   1.81
>  3   92   1012.1
>  4   1719   2.12
>  5   4727   1.57
>  6   8346   1.55
>  7   6626   1.39
>  8  209   102   1.49
>  9  261   129   1.49
> 10  11051   1.46
> 11  12147   1.39
> 12   4019   1.48
>  total 1178   644   1.55
>
> Project: tripleo-puppet-elements
>
>  month  patches  rechecks  CI-factor
>  1   24 9   1.38
>  2920   3.22
>  3716   3.29
>  4924   3.67
>  5   1417   2.21
>  6   1733   2.94
>  7   1216   2.33
>  8   15212.4
>  9   10142.4
> 10   12 5   1.42
> 11   3425   1.74
> 12   10132.3
>  total  173   

[openstack-dev] [neutron] multinode CI jobs in the gate

[Armando M.]

Hi Neutrinos,

Infra patch proposed in [1] got me thinking again about what we shall do
when it comes to multinode testing in the gate and how to focus our testing
and CI efforts upstream going forward. My line of thinking has always been
that multinode resources should be devoted to configurations whose coverage
fully benefit from the inherent nature of the distributed deployment, and
that means giving priority to DVR+HA and demote other configurations that
use centralized routing.

I know that some of you in team have worked on this, but I am a bit behind
on the latest status update. Any good soul willing to bring a strapped (for
time) PTL up to speed?

Cheers,
Armando

[1] https://review.openstack.org/#/c/411263/
__
OpenStack Development Mailing List (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] proposing Ryan Tidwell and Nate Johnston as service LTs

[Armando M.]

 Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for
service-related patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and
neutron-fwaas, and have a good understanding of the service framework, the
agent framework and other bits and pieces. At this point, entrusting them
with the responsibility is almost a formality.

Cheers,
Armando

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

Re: [openstack-dev] [architecture][api][Nova][Neutron][Cinder] nova-compute's architecture/API

[Armando M.]

On 16 December 2016 at 00:01, Clint Byrum  wrote:

> So, I've been quietly ranting in hallways about this for a while. I may
> be way way off base here. I want to kick the discussion off, so I've
> submitted a proposal to the arch-wg about it. Please if you're interested
> in how Nova/Neutron/Cinder interact with nova-compute, I think it might
> be worthwhile to read it and get it into a factual state, so the arch-wg
> can do a deeper analysis. Please do rip it to shreds in comments, and
> feel free to revise it and add more details. Thanks very much!
>
> https://review.openstack.org/411527
>
>
Noted! I'll bring this up at the next team meeting. Thanks for spearheading
this!


Cheers,
Armando

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

[openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Armando M.]

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and
reliably. I would like to propose him to be entrusted with +2/+A rights in
the areas he's been most prolific, which are L3 and DHCP.

At the same time, I'd like to propose Brian Haley as our next Chief L3
Officer. Both of them have worked with Carl Baldwin extensively and that
can only be a guarantee of quality.

Cheers,
Armando

[1] https://review.openstack.org/#/c/411531/
__
OpenStack Development Mailing List (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] [architecture][api][Nova][Neutron][Cinder] nova-compute's architecture/API

[Clint Byrum]

So, I've been quietly ranting in hallways about this for a while. I may
be way way off base here. I want to kick the discussion off, so I've
submitted a proposal to the arch-wg about it. Please if you're interested
in how Nova/Neutron/Cinder interact with nova-compute, I think it might
be worthwhile to read it and get it into a factual state, so the arch-wg
can do a deeper analysis. Please do rip it to shreds in comments, and
feel free to revise it and add more details. Thanks very much!

https://review.openstack.org/411527

__
OpenStack Development Mailing List (not for 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] Proposing Abhishek Raut as neutronclient core

[Armando M.]

On 15 December 2016 at 09:50, Akihiro Motoki  wrote:

> +1
>

Welcome to the team Abhishek!


>
> 2016-12-14 10:22 GMT+09:00 Armando M. :
>
>> Hi folks,
>>
>> Abhishek Raut's recent involvement in OSC and python-neutronclient has
>> helped moving a few efforts along in the right direction. I would like to
>> suggest we double down on core firepower for the neutronclient repo
>> alongside Akihiro [1].
>>
>> This not only will help speed up our transition to OSC CLI, but also
>> improve the number of folks who can effectively liasion with the OSC team,
>> and look after the needs of neutron's client repo.
>>
>> Many thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/410485/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [architecture] Updates from the Architecture Working Group

[Clint Byrum]

Greetings!

We've had a slow couple of months since Barcelona, and I expect we'll
continue to go very slow for the rest of 2016, but we definitely don't
want to lose momentum, so here is what we've been up to and where we're
going in the immediate future:

 * arch-wg repo is live - This is the repository where we'll track work
   as it moves through our process. Currently we have one proposal
   merged, which we'll be discussing here on the ML and in our IRC
   meetings, and which should lead to a cross-project spec at the very
   least. git clone https://git.openstack.org/openstack/arch-wg if you
   are curious and/or want to help.

 * APAC friendly time slot not working out - Basically, 19:00 in my
   house is busier than I had expected. So I haven't been able to chair
   any APAC friendly timeslot meetings yet. Apologies for those who
   tried to attend. If there is anyone who would like to chair that
   meeting slot, please join #openstack-architecture on Freenode and
   ping me (SpamapS).

 * 2016 meetings done - Those of us who have been the most active in
   our meetings have all agreed that we should cancel the rest of the
   meetings for 2016. So there will be no Arch-WG meeting until the
   first week of January, 2017.

__
OpenStack Development Mailing List (not for 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] Network Configuration in TripleO UI

[Ben Nemec]

On 12/08/2016 08:05 AM, Jiri Tomasek wrote:

Hi all,

I've been investigating how to implement TripleO network configuration
in TripleO UI. Based on my findings I'd like to propose a solution.

tl;dr proposal: Slightly refactor Network environment files to match GUI
usage, Use Jinja Templating to generate dynamic parts of the
templates/environments


# Overview

I've used Ben Nemec's amazing Network template generator as a reference
to help me understand how the network configuration works [1]. In
general the process of configuring the network in TripleO is:

Define which Networks we intend to use -> Assign Roles to the Networks
(+ Assign Role Services to the Network) -> Generate NIC config templates
based on previous information



[snip]

# The proposal

So having described previous, here is the approach I think we should use
to achieve network configuration using TripleO UI:

1. Put networks definitions into separate environment for each network:
- this way GUI can provide a list of networks available to use and let
user select which of them he wants to use. These environments are not
dynamic and if user wants to add a new network, he does so by creating
new templates and environment for it. UI also provides means to
configure parameters for each network at this point (if needed).

For example the environment for a Storage Network looks like this:

resource_registry:
  OS::TripleO::Network::Storage: ../network/storage.yaml
  OS::TripleO::Network::Ports::StorageVipPort:
../network/ports/storage.yaml


This seems like an obvious improvement, and is essentially how my tool 
works too except that it munges all of the individual environments back 
together at the end.


Definite +1 from me.



2. Assign Roles to Networks
Having the Networks selected as well as Roles defined, TripleO UI
provides user with means to assign Roles to Networks. This step involves
generating the network-environment.yaml file. So TripleO UI sends the
mapping of roles to network in json format to tripleo-common which in
turn uses network-isolation.j2.yaml Jinja template to generate the
environment file. I expect that pre-defined network-isolation.yaml will
be included in default plan so the user does not need to start from
scratch. Tripleo-common also provides an action to fetch network-roles
assignment data by parsing the network-isolation.yaml

In addition, user is able to assign individual Role Services to a
Network. ServiceNetMap parameter is currently used for this. GUI needs
to make sure that it represents Services-Networks assignment grouped by
Role so it is ensured that user assigns Services to only networks where
their Role is assigned.


This sounds reasonable to me, but I do want to note that assigning roles 
to networks feels a little backwards to me.  I tend to think of a role 
as kind of the top level thing here, to which we assign other things 
(services and networks, for example).  So my mental model kind of looks 
like:


roles:
  Controller:
networks:
  - provision
  - external
  - internal
  ...
  Compute:
networks:
  -provision
  ...

as opposed to what I think you're describing, which is

networks:
  Provision:
roles:
  - controller
  - compute
  External:
roles:
  - controller
  ...

Maybe there are benefits to modeling it as the latter, but I think the 
former fits better with the composable roles architecture.




3. Generate NIC Config templates
TripleO UI provides means to configure NICS, Bonds etc. for each Role,
using the information from previous steps. It sends the data in json
format to tripleo-common which then generates nic config templates for
each Role based on network/config/nic-configs/role.j2.yaml Jinja
template and generates network-environment.yaml based on
network-environment.j2.yaml which references those templates.

Note that network-environment.j2.yaml probably can't be combined with
network-isolation.j2.yaml as every time that environment would need to
get updated, all data the template needs would need to be provided.

There are wireframes made by Liz Blanchard currently available [5],
althought they are not exactly up to date to this proposal. Ideally
whole network configuration would happen on a screen based on the
graphical representation of network [6].


Any comments to this proposal are very welcome, please note that I am
not a networking expert so I might be missing something.

There is a spec [7] in progress aimed for Ocata, but the feature will
highly probably not land in Ocata, so we'll need to update the spec and
move it to next cycle.


[1]
http://blog.nemebean.com/content/tripleo-network-isolation-template-generator

[2] https://github.com/openstack/tripleo-heat-templates
[3]
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/network-environment.yaml

[4]
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/network-isolation.yaml

[5] 

Re: [openstack-dev] [tripleo] [ci] recheck impact on CI infrastructure

[Diana Clarke]

Neat, thanks Sven!

Here are the nova stats:

http://paste.openstack.org/show/592551/

--diana

On Thu, Dec 15, 2016 at 12:22 PM, Sven Anderson  wrote:
> Hi all,
>
> while I was waiting again for the CI to be fixed and didn't want to
> torture it with additional rechecks, I wanted to find out, how much of
> our CI infrastructure we waste with rechecks. My assumption was that
> every recheck is a waste of resources based on a false negative, because
> it renders the previous build useless. So I wrote a small script[1] to
> calculate how many rechecks are made on average per built patch-set. It
> calculates the number of patch-sets of merged changes that CI was
> testing (some patch-sets are not, because they were updated before CI
> started testing), the number of rechecks issued on these patch-sets, and
> a value "CI-factor", which is the factor by which the rechecks increased
> the the CI runs, that is, without rechecks it would be 1, if every
> tested patch-set would have exactly one recheck it would be 2.
>
> The results were not as bad as my feeling, we are below 2 for most of
> the projects I tested. :-) But still, on THT for instance we use 71%
> more resources because of the false negatives. I made monthly
> breakdowns, so you can see a positive trend at least.
>
>
> Here the results:
>
> Project: tripleo-heat-templates
>
>  month  patches  rechecks  CI-factor
>  1  221   102   1.46
>  2  282   300   2.06
>  3  588   567   1.96
>  4  220   253   2.15
>  5  333   242   1.73
>  6  459   325   1.71
>  7  612   390   1.64
>  8  694   442   1.64
>  9  717   440   1.61
> 10  474   316   1.67
> 11  358   189   1.53
> 12  16880   1.48
>  total 5126  3646   1.71
>
> Project: tripleo-common
>
>  month  patches  rechecks  CI-factor
>  1   73291.4
>  2   5948   1.81
>  3   92   1012.1
>  4   1719   2.12
>  5   4727   1.57
>  6   8346   1.55
>  7   6626   1.39
>  8  209   102   1.49
>  9  261   129   1.49
> 10  11051   1.46
> 11  12147   1.39
> 12   4019   1.48
>  total 1178   644   1.55
>
> Project: tripleo-puppet-elements
>
>  month  patches  rechecks  CI-factor
>  1   24 9   1.38
>  2920   3.22
>  3716   3.29
>  4924   3.67
>  5   1417   2.21
>  6   1733   2.94
>  7   1216   2.33
>  8   15212.4
>  9   10142.4
> 10   12 5   1.42
> 11   3425   1.74
> 12   10132.3
>  total  173   213   2.23
>
> Project: puppet-tripleo
>
>  month  patches  rechecks  CI-factor
>  1   2923   1.79
>  2   3668   2.89
>  3   40442.1
>  4   6874   2.09
>  5  12943   1.33
>  6  265   206   1.78
>  7  235   1181.5
>  8  193   130   1.67
>  9  147   123   1.84
> 10  233   159   1.68
> 11  13786   1.63
> 12   20 5   1.25
>  total 1532  10791.7
>
>
> [1] https://gist.github.com/ansiwen/e139cbf25bc243d30629e0157fc753ff
>
> __
> OpenStack Development Mailing List (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] [glance] meeting schedule for next 3 weeks

[Brian Rosmaita]

The weekly IRC meetings for Glance are held in #openstack-meeting-4 on
Thursdays at 14:00 UTC.  The agenda [0] and transcripts [1] are publicly
available.

Given the upcoming holidays, here's what we decided today about the next
3 weeks:

December 22: We will meet, but don't feel bad if you can't make it.  It
will probably be a short meeting, so show up at 14:00 UTC if you have
something you want to talk about.

December 29: Cancelled!

January 5: Same deal as Dec 22.

Keep in mind that many reviewers will be on vacation, so things may
occur bit more slowly than usual (if you can imagine that).  If you have
something you'd like to discuss, you can put a shout in
#openstack-glance on IRC to see if anyone is around, or send a topic to
the mailing list (tagged with [glance] in the subject line).

We'll continue meeting in normal fashion (well, normal for Glance,
anyway) on January 12, 2017.


Happy holidays to all!
brian

[0] https://etherpad.openstack.org/p/glance-team-meeting-agenda
[1] http://eavesdrop.openstack.org/meetings/glance/

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Michał Jastrzębski]

Ok, let me reverse this discussion. We think hangouts are exclusive,
and irc is not? I've seen multiple times when people were waaay into
discussion, lines of text swarming the screen, somebody from outside
speaks up, entirely reasonable and on topic thing, but is ignored
because other actors in discussion were busy smashing keyboard to
defend their mind? This person was unwillingly excluded from
conversation and might feel bad enough to not speak up again. I've
seen this happened. It happened to me on more than one occasion. That
speak up thing might not be so easily ignored if actually spoken up in
hangouts.

My point is, every communication channel has it's way to exclude
people. Some people are intimidated to even speak up in public. Some
people don't have money to travel to design summit. Saying that "we
include everyone" is utopia. Best we can do is to try hard to be
inclusive.

I think having rules like "no ad hoc hangout meetings" will be
extremely hurtful to communities. I am strong believer that different
problems works better with different solutions, and that's true for
communication too. Sometimes hot brainstorm-style ad hoc discussion is
exactly what project need. Sometimes we need long, stretched
discussion on ML, where everyone can speak up their mind in length.

Kolla community have always put inclusiveness as one of it's main
values to uphold, that is reflected in our diversity in both core team
and general community stats.

I did some digging and I think I know which particular hangout
sprouted this whole discussion, so let me give you some context:

1. This hangout ended 2 week long ongoing disagreement that we
couldn't resolve on irc or spec. It took 1hr of us actually talking to
each other to finally come to conclusion.
2. Most of kolla-k8s active team was there discussing
3. Besides kolla-k8s team we also had kubernetes community members who
are much more used to this type of discussion (not irc, so some could
argue that *this* was inclusive way to work between two opensource
communities, finding common toolset to communicate).
4. Part of why we did it in such an unplanned manned (therefore some
people interested weren't present at the time) is that this k8s
community members happened to join us at that time and we wanted to
make most of it.
5. At the end it helped us greatly to move past problems that stalled
our development for weeks.

I will defend this thing as something what we needed at the time.
Sometimes heated up video discussion helps to resolve
misunderstandings which otherwise could grow up and become conflicts
in community, which would be much worse.

So please, let's not put artificial rules regarding our communication
just to be "inclusive". If there is a will to be inclusive, we can be
regardless of tool, if there is none, no tool will help. I will
advocate to allow whichever way community decides to work to that
community and focus on building culture of inclusiveness.

If we have correct mindset, that's all that matters and I, for one, am
strong believer that Kolla community has been built on top of this
mindset, and we keep doing good job on following it.

Regards,
Michal

On 15 December 2016 at 14:16, Zane Bitter  wrote:
> On 14/12/16 18:18, Michał Jastrzębski wrote:
>>
>> I agree that meeting notes are crucial to this type of meeting.I just
>> say that gerrit PoC/demo is valid form of 'notes' if meeting was about
>> some implementional detail, which I assume is the case for this type of
>> meetings.
>>
>> Do we agree that as hoc hangout meetings are acceptable form of
>> cooperation if invitation is own and notes are published?
>
>
> It's not possible to have 100% open design. When I'm sitting alone at my
> desk thinking, that's kind of like a videoconference of one. Nobody else can
> be inside my head (much to y'all's relief, I'm sure). But open design means
> that everything I come up with there is subject to review, and possibly
> reversal, by the community. As such, it makes sense to keep the community
> updated as regularly as possible. It may seem like that's slowing down your
> work, but it actually speeds up the project as a whole because there's less
> work to be thrown out when the consensus comes down another way.
>
> IMHO the same rules apply when there's more than one person involved. It's
> fine to discuss, but not to think that you can make a decision for the
> community without the involvement of the rest of the community. What's
> really annoying is when some group gets together in private to discuss
> Problem X, and then comes back to the community to announce that "we need to
> implement Solution Y". That's not open design. Open design means laying out
> Problem X, Solution Y, alternative Solution Z, and the reasoning behind
> preferring one over the other, and then letting the community at large have
> their say (perhaps even proposing completely different solutions) before
> reaching a consensus.
>
> If the outcome of a 

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Zane Bitter]

On 14/12/16 18:18, Michał Jastrzębski wrote:

I agree that meeting notes are crucial to this type of meeting.I just
say that gerrit PoC/demo is valid form of 'notes' if meeting was about
some implementional detail, which I assume is the case for this type of
meetings.

Do we agree that as hoc hangout meetings are acceptable form of
cooperation if invitation is own and notes are published?


It's not possible to have 100% open design. When I'm sitting alone at my 
desk thinking, that's kind of like a videoconference of one. Nobody else 
can be inside my head (much to y'all's relief, I'm sure). But open 
design means that everything I come up with there is subject to review, 
and possibly reversal, by the community. As such, it makes sense to keep 
the community updated as regularly as possible. It may seem like that's 
slowing down your work, but it actually speeds up the project as a whole 
because there's less work to be thrown out when the consensus comes down 
another way.


IMHO the same rules apply when there's more than one person involved. 
It's fine to discuss, but not to think that you can make a decision for 
the community without the involvement of the rest of the community. 
What's really annoying is when some group gets together in private to 
discuss Problem X, and then comes back to the community to announce that 
"we need to implement Solution Y". That's not open design. Open design 
means laying out Problem X, Solution Y, alternative Solution Z, and the 
reasoning behind preferring one over the other, and then letting the 
community at large have their say (perhaps even proposing completely 
different solutions) before reaching a consensus.


If the outcome of a private discussion is simply a Gerrit patch 
implementing Solution Y then that feels dangerously close to the 
undesirable case to me unless it's accompanied by extensive commentary.


A post to the mailing list with the extra details is one way of handling 
it. You have to trade off the extra cost of doing that against the 
benefit of a high-bandwidth burst of (effectively private) 
communication. If it's still worth it then that's OK. But if you try to 
have your cake and eat it then you risk compromising the openness of 
your design process.



So if one of potential attendees cannot join for that reason, again I
would consider this to be reason enough to move meeting back to irc.
IRC is and keep being our default communication channel.


I'm glad you see it that way too. However, we also need to be mindful of 
the fact that some people, especially newcomers, may not feel able to 
speak up and demand that an out-of-band meeting of cores not take place. 
Particularly if this becomes a routine occurrence.


The next 'generation' of core reviewers will acquire their knowledge 
largely from discussions between the current cores. It's important to 
the long-term health of the project not to cut them off from those 
discussions, even at some cost to the short-term velocity.


cheers,
Zane.

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

-Original Message-
From: Michał Jastrzębski 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 14, 2016 at 17:20:21
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> I agree that meeting notes are crucial to this type of meeting.I just say
> that gerrit PoC/demo is valid form of 'notes' if meeting was about some
> implementional detail, which I assume is the case for this type of meetings.

It really isn't though. It only covers the conclusion. It doesn't explain how 
that conclusion was reached. By not providing that information, you are hiding 
the path to that conclusion from the rest of the community that could not 
participate in the meeting. By saying "the final patchset makes this obvious" 
you're excluding:

- Users who don't review the code
- Users who won't have time to dig through commit history to find the commit 
that may or may not have an accurate summary of how that conclusion was reached
- Fellow developers who can't attend the meetings based on time
- Fellow developers who can attend the meetings but can't follow them (for 
various reasons)

If it's just "some implementation detail" then I really don't understand why it 
is important enough to need several developers to join a video call. If it was 
important enough or controversial enough to need a collaboration that 
significant, it's worth documenting in a form other than the commit itself.

> Do we agree that as hoc hangout meetings are acceptable form of cooperation
> if invitation is own and notes are published?

Well I think we all agree that Google Hangouts aren't acceptable as they 
exclude residents of an entire nation.

I don't think anyone's against teams using impromptu video calls to help 
resolve conversations. I think each team needs to listen to its members, 
though, and respond to their concerns.

--  
Ian Cordasco


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

[openstack-dev] [Neutron][DVR] - No IRC Meeting until 2017

[Brian Haley]

Hi Folks,

We will not have another DVR sub-team meeting until 2017, resuming on January 
4th, to accommodate those that will be away.


Enjoy the break!

-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] [nova] Let's kill quota classes (again)

[Andrey Volkov]

> We're moving quotas to the API and we're going to stop doing the 
> reservation/commit/rollback race dance between API and compute nodes per 
> this spec:
>
> https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html

It's very nice spec. If we can remove all quota_usages and reservations
stuff it will be great. As I understand a lot of places should be
changed I'd happy to take part and to help.

Matt Riedemann writes:

> On 12/15/2016 3:11 AM, Andrey Volkov wrote:
>> Hi,
>>
>> I totally agree with Matt than `os-quota-class-sets` is inconsistent.
>> It has that hardcoded default class can't be changed.
>> API call is documented neither Nova nor Cinder (has the same API for
>> quotas).
>>
>> With defaults in the configuration I have some concerns:
>> - As it was mentioned before, possibly we need to update configs in
>> several places.
>
> We're moving quotas to the API and we're going to stop doing the 
> reservation/commit/rollback race dance between API and compute nodes per 
> this spec:
>
> https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html
>
> So that would mean you really only need the default quota configuration 
> on the API node, so I don't think this is as much of a problem after 
> that change.
>
>> - To make changes be applied we need to restart service, possibly SIGHUP
>> can help
>>   but I'm not sure.
>
> I'd think we could make these mutable config options so we could pickup 
> the changes without restarting the service.
>
>>
>> Alternatives I see are:
>> - Update `os-quota-sets` and give it possibility to work with defaults.
>> - Use external centralized quota service on which the work's doing actively.
>>   Please see [1] spec for limits in keystone and doc [2] having information
>>   how it can be applied in Nova and Cinder.
>>
>> [1] https://review.openstack.org/#/c/363765/
>> [2]
>> https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit#
>>
>>

-- 
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.

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

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Anne Gentle]

On Thu, Dec 15, 2016 at 10:58 AM, Sean Dague  wrote:

> One of the big things to consider is which of these items directly
> support one of the key PWG issues: "painless upgrades"
>
> The following items: movinging paste.ini out of config, new style
> olso.policy (in code), and rootwrap -> privsep all eliminate files in
> /etc that dramatically impact code execution, and need careful merging
> during upgrades.
>
> These are kind of the trifecta of content that really never should have
> been in /etc, except it was easy to hack out in an initial version.
>
> So, it may not be evident to users that this is what's getting in the
> way of features rolling out to them, or them being 2 to 3 releases
> behind master, it's a huge part of it. As such, I think any/all of them
> should be considered as top level item for the next round of priorities.
>

Yep -- this is the heart of the comms difficulty with these goals. I
struggled myself to understand why there were perceived "tech debt" items
high on the list. I had to have the cascading need explained to me that got
the end user outcome from the goal. So, adding that additional context to
the goal proposals helps.

Anne


>
> I'd argue that until upgrades become really easy, everything else is
> pretty secondary, because if people don't upgrade they'll never get any
> of the other enhancements you are making.
>
> On 12/15/2016 04:11 AM, Jean-Philippe Evrard wrote:
> > Hello,
> >
> > Maybe this will sound dumb …
> >
> > I received this email on openstack-dev mailing list. I don’t know if it
> was sent to any other place, because it’s basically agreeing on development
> to be done, which makes sense to me.
> > So openstack-dev people (called further “devs”) will push their company
> agenda on these goals based on what they know in their company. I see the
> work done together there, and I find it great, but…
> >
> > Wouldn’t that be better if we open this discussion to the general
> population (openstack users, operators, and devs) instead of just devs?
> > I submit this question because what I see on https://etherpad.openstack.
> org/p/community-goals is not only tech debt items that we have to fix,
> but also ideas of improvement on the long run for our users.
> > It makes sense to me to keep the tech debt items as a devs only topic (I
> don’t see why a user cares _at least at first_ about using oslo.privsep vs
> oslo.rootwrap), and it makes also sense to me to align “community goals”
> with the broad community.
> >
> > What do you think? Should we remove the non tech-debt items in this
> dev-community-goals etherpad?
> > Should we have another set of community goals that could serve as a
> basis for the OpenStack user survey?
> > Or should we keep these goals merged together, with the risk of having
> tech-debt items having lower priority the user requirements? (For that, the
> TC would be a good judge for final cycle prioritization)
> >
> > I think having community goals is great for openstack, and I’d be happy
> to understand how we’ll adapt http://governance.openstack.
> org/goals/index.html into real life work usable for everyone.
> >
> > Thanks for your clarifications.
> >
> > Best regards,
> > Jean-Philippe Evrard
> >
> >
> > On 12/12/2016, 12:19, "Emilien Macchi"  wrote:
> >
> > On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi 
> wrote:
> > > A few months ago, our community started to find and work on
> > > OpenStack-wide goals to "achieve visible common changes, push for
> > > basic levels of consistency and user experience, and efficiently
> > > improve certain areas where technical debt payments have become too
> > > high – across all OpenStack projects".
> > >
> > > http://governance.openstack.org/goals/index.html
> > >
> > > We started to define a first Goal in Ocata (Remove Copies of
> Incubated
> > > Oslo Code) and we would like to move forward in Pike.
> > > I see 3 actions we could take now:
> > >
> > > 1) Collect feedback of our first iteration of Community Goals in
> > > OpenStack during Ocata. What went well? What was more challenging?
> > >
> > > Some examples:
> > > - should we move the goal documents into a separate repo to allow a
> > > shorter review time, where we could just have 2 TC members approve
> > > them instead of waiting a week?
> > > -  we expected all teams to respond to all goals, even if they
> have no
> > > work to do. Should we continue that way?
> > > - should we improve the guidance to achieve Goals?
> > >
> > > I created an etherpad if folks want to give feedback:
> > > https://etherpad.openstack.org/p/community-goals-ocata-feedback
> > >
> > > 2) Goals backlog - https://etherpad.openstack.
> org/p/community-goals
> > > - new Goals are highly welcome.
> > > - each Goal would be achievable in one cycle, if not I think we
> need
> > > to break it 

Re: [openstack-dev] Golang technical requirements

[Jeremy Stanley]

On 2016-12-14 17:49:46 -0600 (-0600), Monty Taylor wrote:
[...]
> For things we generate in pbr - like AUTHORS and ChangeLog - assuming we
> want to do the same thing in go, we could likely come up with something
> similar. I also think we should consider that perhaps those two files
> are not needed if the primary expectation for distribution is git.

Completely agree on this point. We auto-generate those two files in
particular as a means for us to export data from our revision
control system (specifically data which is not normally represented
in the file content under revision control) such that it can be
conveyed within a tarball that would otherwise lack the relevant
context to derive it.

Some teams do hand-create those files instead and check them into
revision control, but could of course continue to do so in Git repos
of Go code as well with no real change to their usual process.
-- 
Jeremy Stanley

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

[openstack-dev] [tripleo] [ci] recheck impact on CI infrastructure

[Sven Anderson]

Hi all,

while I was waiting again for the CI to be fixed and didn't want to
torture it with additional rechecks, I wanted to find out, how much of
our CI infrastructure we waste with rechecks. My assumption was that
every recheck is a waste of resources based on a false negative, because
it renders the previous build useless. So I wrote a small script[1] to
calculate how many rechecks are made on average per built patch-set. It
calculates the number of patch-sets of merged changes that CI was
testing (some patch-sets are not, because they were updated before CI
started testing), the number of rechecks issued on these patch-sets, and
a value "CI-factor", which is the factor by which the rechecks increased
the the CI runs, that is, without rechecks it would be 1, if every
tested patch-set would have exactly one recheck it would be 2.

The results were not as bad as my feeling, we are below 2 for most of
the projects I tested. :-) But still, on THT for instance we use 71%
more resources because of the false negatives. I made monthly
breakdowns, so you can see a positive trend at least.


Here the results:

Project: tripleo-heat-templates

 month  patches  rechecks  CI-factor
 1  221   102   1.46
 2  282   300   2.06
 3  588   567   1.96
 4  220   253   2.15
 5  333   242   1.73
 6  459   325   1.71
 7  612   390   1.64
 8  694   442   1.64
 9  717   440   1.61
10  474   316   1.67
11  358   189   1.53
12  16880   1.48
 total 5126  3646   1.71

Project: tripleo-common

 month  patches  rechecks  CI-factor
 1   73291.4
 2   5948   1.81
 3   92   1012.1
 4   1719   2.12
 5   4727   1.57
 6   8346   1.55
 7   6626   1.39
 8  209   102   1.49
 9  261   129   1.49
10  11051   1.46
11  12147   1.39
12   4019   1.48
 total 1178   644   1.55

Project: tripleo-puppet-elements

 month  patches  rechecks  CI-factor
 1   24 9   1.38
 2920   3.22
 3716   3.29
 4924   3.67
 5   1417   2.21
 6   1733   2.94
 7   1216   2.33
 8   15212.4
 9   10142.4
10   12 5   1.42
11   3425   1.74
12   10132.3
 total  173   213   2.23

Project: puppet-tripleo

 month  patches  rechecks  CI-factor
 1   2923   1.79
 2   3668   2.89
 3   40442.1
 4   6874   2.09
 5  12943   1.33
 6  265   206   1.78
 7  235   1181.5
 8  193   130   1.67
 9  147   123   1.84
10  233   159   1.68
11  13786   1.63
12   20 5   1.25
 total 1532  10791.7


[1] https://gist.github.com/ansiwen/e139cbf25bc243d30629e0157fc753ff

__
OpenStack Development Mailing List (not for 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][ptls][tc][goals] community goals for Pike

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-12-15 11:58:42 -0500:
> One of the big things to consider is which of these items directly
> support one of the key PWG issues: "painless upgrades"
> 
> The following items: movinging paste.ini out of config, new style
> olso.policy (in code), and rootwrap -> privsep all eliminate files in
> /etc that dramatically impact code execution, and need careful merging
> during upgrades.
> 
> These are kind of the trifecta of content that really never should have
> been in /etc, except it was easy to hack out in an initial version.
> 
> So, it may not be evident to users that this is what's getting in the
> way of features rolling out to them, or them being 2 to 3 releases
> behind master, it's a huge part of it. As such, I think any/all of them
> should be considered as top level item for the next round of priorities.

That's great context to have.  It would be useful to add that to
the etherpad, possibly even grouping the related goals together
under an umbrella topic or somehow tagging them as related.

> I'd argue that until upgrades become really easy, everything else is
> pretty secondary, because if people don't upgrade they'll never get any
> of the other enhancements you are making.

As far as priorities go, we'll need to have folks ready to write
up the detailed proposals and then act as Guides for the teams doing
the implementation work. Does anyone want to volunteer to do that
for any of the current items?

Doug

> 
> On 12/15/2016 04:11 AM, Jean-Philippe Evrard wrote:
> > Hello,
> > 
> > Maybe this will sound dumb …
> > 
> > I received this email on openstack-dev mailing list. I don’t know if it was 
> > sent to any other place, because it’s basically agreeing on development to 
> > be done, which makes sense to me.
> > So openstack-dev people (called further “devs”) will push their company 
> > agenda on these goals based on what they know in their company. I see the 
> > work done together there, and I find it great, but…
> > 
> > Wouldn’t that be better if we open this discussion to the general 
> > population (openstack users, operators, and devs) instead of just devs?
> > I submit this question because what I see on 
> > https://etherpad.openstack.org/p/community-goals is not only tech debt 
> > items that we have to fix, but also ideas of improvement on the long run 
> > for our users.
> > It makes sense to me to keep the tech debt items as a devs only topic (I 
> > don’t see why a user cares _at least at first_ about using oslo.privsep vs 
> > oslo.rootwrap), and it makes also sense to me to align “community goals” 
> > with the broad community.
> > 
> > What do you think? Should we remove the non tech-debt items in this 
> > dev-community-goals etherpad?
> > Should we have another set of community goals that could serve as a basis 
> > for the OpenStack user survey?
> > Or should we keep these goals merged together, with the risk of having 
> > tech-debt items having lower priority the user requirements? (For that, the 
> > TC would be a good judge for final cycle prioritization)
> > 
> > I think having community goals is great for openstack, and I’d be happy to 
> > understand how we’ll adapt http://governance.openstack.org/goals/index.html 
> > into real life work usable for everyone.
> > 
> > Thanks for your clarifications.
> > 
> > Best regards,
> > Jean-Philippe Evrard
> > 
> > 
> > On 12/12/2016, 12:19, "Emilien Macchi"  wrote:
> > 
> > On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi  
> > wrote:
> > > A few months ago, our community started to find and work on
> > > OpenStack-wide goals to "achieve visible common changes, push for
> > > basic levels of consistency and user experience, and efficiently
> > > improve certain areas where technical debt payments have become too
> > > high – across all OpenStack projects".
> > >
> > > http://governance.openstack.org/goals/index.html
> > >
> > > We started to define a first Goal in Ocata (Remove Copies of Incubated
> > > Oslo Code) and we would like to move forward in Pike.
> > > I see 3 actions we could take now:
> > >
> > > 1) Collect feedback of our first iteration of Community Goals in
> > > OpenStack during Ocata. What went well? What was more challenging?
> > >
> > > Some examples:
> > > - should we move the goal documents into a separate repo to allow a
> > > shorter review time, where we could just have 2 TC members approve
> > > them instead of waiting a week?
> > > -  we expected all teams to respond to all goals, even if they have no
> > > work to do. Should we continue that way?
> > > - should we improve the guidance to achieve Goals?
> > >
> > > I created an etherpad if folks want to give feedback:
> > > https://etherpad.openstack.org/p/community-goals-ocata-feedback
> > >
> > > 2) Goals backlog - 

Re: [openstack-dev] [watcher] Next PTL elections

[Ed Leafe]

On Dec 15, 2016, at 8:15 AM, Antoine Cabot  wrote:

> Each of you are amazing and together you make an awesome team.
> It has been an absolute pleasure to serve as PTL, thank you for letting me
> do so.

It was great to work with you, taking Watcher from an idea to a full OpenStack 
project. Thanks for your hard work!

-- 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] [all][ptls][tc][goals] community goals for Pike

[Sean Dague]

One of the big things to consider is which of these items directly
support one of the key PWG issues: "painless upgrades"

The following items: movinging paste.ini out of config, new style
olso.policy (in code), and rootwrap -> privsep all eliminate files in
/etc that dramatically impact code execution, and need careful merging
during upgrades.

These are kind of the trifecta of content that really never should have
been in /etc, except it was easy to hack out in an initial version.

So, it may not be evident to users that this is what's getting in the
way of features rolling out to them, or them being 2 to 3 releases
behind master, it's a huge part of it. As such, I think any/all of them
should be considered as top level item for the next round of priorities.

I'd argue that until upgrades become really easy, everything else is
pretty secondary, because if people don't upgrade they'll never get any
of the other enhancements you are making.

On 12/15/2016 04:11 AM, Jean-Philippe Evrard wrote:
> Hello,
> 
> Maybe this will sound dumb …
> 
> I received this email on openstack-dev mailing list. I don’t know if it was 
> sent to any other place, because it’s basically agreeing on development to be 
> done, which makes sense to me.
> So openstack-dev people (called further “devs”) will push their company 
> agenda on these goals based on what they know in their company. I see the 
> work done together there, and I find it great, but…
> 
> Wouldn’t that be better if we open this discussion to the general population 
> (openstack users, operators, and devs) instead of just devs?
> I submit this question because what I see on 
> https://etherpad.openstack.org/p/community-goals is not only tech debt items 
> that we have to fix, but also ideas of improvement on the long run for our 
> users.
> It makes sense to me to keep the tech debt items as a devs only topic (I 
> don’t see why a user cares _at least at first_ about using oslo.privsep vs 
> oslo.rootwrap), and it makes also sense to me to align “community goals” with 
> the broad community.
> 
> What do you think? Should we remove the non tech-debt items in this 
> dev-community-goals etherpad?
> Should we have another set of community goals that could serve as a basis for 
> the OpenStack user survey?
> Or should we keep these goals merged together, with the risk of having 
> tech-debt items having lower priority the user requirements? (For that, the 
> TC would be a good judge for final cycle prioritization)
> 
> I think having community goals is great for openstack, and I’d be happy to 
> understand how we’ll adapt http://governance.openstack.org/goals/index.html 
> into real life work usable for everyone.
> 
> Thanks for your clarifications.
> 
> Best regards,
> Jean-Philippe Evrard
> 
> 
> On 12/12/2016, 12:19, "Emilien Macchi"  wrote:
> 
> On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi  
> wrote:
> > A few months ago, our community started to find and work on
> > OpenStack-wide goals to "achieve visible common changes, push for
> > basic levels of consistency and user experience, and efficiently
> > improve certain areas where technical debt payments have become too
> > high – across all OpenStack projects".
> >
> > http://governance.openstack.org/goals/index.html
> >
> > We started to define a first Goal in Ocata (Remove Copies of Incubated
> > Oslo Code) and we would like to move forward in Pike.
> > I see 3 actions we could take now:
> >
> > 1) Collect feedback of our first iteration of Community Goals in
> > OpenStack during Ocata. What went well? What was more challenging?
> >
> > Some examples:
> > - should we move the goal documents into a separate repo to allow a
> > shorter review time, where we could just have 2 TC members approve
> > them instead of waiting a week?
> > -  we expected all teams to respond to all goals, even if they have no
> > work to do. Should we continue that way?
> > - should we improve the guidance to achieve Goals?
> >
> > I created an etherpad if folks want to give feedback:
> > https://etherpad.openstack.org/p/community-goals-ocata-feedback
> >
> > 2) Goals backlog - https://etherpad.openstack.org/p/community-goals
> > - new Goals are highly welcome.
> > - each Goal would be achievable in one cycle, if not I think we need
> > to break it down into separated Goals (with connections).
> > - some Goals already have a team (ex: Python 3) but some haven't.
> > Maybe could we dress a list of people able to step-up and volunteer to
> > help on these ones.
> > - some Goals might require some documentation for how to achieve it.
> >
> > I think for now 2) can be discussed on the etherpad, though feel free
> > to propose another channel.
> >
> > 3) Choose Goals for Pike.
> > Some of us already did, but we might want to start 

[openstack-dev] [all][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

This week we have the pleasure of adding Ed Leafe as a core. Ed has been a 
consistent and positive presence for quite some time and he'll be good, by hook 
or crook.

Our discussion today was focused in two areas:

* The developing capabilities guideline (at 
https://review.openstack.org/#/c/386555/ ). This is something that is likely to 
impact many projects but has different levels of socialization between 
projects. It needs wide review before it gets too far down into the 
implementation details to make sure that the use cases it is trying to address 
are well understood and enumerated. The goal is to have a consistent way to 
inspect what a cloud can do. Yes, that's a very broad thing that involves user 
authorization, cloud deployment hardware and configuration, usage quotas, and 
policy. There should be agreement as to whether the answer given is for a 
particular user at a particular point in time, or general capabilities for that 
particular cloud.

* How to do deal with booleans and concepts of "state" or "status" consistently 
in query strings and representations across all the APIs. Ed's going to do some investigation and 
produce some strawman proposals as grist for discussion.

Please note that the API-WG meetings scheduled for the 22nd and 29th of 
December will be cancelled and thus there will be no more newsletters this 
year. Thanks to everyone for helping out this year. See in you January.

# Newly Published Guidelines

* Add clarification on 400 vs. 404 guideline
  https://review.openstack.org/#/c/405515/1

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at the moment.

# Guidelines Currently Under Review [3]

These first two are going to require quite a bit of input from a wide audience. 
Both have been tried a few times in the past.

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/
  This one is a bit stuck, any volunteers to pick it up?

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* correct names of capitalization styles
  https://review.openstack.org/#/c/411391/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are faciing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Tim Bell]

> On 15 Dec 2016, at 16:19, Doug Hellmann  wrote:
> 
> Excerpts from Jean-Philippe Evrard's message of 2016-12-15 09:11:12 +:
>> Hello,
>> 
>> Maybe this will sound dumb …
>> 
>> I received this email on openstack-dev mailing list. I don’t know if it was 
>> sent to any other place, because it’s basically agreeing on development to 
>> be done, which makes sense to me.
>> So openstack-dev people (called further “devs”) will push their company 
>> agenda on these goals based on what they know in their company. I see the 
>> work done together there, and I find it great, but…
>> 
>> Wouldn’t that be better if we open this discussion to the general population 
>> (openstack users, operators, and devs) instead of just devs?
>> I submit this question because what I see on 
>> https://etherpad.openstack.org/p/community-goals is not only tech debt items 
>> that we have to fix, but also ideas of improvement on the long run for our 
>> users.
> 
> Excellent point.
> 
> Collecting enough information to be confident that we are choosing
> goals that are important to the whole project while still being
> actionable is going to be a challenge. I expect us to get better
> at it over time, but this is only the second time we've tried.
> 
> Emilien has also started talking with the Product Working group
> [1], which is chartered by the board to collect this sort of feedback.
> 

I think using the product WG for this selection is a very welcome approach and 
the sort of initiative that we were aiming for with the consolidation of needs 
to evangelise. It ensures the operator/user proposals have had a reasonable 
scrutiny before being considered as the community goals. With many of product 
working group members being employed by companies contributing significantly to 
OpenStack, it is also more likely to resonate with the development resource 
allocations and strategy.

High quality user stories greatly help the drafting of appropriate blueprints 
since the multiple perspectives are consolidated into a small number of 
problems to solve.


> …
> It's up to us to ensure that operators and users understand the
> importance of those technical debt items so we can all prioritize them
> together.

+1 - the improvements will help reduce operations effort in the long term. 

Tim

> 
>> ...
> 
> Doug
> 
>> 
>> Best regards,
>> Jean-Philippe Evrard
>> 
>> 
>> On 12/12/2016, 12:19, "Emilien Macchi"  wrote:
>> 
>>On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi  
>> wrote:
>>> A few months ago, our community started to find and work on
>>> OpenStack-wide goals to "achieve visible common changes, push for
>>> basic levels of consistency and user experience, and efficiently
>>> improve certain areas where technical debt payments have become too
>>> high – across all OpenStack projects".
>>> 
>>> http://governance.openstack.org/goals/index.html
>>> 
>>> We started to define a first Goal in Ocata (Remove Copies of Incubated
>>> Oslo Code) and we would like to move forward in Pike.
>>> I see 3 actions we could take now:
>>> 
>>> 1) Collect feedback of our first iteration of Community Goals in
>>> OpenStack during Ocata. What went well? What was more challenging?
>>> 
>>> Some examples:
>>> - should we move the goal documents into a separate repo to allow a
>>> shorter review time, where we could just have 2 TC members approve
>>> them instead of waiting a week?
>>> -  we expected all teams to respond to all goals, even if they have no
>>> work to do. Should we continue that way?
>>> - should we improve the guidance to achieve Goals?
>>> 
>>> I created an etherpad if folks want to give feedback:
>>> https://etherpad.openstack.org/p/community-goals-ocata-feedback
>>> 
>>> 2) Goals backlog - https://etherpad.openstack.org/p/community-goals
>>> - new Goals are highly welcome.
>>> - each Goal would be achievable in one cycle, if not I think we need
>>> to break it down into separated Goals (with connections).
>>> - some Goals already have a team (ex: Python 3) but some haven't.
>>> Maybe could we dress a list of people able to step-up and volunteer to
>>> help on these ones.
>>> - some Goals might require some documentation for how to achieve it.
>>> 
>>> I think for now 2) can be discussed on the etherpad, though feel free
>>> to propose another channel.
>>> 
>>> 3) Choose Goals for Pike.
>>> Some of us already did, but we might want to start looking at what
>>> Goals we would like to achieve during Pike cycle.
>>> I was thinking at giving a score to the Goals, that could be
>>> calculated by its priority (I know it's vague but we know what is
>>> really urgent for us versus what can wait 6 months); but also the
>>> number of people who are interested to contribute on a Goal (if this
>>> Goal doesn't have a team yet).
>>> For now, openstack/governance is the repository for Goals, please
>>> propose them here.
>>> 
>>> 
>>> Please give feedback, we're doing iterations 

[openstack-dev] [neutron] drivers meeting cancellation today

[Armando M.]

Hi folks,

Due to conflicts, we are unable to host the drivers meeting today.

Apologies for the short notice.

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

Re: [openstack-dev] [glance] Propose Steve Lewis for Glance core

[Brian Rosmaita]

Having heard only affirmative responses, I've added Steve Lewis to the
Glance core group, with all the rights and privileges pertaining thereto.

Welcome to the Glance core team, Steve!


On 12/13/16 5:05 PM, Brian Rosmaita wrote:
> I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
> a look at any of his reviews, and you can see that he's thorough and
> comprehensive in his reviewing.  He's knowledgeable about Python,
> Glance, and software engineering in general.  He's gained a lot of
> experience in various OpenStack projects (including experience as a core
> reviewer), and will be a great addition to the Glance core reviewers team.
> 
> If you have any concerns, please let me know.  I plan to add Steve to
> the core list after this week's Glance meeting.
> 
> 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

[openstack-dev] [searchlight] End of 2017 meeting schedule

[Tripp, Travis S]

Hello everyone,

Due to the upcoming holidays we have a modified meeting schedule the next few 
weeks.

December 29th meeting is cancelled.

December 22nd meeting is tentative.  Kevin_Zheng, lei-zh, yingjun will 
coordinate deciding whether or not one is needed and if one of them will be 
available to chair the meeting.

Thanks and happy holidays!
-Travis
__
OpenStack Development Mailing List (not for 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][ptls][tc][goals] community goals for Pike

[Doug Hellmann]

Excerpts from Jean-Philippe Evrard's message of 2016-12-15 09:11:12 +:
> Hello,
> 
> Maybe this will sound dumb …
> 
> I received this email on openstack-dev mailing list. I don’t know if it was 
> sent to any other place, because it’s basically agreeing on development to be 
> done, which makes sense to me.
> So openstack-dev people (called further “devs”) will push their company 
> agenda on these goals based on what they know in their company. I see the 
> work done together there, and I find it great, but…
> 
> Wouldn’t that be better if we open this discussion to the general population 
> (openstack users, operators, and devs) instead of just devs?
> I submit this question because what I see on 
> https://etherpad.openstack.org/p/community-goals is not only tech debt items 
> that we have to fix, but also ideas of improvement on the long run for our 
> users.

Excellent point.

Collecting enough information to be confident that we are choosing
goals that are important to the whole project while still being
actionable is going to be a challenge. I expect us to get better
at it over time, but this is only the second time we've tried.

Emilien has also started talking with the Product Working group
[1], which is chartered by the board to collect this sort of feedback.

As far as a "company agenda" goes, I hope we will be able to identify
those items as either too narrowly scoped (into one project, or a
minor feature), or of narrow interest (something one customer wants)
to avoid them. On the other hand, just because an idea starts out
with one supporter doesn't mean it's necessarily bad. It may just
mean that it takes more time to build up enough support to become
a community goal. That's one benefit of keeping the backlog: We can see
what has been proposed in the past, until older ideas become more
relevant or mature into something that we can implement.

[1] http://lists.openstack.org/pipermail/product-wg/2016-December/001372.html

> It makes sense to me to keep the tech debt items as a devs only topic (I 
> don’t see why a user cares _at least at first_ about using oslo.privsep vs 
> oslo.rootwrap), and it makes also sense to me to align “community goals” with 
> the broad community.
> 
> What do you think? Should we remove the non tech-debt items in this 
> dev-community-goals etherpad?

It's up to us to ensure that operators and users understand the
importance of those technical debt items so we can all prioritize them
together.

> Should we have another set of community goals that could serve as a basis for 
> the OpenStack user survey?

I'm not sure a simple survey is a useful way to collect this sort
of information. I would expect everyone to answer yes to features
and no to anything else. A tiny text box also doesn't give enough
space to describe goals in sufficient detail to make them actionable.
Engagement through discussion allows for more collaborative decision
making, because we can argue the relative merits of proposals. It
also allows us to have more detailed writeup, which will help
identify things we are ready to finish versus things that need more
experimentation, examples, or refinement.

> Or should we keep these goals merged together, with the risk of having 
> tech-debt items having lower priority the user requirements? (For that, the 
> TC would be a good judge for final cycle prioritization)

Yes, that's why the TC makes the final call, after considering all of
the input. Sometimes we will need to take the timing of a goal into
account, and pay down debt before we add a feature.

> I think having community goals is great for openstack, and I’d be happy to 
> understand how we’ll adapt http://governance.openstack.org/goals/index.html 
> into real life work usable for everyone.
> 
> Thanks for your clarifications.

Thanks for these questions!

Doug

> 
> Best regards,
> Jean-Philippe Evrard
> 
> 
> On 12/12/2016, 12:19, "Emilien Macchi"  wrote:
> 
> On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi  
> wrote:
> > A few months ago, our community started to find and work on
> > OpenStack-wide goals to "achieve visible common changes, push for
> > basic levels of consistency and user experience, and efficiently
> > improve certain areas where technical debt payments have become too
> > high – across all OpenStack projects".
> >
> > http://governance.openstack.org/goals/index.html
> >
> > We started to define a first Goal in Ocata (Remove Copies of Incubated
> > Oslo Code) and we would like to move forward in Pike.
> > I see 3 actions we could take now:
> >
> > 1) Collect feedback of our first iteration of Community Goals in
> > OpenStack during Ocata. What went well? What was more challenging?
> >
> > Some examples:
> > - should we move the goal documents into a separate repo to allow a
> > shorter review time, where we could just have 2 TC members approve
> > 

Re: [openstack-dev] [TripleO][Upgrade Squad syncup]

[Marios Andreou]

On 14/12/16 12:34, Marios Andreou wrote:
> On 14/12/16 11:17, Julie Pichon wrote:
>> On 14 December 2016 at 08:56, Dougal Matthews  wrote:
>>> On 13 December 2016 at 16:12, Emilien Macchi  wrote:

 On Tue, Dec 13, 2016 at 10:58 AM, Marios Andreou 
 wrote:
> Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
> lets schedule a syncup on the Ocata composable upgrades work and how we
> will build on Steve Hardy's base ansible driven implementation.
>
> IMO a call would be the best format (I propose to schedule a bluejeans
> call, though I am open to any other suggestions). For now I've setup a
> doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
> you'd like to participate. Assuming we go with bluejeans (unless I hear
> strong pushback/other suggestions) then I'll try and make a recording
> available to address the concerns expressed at
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
> (thanks shardy for pointing that out).
>
> Moving forward we should probably switch to an irc based syncup,

 As long as:
 - we have zero pushbash from our community members
 - anyone can join the call
 - our design and discussions stay open (mailing-list, tripleo-specs, IRC)
 - a nice summary is sent to openstack-dev
>>>
>>> or maybe even better, a recording is posted online?
>>
>> Personally, I find summaries easier to parse compared to finding an
>> hour to listen to people talking back and forth about something,
>> though it doesn't need to be an either/or proposition :) One of the
>> issues brought up in the other thread about video calls is that they
>> can be difficult to follow for folks who don't have English as a first
>> language. Having a few written notes about what came up during the
>> meeting and some of the conclusions would help with this I think.
>>
>> Looking forward to seeing how the upgrade work comes along!
>>
>> Julie
>>
 - we keep tripleo meeting on IRC every week

 I don't see any blocker to do video-conference between folks that work
 together on a same topic.

> I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
> ) and schedule the meeting accordingly with a followup mail here,
> 
> 
> Looks like Thursday works for everybody. I've created an etherpad which
> we can use for the agenda and for notes during the call and with dial-in
> info @ https://etherpad.openstack.org/p/tripleo-upgrades-squad. I've
> added what imo are some reasonable defaults but please fix as
> appropriate - bear in mind we are aiming for a half hour quick call so
> may not get to solve all the things!
> 
> Thanks for the feedback about the video vs irc - lets see how we get on
> having both a recording and the etherpad for this first syncup,
> 
> thanks, marios



o/ OOO - thanks to everyone that participated and for anyone else that
is interested,  we just had this call... the recording is available at
https://bluejeans.com/s/xEi@S/ and there are notes at
https://etherpad.openstack.org/p/tripleo-upgrades-squad


thanks, marios




> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>
> thanks, marios
>
>
> [1]
>
> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (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] [sahara] Meetings schedule for next 3 weeks

[Vitaly Gridnev]

Hello everyone,

I’d lke to announce that next 3 meetings (Dec. 22, Dec. 29, Jan. 5) for Sahara 
project are cancelled due to future holidays (Christmas, New Year). Next 
meeting will be at Jan. 12. 

If you have something to discuss, bring your topics to #openstack-sahara 
channel or mailing list. Important notes should be done via development mailing 
list (with [sahara] tag).

Thanks and happy holidays!

Best regards,
Vitaly Gridnev


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

[openstack-dev] [watcher] Next PTL elections

[Antoine Cabot]

Hi Watcher team,

I would like to share with you that I do not intend to run for the PTL
position of the Pike development cycle starting in March 2017. Next PTL
elections will be held at the end of January 2017. I'm sending this now
so I can work with people interested in the role, if you intend to
run for PTL in Pike then send me an email to discuss.

It's been an unforgettable ride. Being PTL a is very rewarding
experience, I'm not going away from the community, I just think three
terms as PTL has been enough and Watcher needs a new leader after 1.0
version targeted for Ocata.

To the Watcher contributors, thank you for all your time and commitment.
Each of you are amazing and together you make an awesome team.
It has been an absolute pleasure to serve as PTL, thank you for letting me
do so.

Antoine
acabot

__
OpenStack Development Mailing List (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] Next IRC meeting in 2017

[Hayes, Graham]

Hi All,

As a lot of people are now going on vacation for the holiday season, we
decided to pick up IRC meetings in 2017.

So, our first meeting will be 4th Jan 2017 @ 17:00 UTC

See everyone after the break

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] [nova] Let's kill quota classes (again)

[Matt Riedemann]

On 12/15/2016 3:11 AM, Andrey Volkov wrote:

Hi,

I totally agree with Matt than `os-quota-class-sets` is inconsistent.
It has that hardcoded default class can't be changed.
API call is documented neither Nova nor Cinder (has the same API for
quotas).

With defaults in the configuration I have some concerns:
- As it was mentioned before, possibly we need to update configs in
several places.


We're moving quotas to the API and we're going to stop doing the 
reservation/commit/rollback race dance between API and compute nodes per 
this spec:


https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html

So that would mean you really only need the default quota configuration 
on the API node, so I don't think this is as much of a problem after 
that change.



- To make changes be applied we need to restart service, possibly SIGHUP
can help
  but I'm not sure.


I'd think we could make these mutable config options so we could pickup 
the changes without restarting the service.




Alternatives I see are:
- Update `os-quota-sets` and give it possibility to work with defaults.
- Use external centralized quota service on which the work's doing actively.
  Please see [1] spec for limits in keystone and doc [2] having information
  how it can be applied in Nova and Cinder.

[1] https://review.openstack.org/#/c/363765/
[2]
https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit#





--

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] [nova] Next notification meeting in 2017

[Balázs Gibizer]

Hi, 

Due to the holiday season the next notification subteam meeting will be held on 
3rd of January [1].

Cheers,
gibi
[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170103T17 

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

Re: [openstack-dev] [infra][neutron] Intel NFV CI voting permission in Neutron

[Ihar Hrachyshka]

Waldemar  wrote:


Hi Ihar et al,
Apologies for late reply. We were fighting couple of issues with the CI  
in last couple of days. The networking problem mentioned by Ihar was one  
of them.
We're running fine as of yesterday [1]. To stay on the safe side let's  
wait a few days so CI proves stable before making it voting. I'll ping  
you this Friday - hope that's ok.



1. http://ci-watch.tintri.com/project?project=neutron=7+days


OK, the CI was enabled for short time, and then broke again:

http://intel-openstack-ci-logs.ovh/68/410768/2/check/tempest-dsvm-ovsdpdk-nfv-networking-xenial/7ba23b1/logs/devstacklog.txt.gz

It -1d every single patch that was proposed lately. So I disabled it,  
again. At this point, it seems like stability of the CI is not ideal, and  
owners should work on guarding it from external breakages before we  
consider making it voting again.


Ihar

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

Re: [openstack-dev] [kolla] Bugs cleanup dashboard

[Paul Bourke]

This actually seems really useful, thanks Christian.

On 15/12/16 11:35, Christian Berendt wrote:

Hello everybody.

Based on the dashboard which is used for the Nova project I have created one 
for Kolla. The dashboard gets updated hourly.

http://kolla.betacloud.io/bugs-dashboard.html

Christian.



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

[openstack-dev] [kolla] Bugs cleanup dashboard

[Christian Berendt]

Hello everybody.

Based on the dashboard which is used for the Nova project I have created one 
for Kolla. The dashboard gets updated hourly.

http://kolla.betacloud.io/bugs-dashboard.html

Christian.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


__
OpenStack Development Mailing List (not for 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] Deep dive session about the UI - January 12

[Ana Krivokapic]

On Tue, Dec 13, 2016 at 5:05 PM, Emilien Macchi  wrote:

> On Mon, Dec 12, 2016 at 1:30 PM, Ana Krivokapic 
> wrote:
> > Hi Everyone,
> >
> > On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on
> how
> > to contribute to the TripleO UI. Hope to see many of you there!
>
> That's awesome! Thanks for this work.
> Is there some requirements that we should prepare? (e.g. having an
> undercloud ready, etc).
>

Good question. Yes, I will start with an installed undercloud and go from
there. A virt setup with all the default options is perfectly fine.
Basically, one would need to follow the TripleO docs [1] up to and
including "Undercloud Installation". l also recommend looking at Trown's
excellent deep dive[2] on how to set up a development environment.


> Is it a presentation or/and Hands-On?
>

My idea was to have a short intro segment where I would do a quick
high-level overview on the TripleO UI. Then I would dive into the specifics
about setting a up a dev environment for the UI development, and maybe even
submit a simple patch for review as part of this. I suppose the audience
could follow along, although I think it would be easier to just watch me do
it and then replicate the steps later (with the help of the video and/or
developer docs). At the end, we will have a special guest Liz Blanchard
talk about how to contribute designs to the UI.

I started an etherpad[3] with the agenda for the deep dive (still very much
WIP).

If anyone has any ideas about other things that they would like to see
included, please by all means let me know. The outline above is just my
idea of what could be included. We have plenty of time to add other things
to the list, if people would find them useful. One point though, I did want
to keep it more about how to contribute, as opposed to how to *use* the UI
(developer perspective vs user perspective). The latter is a subject that
would IMO deserve a whole separate session.


>
> Also, I propose that we record it as we did for the previous sessions,
> so anyone can watch it again.
>

Absolutely, great idea.


>
> Thanks again.
>
> >
> > [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
> >
> > --
> > Regards,
> > Ana Krivokapic
> > Senior Software Engineer
> > OpenStack team
> > Red Hat Inc.
> >
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

[1] http://docs.openstack.org/developer/tripleo-docs/index.html
[2] https://www.youtube.com/watch?v=E1d_RmysnA8
[3] https://etherpad.openstack.org/p/tripleo-deep-dive-ui

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Thierry Carrez]

Jean-Philippe Evrard wrote:
> Maybe this will sound dumb …
> 
> I received this email on openstack-dev mailing list. I don’t know if it was 
> sent to any other place, because it’s basically agreeing on development to be 
> done, which makes sense to me.
> So openstack-dev people (called further “devs”) will push their company 
> agenda on these goals based on what they know in their company. I see the 
> work done together there, and I find it great, but…
> 
> Wouldn’t that be better if we open this discussion to the general population 
> (openstack users, operators, and devs) instead of just devs?
> I submit this question because what I see on 
> https://etherpad.openstack.org/p/community-goals is not only tech debt items 
> that we have to fix, but also ideas of improvement on the long run for our 
> users.
> It makes sense to me to keep the tech debt items as a devs only topic (I 
> don’t see why a user cares _at least at first_ about using oslo.privsep vs 
> oslo.rootwrap), and it makes also sense to me to align “community goals” with 
> the broad community.
> 
> What do you think? Should we remove the non tech-debt items in this 
> dev-community-goals etherpad?
> Should we have another set of community goals that could serve as a basis for 
> the OpenStack user survey?
> Or should we keep these goals merged together, with the risk of having 
> tech-debt items having lower priority the user requirements? (For that, the 
> TC would be a good judge for final cycle prioritization)
> 
> I think having community goals is great for openstack, and I’d be happy to 
> understand how we’ll adapt http://governance.openstack.org/goals/index.html 
> into real life work usable for everyone.
> 
> Thanks for your clarifications.

Hi Jean-Philippe,

Ocata is a bit of a transition cycle due to the event reorg. In future
development cycles, we'll have an OpenStack Summit around the middle of
the cycle, at the time we start thinking about goals for the next cycle.

So for those future cycles, the Summit is where we'll prime the "goals"
pump. The "Forum" at those future summits will be the occasion to
discuss potential future goals, engage with all the community on
requirements and expectations. Then in the next months (before
development starts), those potential goals will be evaluated for
feasibility before we come to the definitive list.

So for Queens, we'll start discussing the future goals in Boston in May
when all the community gets together. For Pike we don't have such a
forum around the time we start thinking about defining goals (i.e. now),
so we are using mailing-list instead. I'm all for extending the
discussion to other mailing-lists, but Queens goals is really when the
goals process will be as inclusive as it's designed to be.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [[neutron]how to contribute for "tunnel termination point as part of the binding details"

[joehuang]

Hello, Kevin and others may be involved:

After the discussion for "VxLAN L2 networking across Neutron"[1], Tricircle 
team wants to contribute on this point as mentioned in the recap mail[2]: 
"formalize the tunnel termination point by adding it to the port binding data 
model just like other encapsulation details". Just as what discussed with Kevin 
in Barcelona, it'll not only help current push notification mechanism, but also 
help Tricircle in VxLAN L2 networking across Neutron, so Tricircle team would 
like to contribute on this topic.

As most of us are working in east Asia, it's not easy for us to attend the 
weekly meeting and talk this directly due to time difference. I also contacted 
Anil, he said only DevRef is required. And I searched recent patches in 
Neutron, but not find relevant patches, don't know what's the progress of this 
improvement. Would like to know how can we help and contribute on this 
improvement if needed.


  *

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


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] Let's kill quota classes (again)

[Andrey Volkov]

Hi,

I totally agree with Matt than `os-quota-class-sets` is inconsistent.
It has that hardcoded default class can't be changed.
API call is documented neither Nova nor Cinder (has the same API for
quotas).

With defaults in the configuration I have some concerns:
- As it was mentioned before, possibly we need to update configs in several
places.
- To make changes be applied we need to restart service, possibly SIGHUP
can help
  but I'm not sure.

Alternatives I see are:
- Update `os-quota-sets` and give it possibility to work with defaults.
- Use external centralized quota service on which the work's doing actively.
  Please see [1] spec for limits in keystone and doc [2] having information
  how it can be applied in Nova and Cinder.

[1] https://review.openstack.org/#/c/363765/
[2]
https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit#


On Thu, Dec 15, 2016 at 6:32 AM, joehuang  wrote:

> If we don't update the default quota configuration at the same time for
> Nova services in different
> physical nodes, then there is a chance for the quota control in dis-order
> period: for example,
> 30 cores qutoa limit in one node, 20 cores quota limit in the other node.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Matt Riedemann [mrie...@linux.vnet.ibm.com]
> Sent: 15 December 2016 10:42
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again)
>
> On 7/18/2016 6:36 PM, Sean Dague wrote:
> > On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:
> >> The original concept of quota classes was to allow the default quotas
> >> applied to a tenant to be a function of the type of tenant.  That is,
> >> say you have a tiered setup, where you have gold-, silver-, and
> >> bronze-level customers, with gold having lots of free quota and bronze
> >> having a small amount of quota.  Rather than having to set the quotas
> >> individually for each tenant you created, the idea is that you set the
> >> _class_ of the tenant, and have quotas associated with the classes.
> >> This also has the advantage that, if someone levels up (or down) to
> >> another class of service, all you do is change the tenant's class, and
> >> the new quotas apply immediately.
> >>
> >> (By the way, the turnstile integration was not part of turnstile itself;
> >> there's a turnstile plugin to allow it to integrate with nova that's
> >> quota_class-aware, so you could also apply rate limits this way.)
> >>
> >> Personally, it wouldn't break my heart if quota classes went away; I
> >> think this level of functionality, if it seems reasonable to include,
> >> should become part of a more unified quota API (which we're still
> >> struggling to come up with anyway) so that everyone gets the benefit…or
> >> perhaps shares the pain? ;)  Anyway, I'm not aware of anyone using this
> >> functionality, though it might be worth asking about on the operators
> >> list—for curiosity's sake, if nothing else.  It would be interesting to
> >> see if anyone would be interested in the original idea, even if the
> >> current implementation doesn't make sense :)
> >
> > We've already dropped the hook turnstile was using, so I don't see any
> > reason not to drop this bit as well. I don't think it will work for
> > anyone with the current code.
> >
> > I agree that this probably makes way more sense in common quota code
> > then buried inside of Nova.
> >
> > -Sean
> >
>
> Following up on this, I missed the boat for Ocata, but got to talking
> with melwitt about this again today and while I had it all in my head
> again I've written a spec for Pike to deprecate the os-quota-class-sets
> API:
>
> https://review.openstack.org/#/c/411035/
>
> This essentially means no more custom quota classes (they aren't
> functional today anyway), and no more controlling global default quota
> limits via the REST API - that has to be done via the configuration
> (after the microversion).
>
> --
>
> 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
>



-- 
Thanks,

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

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Jean-Philippe Evrard]

Hello,

Maybe this will sound dumb …

I received this email on openstack-dev mailing list. I don’t know if it was 
sent to any other place, because it’s basically agreeing on development to be 
done, which makes sense to me.
So openstack-dev people (called further “devs”) will push their company agenda 
on these goals based on what they know in their company. I see the work done 
together there, and I find it great, but…

Wouldn’t that be better if we open this discussion to the general population 
(openstack users, operators, and devs) instead of just devs?
I submit this question because what I see on 
https://etherpad.openstack.org/p/community-goals is not only tech debt items 
that we have to fix, but also ideas of improvement on the long run for our 
users.
It makes sense to me to keep the tech debt items as a devs only topic (I don’t 
see why a user cares _at least at first_ about using oslo.privsep vs 
oslo.rootwrap), and it makes also sense to me to align “community goals” with 
the broad community.

What do you think? Should we remove the non tech-debt items in this 
dev-community-goals etherpad?
Should we have another set of community goals that could serve as a basis for 
the OpenStack user survey?
Or should we keep these goals merged together, with the risk of having 
tech-debt items having lower priority the user requirements? (For that, the TC 
would be a good judge for final cycle prioritization)

I think having community goals is great for openstack, and I’d be happy to 
understand how we’ll adapt http://governance.openstack.org/goals/index.html 
into real life work usable for everyone.

Thanks for your clarifications.

Best regards,
Jean-Philippe Evrard


On 12/12/2016, 12:19, "Emilien Macchi"  wrote:

On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi  wrote:
> A few months ago, our community started to find and work on
> OpenStack-wide goals to "achieve visible common changes, push for
> basic levels of consistency and user experience, and efficiently
> improve certain areas where technical debt payments have become too
> high – across all OpenStack projects".
>
> http://governance.openstack.org/goals/index.html
>
> We started to define a first Goal in Ocata (Remove Copies of Incubated
> Oslo Code) and we would like to move forward in Pike.
> I see 3 actions we could take now:
>
> 1) Collect feedback of our first iteration of Community Goals in
> OpenStack during Ocata. What went well? What was more challenging?
>
> Some examples:
> - should we move the goal documents into a separate repo to allow a
> shorter review time, where we could just have 2 TC members approve
> them instead of waiting a week?
> -  we expected all teams to respond to all goals, even if they have no
> work to do. Should we continue that way?
> - should we improve the guidance to achieve Goals?
>
> I created an etherpad if folks want to give feedback:
> https://etherpad.openstack.org/p/community-goals-ocata-feedback
>
> 2) Goals backlog - https://etherpad.openstack.org/p/community-goals
> - new Goals are highly welcome.
> - each Goal would be achievable in one cycle, if not I think we need
> to break it down into separated Goals (with connections).
> - some Goals already have a team (ex: Python 3) but some haven't.
> Maybe could we dress a list of people able to step-up and volunteer to
> help on these ones.
> - some Goals might require some documentation for how to achieve it.
>
> I think for now 2) can be discussed on the etherpad, though feel free
> to propose another channel.
>
> 3) Choose Goals for Pike.
> Some of us already did, but we might want to start looking at what
> Goals we would like to achieve during Pike cycle.
> I was thinking at giving a score to the Goals, that could be
> calculated by its priority (I know it's vague but we know what is
> really urgent for us versus what can wait 6 months); but also the
> number of people who are interested to contribute on a Goal (if this
> Goal doesn't have a team yet).
> For now, openstack/governance is the repository for Goals, please
> propose them here.
>
>
> Please give feedback, we're doing iterations here, and hopefully we'll
> improve our Community Goals over the next cycles.
> Thanks for your time,

Two weeks happened, here's a digest version of the etherpad:

- Most of projects achieved the goal for Ocata, and we saw strong
interest to do it on time
- Some confusion between the ACK'ing of a goal, and actually doing the work.
- Some projects were slow on the uptake (of starting the work) and
even reviewing the patches.
- For now, keep using openstack/governance repo for documenting Goals.
- Improve guidance on what projects are expected to do when updating
the status 

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Akihiro Motoki]

+1

2016-12-14 10:22 GMT+09:00 Armando M. :

> Hi folks,
>
> Abhishek Raut's recent involvement in OSC and python-neutronclient has
> helped moving a few efforts along in the right direction. I would like to
> suggest we double down on core firepower for the neutronclient repo
> alongside Akihiro [1].
>
> This not only will help speed up our transition to OSC CLI, but also
> improve the number of folks who can effectively liasion with the OSC team,
> and look after the needs of neutron's client repo.
>
> Many thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/410485/
>
> __
> OpenStack Development Mailing List (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