[openstack-dev] Nova scheduler 3rd-party (custom) driver connection in Newton

[Anatoly Smolyaninov]

Hello! 

Before Newton release, I just used full module path in nova.conf to plugin. But 
now blueprints suggest to use built-in drivers via entry points from 
`nova.scheduler` namespace. 

**How I should plug 3rd-party, not built-in  drivers?** 

I actually tried to add entry points manually to e.g. 
`/usr/lib/python2.7/site-packages/nova-13.1.0-py2.7.egg-info/entry_points.txt`, 
and it works, but it doesn't look like correct way.
__
OpenStack Development Mailing 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] Please add kolla-kubernetes to your watched prjoects

[Steven Dake (stdake)]

Kollagues,

The reviews on kolla-kubernetes are going slowly.  I suspect the reason is 
folks don’t have kolla-kubernetes enabled in their watched projects list.  If 
you need instruction on how to do that, please contact me on IRC.

We need to work as a team to get the kolla-kubernetes backed-up reviews merged. 
 Even if you don’t feel totally comfortable reviewing the code, we operate as 
one community and as such I’d request reviewers to take care to review 
kolla-kubernetes patches.

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

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

On 09/07/2016 07:44 PM, Joshua Harlow wrote:
> 
>>
>> Gnocchi is a service. It's not in the pip requirements list for
>> ceilometer, so releasing a new version of oslo.db and having that
>> trigger a new release of gnocchi won't also trigger a new release
>> of ceilometer to update its dependency list.
>>
>> The service projects are not yet at their RC1 point, so haven't been
>> branched. Neither has the requirements list. If blocking the "bad"
>> version of oslo.db doesn't trigger a cascade of new library releases, we
>> should do it before we tag RC1 and branch the requirements list so that
>> we don't have to try to backport the block into newton.
>>
> 
> So just to aid this along, wanted to check what was the recommended
> procedure here. https://review.openstack.org/#/c/366362/ is the final
> fix for this (I hope).
> 
> I'm guessing (but would like input before doing much here) we need that
> backported to stable/newton and getting out 4.13.3
> 
> Does that sound about right to folks, or was the desire to block pymysql
> (which I believe is fixed by now?) and then just block the bad oslo.db
> release (4.13.2) and continue with the release train as is.
> 
> Want to make sure I pick the right path here ;)
> 
> -Josh
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think the backport/release and mask of the bad oslo.db should be enough.

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

[Tony Breeds]

On Wed, Sep 07, 2016 at 08:10:45AM -0500, Matthew Thode wrote:
> https://review.openstack.org/366631
> 
> The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> current minimum requirement) results in various unit test failures in
> barbican, related to parsing of request headers in generated contexts
> for unit testing.  Updating to 1.1.1 resolves this issue.

I'd really like to get to the bottom of exactly what these failures are and how
they can be fixed.  I'd ask why we didn't catch them sooner but that boils down
to us not actually testing our lower-bounds.

https://bugs.launchpad.net/oslo.context/+bug/1620963 indicates that they're
unit test failures but elsewhere I saw functional tests mentioned.  Have we
uncovered a real issue or a testing defect?

> This is specifically affecting barbican and RDO testing (from discussion
> and the review).
> 
> The reason I think an FFE is needed is because downstream packagers,
> while encouraged to package based on upper-constraints sometimes don't.
> Meaning they'd miss something like this.

Yeah it's complex.  We've stated several  times that this is the contract we
make with downstream that we test with u-c and that's our reccomendation for
packaging.  While I agree that we shoudl test our minimums that's not a thing
we can do right now[1]

I agree that it's wrong to state our minimum is 1.0.1 when we *know* that it's
1.1.1, I'm not convinced the know that yet.

> Arguments against are that this will have knock on effects down the line
> (will require re-releases and re-re-releases because of updating things
> like keystone (this is deep in the depgraph)), so is bad from a release
> team work point of view.  Also, I think this just effects testing, so
> the impact of this is more minor than something more serious (not JUST
> breaking testing).

Here's my summary of the changes needed to bump the minimum[2]

Package  : positional [positional>=1.0.1] (used by 4 projects)
Re-Release   : 4 projects
openstack/keystoneauth[type:library]
openstack/keystonemiddleware  [type:library]
openstack/oslo.context[type:library]
openstack/python-keystoneclient   [type:library]

Each of those 4 libraries have stable/newton branches that only contain updates 
to .gitreview
origin/master : keystoneauth1===2.12.1
origin/master : keystonemiddleware===4.9.0
origin/master : oslo.context===2.9.0
origin/master : python-keystoneclient===3.5.0

So if we take the g-r change we'd need to release

keystoneauth1===2.13.0
keystonemiddleware===4.10.0
oslo.context===2.10.0
python-keystoneclient===3.6.0

All of which would be accepted by global-requirements

I know during the requirements meeting I sdaid I was worried about secondary
release effects but if I follow correctly they'll be minimal.

I guess that's a long way of saying we need someone that knows about
oslo.context and hopefully barbican to look at this

Yours Tony.

[1] I just had an idea for a crazy hack that might kinda work to generate
lower-constraints.txt something to look at Ocata :)
[2] If we don't do this befoer we branch stable/newton then we *can't* do it.


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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Steven Dake (stdake)]

Kolla core reviewer team,

It is my pleasure to nominate Christian Berendt for the Kolla core team.

Christian’s output over the last cycle has been fantastic – cracking the top 10 
reviewer list for the full cycle.  His 30 day stats [1] place him in solid 7th 
position, and considering the size of the core review team we have, this is a 
great accomplishment.  Christian also has solid 60 day review stats [2] place 
him in solid 7th position.  But more importantly his reviews are of high 
quality.  He has great IRC participation as well as having implemented all 
kinds of bug fixes all over the code base.  He clearly understands Kolla by the 
quality of his reviews.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of Christian as a candidate, a 0 vote 
indicates an abstain, and a -1 is a veto.  Voting is open for 7 days until 
September 15th, or a unanimous response is reached or a veto vote occurs.  If a 
unanimous response is reached or a veto occurs, voting will close early.

Regards,
-steve

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60

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

Re: [openstack-dev] [requirements][FFE] Request to allow os-vif 1.2.1 in upper-constraints for newton

[Tony Breeds]

On Wed, Sep 07, 2016 at 02:10:55PM -0500, Matt Riedemann wrote:
> This is the FFE to get this change in for newton:
> 
> https://review.openstack.org/#/c/365165/
> 
> The os-vif 1.2.1 release was a bug fix patch release to get a high priority
> bug [1] in for newton that is impacting the neutron linuxbridge job in the
> gate [2].
> 
> So we already have the release done, we just need the u-c change to use it.

Sounds good to me.  A quick look at os-vif users shows:
Package  : os-vif [os-vif>=1.1.0] (used by 1 projects)
Re-Release   : 0 projects

Included in  : 1 projects
openstack/nova[type:service]
Also affects : 0 projects

So umm yeah if you're good with the bump lets try it.

Yours Tony.


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

Re: [openstack-dev] [tricircle] your proposal for the name of networking and gateway sub-projects

[joehuang]

For oral interpretation, Trio2o could be "Try OpenStack api gateway to 
OpenStack for large scale and/or distributed cloud", but for formal 
interpretation, how about "Trio2o is to provide APIs gateway for multiple 
OpenStack clouds to act as a single OpenStack cloud".

And for Tricircle, "Tricircle is to provide networking automation across 
Neutron". 

Your thoughts?

Best Regards
Chaoyi Huang(joehuang)


From: joehuang
Sent: 08 September 2016 8:57
To: ski...@redhat.com; OpenStack Development Mailing List (not for usage 
questions)
Subject: RE: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects

Hi, Shinobu and team,

For Trio2o we can define it more specifically as:

Try OpenStack api gateway to OpenStack for large scale cloud: so the meaning in 
short is trio2o.

This is my personal interpretation, how do you think about this interpretation?

-

And now the vote results are:

Trio2o, 8 votes
Triangel, 3 votes
Trifennal, 2 votes

Consider most of our active contributors have already vote for the naming, so 
Trio2o will be the name for the gateway project.

Best Regards
Chaoyi Huang (joehuang)

From: Shinobu Kinjo [shinobu...@gmail.com]
Sent: 07 September 2016 18:20
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects

I prefer this.

4. Trio2o, 3 votes

But I would like to make sure what this actually means more specifically.
How can we define this word?

openstack-to-openstack

Cheers,
Shinobu



On Tue, Sep 6, 2016 at 9:01 PM, liukun  wrote:
> Triangel +1
>
> At 2016-09-06 16:27:22, "joehuang"  wrote:
>
> Hello,
>
> After the discussion in the #openstack-tricircle channel and mail-list, 4
> candidates
> available now, please vote the name for the new sub-project for api-gateway
> functionality:
>
> 1. Triangel, 2 votes
>   The Triangel are dolls that bring luck. Found some meaning may not all
> people like it, Zhiyuan proposed another candidate "Trio2o"
> 2. Tridonut, 0 votes
>   Three Donuts. Delicious food, often buy 3 get 1 free.
> 3. Trifennel, 2 votes
>   Three Fennel. Fennel is highly prized for its licorice-like flavor and
>   the myriad of health benefits it provides
> 4. Trio2o, 3 votes
>   openstack-to-openstack
>
> Some team members just joined the mail-list, so please continue to vote for
> the api-gateway project name.
>
> Best Regards
> Chaoyi Huang(joehuang)
>
> 
> From: joehuang
> Sent: 06 September 2016 9:04
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [tricircle] your proposal for the name of
> networking and gateway sub-projects
>
> I also like trio2o, +1 for trio2o.
>
> 
> From: xiulin yin [yinxiuli...@gmail.com]
> Sent: 05 September 2016 18:44
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] your proposal for the name of
> networking and gateway sub-projects
>
> trio2o +1， Accurately express the function of the project.
>
> 2016-09-05 17:34 GMT+08:00 Vega Cai :
>>
>> Oops, sorry for "triangel". Then what about "trio2o",
>> openstack-to-openstack
>>
>> Zhiyuan
>>
>> Yipei Niu 于2016年9月5日周一 上午11:22写道：
>>>
>>> Trifennel +1
>>>
>>> Best regards,
>>> Yipei
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> From: Dongfeng Huang [dfhua...@gmail.com]
> Sent: 05 September 2016 20:17
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tricircle]your proposal for the name of
> networking and gateway sub-projects (joehuang)
>
>  Trifennel +1
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Email:
shin...@linux.com
shin...@redhat.com

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

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Tony Breeds]

On Wed, Sep 07, 2016 at 01:29:35PM -0400, Doug Hellmann wrote:
> What do we have that uses oslo.db and is itself a library that would
> need to be re-released?

Package  : oslo-db [oslo-db>=4.10.0] (used by 40 projects)
Re-Release   : 1 projects
openstack/neutron-lib [type:library]
Included in  : 20 projects
openstack/cinder  [type:service]
openstack/congress[type:service]
openstack/designate   [type:service]
openstack/glance  [type:service]
openstack/heat[type:service]
openstack/ironic  [type:service]
openstack/karbor  [type:service]
openstack/keystone[type:service]
openstack/magnum  [type:service]
openstack/manila  [type:service]
openstack/mistral [type:service]
openstack/murano  [type:service]
openstack/neutron [type:service]
openstack/nova[type:service]
openstack/sahara  [type:service]
openstack/senlin  [type:service]
openstack/solum   [type:service]
openstack/tacker  [type:service]
openstack/trove   [type:service]
openstack/watcher [type:service]
Also affects : 19 projects
openstack/astara  [release:cycle-with-milestones]
openstack/cue []
openstack/dragonflow  [release:independent]
openstack/ec2-api [release:independent]
openstack/gce-api []
openstack/ironic-inspector[release:cycle-with-intermediary]
openstack/kingbird[]
openstack/kosmos  []
openstack/networking-bagpipe  [release:independent]
openstack/networking-sfc  [release:independent]
openstack/neutron-dynamic-routing [release:cycle-with-milestones]
openstack/neutron-fwaas   [release:cycle-with-milestones]
openstack/neutron-lbaas   [release:cycle-with-milestones]
openstack/neutron-vpnaas  [release:cycle-with-milestones]
openstack/nimble  []
openstack/octavia [release:independent]
openstack/tricircle   []
openstack/vmware-nsx  []
openstack/zun []

A patch bump in neutron-lib will affect 19 projects but doesn't require a
another g-r change

I've updated https://review.openstack.org/365565 Can we get +1's from the
Release managers and Neutron ?

Yours Tony.


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

Re: [openstack-dev] [puppet] Puppet 4 related backports

[Emilien Macchi]

On Wed, Sep 7, 2016 at 4:27 PM, Cody Herriges  wrote:
> For an ongoing project here at Puppet I needed to validate the stable/mitaka
> branches against Puppet 4.  I've done that for all three scenarios but doing
> so required a few backports of items currently in master.
>
> https://review.openstack.org/#/c/296557/
> https://review.openstack.org/#/c/310794/
> https://review.openstack.org/#/c/298397/
> https://review.openstack.org/#/c/298373/
> https://review.openstack.org/#/c/301971/
>
> These backports do not change any interfaces so I think they are fair game
> for backporting but one does bump the apache module up a minor rev from 1.8
> to 1.9.  Here are the cherry-picked changes.
>
> https://review.openstack.org/#/c/366956/
> https://review.openstack.org/#/c/366954/
> https://review.openstack.org/#/c/366951/
> https://review.openstack.org/#/c/366950/
> https://review.openstack.org/#/c/366949/
>

lgtm.
Thanks for the backports!

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



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

[openstack-dev] [interop][defcore][ptl] Intro to creating next Interop (DefCore) guideline

[Egle Sigler]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Egle Sigler:MAILTO:egle.sig...@rackspace.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=openstack
 -dev:MAILTO:openstack-dev@lists.openstack.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=defcore-c
 ommit...@lists.openstack.org:MAILTO:defcore-commit...@lists.openstack.org
DESCRIPTION;LANGUAGE=en-US:Hello Everyone\,\n\n\nInterop Working Group (aka
  DefCore Committee) is starting to work on the next guideline. The next gu
 ideline will be published on 2017.01\, but before then\, we need to evalua
 te and score additional components to see if they should be added to the g
 uideline. What is scoring? How does a component get added to the guideline
 ? Will your favorite project be added to the next guideline? We are going 
 to have a google hangout session on Friday and Chris Hoge will answer all 
 these questions. The session will be recorded\, so if you are not able to 
 attend it\, you can watch it later.\n\n\nEvent Page: https://plus.google.c
 om/events/cuejgn5k8keg0j0c11qi3k4j15c\nYouTube page: http://www.youtube.co
 m/watch?v=kDn4jj0iSK8\n\n\nReading list for those that would like to prepa
 re questions ahead of time:\n   *   Hacking: https://github.com/openstack/
 defcore/blob/master/HACKING.rst\n   *   Scoring: https://github.com/openst
 ack/defcore/blob/master/working_materials/scoring.txt\n   *   Lexicon: htt
 ps://github.com/openstack/defcore/blob/master/doc/source/process/Lexicon.r
 st\n   *   Core Criteria: https://github.com/openstack/defcore/blob/master
 /doc/source/process/CoreCriteria.rst\n   *   Core Definition: https://gith
 ub.com/openstack/defcore/blob/master/doc/source/process/CoreDefinition.rst
 \n   *   Designated Sections: https://github.com/openstack/defcore/blob/ma
 ster/doc/source/process/DesignatedSections.rst\n\n\nAs always\, we are ava
 ilable to answer questions on #openstack-defcore IRC channel or defcore-co
 mmit...@lists.openstack.org mailing list.\n\n\nThank you\,\nEgle Sigler\n
SUMMARY;LANGUAGE=en-US:[interop][defcore][ptl] Intro to creating next Inter
 op (DefCore) guideline
DTSTART;TZID=Central Standard Time:20160909T13
DTEND;TZID=Central Standard Time:20160909T14
UID:17DF4CD1-46F2-4038-BE81-DA5CB24F095F
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20160908T015254Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Google Hangout
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2114534223
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Getting rid of ISO

[Guo, Ruijing]

Congratuations. any plan to have fuel docker image?

From: Oleg Gelbukh [mailto:ogelb...@mirantis.com]
Sent: Thursday, September 8, 2016 4:28 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Fuel] Getting rid of ISO

Congratulations, Vladimir, that's a huge step in a right direction for Fuel.

--
Best regards,
Oleg Gelbukh

On Wed, Sep 7, 2016 at 6:47 AM, Vladimir Kozhukalov 
> wrote:
Dear colleagues,
I'm glad to announce that we have working BVT jobs on Fuel CI that do not use 
ISO but instead deploy Fuel admin node from packages onto vanilla Centos 7.
Please take a look at [1]. There are jobs '10.0.repos.*' [2], [3], [4].
We continue to work on re-implementing review jobs like this one [5] for 
example.


[1] https://ci.fuel-infra.org/view/BVT/
[2] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.snapshot/
[3] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.bvt_2/
[4] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.smoke_neutron/
[5] 
https://ci.fuel-infra.org/job/master.fuel-astute.pkgs.ubuntu.review_astute_patched/



Vladimir Kozhukalov

On Thu, Sep 1, 2016 at 1:13 PM, Roman Prykhodchenko 
> wrote:
This is so awesome! Thanks!

On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes 
> wrote:
On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote:
> Dear colleagues,
>
> We finally have working custom deployment job that deploys Fuel admin
> node using online RPM repositories (not ISO) on vanilla Centos 7.0.

Bravo! :)

> Currently all Fuel system and deployment tests use ISO and we are
> planning to re-implement all these jobs (including BVT, SWARM, and Fuel
> CI jobs) to exclude ISO from the pipeline. That will allow us to get rid
> of ISO as our deliverable and instead rely totally on package
> repositories. Linux distributions like Ubuntu, Debian, RHEL, etc. are
> already delivered via ISO/qcow2/etc. images and we'd better stop
> reinventing a wheel and support our own ISO build code. That will allow
> us to make Fuel admin node deployment more flexible.
>
> I will infrom about our next steps here in the thread.

Thanks, Vova, this is an excellent step forward for ease-of-use with Fuel.

Nice work,
-jay

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

__
OpenStack Development Mailing 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] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Adrian Turjak]

Double api sounds a little terrifying when really there are probably so
many different ways you can already solve this using the services we
already have.

The thing I don't get is Martin's requirement that "an instance must
have internet on boot" and that to do that he must have a floating ip
assigned to it. Internet on boot I can understand because of
preconfigured images and snapshots starting internal services and tasks
on boot, but why is floating ip on boot such a hard requirement? Is
adding a floating ip before boot even possible with Nova right now (I
ask as I've never looked into it)?

Unless I'm missing something, you can easily setup a private network
with internet access, boot your instance on that, and then add a
floating ip. The instance will have internet on boot, and then be given
a floating ip. Does that not solve your problem and can that not be
orchestrated with the current range of services/tools we have?

On 08/09/16 12:41, Fox, Kevin M wrote:
> Interesting. It kind of sounds like your proposing a sort of... openstack 
> standard library api api? (yes, double apis) Where you can build up an api 
> using other api calls and users can rely on those standard overarching api's 
> to be there?
>
> Thanks,
> Kevin
> 
> From: Andrew Laski [and...@lascii.com]
> Sent: Wednesday, September 07, 2016 4:34 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance 
> with Floating IP
>
> On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
>> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
>>> This is exactly what something like Minstral would be fantastic for.
>>> Multi-project workflow.
>>> Rather than try and build logic like this directly into nova, looks
>>> at extending something like Minstral with a basic easy to call task.
>> I have API- and code-reading homework to do here - but based on input
>> on IRC, and efforts thus far, the ideal solution is not really to bolt
>> a humongous piece of logic onto Nova. Rather it is appears to be first
>> and foremost Neutron that need a little bit more intelligence regarding
>> its virtual networks and the intentions of its operators.
>>
>> From what I can tell, Mistral is a very useful project for scheduling
>> recurring tasks or similar, which there is a definite need of in a
>> mature deployment.
>>
>> But I disagree with the "solve it with a new project"-approach here:
>>
>>  1) "launch my instance" is as core as it gets in OpenStack,
>>
>>  2) "launch my instance with Internet" is approximately identically as
>> core, just a bit difficult for $reasons and not fully supported today,
>>
>>  3) core functionality should IMO require as few API calls as possible,
>> to as few components as possible, while keeping REST data models etc.
>> intact, [1][2]
> I agree that it should require as few API calls as possible but maybe we
> disagree about what core functionality is. Or to put it another way,
> what is core functionality depends on your perspective.
>
> I subscribe to the plumbing and porcelain approach
> (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)
> and believe that Nova should be part of the plumbing. So while I fully
> agree with a small number of API calls to do simple tasks I don't
> believe that orchestrating network setups is core functionality in Nova
> but is core to OpenStack.
>
>>  4) there are timing concerns with adding Internet to an instance today
>> in OpenStack, since it in some cases needs to happen somewhere between
>> the events "network port created" and "instance launched", in order for
>> the instance to actually have Internet when it boots,
>>
>>  5) Scheduling "Launch instance with Internet" or "Add Internet to
>> instance" via something like Mistral would additionally either, A) add
>> a significant delay to the boot time, or B) not even fulfill the
>> objective of having Internet once instance powers on,
>>
>>  6) To replicate the logic of shade's "get me online" functions, a
>> large amount of code is required, and depending on how you go about it,
>> you also risk duplicating logic already in e.g. Nova or Neutron.
>>
>> Best regards,
>> Martin
>>
>> [1] "A designer knows he has achieved perfection not when there is
>> nothing left to add, but when there is nothing left to take away."
>>   -- Antoine de Saint-Exupery
>> [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community
>> -02.txt (example of commendable improvement almost unheard of within
>> the IETF)
>>
>> __
>> OpenStack Development Mailing 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 

Re: [openstack-dev] [tricircle] your proposal for the name of networking and gateway sub-projects

[joehuang]

Hi, Shinobu and team,

For Trio2o we can define it more specifically as:

Try OpenStack api gateway to OpenStack for large scale cloud: so the meaning in 
short is trio2o.

This is my personal interpretation, how do you think about this interpretation?

-

And now the vote results are: 

Trio2o, 8 votes
Triangel, 3 votes
Trifennal, 2 votes

Consider most of our active contributors have already vote for the naming, so 
Trio2o will be the name for the gateway project.

Best Regards
Chaoyi Huang (joehuang)

From: Shinobu Kinjo [shinobu...@gmail.com]
Sent: 07 September 2016 18:20
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects

I prefer this.

4. Trio2o, 3 votes

But I would like to make sure what this actually means more specifically.
How can we define this word?

openstack-to-openstack

Cheers,
Shinobu



On Tue, Sep 6, 2016 at 9:01 PM, liukun  wrote:
> Triangel +1
>
> At 2016-09-06 16:27:22, "joehuang"  wrote:
>
> Hello,
>
> After the discussion in the #openstack-tricircle channel and mail-list, 4
> candidates
> available now, please vote the name for the new sub-project for api-gateway
> functionality:
>
> 1. Triangel, 2 votes
>   The Triangel are dolls that bring luck. Found some meaning may not all
> people like it, Zhiyuan proposed another candidate "Trio2o"
> 2. Tridonut, 0 votes
>   Three Donuts. Delicious food, often buy 3 get 1 free.
> 3. Trifennel, 2 votes
>   Three Fennel. Fennel is highly prized for its licorice-like flavor and
>   the myriad of health benefits it provides
> 4. Trio2o, 3 votes
>   openstack-to-openstack
>
> Some team members just joined the mail-list, so please continue to vote for
> the api-gateway project name.
>
> Best Regards
> Chaoyi Huang(joehuang)
>
> 
> From: joehuang
> Sent: 06 September 2016 9:04
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [tricircle] your proposal for the name of
> networking and gateway sub-projects
>
> I also like trio2o, +1 for trio2o.
>
> 
> From: xiulin yin [yinxiuli...@gmail.com]
> Sent: 05 September 2016 18:44
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] your proposal for the name of
> networking and gateway sub-projects
>
> trio2o +1， Accurately express the function of the project.
>
> 2016-09-05 17:34 GMT+08:00 Vega Cai :
>>
>> Oops, sorry for "triangel". Then what about "trio2o",
>> openstack-to-openstack
>>
>> Zhiyuan
>>
>> Yipei Niu 于2016年9月5日周一 上午11:22写道：
>>>
>>> Trifennel +1
>>>
>>> Best regards,
>>> Yipei
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> From: Dongfeng Huang [dfhua...@gmail.com]
> Sent: 05 September 2016 20:17
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tricircle]your proposal for the name of
> networking and gateway sub-projects (joehuang)
>
>  Trifennel +1
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Email:
shin...@linux.com
shin...@redhat.com

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

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Joshua Harlow]

Gnocchi is a service. It's not in the pip requirements list for
ceilometer, so releasing a new version of oslo.db and having that
trigger a new release of gnocchi won't also trigger a new release
of ceilometer to update its dependency list.

The service projects are not yet at their RC1 point, so haven't been
branched. Neither has the requirements list. If blocking the "bad"
version of oslo.db doesn't trigger a cascade of new library releases, we
should do it before we tag RC1 and branch the requirements list so that
we don't have to try to backport the block into newton.



So just to aid this along, wanted to check what was the recommended 
procedure here. https://review.openstack.org/#/c/366362/ is the final 
fix for this (I hope).


I'm guessing (but would like input before doing much here) we need that 
backported to stable/newton and getting out 4.13.3


Does that sound about right to folks, or was the desire to block pymysql 
(which I believe is fixed by now?) and then just block the bad oslo.db 
release (4.13.2) and continue with the release train as is.


Want to make sure I pick the right path here ;)

-Josh

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Fox, Kevin M]

Interesting. It kind of sounds like your proposing a sort of... openstack 
standard library api api? (yes, double apis) Where you can build up an api 
using other api calls and users can rely on those standard overarching api's to 
be there?

Thanks,
Kevin

From: Andrew Laski [and...@lascii.com]
Sent: Wednesday, September 07, 2016 4:34 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with 
Floating IP

On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
> > This is exactly what something like Minstral would be fantastic for.
> > Multi-project workflow.
> > Rather than try and build logic like this directly into nova, looks
> > at extending something like Minstral with a basic easy to call task.
>
> I have API- and code-reading homework to do here - but based on input
> on IRC, and efforts thus far, the ideal solution is not really to bolt
> a humongous piece of logic onto Nova. Rather it is appears to be first
> and foremost Neutron that need a little bit more intelligence regarding
> its virtual networks and the intentions of its operators.
>
> From what I can tell, Mistral is a very useful project for scheduling
> recurring tasks or similar, which there is a definite need of in a
> mature deployment.
>
> But I disagree with the "solve it with a new project"-approach here:
>
>  1) "launch my instance" is as core as it gets in OpenStack,
>
>  2) "launch my instance with Internet" is approximately identically as
> core, just a bit difficult for $reasons and not fully supported today,
>
>  3) core functionality should IMO require as few API calls as possible,
> to as few components as possible, while keeping REST data models etc.
> intact, [1][2]

I agree that it should require as few API calls as possible but maybe we
disagree about what core functionality is. Or to put it another way,
what is core functionality depends on your perspective.

I subscribe to the plumbing and porcelain approach
(https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)
and believe that Nova should be part of the plumbing. So while I fully
agree with a small number of API calls to do simple tasks I don't
believe that orchestrating network setups is core functionality in Nova
but is core to OpenStack.

>
>  4) there are timing concerns with adding Internet to an instance today
> in OpenStack, since it in some cases needs to happen somewhere between
> the events "network port created" and "instance launched", in order for
> the instance to actually have Internet when it boots,
>
>  5) Scheduling "Launch instance with Internet" or "Add Internet to
> instance" via something like Mistral would additionally either, A) add
> a significant delay to the boot time, or B) not even fulfill the
> objective of having Internet once instance powers on,
>
>  6) To replicate the logic of shade's "get me online" functions, a
> large amount of code is required, and depending on how you go about it,
> you also risk duplicating logic already in e.g. Nova or Neutron.
>
> Best regards,
> Martin
>
> [1] "A designer knows he has achieved perfection not when there is
> nothing left to add, but when there is nothing left to take away."
>   -- Antoine de Saint-Exupery
> [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community
> -02.txt (example of commendable improvement almost unheard of within
> the IETF)
>
> __
> OpenStack Development Mailing 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] [keystone] new core reviewer (rderose)

[Jamie Lennox]

Congratulations Ron. Welcome aboard.

On 3 September 2016 at 04:13, Brad Topol  wrote:

> Shh! Let them get the leg irons welded shut on him first :-). Pay no
> attention Ron... Congratulations!
>
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
>
> [image: Inactive hide details for Morgan Fainberg ---09/02/2016 12:55:37
> PM---On Sep 2, 2016 08:44, "Brad Topol"  wr]Morgan
> Fainberg ---09/02/2016 12:55:37 PM---On Sep 2, 2016 08:44, "Brad Topol" <
> bto...@us.ibm.com> wrote: >
>
> From: Morgan Fainberg 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 09/02/2016 12:55 PM
> Subject: Re: [openstack-dev] [keystone] new core reviewer (rderose)
>
> --
>
>
>
> On Sep 2, 2016 08:44, "Brad Topol" <*bto...@us.ibm.com*
> > wrote:
> >
> > Congratulations Ron!!! Very well deserved!!!
> >
> > --Brad
> >
> >
> > Brad Topol, Ph.D.
> > IBM Distinguished Engineer
> > OpenStack
> > (919) 543-0646
> > Internet: *bto...@us.ibm.com* 
> > Assistant: Kendra Witherspoon (919) 254-0680
> >
> > Steve Martinelli ---09/01/2016 10:47:49 AM---I want to welcome Ron De
> Rose (rderose) to the Keystone core team. In a short time Ron has shown a v
> >
> > From: Steve Martinelli <*s.martine...@gmail.com*
> >
> >
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> *openstack-dev@lists.openstack.org* >
> > Date: 09/01/2016 10:47 AM
> >
> > Subject: [openstack-dev] [keystone] new core reviewer (rderose)
> > 
> >
> >
> >
> > I want to welcome Ron De Rose (rderose) to the Keystone core team. In a
> short time Ron has shown a very positive impact. Ron has contributed
> feature work for shadowing LDAP and federated users, as well as enhancing
> password support for SQL users. Implementing these features and picking up
> various bugs along the way has helped Ron to understand the keystone code
> base. As a result he is able to contribute to the team with quality code
> reviews.
> >
> > Thanks for all your hard work Ron, we sincerely appreciate it.
> >
> > Steve___
> ___
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> *openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
> 
> > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
> 
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> *openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
> 
> > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
> 
> >
>
> Ahahaha! Another person to direct questions to now! ;)
>
> Congrats Ron!
> __
> OpenStack Development Mailing 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] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Andrew Laski]

On Wed, Sep 7, 2016, at 06:33 PM, Adrian Turjak wrote:
> Heat is a bit of overkill for something as tiny as this.

I agree. And though it's been a while since I've looked at Heat I didn't
get the impression that it was designed for this sort of usage: a simple
API call that orchestrates networking and instance setup that then
allows you to interact with Nova/Neutron directly for further actions.

> I was mainly responding to Andrew Laski's comment talking about a
> service exactly like Minstral, for smaller cross project orchestration
> of finite tasks.
> On 8/09/2016 10:12 AM, "Fox, Kevin M"  wrote:
>  >
>  > I've typically used heat to do this too. As it has a nice way out
>  > of the box to to undo the actions it does.
>  >
>  > Thanks,
>  > Kevin
>  > 
>  > From: Adrian Turjak [adri...@catalyst.net.nz]
>  > Sent: Wednesday, September 07, 2016 2:34 PM
>  > To: OpenStack Development Mailing List (not for usage questions)
>  > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch
>  > instance with Floating IP
>  >
>  > This is exactly what something like Minstral would be fantastic
>  > for. Multi-project workflow.
>  >
>  > Rather than try and build logic like this directly into nova, looks
>  > at extending something like Minstral with a basic easy to call
>  > task.
> -
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Andrew Laski]

On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
> > This is exactly what something like Minstral would be fantastic for.
> > Multi-project workflow.
> > Rather than try and build logic like this directly into nova, looks
> > at extending something like Minstral with a basic easy to call task.
> 
> I have API- and code-reading homework to do here - but based on input
> on IRC, and efforts thus far, the ideal solution is not really to bolt
> a humongous piece of logic onto Nova. Rather it is appears to be first
> and foremost Neutron that need a little bit more intelligence regarding
> its virtual networks and the intentions of its operators.
> 
> From what I can tell, Mistral is a very useful project for scheduling
> recurring tasks or similar, which there is a definite need of in a
> mature deployment.
> 
> But I disagree with the "solve it with a new project"-approach here:
> 
>  1) "launch my instance" is as core as it gets in OpenStack,
> 
>  2) "launch my instance with Internet" is approximately identically as
> core, just a bit difficult for $reasons and not fully supported today,
> 
>  3) core functionality should IMO require as few API calls as possible,
> to as few components as possible, while keeping REST data models etc.
> intact, [1][2]

I agree that it should require as few API calls as possible but maybe we
disagree about what core functionality is. Or to put it another way,
what is core functionality depends on your perspective.

I subscribe to the plumbing and porcelain approach
(https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)
and believe that Nova should be part of the plumbing. So while I fully
agree with a small number of API calls to do simple tasks I don't
believe that orchestrating network setups is core functionality in Nova
but is core to OpenStack.

> 
>  4) there are timing concerns with adding Internet to an instance today
> in OpenStack, since it in some cases needs to happen somewhere between
> the events "network port created" and "instance launched", in order for
> the instance to actually have Internet when it boots,
> 
>  5) Scheduling "Launch instance with Internet" or "Add Internet to
> instance" via something like Mistral would additionally either, A) add
> a significant delay to the boot time, or B) not even fulfill the
> objective of having Internet once instance powers on,
> 
>  6) To replicate the logic of shade's "get me online" functions, a
> large amount of code is required, and depending on how you go about it,
> you also risk duplicating logic already in e.g. Nova or Neutron.
> 
> Best regards,
> Martin
> 
> [1] "A designer knows he has achieved perfection not when there is
> nothing left to add, but when there is nothing left to take away."
>   -- Antoine de Saint-Exupery
> [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community
> -02.txt (example of commendable improvement almost unheard of within
> the IETF)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [freezer] Core team updates

[Saad Zaher]

+1

On Fri, Aug 26, 2016 at 11:59 PM, Dieterly, Deklan 
wrote:

> +1
> --
> Deklan Dieterly
>
> Senior Systems Software Engineer
> HPE
>
>
>
>
> On 8/25/16, 9:33 AM, "Mathieu, Pierre-Arthur"
>  wrote:
>
> >Hello,
> >
> >I would like to propose some modifications regarding the Freezer core
> >team.
> >
> >First, the removal of two inactive members:
> >  - Fabrizio Fresco: Inactive
> >  - Eldar Nugaev: Switched company and is now focusing on other projects.
> >Thank you very much for your contributions.
> >
> >
> >Secondly, I would like to propose that we promote Yang Yapeng
> >(yangyapeng) core.
> >He has been a highly valuable developper for the past few month, mainly
> >working on integration with Nova and Cinder.
> >His work can be found here: [1]
> >And his stackalitics profile here: [2]
> >
> >
> >If you agree with all these change, please approve with a +1 answer or
> >explain your opinion on any of these individual modification.
> >If there are no objection, I plan on applying these tomorrow evening.
> >
> >Thanks
> >- Pierre, Freezer PTL
> >
> >[1]  https://review.openstack.org/#/q/owner:%22yapeng+Yang%22
> >[2] http://stackalytics.com/?release=all=loc_id=yang-yapeng
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >___
> ___
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [fuel-library] Nominate Stanislaw Bogatkin to fuel-library core

[Maksim Malchuk]

Hello,

I would like to nominate Stanislaw Bogatkin to fuel-library core due to his
significant contribution to the project [1] and [2]. He is one of the top
reviewers and contributors in the project.

[1]
http://stackalytics.com/?user_id=sbogatkin_type=all=all=marks=fuel-library
[2] http://stackalytics.com/report/contribution/fuel-library/90

-- 
Best Regards,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

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

[openstack-dev] [fuel-virtualbox] Nominate Serhii Ovsianikov to fuel-virtualbox core

[Maksim Malchuk]

Hello,

I would like to nominate Serhii Ovsianikov to fuel-virtualbox core due to
his significant contribution to the project [1] and [2]. He is the second
reviewer and for the last half of the year [2] acts as an unoficial QA in
the fuel-virtualbox project.

[1]
http://stackalytics.com/?user_id=sovsianikov_type=all=all=marks=fuel-virtualbox
[2] http://stackalytics.com/report/contribution/fuel-virtualbox/180

-- 
Best Regards,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
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] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Martin Millnert]

On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
> This is exactly what something like Minstral would be fantastic for.
> Multi-project workflow.
> Rather than try and build logic like this directly into nova, looks
> at extending something like Minstral with a basic easy to call task.

I have API- and code-reading homework to do here - but based on input
on IRC, and efforts thus far, the ideal solution is not really to bolt
a humongous piece of logic onto Nova. Rather it is appears to be first
and foremost Neutron that need a little bit more intelligence regarding
its virtual networks and the intentions of its operators.

From what I can tell, Mistral is a very useful project for scheduling
recurring tasks or similar, which there is a definite need of in a
mature deployment.

But I disagree with the "solve it with a new project"-approach here:

 1) "launch my instance" is as core as it gets in OpenStack,

 2) "launch my instance with Internet" is approximately identically as
core, just a bit difficult for $reasons and not fully supported today,

 3) core functionality should IMO require as few API calls as possible,
to as few components as possible, while keeping REST data models etc.
intact, [1][2]

 4) there are timing concerns with adding Internet to an instance today
in OpenStack, since it in some cases needs to happen somewhere between
the events "network port created" and "instance launched", in order for
the instance to actually have Internet when it boots,

 5) Scheduling "Launch instance with Internet" or "Add Internet to
instance" via something like Mistral would additionally either, A) add
a significant delay to the boot time, or B) not even fulfill the
objective of having Internet once instance powers on,

 6) To replicate the logic of shade's "get me online" functions, a
large amount of code is required, and depending on how you go about it,
you also risk duplicating logic already in e.g. Nova or Neutron.

Best regards,
Martin

[1] "A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away."
  -- Antoine de Saint-Exupery
[2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community
-02.txt (example of commendable improvement almost unheard of within
the IETF)

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Adrian Turjak]

Heat is a bit of overkill for something as tiny as this.
I was mainly responding to Andrew Laski's comment talking about a service exactly like Minstral, for smaller cross project orchestration of finite tasks.
On 8/09/2016 10:12 AM, "Fox, Kevin M"  wrote:
>
> I've typically used heat to do this too. As it has a nice way out of the box to to undo the actions it does.
>
> Thanks,
> Kevin
> 
> From: Adrian Turjak [adri...@catalyst.net.nz]
> Sent: Wednesday, September 07, 2016 2:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
>
> This is exactly what something like Minstral would be fantastic for. Multi-project workflow.
>
> Rather than try and build logic like this directly into nova, looks at extending something like Minstral with a basic easy to call task.

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Fox, Kevin M]

I've typically used heat to do this too. As it has a nice way out of the box to 
to undo the actions it does.

Thanks,
Kevin

From: Adrian Turjak [adri...@catalyst.net.nz]
Sent: Wednesday, September 07, 2016 2:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with 
Floating IP


This is exactly what something like Minstral would be fantastic for. 
Multi-project workflow.

Rather than try and build logic like this directly into nova, looks at 
extending something like Minstral with a basic easy to call task.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [poll][kolla] Name of baremetal role/group

[Steven Dake (stdake)]

Sean,

I’d recommend deploy-hosts (I assume this is the bootstrap renamed?)

I’d also add a duplicate API of “deploy” and mark deploy as deprecated and 
follow the standard deprecation policies.  I’d recommend making the new 
OpenStack specific deploy command deploy-openstack

Regards
-steve


From: "sean.k.moo...@intel.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, September 7, 2016 at 11:51 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [poll][kolla] Name of baremetal role/group

Hi
I recently introduced a new baremetal role/group which is used as part of the 
kolla-host playbook.
https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
This baremetal role is used to install all the dependencies required to deploy 
kolla containers on a “baremetal” host.
The host does not have to be baremetal it can be a vm but the term baremetal 
was originally chosen as unlike other rules in
Kolla it installs and configures packages on the host os.

Given that kolla also has baremetal as a service via ironic and baremetal 
provision of servers with bifrost the question I would like
To ask is should we change the name of the current role to install the kolla 
dependencies to something else.

I have created a strawpoll link for this here http://www.strawpoll.me/11175159
The options available in the strawpool are:

· kolla-host

· host

· baremetal

· pre-install
If there are any other suggestions fell free to discuss them in this thread.
I will check the poll Friday evening gmt and submit a patch for review if 
consensus is that it should be changed.

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

Re: [openstack-dev] [cinder] moving driver to open source

[Matt Riedemann]

On 9/7/2016 8:47 AM, John Griffith wrote:



On Tue, Sep 6, 2016 at 9:27 AM, Alon Marx > wrote:

I want to share our plans to open the IBM Storage driver source
code. Historically we started our way in cinder way back (in Essex
if I'm not mistaken)

​You're mistaken, Cinder didn't exist at that time... but it's irrelevant.
​


with just a small piece of code in the community while keeping most
of the driver code closed. Since then the code has grown, but we
kept with the same format. We would like now to open the driver
source code, while keeping the connectivity to the storage as closed
source.

​It might help to know *which* driver you are referring to.  IBM has a
number of Storwiz and GPFS drivers in Cinder... what drivers are you
referring to here?​



I believe that there are other cinder drivers that have some stuff
in proprietary libraries.

​Actually we've had a hard stance on this, if you have code in Cinder
that requires an external lib (I personally hate this model) we
typically require it to be open source.

I want to propose and formalize the principles to where we draw the
line (this has also been discussed in
https://review.openstack.org/#/c/341780/
) on what's acceptable by
the community.
​



Based on previous discussion I understand that the rule of thumb is
"as long as the majority of the driver logic is in the public
driver" the community would be fine with that. Is this acceptable to
the community?

​No, I don't think that's true.  It's quite possible that some people
make those sorts of statements but frankly their missing the entire point.

In case you weren't aware, OpenStack IS an OPEN SOURCE project, not a
proprietary or hybrid project.  We are VERY clear as a community about
that fact and what we call the "4 Opens" [1].  It's my opinion that if
you're in then you're ALL in.​

[1]: https://governance.openstack.org/reference/opens.html
​



Regards,
Alon









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



I'm assuming this is the XIV driver which is a shim:

https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/ibm/ibm_storage.py

As for the open source part of it, vcenter isn't open source but there 
is a vmdk driver to talk to it, I imagine this is similar.


--

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] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Adrian Turjak]

This is exactly what something like Minstral would be fantastic for. Multi-project workflow.
Rather than try and build logic like this directly into nova, looks at extending something like Minstral with a basic easy to call task.
__
OpenStack Development Mailing 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] [murano] [app-catalog] [ffe] App Catalog dashboards patches are ready

[Kirill Zaitsev]

Hi!

As the title says here are the patches that set up app-catalog-ui and 
murano-dashboard to work under common panel structure [1] Repositories would 
now share a couple of small config files to allow both dashboards be installed 
independently, if needed [2], [3]

Here is also a small script I used to fetch a clean install 
http://paste.openstack.org/show/567659/ [4] (you would obviously need to change 
your OPENSTACK_HOST ip)

I already got some positive feedback on the murano side of patches, but I am 
holding them back till I get some feedback on the app-catalog-ui side. I’d like 
to kindly ask Kevin and Chris to take a look at the patches and new structure 
and provide some feedback. We still have time before RC1 and I really hope to 
see this land in Newton =)


[1] https://review.openstack.org/#/q/topic:bp/catalog-dashboard-reorg 
[2] 
https://review.openstack.org/#/c/335725/6/app_catalog/enabled/_50_dashboard_catalog.py
[3] 
https://review.openstack.org/#/c/335725/6/app_catalog/enabled/_60_panel_group_browse.py
[4] http://paste.openstack.org/show/567659/ 

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
OpenStack Development Mailing List (not for 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] Timeframe for future elections & "Release stewards"

[Hongbin Lu]

> -Original Message-
> From: Sean McGinnis [mailto:sean.mcgin...@gmx.com]
> Sent: September-07-16 3:17 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> "Release stewards"
> 
> On Wed, Sep 07, 2016 at 01:07:22PM -0400, Sean Dague wrote:
> > On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> > > Barrett, Carol L wrote:
> > >> From: Sean Dague [mailto:s...@dague.net]
> > >>> I think another option would be to run the PTL election early,
> but
> > >>> just don't have the turn over happen until the master release
> > >>> opens up. The current transition period is > > > actually quite
> short as noted by the comments around how design summit planning
> happens. Having the PTL-next elected half way through the cycle, but
> having PTL current > still > own landing the current release actually
> provides a lot more transition time.
> > >>>
> > >>> -Sean
> > >>
> > >> I had a similar thought to Sean's, with a few changes. Why not
> have a PTL own the release from start to finish, with the PTL for the
> next release getting elected as above. In this model, it would probably
> be advisable (or a guideline) that a PTL not run for 2 cycles in a row,
> because the work load would be unmanageable. This approach could help
> to grow a stronger leadership pipeline for each project and provide
> more opportunities for people in the team to grow their skills and take
> on leadership.
> > >
> > > The drawback of this approach is that it breaks the governance
> model
> > > around project teams. You need a "the buck stops here" person (even
> > > if that power is seldom used). But you can't have two -- what
> > > happens if they disagree ?
> > >
> > > So it's simpler to have a single PTL at all times and one or two
> > > release liaisons at all times. Could be the same person though.
> >
> > It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> > decisions on master once it opens up, and guides it until it's a
> > stable branch. It doesn't seem like it breaks anything to me.
> >
> > -Sean
> 
> In the <5 minutes I've taken so far to digest this thread, this is my
> preference. It gives the incoming PTL extra run time to start planning
> and thinking about their cycle. There would be less transition time
> between PTLs and the incoming PTL can start making the decisions like
> Summit planning that will impact them.
> 
> It's at least a simpler transition from where we are to where we want
> to be.

+1

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

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

[openstack-dev] [puppet] Puppet 4 related backports

[Cody Herriges]

For an ongoing project here at Puppet I needed to validate the stable/mitaka 
branches against Puppet 4.  I've done that for all three scenarios but doing so 
required a few backports of items currently in master.

https://review.openstack.org/#/c/296557/
https://review.openstack.org/#/c/310794/
https://review.openstack.org/#/c/298397/
https://review.openstack.org/#/c/298373/
https://review.openstack.org/#/c/301971/

These backports do not change any interfaces so I think they are fair game for 
backporting but one does bump the apache module up a minor rev from 1.8 to 1.9. 
 Here are the cherry-picked changes.

https://review.openstack.org/#/c/366956/
https://review.openstack.org/#/c/366954/
https://review.openstack.org/#/c/366951/
https://review.openstack.org/#/c/366950/
https://review.openstack.org/#/c/366949/


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

Re: [openstack-dev] [Fuel] Getting rid of ISO

[Oleg Gelbukh]

Congratulations, Vladimir, that's a huge step in a right direction for Fuel.

--
Best regards,
Oleg Gelbukh

On Wed, Sep 7, 2016 at 6:47 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I'm glad to announce that we have working BVT jobs on Fuel CI that do not
> use ISO but instead deploy Fuel admin node from packages onto vanilla
> Centos 7.
>
> Please take a look at [1]. There are jobs '10.0.repos.*' [2], [3], [4].
>
> We continue to work on re-implementing review jobs like this one [5] for
> example.
>
>
> [1] https://ci.fuel-infra.org/view/BVT/
> [2] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.snapshot/
> [3] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.bvt_2/
> [4] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.
> ubuntu.smoke_neutron/
> [5] https://ci.fuel-infra.org/job/master.fuel-astute.pkgs.
> ubuntu.review_astute_patched/
>
>
>
>
> Vladimir Kozhukalov
>
> On Thu, Sep 1, 2016 at 1:13 PM, Roman Prykhodchenko  wrote:
>
>> This is so awesome! Thanks!
>>
>> On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes  wrote:
>>
>>> On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote:
>>> > Dear colleagues,
>>> >
>>> > We finally have working custom deployment job that deploys Fuel admin
>>> > node using online RPM repositories (not ISO) on vanilla Centos 7.0.
>>>
>>> Bravo! :)
>>>
>>> > Currently all Fuel system and deployment tests use ISO and we are
>>> > planning to re-implement all these jobs (including BVT, SWARM, and Fuel
>>> > CI jobs) to exclude ISO from the pipeline. That will allow us to get
>>> rid
>>> > of ISO as our deliverable and instead rely totally on package
>>> > repositories. Linux distributions like Ubuntu, Debian, RHEL, etc. are
>>> > already delivered via ISO/qcow2/etc. images and we'd better stop
>>> > reinventing a wheel and support our own ISO build code. That will allow
>>> > us to make Fuel admin node deployment more flexible.
>>> >
>>> > I will infrom about our next steps here in the thread.
>>>
>>> Thanks, Vova, this is an excellent step forward for ease-of-use with
>>> Fuel.
>>>
>>> Nice work,
>>> -jay
>>>
>>> 
>>> __
>>> 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
>
>
__
OpenStack Development Mailing 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] Newton RC reviews and releases

[Nikhil Komawar]

Hi team,


The RC period for a release spans multiple weeks, see Newton schedule
here [1]. There are about 4 more weeks in Newton when potential RC
releases could take place. The RC1 is bound to happen next week and
there will most likely be a RC2 with translations. If there are more
critical fixes to be done during this phase we would need to accommodate
in either of the two or in rare case propose another candidate.


Hence, to smoothen the release process I've started changing the topic
to "newton-rc-potential" of certain reviews that I thought are
important; they can thus be discovered using the link [2]. Core
reviewers, please give a preferential review to these. Also, if you are
a Glance core, please feel free to change the topics of reviews that you
think are RC critical respectively. If you are not a Glance core and
think that a review could be part of the Newton release, please ping me
or one of the Glance cores you know, to consider it to be part of
newton-rc-potential group.


Please reach out for any outstanding questions or comments.


[1] https://releases.openstack.org/newton/schedule.html

[2]
https://review.openstack.org/#/q/status:open+project:openstack/glance+topic:newton-rc-potential


-- 

Thanks,
Nikhil


__
OpenStack Development Mailing 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] Bug days next week

[Nikhil Komawar]

Hi all,


I would like to propose bug days for Glance next week Tuesday 13th
September and Wednesday 14th September (during your work hours / in your
time zone).


We've a plenty of bugs to address [1, 2, 3] and looks like the the right
time in the cycle when we would get a good benefit of these bug days. I
would encourage people to focus on Glance server bugs rather than client
and store bugs during these days. Nevertheless, you are free to choose
what best suits your needs.


RC1 is supposed to be targeted on Thursday Sept 15th and it would be a
good time to triage some critical bugs for the same.


Additionally, this is an excellent opportunity to all those who are
looking to get involved, become a glance-core or just make some more
contributions to Glance.


If you happen to fix an important bug and think that we need to include
it as a part of a Glance RC release, please drop me a note on IRC and
wait for my update. Either I will propose a topic change to
"newton-rc-potential" indicating that it has been considered strongly to
be a part of the release or I may leave a comment indicating why we
haven't considered so. Please do NOT make the topic to
"newton-rc-potential" yourself as it will be used while coordinating the
release work and unexpected reviews under that topic will delay or
disrupt the release process.


If you do not have time to propose a review and have found a bug that
could be a good candidate for Newton RC, then please "tag" that bug in
launchpad to have the tag named "newton-rc-potential" (this tag has been
added to official tags list). The bug team or the Glance core team will
then consider proposing fixes for these bugs.


We will use etherpad to collaboratively add notes and updates for this
event here [4]. Please see my official entry for this event at [5].


As always, feel free to reach out for questions and comments.


[1] https://bugs.launchpad.net/glance/

[2] https://bugs.launchpad.net/glance-store

[3] https://bugs.launchpad.net/python-glanceclient/

[4] https://etherpad.openstack.org/p/newton-glance-sept-bug-days

[5] https://review.openstack.org/366923


-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Doug Hellmann]

Excerpts from Mike Bayer's message of 2016-09-07 14:09:06 -0400:
> 
> On 09/07/2016 01:29 PM, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2016-09-07 09:11:58 -0500:
> >> On 09/07/2016 08:58 AM, Doug Hellmann wrote:
> >>> Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
>  https://review.openstack.org/366298
> 
>  This is just a bump to upper-constraints so is more minor to get testing
>  working and fix the bug that occurred in Gnocchi (and possibly others).
> 
>  We are able to mask the 'bad' versions of oslo.db and unmask pymysql
>  0.7.7 after the freeze (and backport them to stable/newton) so this is
>  easier to merge.
> 
> >>>
> >>> If we have a known-bad version of the library, maybe it would be better
> >>> to incorporate that info into the global-requirements list before we
> >>> branch the requirements repository? I'm not sure what we've done in
> >>> this case for past cycles.
> >>>
> >>> Doug
> >>>
> >>> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >> Are you fine with the knock on effects that a gr update would cause?
> >
> > What do we have that uses oslo.db and is itself a library that would
> > need to be re-released?
> 
> I would assume Gnocchi which acts as a backend for Ceilometer.

Gnocchi is a service. It's not in the pip requirements list for
ceilometer, so releasing a new version of oslo.db and having that
trigger a new release of gnocchi won't also trigger a new release
of ceilometer to update its dependency list.

The service projects are not yet at their RC1 point, so haven't been
branched. Neither has the requirements list. If blocking the "bad"
version of oslo.db doesn't trigger a cascade of new library releases, we
should do it before we tag RC1 and branch the requirements list so that
we don't have to try to backport the block into newton.

Doug

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Sean McGinnis]

On Wed, Sep 07, 2016 at 01:07:22PM -0400, Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> > Barrett, Carol L wrote:
> >> From: Sean Dague [mailto:s...@dague.net] 
> >>> I think another option would be to run the PTL election early, but just 
> >>> don't have the turn over happen until the master release opens up. The 
> >>> current transition period is > > > 
> >>> actually quite short as noted by the comments around how design summit 
> >>> planning happens. Having the PTL-next elected half way through the cycle, 
> >>> but having PTL current > 
> >>> still > own landing the current release actually provides a lot more 
> >>> transition time.
> >>>
> >>>   -Sean
> >>
> >> I had a similar thought to Sean's, with a few changes. Why not have a PTL 
> >> own the release from start to finish, with the PTL for the next release 
> >> getting elected as above. In this model, it would probably be advisable 
> >> (or a guideline) that a PTL not run for 2 cycles in a row, because the 
> >> work load would be unmanageable. This approach could help to grow a 
> >> stronger leadership pipeline for each project and provide more 
> >> opportunities for people in the team to grow their skills and take on 
> >> leadership.
> > 
> > The drawback of this approach is that it breaks the governance model
> > around project teams. You need a "the buck stops here" person (even if
> > that power is seldom used). But you can't have two -- what happens if
> > they disagree ?
> > 
> > So it's simpler to have a single PTL at all times and one or two release
> > liaisons at all times. Could be the same person though.
> 
> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> decisions on master once it opens up, and guides it until it's a stable
> branch. It doesn't seem like it breaks anything to me.
> 
>   -Sean

In the <5 minutes I've taken so far to digest this thread, this is my
preference. It gives the incoming PTL extra run time to start planning
and thinking about their cycle. There would be less transition time
between PTLs and the incoming PTL can start making the decisions like
Summit planning that will impact them.

It's at least a simpler transition from where we are to where we want to
be.

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

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

[openstack-dev] [requirements][FFE] Request to allow os-vif 1.2.1 in upper-constraints for newton

[Matt Riedemann]

This is the FFE to get this change in for newton:

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

The os-vif 1.2.1 release was a bug fix patch release to get a high 
priority bug [1] in for newton that is impacting the neutron linuxbridge 
job in the gate [2].


So we already have the release done, we just need the u-c change to use it.

Pretty please.

[1] https://bugs.launchpad.net/os-vif/+bug/1617447
[2] http://status.openstack.org//elastic-recheck/index.html#1617447

--

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] [all] Timeframe for future elections & "Release stewards"

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-09-07 18:24:46 +0200:
> Davanum Srinivas wrote:
> > Doug, Thierry,
> > 
> > Do we want the stewards to serve as the CPL for Release team as well?
> 
> Yes, they probably would be an evolution of the current release
> liaisons. Like I said in the email, "a sort of per-cycle release liaison
> on steroids".
> 

Right, I would expect them to be interact with the release team in
a lot of similar ways.

Doug

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

[openstack-dev] [poll][kolla] Name of baremetal role/group

[Mooney, Sean K]

Hi
I recently introduced a new baremetal role/group which is used as part of the 
kolla-host playbook.
https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
This baremetal role is used to install all the dependencies required to deploy 
kolla containers on a "baremetal" host.
The host does not have to be baremetal it can be a vm but the term baremetal 
was originally chosen as unlike other rules in
Kolla it installs and configures packages on the host os.

Given that kolla also has baremetal as a service via ironic and baremetal 
provision of servers with bifrost the question I would like
To ask is should we change the name of the current role to install the kolla 
dependencies to something else.

I have created a strawpoll link for this here http://www.strawpoll.me/11175159
The options available in the strawpool are:

* kolla-host

* host

* baremetal

* pre-install
If there are any other suggestions fell free to discuss them in this thread.
I will check the poll Friday evening gmt and submit a patch for review if 
consensus is that it should be changed.

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Matt Riedemann]

On 9/7/2016 11:33 AM, Jim Rollenhagen wrote:


I like this. As someone that has been PTL for multiple cycles, it is
incredibly stressful trying to finish the release, start planning for the
next one, manage summit planning, etc. I'd love to have someone
designated to manage the release-specific bits of the project, while
PTLs can worry about the longer-term vision of the project and the
day-to-day management.

Thanks for writing this up, Thierry. :)

// jim



I don't really see how managing the release-specific bits of the project 
as a 'release steward' is different from a release cross-project 
liaison. Nova has a release CPL (really more than one probably informally).


I do think it's a bit weird that I've already slotted the Ocata design 
summit rooms for Nova when someone else could be PTL, but I don't think 
what I'd reserve would be drastically different from someone else in 
Nova, this is why we have trust relationships and talk about stuff as a 
team.  There was a lot of overlap from Michael to John and from John to 
myself and we've shared responsibilities during those transitions.


The release steward concept just seems like unnecessarily complexity and 
formality to me, but that's just my opinion. Things might work 
differently in other projects.


--

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] [all] Timeframe for future elections & "Release stewards"

[Anita Kuno]

On 16-09-07 02:19 PM, Ian Cordasco wrote:
  


-Original Message-
From: Anita Kuno 
Reply: Anita Kuno 
Date: September 7, 2016 at 13:08:44
To: Ian Cordasco , OpenStack Development Mailing List (not 
for usage questions) 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 16-09-07 01:59 PM, Ian Cordasco wrote:


-Original Message-
From: Anita Kuno
Reply: OpenStack Development Mailing List (not for usage questions)
Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 16-09-07 12:43 PM, Davanum Srinivas wrote:

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should 
definitely

move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


One question, should "Release Stewards" also be members of the Stable Team for 
that

project or will they become members of the Stable Team? It seems like there 
should be

a

relationship there to me (although maybe not a strictly enforced one).

Welcomed and required are two different things. I think the stable team
is always willing to work with new contributors. I additionally think
that floating the expectation that someone able to take on the release
steward position also is required to entertain the stable team
responsibilities might shy away good candidates for the release steward
position. I think working with the single concept of release steward
first is a good place to begin. Give it space to grow both as a concept
within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did

a very poor job explaining why I think this is related, I'm sorry.

In my mind, if I were a Release Steward for a project. I would think I'd not 
only be in charge

of helping the initial release but also managing "post-release bugfix-backport 
phase".
That to me is what a PTL does with the Stable Team, so at least I would need to 
coordinate
with the Stable Team. It at least seems implied. Now whether the person be an 
existing
member of the Stable Team, doesn't seem important. But if the person is Release 
Steward,
I'd expect them to be able to help approve changes to the branch/release 
they're stewarding.
That, implies to me, that they'll need to work within the Stable Team. Given 
that train
of thought, it makes sense to me that a Release Steward who is not already a 
Stable Team
member would have to become one to continue their stewardship and would be 
trusted to
(maybe only at first) approve changes for their release and not for all stable 
branches.

Does that help to explain my reasoning for bringing that up?
  
Yes it does, thanks for taking the time to expand. What you say makes

perfect sense from the perspective of the contributors.
  
I'm taking a look at the perspective of a manager, who may or may not

know what our actual workflow is and how we operate. There are a number
of folks who unfortunately have to quantify their time working on
OpenStack in terms of percentage of a week or month. For anyone in that
position, and to the managers who care enough to read this list (thank
you by the way) I want to help those in this position to be able to get
permission to do the work if that is their wish. If we keep the time
required to a percentage their manager will approve then we open the
door wider. Hence my recognition of the difference between welcomed and
required. If we keep the required bit to the smallest workable piece
more managers will allow their charges to do the work or at the very
least, not block them.

I absolutely agree. =) (I'm also one of those people who has to track and 
justify % of time on OpenStack so I appreciate your consideration of us, 
sincerely.)


Thanks Ian, I'm glad we are in agreement. I know you had to cut back on 
duties a while ago. I hope you are able to consider helping in this role 
if you are interested 

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Matt Riedemann]

On 9/7/2016 11:35 AM, Ian Cordasco wrote:



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

Date: September 7, 2016 at 10:58:52
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 09/07/2016 10:43 AM, Thierry Carrez wrote:

Hi everyone,

As you probably know by now, starting with the Boston event in 2017, the
Summit will happen further away from the release day and more around the
middle of the next development cycle. You can find more info on the
rationale for that at [1] and [2] if interested, this is not the topic
of this email.

One interesting side-effect is that since the timing of the election
period (for PTL and TC positions) is defined in the TC charter[3]
relative to the *Summit*, it means that (unless we change this) we'll
now run elections to renew PTL and TC positions in the middle of the
cycle. Crazy, right ? That's what I first thought. But after discussing
it with various people, this is not as crazy as it sounds.

First, the current election timing is not perfect -- we change PTLs in
the middle of the design summit prep, with old PTLs making Design Summit
space requests that will affect their successor. It's not as if there
was a perfect timing for doing elections.

Second, release cycles are longer than 6 months. They actually start a
few months before actual development starts, with discussions on next
cycle priorities and Design Summit prep. They continue a few months
after release, with critical stable branch backports and communication
about landed features. So they are one year-long, overlapping cycles
(like explained on the diagram at [4]). With that in mind, the PTL/TC
election actually would happen just before the start of the start of the
requirements-gathering pre-development phase of the next development
cycle, which makes a lot of sense.

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

Since development cycles overlap, there would be two active release
stewards at all times. This would help with the awkward situation where
the PTL ends up having to think about the next cycle and prepare the
Design Summit (or PTG) while still being knee-deep juggling with feature
freeze exceptions, getting the current release out of the door, and
coordinating early critical fixes stable backports. Those two jobs could
be held by two different people.

Now, some teams (especially those doing intermediary releases) may want
to use the same super-human to handle everything (PTL, release steward,
release+1 steward), and some others might use two or three humans to
spread the load. That's up to them. But once designated by the
newly-elected PTL, the release steward would be responsible for the full
release cycle and would not be displaced by the next PTL 6 months later.
One year being a long time, if a steward needs to step down, the
currently-active PTL would appoint someone else to finish the job.

With this new concept I think we can get the best of both worlds, and
keep the election period as currently defined in the charter (rather
than having to change it). The PTLs we will elect in the coming weeks
won't be renewed before April, 2017 -- while Pike development will start
in February.

I know this can all be a bit confusing, so feel free to reach out to me
with questions on this.


I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.


I agree. Regardless of how PTL elections end up working, I think we should definitely 
move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

One question, should "Release Stewards" also be members of the Stable Team for 
that project or will they become members of the Stable Team? It seems like there should 
be a relationship there to me (although maybe not a strictly enforced one).

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



Membership in the stable team doesn't really have anything to do with 
whether or not you're a PTL or release liaison, it 

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Ian Cordasco]

 

-Original Message-
From: Anita Kuno 
Reply: Anita Kuno 
Date: September 7, 2016 at 13:08:44
To: Ian Cordasco , OpenStack Development Mailing List 
(not for usage questions) 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

> On 16-09-07 01:59 PM, Ian Cordasco wrote:
> >
> >
> > -Original Message-
> > From: Anita Kuno  
> > Reply: OpenStack Development Mailing List (not for usage questions)  
> > Date: September 7, 2016 at 12:03:25
> > To: openstack-dev@lists.openstack.org  
> > Subject: Re: [openstack-dev] [all] Timeframe for future elections & 
> > "Release stewards"  
> >
> >> On 16-09-07 12:43 PM, Davanum Srinivas wrote:
> >> Now, the main drawback of holding elections in the middle of a
> >> development cycle is that you don't want to introduce a discontinuity 
> >> in
> >> leadership in that development cycle. To mitigate that, we propose the
> >> introduction of a new role, the "release steward", which would be
> >> attached to the release cycle. That person (who may or may not double 
> >> as
> >> PTL) would be responsible for a complete release cycle on a given
> >> project team, from requirements gathering phase to post-release
> >> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> > I think this is a great idea. Having a person be on point for a
> > particular release from inception to whenever we stop caring about it
> > makes a lot of sense.
>  I agree. Regardless of how PTL elections end up working, I think we 
>  should definitely  
> >> move forward with this "Release Stewards" concept. It sounds like an 
> >> excellent idea.  
> >>> Also since "Release Stewards" are nominated by PTL, projects can just
> >>> start using this concept right away (as it's not an elected position).
> >>> +1 from me.
> >>>
>  One question, should "Release Stewards" also be members of the Stable 
>  Team for that  
> >> project or will they become members of the Stable Team? It seems like 
> >> there should be  
> a
> >> relationship there to me (although maybe not a strictly enforced one).
> >>
> >> Welcomed and required are two different things. I think the stable team
> >> is always willing to work with new contributors. I additionally think
> >> that floating the expectation that someone able to take on the release
> >> steward position also is required to entertain the stable team
> >> responsibilities might shy away good candidates for the release steward
> >> position. I think working with the single concept of release steward
> >> first is a good place to begin. Give it space to grow both as a concept
> >> within OpenStack and within individual projects.
> > I absolutely agree that this could scare off potentially good candidates. I 
> > also did  
> a very poor job explaining why I think this is related, I'm sorry.
> >
> > In my mind, if I were a Release Steward for a project. I would think I'd 
> > not only be in charge  
> of helping the initial release but also managing "post-release 
> bugfix-backport phase".  
> That to me is what a PTL does with the Stable Team, so at least I would need 
> to coordinate  
> with the Stable Team. It at least seems implied. Now whether the person be an 
> existing  
> member of the Stable Team, doesn't seem important. But if the person is 
> Release Steward,  
> I'd expect them to be able to help approve changes to the branch/release 
> they're stewarding.  
> That, implies to me, that they'll need to work within the Stable Team. Given 
> that train  
> of thought, it makes sense to me that a Release Steward who is not already a 
> Stable Team  
> member would have to become one to continue their stewardship and would be 
> trusted to  
> (maybe only at first) approve changes for their release and not for all 
> stable branches.  
> >
> > Does that help to explain my reasoning for bringing that up?
>  
> Yes it does, thanks for taking the time to expand. What you say makes
> perfect sense from the perspective of the contributors.
>  
> I'm taking a look at the perspective of a manager, who may or may not
> know what our actual workflow is and how we operate. There are a number
> of folks who unfortunately have to quantify their time working on
> OpenStack in terms of percentage of a week or month. For anyone in that
> position, and to the managers who care enough to read this list (thank
> you by the way) I want to help those in this position to be able to get
> permission to do the work if that is their wish. If we keep the time
> required to a percentage their manager will approve then we open the
> door wider. Hence my recognition of the difference between welcomed and
> required. If we keep the required bit to the smallest workable piece
> more managers will allow their charges to do the work or at the very
> 

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Mike Bayer]

On 09/07/2016 01:29 PM, Doug Hellmann wrote:

Excerpts from Matthew Thode's message of 2016-09-07 09:11:58 -0500:

On 09/07/2016 08:58 AM, Doug Hellmann wrote:

Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:

https://review.openstack.org/366298

This is just a bump to upper-constraints so is more minor to get testing
working and fix the bug that occurred in Gnocchi (and possibly others).

We are able to mask the 'bad' versions of oslo.db and unmask pymysql
0.7.7 after the freeze (and backport them to stable/newton) so this is
easier to merge.



If we have a known-bad version of the library, maybe it would be better
to incorporate that info into the global-requirements list before we
branch the requirements repository? I'm not sure what we've done in
this case for past cycles.

Doug

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


Are you fine with the knock on effects that a gr update would cause?


What do we have that uses oslo.db and is itself a library that would
need to be re-released?


I would assume Gnocchi which acts as a backend for Ceilometer.





Doug

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



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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Anita Kuno]

On 16-09-07 01:59 PM, Ian Cordasco wrote:
  


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

Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 16-09-07 12:43 PM, Davanum Srinivas wrote:

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should 
definitely

move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


One question, should "Release Stewards" also be members of the Stable Team for 
that

project or will they become members of the Stable Team? It seems like there 
should be a
relationship there to me (although maybe not a strictly enforced one).
  
Welcomed and required are two different things. I think the stable team

is always willing to work with new contributors. I additionally think
that floating the expectation that someone able to take on the release
steward position also is required to entertain the stable team
responsibilities might shy away good candidates for the release steward
position. I think working with the single concept of release steward
first is a good place to begin. Give it space to grow both as a concept
within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did a very poor job explaining why I think this is related, I'm sorry.

In my mind, if I were a Release Steward for a project. I would think I'd not only be in 
charge of helping the initial release but also managing "post-release 
bugfix-backport phase". That to me is what a PTL does with the Stable Team, so at 
least I would need to coordinate with the Stable Team. It at least seems implied. Now 
whether the person be an existing member of the Stable Team, doesn't seem important. But 
if the person is Release Steward, I'd expect them to be able to help approve changes to 
the branch/release they're stewarding. That, implies to me, that they'll need to work 
within the Stable Team. Given that train of thought, it makes sense to me that a Release 
Steward who is not already a Stable Team member would have to become one to continue 
their stewardship and would be trusted to (maybe only at first) approve changes for their 
release and not for all stable branches.

Does that help to explain my reasoning for bringing that up?


Yes it does, thanks for taking the time to expand. What you say makes 
perfect sense from the perspective of the contributors.


I'm taking a look at the perspective of a manager, who may or may not 
know what our actual workflow is and how we operate. There are a number 
of folks who unfortunately have to quantify their time working on 
OpenStack in terms of percentage of a week or month. For anyone in that 
position, and to the managers who care enough to read this list (thank 
you by the way) I want to help those in this position to be able to get 
permission to do the work if that is their wish. If we keep the time 
required to a percentage their manager will approve then we open the 
door wider. Hence my recognition of the difference between welcomed and 
required. If we keep the required bit to the smallest workable piece 
more managers will allow their charges to do the work or at the very 
least, not block them.


Thanks,
Anita.



I don't want to scare folks off at all, but I think we should maybe chat a bit 
about this.
--
Ian Cordasco




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

Re: [openstack-dev] [nova] Add support for tag instances when booting

[Matt Riedemann]

On 9/7/2016 9:25 AM, Andrew Laski wrote:




On Wed, Sep 7, 2016, at 05:15 AM, Zhenyu Zheng wrote:

Hi All,

Tags for servers are supported in microversion 2.26, but currently we
can only add tags to
instances that are already existed in the cloud, that is, we can not
set tags to instances
when we boot the instances. User will have to first find the instances
and then add tags
with another API call. This is not user-friendly enough when user
doing bulk boot, it will be
not practical to add tags for those instances one by one afterwards.

So, I think it will be good to add support for tag instances when
booting them, I have registered
a BP for O:
https://blueprints.launchpad.net/nova/+spec/support-tag-instance-when-boot
https://review.openstack.org/#/c/366469/

Comments?


I haven't looked at the spec, and probably won't until at least RC1 is
done, but I think this is a good idea. A few cores noticed that this was
missing a little bit ago and already agreed that it would be a good
addition in O.



Thanks,

Zhenyu Zheng

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



+1

--

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] [all] Timeframe for future elections & "Release stewards"

[Ian Cordasco]

 

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

Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

> On 16-09-07 12:43 PM, Davanum Srinivas wrote:
>  Now, the main drawback of holding elections in the middle of a
>  development cycle is that you don't want to introduce a discontinuity in
>  leadership in that development cycle. To mitigate that, we propose the
>  introduction of a new role, the "release steward", which would be
>  attached to the release cycle. That person (who may or may not double as
>  PTL) would be responsible for a complete release cycle on a given
>  project team, from requirements gathering phase to post-release
>  bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> >>> I think this is a great idea. Having a person be on point for a
> >>> particular release from inception to whenever we stop caring about it
> >>> makes a lot of sense.
> >> I agree. Regardless of how PTL elections end up working, I think we should 
> >> definitely  
> move forward with this "Release Stewards" concept. It sounds like an 
> excellent idea.  
> > Also since "Release Stewards" are nominated by PTL, projects can just
> > start using this concept right away (as it's not an elected position).
> > +1 from me.
> >
> >> One question, should "Release Stewards" also be members of the Stable Team 
> >> for that  
> project or will they become members of the Stable Team? It seems like there 
> should be a  
> relationship there to me (although maybe not a strictly enforced one).
>  
> Welcomed and required are two different things. I think the stable team
> is always willing to work with new contributors. I additionally think
> that floating the expectation that someone able to take on the release
> steward position also is required to entertain the stable team
> responsibilities might shy away good candidates for the release steward
> position. I think working with the single concept of release steward
> first is a good place to begin. Give it space to grow both as a concept
> within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did a very poor job explaining why I think this is related, I'm sorry. 

In my mind, if I were a Release Steward for a project. I would think I'd not 
only be in charge of helping the initial release but also managing 
"post-release bugfix-backport phase". That to me is what a PTL does with the 
Stable Team, so at least I would need to coordinate with the Stable Team. It at 
least seems implied. Now whether the person be an existing member of the Stable 
Team, doesn't seem important. But if the person is Release Steward, I'd expect 
them to be able to help approve changes to the branch/release they're 
stewarding. That, implies to me, that they'll need to work within the Stable 
Team. Given that train of thought, it makes sense to me that a Release Steward 
who is not already a Stable Team member would have to become one to continue 
their stewardship and would be trusted to (maybe only at first) approve changes 
for their release and not for all stable branches.

Does that help to explain my reasoning for bringing that up?

I don't want to scare folks off at all, but I think we should maybe chat a bit 
about this.
--  
Ian Cordasco


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Jeremy Stanley]

On 2016-09-07 16:20:49 + (+), Barrett, Carol L wrote:
[...]
> Why not have a PTL own the release from start to finish, with the
> PTL for the next release getting elected as above.
[...]

An overwhelming majority (87%) of our official project teams'
deliverables do not follow a synchronous release cadence, and that
suggestion would unnecessarily tie their governance even more
strongly to the schedules of the minority who do.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Dean Troyer]

On Wed, Sep 7, 2016 at 10:19 AM, Dean Troyer  wrote:

> I created the OSC session Etherpad[0] to start tracking these topic
> suggestions.
>
> [0]https://etherpad.openstack.org/p/osc-otaka-summit
>

/me sighs loudly

I wish I could blame the lack of caffeine, but alas, that URL is just wrong:

[0]https://etherpad.openstack.org/p/osc-ocata-summit

We now resume your normally scheduled programming...

dt

-- 

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Fox, Kevin M]

Right.

I use floating ip's because I need the flexibility to have an ip out last the 
vm its attached to.

auto floating ip's are in the "just put this on the network, I don't care what 
happens when I need to delete my vm" kind of thing. which just having public 
ip's also could also solve.

Thanks,
Kevin

From: Monty Taylor [mord...@inaugust.com]
Sent: Wednesday, September 07, 2016 10:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with 
Floating IP

On 09/07/2016 11:27 AM, Fox, Kevin M wrote:
> On the flip side, so is "I want my vm on a private network and I want a 
> floating ip to attach it to the public network."
>
> As some clouds don't support it.

Yes.

I'd categorize the main things possible as:

"I want a VM on a public network"
"I want a VM on a private network"
"I want a VM on both a public and private network"

For both instances of "public network" - there are:

"I want a public IP and do not care how that happens"
"I specifically want a floating IP"
"I specifically want a non-floating IP"

I'd argue though that the on the clouds where you have the option of a
direct attached public IP and also of getting a floating IP, the people
from the:

"I want a VM on both a public and private network"

camp who explicitly want a floating and not a fixed public IP are users
whom a "give me an auto public ip" feature is likely not going to serve
without making that feature too complex. It is already completely
possible for a user to create a server without an auto function, and
then to select a floating ip if that is a construct they desire.

With using an auto function, the user is effectively saying:

"I want a public IP and do not care how that happens"

which is the use case that is not possible today unless you happen to be
a shade user.

> 
> From: Monty Taylor [mord...@inaugust.com]
> Sent: Wednesday, September 07, 2016 8:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance 
> with Floating IP
>
> On 09/07/2016 03:31 AM, Martin Millnert wrote:
>> Hi Matt,
>>
>> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote:
>>> Floating IPs aren't required in OpenStack deployments, and anyone
>>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use
>>> or
>>> support them, at least without patching Nova. So I'm not sure what
>>> 'industry standard' is being referred to here.
>>
>> Nod. There are many models, I acknowledge that as well. When referring
>> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non-
>> legacy network behaviour. I didn't mean to imply that this model is the
>> only one, not even the best one, just the most widely used one at
>> large.
>
> It's a terrible networking choice. NAT is a terrible model for doing
> networking on the Internet. One of the things I'm most proud of about
> OpenStack is that we allow people to make clouds that are not inherently
> broken like AWS and GCE are.
>
> THAT SAID 
>
> "I would like to boot a VM that has a public IP"
>
> is a very clear use case, and it's very hard to achieve across OpenStack
> clouds. If you want to gouge your eyes out, go read the giant pile of
> code in the shade library which implements this.
>
> So - yes please on the feature - although it should be called
> "--auto-assign-public-ip" or "--auto-assign-external-ip" or something,
> not floating - because part of the problem is actually knowing whether
> or not the cloud requires floating ips or doesn't.
>
> However, as I mentioned, it's a GIANT amount of code to get this
> 'right'. We've gone thought a ton of iterations on it over the last 2
> years - I recommend strongly not starting from scratch.
>
   Problem:
  - nova: we're not adding anything
>>>
>>> Correct, nova provides the APIs to do this already, something sitting
>>> on top just needs to use them to orchestrate your use case.
>>
>> It exists in terms of multiple calls, yes. My e-mail is about what the
>> best multi-project solution to improving the total logic required to
>> achieve the goal, within OpenStack. It's not clear the answer is to
>> improve Nova's server create API, but it is one very obvious candidate
>> solution.
>
> It would be the nicest thing, but it would also require nova to learn a
> lot more about neutron than it currently needs to know.
>
>>> The get-me-a-network work is complete with the 2.37 API microversion
>>> in Nova and the 6.0.0 python-novaclient release. You can test it out
>>> today.
>>> However, it does not allocate and auto-assign a floating IP.
>>
>> I'd argue that what a typical user is most interested in is not, in
>> fact, in "having a network", but, "having internet access".
>
> Yes, this is correct.
>
>> Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one
>> of them, as you point out, deals with 

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2016-09-07 09:11:58 -0500:
> On 09/07/2016 08:58 AM, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
> >> https://review.openstack.org/366298
> >>
> >> This is just a bump to upper-constraints so is more minor to get testing
> >> working and fix the bug that occurred in Gnocchi (and possibly others).
> >>
> >> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
> >> 0.7.7 after the freeze (and backport them to stable/newton) so this is
> >> easier to merge.
> >>
> > 
> > If we have a known-bad version of the library, maybe it would be better
> > to incorporate that info into the global-requirements list before we
> > branch the requirements repository? I'm not sure what we've done in
> > this case for past cycles.
> > 
> > Doug
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> Are you fine with the knock on effects that a gr update would cause?

What do we have that uses oslo.db and is itself a library that would
need to be re-released?

Doug

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

Re: [openstack-dev] [Manila] Choose a new logo

[Ben Swartzlander]

On 09/07/2016 01:20 PM, Ben Swartzlander wrote:

For reasons discussed in last week's IRC meeting, we have vacated the
previous logo choice and are redoing the vote.

http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_6f0d111cec78c5ef;
akey=d34a751f2d084d79


http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_6f0d111cec78c5ef=d34a751f2d084d79


This time I'm using the CIVS system because it will allow us to
determine a #2 and #3 choice in case the new winner is disqualified for
any reason.

-Ben

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



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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Amrith Kumar]

Thierry, thanks for writing this up. I think this is a great idea, and 
something that will help focus the release stewards on a specific release while 
the PTL can coordinate activities for all aspects of the project. Where 
appropriate, and where a project decides to take this route, it allows PTL's to 
distribute some of the load amongst others in the project team.

One other important benefit of this approach is, I believe, that we can expand 
the leadership pool within OpenStack by distributing the leadership activities 
to the release stewards. One of the conversations at the OpenStack SWG [1] and 
[2] has been to expand this leadership pool and I believe that this proposal 
for release stewards is a good step in that direction.

Thanks,

-amrith

[1] https://review.openstack.org/#/c/337895/
[2] https://wiki.openstack.org/wiki/Meetings/SWGMeeting

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Wednesday, September 07, 2016 11:44 AM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [all] Timeframe for future elections & "Release
> stewards"
> 
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, the
> Summit will happen further away from the release day and more around the
> middle of the next development cycle. You can find more info on the
> rationale for that at [1] and [2] if interested, this is not the topic
> of this email.
> 
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and TC positions in the middle of the
> cycle. Crazy, right ? That's what I first thought. But after discussing
> it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in
> the middle of the design summit prep, with old PTLs making Design Summit
> space requests that will affect their successor. It's not as if there
> was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a
> few months before actual development starts, with discussions on next
> cycle priorities and Design Summit prep. They continue a few months
> after release, with critical stable branch backports and communication
> about landed features. So they are one year-long, overlapping cycles
> (like explained on the diagram at [4]). With that in mind, the PTL/TC
> election actually would happen just before the start of the start of the
> requirements-gathering pre-development phase of the next development
> cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a
> development cycle is that you don't want to introduce a discontinuity in
> leadership in that development cycle. To mitigate that, we propose the
> introduction of a new role, the "release steward", which would be
> attached to the release cycle. That person (who may or may not double as
> PTL) would be responsible for a complete release cycle on a given
> project team, from requirements gathering phase to post-release
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release
> stewards at all times. This would help with the awkward situation where
> the PTL ends up having to think about the next cycle and prepare the
> Design Summit (or PTG) while still being knee-deep juggling with feature
> freeze exceptions, getting the current release out of the door, and
> coordinating early critical fixes stable backports. Those two jobs could
> be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may want
> to use the same super-human to handle everything (PTL, release steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the
> newly-elected PTL, the release steward would be responsible for the full
> release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and
> keep the election period as currently defined in the charter (rather
> than having to change it). The PTLs we will elect in the coming weeks
> won't be renewed before April, 2017 -- while Pike development will start
> in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to me
> with questions on this.
> 
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-ptl-
> seats
> [4]
> 

[openstack-dev] [Neutron] Feature Freeze and Feature Freeze exceptions

[Armando M.]

Hi folks,

We are about a week away from cutting our first release candidate [0]. In
preparation for that event, we need to make sure our postmortem [1] and FFE
requests are in good order.

For those of you have not had the chance of commenting on [1], please go
ahead and provide your input. Anything else that lacks feedback will very
likely be deferred to Ocata [2] or killed altogether if I am unable to
trace back any recent development. Also, bear in mind that your pending
specs should be retargeted to the new Ocata spec directory [3].

As soon as we cut RC1 and the newton stable branch is cut, master is open
again. For critical or last minute fixes, please file a bug and target for
RC1 for us to evaluate its release impact.

Many thanks for your collaboration!
Cheers,
Armando

[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/102829.html
[1] https://review.openstack.org/#/c/360207/
[2] https://launchpad.net/neutron/ocata
[3] https://github.com/openstack/neutron-specs/tree/master/specs/ocata
[4] https://launchpad.net/neutron/+milestone/newton-rc1
__
OpenStack Development Mailing 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] [Manila] Choose a new logo

[Ben Swartzlander]

For reasons discussed in last week's IRC meeting, we have vacated the 
previous logo choice and are redoing the vote.


http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_6f0d111cec78c5ef;
akey=d34a751f2d084d79

This time I'm using the CIVS system because it will allow us to 
determine a #2 and #3 choice in case the new winner is disqualified for 
any reason.


-Ben

__
OpenStack Development Mailing List (not for 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] Timeframe for future elections & "Release stewards"

[Sean Dague]

On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> Barrett, Carol L wrote:
>> From: Sean Dague [mailto:s...@dague.net] 
>>> I think another option would be to run the PTL election early, but just 
>>> don't have the turn over happen until the master release opens up. The 
>>> current transition period is > > > 
>>> actually quite short as noted by the comments around how design summit 
>>> planning happens. Having the PTL-next elected half way through the cycle, 
>>> but having PTL current > 
>>> still > own landing the current release actually provides a lot more 
>>> transition time.
>>>
>>> -Sean
>>
>> I had a similar thought to Sean's, with a few changes. Why not have a PTL 
>> own the release from start to finish, with the PTL for the next release 
>> getting elected as above. In this model, it would probably be advisable (or 
>> a guideline) that a PTL not run for 2 cycles in a row, because the work load 
>> would be unmanageable. This approach could help to grow a stronger 
>> leadership pipeline for each project and provide more opportunities for 
>> people in the team to grow their skills and take on leadership.
> 
> The drawback of this approach is that it breaks the governance model
> around project teams. You need a "the buck stops here" person (even if
> that power is seldom used). But you can't have two -- what happens if
> they disagree ?
> 
> So it's simpler to have a single PTL at all times and one or two release
> liaisons at all times. Could be the same person though.

It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
decisions on master once it opens up, and guides it until it's a stable
branch. It doesn't seem like it breaks anything to me.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Dean Troyer]

On Wed, Sep 7, 2016 at 11:35 AM, Ian Cordasco 
wrote:

> One question, should "Release Stewards" also be members of the Stable Team
> for that project or will they become members of the Stable Team? It seems
> like there should be a relationship there to me (although maybe not a
> strictly enforced one).
>

That relationship is in the job description, but making it a bit more
formal could be beneficial to some teams, as well as spread the stable team
load a bit (I have no ideal what their workload is line now).

I could also see the release steward role extending, informally, until that
release's EOL.  Maybe that should also be addressed, be it affirmative or
negative...

dt

-- 

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Monty Taylor]

On 09/07/2016 11:27 AM, Fox, Kevin M wrote:
> On the flip side, so is "I want my vm on a private network and I want a 
> floating ip to attach it to the public network."
> 
> As some clouds don't support it.

Yes.

I'd categorize the main things possible as:

"I want a VM on a public network"
"I want a VM on a private network"
"I want a VM on both a public and private network"

For both instances of "public network" - there are:

"I want a public IP and do not care how that happens"
"I specifically want a floating IP"
"I specifically want a non-floating IP"

I'd argue though that the on the clouds where you have the option of a
direct attached public IP and also of getting a floating IP, the people
from the:

"I want a VM on both a public and private network"

camp who explicitly want a floating and not a fixed public IP are users
whom a "give me an auto public ip" feature is likely not going to serve
without making that feature too complex. It is already completely
possible for a user to create a server without an auto function, and
then to select a floating ip if that is a construct they desire.

With using an auto function, the user is effectively saying:

"I want a public IP and do not care how that happens"

which is the use case that is not possible today unless you happen to be
a shade user.

> 
> From: Monty Taylor [mord...@inaugust.com]
> Sent: Wednesday, September 07, 2016 8:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance 
> with Floating IP
> 
> On 09/07/2016 03:31 AM, Martin Millnert wrote:
>> Hi Matt,
>>
>> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote:
>>> Floating IPs aren't required in OpenStack deployments, and anyone
>>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use
>>> or
>>> support them, at least without patching Nova. So I'm not sure what
>>> 'industry standard' is being referred to here.
>>
>> Nod. There are many models, I acknowledge that as well. When referring
>> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non-
>> legacy network behaviour. I didn't mean to imply that this model is the
>> only one, not even the best one, just the most widely used one at
>> large.
> 
> It's a terrible networking choice. NAT is a terrible model for doing
> networking on the Internet. One of the things I'm most proud of about
> OpenStack is that we allow people to make clouds that are not inherently
> broken like AWS and GCE are.
> 
> THAT SAID 
> 
> "I would like to boot a VM that has a public IP"
> 
> is a very clear use case, and it's very hard to achieve across OpenStack
> clouds. If you want to gouge your eyes out, go read the giant pile of
> code in the shade library which implements this.
> 
> So - yes please on the feature - although it should be called
> "--auto-assign-public-ip" or "--auto-assign-external-ip" or something,
> not floating - because part of the problem is actually knowing whether
> or not the cloud requires floating ips or doesn't.
> 
> However, as I mentioned, it's a GIANT amount of code to get this
> 'right'. We've gone thought a ton of iterations on it over the last 2
> years - I recommend strongly not starting from scratch.
> 
   Problem:
  - nova: we're not adding anything
>>>
>>> Correct, nova provides the APIs to do this already, something sitting
>>> on top just needs to use them to orchestrate your use case.
>>
>> It exists in terms of multiple calls, yes. My e-mail is about what the
>> best multi-project solution to improving the total logic required to
>> achieve the goal, within OpenStack. It's not clear the answer is to
>> improve Nova's server create API, but it is one very obvious candidate
>> solution.
> 
> It would be the nicest thing, but it would also require nova to learn a
> lot more about neutron than it currently needs to know.
> 
>>> The get-me-a-network work is complete with the 2.37 API microversion
>>> in Nova and the 6.0.0 python-novaclient release. You can test it out
>>> today.
>>> However, it does not allocate and auto-assign a floating IP.
>>
>> I'd argue that what a typical user is most interested in is not, in
>> fact, in "having a network", but, "having internet access".
> 
> Yes, this is correct.
> 
>> Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one
>> of them, as you point out, deals with auto-allocating-and-assigning
>> FIPs, which is fine in and of itself - Rome wasn't built in one day
>> either.
>>
>> I.e. today,
>>  A) 'networks=auto' != "get me online",
>>  B) 'networks=auto' == "get me an openstack network interface".
>>
>> B is a subset of A, but A is not a subset of B.
>>
>> Assuming,
>>  1) 'networks' is definitely meant to mean just what it's called, and does 
>> today, and
>>  2) "get me online" is a desirable feature,
>>
>> then it is actually the case that we're missing an option like 
>> "public_ip=auto" or similar to complete 

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Monty Taylor]

On 09/07/2016 11:43 AM, Davanum Srinivas wrote:
> On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco  wrote:
>>
>>
>> -Original Message-
>> From: Monty Taylor 
>> Reply: OpenStack Development Mailing List (not for usage questions) 
>> 
>> Date: September 7, 2016 at 10:58:52
>> To: openstack-dev@lists.openstack.org 
>> Subject:  Re: [openstack-dev] [all] Timeframe for future elections & 
>> "Release stewards"
>>
>>> On 09/07/2016 10:43 AM, Thierry Carrez wrote:
 Hi everyone,

 As you probably know by now, starting with the Boston event in 2017, the
 Summit will happen further away from the release day and more around the
 middle of the next development cycle. You can find more info on the
 rationale for that at [1] and [2] if interested, this is not the topic
 of this email.

 One interesting side-effect is that since the timing of the election
 period (for PTL and TC positions) is defined in the TC charter[3]
 relative to the *Summit*, it means that (unless we change this) we'll
 now run elections to renew PTL and TC positions in the middle of the
 cycle. Crazy, right ? That's what I first thought. But after discussing
 it with various people, this is not as crazy as it sounds.

 First, the current election timing is not perfect -- we change PTLs in
 the middle of the design summit prep, with old PTLs making Design Summit
 space requests that will affect their successor. It's not as if there
 was a perfect timing for doing elections.

 Second, release cycles are longer than 6 months. They actually start a
 few months before actual development starts, with discussions on next
 cycle priorities and Design Summit prep. They continue a few months
 after release, with critical stable branch backports and communication
 about landed features. So they are one year-long, overlapping cycles
 (like explained on the diagram at [4]). With that in mind, the PTL/TC
 election actually would happen just before the start of the start of the
 requirements-gathering pre-development phase of the next development
 cycle, which makes a lot of sense.

 Now, the main drawback of holding elections in the middle of a
 development cycle is that you don't want to introduce a discontinuity in
 leadership in that development cycle. To mitigate that, we propose the
 introduction of a new role, the "release steward", which would be
 attached to the release cycle. That person (who may or may not double as
 PTL) would be responsible for a complete release cycle on a given
 project team, from requirements gathering phase to post-release
 bugfix-backport phase. A sort of per-cycle release liaison on steroids.

 Since development cycles overlap, there would be two active release
 stewards at all times. This would help with the awkward situation where
 the PTL ends up having to think about the next cycle and prepare the
 Design Summit (or PTG) while still being knee-deep juggling with feature
 freeze exceptions, getting the current release out of the door, and
 coordinating early critical fixes stable backports. Those two jobs could
 be held by two different people.

 Now, some teams (especially those doing intermediary releases) may want
 to use the same super-human to handle everything (PTL, release steward,
 release+1 steward), and some others might use two or three humans to
 spread the load. That's up to them. But once designated by the
 newly-elected PTL, the release steward would be responsible for the full
 release cycle and would not be displaced by the next PTL 6 months later.
 One year being a long time, if a steward needs to step down, the
 currently-active PTL would appoint someone else to finish the job.

 With this new concept I think we can get the best of both worlds, and
 keep the election period as currently defined in the charter (rather
 than having to change it). The PTLs we will elect in the coming weeks
 won't be renewed before April, 2017 -- while Pike development will start
 in February.

 I know this can all be a bit confusing, so feel free to reach out to me
 with questions on this.
>>>
>>> I think this is a great idea. Having a person be on point for a
>>> particular release from inception to whenever we stop caring about it
>>> makes a lot of sense.
>>
>> I agree. Regardless of how PTL elections end up working, I think we should 
>> definitely move forward with this "Release Stewards" concept. It sounds like 
>> an excellent idea.
> 
> Also since "Release Stewards" are nominated by PTL, projects can just
> start using this concept right away (as it's not an elected position).
> +1 from me.
> 
>> One question, should "Release Stewards" also be 

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Anita Kuno]

On 16-09-07 12:43 PM, Davanum Srinivas wrote:

On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco  wrote:


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

Date: September 7, 2016 at 10:58:52
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 09/07/2016 10:43 AM, Thierry Carrez wrote:

Hi everyone,

As you probably know by now, starting with the Boston event in 2017, the
Summit will happen further away from the release day and more around the
middle of the next development cycle. You can find more info on the
rationale for that at [1] and [2] if interested, this is not the topic
of this email.

One interesting side-effect is that since the timing of the election
period (for PTL and TC positions) is defined in the TC charter[3]
relative to the *Summit*, it means that (unless we change this) we'll
now run elections to renew PTL and TC positions in the middle of the
cycle. Crazy, right ? That's what I first thought. But after discussing
it with various people, this is not as crazy as it sounds.

First, the current election timing is not perfect -- we change PTLs in
the middle of the design summit prep, with old PTLs making Design Summit
space requests that will affect their successor. It's not as if there
was a perfect timing for doing elections.

Second, release cycles are longer than 6 months. They actually start a
few months before actual development starts, with discussions on next
cycle priorities and Design Summit prep. They continue a few months
after release, with critical stable branch backports and communication
about landed features. So they are one year-long, overlapping cycles
(like explained on the diagram at [4]). With that in mind, the PTL/TC
election actually would happen just before the start of the start of the
requirements-gathering pre-development phase of the next development
cycle, which makes a lot of sense.

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

Since development cycles overlap, there would be two active release
stewards at all times. This would help with the awkward situation where
the PTL ends up having to think about the next cycle and prepare the
Design Summit (or PTG) while still being knee-deep juggling with feature
freeze exceptions, getting the current release out of the door, and
coordinating early critical fixes stable backports. Those two jobs could
be held by two different people.

Now, some teams (especially those doing intermediary releases) may want
to use the same super-human to handle everything (PTL, release steward,
release+1 steward), and some others might use two or three humans to
spread the load. That's up to them. But once designated by the
newly-elected PTL, the release steward would be responsible for the full
release cycle and would not be displaced by the next PTL 6 months later.
One year being a long time, if a steward needs to step down, the
currently-active PTL would appoint someone else to finish the job.

With this new concept I think we can get the best of both worlds, and
keep the election period as currently defined in the charter (rather
than having to change it). The PTLs we will elect in the coming weeks
won't be renewed before April, 2017 -- while Pike development will start
in February.

I know this can all be a bit confusing, so feel free to reach out to me
with questions on this.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should definitely 
move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


One question, should "Release Stewards" also be members of the Stable Team for 
that project or will they become members of the Stable Team? It seems like there should 
be a relationship there to me (although maybe not a strictly enforced one).


Welcomed and required are two different things. I think the stable team 
is always willing to work with new contributors. I additionally think 
that floating the expectation that someone 

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[gordon chung]

just a heads up, oslo.db 4.13.2 is also broken. we will need this: 
https://review.openstack.org/#/c/366362/ or something that fixes issue :)

On 07/09/16 09:21 AM, Matthew Thode wrote:
> https://review.openstack.org/366298
>
> This is just a bump to upper-constraints so is more minor to get testing
> working and fix the bug that occurred in Gnocchi (and possibly others).
>
> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
> 0.7.7 after the freeze (and backport them to stable/newton) so this is
> easier to merge.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
gord

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Davanum Srinivas]

On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco  wrote:
>
>
> -Original Message-
> From: Monty Taylor 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: September 7, 2016 at 10:58:52
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
> stewards"
>
>> On 09/07/2016 10:43 AM, Thierry Carrez wrote:
>> > Hi everyone,
>> >
>> > As you probably know by now, starting with the Boston event in 2017, the
>> > Summit will happen further away from the release day and more around the
>> > middle of the next development cycle. You can find more info on the
>> > rationale for that at [1] and [2] if interested, this is not the topic
>> > of this email.
>> >
>> > One interesting side-effect is that since the timing of the election
>> > period (for PTL and TC positions) is defined in the TC charter[3]
>> > relative to the *Summit*, it means that (unless we change this) we'll
>> > now run elections to renew PTL and TC positions in the middle of the
>> > cycle. Crazy, right ? That's what I first thought. But after discussing
>> > it with various people, this is not as crazy as it sounds.
>> >
>> > First, the current election timing is not perfect -- we change PTLs in
>> > the middle of the design summit prep, with old PTLs making Design Summit
>> > space requests that will affect their successor. It's not as if there
>> > was a perfect timing for doing elections.
>> >
>> > Second, release cycles are longer than 6 months. They actually start a
>> > few months before actual development starts, with discussions on next
>> > cycle priorities and Design Summit prep. They continue a few months
>> > after release, with critical stable branch backports and communication
>> > about landed features. So they are one year-long, overlapping cycles
>> > (like explained on the diagram at [4]). With that in mind, the PTL/TC
>> > election actually would happen just before the start of the start of the
>> > requirements-gathering pre-development phase of the next development
>> > cycle, which makes a lot of sense.
>> >
>> > Now, the main drawback of holding elections in the middle of a
>> > development cycle is that you don't want to introduce a discontinuity in
>> > leadership in that development cycle. To mitigate that, we propose the
>> > introduction of a new role, the "release steward", which would be
>> > attached to the release cycle. That person (who may or may not double as
>> > PTL) would be responsible for a complete release cycle on a given
>> > project team, from requirements gathering phase to post-release
>> > bugfix-backport phase. A sort of per-cycle release liaison on steroids.
>> >
>> > Since development cycles overlap, there would be two active release
>> > stewards at all times. This would help with the awkward situation where
>> > the PTL ends up having to think about the next cycle and prepare the
>> > Design Summit (or PTG) while still being knee-deep juggling with feature
>> > freeze exceptions, getting the current release out of the door, and
>> > coordinating early critical fixes stable backports. Those two jobs could
>> > be held by two different people.
>> >
>> > Now, some teams (especially those doing intermediary releases) may want
>> > to use the same super-human to handle everything (PTL, release steward,
>> > release+1 steward), and some others might use two or three humans to
>> > spread the load. That's up to them. But once designated by the
>> > newly-elected PTL, the release steward would be responsible for the full
>> > release cycle and would not be displaced by the next PTL 6 months later.
>> > One year being a long time, if a steward needs to step down, the
>> > currently-active PTL would appoint someone else to finish the job.
>> >
>> > With this new concept I think we can get the best of both worlds, and
>> > keep the election period as currently defined in the charter (rather
>> > than having to change it). The PTLs we will elect in the coming weeks
>> > won't be renewed before April, 2017 -- while Pike development will start
>> > in February.
>> >
>> > I know this can all be a bit confusing, so feel free to reach out to me
>> > with questions on this.
>>
>> I think this is a great idea. Having a person be on point for a
>> particular release from inception to whenever we stop caring about it
>> makes a lot of sense.
>
> I agree. Regardless of how PTL elections end up working, I think we should 
> definitely move forward with this "Release Stewards" concept. It sounds like 
> an excellent idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.

> One question, should "Release Stewards" also be members of the Stable Team 
> for that project or will they become members of the 

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Ian Cordasco]

 

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

Date: September 7, 2016 at 10:58:52
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

> On 09/07/2016 10:43 AM, Thierry Carrez wrote:
> > Hi everyone,
> >
> > As you probably know by now, starting with the Boston event in 2017, the
> > Summit will happen further away from the release day and more around the
> > middle of the next development cycle. You can find more info on the
> > rationale for that at [1] and [2] if interested, this is not the topic
> > of this email.
> >
> > One interesting side-effect is that since the timing of the election
> > period (for PTL and TC positions) is defined in the TC charter[3]
> > relative to the *Summit*, it means that (unless we change this) we'll
> > now run elections to renew PTL and TC positions in the middle of the
> > cycle. Crazy, right ? That's what I first thought. But after discussing
> > it with various people, this is not as crazy as it sounds.
> >
> > First, the current election timing is not perfect -- we change PTLs in
> > the middle of the design summit prep, with old PTLs making Design Summit
> > space requests that will affect their successor. It's not as if there
> > was a perfect timing for doing elections.
> >
> > Second, release cycles are longer than 6 months. They actually start a
> > few months before actual development starts, with discussions on next
> > cycle priorities and Design Summit prep. They continue a few months
> > after release, with critical stable branch backports and communication
> > about landed features. So they are one year-long, overlapping cycles
> > (like explained on the diagram at [4]). With that in mind, the PTL/TC
> > election actually would happen just before the start of the start of the
> > requirements-gathering pre-development phase of the next development
> > cycle, which makes a lot of sense.
> >
> > Now, the main drawback of holding elections in the middle of a
> > development cycle is that you don't want to introduce a discontinuity in
> > leadership in that development cycle. To mitigate that, we propose the
> > introduction of a new role, the "release steward", which would be
> > attached to the release cycle. That person (who may or may not double as
> > PTL) would be responsible for a complete release cycle on a given
> > project team, from requirements gathering phase to post-release
> > bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> >
> > Since development cycles overlap, there would be two active release
> > stewards at all times. This would help with the awkward situation where
> > the PTL ends up having to think about the next cycle and prepare the
> > Design Summit (or PTG) while still being knee-deep juggling with feature
> > freeze exceptions, getting the current release out of the door, and
> > coordinating early critical fixes stable backports. Those two jobs could
> > be held by two different people.
> >
> > Now, some teams (especially those doing intermediary releases) may want
> > to use the same super-human to handle everything (PTL, release steward,
> > release+1 steward), and some others might use two or three humans to
> > spread the load. That's up to them. But once designated by the
> > newly-elected PTL, the release steward would be responsible for the full
> > release cycle and would not be displaced by the next PTL 6 months later.
> > One year being a long time, if a steward needs to step down, the
> > currently-active PTL would appoint someone else to finish the job.
> >
> > With this new concept I think we can get the best of both worlds, and
> > keep the election period as currently defined in the charter (rather
> > than having to change it). The PTLs we will elect in the coming weeks
> > won't be renewed before April, 2017 -- while Pike development will start
> > in February.
> >
> > I know this can all be a bit confusing, so feel free to reach out to me
> > with questions on this.
>  
> I think this is a great idea. Having a person be on point for a
> particular release from inception to whenever we stop caring about it
> makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should 
definitely move forward with this "Release Stewards" concept. It sounds like an 
excellent idea.

One question, should "Release Stewards" also be members of the Stable Team for 
that project or will they become members of the Stable Team? It seems like 
there should be a relationship there to me (although maybe not a strictly 
enforced one).

--  
Ian Cordasco


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Jim Rollenhagen]

On Wed, Sep 7, 2016 at 11:43 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> As you probably know by now, starting with the Boston event in 2017, the
> Summit will happen further away from the release day and more around the
> middle of the next development cycle. You can find more info on the
> rationale for that at [1] and [2] if interested, this is not the topic
> of this email.
>
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and TC positions in the middle of the
> cycle. Crazy, right ? That's what I first thought. But after discussing
> it with various people, this is not as crazy as it sounds.
>
> First, the current election timing is not perfect -- we change PTLs in
> the middle of the design summit prep, with old PTLs making Design Summit
> space requests that will affect their successor. It's not as if there
> was a perfect timing for doing elections.
>
> Second, release cycles are longer than 6 months. They actually start a
> few months before actual development starts, with discussions on next
> cycle priorities and Design Summit prep. They continue a few months
> after release, with critical stable branch backports and communication
> about landed features. So they are one year-long, overlapping cycles
> (like explained on the diagram at [4]). With that in mind, the PTL/TC
> election actually would happen just before the start of the start of the
> requirements-gathering pre-development phase of the next development
> cycle, which makes a lot of sense.
>
> Now, the main drawback of holding elections in the middle of a
> development cycle is that you don't want to introduce a discontinuity in
> leadership in that development cycle. To mitigate that, we propose the
> introduction of a new role, the "release steward", which would be
> attached to the release cycle. That person (who may or may not double as
> PTL) would be responsible for a complete release cycle on a given
> project team, from requirements gathering phase to post-release
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
>
> Since development cycles overlap, there would be two active release
> stewards at all times. This would help with the awkward situation where
> the PTL ends up having to think about the next cycle and prepare the
> Design Summit (or PTG) while still being knee-deep juggling with feature
> freeze exceptions, getting the current release out of the door, and
> coordinating early critical fixes stable backports. Those two jobs could
> be held by two different people.
>
> Now, some teams (especially those doing intermediary releases) may want
> to use the same super-human to handle everything (PTL, release steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the
> newly-elected PTL, the release steward would be responsible for the full
> release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the
> currently-active PTL would appoint someone else to finish the job.
>
> With this new concept I think we can get the best of both worlds, and
> keep the election period as currently defined in the charter (rather
> than having to change it). The PTLs we will elect in the coming weeks
> won't be renewed before April, 2017 -- while Pike development will start
> in February.
>
> I know this can all be a bit confusing, so feel free to reach out to me
> with questions on this.
>
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-ptl-seats
> [4]
> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png
>
> --
> Thierry Carrez (ttx)

I like this. As someone that has been PTL for multiple cycles, it is
incredibly stressful trying to finish the release, start planning for the
next one, manage summit planning, etc. I'd love to have someone
designated to manage the release-specific bits of the project, while
PTLs can worry about the longer-term vision of the project and the
day-to-day management.

Thanks for writing this up, Thierry. :)

// jim

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Anita Kuno]

On 16-09-07 12:20 PM, Barrett, Carol L wrote:


-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Wednesday, September 07, 2016 9:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 09/07/2016 11:43 AM, Thierry Carrez wrote:

Hi everyone,

As you probably know by now, starting with the Boston event in 2017,
the Summit will happen further away from the release day and more
around the middle of the next development cycle. You can find more
info on the rationale for that at [1] and [2] if interested, this is
not the topic of this email.

One interesting side-effect is that since the timing of the election
period (for PTL and TC positions) is defined in the TC charter[3]
relative to the *Summit*, it means that (unless we change this) we'll
now run elections to renew PTL and TC positions in the middle of the
cycle. Crazy, right ? That's what I first thought. But after
discussing it with various people, this is not as crazy as it sounds.

First, the current election timing is not perfect -- we change PTLs in
the middle of the design summit prep, with old PTLs making Design
Summit space requests that will affect their successor. It's not as if
there was a perfect timing for doing elections.

Second, release cycles are longer than 6 months. They actually start a
few months before actual development starts, with discussions on next
cycle priorities and Design Summit prep. They continue a few months
after release, with critical stable branch backports and communication
about landed features. So they are one year-long, overlapping cycles
(like explained on the diagram at [4]). With that in mind, the PTL/TC
election actually would happen just before the start of the start of
the requirements-gathering pre-development phase of the next
development cycle, which makes a lot of sense.

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity
in leadership in that development cycle. To mitigate that, we propose
the introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double
as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

Since development cycles overlap, there would be two active release
stewards at all times. This would help with the awkward situation
where the PTL ends up having to think about the next cycle and prepare
the Design Summit (or PTG) while still being knee-deep juggling with
feature freeze exceptions, getting the current release out of the
door, and coordinating early critical fixes stable backports. Those
two jobs could be held by two different people.

Now, some teams (especially those doing intermediary releases) may
want to use the same super-human to handle everything (PTL, release
steward,
release+1 steward), and some others might use two or three humans to
spread the load. That's up to them. But once designated by the
newly-elected PTL, the release steward would be responsible for the
full release cycle and would not be displaced by the next PTL 6 months later.
One year being a long time, if a steward needs to step down, the
currently-active PTL would appoint someone else to finish the job.

With this new concept I think we can get the best of both worlds, and
keep the election period as currently defined in the charter (rather
than having to change it). The PTLs we will elect in the coming weeks
won't be renewed before April, 2017 -- while Pike development will
start in February.

I know this can all be a bit confusing, so feel free to reach out to
me with questions on this.

[1] http://www.openstack.org/ptg
[2] http://www.openstack.org/ptg/ptgfaq/
[3]
http://governance.openstack.org/reference/charter.html#election-for-pt
l-seats
[4]
http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-r
evised.png

I think another option would be to run the PTL election early, but just don't have the 
turn over happen until the master release opens up. The current transition period is 
> > >
actually quite short as noted by the comments around how design summit planning 
happens. Having the PTL-next elected half way through the cycle, but having PTL 
current >
still > own landing the current release actually provides a lot more transition 
time.

-Sean

I had a similar thought to Sean's, with a few changes. Why not have a PTL own 
the release from start to finish, with the PTL for the next release getting 
elected as above. In this model, it would probably be advisable (or a 
guideline) that a PTL not run for 2 cycles in a row, because the work load 
would be unmanageable. This approach could help to grow a stronger leadership 
pipeline for each project and provide more 

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Fox, Kevin M]

On the flip side, so is "I want my vm on a private network and I want a 
floating ip to attach it to the public network."

As some clouds don't support it.

Thanks,
Kevin

From: Monty Taylor [mord...@inaugust.com]
Sent: Wednesday, September 07, 2016 8:55 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with 
Floating IP

On 09/07/2016 03:31 AM, Martin Millnert wrote:
> Hi Matt,
>
> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote:
>> Floating IPs aren't required in OpenStack deployments, and anyone
>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use
>> or
>> support them, at least without patching Nova. So I'm not sure what
>> 'industry standard' is being referred to here.
>
> Nod. There are many models, I acknowledge that as well. When referring
> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non-
> legacy network behaviour. I didn't mean to imply that this model is the
> only one, not even the best one, just the most widely used one at
> large.

It's a terrible networking choice. NAT is a terrible model for doing
networking on the Internet. One of the things I'm most proud of about
OpenStack is that we allow people to make clouds that are not inherently
broken like AWS and GCE are.

THAT SAID 

"I would like to boot a VM that has a public IP"

is a very clear use case, and it's very hard to achieve across OpenStack
clouds. If you want to gouge your eyes out, go read the giant pile of
code in the shade library which implements this.

So - yes please on the feature - although it should be called
"--auto-assign-public-ip" or "--auto-assign-external-ip" or something,
not floating - because part of the problem is actually knowing whether
or not the cloud requires floating ips or doesn't.

However, as I mentioned, it's a GIANT amount of code to get this
'right'. We've gone thought a ton of iterations on it over the last 2
years - I recommend strongly not starting from scratch.

>>>   Problem:
>>>  - nova: we're not adding anything
>>
>> Correct, nova provides the APIs to do this already, something sitting
>> on top just needs to use them to orchestrate your use case.
>
> It exists in terms of multiple calls, yes. My e-mail is about what the
> best multi-project solution to improving the total logic required to
> achieve the goal, within OpenStack. It's not clear the answer is to
> improve Nova's server create API, but it is one very obvious candidate
> solution.

It would be the nicest thing, but it would also require nova to learn a
lot more about neutron than it currently needs to know.

>> The get-me-a-network work is complete with the 2.37 API microversion
>> in Nova and the 6.0.0 python-novaclient release. You can test it out
>> today.
>> However, it does not allocate and auto-assign a floating IP.
>
> I'd argue that what a typical user is most interested in is not, in
> fact, in "having a network", but, "having internet access".

Yes, this is correct.

> Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one
> of them, as you point out, deals with auto-allocating-and-assigning
> FIPs, which is fine in and of itself - Rome wasn't built in one day
> either.
>
> I.e. today,
>  A) 'networks=auto' != "get me online",
>  B) 'networks=auto' == "get me an openstack network interface".
>
> B is a subset of A, but A is not a subset of B.
>
> Assuming,
>  1) 'networks' is definitely meant to mean just what it's called, and does 
> today, and
>  2) "get me online" is a desirable feature,
>
> then it is actually the case that we're missing an option like 
> "public_ip=auto" or similar to complete the picture.
> In the deployments you mention above, it'd have virtually nothing to do. In 
> others, for example FIP, it'd have only little to do.
>
> Then, the combination networks=auto, public_ip(v4)=auto would equal 
> "getmeonline".

Yes. This is, in fact, how the shade create_server API works.

>>> So how can one solve an OpenStack cross-project problem like
> this,
>>> possibly without having to implement an artificial
>>> superintelligence
>>> first?
>>
>> Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or
>> maybe even Heat would support this.
>
> Right, the total amount of options are thus:
> 1) Introduce a new, custom API service to proxy for Nova, and fork
> Horizon to handle it,
> 2) Patch Nova and do UI fixes in Horizon, but do not submit it
> upstream,
> 3) Patch Nova and do UI fixes in Horizon, and submit it upstream,
> 4) Make Horizon stateful and do UI changes, but do not submit it
> upstream,
> 5) Make Horizon stateful and do UI changes, and submit it upstream
>
> I'm sure there are more enumerations of this, but Heat is not one of
> them. :-)
>
> To me, from the above, option 3 seems the one that involves the least
> amount of complexity, which already there is a good indication of being
> the right choice.

I think 

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Thierry Carrez]

Barrett, Carol L wrote:
> From: Sean Dague [mailto:s...@dague.net] 
>> I think another option would be to run the PTL election early, but just 
>> don't have the turn over happen until the master release opens up. The 
>> current transition period is > > > 
>> actually quite short as noted by the comments around how design summit 
>> planning happens. Having the PTL-next elected half way through the cycle, 
>> but having PTL current > 
>> still > own landing the current release actually provides a lot more 
>> transition time.
>>
>>  -Sean
> 
> I had a similar thought to Sean's, with a few changes. Why not have a PTL own 
> the release from start to finish, with the PTL for the next release getting 
> elected as above. In this model, it would probably be advisable (or a 
> guideline) that a PTL not run for 2 cycles in a row, because the work load 
> would be unmanageable. This approach could help to grow a stronger leadership 
> pipeline for each project and provide more opportunities for people in the 
> team to grow their skills and take on leadership.

The drawback of this approach is that it breaks the governance model
around project teams. You need a "the buck stops here" person (even if
that power is seldom used). But you can't have two -- what happens if
they disagree ?

So it's simpler to have a single PTL at all times and one or two release
liaisons at all times. Could be the same person though.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Thierry Carrez]

Davanum Srinivas wrote:
> Doug, Thierry,
> 
> Do we want the stewards to serve as the CPL for Release team as well?

Yes, they probably would be an evolution of the current release
liaisons. Like I said in the email, "a sort of per-cycle release liaison
on steroids".

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Barrett, Carol L]

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Wednesday, September 07, 2016 9:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 09/07/2016 11:43 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, 
> the Summit will happen further away from the release day and more 
> around the middle of the next development cycle. You can find more 
> info on the rationale for that at [1] and [2] if interested, this is 
> not the topic of this email.
> 
> One interesting side-effect is that since the timing of the election 
> period (for PTL and TC positions) is defined in the TC charter[3] 
> relative to the *Summit*, it means that (unless we change this) we'll 
> now run elections to renew PTL and TC positions in the middle of the 
> cycle. Crazy, right ? That's what I first thought. But after 
> discussing it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in 
> the middle of the design summit prep, with old PTLs making Design 
> Summit space requests that will affect their successor. It's not as if 
> there was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a 
> few months before actual development starts, with discussions on next 
> cycle priorities and Design Summit prep. They continue a few months 
> after release, with critical stable branch backports and communication 
> about landed features. So they are one year-long, overlapping cycles 
> (like explained on the diagram at [4]). With that in mind, the PTL/TC 
> election actually would happen just before the start of the start of 
> the requirements-gathering pre-development phase of the next 
> development cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a 
> development cycle is that you don't want to introduce a discontinuity 
> in leadership in that development cycle. To mitigate that, we propose 
> the introduction of a new role, the "release steward", which would be 
> attached to the release cycle. That person (who may or may not double 
> as
> PTL) would be responsible for a complete release cycle on a given 
> project team, from requirements gathering phase to post-release 
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release 
> stewards at all times. This would help with the awkward situation 
> where the PTL ends up having to think about the next cycle and prepare 
> the Design Summit (or PTG) while still being knee-deep juggling with 
> feature freeze exceptions, getting the current release out of the 
> door, and coordinating early critical fixes stable backports. Those 
> two jobs could be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may 
> want to use the same super-human to handle everything (PTL, release 
> steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the 
> newly-elected PTL, the release steward would be responsible for the 
> full release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the 
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and 
> keep the election period as currently defined in the charter (rather 
> than having to change it). The PTLs we will elect in the coming weeks 
> won't be renewed before April, 2017 -- while Pike development will 
> start in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to 
> me with questions on this.
> 
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-pt
> l-seats
> [4]
> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-r
> evised.png
> 

> I think another option would be to run the PTL election early, but just don't 
> have the turn over happen until the master release opens up. The current 
> transition period is > > > 
> actually quite short as noted by the comments around how design summit 
> planning happens. Having the PTL-next elected half way through the cycle, but 
> having PTL current > 
> still > own landing the current release actually provides a lot more 
> transition time.
>
>   -Sean

I had a similar thought to Sean's, with a few changes. Why not have a PTL own 
the release from start to finish, with the PTL for the next release getting 
elected as above. In this model, it would probably be advisable (or a 
guideline) that a PTL not run for 2 

Re: [openstack-dev] [third-party] [puppet] [infra] puppet-jenkins doesn't allow to pin version

[Asselin, Ramy]

Adding [infra]. 

Simon proposed a patch to make it work.
https://review.openstack.org/#/c/366803/1

-Original Message-
From: Evgeny Antyshev [mailto:eantys...@virtuozzo.com] 
Sent: Tuesday, September 06, 2016 2:22 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [third-party] [puppet] puppet-jenkins doesn't allow to 
pin version

Hello!

Last time I created Third-Party CI in new environment, I faced difficulties 
installing Jenkins by puppet-jenkins:

1) It really doesn't allow to pin Jenkins version, due to bug (or lack of 
functionality) in Jenkins infrastructure:
https://issues.jenkins-ci.org/browse/INFRA-92

Therefore, the change at https://review.openstack.org/354086 don't actually 
work.

There are 2 options to workaround this: install Jenkins package from *.deb by 
given link, which involves some possible issues with dependancies. Or to make 
it without Jenkins, using Zuul launcher in 3rd-party environment, has anybody 
tried that?

2) 3rd-party CI also needs https://review.openstack.org/334400 (to disable 
security policy preventing custom build parameters). But this solution won't be 
accepted, and there's no other yet.

Does anyone have opinion on this?

Thanks in advance!

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

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Sean Dague]

On 09/07/2016 11:43 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, the
> Summit will happen further away from the release day and more around the
> middle of the next development cycle. You can find more info on the
> rationale for that at [1] and [2] if interested, this is not the topic
> of this email.
> 
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and TC positions in the middle of the
> cycle. Crazy, right ? That's what I first thought. But after discussing
> it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in
> the middle of the design summit prep, with old PTLs making Design Summit
> space requests that will affect their successor. It's not as if there
> was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a
> few months before actual development starts, with discussions on next
> cycle priorities and Design Summit prep. They continue a few months
> after release, with critical stable branch backports and communication
> about landed features. So they are one year-long, overlapping cycles
> (like explained on the diagram at [4]). With that in mind, the PTL/TC
> election actually would happen just before the start of the start of the
> requirements-gathering pre-development phase of the next development
> cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a
> development cycle is that you don't want to introduce a discontinuity in
> leadership in that development cycle. To mitigate that, we propose the
> introduction of a new role, the "release steward", which would be
> attached to the release cycle. That person (who may or may not double as
> PTL) would be responsible for a complete release cycle on a given
> project team, from requirements gathering phase to post-release
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release
> stewards at all times. This would help with the awkward situation where
> the PTL ends up having to think about the next cycle and prepare the
> Design Summit (or PTG) while still being knee-deep juggling with feature
> freeze exceptions, getting the current release out of the door, and
> coordinating early critical fixes stable backports. Those two jobs could
> be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may want
> to use the same super-human to handle everything (PTL, release steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the
> newly-elected PTL, the release steward would be responsible for the full
> release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and
> keep the election period as currently defined in the charter (rather
> than having to change it). The PTLs we will elect in the coming weeks
> won't be renewed before April, 2017 -- while Pike development will start
> in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to me
> with questions on this.
> 
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-ptl-seats
> [4]
> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png
> 

I think another option would be to run the PTL election early, but just
don't have the turn over happen until the master release opens up. The
current transition period is actually quite short as noted by the
comments around how design summit planning happens. Having the PTL-next
elected half way through the cycle, but having PTL current still own
landing the current release actually provides a lot more transition time.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Davanum Srinivas]

Doug, Thierry,

Do we want the stewards to serve as the CPL for Release team as well?

-- Dims

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

On Wed, Sep 7, 2016 at 11:57 AM, Doug Hellmann  wrote:
> Excerpts from Thierry Carrez's message of 2016-09-07 17:43:59 +0200:
>> Hi everyone,
>>
>> As you probably know by now, starting with the Boston event in 2017, the
>> Summit will happen further away from the release day and more around the
>> middle of the next development cycle. You can find more info on the
>> rationale for that at [1] and [2] if interested, this is not the topic
>> of this email.
>>
>> One interesting side-effect is that since the timing of the election
>> period (for PTL and TC positions) is defined in the TC charter[3]
>> relative to the *Summit*, it means that (unless we change this) we'll
>> now run elections to renew PTL and TC positions in the middle of the
>> cycle. Crazy, right ? That's what I first thought. But after discussing
>> it with various people, this is not as crazy as it sounds.
>>
>> First, the current election timing is not perfect -- we change PTLs in
>> the middle of the design summit prep, with old PTLs making Design Summit
>> space requests that will affect their successor. It's not as if there
>> was a perfect timing for doing elections.
>>
>> Second, release cycles are longer than 6 months. They actually start a
>> few months before actual development starts, with discussions on next
>> cycle priorities and Design Summit prep. They continue a few months
>> after release, with critical stable branch backports and communication
>> about landed features. So they are one year-long, overlapping cycles
>> (like explained on the diagram at [4]). With that in mind, the PTL/TC
>> election actually would happen just before the start of the start of the
>> requirements-gathering pre-development phase of the next development
>> cycle, which makes a lot of sense.
>>
>> Now, the main drawback of holding elections in the middle of a
>> development cycle is that you don't want to introduce a discontinuity in
>> leadership in that development cycle. To mitigate that, we propose the
>> introduction of a new role, the "release steward", which would be
>> attached to the release cycle. That person (who may or may not double as
>> PTL) would be responsible for a complete release cycle on a given
>> project team, from requirements gathering phase to post-release
>> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
>>
>> Since development cycles overlap, there would be two active release
>> stewards at all times. This would help with the awkward situation where
>> the PTL ends up having to think about the next cycle and prepare the
>> Design Summit (or PTG) while still being knee-deep juggling with feature
>> freeze exceptions, getting the current release out of the door, and
>> coordinating early critical fixes stable backports. Those two jobs could
>> be held by two different people.
>>
>> Now, some teams (especially those doing intermediary releases) may want
>> to use the same super-human to handle everything (PTL, release steward,
>> release+1 steward), and some others might use two or three humans to
>> spread the load. That's up to them. But once designated by the
>> newly-elected PTL, the release steward would be responsible for the full
>> release cycle and would not be displaced by the next PTL 6 months later.
>> One year being a long time, if a steward needs to step down, the
>> currently-active PTL would appoint someone else to finish the job.
>>
>> With this new concept I think we can get the best of both worlds, and
>> keep the election period as currently defined in the charter (rather
>> than having to change it). The PTLs we will elect in the coming weeks
>> won't be renewed before April, 2017 -- while Pike development will start
>> in February.
>>
>> I know this can all be a bit confusing, so feel free to reach out to me
>> with questions on this.
>>
>> [1] http://www.openstack.org/ptg
>> [2] http://www.openstack.org/ptg/ptgfaq/
>> [3]
>> http://governance.openstack.org/reference/charter.html#election-for-ptl-seats
>> [4]
>> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png
>>
>
> Thanks for writing this up, Thierry. It sounds similar to what I
> know a few companies are already doing internally.  It should help
> with continuity upstream, too, since the steward will work on a
> given release through its whole life-cycle, rather than handing off
> each time a new release cycle starts.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Monty Taylor]

On 09/07/2016 10:43 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, the
> Summit will happen further away from the release day and more around the
> middle of the next development cycle. You can find more info on the
> rationale for that at [1] and [2] if interested, this is not the topic
> of this email.
> 
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and TC positions in the middle of the
> cycle. Crazy, right ? That's what I first thought. But after discussing
> it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in
> the middle of the design summit prep, with old PTLs making Design Summit
> space requests that will affect their successor. It's not as if there
> was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a
> few months before actual development starts, with discussions on next
> cycle priorities and Design Summit prep. They continue a few months
> after release, with critical stable branch backports and communication
> about landed features. So they are one year-long, overlapping cycles
> (like explained on the diagram at [4]). With that in mind, the PTL/TC
> election actually would happen just before the start of the start of the
> requirements-gathering pre-development phase of the next development
> cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a
> development cycle is that you don't want to introduce a discontinuity in
> leadership in that development cycle. To mitigate that, we propose the
> introduction of a new role, the "release steward", which would be
> attached to the release cycle. That person (who may or may not double as
> PTL) would be responsible for a complete release cycle on a given
> project team, from requirements gathering phase to post-release
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release
> stewards at all times. This would help with the awkward situation where
> the PTL ends up having to think about the next cycle and prepare the
> Design Summit (or PTG) while still being knee-deep juggling with feature
> freeze exceptions, getting the current release out of the door, and
> coordinating early critical fixes stable backports. Those two jobs could
> be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may want
> to use the same super-human to handle everything (PTL, release steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the
> newly-elected PTL, the release steward would be responsible for the full
> release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and
> keep the election period as currently defined in the charter (rather
> than having to change it). The PTLs we will elect in the coming weeks
> won't be renewed before April, 2017 -- while Pike development will start
> in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to me
> with questions on this.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.


__
OpenStack Development Mailing List (not for 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] Timeframe for future elections & "Release stewards"

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-09-07 17:43:59 +0200:
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, the
> Summit will happen further away from the release day and more around the
> middle of the next development cycle. You can find more info on the
> rationale for that at [1] and [2] if interested, this is not the topic
> of this email.
> 
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and TC positions in the middle of the
> cycle. Crazy, right ? That's what I first thought. But after discussing
> it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in
> the middle of the design summit prep, with old PTLs making Design Summit
> space requests that will affect their successor. It's not as if there
> was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a
> few months before actual development starts, with discussions on next
> cycle priorities and Design Summit prep. They continue a few months
> after release, with critical stable branch backports and communication
> about landed features. So they are one year-long, overlapping cycles
> (like explained on the diagram at [4]). With that in mind, the PTL/TC
> election actually would happen just before the start of the start of the
> requirements-gathering pre-development phase of the next development
> cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a
> development cycle is that you don't want to introduce a discontinuity in
> leadership in that development cycle. To mitigate that, we propose the
> introduction of a new role, the "release steward", which would be
> attached to the release cycle. That person (who may or may not double as
> PTL) would be responsible for a complete release cycle on a given
> project team, from requirements gathering phase to post-release
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release
> stewards at all times. This would help with the awkward situation where
> the PTL ends up having to think about the next cycle and prepare the
> Design Summit (or PTG) while still being knee-deep juggling with feature
> freeze exceptions, getting the current release out of the door, and
> coordinating early critical fixes stable backports. Those two jobs could
> be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may want
> to use the same super-human to handle everything (PTL, release steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the
> newly-elected PTL, the release steward would be responsible for the full
> release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and
> keep the election period as currently defined in the charter (rather
> than having to change it). The PTLs we will elect in the coming weeks
> won't be renewed before April, 2017 -- while Pike development will start
> in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to me
> with questions on this.
> 
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-ptl-seats
> [4]
> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png
> 

Thanks for writing this up, Thierry. It sounds similar to what I
know a few companies are already doing internally.  It should help
with continuity upstream, too, since the steward will work on a
given release through its whole life-cycle, rather than handing off
each time a new release cycle starts.

Doug

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Monty Taylor]

On 09/07/2016 03:31 AM, Martin Millnert wrote:
> Hi Matt,
> 
> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote:
>> Floating IPs aren't required in OpenStack deployments, and anyone 
>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use
>> or 
>> support them, at least without patching Nova. So I'm not sure what 
>> 'industry standard' is being referred to here.
> 
> Nod. There are many models, I acknowledge that as well. When referring
> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non-
> legacy network behaviour. I didn't mean to imply that this model is the
> only one, not even the best one, just the most widely used one at
> large.

It's a terrible networking choice. NAT is a terrible model for doing
networking on the Internet. One of the things I'm most proud of about
OpenStack is that we allow people to make clouds that are not inherently
broken like AWS and GCE are.

THAT SAID 

"I would like to boot a VM that has a public IP"

is a very clear use case, and it's very hard to achieve across OpenStack
clouds. If you want to gouge your eyes out, go read the giant pile of
code in the shade library which implements this.

So - yes please on the feature - although it should be called
"--auto-assign-public-ip" or "--auto-assign-external-ip" or something,
not floating - because part of the problem is actually knowing whether
or not the cloud requires floating ips or doesn't.

However, as I mentioned, it's a GIANT amount of code to get this
'right'. We've gone thought a ton of iterations on it over the last 2
years - I recommend strongly not starting from scratch.

>>>   Problem:
>>>  - nova: we're not adding anything
>>
>> Correct, nova provides the APIs to do this already, something sitting
>> on top just needs to use them to orchestrate your use case.
> 
> It exists in terms of multiple calls, yes. My e-mail is about what the
> best multi-project solution to improving the total logic required to
> achieve the goal, within OpenStack. It's not clear the answer is to
> improve Nova's server create API, but it is one very obvious candidate
> solution.

It would be the nicest thing, but it would also require nova to learn a
lot more about neutron than it currently needs to know.

>> The get-me-a-network work is complete with the 2.37 API microversion
>> in Nova and the 6.0.0 python-novaclient release. You can test it out
>> today. 
>> However, it does not allocate and auto-assign a floating IP.
> 
> I'd argue that what a typical user is most interested in is not, in
> fact, in "having a network", but, "having internet access".

Yes, this is correct.

> Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one
> of them, as you point out, deals with auto-allocating-and-assigning
> FIPs, which is fine in and of itself - Rome wasn't built in one day
> either.
> 
> I.e. today,
>  A) 'networks=auto' != "get me online",
>  B) 'networks=auto' == "get me an openstack network interface".
> 
> B is a subset of A, but A is not a subset of B.
> 
> Assuming,
>  1) 'networks' is definitely meant to mean just what it's called, and does 
> today, and
>  2) "get me online" is a desirable feature,
> 
> then it is actually the case that we're missing an option like 
> "public_ip=auto" or similar to complete the picture.
> In the deployments you mention above, it'd have virtually nothing to do. In 
> others, for example FIP, it'd have only little to do.
> 
> Then, the combination networks=auto, public_ip(v4)=auto would equal 
> "getmeonline".

Yes. This is, in fact, how the shade create_server API works.

>>> So how can one solve an OpenStack cross-project problem like
> this,
>>> possibly without having to implement an artificial
>>> superintelligence
>>> first?
>>
>> Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or 
>> maybe even Heat would support this.
> 
> Right, the total amount of options are thus:
> 1) Introduce a new, custom API service to proxy for Nova, and fork
> Horizon to handle it,
> 2) Patch Nova and do UI fixes in Horizon, but do not submit it
> upstream,
> 3) Patch Nova and do UI fixes in Horizon, and submit it upstream,
> 4) Make Horizon stateful and do UI changes, but do not submit it
> upstream,
> 5) Make Horizon stateful and do UI changes, and submit it upstream
> 
> I'm sure there are more enumerations of this, but Heat is not one of
> them. :-)
> 
> To me, from the above, option 3 seems the one that involves the least
> amount of complexity, which already there is a good indication of being
> the right choice.

I think the complexity in 3 should not be understated... but please
don't fork and not submit upstream... :)

Monty

__
OpenStack Development Mailing List (not for 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] Next steps for resource providers work

[Sean Dague]

On 09/07/2016 06:46 AM, Chris Dent wrote:
> 
> More updates on resource providers work:
> 
> Yesterday we realized that a SQL join for associating inventories
> with allocations and resource providers was missing a critical and
> clause. This was leading to allocations failing to be written when
> there should have been plenty of capacity.
> 
> This was fixed in:
> 
> https://review.openstack.org/#/c/366245/
> 
> It will merged in a few minutes. There are still some concerns that
> we don't understand why tests (of the prior code) were not failing.

As a follow up here, I actually got to the bottom of why the old tests
didn't work.

There were no tests which had > 1 resource class and > 1 consumer for a
resource provider. And even if there had been, they probably wouldn't
have failed unless the scales of the resource providers were enough that
comparing the free / used mixed up between them would have caused an issue.

To reproduce the key issue you need to have active allocations in the
database not owned by your consumer. Because one of the first things
that happens when setting allocations for your consumer, is it deletes
existing allocations.

If nothing is in the allocations table the left outer join has nothing
to add up to join for usage. Basically the column set:


cols_in_output = [
_RP_TBL.c.id.label('resource_provider_id'),
_RP_TBL.c.uuid,
_RP_TBL.c.generation,
_INV_TBL.c.resource_class_id,
_INV_TBL.c.total,
_INV_TBL.c.reserved,
_INV_TBL.c.allocation_ratio,
usage.c.used,
]

Ends up with None in the final column. So you'll get rows like.

1,$uuid,1,2,1024,4,16.0,None
1,$uuid,1,9,40,4,1.0,None

However, if there are existing allocations there, the left outer join
blows this out into a matrix and you'd get:

1,$uuid,1,2,1024,4,16.0,16
1,$uuid,1,9,40,4,1.0,16
1,$uuid,1,2,1024,4,16.0,1
1,$uuid,1,9,40,4,1.0,1

Where 1 is the usage by resource provider 9, and 16 is the usage by
resource provider 2. This is because of a missing join where the
inventory.resource_class_id == allocs.resource_class_id.

The fix provides a test that will explode if we regress this.

Because this only would expose when we've got existing allocations by a
different consumer (i.e. a concurrently running guest), this explains
why it was spuraticly showing up in the gate. Only when 3 guests were
stood up at the same time (either in a test, or between) would we get
this issue. Our guests run at 64M memory, we run on 8 cpu hosts, with
16x modifier.

If we compare consumed ram to available cpu (which was the actual fail
happening) the first guest up consumes 64M ram, 1 vcpu. 128 vcpu can be
consumed, 128 - 64 >= 0. Second guest gets us to 128M ram, 2 vcpu.
Again, we can actually survive the column shift. But once we are >= 3
guests at once we can hit this. There are no ORDER by clauses inside the
SQL monster
(https://github.com/openstack/nova/blob/25abb68039ca122b4b3796a9f8c9e3495db22772/nova/objects/resource_provider.py#L637)
which means which order we'll get the rows and the join means sometimes
we'll be correctly comparing, sometimes we won't. But until you get to 3
guests at once, then you'll never be able to see it.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Thierry Carrez]

Hi everyone,

As you probably know by now, starting with the Boston event in 2017, the
Summit will happen further away from the release day and more around the
middle of the next development cycle. You can find more info on the
rationale for that at [1] and [2] if interested, this is not the topic
of this email.

One interesting side-effect is that since the timing of the election
period (for PTL and TC positions) is defined in the TC charter[3]
relative to the *Summit*, it means that (unless we change this) we'll
now run elections to renew PTL and TC positions in the middle of the
cycle. Crazy, right ? That's what I first thought. But after discussing
it with various people, this is not as crazy as it sounds.

First, the current election timing is not perfect -- we change PTLs in
the middle of the design summit prep, with old PTLs making Design Summit
space requests that will affect their successor. It's not as if there
was a perfect timing for doing elections.

Second, release cycles are longer than 6 months. They actually start a
few months before actual development starts, with discussions on next
cycle priorities and Design Summit prep. They continue a few months
after release, with critical stable branch backports and communication
about landed features. So they are one year-long, overlapping cycles
(like explained on the diagram at [4]). With that in mind, the PTL/TC
election actually would happen just before the start of the start of the
requirements-gathering pre-development phase of the next development
cycle, which makes a lot of sense.

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

Since development cycles overlap, there would be two active release
stewards at all times. This would help with the awkward situation where
the PTL ends up having to think about the next cycle and prepare the
Design Summit (or PTG) while still being knee-deep juggling with feature
freeze exceptions, getting the current release out of the door, and
coordinating early critical fixes stable backports. Those two jobs could
be held by two different people.

Now, some teams (especially those doing intermediary releases) may want
to use the same super-human to handle everything (PTL, release steward,
release+1 steward), and some others might use two or three humans to
spread the load. That's up to them. But once designated by the
newly-elected PTL, the release steward would be responsible for the full
release cycle and would not be displaced by the next PTL 6 months later.
One year being a long time, if a steward needs to step down, the
currently-active PTL would appoint someone else to finish the job.

With this new concept I think we can get the best of both worlds, and
keep the election period as currently defined in the charter (rather
than having to change it). The PTLs we will elect in the coming weeks
won't be renewed before April, 2017 -- while Pike development will start
in February.

I know this can all be a bit confusing, so feel free to reach out to me
with questions on this.

[1] http://www.openstack.org/ptg
[2] http://www.openstack.org/ptg/ptgfaq/
[3]
http://governance.openstack.org/reference/charter.html#election-for-ptl-seats
[4]
http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png

-- 
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] [ironic] Future of cleaning when in maintenance mode

[Dmitry Tantsur]

Hi all!

Today while playing with my installation I noticed that we do try to run 
cleaning for nodes in maintenance mode. This leads to a somewhat 
confusing result, because we no-op heartbeats for such nodes. So 
cleaning gets stuck in "clean wait" forever [1].


However, it seems like some folks find it a convenient feature. This way 
they can ask Ironic to boot the ramdisk and make it wait for operator's 
commands. It's a fair use case, but I still find the current situation 
confusing.


We've ended up with these few options:

1. Ensure we don't run cleaning for nodes in maintenance mode. I've 
proposed a patch [2] banning most of provision verbs from working in 
maintenance. However, we still want to allow deleting an instance, which 
still results in cleaning.


2. On receiving a heartbeat in {CLEAN,DEPLOY}WAIT and maintenance on 
[3], move the node to {CLEAN,DEPLOY}FAIL (optionally without powering it 
off, so that IPA stays running).


3. Document this as a desired feature and don't change anything.

What do you think?

[1] https://bugs.launchpad.net/ironic/+bug/1621006
[2] https://review.openstack.org/#/c/366793/
[3] 
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent_base_vendor.py#L474-L478.


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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Dean Troyer]

On Wed, Sep 7, 2016 at 9:48 AM, Steve Martinelli 
wrote:

> There's been a bug filed against OSC to implement ospurge for cleaning up
> resources in (compute, network, storage, image and identity) [1] for a
> while now. As Jordan said, this is something we want to be modular, and
> pluggable, so other OSC plugins could extend this clean up command.
>

The hurdle here for OSC is making a way for plugins to extend existing
commands, in a way that doesn't lend itself to untrusted code slipping in
and subverting things.  Right now we blindly trust entry points to Do The
Right Thing for new commands, modifying existing commands I think requires
a higher bar for trust.

Building a purge for the APIs handled in the OSC repo is straightforward,
it'll look a lot like the quota commands for example.  Extending that to
plugins is not quite so simple.

I created the OSC session Etherpad[0] to start tracking these topic
suggestions.

dt

[0]https://etherpad.openstack.org/p/osc-otaka-summit
__
OpenStack Development Mailing List (not for 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] proposing adding Tony Breeds to "Release Managers" team

[Sean McGinnis]

On Tue, Sep 06, 2016 at 07:37:55PM -0400, Emilien Macchi wrote:
> My vote doesn't count but I still have feedback to share.
> 
> As a PTL I have to release multiple projects and Tony was always very
> helpful and responsive in the reviews.
> I would be super happy to have him part of release managers team.
> 

+1 - same from me.

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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Steve Martinelli]

There's been a bug filed against OSC to implement ospurge for cleaning up
resources in (compute, network, storage, image and identity) [1] for a
while now. As Jordan said, this is something we want to be modular, and
pluggable, so other OSC plugins could extend this clean up command.

[1] https://bugs.launchpad.net/python-openstackclient/+bug/1584596

On Wed, Sep 7, 2016 at 10:42 AM, Jordan Pittier 
wrote:

>
> On Wed, Sep 7, 2016 at 4:18 PM, Boris Bobrov  wrote:
>
>> Hello,
>>
>> I wonder if it would be worth integrating ospurge into openstackclient.
>>
>> Are there any osc sessions planned at the summit?
>>
>>
>> Hi,
> I am the current "PTL" of the openstack/ospurge project. The project is
> still alive and we have some small contributions from time to time, which
> proves that there's definitively a need for a project purger tool.
>
> It would be great if there were an official/widely used tool to do that,
> maybe OSC is the best place. One advice to who ever wants to have another
> stab at it: make the thing modular from the start. (in ospurge we now have
> a fat file of 900LoC that's hard to maintain and I regularly have to "say
> no" to people trying to extend it to clean resources of the new a-la-mode
> openstack service).
>
>
>> On 09/07/2016 04:05 PM, John Davidge wrote:
>>
>>> Hello,
>>>
>>> During the Mitaka cycle we merged a new feature into the
>>> python-neutronclient called ’neutron purge’. This enables a simple CLI
>>> command that deletes all of the neutron resources owned by a given
>>> tenant. It’s documented in the networking guide[1].
>>>
>>> We did this in response to feedback from operators that they needed a
>>> better way to remove orphaned resources after a tenant had been deleted.
>>> So far this feature has been well received, and we already have a couple
>>> of enhancement requests. Given that we’re moving to OSC I’m hesitant to
>>> continue iterating on this in the neutron client, and so I’m reaching
>>> out to propose that we look into making this a part of OSC.
>>>
>>> Earlier this week I was about to file a BP, when I noticed one covering
>>> this subject was already filed last month[2]. I’ve spoken to Roman, who
>>> says that they’ve been thinking about implementing this in nova, and
>>> have come to the same conclusion that it would fit better in OSC.
>>>
>>> I would propose that we work together to establish how this command will
>>> behave in OSC, and build a framework that implements the cleanup of a
>>> small set of core resources. This should be achievable during the Ocata
>>> cycle. After that, we can reach out to the wider community to encourage
>>> a cross-project effort to incrementally support more projects/resources
>>> over time.
>>>
>>> If you already have an etherpad for planning summit sessions then please
>>> let me know, I’d love to get involved.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> [1] http://docs.openstack.org/mitaka/networking-guide/ops-resour
>>> ce-purge.html
>>> [2] https://blueprints.launchpad.net/python-openstackclient/+spe
>>> c/tenant-data-scrub
>>>
>>> 
>>> Rackspace Limited is a company registered in England & Wales (company
>>> registered number 03897010) whose registered office is at 5 Millington
>>> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
>>> policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This
>>> e-mail message may contain confidential or privileged information
>>> intended for the recipient. Any dissemination, distribution or copying
>>> of the enclosed material is prohibited. If you receive this transmission
>>> in error, please notify us immediately by e-mail at ab...@rackspace.com
>>> and delete the original message. Your cooperation is appreciated.
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Jordan Pittier]

On Wed, Sep 7, 2016 at 4:18 PM, Boris Bobrov  wrote:

> Hello,
>
> I wonder if it would be worth integrating ospurge into openstackclient.
>
> Are there any osc sessions planned at the summit?
>
>
> Hi,
I am the current "PTL" of the openstack/ospurge project. The project is
still alive and we have some small contributions from time to time, which
proves that there's definitively a need for a project purger tool.

It would be great if there were an official/widely used tool to do that,
maybe OSC is the best place. One advice to who ever wants to have another
stab at it: make the thing modular from the start. (in ospurge we now have
a fat file of 900LoC that's hard to maintain and I regularly have to "say
no" to people trying to extend it to clean resources of the new a-la-mode
openstack service).


> On 09/07/2016 04:05 PM, John Davidge wrote:
>
>> Hello,
>>
>> During the Mitaka cycle we merged a new feature into the
>> python-neutronclient called ’neutron purge’. This enables a simple CLI
>> command that deletes all of the neutron resources owned by a given
>> tenant. It’s documented in the networking guide[1].
>>
>> We did this in response to feedback from operators that they needed a
>> better way to remove orphaned resources after a tenant had been deleted.
>> So far this feature has been well received, and we already have a couple
>> of enhancement requests. Given that we’re moving to OSC I’m hesitant to
>> continue iterating on this in the neutron client, and so I’m reaching
>> out to propose that we look into making this a part of OSC.
>>
>> Earlier this week I was about to file a BP, when I noticed one covering
>> this subject was already filed last month[2]. I’ve spoken to Roman, who
>> says that they’ve been thinking about implementing this in nova, and
>> have come to the same conclusion that it would fit better in OSC.
>>
>> I would propose that we work together to establish how this command will
>> behave in OSC, and build a framework that implements the cleanup of a
>> small set of core resources. This should be achievable during the Ocata
>> cycle. After that, we can reach out to the wider community to encourage
>> a cross-project effort to incrementally support more projects/resources
>> over time.
>>
>> If you already have an etherpad for planning summit sessions then please
>> let me know, I’d love to get involved.
>>
>> Thanks,
>>
>> John
>>
>> [1] http://docs.openstack.org/mitaka/networking-guide/ops-resour
>> ce-purge.html
>> [2] https://blueprints.launchpad.net/python-openstackclient/+spe
>> c/tenant-data-scrub
>>
>> 
>> Rackspace Limited is a company registered in England & Wales (company
>> registered number 03897010) whose registered office is at 5 Millington
>> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
>> policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This
>> e-mail message may contain confidential or privileged information
>> intended for the recipient. Any dissemination, distribution or copying
>> of the enclosed material is prohibited. If you receive this transmission
>> in error, please notify us immediately by e-mail at ab...@rackspace.com
>> and delete the original message. Your cooperation is appreciated.
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Andrew Laski]

On Wed, Sep 7, 2016, at 04:31 AM, Martin Millnert wrote:
> Hi Matt,
> 
> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote:
> > Floating IPs aren't required in OpenStack deployments, and anyone 
> > running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use
> > or 
> > support them, at least without patching Nova. So I'm not sure what 
> > 'industry standard' is being referred to here.
> 
> Nod. There are many models, I acknowledge that as well. When referring
> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non-
> legacy network behaviour. I didn't mean to imply that this model is the
> only one, not even the best one, just the most widely used one at
> large.
> 
> > >   Problem:
> > >  - nova: we're not adding anything
> > 
> > Correct, nova provides the APIs to do this already, something sitting
> > on top just needs to use them to orchestrate your use case.
> 
> It exists in terms of multiple calls, yes. My e-mail is about what the
> best multi-project solution to improving the total logic required to
> achieve the goal, within OpenStack. It's not clear the answer is to
> improve Nova's server create API, but it is one very obvious candidate
> solution.
> 
> > The get-me-a-network work is complete with the 2.37 API microversion
> > in Nova and the 6.0.0 python-novaclient release. You can test it out
> > today. 
> > However, it does not allocate and auto-assign a floating IP.
> 
> I'd argue that what a typical user is most interested in is not, in
> fact, in "having a network", but, "having internet access".
> 
> Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one
> of them, as you point out, deals with auto-allocating-and-assigning
> FIPs, which is fine in and of itself - Rome wasn't built in one day
> either.
> 
> I.e. today,
>  A) 'networks=auto' != "get me online",
>  B) 'networks=auto' == "get me an openstack network interface".
> 
> B is a subset of A, but A is not a subset of B.
> 
> Assuming,
>  1) 'networks' is definitely meant to mean just what it's called, and does 
> today, and
>  2) "get me online" is a desirable feature,
> 
> then it is actually the case that we're missing an option like
> "public_ip=auto" or similar to complete the picture.
> In the deployments you mention above, it'd have virtually nothing to do.
> In others, for example FIP, it'd have only little to do.
> 
> Then, the combination networks=auto, public_ip(v4)=auto would equal
> "getmeonline".
> 
> > > So how can one solve an OpenStack cross-project problem like
> this,
> > > possibly without having to implement an artificial
> > > superintelligence
> > > first?
> > 
> > Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or 
> > maybe even Heat would support this.
> 
> Right, the total amount of options are thus:
> 1) Introduce a new, custom API service to proxy for Nova, and fork
> Horizon to handle it,

I would change this slightly and say that my preference would be to have
a new API service which can handle cross project orchestration needs.
Things like what you're discussing, or creating a volume and booting
from it, and many other things that require a client to touch multiple
services. I believe there's a gap here that Heat doesn't fill and that
encourages people to think that adding orchestration to Nova is the
right thing to do.

> 2) Patch Nova and do UI fixes in Horizon, but do not submit it
> upstream,
> 3) Patch Nova and do UI fixes in Horizon, and submit it upstream,
> 4) Make Horizon stateful and do UI changes, but do not submit it
> upstream,
> 5) Make Horizon stateful and do UI changes, and submit it upstream
> 
> I'm sure there are more enumerations of this, but Heat is not one of
> them. :-)
> 
> To me, from the above, option 3 seems the one that involves the least
> amount of complexity, which already there is a good indication of being
> the right choice.
> 
> Best regards,
> Martin
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] Add support for tag instances when booting

[Andrew Laski]

On Wed, Sep 7, 2016, at 05:15 AM, Zhenyu Zheng wrote:
> Hi All,
>
> Tags for servers are supported in microversion 2.26, but currently we
> can only add tags to
> instances that are already existed in the cloud, that is, we can not
> set tags to instances
> when we boot the instances. User will have to first find the instances
> and then add tags
> with another API call. This is not user-friendly enough when user
> doing bulk boot, it will be
> not practical to add tags for those instances one by one afterwards.
>
> So, I think it will be good to add support for tag instances when
> booting them, I have registered
> a BP for O:
> https://blueprints.launchpad.net/nova/+spec/support-tag-instance-when-boot
> https://review.openstack.org/#/c/366469/
>
> Comments?

I haven't looked at the spec, and probably won't until at least RC1 is
done, but I think this is a good idea. A few cores noticed that this was
missing a little bit ago and already agreed that it would be a good
addition in O.

>
> Thanks,
>
> Zhenyu Zheng
> -
> 
> OpenStack Development Mailing 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] [TripleO] Mistral transition status for RC1

[Dougal Matthews]

Hey,

This is just a quick update on the Mistral API transition. We are now at a
point where all the major CLI commands (node registration, introspection
and deployment) are being powered by mistral workflows.

We have an etherpad that is tracking all the reviews in quite a bit of
detail:
https://etherpad.openstack.org/p/tripleo-mistral-api

I'd like to call out a few specific bugs that are important (and maybe
should be considered blockers):


- Remove the existing plan before deploying with `openstack overcloud
deploy`

This one is a blocker as it is a regression. For backwards compatibility,
this command can't care about existing plans and they shouldn't change it's
behavior - otherwise in theory deploying twice in a row could have a
different outcome than it would previously, before plans were stored.

https://launchpad.net/bugs/1620932


- Remaining CLI logic

Some parameters are still set by the CLI, these wont be available to the
GUI and it will need to replicate the process.

https://launchpad.net/bugs/1621097
https://launchpad.net/bugs/1621099


- Plan CLI commands

Without these two commands it wont be possible to work with plans
https://launchpad.net/bugs/1616351
https://launchpad.net/bugs/1616015


I think that is everything, I am going to ping rbrady, jpeeler and dprince
to see if they have anything to add that I might have missed.

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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Boris Bobrov]

Hello,

I wonder if it would be worth integrating ospurge into openstackclient.

Are there any osc sessions planned at the summit?

On 09/07/2016 04:05 PM, John Davidge wrote:

Hello,

During the Mitaka cycle we merged a new feature into the
python-neutronclient called ’neutron purge’. This enables a simple CLI
command that deletes all of the neutron resources owned by a given
tenant. It’s documented in the networking guide[1].

We did this in response to feedback from operators that they needed a
better way to remove orphaned resources after a tenant had been deleted.
So far this feature has been well received, and we already have a couple
of enhancement requests. Given that we’re moving to OSC I’m hesitant to
continue iterating on this in the neutron client, and so I’m reaching
out to propose that we look into making this a part of OSC.

Earlier this week I was about to file a BP, when I noticed one covering
this subject was already filed last month[2]. I’ve spoken to Roman, who
says that they’ve been thinking about implementing this in nova, and
have come to the same conclusion that it would fit better in OSC.

I would propose that we work together to establish how this command will
behave in OSC, and build a framework that implements the cleanup of a
small set of core resources. This should be achievable during the Ocata
cycle. After that, we can reach out to the wider community to encourage
a cross-project effort to incrementally support more projects/resources
over time.

If you already have an etherpad for planning summit sessions then please
let me know, I’d love to get involved.

Thanks,

John

[1] http://docs.openstack.org/mitaka/networking-guide/ops-resource-purge.html
[2] 
https://blueprints.launchpad.net/python-openstackclient/+spec/tenant-data-scrub


Rackspace Limited is a company registered in England & Wales (company
registered number 03897010) whose registered office is at 5 Millington
Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This
e-mail message may contain confidential or privileged information
intended for the recipient. Any dissemination, distribution or copying
of the enclosed material is prohibited. If you receive this transmission
in error, please notify us immediately by e-mail at ab...@rackspace.com
and delete the original message. Your cooperation is appreciated.


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



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

Re: [openstack-dev] [requirements][FFE] global-requirements update to positional to 1.1.1

[James Page]

On Wed, 7 Sep 2016 at 14:30 Ian Cordasco  wrote:
[...]

> https://review.openstack.org/366631
> >
> > The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> > current minimum requirement) results in various unit test failures in
> > barbican, related to parsing of request headers in generated contexts
> > for unit testing. Updating to 1.1.1 resolves this issue.
>
> So I take it someone has verified that the request headers used in the
> faked(?) contexts in these tests will never be seen in the real world
> then? I looked at the tests that James linked in the barbican channel
> when they were looking for help debugging this and those looked like
> *functional* tests, not unit tests. That doesn't give me any
> confidence that this is *just* a testing issue.
>
> > This is specifically affecting barbican and RDO testing (from discussion
> > and the review).
>
> I believe this is also affecting Ubuntu's backing of Newton-3, but
> James can correct me if I'm wrong.
>

We're unblocked by upgrading to positional 1.1.1 (the CI build failure was
detected a week or so ago, but with b3 also arriving and it not being
entirely obvious what the problem was its taken a while to figure out);
I've enforced this as a versioned package dependency for oslo.context, so
upgrades from mitaka will get the right version as well.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

On 09/07/2016 08:58 AM, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
>> https://review.openstack.org/366298
>>
>> This is just a bump to upper-constraints so is more minor to get testing
>> working and fix the bug that occurred in Gnocchi (and possibly others).
>>
>> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
>> 0.7.7 after the freeze (and backport them to stable/newton) so this is
>> easier to merge.
>>
> 
> If we have a known-bad version of the library, maybe it would be better
> to incorporate that info into the global-requirements list before we
> branch the requirements repository? I'm not sure what we've done in
> this case for past cycles.
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Are you fine with the knock on effects that a gr update would cause?

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Tim Bell]

On 07 Sep 2016, at 15:05, John Davidge 
> wrote:

Hello,

During the Mitaka cycle we merged a new feature into the python-neutronclient 
called ’neutron purge’. This enables a simple CLI command that deletes all of 
the neutron resources owned by a given tenant. It’s documented in the 
networking guide[1].

We did this in response to feedback from operators that they needed a better 
way to remove orphaned resources after a tenant had been deleted. So far this 
feature has been well received, and we already have a couple of enhancement 
requests. Given that we’re moving to OSC I’m hesitant to continue iterating on 
this in the neutron client, and so I’m reaching out to propose that we look 
into making this a part of OSC.

Earlier this week I was about to file a BP, when I noticed one covering this 
subject was already filed last month[2]. I’ve spoken to Roman, who says that 
they’ve been thinking about implementing this in nova, and have come to the 
same conclusion that it would fit better in OSC.


This would be really great. From experience of using the existing purge 
commands (such as for deleted volumes), would it be possible to add a dry run 
option where it would list the deletions that it would do but not do them. This 
would allow the operator to check what is due to be cleaned up.

One other area where there have sometimes been problems is when lots of items 
need to be deleted. Some purge commands add a max resources or similar so that 
you can do it in smaller steps and avoid a timeout.

Tim


I would propose that we work together to establish how this command will behave 
in OSC, and build a framework that implements the cleanup of a small set of 
core resources. This should be achievable during the Ocata cycle. After that, 
we can reach out to the wider community to encourage a cross-project effort to 
incrementally support more projects/resources over time.

If you already have an etherpad for planning summit sessions then please let me 
know, I’d love to get involved.

Thanks,

John

[1] http://docs.openstack.org/mitaka/networking-guide/ops-resource-purge.html
[2] 
https://blueprints.launchpad.net/python-openstackclient/+spec/tenant-data-scrub


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

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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Tim Bell]

On 07 Sep 2016, at 15:05, John Davidge 
> wrote:

Hello,

During the Mitaka cycle we merged a new feature into the python-neutronclient 
called ’neutron purge’. This enables a simple CLI command that deletes all of 
the neutron resources owned by a given tenant. It’s documented in the 
networking guide[1].

We did this in response to feedback from operators that they needed a better 
way to remove orphaned resources after a tenant had been deleted. So far this 
feature has been well received, and we already have a couple of enhancement 
requests. Given that we’re moving to OSC I’m hesitant to continue iterating on 
this in the neutron client, and so I’m reaching out to propose that we look 
into making this a part of OSC.

Earlier this week I was about to file a BP, when I noticed one covering this 
subject was already filed last month[2]. I’ve spoken to Roman, who says that 
they’ve been thinking about implementing this in nova, and have come to the 
same conclusion that it would fit better in OSC.


This would be really great. From experience of using the existing purge 
commands (such as for deleted volumes), would it be possible to add a dry run 
option where it would list the deletions that it would do but not do them. This 
would allow the operator to check what is due to be cleaned up.

One other area where there have sometimes been problems is when lots of items 
need to be deleted. Some purge commands add a max resources or similar so that 
you can do it in smaller steps and avoid a timeout.

Tim


I would propose that we work together to establish how this command will behave 
in OSC, and build a framework that implements the cleanup of a small set of 
core resources. This should be achievable during the Ocata cycle. After that, 
we can reach out to the wider community to encourage a cross-project effort to 
incrementally support more projects/resources over time.

If you already have an etherpad for planning summit sessions then please let me 
know, I’d love to get involved.

Thanks,

John

[1] http://docs.openstack.org/mitaka/networking-guide/ops-resource-purge.html
[2] 
https://blueprints.launchpad.net/python-openstackclient/+spec/tenant-data-scrub


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

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

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
> https://review.openstack.org/366298
> 
> This is just a bump to upper-constraints so is more minor to get testing
> working and fix the bug that occurred in Gnocchi (and possibly others).
> 
> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
> 0.7.7 after the freeze (and backport them to stable/newton) so this is
> easier to merge.
> 

If we have a known-bad version of the library, maybe it would be better
to incorporate that info into the global-requirements list before we
branch the requirements repository? I'm not sure what we've done in
this case for past cycles.

Doug

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

Re: [openstack-dev] [oslo.context][requirements][ffe] newton - positional 1.1.1 minimum requirement

[Ian Cordasco]

Hey James!

There's already a discussion about this with the [requirements] and
[ffe] tags by Matthew Thode. Could we centralize the discussion on
that thread please?

Thanks,
Ian

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

Date: September 7, 2016 at 08:46:24
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [oslo.context][requirements][ffe] newton -
positional 1.1.1 minimum requirement

> Hi
>
> Whilst fixing CI test failures/preparing b3 uploads for OpenStack Newton
> for Ubuntu, we tripped over [0], symptomatically in Barbican's unit test
> suite starting to throw failures when oslo.context was updated to the
> latest newton version.
>
> Global requirement currently details 1.0.1 of positional as the minimum
> requirement, but 1.1.1 is required to ensure correct parsing of role
> headers via oslo.context - basically the roles where being dropped from the
> credentials context, resulting in policy enforcement failures.
>
> I've raised a review on requirements to increase the minimum requirement;
> as we're in freeze, this will need an exception to be granted.
>
> Cheers
>
> James
>
> [0] https://bugs.launchpad.net/oslo.context/+bug/1620963
> [1] https://review.openstack.org/#/c/366631/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

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

Re: [openstack-dev] [oslo.context][requirements][ffe] newton - positional 1.1.1 minimum requirement

[James Page]

On Wed, 7 Sep 2016 at 14:51 Ian Cordasco  wrote:

> Hey James!
>
> There's already a discussion about this with the [requirements] and
> [ffe] tags by Matthew Thode. Could we centralize the discussion on
> that thread please?
>

Of course - missed that whilst eating lunch!
__
OpenStack Development Mailing 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] [Ironic] QA Meeting cancelled today

[Villalovos, John L]

To focus on the Newton work. The Ironic QA meeting is cancelled for today.

Thanks,
John

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

Re: [openstack-dev] [cinder] moving driver to open source

[John Griffith]

On Tue, Sep 6, 2016 at 9:27 AM, Alon Marx  wrote:

> I want to share our plans to open the IBM Storage driver source code.
> Historically we started our way in cinder way back (in Essex if I'm not
> mistaken)

​You're mistaken, Cinder didn't exist at that time... but it's irrelevant.
​


> with just a small piece of code in the community while keeping most of the
> driver code closed. Since then the code has grown, but we kept with the
> same format. We would like now to open the driver source code, while
> keeping the connectivity to the storage as closed source.

​It might help to know *which* driver you are referring to.  IBM has a
number of Storwiz and GPFS drivers in Cinder... what drivers are you
referring to here?​


>
> I believe that there are other cinder drivers that have some stuff in
> proprietary libraries.

​Actually we've had a hard stance on this, if you have code in Cinder that
requires an external lib (I personally hate this model) we typically
require it to be open source.

I want to propose and formalize the principles to where we draw the line
> (this has also been discussed in https://review.openstack.org/#/c/341780/)
> on what's acceptable by the community.
> ​
>


> Based on previous discussion I understand that the rule of thumb is "as
> long as the majority of the driver logic is in the public driver" the
> community would be fine with that. Is this acceptable to the community?

​No, I don't think that's true.  It's quite possible that some people make
those sorts of statements but frankly their missing the entire point.

In case you weren't aware, OpenStack IS an OPEN SOURCE project, not a
proprietary or hybrid project.  We are VERY clear as a community about that
fact and what we call the "4 Opens" [1].  It's my opinion that if you're in
then you're ALL in.​

[1]: https://governance.openstack.org/reference/opens.html
​

>
>
> Regards,
> Alon
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [Fuel] Getting rid of ISO

[Vladimir Kozhukalov]

Dear colleagues,

I'm glad to announce that we have working BVT jobs on Fuel CI that do not
use ISO but instead deploy Fuel admin node from packages onto vanilla
Centos 7.

Please take a look at [1]. There are jobs '10.0.repos.*' [2], [3], [4].

We continue to work on re-implementing review jobs like this one [5] for
example.


[1] https://ci.fuel-infra.org/view/BVT/
[2] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.snapshot/
[3] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.bvt_2/
[4]
https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.smoke_neutron/
[5]
https://ci.fuel-infra.org/job/master.fuel-astute.pkgs.ubuntu.review_astute_patched/




Vladimir Kozhukalov

On Thu, Sep 1, 2016 at 1:13 PM, Roman Prykhodchenko  wrote:

> This is so awesome! Thanks!
>
> On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes  wrote:
>
>> On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote:
>> > Dear colleagues,
>> >
>> > We finally have working custom deployment job that deploys Fuel admin
>> > node using online RPM repositories (not ISO) on vanilla Centos 7.0.
>>
>> Bravo! :)
>>
>> > Currently all Fuel system and deployment tests use ISO and we are
>> > planning to re-implement all these jobs (including BVT, SWARM, and Fuel
>> > CI jobs) to exclude ISO from the pipeline. That will allow us to get rid
>> > of ISO as our deliverable and instead rely totally on package
>> > repositories. Linux distributions like Ubuntu, Debian, RHEL, etc. are
>> > already delivered via ISO/qcow2/etc. images and we'd better stop
>> > reinventing a wheel and support our own ISO build code. That will allow
>> > us to make Fuel admin node deployment more flexible.
>> >
>> > I will infrom about our next steps here in the thread.
>>
>> Thanks, Vova, this is an excellent step forward for ease-of-use with Fuel.
>>
>> Nice work,
>> -jay
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Need clarify about baremetal host group and role in Ansible

[Mooney, Sean K]

> -Original Message-
> From: duon...@vn.fujitsu.com [mailto:duon...@vn.fujitsu.com]
> Sent: Wednesday, August 24, 2016 5:42 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [kolla] Need clarify about baremetal host
> group and role in Ansible
> 
> Hi all, sean-k-mooney,
> 
> In recent baremetal patchset [1] from sean-k-mooney, file
> ansible/inventory/multinode has following code snippet:
> 
> > [baremetal:children]
> > control
> > network
> > compute
> > storage
> 
> But all-in-one inventory does not have any change, so I have some
> questions after read through code base:
> - Why all-in-one is treated differently.
[Mooney, Sean K] in the all in one config the host is also the build host for 
the docker images.
I have not written the code to deploy the build host yet hence why its treated 
differently currently.
> - Do you treat every nodes as baremetal node?
[Mooney, Sean K] yes the baremetal group define all nodes that should be 
Prepared for use in hosting kolla services so it should include all nodes in 
the cloud.
Baremetal in this context has noting to do with ironic or biforst but rather 
the kolla host playbook.
I will be sending a separate mail later today dissucssing if we should change 
the name of the role and
Group for more clarity but itially the kolla-host playbook was being called the 
baremetal playbook to indicate
That it made changes to the host unlike the other kolla playbooks that do not.

> If the answer is "yes" so why we put it in "baremetal" role/group, I
> think it is quite misleading.
> - Why many host setup playbooks are placed in baremetal role? I think
> we can factor out to more general role.
> 
> Fix me if I wrong.
> 
> 
> [1] https://review.openstack.org/#/c/325631
> 
> Best regards,
> 
> duonghq
> PODC - Fujitsu Vietnam Ltd.
> 
> 
> 
> ___
> ___
> OpenStack Development Mailing 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] [cinder] moving driver to open source

[Michał Dulko]

On 09/06/2016 05:27 PM, Alon Marx wrote:
> I want to share our plans to open the IBM Storage driver source code.
> Historically we started our way in cinder way back (in Essex if I'm
> not mistaken) with just a small piece of code in the community while
> keeping most of the driver code closed. Since then the code has grown,
> but we kept with the same format. We would like now to open the driver
> source code, while keeping the connectivity to the storage as closed
> source.
> I believe that there are other cinder drivers that have some stuff in
> proprietary libraries. I want to propose and formalize the principles
> to where we draw the line (this has also been discussed in
> https://review.openstack.org/#/c/341780/) on what's acceptable by the
> community.
> Based on previous discussion I understand that the rule of thumb is
> "as long as the majority of the driver logic is in the public driver"
> the community would be fine with that. Is this acceptable to the
> community?

To me it seems impossible to openly measure "majority of the driver
logic"  when any logic is being closed source as you simply don't know
how much logic is being hidden. Normal practice in other Cinder drivers
is communicating with the storage through the REST API, and in that case
community doesn't care about the logic hidden in the REST API. But I
guess this won't work for your requirements as you want to "keep the
connectivity to the storage as closed source". Are my assumptions right?

>
> Regards,
> Alon


__
OpenStack Development Mailing List (not for 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] Testing optional composable services in the CI

[Emilien Macchi]

On Wed, Sep 7, 2016 at 9:18 AM, Dmitry Tantsur  wrote:
> On 09/01/2016 05:48 PM, Emilien Macchi wrote:
>>
>> On Thu, Aug 25, 2016 at 9:16 AM, Steven Hardy  wrote:
>>>
>>> On Wed, Aug 17, 2016 at 07:20:59AM -0400, James Slagle wrote:

 On Wed, Aug 17, 2016 at 4:04 AM, Dmitry Tantsur 
 wrote:
>
> However, the current gate system allows to run jobs based on files
> affected.
> So we can also run a scenario covering ironic on THT check/gate if
> puppet/services/*ironic* is affected, but not in the other cases. This
> won't
> cover all potential failures, but it would be of great help anyway. It
> should also run in experimental pipeline, so that it can be triggered
> on any
> patch.
>
> This is in addition to periodic jobs you're proposing, not replacing
> them.
> WDYT?


 Using the files affected to trigger a scenario test that uses the
 affected composable service sounds like a really good idea to me.
>>>
>>>
>>> +1 I think this sounds like a really good idea.
>>>
>>> Now that we're doing almost all per-service configuration in the
>>> respective
>>> templates and puppet profiles, this should be much easier to implement I
>>> think so definitely +1 on giving it a go.
>>>
>>
>> So I would like to give an update about this.
>> The work has been done to have the structure in place.
>> I first used experimental pipeline to test the new jobs but they are
>> now in check pipeline, as non-voting.
>>
>> I created a multinode jobs CI matrix here:
>> https://github.com/openstack-infra/tripleo-ci#service-testing-matrix
>> I encourage everyone to have a quick look at it.
>>
>> What is happening now?
>>
>> - If you submit a patch in THT (in puppet/services/ceilometer*) it
>> will trigger scenario001 job (example with Telemetry). Same thing for
>> Puppet profiles in puppet-tripleo. Note: with Zuul v3 we'll be able to
>> make things more granular and specific to projects and files. We're
>> looking for having it!
>> - Since multinode-nonha initially created by slagle is now a bit
>> redundant with scenarios, I'll make it lighter to test basic compute
>> services with the less services as possible.
>> - I'll continue to extend the scenarios complexity and start testing
>> different backends (ie, ceph/rbd on scenario001 with Telemetry, etc),
>> like we're doing in Puppet CI:
>> https://github.com/openstack/puppet-openstack-integration#description
>> - For now, we're using pingtest to test that services actually work. I
>> guess it's good for now, but we also might want to consider Tempest
>> sometimes. I know Tempest already runs on periodic jobs, but should we
>> also consider it in those multinode jobs? The feedback would be
>> valuable though but we would have to make tempest configuration
>> composable, depending on the services we actually run (maybe using
>> discovery, etc).
>>
>> Any help and feedback on this topic is highly welcome,
>>
>
> It's pretty cool, unfortunately putting nova-compute on controllers is
> incompatible with the approach we currently take for ironic... so we either
> need a separate scenario or another approach here.

Yes, if you read the end of my blog post, you'll see that we need to
investigate adding one more node for the scenario where Ironic would
run... That's something we will investigate and probably implement
soon.

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



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

Re: [openstack-dev] [requirements][FFE] global-requirements update to positional to 1.1.1

[Ian Cordasco]

-Original Message-
From: Matthew Thode 
Reply: prometheanf...@gentoo.org ,
OpenStack Development Mailing List (not for usage questions)

Date: September 7, 2016 at 08:12:15
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [requirements][FFE] global-requirements
update to positional to 1.1.1

> https://review.openstack.org/366631
>
> The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> current minimum requirement) results in various unit test failures in
> barbican, related to parsing of request headers in generated contexts
> for unit testing. Updating to 1.1.1 resolves this issue.

So I take it someone has verified that the request headers used in the
faked(?) contexts in these tests will never be seen in the real world
then? I looked at the tests that James linked in the barbican channel
when they were looking for help debugging this and those looked like
*functional* tests, not unit tests. That doesn't give me any
confidence that this is *just* a testing issue.

> This is specifically affecting barbican and RDO testing (from discussion
> and the review).

I believe this is also affecting Ubuntu's backing of Newton-3, but
James can correct me if I'm wrong.

> The reason I think an FFE is needed is because downstream packagers,
> while encouraged to package based on upper-constraints sometimes don't.
> Meaning they'd miss something like this.
>
> Arguments against are that this will have knock on effects down the line
> (will require re-releases and re-re-releases because of updating things
> like keystone (this is deep in the depgraph)), so is bad from a release
> team work point of view. Also, I think this just effects testing, so
> the impact of this is more minor than something more serious (not JUST
> breaking testing).

That's one aspect of the conversation. The other is that we *claim* to
support a minimum version of positional which we don't actually
support (and it seems like we either can't or won't). We should have
the *correct* minimum version specified. While I think this is the
*correct* approach, I also realize that the release team is probably
against this for more *pragmatic* reasons and I respect those and the
release team immensely. I'd like them to weigh in here as well.

--
Ian Cordasco

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

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

https://review.openstack.org/366298

This is just a bump to upper-constraints so is more minor to get testing
working and fix the bug that occurred in Gnocchi (and possibly others).

We are able to mask the 'bad' versions of oslo.db and unmask pymysql
0.7.7 after the freeze (and backport them to stable/newton) so this is
easier to merge.


-- 
-- Matthew Thode (prometheanfire)



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