Re: [openstack-dev] [neutron][stadium] Query regarding procedure for inclusion in Neutron Stadium

[Takashi Yamamoto]

hi,

On Fri, Sep 23, 2016 at 4:20 AM, Armando M.  wrote:
>
>
> On 22 September 2016 at 00:46, reedip banerjee  wrote:
>>
>> Dear Neutron Core members,
>>
>> I have a query regarding the procedure for inclusion in the Neutron
>> Stadium.
>> I wanted to know if a project can apply for Big Tent and Neutron Stadium
>> together ( means can a project be accepted in the Neutron Stadium and as a
>> result into the Big Tent )
>>
>> I was checking out the checklist in  [1], and IMO , I think that we need
>> to conform to the checklist to be added to the Neutron Stadium ( along with
>> the other requirements  like keeping in sync with the core neutron concepts)
>>
>> But IIUC, certain items in the checklist would be completed if a project
>> is already included in the Big Tent.
>
>
> I would not worry about those, as these are rather trivial to implement in
> conjunction with Stadium inclusion. I'd worry about the fork that the
> project relies on, which is a big show stopper for Stadium inclusion.
>
> [1] https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50

just a clarification; this is not a fork of ovs-agent. it's a separate agent.

>
>>
>>
>> So my doubt is ,should a project apply for the Big Tent first, and after
>> inclusion, apply for Neutron Stadium ? Or can a project be integrated to
>> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
>> this though)?
>
>
> You are confusing the two things. A project either belongs to list [1] or
> list [2], and you can't be in both at the same time. To be part of either
> list a project must comply with a set of criteria. As for the latter, a
> couple of steps may sound like a catch 22: for instance you can't make docs
> available on docs.o.o unless you are in [2] and you can't be in [2]
> unless...and here's the trick, unless you are a point where you can
> successfully demonstrate that the project has substantial documentation (of
> any sort, API included). The process of 'demonstrating'/application for
> inclusion in list [2] follows the RFE submission process that we have
> adopted for a while, and that means submitting a spec. Since the request
> does not require a conventional design process, I was going to prepare an
> ad-hoc template and make it available soon. So watch the neutron-specs repo
> for updates.
>
> In the meantime, I'd urge you to go over the checklist and make sure you can
> address the hard parts.
>
> If you ask me, if you go with [1], it makes no sense to go and apply to be
> in [2].
>
> HTH
> Armando
>
> [1] http://governance.openstack.org/reference/projects/
> [2] http://governance.openstack.org/reference/projects/neutron.html
>
>>
>>
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/stadium/governance.html#checklist
>> --
>> Thanks and Regards,
>> Reedip Banerjee
>> IRC: reedip
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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] What's Up, Doc? 23 September

[Lana Brindley]

Hi everyone,

Newton goes out in just two weeks, and the release team and I have been busy 
working through release tasks in preparation. Don't forget that you can contact 
any of us (or just send mail to the docs mailing list) if you have any 
questions about the Newton docs release. 

I'm also pleased to announce that I have been returned as the documentation PTL 
for Ocata, which will be my fourth term. Thanks for all the support!

== Progress towards Newton ==

12 days to go!

Bugs closed so far: 455

Release managers: Olena Logvinova and Alexandra Settle

Release tasks are being tracked here: 
https://etherpad.openstack.org/p/NewtonRelease

Install Guide testing is being tracked here: 
https://wiki.openstack.org/wiki/Documentation/NewtonDocTesting

== The Road to Barcelona ==

* I have a draft schedule starting to take shape, which you can see here: 
https://etherpad.openstack.org/p/Ocata-DocsSessions I'll put this into Sched 
once the tool becomes available, and your early feedback is welcome. 
Additionally, if you're interested in moderating a session in Barcelona, please 
let me know. 
* By now, you should be well on the way to having your travel and accommodation 
booked for Barcelona. In case you're still working on it, though, there's 
travel information available on the Summit site here: 
https://www.openstack.org/summit/barcelona-2016/travel/
* Looking a little further forward, Foundation have now announced that the 
first Project Team Gathering (PTG) will be held in Atlanta, US, on Feb 20-24: 
http://www.openstack.org/ptg

== Doc team meeting ==

Next meetings:

The APAC meeting was skipped this week.

Next meetings:
US: Wednesday 28 September, 19:00 UTC
APAC: Wednesday 5 October, 00:30 UTC

These two meetings will be the final meetings before release day.

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#23_September_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] floating IP is DOWN

[Salvatore Orlando]

Probably that LOG statement is a line added for debugging purposes.
There are several probable causes for a floating ip being down. If you see
any traceback in the neutron server or l3-agent that will probably
immediately reveal the root cause.

On the other hand, lack of any traceback might indicate communication
issues between the server and the l3 agent.

Salvatore

On 22 September 2016 at 16:53, Brian Haley  wrote:

> On 09/22/2016 10:19 AM, Barber, Ofer wrote:
>
>> when i assign a floating IP to a server, i see that the status of the
>> floating
>> IP is "down"
>>
>> why is that so ?
>>
>> *_code:_*
>>
>> LOG.info("\n<== float IP address: %s and status: %s  ==>" %
>> (float_ip['floating_ip_address'],float_ip['status']))
>>
>> *_Output:_*
>>
>> <== float IP address: 10.63.101.225 and status: DOWN  ==>
>>
>
> I couldn't find that code anywhere, what release was this on?
>
> From a Newton-based system created yesterday, this is the message in the
> l3-agent log when I associate a floating IP:
>
> Floating ip 4c1b4571-a003-43f2-96a1-f7073cd1319d added, status ACTIVE
>
> -Brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Davanum Srinivas]

Steven,

Fair point.

Thanks,
Dims

On Thu, Sep 22, 2016 at 11:04 PM, Steven Dake (stdake)  wrote:
> Dims,
>
> This isn’t any of my particular business except it could affect emerging 
> technology projects (which I find important to OpenStack’s future) negatively 
> – so I thought I’d chime in.
>
> A lack of activity in a specs repo doesn’t mean much to me.  For example, as 
> Kolla was an emerging project we didn’t use any specs process at all (or very 
> rarely).  There is a reason behind this. Now that Kolla is stable and 
> reliable and we feel we are not an emerging project, we plan to make use of a 
> specs repo starting in Ocata.
>
> I have no particular concerns with the other commentary – but please don’t 
> judge a project by activity or lack of activity in one repo of its 
> deliverables.  Judge it holistically (You are judging holistically.  I 
> believe a lack of one repo’s activity shouldn’t be part of that judgement).
>
> Regards
> -steve
>
>
> On 9/21/16, 2:08 PM, "Davanum Srinivas"  wrote:
>
> Jakub,
>
> Please see below.
>
> On Wed, Sep 21, 2016 at 3:46 PM, Jakub Pavlik  
> wrote:
> > Hello all,
> >
> > it took us 2 years of hard working to get these official. 
> OpenStack-Salt is
> > now used by around 40 production deployments and it is focused very on
> > operation and popularity is growing. You are removing the project week 
> after
> > one of top contributor announced that they will use that as part of
> > solution. We made a mistakes, however I do not think that is reason to
> > remove us. I do no think that quality of the project is measured like 
> this.
> > Our PTL got ill and did not do properly his job for last 3 weeks, but 
> this
> > can happen anybody.
> >
> >  It is up to you. If you think that we are useless for community, then
> > remove us and we will have to continue outside of this community. 
> However
> > growing successful use cases will not be under official openstack 
> community,
> > which makes my feeling bad.
>
> Data points so far are:
> 1. No response during Barcelona planning for rooms
> 2. Lack of candidates for PTL election
> 3. No activity in the releases/ repository hence no entries in
> https://releases.openstack.org/
> 4. Meetings are not so regular?
> http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed
> to be weekly)
> 5. Is the specs repo really active?
> http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
> work being done elsewhere?
> 6. Is there an effort to add stuff to the CI jobs running on openstack
> infrastructure? (can't seem to find much
> 
> http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config)
>
> I'll stop here and switch to #openstack-salt channel to help work you
> all through if there is a consensus/willingness from the
> openstack-salt team that there's significant work to be done. If you
> think you are better off not on the governance, that would be your
> call as well.
>
> Thanks,
> Dims
>
> > Thanks,
> >
> > Jakub
> >
> >
> > On 21.9.2016 21:03, Doug Hellmann wrote:
> >>
> >> Excerpts from Filip Pytloun's message of 2016-09-21 20:36:42 +0200:
> >>>
> >>> On 2016/09/21 13:23, Doug Hellmann wrote:
> 
>  The idea of splitting the contributor list comes up pretty regularly
>  and we rehash the same suggestions each time.  Given that what we
>  have now worked fine for 57 of the 59 offical teams (the Astara
>  team knew in advance it would not have a PTL running, and Piet had
>  some sort of technical issue submitting his candidacy for the UX
>  team), I'm not yet convinced that we need to make large-scale changes
>  to our community communication standard practices in support of the
>  2 remaining teams.
> 
>  That's not to say that the system we have now is perfect, but we
>  can't realistically support multiple systems at the same time.  We
>  need everyone to use the same system, otherwise we have (even more)
>  fragmented communication. So, we either need everyone to agree to
>  some new system and then have people step forward to implement it,
>  or we need to all agree to do our best to use the system we have
>  in place now.
> >>>
> >>> I think it may work as is (with proper mail filters), but as someone
> >>> already
> >>> mentioned in this thread it would be better to have someone more
> >>> experienced
> >>> in Openstack community projects as a core team member or PTL to catch 
> all
> >>> these things otherwise it may happen that inexperienced PTL/team just
> >>> miss
> >>> something like now.
> >>
> >> If the team needs help, 

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Steven Dake (stdake)]

Dims,

This isn’t any of my particular business except it could affect emerging 
technology projects (which I find important to OpenStack’s future) negatively – 
so I thought I’d chime in.

A lack of activity in a specs repo doesn’t mean much to me.  For example, as 
Kolla was an emerging project we didn’t use any specs process at all (or very 
rarely).  There is a reason behind this. Now that Kolla is stable and reliable 
and we feel we are not an emerging project, we plan to make use of a specs repo 
starting in Ocata.

I have no particular concerns with the other commentary – but please don’t 
judge a project by activity or lack of activity in one repo of its 
deliverables.  Judge it holistically (You are judging holistically.  I believe 
a lack of one repo’s activity shouldn’t be part of that judgement).

Regards
-steve


On 9/21/16, 2:08 PM, "Davanum Srinivas"  wrote:

Jakub,

Please see below.

On Wed, Sep 21, 2016 at 3:46 PM, Jakub Pavlik  
wrote:
> Hello all,
>
> it took us 2 years of hard working to get these official. OpenStack-Salt 
is
> now used by around 40 production deployments and it is focused very on
> operation and popularity is growing. You are removing the project week 
after
> one of top contributor announced that they will use that as part of
> solution. We made a mistakes, however I do not think that is reason to
> remove us. I do no think that quality of the project is measured like 
this.
> Our PTL got ill and did not do properly his job for last 3 weeks, but this
> can happen anybody.
>
>  It is up to you. If you think that we are useless for community, then
> remove us and we will have to continue outside of this community. However
> growing successful use cases will not be under official openstack 
community,
> which makes my feeling bad.

Data points so far are:
1. No response during Barcelona planning for rooms
2. Lack of candidates for PTL election
3. No activity in the releases/ repository hence no entries in
https://releases.openstack.org/
4. Meetings are not so regular?
http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed
to be weekly)
5. Is the specs repo really active?
http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
work being done elsewhere?
6. Is there an effort to add stuff to the CI jobs running on openstack
infrastructure? (can't seem to find much

http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config)

I'll stop here and switch to #openstack-salt channel to help work you
all through if there is a consensus/willingness from the
openstack-salt team that there's significant work to be done. If you
think you are better off not on the governance, that would be your
call as well.

Thanks,
Dims

> Thanks,
>
> Jakub
>
>
> On 21.9.2016 21:03, Doug Hellmann wrote:
>>
>> Excerpts from Filip Pytloun's message of 2016-09-21 20:36:42 +0200:
>>>
>>> On 2016/09/21 13:23, Doug Hellmann wrote:

 The idea of splitting the contributor list comes up pretty regularly
 and we rehash the same suggestions each time.  Given that what we
 have now worked fine for 57 of the 59 offical teams (the Astara
 team knew in advance it would not have a PTL running, and Piet had
 some sort of technical issue submitting his candidacy for the UX
 team), I'm not yet convinced that we need to make large-scale changes
 to our community communication standard practices in support of the
 2 remaining teams.

 That's not to say that the system we have now is perfect, but we
 can't realistically support multiple systems at the same time.  We
 need everyone to use the same system, otherwise we have (even more)
 fragmented communication. So, we either need everyone to agree to
 some new system and then have people step forward to implement it,
 or we need to all agree to do our best to use the system we have
 in place now.
>>>
>>> I think it may work as is (with proper mail filters), but as someone
>>> already
>>> mentioned in this thread it would be better to have someone more
>>> experienced
>>> in Openstack community projects as a core team member or PTL to catch 
all
>>> these things otherwise it may happen that inexperienced PTL/team just
>>> miss
>>> something like now.
>>
>> If the team needs help, please ask for it. We should be able to find
>> someone to do a little mentoring and provide some guidance.
>>
>>> Still I don't think it's such a big issue to just fire project from Big
>>> Tent -
>>> who will benefit from that? Again someone already mentioned what will it
>>> mean

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

[Brandon Logan]

Congrats Ihar!

On Sat, 2016-09-17 at 09:40 -0700, Armando M. wrote:
> Hi folks,
> 
> I would like to propose Ihar to become a member of the Neutron
> drivers team [1].
> 
> Ihar wide knowledge of the Neutron codebase, and his longstanding
> duties as stable core, downstream package whisperer, release and
> oslo liaison (I am sure I am forgetting some other capacity he is in)
> is going to put him at great comfort in the newly appointed role, and
> help him grow and become wise even further.
> 
> Even though we have not been meeting regularly lately we will resume
> our Thursday meetings soon [2], and having Ihar onboard by then will
> be highly beneficial. 
> 
> Please, join me in welcome Ihar to the team.
> 
> Cheers,
> Armando 
> 
> [1] http://docs.openstack.org/developer/neutron/policies/neutron-team
> s.html#drivers-team
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [tricircle]freeze date and patches to be merged for Newton release

[joehuang]

Good idea, Two patches got merged yesterday.

Reorganized the items as follows, updated in 
https://etherpad.openstack.org/p/TricircleNewtonFreeze:

MUST TO HAVE: subnet deletion

  *   https://review.openstack.org/355847

  *

MUST TO HAVE: router deletion

  *   https://review.openstack.org/360848

  *

MUST TO HAVE: server action part2

  *   https://review.openstack.org/#/c/369958/

MUST TO HAVE: framework for dynamic pod binding

  *   https://review.openstack.org/#/c/356187/

  *

MUST TO HAVE: volume detach

  *   https://review.openstack.org/#/c/326192/

MUST TO HAVE: installation update

  *   https://review.openstack.org/#/c/372414/

  *

MUST TO HAVE: floating ip deletion (merged)

  *   https://review.openstack.org/354604

  *

MUST TO HAVE: server action part1 (merged)

  *   https://review.openstack.org/#/c/366606/

GOOD TO HAVE: add resource_affinity_tag

  *   https://review.openstack.org/#/c/323687/

  *

GOOD TO HAVE: spec for local plugin

  *   https://review.openstack.org/368529

  *

GOOD TO HAVE: force detach volume

  *   https://review.openstack.org/#/c/359561/

GOOD TO HAVE: others not mentioned here


It's hard to rank these MUST TO HAVE items, so let's review MUST TO HAVE patch 
in time when it's ready or with new update.

Best Regards
Chaoyi Huang (joehuang)

From: Shinobu Kinjo [shinobu...@gmail.com]
Sent: 22 September 2016 18:00
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]freeze date and patches to be merged 
for Newton release

Please add 1 line above description of each patch.

MUST TO HAVE
or
GOOD TO HAVE

e.g.,
https://review.openstack.org/#/c/356187/

 MUST TO HAVE
 The framework of dynamic pod binding.

So that we can prioritize clearly and easily.

Ideally we should have made priority for each *MUST* case.

Regards,
Shinobu


On Thu, Sep 22, 2016 at 10:42 AM, joehuang 
> wrote:
Hello,

During yesterday's weekly meeting, patches were identified for these must be 
merged before freeze date for Newton release:

Freeze date: Sept.30, 2016

Must to have: must be merged before Sept.30, basic feature for Tricircle Newton 
release
https://review.openstack.org/#/c/356187/ framework for dynamic pod binding
https://review.openstack.org/354604 floating ip deletion
https://review.openstack.org/355847 subnet deletion
https://review.openstack.org/360848 router deletion
https://review.openstack.org/#/c/366606/ server action part1
https://review.openstack.org/#/c/369958/ server action part2
https://review.openstack.org/#/c/372414/ installation update
https://review.openstack.org/#/c/326192/ volume detach

Good to have: best effort
https://review.openstack.org/#/c/323687/ add resource_affinity_tag
https://review.openstack.org/368529 spec for local plugin
https://review.openstack.org/#/c/359561/
others not mentioned here

You can also refer to https://etherpad.openstack.org/p/TricircleNewtonFreeze  
for the discussion log.

Let's update patch and review in time to ensure "Must to have" get merged 
before freeze date Sept.30.

Thank you for your great effort. The Newton branch will be created at UTC 
9:00AM Sept.30.

Best Regards
Chaoyi Huang (joehuang)

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




--
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-dev] [horizon] gate failures (fragile integrated tests)

[Akihiro Motoki]

Hi horizoners,

The current horizon gate is half broken as both integrated tests are 30-40%
failure rate.
(See https://bugs.launchpad.net/horizon/+bug/1626536 and
https://bugs.launchpad.net/horizon/+bug/1626643)
Fixes for these bugs are now under the gate.

Please avoid using 'recheck' if one of integrated tests fails.

Cores, let these fixes be merged first.
Until then, avoid giving +A for others to merge them fast.

Thanks,
Akihiro
__
OpenStack Development Mailing List (not for 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] when we use yum install ansible to install ansible2.1.1.0， I deploy failed with mitaka ，and actually precheck limit version to 2.0.0.

[Jeffrey Zhang]

Mitaka only supports ansible < 2 version. You can install ansible 1.9
by `yum install ansible1.9`

On Thu, Sep 22, 2016 at 8:41 PM,   wrote:
> when we use yum install ansible to install ansible2.1.1.0， I deploy failed
> with mitaka ，and actually precheck limit version to 2.0.0.
> so I want to know if kolla with mitaka suppout ansible2.1.1.0，can you help
> me？ thanks！
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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

Re: [openstack-dev] [Security] Picking a new tag

[Jeremy Stanley]

On 2016-09-23 08:35:54 +1000 (+1000), Tony Breeds wrote:
[...]
> I had a look at
> http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev
> which will list the topics setup and it's far from exhustive, for
> example '[all]' isn't there :(
[...]

It actually is, but Mailman (unhelpfully) lists tags by their long
descriptions. Go ahead and click on the Details link next to the
Cross-project coordination topic and you'll see that's actually the
name for the [all] tag.
-- 
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] [ptl] code churn and questionable changes

[Fei Long Wang]

On 23/09/16 11:19, Lana Brindley wrote:

On 23/09/16 02:19, Amrith Kumar wrote:

Joshua,

I think Steve and you may be missing the point of my email. It *IS* because I 
want to be open and inviting that I even asked the question, and what I'm 
asking for is how to deal with it.

All Steve says is " The fact that a new-to-openstack contributor would make such and 
error doesn’t warrant such a negative response even if it a hassle for the various PTLs 
and core reviewer teams to deal with".

I'm not proposing a negative response, I'm asking how to deal with it.

What, for example, does one do if a patch is proposed virtually identically in 
a half dozen (or two dozen) projects by someone and is totally bat-shit crazy? 
Merely -1'ing it and offering to help in a private email is not really the 
answer. I've tried it.

We all have. And we keep doing it. And doing it again.


Having a file in the projects repo that talks about guidelines for 
contributions isn't it either. We have one of those. It is up to the 
contributor to read it; yes, I can keep pointing contributors to that but this 
is a systemic problem which I'm hoping to address.

It's only systemic in the sense that it's standard human behaviour. And I doubt 
you'll be able to fix that with some automation.


What does one do when a contributor continually proposes one line changes that 
fix typos in comments (yes, really). At some point, these changes (while 
absolutely, and unarguably valid) begin to be a drag on the community.

Coach. Train. Communicate.


What I'm asking for is something, something that may cross project boundaries, 
that will help bring contributors onto openstack, and rapidly bring them to the 
point where they are contributing at a level that materially benefits the 
project(s).

-amrith


Sounds like you're looking for a technical solution to a social problem.


Agree, it's not a technical problem. And as you know, most of them are 
new comers, normally, they just need more time to familiar with the 
rules or find a project they're interested in. I don't think an very 
experienced openstacker will enjoy proposing a lot of low-value patches.



You're the PTL. Make sure there's good documentation about expected behaviours, 
point to it when you decline a patch, and always be available for mentoring and 
coaching. Yes, you will teach people the 101 version of contributing a million 
times over, and you'll repeat yourself ad nauseum, often to the same people. 
It's called leadership.

If you have a truly toxic person in your midst (hint: these are rarely 
newcomers, you don't discover these people straight away, I've found), *then* 
you can do something to remove them from your community. Here's a good place to 
start: https://hypatia.ca/2016/06/21/no-more-rock-stars/

No one said leadership was easy.

L



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


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

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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Lana Brindley]

On 23/09/16 02:19, Amrith Kumar wrote:
> Joshua,
> 
> I think Steve and you may be missing the point of my email. It *IS* because I 
> want to be open and inviting that I even asked the question, and what I'm 
> asking for is how to deal with it.
> 
> All Steve says is " The fact that a new-to-openstack contributor would make 
> such and error doesn’t warrant such a negative response even if it a hassle 
> for the various PTLs and core reviewer teams to deal with".
> 
> I'm not proposing a negative response, I'm asking how to deal with it.
> 
> What, for example, does one do if a patch is proposed virtually identically 
> in a half dozen (or two dozen) projects by someone and is totally bat-shit 
> crazy? Merely -1'ing it and offering to help in a private email is not really 
> the answer. I've tried it.

We all have. And we keep doing it. And doing it again.

> 
> Having a file in the projects repo that talks about guidelines for 
> contributions isn't it either. We have one of those. It is up to the 
> contributor to read it; yes, I can keep pointing contributors to that but 
> this is a systemic problem which I'm hoping to address. 

It's only systemic in the sense that it's standard human behaviour. And I doubt 
you'll be able to fix that with some automation.

> 
> What does one do when a contributor continually proposes one line changes 
> that fix typos in comments (yes, really). At some point, these changes (while 
> absolutely, and unarguably valid) begin to be a drag on the community.

Coach. Train. Communicate.

> 
> What I'm asking for is something, something that may cross project 
> boundaries, that will help bring contributors onto openstack, and rapidly 
> bring them to the point where they are contributing at a level that 
> materially benefits the project(s).
> 
> -amrith
> 

Sounds like you're looking for a technical solution to a social problem.

You're the PTL. Make sure there's good documentation about expected behaviours, 
point to it when you decline a patch, and always be available for mentoring and 
coaching. Yes, you will teach people the 101 version of contributing a million 
times over, and you'll repeat yourself ad nauseum, often to the same people. 
It's called leadership.

If you have a truly toxic person in your midst (hint: these are rarely 
newcomers, you don't discover these people straight away, I've found), *then* 
you can do something to remove them from your community. Here's a good place to 
start: https://hypatia.ca/2016/06/21/no-more-rock-stars/

No one said leadership was easy. 

L

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] [AODH] event-alarm timeout discussion

[gordon chung]

On 22/09/2016 2:40 AM, Zhai, Edwin wrote:
>
> See
> https://github.com/openstack/aodh/blob/master/aodh/evaluator/event.py#L158
>
> evaluate_events is the handler of the endpoint for 'alarm.all', it
> iterates the event list and evaluate them one by one with project
> alarms. If both 'timeout.end' and 'X' are in the event list, I assume
> they are handled in sequence at different iterations of for loop. Am I
> right?

not exactly. the code above is actually an endpoint for event listener. 
the event listener itself is threaded so in theory, we have 64 of these 
endpoints/loops. you can override the threads to have just one but 
that's where things slow down a lot. we handle this in ceilometer by 
having many single thread listeners each handling it's own queue[1]. i 
still need to publish diagram on how that works.

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/notification.py#L308

>
> If we have evaluate_timeout_events as handler of another endpoint for
> 'alarm.timeout', then 2 handlers can run concurrently to lead race
> condition. I'm not familiar with underline oslo notifications, and think
> separated queue is different story. Pls. correct me if I'm wrong.
>

deleted your sequence diagram since it's malformed in my response but 
that is pretty cool.

a few questions:
- when alarm creation event arrives at evaluator it creates a thread to 
process alarm. this thread will timeout and raise a new event if it 
doesn't receive event in time? i don't understand why we need a 
timeout.end event? can the evaluator not just update_alarm and notify if 
we timeout? or update_alarm and skip notify if we receive event on time?

cheers,

-- 
gord

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

Re: [openstack-dev] [Security] Picking a new tag

[Tony Breeds]

On Thu, Sep 22, 2016 at 11:03:31PM +0100, Dave Walker wrote:
> Hi,
> 
> I'm not convinced it needs changing.  [security] is a pretty logical topic
> tag, and rolls off the keyboard quite easily.
> 
> So the real issue is filtering on headers.  Most mail providers do provide
> this, and certainly MUA.. however gmail does make it a bit harder.
> 
> Mailman wont see all arbitrary "[strings]", but the ones that are added
> allows the user to subscript specifically to them.  [security] is one such
> tag, which means that OSSP interested parties could subscribe
> *specifically* to that tag (and probably [all] for good measure).
> 
> However, this does mean that these subscribers have little chance of seeing
> any other mail.  What would be better would be to add labels (gmail
> terminology) specifically to [security] threads.
> 
> Mailman does add an X- field such as:
> "X-Topics: foo Security bar"

Well you learn something everyday ... today it just started early ;)

I had a look at
http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev which will
list the topics setup and it's far from exhustive, for example '[all]' isn't
there :(

I don't want to start a flood of requests to the Infrastructure team but we
might want to expand the list a little.

Personally I'd like to see all and stable added.
We can avoid adding election as a topic if the election officials use
'[all][election]' in the subject line[1][2]

It's probably beneficial for the PTL to subscribe to cross-project.

Yours Tony.
[1] Which, speaking only for myself, I'm happy to do
[2] Assuming All is added as a topic


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] [Security] Picking a new tag

[Dave Walker]

On 22 September 2016 at 19:52, Ian Cordasco  wrote:

> During the OpenStack Security Project (OSSP) meeting today we
> discussed the fact that some MUAs don't filter the "[Security]" tag
> very well and this causes a bit of an overload for people trying to
> follow the internal workings of the OSSP. We were briefly side-tracked
> trying to come up with a different tag that would be less likely to
> cause false positives with filtering.
>
> This also seemed like a good opportunity to use the mailing list to
> come up with our new tag, since we've had such an atrocious time using
> it in the past.
>
> Some of the suggestions I recall from the meeting include:
>
> - OSSP
> - openstack-sec
>
> I think we'd want to keep "openstack" out of our tag name, so maybe
>
> - sec-project
> - security-project
>
> Thoughts?
>
>
Hi,

I'm not convinced it needs changing.  [security] is a pretty logical topic
tag, and rolls off the keyboard quite easily.

So the real issue is filtering on headers.  Most mail providers do provide
this, and certainly MUA.. however gmail does make it a bit harder.

Mailman wont see all arbitrary "[strings]", but the ones that are added
allows the user to subscript specifically to them.  [security] is one such
tag, which means that OSSP interested parties could subscribe
*specifically* to that tag (and probably [all] for good measure).

However, this does mean that these subscribers have little chance of seeing
any other mail.  What would be better would be to add labels (gmail
terminology) specifically to [security] threads.

Mailman does add an X- field such as:
"X-Topics: foo Security bar"

Sadly you cannot search using the Gmail interface for these fields.. but it
does provide a service to run scripts on mails on regular intervals, which
will allow the desired labelling.

I've written a sample script, and it works.  Go to https://script.google.com
and add the contents of
https://gist.github.com/Daviey/eb61c284b6d3bf6562763db2cb8a7351 .  Click
the clock symbol, and set an hourly interval.

This will mean that all [Security] tagged mails receive an OSSP gmail label.

HTH, let me know if it does.

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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Clay Gerrard]

FWIW, No, this is *not* just an problem for OpenStack

https://youtu.be/wf-BqAjZb8M?t=531

^ Raymond Hettinger

Ultimately the problem is mis-aligned goals between the individual and the
project maintainers.  They want to "do stuff" and get a change landed; we
want to maximize the positive results for the project with our limited
available time.

But I caution you not to allow yourself to conflate their effort (while
borderline unhelpful to project/maintainers) as "bad" - they don't owe us
anything.  As long as blasting out a bunch of bugs and non-material changes
get them a few "commits in OpenStack" there is probably actual honest to
goodness reasons for that behavior to continue.

Go ahead and try to evaluate each change as best you can on it's own
merits.  Be friendly and helpful.  If you -2 provide *context*.  Point them
at canned materials you have for new contributors!

But, don't get your hopes up that any of these folks are going to "come
around".

-Clay


On Thu, Sep 22, 2016 at 1:05 PM, Sean M. Collins  wrote:

> Sean Dague wrote:
> > If this is the bug that triggered this discussion, yes, please never do
> > anything like that -
> > https://bugs.launchpad.net/python-openstacksdk/+bug/1475722
> >
>
> Here was another fun one.
>
> https://bugs.launchpad.net/python-cinderclient/+bug/1586268
>
> I commented as such that we don't like these kind of patches, but I
> couldn't find the mailing list thread where we last had this discussion.
>
> https://review.openstack.org/#/c/343133/
>
> Anyway, yeah this kind of thing is really annoying and burns a ton of
> resources for no good reason
>
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Anita Kuno]

On 16-09-21 01:11 PM, Doug Hellmann wrote:

Excerpts from Clint Byrum's message of 2016-09-21 08:56:24 -0700:

Excerpts from Filip Pytloun's message of 2016-09-21 14:58:52 +0200:

Hello,

it's definately our bad that we missed elections in OpenStackSalt
project. Reason is similar to Rob's - we are active on different
channels (mostly IRC as we keep regular meetings) and don't used to
reading mailing lists with lots of generic topics (it would be good to
have separate mailing list for such calls and critical topics or
individual mails to project's core members).

Our project is very active [1], trying to do things the Openstack way
and I think it would be a pitty to remove it from Big Tent just because
we missed mail and therefore our first PTL election.

Of course I don't want to excuse our fault. In case it's not too late,
we will try to be more active in mailing lists like openstack-dev and
not miss such important events next time.

[1] http://stackalytics.com/?module=openstacksalt-group


Seems like we need a bit added to this process which makes sure big tent
projects have their primary IRC channel identified, and a list of core
reviewer and meeting chair IRC nicks to ping when something urgent comes
up. This isn't just useful for elections, but is probably something the
VMT would appreciate as well, and likely anyone else who has an urgent
need to make contact with a team.

IRC channels are listed on team pages on governance.o.o. For example:
http://governance.openstack.org/reference/projects/openstacksalt.html

Core reviewers are accessible through gerrit. For example,
https://review.openstack.org/#/admin/projects/openstack/openstack-salt,access
leads to https://review.openstack.org/#/admin/groups/1268,members

Meeting chair nicks are available on eavesdrop.o.o. For example,
http://eavesdrop.openstack.org/#OpenStack_Salt_Team_Meeting

It might make sense to automate pulling that information together into a
single page somewhere, maybe the team page on governance.o.o.

The larger point is that the community expects teams to be paying
attention to the cycle schedule and taking care of the actions expected
without being individually asked to do so.


I think it might also be useful if we could make the meeting bot remind
teams of any pending actions they need to take such as elections upon
#startmeeting.

I could see that being useful, yes.


Seems like all of that could be automated.


__
OpenStack Development Mailing 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 am not convinced this situation arose due to lack of available 
information.


Thank you,
Anita.

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

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

[Thomas Goirand]

On 09/21/2016 03:44 PM, Ian Cordasco wrote:
> Thomas,
> 
> As you already pointed out, where it matters, the analysis of
> commits is correct. I'm sure the Stackalytics team has prioritized
> this as they see appropriate.

I've asked because I would like to attempt to fix it myself, considering
Ilya may not have enough time. That's a constructive reply, unlike what
you seemed to believe.

> How does the current prioritization
> harm the Debian packaging team?

No more or less than any other project in the big tent, I guess.

> Are employers of team members using stackalytics to judge activity?

Sorry to say it strait this way, but that's really none of your
business. Please avoid this type of remarks in the future.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for 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] when we use yum install ansible to install ansible2.1.1.0， I deploy failed with mitaka ，and actually precheck limit version to 2.0.0.

[Steven Dake (stdake)]

Lu,

The kolla documentation specifically states Newton has a pin on ansible < 
2.0.0.0

From: "lu.yao...@zte.com.cn" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, September 22, 2016 at 5:41 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [kolla] when we use yum install ansible to install 
ansible2.1.1.0， I deploy failed with mitaka ，and actually precheck limit 
version to 2.0.0.

when we use yum install ansible to install ansible2.1.1.0， I deploy failed with 
mitaka ，and actually precheck limit version to 2.0.0.
so I want to know if kolla with mitaka suppout ansible2.1.1.0，can you help me？ 
thanks！
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Steven Dake (stdake)]

Flavio,

Apologies for delay in response – my backlog is large.

Forgive me if I parsed your message incorrectly.  It came across to me as “How 
do I blaze a trail for OpenStack on Kubernetes?”.  That was asked of me 
personally 3 years ago which led to the formation of the Kolla project inside 
Red Hat.  Our initial effort at that activity failed.  Instead we decided 
kubernetes wasn’t ready for trailblazing in this space and used a far more 
mature project (Ansible) to solve the “OpenStack in Containers” problems and 
build from there.

We have since expanded our scope to re-solve the “How do I blaze a trail for 
Openstack on Kubernetes?” question since Kubernetes is now ready for this sort 
of trailblazing.  Fuel and several other folks decided to create derived works 
of the Kolla community’s innovations in this area.  I would contend that Fuel 
didn’t need to behave in such a way because the Kolla community is open, 
friendly, mature, diversely affiliated, has a reasonable philosophy and good 
set of principles as well as a strong leadership pipeline.

Rather than go blaze a trail when one already exists or create a derived work, 
why not increase your footprint in Kolla instead?  Red Hat has invested in 
Kolla for some time now, and their footprint hasn’t magically disappeared over 
night.   We will give you what you want within reasonable boundaries (the 
boundaries all open-source projects set of their contributors).  We also accept 
more work than the typical OpenStack project might, so it’s not like you will 
have to bring donuts into the office for every patch you merge into Kolla.

As to your more direct question of reference architecture, that is a totally 
loaded term that I’ll leave untouched.

To answer your question of “Does Kolla have a set of best practices” the answer 
is yes in kolla-ansible and kolla itself and strongly forming set of best 
practices in kolla-kubernetes.

Regards
-steve



On 9/22/16, 4:04 AM, "Flavio Percoco"  wrote:

Greetings,

I've recently started looking into the container technologies around 
OpenStack.
More specifically, I've been looking into the tools that allow for deploying
OpenStack on containers, which is what I'm the most interested in right now 
as
part of the TripleO efforts.

I'm familiar with the Kolla project and the tools managed by this team. In 
fact,
TripleO currently uses kolla images for the containerized nova-compute
deployment.

I am, however, looking beyond a docker based deployment. I'd like to 
explore in
more depth a Kubernetes based deployment of OpenStack. I'm familiar with 
both
kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
have now advanced a bit in their implementations and made some decisions.

As someone that started looking into this topic just recently, I'd love to 
see
our communities collaborate more wherever possible. For example, it'd be 
great
to see us working on a reference architecture for deploying OpenStack on
kubernetes, letting the implementation details aside for a bit. I'd assume 
some
folks have done this already and I bet we can all learn more from it if we 
work
on this together.

So, let me go ahead and ask some further questions here, I might be missing 
some
history and/or context:

- Is there any public documentation that acts as a reference architecture 
for
  deploying OpenStack on kubernetes?
- Is this something the architecture working group could help with? Or 
would it
  be better to hijack one of kolla meetings?

The restult I'd love to see from this collaboration is a reference 
architecture
explaining how OpenStack should be run on Kubernetes.

Thanks in advance. I look forward to see us collaborate more on this area,
Flavio

* thanks to all fuel and kolla contributors that helped me understand 
better the
  work in each of these projects and the direction they are headed
.
-- 
@flaper87
Flavio Percoco



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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Sean M. Collins]

Sean Dague wrote:
> If this is the bug that triggered this discussion, yes, please never do
> anything like that -
> https://bugs.launchpad.net/python-openstacksdk/+bug/1475722
> 

Here was another fun one.

https://bugs.launchpad.net/python-cinderclient/+bug/1586268

I commented as such that we don't like these kind of patches, but I
couldn't find the mailing list thread where we last had this discussion.

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

Anyway, yeah this kind of thing is really annoying and burns a ton of
resources for no good reason

-- 
Sean M. Collins

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

Re: [openstack-dev] [all] call for help debugging release-critical upgrade issue

[Sean Dague]

On 09/22/2016 03:13 PM, Doug Hellmann wrote:
> One of the steps we need to go through to finish this release is
> to set up the stable/newton branch in devstack-gate. The patch to
> do that [1] is consistently hitting timeout errors in some of the
> jobs, waiting for VMs to be visible after they boot, as well as
> another issue that looks like a race condition cleaning up a security
> group.
> 
> See [1] for the logs with the failures.  I have not opened a bug
> yet because it's not clear which project needs a fix.
> 
> We need some folks to get involved to figure out what's wrong and
> fix the problems.  Please follow-up here if you're signing up to
> help.
> 
> Thanks in advance for your help,
> Doug
> 
> [1] https://review.openstack.org/#/c/362438/

dhellman, armax, mriedem, and I spent some time in #openstack-dev
looking at this. We are hoping that -
https://review.openstack.org/#/c/375080/ fixes it. But it will be a
couple hours before tests are all in on 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] [Manila] [Documentation] Manila Documentation Blitz

[Dustin Schoenbrun]

Hey all,

TL;DR: Go to [0], sign up for a part of the docs to verify/review,
prioritize the Installation Guide and the "Steps to Perform" section of the
Administration Reference!

As Newton comes to a close it is a good time to go though our myriad
documentation and make sure that it is up to date, easy to follow, and is
correct. Doing this will help make our user experience all the better and
save us from having to debug as many issues when we could be working on new
features.

I've put together an Etherpad detailing the overarching guides and the
relevant subheadings so that the reviews can be parallelized as much as
possible. The Etherpad is at [0].

Please let me know if you have any questions about where to contribute, how
to contribute, or anything else!

[0] - https://etherpad.openstack.org/p/newton_documentation_blitz

Dustin Schoenbrun
OpenStack Quality Engineer
Red Hat, Inc.
dscho...@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

Re: [openstack-dev] [neutron][stadium] Query regarding procedure for inclusion in Neutron Stadium

[Armando M.]

On 22 September 2016 at 00:46, reedip banerjee  wrote:

> Dear Neutron Core members,
>
> I have a query regarding the procedure for inclusion in the Neutron
> Stadium.
> I wanted to know if a project can apply for Big Tent and Neutron Stadium
> together ( means can a project be accepted in the Neutron Stadium and as a
> result into the Big Tent )
>
> I was checking out the checklist in  [1], and IMO , I think that we need
> to conform to the checklist to be added to the Neutron Stadium ( along with
> the other requirements  like keeping in sync with the core neutron concepts)
>
> But IIUC, certain items in the checklist would be completed if a project
> is already included in the Big Tent.
>

I would not worry about those, as these are rather trivial to implement in
conjunction with Stadium inclusion. I'd worry about the fork that the
project relies on, which is a big show stopper for Stadium inclusion.

[1] https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50


>
> So my doubt is ,should a project apply for the Big Tent first, and after
> inclusion, apply for Neutron Stadium ? Or can a project be integrated to
> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
> this though)?
>

You are confusing the two things. A project either belongs to list [1] or
list [2], and you can't be in both at the same time. To be part of either
list a project must comply with a set of criteria. As for the latter, a
couple of steps may sound like a catch 22: for instance you can't make docs
available on docs.o.o unless you are in [2] and you can't be in [2]
unless...and here's the trick, unless you are a point where you can
successfully demonstrate that the project has substantial documentation (of
any sort, API included). The process of 'demonstrating'/application for
inclusion in list [2] follows the RFE submission process that we have
adopted for a while, and that means submitting a spec. Since the request
does not require a conventional design process, I was going to prepare an
ad-hoc template and make it available soon. So watch the neutron-specs repo
for updates.

In the meantime, I'd urge you to go over the checklist and make sure you
can address the hard parts.

If you ask me, if you go with [1], it makes no sense to go and apply to be
in [2].

HTH
Armando

[1] http://governance.openstack.org/reference/projects/
[2] http://governance.openstack.org/reference/projects/neutron.html


>
>
> [1] http://docs.openstack.org/developer/neutron/stadium/
> governance.html#checklist
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Broken port rule masking: let's have it fixed?

[Armando M.]

On 22 September 2016 at 05:50, Inessa Vasilevskaya <
ivasilevsk...@mirantis.com> wrote:

> Hello,
>
> Apologies for multiple posts, forgot to set proper subject in previous one.
>
> I'd like to turn attention to the broken port rule masking problem [1],
> which affects 2 projects so far:
> neutron (mitaka+ with ovs firewall driver configuration) and
> networking-ovs-dpdk [2].
>
> To keep it short: the existing port masking implementation is broken and
> in several cases it will either leave a range of ports open (causing
> unrestricted access) or make some ports inaccessible (when they should be
> open) because of bad tp_src value being generated.
>
> 2 solutions have been proposed so far:
> * The "low-level one" with O(log n) complexity by IWAMOTO Toshihiro and me
> [2]
> * The "high-level one" with O(n^2) complexity by Jakub Libosvar [3]
>
> As long as the bug looks like a security vulnerability and is kind of
> critical for ovs firewall feature, maybe we should choose one algorithm to
> go on with and have this fixed in Newton?
>
>
We'll try to converge on a path forward during today's Neutron drivers
meeting. Watch the logs.

Cheers,
Armando


> [1] https://bugs.launchpad.net/neutron/+bug/1611991
> [2] https://review.openstack.org/#/c/353782/30
> [3] https://review.openstack.org/#/c/353782/16
>
> Best regards,
> Inessa Vasilevskaya
>
>
> __
> OpenStack Development Mailing 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] [all] call for help debugging release-critical upgrade issue

[Doug Hellmann]

One of the steps we need to go through to finish this release is
to set up the stable/newton branch in devstack-gate. The patch to
do that [1] is consistently hitting timeout errors in some of the
jobs, waiting for VMs to be visible after they boot, as well as
another issue that looks like a race condition cleaning up a security
group.

See [1] for the logs with the failures.  I have not opened a bug
yet because it's not clear which project needs a fix.

We need some folks to get involved to figure out what's wrong and
fix the problems.  Please follow-up here if you're signing up to
help.

Thanks in advance for your help,
Doug

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

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

[openstack-dev] [nova] Can all virt drivers provide a disk 'id' for the diagnostics API?

[Matt Riedemann]

Sergey is working on a spec to use the standardized virt driver instance 
diagnostics in the os-diagnostics API. A question came up during review 
of the spec about how to define a disk 'id':


https://review.openstack.org/#/c/357884/2/specs/ocata/approved/restore-vm-diagnostics.rst@140

The existing diagnostics code doesn't set a disk id in the list of disk 
dicts, but I think with at least libvirt we can set that to the target 
device from the disk device xml.


The xenapi code for getting this info is a bit confusing for me at 
least, but it looks like it's possible to get the disks, but the id 
might need to be parsed out (as a side note, it looks like the 
cpu/memory/disk diagnostics are not even populated in the 
get_instance_diagnostics method for xen).


vmware is in the same boat as xen, it's not fully implemented:

https://github.com/openstack/nova/blob/64cbd7c51a5a82b965dab53eccfaecba45be9c27/nova/virt/vmwareapi/vmops.py#L1561

Hyper-v and Ironic virt drivers haven't implemented 
get_instance_diagnostics yet.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [Security] Picking a new tag

[Ian Cordasco]

During the OpenStack Security Project (OSSP) meeting today we
discussed the fact that some MUAs don't filter the "[Security]" tag
very well and this causes a bit of an overload for people trying to
follow the internal workings of the OSSP. We were briefly side-tracked
trying to come up with a different tag that would be less likely to
cause false positives with filtering.

This also seemed like a good opportunity to use the mailing list to
come up with our new tag, since we've had such an atrocious time using
it in the past.

Some of the suggestions I recall from the meeting include:

- OSSP
- openstack-sec

I think we'd want to keep "openstack" out of our tag name, so maybe

- sec-project
- security-project

Thoughts?

-- 
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] [vote][kolla] deprecation for debian distro support

[Steven Dake (stdake)]

Michal,

I don’t think setting a gate expectation on upstream distros is appropriate 
considering our plans to expand our CI coverage.  This would present a mission 
impossible to the debian maintainers in Kolla.

We want to preserve choice, and locking out an upstream disro because of a lack 
of CI coverage is a bit onerous.  I think the bar we should is:

“Are people working to maintain the implementation?”

Regards
-steve

On 9/22/16, 7:42 AM, "Michał Jastrzębski"  wrote:

I'm also reluctant to deprecation of debian.There are few changes to
ubuntu and it might just work:) However, I'd love to ask whoever would
like us to keep using debian to create gates for it.

I would like to give debian one more release to go and deprecate it if
we fail to create gates in Ocata timeframe, how about that?

On 22 September 2016 at 06:48, Martin André  wrote:
> I'm -1 on deprecating Debian base image considering it's a recent
> addition to Kolla and we can legitimately assume the person who
> contributed it had plans to use it. I would love to get Benedikt’s
> input.
>
> Martin
>
> On Tue, Sep 20, 2016 at 7:27 PM, Steven Dake (stdake)  
wrote:
>> Matthias,
>>
>>
>>
>> I was asked why this is so by a different person.  The reason is 
determining
>> majority is impossible if the electorate isn’t well defined in advance of
>> the vote.  In this case, the electorate is the core team who were 
selected
>> by their peers to serve as the leadership of the project.  We could 
correct
>> this deficiency by holding votes across all contributors for the last 
year.
>> The authorized votes for the PTL election [1] for Kolla Newton were 114
>> people, and 69 voted.
>>
>>
>>
>> The PTL election was a major vote – not something simple like a 
deprecation
>> vote.  Yet 60% of eligible voters voted.  Using this mechanism would 
result
>> in an inability to obtain a majority on any issue in my opinion, would be
>> more heavyweight, and require a whole lot more work, and finally slow 
down
>> decision making processes.
>>
>>
>>
>> We vote on proposals such as this to remove logjams (if there are any to 
be
>> removed) and we want it to be lightweight.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>>
>>
>> From: Steven Dake 
>> Date: Tuesday, September 20, 2016 at 8:32 AM
>>
>>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
>> support
>>
>>
>>
>> Mathias,
>>
>>
>>
>> Thank you for voicing your opinion (and anyone is welcome to do that in
>> Kolla), however, core reviewer votes are the only binding votes in the
>> decision making process.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>> From: Mathias Ewald 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, September 20, 2016 at 7:25 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
>> support
>>
>>
>>
>> Option 2
>>
>>
>>
>> 2016-09-20 16:07 GMT+02:00 Steven Dake (stdake) :
>>
>> Consider this a reversal of my vote for Debian deprecation.
>>
>> Swapnil, thanks for bringing this fact to our attention.  It was missing
>> from the original vote.  I don’t know why I didn’t bring up Benedikt’s
>> contributions (which were substantial) just as Paul’s were substantial 
for
>> Oracle Linux.  I guess the project is too busy for me to keep all the
>> context in my brain.  The fact that there is no debian gate really is
>> orthogonal to the discussion in my mind.  With this action we would be
>> turning away a contributor who has made real contributions, and send the
>> signal his work doesn’t matter or fit in with the project plans.
>>
>> This is totally the wrong message to send.  Further others might 
interpret
>> such an act as a “we don’t care about anyone’s contributions” which is 
not
>> the culture we have cultivated since origination of the project.  We have
>> built a culture of “you build it, we will accept it once it passes 
review”.
>> We want to hold on to that – it’s a really good thing for Kolla.  There 
have
>> been rumblings in this thread and on irc of the expanding support matrix 
and
>> our (lack) of dealing with it appropriately.  I think there are other 

[openstack-dev] [release] Release countdown for week R-1, 26-30 Sept

[Doug Hellmann]

Focus
-

All teams should be working on release-critical bugs before the final
release.

General Notes
-

29 Sept is the deadline for new release candidates or releases from
intermediary projects. After that point we will enter a quiet period
before tagging the last release candidates as final releases on 6 Oct.

Release Actions
---

Projects not following the milestone-based release model who want
stable/newton branches created should talk to the release team about
their needs. Remember, we always create stable branches from tagged
commits, so we need the tag to exist before we branch.

Watch for translation patches and merge them quickly to ensure we have
as many user-facing strings translated as possible in the release
candidates. If your project has already been branched, make sure those
patches are also applied to the stable branch.

Liaisons for projects with independent deliverables should import the
release history by preparing patches to openstack/releases.

Important Dates
---

Newton Last RC, 29 Sept.

Newton Final Release, 6 Oct.

Newton release schedule: http://releases.openstack.org/newton/schedule.html

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

Re: [openstack-dev] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[Emilien Macchi]

On Thu, Sep 22, 2016 at 1:40 PM, Steven Hardy  wrote:
> On Thu, Sep 22, 2016 at 04:36:30PM +0200, Gabriele Cerami wrote:
>> Hi,
>>
>> As reported on this bug
>>
>> https://bugs.launchpad.net/tripleo/+bug/1626483
>>
>> HA gate and periodic jobs for master and sometimes newton started to
>> fail for errors related to memory shortage. Memory on undercloud
>> instance was increased to 8G less than a month ago, so the problem
>> needs a different approach to be solved.
>>
>> We have some solutions in store. However, with the release date so
>> close, I don't think it's time for this kind of changes. So I thought
>> it could be a good compromise to temporarily increase the undercloud
>> instance memory to 12G, just for this week, unless there's a rapid way
>> to reduce memory footprint for heat-engine (usually the biggest memory
>> consumer on the undercloud instance)
>
> If we can avoid it, I'd rather we avoided increasing the ram again - I
> suspect there is an issue with a heat regression as I'm seeing much higher
> memory usage in my local test environment too.
>
> I did a quick re-test of some local monitoring I did earlier in the cycle
> when we experienced some high memory usage:
>
> http://people.redhat.com/~shardy/heat/plots/heat_before_after_end_newton.png
>
> There are three plots there, one early in the cycle, one after some fixes
> which reduced memory usage a lot, then the highest leaky plot is the one I
> just did today.
>
> So I'm pretty sure we have another heat memory leak to track down.
>
> If anyone has any historical data of memory usage e.g from periodic CI
> runs, that would be helpful, otherwise we'll have to bisect testing locally
> or derive it from scraping our dstat data from CI run logs.
>
> Steve.

Steve, I dropped a comment in your Heat bug report, that might be
related to our CI problem:
https://bugs.launchpad.net/heat/+bug/1626675/comments/1

I hope it helps,
-- 
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] [ptl] code churn and questionable changes

[Jeremy Stanley]

On 2016-09-22 08:55:04 -0700 (-0700), Joshua Harlow wrote:
[...]
> And yes I understand it's not always easy, and some of it can be a PITA
> based on (new) contributors experience (or lack of) and so on and so forth
> but that's the way the world works folks (and everyone was likely
> inexperienced at some time in their life...)

Anyone who doesn't _still_ feel like they're inexperienced from time
to time isn't human. ;)
-- 
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] [ironic] Next API meeting cancelled

[Devananda van der Veen]

Considering I'm the only one currently working on it / bringing up new topics, I
think biweekly is a better match to the pace I'm working on this.

However, I hope that changes after the summit / once we start implementing these
changes.

--d

On 09/22/2016 08:38 AM, Jim Rollenhagen wrote:
> We decided in the last meeting to cancel next week's meeting. So we'll
> meet again October 4.
> 
> Side question: should we just make this meeting biweekly always?
> 
> // 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] [ptl] code churn and questionable changes

[Joshua Harlow]

Gotcha, thanks for the clarification :)

-Josh

Amrith Kumar wrote:

Joshua,

I think Steve and you may be missing the point of my email. It *IS* because I 
want to be open and inviting that I even asked the question, and what I'm 
asking for is how to deal with it.

All Steve says is " The fact that a new-to-openstack contributor would make such and 
error doesn’t warrant such a negative response even if it a hassle for the various PTLs 
and core reviewer teams to deal with".

I'm not proposing a negative response, I'm asking how to deal with it.

What, for example, does one do if a patch is proposed virtually identically in 
a half dozen (or two dozen) projects by someone and is totally bat-shit crazy? 
Merely -1'ing it and offering to help in a private email is not really the 
answer. I've tried it.

Having a file in the projects repo that talks about guidelines for 
contributions isn't it either. We have one of those. It is up to the 
contributor to read it; yes, I can keep pointing contributors to that but this 
is a systemic problem which I'm hoping to address.

What does one do when a contributor continually proposes one line changes that 
fix typos in comments (yes, really). At some point, these changes (while 
absolutely, and unarguably valid) begin to be a drag on the community.

What I'm asking for is something, something that may cross project boundaries, 
that will help bring contributors onto openstack, and rapidly bring them to the 
point where they are contributing at a level that materially benefits the 
project(s).

-amrith



-Original Message-
From: Joshua Harlow [mailto:harlo...@fastmail.com]
Sent: Thursday, September 22, 2016 11:55 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [ptl] code churn and questionable changes

Steven Dake (stdake) wrote:

Folks,

We want to be inviting to new contributors even if they are green.  New

contributors reflect on OpenStack’s growth in a positive way.  The fact
that a new-to-openstack contributor would make such and error doesn’t
warrant such a negative response even if it a hassle for the various PTLs
and core reviewer teams to deal with.  This is one of the many aspects of
OpenStack projects a PTL is elected to manage (mentorship).  If mentorship
isn’t in a leader’s personal mission, I’m not sure they should be leading
anything.

Regards
-steve


Well said and +100 from me :)

And yes I understand it's not always easy, and some of it can be a PITA
based on (new) contributors experience (or lack of) and so on and so
forth but that's the way the world works folks (and everyone was likely
inexperienced at some time in their life...)

-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

__
OpenStack Development Mailing 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] [all][summit][kolla] Returning one workroom session to the foundation

[Steven Dake (stdake)]

OpenStack summit planning team,

We have been planning summit for approximately 2-3 months here:
https://etherpad.openstack.org/p/kolla-O-summit-planning

We further codified this into a vote via civs:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_8368e1e74f8a0049

As you can see from the preliminary voting results, a strong majority of topics 
are of high interest to Kolla’s community of operators and developers.  We have 
no shortage of things to design and plan.  We made a request to the foundation 
for the space we thought was appropriate.  I knew Barcelona was going to be 
constrained on space when I made the room allocation request, but I wasn’t 
aware of how constrained space really was.  As a result of seeing the summit 
room allocations here:
https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458=true

I feel it is the right thing to do to return at least 1 workroom session to the 
summit organizers for use using their good judgement.  I would have liked to 
return 2 work room sessions given the space constraints in Barcelona and the 
rapidly growing nature of big tent project additions.  I feel that returning 
more than 1 would hamper our planning ability and the core team is in agreement.

The session we would like to return to the foundation is the Kolla Workroom 
Session Wednesday 3:05-3:45 session.  We have no conflicts in this time slot 
and aren’t returning it as a result of some conflict in the core team’s 
schedule that I am aware of.  I also believe the time slot and day are really 
fantastic (Wednesday – when people are fresh – 3pm after lunch settles) (from 
my 4+ years of planning summits for various projects).  My hope it is put to 
good use, perhaps to give an emerging technology project some planning time at 
summit.

I leave the decision of how the improved room availability may be used at the 
discretion of the summit organizers.  All that said, if the summit organizers 
are satisfied with the current room allocation, we will put that slot to good 
use if it can’t be used by others in the OpenStack community.

Thanks!
-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] [ptl] code churn and questionable changes

[Sean McGinnis]

On Wed, Sep 21, 2016 at 12:43:06PM +, Dolph Mathews wrote:
> 
> 
> 
> And as a general rule, there is zero benefit to filing bugs in Launchpad if
> there is no end-user impact (especially against 20+ projects). Close the
> bug as Opinion (if Launchpad hasn't already broken) and focus on the
> patches. The stakeholders for these types of change are developers reading
> and writing code, not end users, so the bug reports are superfluous.
> 

+1000

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

[openstack-dev] [new][murano] murano-pkg-check 0.1.1 release

[no-reply]

We are glowing to announce the release of:

murano-pkg-check 0.1.1: Murano package validator tool

With source available at:

http://git.openstack.org/cgit/openstack/murano-pkg-check

With package available at:

https://pypi.python.org/pypi/murano-pkg-check

Please report issues through launchpad:

http://bugs.launchpad.net/murano-pkg-check

For more details, please see below.

Changes in murano-pkg-check 0.1.0..0.1.1


5e6ae60 Introduce option only_errors
9dcc329 Add possibility to load package from open zip file
c0dbd9f Clean imports in code
c60d231 TrivialFix: Remove logging import unused
fc20354 Added functional test base
a71fe26 Added docs autogeneration for error list


Diffstat (except docs and test files)
-

.gitignore  |  1 +
muranopkgcheck/error.py |  6 ++
muranopkgcheck/manager.py   | 18 +++--
muranopkgcheck/pkg_loader.py| 10 ++-
muranopkgcheck/validators/base.py   |  2 -
setup.cfg   |  5 ++
tools/gen_errors.py | 45 
tox.ini |  4 +-
17 files changed, 306 insertions(+), 24 deletions(-)




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

Re: [openstack-dev] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[Steven Hardy]

On Thu, Sep 22, 2016 at 04:36:30PM +0200, Gabriele Cerami wrote:
> Hi,
> 
> As reported on this bug
> 
> https://bugs.launchpad.net/tripleo/+bug/1626483
> 
> HA gate and periodic jobs for master and sometimes newton started to
> fail for errors related to memory shortage. Memory on undercloud
> instance was increased to 8G less than a month ago, so the problem
> needs a different approach to be solved. 
> 
> We have some solutions in store. However, with the release date so
> close, I don't think it's time for this kind of changes. So I thought
> it could be a good compromise to temporarily increase the undercloud
> instance memory to 12G, just for this week, unless there's a rapid way
> to reduce memory footprint for heat-engine (usually the biggest memory
> consumer on the undercloud instance)

If we can avoid it, I'd rather we avoided increasing the ram again - I
suspect there is an issue with a heat regression as I'm seeing much higher
memory usage in my local test environment too.

I did a quick re-test of some local monitoring I did earlier in the cycle
when we experienced some high memory usage:

http://people.redhat.com/~shardy/heat/plots/heat_before_after_end_newton.png

There are three plots there, one early in the cycle, one after some fixes
which reduced memory usage a lot, then the highest leaky plot is the one I
just did today.

So I'm pretty sure we have another heat memory leak to track down.

If anyone has any historical data of memory usage e.g from periodic CI
runs, that would be helpful, otherwise we'll have to bisect testing locally
or derive it from scraping our dstat data from CI run logs.

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][nova] Anyone interested in writing a policy generator sphinx extension?

[Alexander Makarov]

Andrew,

the idea is to shift existing RBAC implementation:
currently policy is enforced in the service (Nova, for instance)
against the result of token validation, which is, in general, an access 
check;

I'm thinking about performing policy enforcement along with access check
in a single operation and only if necessary -
not every operation is protected and requires token validation,
though now keystone middleware validates a token on every request.

AFAIK Nova is using some custom logic to change local policies at run-time,
so I assume there may be a benefit in dynamic centralized storage 
managed via API,

so that Horizon can even provide a UI for that.

There are many questions in the matter, and my main is:
if we do RBAC in OpenStack the best way?


On 21.09.2016 20:16, Andrew Laski wrote:


On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:

Andrew Laski wrote:

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.

One way to do this is to setup something like etc.d or zookeeper and
have policy files be placed into certain 'keys' in there by keystone,
then consuming projects would 'watch' those keys for being changed (and
get notified when they are changed); the project would then reload its
policy when the other service (keystone) write a new key/policy.

https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change

or
https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches

or (pretty sure consul has something similar),

This is pretty standard stuff folks :-/ and it's how afaik things like
https://github.com/skynetservices/skydns work (and more), and it would
avoid that 'additional latency' (unless the other service is adjusting
the policy key every millisecond, which seems sorta unreasonable).

Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
not clear to me in any of this is what's the benefit to having Keystone
as a fronted to policy configuration/changes, or be involved in any real
way with authorization decisions? What issue is being solved by getting
Keystone involved?



-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

__
OpenStack Development Mailing 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] [all][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

Today's meeting was lightly attended and somewhat short, due to scheduling 
conflicts. Thanks to those who were able attend. To those who weren't able to 
make it: we missed you. The main new area of business was a need to discuss the 
planned API usability testing at summit [7].

The meeting logs are in the usual place [5]. If you find an issue with an 
existing guideline [3] or think of one that needs to exist, make a bug [4]. 
Also, please feel free to review the bugs that are there and if you think there 
is one you can resolve, please assign yourself and make it happen. If you have 
questions, ask in the #openstack-sdks IRC channel.

# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

Nothing new in the recent past.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

Nothing new this week.

# Guidelines currently under review [6]

There are no new guidelines this week, there is one proposal open for comments 
though.

* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API WG meetings [2] to promote communication surrounding their reviews.

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

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[7]: Thread starting at 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103988.html

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

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Ian Cordasco]

 

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

Date: September 22, 2016 at 10:34:00
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [security] [salt] Removal of Security and 
OpenStackSalt project teams from the Big Tent

> Thank you for your feedback - this is first one since we joined Big Tent
> and very useful.
>  
> On 2016/09/21 17:08, Davanum Srinivas wrote:
> > Data points so far are:
> > 1. No response during Barcelona planning for rooms
> > 2. Lack of candidates for PTL election
> > 3. No activity in the releases/ repository hence no entries in
> > https://releases.openstack.org/
>  
> First releases were done during project move and it seems this was
> forgotten. Anyway there's new release planned to be done.
>  
> > 4. Meetings are not so regular?
> > http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed
> > to be weekly)
>  
> There was decreased activity last few months mostly because one of
> members who was leading these meetings temporarily disconnected from the
> project and because there wasn't anything on agenda to discuss. Still
> these meetings were taken at least 1~2x a month which seemed to be
> sufficient.
>  
> > 5. Is the specs repo really active?
> > http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
> > work being done elsewhere?
>  
> Very excessive documentation and other info is at separate developer
> pages: http://docs.openstack.org/developer/openstack-salt/
> There should be surely new record in specs after new release is made.
>  
> > 6. Is there an effort to add stuff to the CI jobs running on openstack
> > infrastructure? (can't seem to find much
> > http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config)
> >   
>  
> There are tests already doing mostly linting (running states in
> dry-run). More complex tests are in progress but it takes some time
> mostly because used technology is a little bit controversial (there's no
> usable standard in saltstack community yet).
>  
> >
> > I'll stop here and switch to #openstack-salt channel to help work you
> > all through if there is a consensus/willingness from the
> > openstack-salt team that there's significant work to be done. If you
> > think you are better off not on the governance, that would be your
> > call as well.
>  
> I think we are going to fix things, to summarize:
>  
> - make new release for Newton + update specs
> - elect new PTL
> - be more active in openstack-dev mailing list (maybe also have
> separate ML just for our team?)

Some teams have had separate mailing lists but that's never worked to help them 
integrate better with the OpenStack community. You'd better serve yourself in 
this matter if you commit to just using openstack-dev.

> If there's more we can do, we are available at Freenode/#openstack-salt.

You might also be available elsewhere as Anita has pointed out. If you want to 
be part of the Big Tent, you have to make the effort to bridge the gaps.

--  
Ian Cordasco


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

[openstack-dev] [Security] Blog Post: Maturing the security project

[Rob C]

I wrote a blog post based on the recent thread about the future of the
Security Project, it's published here:
https://openstack-security.github.io/organization/2016/09/22/maturing-the-security-project.html


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

Re: [openstack-dev] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[Brent Eagles]

Hi,

On Thu, Sep 22, 2016 at 1:48 PM, James Slagle 
wrote:

> On Thu, Sep 22, 2016 at 10:36 AM, Gabriele Cerami 
> wrote:
> > Hi,
> >
> > As reported on this bug
> >
> > https://bugs.launchpad.net/tripleo/+bug/1626483
> >
> > HA gate and periodic jobs for master and sometimes newton started to
> > fail for errors related to memory shortage. Memory on undercloud
> > instance was increased to 8G less than a month ago, so the problem
> > needs a different approach to be solved.
> >
> > We have some solutions in store. However, with the release date so
> > close, I don't think it's time for this kind of changes. So I thought
> > it could be a good compromise to temporarily increase the undercloud
> > instance memory to 12G, just for this week, unless there's a rapid way
> > to reduce memory footprint for heat-engine (usually the biggest memory
> > consumer on the undercloud instance)
> >
> > Any other ideas ?
>
> The OOM error in the bug is from overcloud-controller-0, not the
> undercloud. The overcloud nodes in OVB are still at 6GB. I think it
> would be reasonable to increase those to 8GB as well.
>
> I also noticed that there are 4 neutron-server processes despite
> having NeutronWorkers: 1 in
> https://github.com/openstack-infra/tripleo-ci/blob/master/
> test-environments/worker-config.yaml.
> If we can get that down to 1, looks like that might save around 270MB.
>
> It also looks like there are 2 nova-api workers despite having
> NovaWorkers: 1. Is that normal? Getting rid of one of them would save
> around another 140MB.
>
> --
> -- James Slagle
> --


​In the case of neutron and some of the other worker settings, we can try
using 0 instead of 1. ​

​This should prevent the spawning of a separate worker processes for
anything that is going on. IIRC, neutron server itself spawns separate API
and RPC workers.

​FWIW, I don't think '0' works for nova though. I think if you do that it
leaves it unset and it will use the service default.​

Cheers,

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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Amrith Kumar]

Joshua,

I think Steve and you may be missing the point of my email. It *IS* because I 
want to be open and inviting that I even asked the question, and what I'm 
asking for is how to deal with it.

All Steve says is " The fact that a new-to-openstack contributor would make 
such and error doesn’t warrant such a negative response even if it a hassle for 
the various PTLs and core reviewer teams to deal with".

I'm not proposing a negative response, I'm asking how to deal with it.

What, for example, does one do if a patch is proposed virtually identically in 
a half dozen (or two dozen) projects by someone and is totally bat-shit crazy? 
Merely -1'ing it and offering to help in a private email is not really the 
answer. I've tried it.

Having a file in the projects repo that talks about guidelines for 
contributions isn't it either. We have one of those. It is up to the 
contributor to read it; yes, I can keep pointing contributors to that but this 
is a systemic problem which I'm hoping to address. 

What does one do when a contributor continually proposes one line changes that 
fix typos in comments (yes, really). At some point, these changes (while 
absolutely, and unarguably valid) begin to be a drag on the community.

What I'm asking for is something, something that may cross project boundaries, 
that will help bring contributors onto openstack, and rapidly bring them to the 
point where they are contributing at a level that materially benefits the 
project(s).

-amrith


> -Original Message-
> From: Joshua Harlow [mailto:harlo...@fastmail.com]
> Sent: Thursday, September 22, 2016 11:55 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [ptl] code churn and questionable changes
> 
> Steven Dake (stdake) wrote:
> > Folks,
> >
> > We want to be inviting to new contributors even if they are green.  New
> contributors reflect on OpenStack’s growth in a positive way.  The fact
> that a new-to-openstack contributor would make such and error doesn’t
> warrant such a negative response even if it a hassle for the various PTLs
> and core reviewer teams to deal with.  This is one of the many aspects of
> OpenStack projects a PTL is elected to manage (mentorship).  If mentorship
> isn’t in a leader’s personal mission, I’m not sure they should be leading
> anything.
> >
> > Regards
> > -steve
> >
> 
> Well said and +100 from me :)
> 
> And yes I understand it's not always easy, and some of it can be a PITA
> based on (new) contributors experience (or lack of) and so on and so
> forth but that's the way the world works folks (and everyone was likely
> inexperienced at some time in their life...)
> 
> -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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[James Slagle]

On Thu, Sep 22, 2016 at 10:36 AM, Gabriele Cerami  wrote:
> Hi,
>
> As reported on this bug
>
> https://bugs.launchpad.net/tripleo/+bug/1626483
>
> HA gate and periodic jobs for master and sometimes newton started to
> fail for errors related to memory shortage. Memory on undercloud
> instance was increased to 8G less than a month ago, so the problem
> needs a different approach to be solved.
>
> We have some solutions in store. However, with the release date so
> close, I don't think it's time for this kind of changes. So I thought
> it could be a good compromise to temporarily increase the undercloud
> instance memory to 12G, just for this week, unless there's a rapid way
> to reduce memory footprint for heat-engine (usually the biggest memory
> consumer on the undercloud instance)
>
> Any other ideas ?

The OOM error in the bug is from overcloud-controller-0, not the
undercloud. The overcloud nodes in OVB are still at 6GB. I think it
would be reasonable to increase those to 8GB as well.

I also noticed that there are 4 neutron-server processes despite
having NeutronWorkers: 1 in
https://github.com/openstack-infra/tripleo-ci/blob/master/test-environments/worker-config.yaml.
If we can get that down to 1, looks like that might save around 270MB.

It also looks like there are 2 nova-api workers despite having
NovaWorkers: 1. Is that normal? Getting rid of one of them would save
around another 140MB.

-- 
-- James Slagle
--

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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Joshua Harlow]

Steven Dake (stdake) wrote:

Folks,

We want to be inviting to new contributors even if they are green.  New 
contributors reflect on OpenStack’s growth in a positive way.  The fact that a 
new-to-openstack contributor would make such and error doesn’t warrant such a 
negative response even if it a hassle for the various PTLs and core reviewer 
teams to deal with.  This is one of the many aspects of OpenStack projects a 
PTL is elected to manage (mentorship).  If mentorship isn’t in a leader’s 
personal mission, I’m not sure they should be leading anything.

Regards
-steve



Well said and +100 from me :)

And yes I understand it's not always easy, and some of it can be a PITA 
based on (new) contributors experience (or lack of) and so on and so 
forth but that's the way the world works folks (and everyone was likely 
inexperienced at some time in their life...)


-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] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[Ben Nemec]

On 09/22/2016 09:36 AM, Gabriele Cerami wrote:

Hi,

As reported on this bug

https://bugs.launchpad.net/tripleo/+bug/1626483

HA gate and periodic jobs for master and sometimes newton started to
fail for errors related to memory shortage. Memory on undercloud
instance was increased to 8G less than a month ago, so the problem
needs a different approach to be solved.


Which was a pretty significant jump for 6 GB before that.  Part of the 
motivation for going to 8 was to move us in line with the rest of the 
infra Jenkins instances, so it would not be ideal to change it again.




We have some solutions in store. However, with the release date so
close, I don't think it's time for this kind of changes. So I thought
it could be a good compromise to temporarily increase the undercloud
instance memory to 12G, just for this week, unless there's a rapid way
to reduce memory footprint for heat-engine (usually the biggest memory
consumer on the undercloud instance)


This is fine for CI and the handful of us who have beefy development 
machines, but are we really at a point now where our memory usage 
_requires_ 12 GB on the undercloud and somewhere north of 6 GB on the 
overcloud nodes (we're also getting quite a few OOMs on overcloud nodes 
in HA deployments lately, with 6 GB instances)?  For an HA deployment, 
that means 40 GB of memory just for the VMs, assuming 7 GB overcloud 
nodes.  And _that's_ without ceph or the ability to test scaleup 
or...you get the idea.


Our developer hardware situation is bad enough as it is.  Requiring a 64 
GB box just to do one of the most common deploy types feels untenable to 
me.  Would providing a worker config that reduces the number of worker 
processes be sufficient to keep us at 8 GB?  We just added a similar 
thing to tripleo-heat-templates for the overcloud, so I think that would 
be reasonable.


Mostly we have to stop bloating the memory usage of even basic 
deployments.  It took us less than a month to use up the extra 2 GB we 
gave ourselves last time.  That's not a good trend. :-/




Any other ideas ?

thanks.

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



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

Re: [openstack-dev] [ptl] code churn and questionable changes

[gordon chung]

On 22/09/2016 11:18 AM, Amrith Kumar wrote:
> [amrith] Actually, not true. Some of the changes I'm seeing are from people 
> who have a track record of these kinds of changes. And if there is a knob in 
> Launchpad somewhere, I sure as hell can't find it.

no way to block actions but as a workaround, Brian reminded me there's a 
'mute bug mail' option which will allow you to pretend like it doesn't 
exist. it'll still keep all your other subscriptions active.

cheers,

-- 
gord

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

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Anita Kuno]

On 16-09-22 11:32 AM, Filip Pytloun wrote:

If there's more we can do, we are available at Freenode/#openstack-salt.
I think this right here is your issue. Believing it is the 
responsibility of the tc or other leaders to find you. It isn't.


Be available on #openstack-dev at the very least.

Anita.

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

Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Michał Jastrzębski]

So issue is, I know of few other openstacks on k8s and everyone does
that slightly differently. So far we lack proof points and real world
data to determine best approaches to stuff. This is still not-to-well
researched field. Right now it's mostly opinions and assumptions.
We're not ready to make document without having a flame war around
it;) Not enough knowledge in our collective brains.

As for Kolla-k8s we are still deep in development, so we are free to
take best course of action we know of. We don't have any technical
debt now. Current state of stuff represents what we thing is best
approach.

There is also part that k8s is constantly growing and it lacks certain
features that created these issues in the first place, if k8s solves
them on their side, that will affect decision on our side.

Welcome to the Chaos;)

On 22 September 2016 at 09:53, Flavio Percoco  wrote:
> On 22/09/16 09:39 -0500, Michał Jastrzębski wrote:
>>
>> Flavio,
>>
>> So as you surely know k8s is an orchiestration tools, docker is
>> container engine. If you are running k8s, you still run docker:)
>
>
> I know this (although, if we really want to nitpick you could technically
> use
> something else than docker :P). In my email I mentioned that I'm interested
> in
> documenting how one would deploy OpenStack on kubernetes, which is likely
> different from how you'd deploy OpenStack on docker (or any other container
> runtime).
>
>> Kolla-kubernetes is a part of Big Tent, is project developed by Kolla
>> community and we're close to our big showdown:) Come over to our
>> session in Barcelona, in the meantime I suggest you look at
>> https://github.com/openstack/kolla-kubernetes and join us at
>> #openstack-kolla
>
>
> Thakns for the info. As I mentioned in my email, I know kolla-kubernetes,
> I've
> reviewed some specs and patches, etc. I am, however, interested in something
> different which is how you'd deploy OpenStack on k8s. Is kolla-kubernetes
> doing
> this the right way? Is there a better way to do it? These are the kind of
> things
> I'd love to document. I know some OPs have contributed to kolla-kubernetes
> too.
>
> Thanks for getting back,
> Flavio
>
>
>
>> On 22 September 2016 at 09:09, Davanum Srinivas  wrote:
>>>
>>> Flavio
>>>
>>> Please see below:
>>>
>>> On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco 
>>> wrote:

 Greetings,

 I've recently started looking into the container technologies around
 OpenStack.
 More specifically, I've been looking into the tools that allow for
 deploying
 OpenStack on containers, which is what I'm the most interested in right
 now
 as
 part of the TripleO efforts.

 I'm familiar with the Kolla project and the tools managed by this team.
 In
 fact,
 TripleO currently uses kolla images for the containerized nova-compute
 deployment.

 I am, however, looking beyond a docker based deployment. I'd like to
 explore
 in
 more depth a Kubernetes based deployment of OpenStack. I'm familiar with
 both
 kolla-kubernetes and fuel-ccp, their structure and direction*. Both
 projects
 have now advanced a bit in their implementations and made some
 decisions.

 As someone that started looking into this topic just recently, I'd love
 to
 see
 our communities collaborate more wherever possible. For example, it'd be
 great
 to see us working on a reference architecture for deploying OpenStack on
 kubernetes, letting the implementation details aside for a bit. I'd
 assume
 some
 folks have done this already and I bet we can all learn more from it if
 we
 work
 on this together.

 So, let me go ahead and ask some further questions here, I might be
 missing
 some
 history and/or context:

 - Is there any public documentation that acts as a reference
 architecture
 for
  deploying OpenStack on kubernetes?
 - Is this something the architecture working group could help with? Or
 would
 it
  be better to hijack one of kolla meetings?

 The restult I'd love to see from this collaboration is a reference
 architecture
 explaining how OpenStack should be run on Kubernetes.
>>>
>>>
>>> At this moment, fuel-ccp-* is an experiment, it's not under
>>> governance, there is no expectation of any releases, there are no
>>> specs or docs that i know of. So kolla/kolla-kubernetes is probably
>>> the best accumulator of kubernetes knowledge specifically about
>>> running openstack.
>>>
>>> Note that tcpcloud folks may also have something, but haven't seen any
>>> public information or reference architecture from them. Definitely
>>> don't know of any plans from that team as well to open up and share.
>>>
 Thanks in advance. I look forward to see us collaborate more on this
 area,
 Flavio

 * thanks to all fuel and 

[openstack-dev] [ironic] Next API meeting cancelled

[Jim Rollenhagen]

We decided in the last meeting to cancel next week's meeting. So we'll
meet again October 4.

Side question: should we just make this meeting biweekly always?

// 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] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Filip Pytloun]

Thank you for your feedback - this is first one since we joined Big Tent
and very useful.

On 2016/09/21 17:08, Davanum Srinivas wrote:
> Data points so far are:
> 1. No response during Barcelona planning for rooms
> 2. Lack of candidates for PTL election
> 3. No activity in the releases/ repository hence no entries in
> https://releases.openstack.org/

First releases were done during project move and it seems this was
forgotten. Anyway there's new release planned to be done.

> 4. Meetings are not so regular?
> http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed
> to be weekly)

There was decreased activity last few months mostly because one of
members who was leading these meetings temporarily disconnected from the
project and because there wasn't anything on agenda to discuss. Still
these meetings were taken at least 1~2x a month which seemed to be
sufficient.

> 5. Is the specs repo really active?
> http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
> work being done elsewhere?

Very excessive documentation and other info is at separate developer
pages: http://docs.openstack.org/developer/openstack-salt/
There should be surely new record in specs after new release is made.

> 6. Is there an effort to add stuff to the CI jobs running on openstack
> infrastructure? (can't seem to find much
> http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config)

There are tests already doing mostly linting (running states in
dry-run). More complex tests are in progress but it takes some time
mostly because used technology is a little bit controversial (there's no
usable standard in saltstack community yet).

> 
> I'll stop here and switch to #openstack-salt channel to help work you
> all through if there is a consensus/willingness from the
> openstack-salt team that there's significant work to be done. If you
> think you are better off not on the governance, that would be your
> call as well.

I think we are going to fix things, to summarize:

 - make new release for Newton + update specs
 - elect new PTL
 - be more active in openstack-dev mailing list (maybe also have
   separate ML just for our team?)

If there's more we can do, we are available at Freenode/#openstack-salt.

-- 
Filip Pytloun
Cloud Architect
 
[tcp ◕ cloud]
 
tcp cloud a.s.
Thamova 16, 180 00  Prague 8
 
Mobile: +420 776 004 323
E-mail: filip.pytl...@tcpcloud.eu
GPG:3802 93B1 6CA8 C7A0 695B  8B28 6808 239B 9C72 E61B
Web:http://www.opentcpcloud.org/


signature.asc
Description: 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] [ptl] code churn and questionable changes

[Doug Hellmann]

Excerpts from Amrith Kumar's message of 2016-09-22 15:18:06 +:
> 
> > -Original Message-
> > From: Boris Bobrov [mailto:bbob...@mirantis.com]
> > Sent: Wednesday, September 21, 2016 10:35 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [ptl] code churn and questionable changes
> > 
> > Hello,
> > 
> > > in addition to this, please, PLEASE stop creating 'all project bugs'. i
> > > don't want to get emails on updates to projects unrelated to the ones i
> > > care about. also, it makes updating the bug impossible because it times
> > > out. i'm too lazy to search ML but this has been raise before, please
> > stop.
> > >
> > > let's all unite together and block these patches to bring an end to it.
> > :)
> > 
> > People who contribute to OpenStack long enough already know this.
> > Usually new contributors do it. And we cannot reach out to them
> > in this mailing list. There should be a way to limit this somewhere
> > in Launchpad.
> 
> [amrith] Actually, not true. Some of the changes I'm seeing are from people 
> who have a track record of these kinds of changes. And if there is a knob in 
> Launchpad somewhere, I sure as hell can't find it.

As far as I know, there is no way to prevent someone from attaching a
project to a bug.

We could start to address the problem by documenting some bug management
best practices in the project team guide so that it's easy to leave a
comment similar to the one Sean left on the bug mentioned earlier in
this thread, but without having to repeat the same info every time. Then
we can educate individual contributors who make these sorts of changes
by referring them to the documentation.

Doug

> 
> > 
> > > On 21/09/16 07:56 AM, Amrith Kumar wrote:
> > >> Of late I've been seeing a lot of rather questionable changes that
> > >> appear to be getting blasted out across multiple projects; changes that
> > >> cause considerable code churn, and don't (IMHO) materially improve the
> > >> quality of OpenStack.
> > >>
> > >> I'd love to provide a list of the changes that triggered this email but
> > >> I know that this will result in a rat hole where we end up discussing
> > >> the merits of the individual items on the list and lose sight of the
> > >> bigger picture. That won't help address the question I have below in
> > any
> > >> way, so I'm at a disadvantage of having to describe my issue in
> > abstract
> > >> terms.
> > >>
> > >>
> > >>
> > >> Here's how I characterize these changes (changes that meet one or more
> > >> of these criteria):
> > >>
> > >>
> > >>
> > >> -Contains little of no information in the commit message (often
> > just
> > >> a single line)
> > >>
> > >> -Makes some generic statement like "Do X not Y", "Don't use Z",
> > >> "Make ABC better" with no further supporting information
> > >>
> > >> -Fail (literally) every single CI job, clearly never tested by the
> > >> developer
> > >>
> > >> -Gets blasted across many projects, literally tens with often the
> > >> same kind of questionable (often wrong) change
> > >>
> > >> -Makes a stylistic python improvement that is not enforced by any
> > >> check (causes a cottage industry of changes making the same correction
> > >> every couple of months)
> > >>
> > >> -Reverses some previous python stylistic improvement with no clear
> > >> reason (another cottage industry)
> > >>
> > >>
> > >>
> > >> I've tried to explain it to myself as enthusiasm, and a desire to
> > >> contribute aggressively; I've lapsed into cynicism at times and tried
> > to
> > >> explain it as gaming the numbers system, but all that is merely
> > >> rationalization and doesn't help.
> > >>
> > >>
> > >>
> > >> Over time, the result generally is that these developers' changes get
> > >> ignored. And that's not a good thing for the community as a whole. We
> > >> want to be a welcoming community and one which values all contributions
> > >> so I'm looking for some suggestions and guidance on how one can work
> > >> with contributors to try and improve the quality of these changes, and
> > >> help the contributor feel that their changes are valued by the project?
> > >> Other more experienced PTL's, ex-PTL's, long time open-source-community
> > >> folks, I'm seriously looking for suggestions and ideas.
> > >>
> > >>
> > >>
> > >> Any and all input is welcome, do other projects see this, how do you
> > >> handle it, is this normal, ...
> > >>
> > >>
> > >>
> > >> Thanks!
> > >>
> > >>
> > >>
> > >> -amrith
> > >>
> > >
> > > cheers,
> > >
> > 
> > __
> > OpenStack Development Mailing 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] design summit proposal deadline approaching

[Brian Rosmaita]

Quick reminder to Glancers and People Interested in Glance that the Glance
Ocata design summit session proposals close at 14:00 UTC Wednesday Sept 28
and voting closes at 13:59 UTC Thursday Sept 29 (that is, just before next
week's Glance meeting).  We'll have final discussion during the Glance
meeting on Sept 29.

The proposals and voting are taking place here:
https://etherpad.openstack.org/p/ocata-glance-summit-planning

cheers,
brian


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

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Alan Pevec]

2016-09-22 15:58 GMT+02:00 Matt Riedemann :
> 1. We don't bump minimums just because a new thing comes out in a given
> release, we only bump minimums when something that uses that dependency
> needs a higher minimum version.
>
> 2. Looking at this:
>
> https://github.com/openstack/releases/blob/master/deliverables/liberty/oslo.concurrency.yaml
>
> I read the first release of oslo.concurrency in liberty was 1.9.0, not
> 2.6.0.

I meant first after stable/liberty was branched, without bumping to
that before release we end up with a situation like this, where we
don't have a release vehicle for stable fixes in the libraries.

Cheers,
Alan

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

Re: [openstack-dev] [vote][kolla] deprecation for debian distro support

[Ryan Hallisey]

I agree with Michal and Martin. I was a little reluctant to respond here 
because the Debian additions are new, while Fedora has been around since the 
beginning and never got a ton of testing.

Berendt what's your take here?

Thanks,
Ryan 

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

Sent: Thursday, September 22, 2016 10:42:13 AM
Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
support

I'm also reluctant to deprecation of debian.There are few changes to
ubuntu and it might just work:) However, I'd love to ask whoever would
like us to keep using debian to create gates for it.

I would like to give debian one more release to go and deprecate it if
we fail to create gates in Ocata timeframe, how about that?

On 22 September 2016 at 06:48, Martin André  wrote:
> I'm -1 on deprecating Debian base image considering it's a recent
> addition to Kolla and we can legitimately assume the person who
> contributed it had plans to use it. I would love to get Benedikt’s
> input.
>
> Martin
>
> On Tue, Sep 20, 2016 at 7:27 PM, Steven Dake (stdake)  
> wrote:
>> Matthias,
>>
>>
>>
>> I was asked why this is so by a different person.  The reason is determining
>> majority is impossible if the electorate isn’t well defined in advance of
>> the vote.  In this case, the electorate is the core team who were selected
>> by their peers to serve as the leadership of the project.  We could correct
>> this deficiency by holding votes across all contributors for the last year.
>> The authorized votes for the PTL election [1] for Kolla Newton were 114
>> people, and 69 voted.
>>
>>
>>
>> The PTL election was a major vote – not something simple like a deprecation
>> vote.  Yet 60% of eligible voters voted.  Using this mechanism would result
>> in an inability to obtain a majority on any issue in my opinion, would be
>> more heavyweight, and require a whole lot more work, and finally slow down
>> decision making processes.
>>
>>
>>
>> We vote on proposals such as this to remove logjams (if there are any to be
>> removed) and we want it to be lightweight.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>>
>>
>> From: Steven Dake 
>> Date: Tuesday, September 20, 2016 at 8:32 AM
>>
>>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
>> support
>>
>>
>>
>> Mathias,
>>
>>
>>
>> Thank you for voicing your opinion (and anyone is welcome to do that in
>> Kolla), however, core reviewer votes are the only binding votes in the
>> decision making process.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>> From: Mathias Ewald 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, September 20, 2016 at 7:25 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
>> support
>>
>>
>>
>> Option 2
>>
>>
>>
>> 2016-09-20 16:07 GMT+02:00 Steven Dake (stdake) :
>>
>> Consider this a reversal of my vote for Debian deprecation.
>>
>> Swapnil, thanks for bringing this fact to our attention.  It was missing
>> from the original vote.  I don’t know why I didn’t bring up Benedikt’s
>> contributions (which were substantial) just as Paul’s were substantial for
>> Oracle Linux.  I guess the project is too busy for me to keep all the
>> context in my brain.  The fact that there is no debian gate really is
>> orthogonal to the discussion in my mind.  With this action we would be
>> turning away a contributor who has made real contributions, and send the
>> signal his work doesn’t matter or fit in with the project plans.
>>
>> This is totally the wrong message to send.  Further others might interpret
>> such an act as a “we don’t care about anyone’s contributions” which is not
>> the culture we have cultivated since origination of the project.  We have
>> built a culture of “you build it, we will accept it once it passes review”.
>> We want to hold on to that – it’s a really good thing for Kolla.  There have
>> been rumblings in this thread and on irc of the expanding support matrix and
>> our (lack) of dealing with it appropriately.  I think there are other ways
>> to solve that problem without a policy hammer.
>>
>> I added the fedora work originally along with others who have since moved on
>> to other projects.  I personally have been unsuccessful at maintaining it,
>> because of the change to DNF (And PTL is a 100% time commitment without a
>> whole lot of time for implementation work).  That said Fedora moves too fast
>> for me personally to commit to maintenance 

Re: [openstack-dev] [ptl] code churn and questionable changes

[Amrith Kumar]

> -Original Message-
> From: Boris Bobrov [mailto:bbob...@mirantis.com]
> Sent: Wednesday, September 21, 2016 10:35 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [ptl] code churn and questionable changes
> 
> Hello,
> 
> > in addition to this, please, PLEASE stop creating 'all project bugs'. i
> > don't want to get emails on updates to projects unrelated to the ones i
> > care about. also, it makes updating the bug impossible because it times
> > out. i'm too lazy to search ML but this has been raise before, please
> stop.
> >
> > let's all unite together and block these patches to bring an end to it.
> :)
> 
> People who contribute to OpenStack long enough already know this.
> Usually new contributors do it. And we cannot reach out to them
> in this mailing list. There should be a way to limit this somewhere
> in Launchpad.

[amrith] Actually, not true. Some of the changes I'm seeing are from people who 
have a track record of these kinds of changes. And if there is a knob in 
Launchpad somewhere, I sure as hell can't find it.

> 
> > On 21/09/16 07:56 AM, Amrith Kumar wrote:
> >> Of late I've been seeing a lot of rather questionable changes that
> >> appear to be getting blasted out across multiple projects; changes that
> >> cause considerable code churn, and don't (IMHO) materially improve the
> >> quality of OpenStack.
> >>
> >> I'd love to provide a list of the changes that triggered this email but
> >> I know that this will result in a rat hole where we end up discussing
> >> the merits of the individual items on the list and lose sight of the
> >> bigger picture. That won't help address the question I have below in
> any
> >> way, so I'm at a disadvantage of having to describe my issue in
> abstract
> >> terms.
> >>
> >>
> >>
> >> Here's how I characterize these changes (changes that meet one or more
> >> of these criteria):
> >>
> >>
> >>
> >> -Contains little of no information in the commit message (often
> just
> >> a single line)
> >>
> >> -Makes some generic statement like "Do X not Y", "Don't use Z",
> >> "Make ABC better" with no further supporting information
> >>
> >> -Fail (literally) every single CI job, clearly never tested by the
> >> developer
> >>
> >> -Gets blasted across many projects, literally tens with often the
> >> same kind of questionable (often wrong) change
> >>
> >> -Makes a stylistic python improvement that is not enforced by any
> >> check (causes a cottage industry of changes making the same correction
> >> every couple of months)
> >>
> >> -Reverses some previous python stylistic improvement with no clear
> >> reason (another cottage industry)
> >>
> >>
> >>
> >> I've tried to explain it to myself as enthusiasm, and a desire to
> >> contribute aggressively; I've lapsed into cynicism at times and tried
> to
> >> explain it as gaming the numbers system, but all that is merely
> >> rationalization and doesn't help.
> >>
> >>
> >>
> >> Over time, the result generally is that these developers' changes get
> >> ignored. And that's not a good thing for the community as a whole. We
> >> want to be a welcoming community and one which values all contributions
> >> so I'm looking for some suggestions and guidance on how one can work
> >> with contributors to try and improve the quality of these changes, and
> >> help the contributor feel that their changes are valued by the project?
> >> Other more experienced PTL's, ex-PTL's, long time open-source-community
> >> folks, I'm seriously looking for suggestions and ideas.
> >>
> >>
> >>
> >> Any and all input is welcome, do other projects see this, how do you
> >> handle it, is this normal, ...
> >>
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> -amrith
> >>
> >
> > cheers,
> >
> 
> __
> OpenStack Development Mailing 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] [ptl] code churn and questionable changes

[Boris Bobrov]

I agree.

I am not saying new contributors are not welcome. They are. But there
are also things that we are not comfortable with. But our leadership
cannot prevent them from making such error. There should be a way to
lure them to mentors before doing things that we consider bad.

On 09/22/2016 09:26 AM, Steven Dake (stdake) wrote:

Folks,

We want to be inviting to new contributors even if they are green.  New 
contributors reflect on OpenStack’s growth in a positive way.  The fact that a 
new-to-openstack contributor would make such and error doesn’t warrant such a 
negative response even if it a hassle for the various PTLs and core reviewer 
teams to deal with.  This is one of the many aspects of OpenStack projects a 
PTL is elected to manage (mentorship).  If mentorship isn’t in a leader’s 
personal mission, I’m not sure they should be leading anything.

Regards
-steve


On 9/21/16, 7:35 AM, "Boris Bobrov"  wrote:

Hello,

> in addition to this, please, PLEASE stop creating 'all project bugs'. i
> don't want to get emails on updates to projects unrelated to the ones i
> care about. also, it makes updating the bug impossible because it times
> out. i'm too lazy to search ML but this has been raise before, please 
stop.
>
> let's all unite together and block these patches to bring an end to it. :)

People who contribute to OpenStack long enough already know this.
Usually new contributors do it. And we cannot reach out to them
in this mailing list. There should be a way to limit this somewhere
in Launchpad.

> On 21/09/16 07:56 AM, Amrith Kumar wrote:
>> Of late I've been seeing a lot of rather questionable changes that
>> appear to be getting blasted out across multiple projects; changes that
>> cause considerable code churn, and don't (IMHO) materially improve the
>> quality of OpenStack.
>>
>> I’d love to provide a list of the changes that triggered this email but
>> I know that this will result in a rat hole where we end up discussing
>> the merits of the individual items on the list and lose sight of the
>> bigger picture. That won’t help address the question I have below in any
>> way, so I’m at a disadvantage of having to describe my issue in abstract
>> terms.
>>
>>
>>
>> Here’s how I characterize these changes (changes that meet one or more
>> of these criteria):
>>
>>
>>
>> -Contains little of no information in the commit message (often just
>> a single line)
>>
>> -Makes some generic statement like “Do X not Y”, “Don’t use Z”,
>> “Make ABC better” with no further supporting information
>>
>> -Fail (literally) every single CI job, clearly never tested by the
>> developer
>>
>> -Gets blasted across many projects, literally tens with often the
>> same kind of questionable (often wrong) change
>>
>> -Makes a stylistic python improvement that is not enforced by any
>> check (causes a cottage industry of changes making the same correction
>> every couple of months)
>>
>> -Reverses some previous python stylistic improvement with no clear
>> reason (another cottage industry)
>>
>>
>>
>> I’ve tried to explain it to myself as enthusiasm, and a desire to
>> contribute aggressively; I’ve lapsed into cynicism at times and tried to
>> explain it as gaming the numbers system, but all that is merely
>> rationalization and doesn’t help.
>>
>>
>>
>> Over time, the result generally is that these developers’ changes get
>> ignored. And that’s not a good thing for the community as a whole. We
>> want to be a welcoming community and one which values all contributions
>> so I’m looking for some suggestions and guidance on how one can work
>> with contributors to try and improve the quality of these changes, and
>> help the contributor feel that their changes are valued by the project?
>> Other more experienced PTL’s, ex-PTL’s, long time open-source-community
>> folks, I’m seriously looking for suggestions and ideas.
>>
>>
>>
>> Any and all input is welcome, do other projects see this, how do you
>> handle it, is this normal, …
>>
>>
>>
>> Thanks!
>>
>>
>>
>> -amrith
>>
>
> cheers,
>

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



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

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Kashyap Chamarthy]

On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote:
> The said patch in question fixes a CVE[x] in stable/liberty.
> 
> We currently have two options, both of them have caused an impasse with
> the Nova upstream / stable maintainers.  We've had two-ish months to
> mull over this.  I'd prefer to get this out of a limbo, & bring this to
> a logical conclusion.
> 
> The two options at hand:
> 
> (1) Nova backport from master (that also adds a check for the presence
> of 'ProcessLimits' attribute which is only present in
> oslo.concurrency>=2.6.1; and a conditional check for 'prlimit'
> parameter in qemu_img_info() method.)
> 
> https://review.openstack.org/#/c/327624/ -- "virt: set address space
> & CPU time limits when running qemu-img"

Conclusion: After discussion and analysis on this thread, especially
Tony's response here[*], we went the route of option (1) above, and it
is now merged in stable/liberty


http://git.openstack.org/cgit/openstack/nova/commit/?h=stable/liberty=6bc37dc

Jeremy said (on #openstack-stable) he's going to follow up on the bug
for the security advisory.

Thanks everyone!

[*]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104303.html

> (2) Or bump global-requirements for 'oslo.concurrency'
> 
> https://review.openstack.org/#/c/337277/5 -- Bump
> 'global-requirements' for 'oslo.concurrency' to 2.6.1
> 
> Both patches have had long (and useful) discussion about their merits /
> demerits in the review comments in context of stable backports.  If you
> have sometime, I'd recommend going through the comments in both the
> reviews provides all the context, current disagreements.
> 
> 
> 
> [x] https://bugs.launchpad.net/nova/+bug/1449062 -- 
> qemu-img calls need to be restricted by ulimit (CVE-2015-5162)

-- 
/kashyap

__
OpenStack Development Mailing List (not for 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][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Flavio Percoco]

On 22/09/16 09:39 -0500, Michał Jastrzębski wrote:

Flavio,

So as you surely know k8s is an orchiestration tools, docker is
container engine. If you are running k8s, you still run docker:)


I know this (although, if we really want to nitpick you could technically use
something else than docker :P). In my email I mentioned that I'm interested in
documenting how one would deploy OpenStack on kubernetes, which is likely
different from how you'd deploy OpenStack on docker (or any other container
runtime).


Kolla-kubernetes is a part of Big Tent, is project developed by Kolla
community and we're close to our big showdown:) Come over to our
session in Barcelona, in the meantime I suggest you look at
https://github.com/openstack/kolla-kubernetes and join us at
#openstack-kolla


Thakns for the info. As I mentioned in my email, I know kolla-kubernetes, I've
reviewed some specs and patches, etc. I am, however, interested in something
different which is how you'd deploy OpenStack on k8s. Is kolla-kubernetes doing
this the right way? Is there a better way to do it? These are the kind of things
I'd love to document. I know some OPs have contributed to kolla-kubernetes too.

Thanks for getting back,
Flavio



On 22 September 2016 at 09:09, Davanum Srinivas  wrote:

Flavio

Please see below:

On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco  wrote:

Greetings,

I've recently started looking into the container technologies around
OpenStack.
More specifically, I've been looking into the tools that allow for deploying
OpenStack on containers, which is what I'm the most interested in right now
as
part of the TripleO efforts.

I'm familiar with the Kolla project and the tools managed by this team. In
fact,
TripleO currently uses kolla images for the containerized nova-compute
deployment.

I am, however, looking beyond a docker based deployment. I'd like to explore
in
more depth a Kubernetes based deployment of OpenStack. I'm familiar with
both
kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
have now advanced a bit in their implementations and made some decisions.

As someone that started looking into this topic just recently, I'd love to
see
our communities collaborate more wherever possible. For example, it'd be
great
to see us working on a reference architecture for deploying OpenStack on
kubernetes, letting the implementation details aside for a bit. I'd assume
some
folks have done this already and I bet we can all learn more from it if we
work
on this together.

So, let me go ahead and ask some further questions here, I might be missing
some
history and/or context:

- Is there any public documentation that acts as a reference architecture
for
 deploying OpenStack on kubernetes?
- Is this something the architecture working group could help with? Or would
it
 be better to hijack one of kolla meetings?

The restult I'd love to see from this collaboration is a reference
architecture
explaining how OpenStack should be run on Kubernetes.


At this moment, fuel-ccp-* is an experiment, it's not under
governance, there is no expectation of any releases, there are no
specs or docs that i know of. So kolla/kolla-kubernetes is probably
the best accumulator of kubernetes knowledge specifically about
running openstack.

Note that tcpcloud folks may also have something, but haven't seen any
public information or reference architecture from them. Definitely
don't know of any plans from that team as well to open up and share.


Thanks in advance. I look forward to see us collaborate more on this area,
Flavio

* thanks to all fuel and kolla contributors that helped me understand better
the
 work in each of these projects and the direction they are headed
.
--
@flaper87
Flavio Percoco

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



Thanks,
Dims

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

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


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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] floating IP is DOWN

[Brian Haley]

On 09/22/2016 10:19 AM, Barber, Ofer wrote:

when i assign a floating IP to a server, i see that the status of the floating
IP is "down"

why is that so ?

*_code:_*

LOG.info("\n<== float IP address: %s and status: %s  ==>" %
(float_ip['floating_ip_address'],float_ip['status']))

*_Output:_*

<== float IP address: 10.63.101.225 and status: DOWN  ==>


I couldn't find that code anywhere, what release was this on?

From a Newton-based system created yesterday, this is the message in the 
l3-agent log when I associate a floating IP:


Floating ip 4c1b4571-a003-43f2-96a1-f7073cd1319d added, status ACTIVE

-Brian

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

Re: [openstack-dev] [Cinder] FFE request for RBD replication

[Gorka Eguileor]

On 12/09, Sean McGinnis wrote:
> On Mon, Sep 12, 2016 at 10:24:23AM +0200, Michał Dulko wrote:
> > +1, thanks for taking care of that!
> >
> > On 09/12/2016 03:35 AM, Huang Zhiteng wrote:
> > > +1 for this long-waited feature to land in Newton.
> > >
> > > On Sun, Sep 11, 2016 at 1:09 AM, Jay S. Bryant
> > > >
> > > wrote:
> > >
> > > +1 from me.  It is making good progress and is low risk.
> > >
> > > -Jay
> > >
> > >
> > >
> > > On 09/09/2016 02:32 PM, Gorka Eguileor wrote:
> > >
> > > Hi,
> > >
> > > As some of you may know, Jon Bernard (jbernard on IRC) has
> > > been working
> > > on the RBD v2.1 replication implementation [1] for a while,
> > > and we would
> > > like to request a Feature Freeze Exception for that work, as
> > > we believe
> > > it is a good candidate being a low risk change for the
> > > integrity of
> > > the existing functionality in the driver:
> > >
> > > - It's non intrusive if it's not enabled (enabled using
> > >replication_device configuration option).
> > > - It doesn't affect existing deployments (disabled by default).
> > > - Changes are localized to the driver itself (rbd.py) and the
> > > driver
> > >unit tests file (test_rbd.py).
>
> This looks fine to me. My only concern is the risk accepting it would
> introduce, but as you point out that risk is low and should be well
> contained. I think it should be fine to still get this in.
>
>
> > >
> > > Jon would have liked to make this request himself, but due to the
> > > untimely arrival of his newborn baby this is not possible.
> > >
> > > For obvious reasons Jon will not be available for a little
> > > while, but
> > > this will not be a problem, as I am well acquainted with the
> > > code -and
> > > I'll be able to reach Jon if necessary- and will be taking
> > > care of the
> > > final steps of the review process of his patch: replying to
> > > comments in
> > > a timely fashion, making changes to the code as required, and
> > > answering
> > > pings on IRC regarding the patch.
> > >
> > > Since some people may be interested in testing this
> > > functionality during
> > > the reviewing process -or just for fun- I'll be publishing a
> > > post with
> > > detailed explanation on how to deploy and test this feature as
> > > well as
> > > an automated way to deploy 2 Ceph clusters -linked to be
> > > mirroring one
> > > another-, and one devstack node with everything ready to test the
> > > functionality (configuration and keys for the Ceph clusters,
> > > cinder
> > > configuration, the latest upstream patch, and a volume type
> > > with the
> > > right configuration).
> > >
> > > Please, do not hesitate to ask if there are any questions to
> > > or concerns
> > > related to this request.
> > >
> > > Thank you for taking the time to evaluate this request.
> > >
> > > Cheers,
> > > Gorka.
> > >
> > > [1]: https://review.openstack.org/333565
> > > 
> > >
> > > 
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > 
> > > 
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > 
> > > 
> > >
> > >
> > >
> > > 
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > 
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > 
> > >
> > >
> > >
> > >
> > > --
> > > Regards
> > > Huang Zhiteng
> > >
> > >
> > > __
> > > OpenStack Development Mailing 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 

[openstack-dev] [heat] Jenkins Openstack Heat Plugin

[FREDERIC GILLOUARD]

Hi,

We developed a plugin jenkins to facilate the piloting of Heat API from Jenkins.
This plugin permits to generate automaticaly an ihm from the HOT template to 
populate the inputs and to get the outputs.
You can chain the differents templates, pass data between them to create 
complex infrastructure.
This plugin transforms Jenkins as an orchestrator to provide infrastructure as 
code through the Heat API.

https://wiki.jenkins-ci.org/display/JENKINS/Openstack+Heat+Plugin

Best regards,

Frédéric Gillouard

--
Ce message et  toutes les pieces jointes (ci-apres  le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute  utilisation ou  diffusion  non autorisee  est interdite.   Tout
message  etant  susceptible  d'alteration,  l'emetteur  decline  toute
responsabilite au titre de  ce message  s'il a  ete altere, deforme ou
falsifie.
---
This message and any  attachments (the "message") are confidential and
intended  solely   for  the   addressees.  Any  unauthorised   use  or
dissemination is prohibited. As e-mails are susceptible to alteration,
the issuer shall  not be  liable for  the  message if altered, changed
or falsified.

__
OpenStack Development Mailing List (not for 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][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Flavio Percoco]

On 22/09/16 10:09 -0400, Davanum Srinivas wrote:

Flavio

Please see below:

On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco  wrote:

Greetings,

I've recently started looking into the container technologies around
OpenStack.
More specifically, I've been looking into the tools that allow for deploying
OpenStack on containers, which is what I'm the most interested in right now
as
part of the TripleO efforts.

I'm familiar with the Kolla project and the tools managed by this team. In
fact,
TripleO currently uses kolla images for the containerized nova-compute
deployment.

I am, however, looking beyond a docker based deployment. I'd like to explore
in
more depth a Kubernetes based deployment of OpenStack. I'm familiar with
both
kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
have now advanced a bit in their implementations and made some decisions.

As someone that started looking into this topic just recently, I'd love to
see
our communities collaborate more wherever possible. For example, it'd be
great
to see us working on a reference architecture for deploying OpenStack on
kubernetes, letting the implementation details aside for a bit. I'd assume
some
folks have done this already and I bet we can all learn more from it if we
work
on this together.

So, let me go ahead and ask some further questions here, I might be missing
some
history and/or context:

- Is there any public documentation that acts as a reference architecture
for
 deploying OpenStack on kubernetes?
- Is this something the architecture working group could help with? Or would
it
 be better to hijack one of kolla meetings?

The restult I'd love to see from this collaboration is a reference
architecture
explaining how OpenStack should be run on Kubernetes.


At this moment, fuel-ccp-* is an experiment, it's not under
governance, there is no expectation of any releases, there are no
specs or docs that i know of. So kolla/kolla-kubernetes is probably
the best accumulator of kubernetes knowledge specifically about
running openstack.

Note that tcpcloud folks may also have something, but haven't seen any
public information or reference architecture from them. Definitely
don't know of any plans from that team as well to open up and share.


Yeah, I know all of the above, which is why I said I don't really care about the
implementation detail of things. I think the knowledge the folks in fuel-ccp
have and the knowledge folks in the kolla team have could produce a base
knowledge for folks looking into deploying OpenStack on kubernetes.

It'd be great to see this happening and I'm sure teams would benefit from it
too.

Flavio


Thanks in advance. I look forward to see us collaborate more on this area,
Flavio

* thanks to all fuel and kolla contributors that helped me understand better
the
 work in each of these projects and the direction they are headed
.
--
@flaper87
Flavio Percoco

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



Thanks,
Dims

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

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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [vote][kolla] deprecation for debian distro support

[Michał Jastrzębski]

I'm also reluctant to deprecation of debian.There are few changes to
ubuntu and it might just work:) However, I'd love to ask whoever would
like us to keep using debian to create gates for it.

I would like to give debian one more release to go and deprecate it if
we fail to create gates in Ocata timeframe, how about that?

On 22 September 2016 at 06:48, Martin André  wrote:
> I'm -1 on deprecating Debian base image considering it's a recent
> addition to Kolla and we can legitimately assume the person who
> contributed it had plans to use it. I would love to get Benedikt’s
> input.
>
> Martin
>
> On Tue, Sep 20, 2016 at 7:27 PM, Steven Dake (stdake)  
> wrote:
>> Matthias,
>>
>>
>>
>> I was asked why this is so by a different person.  The reason is determining
>> majority is impossible if the electorate isn’t well defined in advance of
>> the vote.  In this case, the electorate is the core team who were selected
>> by their peers to serve as the leadership of the project.  We could correct
>> this deficiency by holding votes across all contributors for the last year.
>> The authorized votes for the PTL election [1] for Kolla Newton were 114
>> people, and 69 voted.
>>
>>
>>
>> The PTL election was a major vote – not something simple like a deprecation
>> vote.  Yet 60% of eligible voters voted.  Using this mechanism would result
>> in an inability to obtain a majority on any issue in my opinion, would be
>> more heavyweight, and require a whole lot more work, and finally slow down
>> decision making processes.
>>
>>
>>
>> We vote on proposals such as this to remove logjams (if there are any to be
>> removed) and we want it to be lightweight.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>>
>>
>> From: Steven Dake 
>> Date: Tuesday, September 20, 2016 at 8:32 AM
>>
>>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
>> support
>>
>>
>>
>> Mathias,
>>
>>
>>
>> Thank you for voicing your opinion (and anyone is welcome to do that in
>> Kolla), however, core reviewer votes are the only binding votes in the
>> decision making process.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>> From: Mathias Ewald 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, September 20, 2016 at 7:25 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
>> support
>>
>>
>>
>> Option 2
>>
>>
>>
>> 2016-09-20 16:07 GMT+02:00 Steven Dake (stdake) :
>>
>> Consider this a reversal of my vote for Debian deprecation.
>>
>> Swapnil, thanks for bringing this fact to our attention.  It was missing
>> from the original vote.  I don’t know why I didn’t bring up Benedikt’s
>> contributions (which were substantial) just as Paul’s were substantial for
>> Oracle Linux.  I guess the project is too busy for me to keep all the
>> context in my brain.  The fact that there is no debian gate really is
>> orthogonal to the discussion in my mind.  With this action we would be
>> turning away a contributor who has made real contributions, and send the
>> signal his work doesn’t matter or fit in with the project plans.
>>
>> This is totally the wrong message to send.  Further others might interpret
>> such an act as a “we don’t care about anyone’s contributions” which is not
>> the culture we have cultivated since origination of the project.  We have
>> built a culture of “you build it, we will accept it once it passes review”.
>> We want to hold on to that – it’s a really good thing for Kolla.  There have
>> been rumblings in this thread and on irc of the expanding support matrix and
>> our (lack) of dealing with it appropriately.  I think there are other ways
>> to solve that problem without a policy hammer.
>>
>> I added the fedora work originally along with others who have since moved on
>> to other projects.  I personally have been unsuccessful at maintaining it,
>> because of the change to DNF (And PTL is a 100% time commitment without a
>> whole lot of time for implementation work).  That said Fedora moves too fast
>> for me personally to commit to maintenance there – so my vote there remains
>> unchanged.
>>
>> Regards
>> -steve
>>
>>
>>
>>
>>
>>
>> On 9/20/16, 2:34 AM, "Paul Bourke"  wrote:
>>
>> If it's the case Benedict or noone else is interested in continuing
>> Debian, I can reverse my vote. Though it seems I'll be outvoted anyway
>> ;)
>>
>> On 20/09/16 10:21, Swapnil Kulkarni wrote:
>> > On Tue, Sep 20, 2016 at 2:38 PM, Paul Bourke 
>> wrote:
>> >> -1 for deprecating Debian.
>> >>
>> >> As I mentioned in 

Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Michał Jastrzębski]

Flavio,

So as you surely know k8s is an orchiestration tools, docker is
container engine. If you are running k8s, you still run docker:)

Kolla-kubernetes is a part of Big Tent, is project developed by Kolla
community and we're close to our big showdown:) Come over to our
session in Barcelona, in the meantime I suggest you look at
https://github.com/openstack/kolla-kubernetes and join us at
#openstack-kolla

On 22 September 2016 at 09:09, Davanum Srinivas  wrote:
> Flavio
>
> Please see below:
>
> On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco  wrote:
>> Greetings,
>>
>> I've recently started looking into the container technologies around
>> OpenStack.
>> More specifically, I've been looking into the tools that allow for deploying
>> OpenStack on containers, which is what I'm the most interested in right now
>> as
>> part of the TripleO efforts.
>>
>> I'm familiar with the Kolla project and the tools managed by this team. In
>> fact,
>> TripleO currently uses kolla images for the containerized nova-compute
>> deployment.
>>
>> I am, however, looking beyond a docker based deployment. I'd like to explore
>> in
>> more depth a Kubernetes based deployment of OpenStack. I'm familiar with
>> both
>> kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
>> have now advanced a bit in their implementations and made some decisions.
>>
>> As someone that started looking into this topic just recently, I'd love to
>> see
>> our communities collaborate more wherever possible. For example, it'd be
>> great
>> to see us working on a reference architecture for deploying OpenStack on
>> kubernetes, letting the implementation details aside for a bit. I'd assume
>> some
>> folks have done this already and I bet we can all learn more from it if we
>> work
>> on this together.
>>
>> So, let me go ahead and ask some further questions here, I might be missing
>> some
>> history and/or context:
>>
>> - Is there any public documentation that acts as a reference architecture
>> for
>>  deploying OpenStack on kubernetes?
>> - Is this something the architecture working group could help with? Or would
>> it
>>  be better to hijack one of kolla meetings?
>>
>> The restult I'd love to see from this collaboration is a reference
>> architecture
>> explaining how OpenStack should be run on Kubernetes.
>
> At this moment, fuel-ccp-* is an experiment, it's not under
> governance, there is no expectation of any releases, there are no
> specs or docs that i know of. So kolla/kolla-kubernetes is probably
> the best accumulator of kubernetes knowledge specifically about
> running openstack.
>
> Note that tcpcloud folks may also have something, but haven't seen any
> public information or reference architecture from them. Definitely
> don't know of any plans from that team as well to open up and share.
>
>> Thanks in advance. I look forward to see us collaborate more on this area,
>> Flavio
>>
>> * thanks to all fuel and kolla contributors that helped me understand better
>> the
>>  work in each of these projects and the direction they are headed
>> .
>> --
>> @flaper87
>> Flavio Percoco
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[Gabriele Cerami]

Hi,

As reported on this bug

https://bugs.launchpad.net/tripleo/+bug/1626483

HA gate and periodic jobs for master and sometimes newton started to
fail for errors related to memory shortage. Memory on undercloud
instance was increased to 8G less than a month ago, so the problem
needs a different approach to be solved. 

We have some solutions in store. However, with the release date so
close, I don't think it's time for this kind of changes. So I thought
it could be a good compromise to temporarily increase the undercloud
instance memory to 12G, just for this week, unless there's a rapid way
to reduce memory footprint for heat-engine (usually the biggest memory
consumer on the undercloud instance)

Any other ideas ?

thanks.

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

[openstack-dev] floating IP is DOWN

[Barber, Ofer]

when i assign a floating IP to a server, i see that the status of the floating 
IP is "down"

why is that so ?


code:
LOG.info("\n<== float IP address: %s and status: %s  ==>" % 
(float_ip['floating_ip_address'],float_ip['status']))

Output:
<== float IP address: 10.63.101.225 and status: DOWN  ==>

Thank you,
Ofer

__
OpenStack Development Mailing List (not for 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][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Davanum Srinivas]

Flavio

Please see below:

On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco  wrote:
> Greetings,
>
> I've recently started looking into the container technologies around
> OpenStack.
> More specifically, I've been looking into the tools that allow for deploying
> OpenStack on containers, which is what I'm the most interested in right now
> as
> part of the TripleO efforts.
>
> I'm familiar with the Kolla project and the tools managed by this team. In
> fact,
> TripleO currently uses kolla images for the containerized nova-compute
> deployment.
>
> I am, however, looking beyond a docker based deployment. I'd like to explore
> in
> more depth a Kubernetes based deployment of OpenStack. I'm familiar with
> both
> kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
> have now advanced a bit in their implementations and made some decisions.
>
> As someone that started looking into this topic just recently, I'd love to
> see
> our communities collaborate more wherever possible. For example, it'd be
> great
> to see us working on a reference architecture for deploying OpenStack on
> kubernetes, letting the implementation details aside for a bit. I'd assume
> some
> folks have done this already and I bet we can all learn more from it if we
> work
> on this together.
>
> So, let me go ahead and ask some further questions here, I might be missing
> some
> history and/or context:
>
> - Is there any public documentation that acts as a reference architecture
> for
>  deploying OpenStack on kubernetes?
> - Is this something the architecture working group could help with? Or would
> it
>  be better to hijack one of kolla meetings?
>
> The restult I'd love to see from this collaboration is a reference
> architecture
> explaining how OpenStack should be run on Kubernetes.

At this moment, fuel-ccp-* is an experiment, it's not under
governance, there is no expectation of any releases, there are no
specs or docs that i know of. So kolla/kolla-kubernetes is probably
the best accumulator of kubernetes knowledge specifically about
running openstack.

Note that tcpcloud folks may also have something, but haven't seen any
public information or reference architecture from them. Definitely
don't know of any plans from that team as well to open up and share.

> Thanks in advance. I look forward to see us collaborate more on this area,
> Flavio
>
> * thanks to all fuel and kolla contributors that helped me understand better
> the
>  work in each of these projects and the direction they are headed
> .
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Thanks,
Dims

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

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

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Matt Riedemann]

On 9/22/2016 8:05 AM, Alan Pevec wrote:

We have:
 * global-requirements.txt:
origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0


But wasn't that wrong from the start?
First Liberty release of oslo.concurrency was 2.6.0 why was that not
bumped in g-r ?

Cheers,
Alan

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



Two things:

1. We don't bump minimums just because a new thing comes out in a given 
release, we only bump minimums when something that uses that dependency 
needs a higher minimum version.


2. Looking at this:

https://github.com/openstack/releases/blob/master/deliverables/liberty/oslo.concurrency.yaml

I read the first release of oslo.concurrency in liberty was 1.9.0, not 
2.6.0.


--

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] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Anita Kuno]

On 16-09-21 05:08 PM, Davanum Srinivas wrote:

Jakub,

Please see below.

On Wed, Sep 21, 2016 at 3:46 PM, Jakub Pavlik  wrote:

Hello all,

it took us 2 years of hard working to get these official. OpenStack-Salt is
now used by around 40 production deployments and it is focused very on
operation and popularity is growing. You are removing the project week after
one of top contributor announced that they will use that as part of
solution. We made a mistakes, however I do not think that is reason to
remove us. I do no think that quality of the project is measured like this.
Our PTL got ill and did not do properly his job for last 3 weeks, but this
can happen anybody.

  It is up to you. If you think that we are useless for community, then
remove us and we will have to continue outside of this community. However
growing successful use cases will not be under official openstack community,
which makes my feeling bad.

Data points so far are:
1. No response during Barcelona planning for rooms
2. Lack of candidates for PTL election
3. No activity in the releases/ repository hence no entries in
https://releases.openstack.org/
4. Meetings are not so regular?
http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed
to be weekly)
5. Is the specs repo really active?
http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
work being done elsewhere?
6. Is there an effort to add stuff to the CI jobs running on openstack
infrastructure? (can't seem to find much
http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config)

I'll stop here and switch to #openstack-salt channel to help work you
all through if there is a consensus/willingness from the
openstack-salt team that there's significant work to be done. If you
think you are better off not on the governance, that would be your
call as well.

Thanks,
Dims


Thanks,

Jakub


On 21.9.2016 21:03, Doug Hellmann wrote:

Excerpts from Filip Pytloun's message of 2016-09-21 20:36:42 +0200:

On 2016/09/21 13:23, Doug Hellmann wrote:

The idea of splitting the contributor list comes up pretty regularly
and we rehash the same suggestions each time.  Given that what we
have now worked fine for 57 of the 59 offical teams (the Astara
team knew in advance it would not have a PTL running, and Piet had
some sort of technical issue submitting his candidacy for the UX
team), I'm not yet convinced that we need to make large-scale changes
to our community communication standard practices in support of the
2 remaining teams.

That's not to say that the system we have now is perfect, but we
can't realistically support multiple systems at the same time.  We
need everyone to use the same system, otherwise we have (even more)
fragmented communication. So, we either need everyone to agree to
some new system and then have people step forward to implement it,
or we need to all agree to do our best to use the system we have
in place now.

I think it may work as is (with proper mail filters), but as someone
already
mentioned in this thread it would be better to have someone more
experienced
in Openstack community projects as a core team member or PTL to catch all
these things otherwise it may happen that inexperienced PTL/team just
miss
something like now.

If the team needs help, please ask for it. We should be able to find
someone to do a little mentoring and provide some guidance.


Still I don't think it's such a big issue to just fire project from Big
Tent -
who will benefit from that? Again someone already mentioned what will it
mean
for such team (loss of potencial developers, etc.).
Moreover for teams who are actively working on project as it seems that
both
OpenStackSalt and Security teams do.

Signing up to be a part of the big tent is not free. Membership comes
with expectations and obligations. Failing to meet those may be an
indication that the team isn't ready, or that membership is not a good
fit.


And I thought that real work on a project is our primary goal.. this
situation
is like loosing job when I left dirty coffee cup at my workspace.

I hope you consider team leadership and community participation to
be more important than your analogy implies.

Doug


Did your release liaison follow the instructions to make that happen?
http://git.openstack.org/cgit/openstack/releases/tree/README.rst

That seems to be the reason. There was new release planned with support
for
containerized deployment which would follow that guide (as first releases
were
done during/shortly after openstack-salt move to Big Tent).
As mentioned above - more experienced PTL would be helpful here and we
are
currently talking with people who could fit that position.


I see no emails tagged with [salt] on the mailing list since March of
this year, aside from this thread. Are you using a different communication
channel for team coordination? You mention IRC, but how are new contributors
expected to find you?

Yes, we are using openstack-salt 

[openstack-dev] [cinder][db] lazy loading of an attribute impossible

[Michał Dulko]

Hi,

I've just noticed another Cinder bug [1], similar to past bugs [2], [3].
All of them have a common exception causing them:

sqlalchemy.orm.exc.DetachedInstanceError: Parent instance
<{$SQLAlchemyObject} at {$MemoryLocation}> is not bound to a Session;
lazy load operation of attribute '{$ColumnName}' cannot proceed

We've normally fixed them by simply making the $ColumnName eager-loaded,
but as there's another similar bug report, I'm starting to think that we
have some issue with how we're managing our DB connections and
SQLAlchemy objects are losing their sessions too quickly, before we'll
manage to lazy-load required stuff.

I'm not too experienced with SQLAlchemy session management, so I would
welcome any help with investigation.

Thanks,
Michal


[1] https://bugs.launchpad.net/cinder/+bug/1626499
[2] https://bugs.launchpad.net/cinder/+bug/1517763
[3] https://bugs.launchpad.net/cinder/+bug/1501838

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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Ian Cordasco]

 

-Original Message-
From: Steven Dake (stdake) 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: September 22, 2016 at 01:29:14
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [ptl] code churn and questionable changes

> Folks,
>  
> We want to be inviting to new contributors even if they are green. New 
> contributors reflect  
> on OpenStack’s growth in a positive way. The fact that a new-to-openstack 
> contributor  
> would make such and error doesn’t warrant such a negative response even if it 
> a hassle  
> for the various PTLs and core reviewer teams to deal with. This is one of the 
> many aspects  
> of OpenStack projects a PTL is elected to manage (mentorship). If mentorship 
> isn’t in  
> a leader’s personal mission, I’m not sure they should be leading anything.

Mentorship is absolutely the responsibility of the core team and PTL. What is 
your preferred solution here? Would you prefer we accept patches that are not 
beneficial and cause code churn? I know of several people who often reach out 
(off list) to try to mentor these folks towards more positive and constructive 
contributions.

--  
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] Is there any reason we shouldn't remove nova.image.s3 now?

[Sean Dague]

On 09/22/2016 09:08 AM, Matt Riedemann wrote:
> On 9/22/2016 8:01 AM, Andrey Pavlov wrote:
>> I've tried to do it some time ago -
>> https://review.openstack.org/#/c/266425/
>> But I tried to remove more than s3_image
>> But there was no consensus...
>>
>> Regards,
>> Andrey.
> 
> Yeah I think we should do this incrementally so it doesn't get out of
> control in a single change. So let's start with nova/image/s3.py and the
> configuration options, then work on the DB and object layer in a follow
> up change.
> 

Ok sure, we should at least take the conf items at the same time (and
probably need a reno on the regard).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] Is there any reason we shouldn't remove nova.image.s3 now?

[Matt Riedemann]

On 9/22/2016 8:01 AM, Andrey Pavlov wrote:

I've tried to do it some time ago - https://review.openstack.org/#/c/266425/
But I tried to remove more than s3_image
But there was no consensus...

Regards,
Andrey.

On Thu, Sep 22, 2016 at 3:01 PM, Sean Dague > wrote:

On 09/22/2016 02:53 AM, Clint Byrum wrote:
> Excerpts from Matt Riedemann's message of 2016-09-21 18:43:06 -0500:
>> The s3 image configuration options were deprecated for removal in newton
>> [1].
>>
>> Clint has a patch up to remove the boto dependency from nova [2] which
>> is only used in the nova.image.s3 module.
>>
>> Rather than remove the boto dependency, I think we should just remove
>> this code. Is there any reason to not do that now that Ocata is open and
>> it's been over the requisite 3 month window of deprecation for CD shops?
>>
>> [1] https://review.openstack.org/#/c/314697/

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

>>
>
> I went ahead and updated this review to remove the code. This is
> definitely cleaner, and users of it can certainly resurrect it out of
> tree if they are in need of it.

+1 on the drop, but we should make sure to pull the related code in the
process. I left notes in the review for other things that can go.

The one open question to me, we've got a dedicated db table for
s3_images. Which, I have no idea when it was last used for anything.
What kind of warning do we need to do on a full table drop? Do we need
to handle the independently?

-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





--
Kind regards,
Andrey Pavlov.


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



Yeah I think we should do this incrementally so it doesn't get out of 
control in a single change. So let's start with nova/image/s3.py and the 
configuration options, then work on the DB and object layer in a follow 
up change.


--

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] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Alan Pevec]

> We have:
>  * global-requirements.txt:
> origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0

But wasn't that wrong from the start?
First Liberty release of oslo.concurrency was 2.6.0 why was that not
bumped in g-r ?

Cheers,
Alan

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

Re: [openstack-dev] [nova] Is there any reason we shouldn't remove nova.image.s3 now?

[Andrey Pavlov]

I've tried to do it some time ago - https://review.openstack.org/#/c/266425/
But I tried to remove more than s3_image
But there was no consensus...

Regards,
Andrey.

On Thu, Sep 22, 2016 at 3:01 PM, Sean Dague  wrote:

> On 09/22/2016 02:53 AM, Clint Byrum wrote:
> > Excerpts from Matt Riedemann's message of 2016-09-21 18:43:06 -0500:
> >> The s3 image configuration options were deprecated for removal in newton
> >> [1].
> >>
> >> Clint has a patch up to remove the boto dependency from nova [2] which
> >> is only used in the nova.image.s3 module.
> >>
> >> Rather than remove the boto dependency, I think we should just remove
> >> this code. Is there any reason to not do that now that Ocata is open and
> >> it's been over the requisite 3 month window of deprecation for CD shops?
> >>
> >> [1] https://review.openstack.org/#/c/314697/
> >> [2] https://review.openstack.org/#/c/374433/
> >>
> >
> > I went ahead and updated this review to remove the code. This is
> > definitely cleaner, and users of it can certainly resurrect it out of
> > tree if they are in need of it.
>
> +1 on the drop, but we should make sure to pull the related code in the
> process. I left notes in the review for other things that can go.
>
> The one open question to me, we've got a dedicated db table for
> s3_images. Which, I have no idea when it was last used for anything.
> What kind of warning do we need to do on a full table drop? Do we need
> to handle the independently?
>
> -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
>



-- 
Kind regards,
Andrey Pavlov.
__
OpenStack Development Mailing 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] [QA] The end-user test suite for OpenStack clusters

[Timur Nurlygayanov]

Hi team,

we have an idea to create the test suite with destructive/HA and advanced
end-user scenarios for the OpenStack clusters. This test suite will
contains advanced scenario integration tests for OpenStack clusters to make
sure that the cluster is ready for the production.

The test cases which we want to cover in this test suite:
1) All simple and advanced destructive actions, like a reboot of the nodes,
restart OpenStack services and etc. (we can probably use of-faults library
[1], which we already use in Rally)
2) All advanced test scenarios like a migration of the bunch of VMs between
nodes and booting of the VMs with large images (10+ Gb), send traffic
between VMs and in parallel restart Neutron l3 agents and etc.

The key requirements:
1) The framework should know the details of the deployments (how many nodes
we have, how to ssh to OpenStack nodes, how to restart the nodes and etc.).
This is why we don't want to add such "advanced" and HA-focused test
scenarios to Tempest.
2) We should be ready to run these tests for any clouds: DevStack clouds
(we can skip HA cases for DevStack), Fuel clouds, clouds which were
deployed by Ansible or Puppet tools.
3) This framework should allow reproduce the issue in a repeatable manner,
this is why we can't just cover all the tests with Rally load tests +
destructive plugins (we are working on this right now too to have an
ability to test HA-related scenarios under the load).

As we discussed on the OpenStack summit a year ago it is better to move
such test suite in a separate repository and this framework can became a
part of the QA (or at least BigTent) program in OpenStack.

I've created the commit to OpenStack project-config repository:
https://review.openstack.org/#/c/374667/

Could you please take a look?

We understand that it will be hard to add such test suite to the gates for
every commit in OpenStack because we will need a lot of hardware. We don't
want to add these tests to the per-commit gates for now, it is ok to run
them just once a day, for example. And we definitely need to have such test
suite to validate our own pre-production clouds.


Thank you!

[1] https://github.com/openstack/os-faults


-- 

Timur,
QA Manager
OpenStack Projects
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] [neutron] [classifier] Common Classifier + OVS Flow Management Meeting

[Duarte Cardoso, Igor]

Hi Common Classifier and OVS Flow Management community,

Cathy has kindly allowed me to drive the next common classifier/flow management 
IRC meetings.

Time, location and recurrence are unchanged, so the next meeting will be next 
Tuesday (27th September) at 17:00 UTC [1] on #openstack-meeting [2].

>From then on, we should have a meeting every 2 weeks.

Feel free to add topics to the meeting's agenda at:
https://wiki.openstack.org/w/index.php?title=Neutron/CommonFlowClassifier=edit=5


Important links about the Common Classifier / Common Classification Framework:

-  https://review.openstack.org/#/q/topic:bug/1476527

-  https://bugs.launchpad.net/networking-sfc/+bug/1476527

-  https://github.com/openstack/neutron-classifier

-  [3] included in topic above as well

Important links about OVS Flow Management:

-  https://review.openstack.org/#/q/topic:bug/1563967

-  https://bugs.launchpad.net/neutron/+bug/1563967


Specifically, the spec in [3] seems to have reached a very stable state. If you 
haven't yet reviewed it to understand if and how your use cases fit there, be 
sure to do it as soon as possible.


[1] 
http://eavesdrop.openstack.org/calendars/neutron-common-classifier-meeting.ics
[2] http://eavesdrop.openstack.org/#Neutron_Common_Classifier_meeting
[3] https://review.openstack.org/#/c/320439/

Best regards,
Igor.

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

[openstack-dev] [Neutron] Broken port rule masking: let's have it fixed?

[Inessa Vasilevskaya]

Hello,

Apologies for multiple posts, forgot to set proper subject in previous one.

I'd like to turn attention to the broken port rule masking problem [1],
which affects 2 projects so far:
neutron (mitaka+ with ovs firewall driver configuration) and
networking-ovs-dpdk [2].

To keep it short: the existing port masking implementation is broken and in
several cases it will either leave a range of ports open (causing
unrestricted access) or make some ports inaccessible (when they should be
open) because of bad tp_src value being generated.

2 solutions have been proposed so far:
* The "low-level one" with O(log n) complexity by IWAMOTO Toshihiro and me
[2]
* The "high-level one" with O(n^2) complexity by Jakub Libosvar [3]

As long as the bug looks like a security vulnerability and is kind of
critical for ovs firewall feature, maybe we should choose one algorithm to
go on with and have this fixed in Newton?

[1] https://bugs.launchpad.net/neutron/+bug/1611991
[2] https://review.openstack.org/#/c/353782/30
[3] https://review.openstack.org/#/c/353782/16

Best regards,
Inessa Vasilevskaya
__
OpenStack Development Mailing 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] when we use yum install ansible to install ansible2.1.1.0， I deploy failed with mitaka ，and actually precheck limit version to 2.0.0.

[lu . yao135]

when we use yum install ansible to install ansible2.1.1.0， I deploy 
failed with mitaka ，and actually precheck limit version to 2.0.0. 
so I want to know if kolla with mitaka suppout ansible2.1.1.0，can you 
help me？ thanks！
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][tripleo] status of tripleo-test-cloud-rh1

[James Slagle]

On Mon, Aug 8, 2016 at 1:47 PM, James Slagle  wrote:
> On Mon, Aug 8, 2016 at 1:06 PM, Jeremy Stanley  wrote:
>> On 2016-08-08 11:47:56 -0400 (-0400), James Slagle wrote:
>> [...]
>>> I suppose it's also possible that we might be pushing too strongly
>>> down the multinode path? Is the general concensus in infra that they'd
>>> like to help enable project teams to eventually add 3 and 4 (and maybe
>>> more) node multinode jobs?
>> [...]
>>
>> We've not outright rejected the idea, but do want to make sure that
>> there's been suitable due diligence done explaining how the things
>> you'll be able to test with >2 job nodes effectively can't be done
>> with <=2.
>
> Our current 2 node job uses the first node as the undercloud which
> deploys an AIO Overcloud on the 2nd node. TripleO traditionally has
> also been able to deploy standalone Compute, Cinder, Swift, and Ceph
> nodes. Additionally in this cycle, a lot of work has gone into making
> it fully customizable what services are deployed on which roles. You
> can deploy nodes that are just API services, or just a DB server, or
> rabbitmq, etc. In order to test the composability feature we need to
> deploy to more than one node.
>
> Also, we'd need at least 3 Overcloud nodes to successfully test that
> we can deploy a Pacemaker managed cluster successfully.
>
>> Also we want to be sure that projects who are interested
>> in multi-node jobs start with just 2 job nodes and get some initial
>> tests performing well and returning stable results before trying to
>> push past 2.
>
> I think that the 2 node job that we've added has been stable. We've
> worked a few issues out that we've hit depending on which cloud
> provider we land on, but generally speaking it has been very stable.
>
> We make use of the ovs_vxlan_bridge function from devstack-gate to
> configure the private networking among the nodes. I think this was a
> good first step since that has been a proven way in the devstack
> multinode jobs. I'd like to move to using TripleO's os-net-config in
> the future though, since that is the tool used in TripleO. The end
> result of the network configuration would be the same (using ovs vxlan
> bridges), we'd just use a different tool to get there.
>
> --
> -- James Slagle
> --

Reviving this thread to continue the discussion. I'd like to keep the
discussion going with hopes that we can set the stage to finalize a
plan for what we want to tackle in Ocata for tripleo-ci at the
Summit[1].

State of rh1 and rh2
==
Both rh1 and rh2 are OVB (OpenStack Virtual Baremetal) enabled
clouds[2]. OVB allows us to treat OpenStack instances as baremetal
instances for traditional tripleo-ci testing (PXE booting, etc).
Currently only rh1 is enabled in nodepool. We could re-enable rh2 if
we wanted (the previous ntp issue is resolved now).

As Paul indicated, he's done signficant work to bring these 2 clouds
in alignment with standard Infra tooling. If we wanted to move forward
with opening up these clouds to run other jobs besides tripleo-ci, we
could do that.

Multinode jobs
==
We've continued to add additional CI jobs using the multinode support
in nodepool and tripleo-ci, running on all the enabled clouds (except
rh1) in nodepool. We are still only at using 2 nodes. I'd like to add
additional jobs and increase this to 3 nodes initially (probably
deploying ceph on the additional node), and then 4 nodes for doing an
HA deployment.

Becoming 3rd party CI
=
tripleo-ci becoming 3rd party CI continues to come up in discussion. I
agree that the OVB based tripleo-ci jobs align better with the 3rd
party CI model since they do require a specially configured OpenStack
cloud. However, the previous points about opening up rh1/rh2 for non
tripleo jobs and scaling out multinode jobs muddies the water for me a
bit when this topic comes up.

Given we'd like to scale out and add more multinode jobs, I'd like to
counter that by offering some capacity back to nodepool by opening up
the rh1/rh2 clouds to all job types.

However, if tripleo-ci becomes 3rd party CI, we need some
infrastructure to run that CI on and resources to set it up and
maintain the CI tooling. At that point, the TripleO team would be
trying to maintain a 3rd party CI system, and keep 2 public clouds
running for normal infra jobs. That may be possible to do, but it is
additional commitment.

Just to be clear, I'm not trying to say that if tripleo-ci becomes 3rd
party CI, we will "just take our cloud and go home" :-). We want to be
better aligned and integrated with infra tooling and jobs. Maintaining
a 3rd party CI system and 2 public clouds integrated with Infra's CI
system is additional work though, and like a lot of project teams, we
have to prioritize and make trade offs.

Further, even if tripleo-ci becomes 3rd party CI for OVB jobs, and
there are capacity concerns about us scaling out our multinode jobs
onto the other enabled clouds in 

[openstack-dev] [new][ironic] ironic-python-agent 1.5.0 release (newton)

[no-reply]

We are grateful to announce the release of:

ironic-python-agent 1.5.0: Ironic Python Agent Ramdisk

This release is part of the newton release series.

For more details, please see below.

1.5.0
^


New Features


* Add 'vendor' and 'product' fields to interfaces data for future
  use in Ironic Inspector.

* Add a new cleaning step called "erase_devices_metadata" to the
  generic hardware manager which is responsible for destroying the
  metadata on the disk devices (partition tables, signatures, file-
  system identifications, etc...).

* Use new Ironic agent API (added in API version 1.22) when it's
  available.

* Extend the root device hints to identify whether a disk is
  rotational or not.


Bug Fixes
*

* Upon initialization of the agent, an attempt to identify and
  initialize any configured hardware iSCSI initiators is performed
  prior to detecting disks.

* Fixed incorrect invocation of "select" which could cause LLDP
  collection to hang under certain conditions.


Other Notes
***

* When building the TinyIPA ramdisk, it is now possible to enable
  SSH access to it. Use "ENABLE_SSH" and "SSH_PUBLIC_KEY" environment
  variables for that (see TinyIPA's README for more details).

Changes in ironic-python-agent 1.4.0..1.5.0
---

fe3b630 Add vendor, product to interface information
993149c Improve error message while download image
9f52f47 Update home page link in cfg file
2136ded Enable SSH access to tinyipa
e20490a Fix TINYCORE_MIRROR_URL option defaults
4298e6c Updated from global requirements
abf98ae Use namedtuple to improve code readability
ddb78ec Remove unused requirements
4facf2c Changed an assert to more specific assert method
814b60d Using assertIsNone() is preferred over assertEqual()
fb1cbbd Fix IPA for stable/mitaka with noauth mode
a0ca6ce Enforce upper-constraints when building ramdisks
95f31be Re-use API client for Heartbeat operations
e3c7f7c Updated from global requirements
4e7077f Updated from global requirements
a12f21a Update hacking test-requirement
8de195a Use upper-constraints for all tox targets
9e4b769 Build socket list right before select call
3b64950 Use CoreOS 1068.9.0
09d5d0c Fallback to the old /lookup endpoint on 401
ad79263 Minor updates to metrics documentation
5f146d4 Make code blocks real code blocks in metrics docs
09265ba Use new agent API if available
277d97b Updated from global requirements
fd87465 Add metrics support to IPA
d46f850 Updated from global requirements
d528728 Add erase_devices_metadata cleaning step
81ca8a8 Use ironic_lib's execute()
7ab53e3 Fix races in advertise_address unit tests
db4099d Fix resolv.conf in tinyipa image build
95c586a Remove discover from test-requirements
f50a14d Follow-up text changes for 327807
62743fe Update to work with latest stevedore
2e10d7b Fix doc warnings
72fc068 Updated from global requirements
5f09bd0 Small refactor in the root device loop matching logic
90424fa Handle diskless hardware connected to remote iscsi
080e413 Extend root device hints to support "rotational"
211756e Updated from global requirements


Diffstat (except docs and test files)
-

.gitignore |   3 +
Dockerfile |   5 +-
.../extract_upper_constraints_from_tox_ini.sh  |   9 ++
imagebuild/common/generate_upper_constraints.sh|  79 ++
imagebuild/coreos/docker_build.bash|   6 +-
imagebuild/coreos/version.txt  |  12 +-
imagebuild/tinyipa/README.rst  |  11 ++
imagebuild/tinyipa/build-tinyipa.sh|  13 +-
imagebuild/tinyipa/build_files/bootlocal.sh|   6 +
imagebuild/tinyipa/finalise-tinyipa.sh |  55 ++-
ironic_python_agent/agent.py   |  34 +++--
ironic_python_agent/api/controllers/root.py|   5 +-
ironic_python_agent/api/controllers/v1/command.py  |  42 +++---
ironic_python_agent/api/controllers/v1/status.py   |   8 +-
ironic_python_agent/cmd/agent.py   |   6 +-
ironic_python_agent/extensions/iscsi.py|   2 +-
ironic_python_agent/extensions/standby.py  |  15 +-
ironic_python_agent/hardware.py| 160 +++-
ironic_python_agent/inspector.py   |  13 +-
ironic_python_agent/ironic_api_client.py   | 108 ++
ironic_python_agent/netutils.py|   3 +-
ironic_python_agent/utils.py   |  22 +--
...erface_vendor_and_product-74e9815f20ee0cac.yaml |   4 +
...evice-metadata-clean-step-31b4a615c0ff7f18.yaml |   6 +
...-detection-on-diskless-hw-f27dcce3aaa35ac2.yaml |   5 +
releasenotes/notes/lldp-loop-fdfa584caf33d847.yaml |   4 +
.../notes/new-agent-api-afbe7391493749be.yaml  |   3 +
...t-device-hints-rotational-67e6e61074c26561.yaml |   4 +
.../notes/tinyipa-ssh-e8a3a01a3f3ff5f4.yaml|   6 +

[openstack-dev] [new][ironic] bifrost 2.1.0 release (newton)

[no-reply]

We are amped to announce the release of:

bifrost 2.1.0: Deployment of physical machines using OpenStack Ironic
and Ansible

This release is part of the newton release series.

For more details, please see below.

2.1.0
^

New Features

* Allows install of ironic-inspector and python-ironic-inspector-
  client from git sources and to specify source branch via env
  variables.

Changes in bifrost 2.0.0..2.1.0
---

5cdda92 Update home page link in cfg file
7b005fd bifrost-prepare-for-test-dynamic: Create known_hosts if it's not present
7fb32dd Fix unbound variable error in scripts/collect-test-info.sh
828d176 Add possibility to set source branch for ironic-inspector
9c3b203 Improve distribution detection in create_vm_nodes-for-role.sh
e1d75ca Updated from global requirements
e0fb22d Fix minor documentation issue
a3706f0 Fix log collection when VMs are created with non-default names


Diffstat (except docs and test files)
-

README.rst| 13 +++--
.../files/create_vm_nodes-for-role.sh | 19 +++
.../roles/bifrost-ironic-install/defaults/main.yml|  6 ++
.../tasks/inspector_install.yml   |  4 
.../roles/bifrost-prep-for-install/defaults/main.yml  |  6 ++
.../bifrost-prep-for-install/tasks/git_download.yaml  | 10 ++
.../bifrost-prep-for-install/tasks/local_path.yaml|  4 
.../bifrost-prepare-for-test-dynamic/tasks/main.yml   |  6 ++
playbooks/test-bifrost-dhcp.yaml  |  2 ++
playbooks/test-bifrost-dynamic.yaml   |  2 ++
playbooks/test-bifrost.yaml   |  2 ++
...c-inspector-install-from-git-d74a3ce3b1d1c87c.yaml |  5 +
requirements.txt  |  2 +-
scripts/collect-test-info.sh  | 15 ---
setup.cfg |  2 +-
15 files changed, 87 insertions(+), 11 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index a9d2be8..34e451b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ six>=1.9.0 # MIT
-PyMySQL>=0.6.2 # MIT License
+PyMySQL!=0.7.7,>=0.6.2 # MIT License



__
OpenStack Development Mailing List (not for 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] Is there any reason we shouldn't remove nova.image.s3 now?

[Sean Dague]

On 09/22/2016 02:53 AM, Clint Byrum wrote:
> Excerpts from Matt Riedemann's message of 2016-09-21 18:43:06 -0500:
>> The s3 image configuration options were deprecated for removal in newton 
>> [1].
>>
>> Clint has a patch up to remove the boto dependency from nova [2] which 
>> is only used in the nova.image.s3 module.
>>
>> Rather than remove the boto dependency, I think we should just remove 
>> this code. Is there any reason to not do that now that Ocata is open and 
>> it's been over the requisite 3 month window of deprecation for CD shops?
>>
>> [1] https://review.openstack.org/#/c/314697/
>> [2] https://review.openstack.org/#/c/374433/
>>
> 
> I went ahead and updated this review to remove the code. This is
> definitely cleaner, and users of it can certainly resurrect it out of
> tree if they are in need of it.

+1 on the drop, but we should make sure to pull the related code in the
process. I left notes in the review for other things that can go.

The one open question to me, we've got a dedicated db table for
s3_images. Which, I have no idea when it was last used for anything.
What kind of warning do we need to do on a full table drop? Do we need
to handle the independently?

-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] [vote][kolla] deprecation for fedora distro support

[Martin André]

My vote goes to option 2. It's common knowledge Kolla's Fedora base
image is in bad shape and doesn't get any attention from developers.
It's time to deprecated it.

Martin

On Mon, Sep 19, 2016 at 7:40 PM, Jeffrey Zhang  wrote:
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [vote][kolla] deprecation for debian distro support

[Martin André]

I'm -1 on deprecating Debian base image considering it's a recent
addition to Kolla and we can legitimately assume the person who
contributed it had plans to use it. I would love to get Benedikt’s
input.

Martin

On Tue, Sep 20, 2016 at 7:27 PM, Steven Dake (stdake)  wrote:
> Matthias,
>
>
>
> I was asked why this is so by a different person.  The reason is determining
> majority is impossible if the electorate isn’t well defined in advance of
> the vote.  In this case, the electorate is the core team who were selected
> by their peers to serve as the leadership of the project.  We could correct
> this deficiency by holding votes across all contributors for the last year.
> The authorized votes for the PTL election [1] for Kolla Newton were 114
> people, and 69 voted.
>
>
>
> The PTL election was a major vote – not something simple like a deprecation
> vote.  Yet 60% of eligible voters voted.  Using this mechanism would result
> in an inability to obtain a majority on any issue in my opinion, would be
> more heavyweight, and require a whole lot more work, and finally slow down
> decision making processes.
>
>
>
> We vote on proposals such as this to remove logjams (if there are any to be
> removed) and we want it to be lightweight.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
>
>
> From: Steven Dake 
> Date: Tuesday, September 20, 2016 at 8:32 AM
>
>
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
> support
>
>
>
> Mathias,
>
>
>
> Thank you for voicing your opinion (and anyone is welcome to do that in
> Kolla), however, core reviewer votes are the only binding votes in the
> decision making process.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> From: Mathias Ewald 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, September 20, 2016 at 7:25 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
> support
>
>
>
> Option 2
>
>
>
> 2016-09-20 16:07 GMT+02:00 Steven Dake (stdake) :
>
> Consider this a reversal of my vote for Debian deprecation.
>
> Swapnil, thanks for bringing this fact to our attention.  It was missing
> from the original vote.  I don’t know why I didn’t bring up Benedikt’s
> contributions (which were substantial) just as Paul’s were substantial for
> Oracle Linux.  I guess the project is too busy for me to keep all the
> context in my brain.  The fact that there is no debian gate really is
> orthogonal to the discussion in my mind.  With this action we would be
> turning away a contributor who has made real contributions, and send the
> signal his work doesn’t matter or fit in with the project plans.
>
> This is totally the wrong message to send.  Further others might interpret
> such an act as a “we don’t care about anyone’s contributions” which is not
> the culture we have cultivated since origination of the project.  We have
> built a culture of “you build it, we will accept it once it passes review”.
> We want to hold on to that – it’s a really good thing for Kolla.  There have
> been rumblings in this thread and on irc of the expanding support matrix and
> our (lack) of dealing with it appropriately.  I think there are other ways
> to solve that problem without a policy hammer.
>
> I added the fedora work originally along with others who have since moved on
> to other projects.  I personally have been unsuccessful at maintaining it,
> because of the change to DNF (And PTL is a 100% time commitment without a
> whole lot of time for implementation work).  That said Fedora moves too fast
> for me personally to commit to maintenance there – so my vote there remains
> unchanged.
>
> Regards
> -steve
>
>
>
>
>
>
> On 9/20/16, 2:34 AM, "Paul Bourke"  wrote:
>
> If it's the case Benedict or noone else is interested in continuing
> Debian, I can reverse my vote. Though it seems I'll be outvoted anyway
> ;)
>
> On 20/09/16 10:21, Swapnil Kulkarni wrote:
> > On Tue, Sep 20, 2016 at 2:38 PM, Paul Bourke 
> wrote:
> >> -1 for deprecating Debian.
> >>
> >> As I mentioned in https://review.openstack.org/#/c/369183/, Debian
> support
> >> was added incrementally by Benedikt Trefzer as recently as June. So
> it's
> >> reasonable to believe there is at least one active user of Debian.
> >>
> >> I would like to try get some input from him on whether he's still
> using it
> >> and would be interested in helping maintain by adding gates etc.
> >>
> >> On 19/09/16 18:44, Jeffrey Zhang wrote:
> >>>
> >>> Kolla core reviewer team,
> >>>
> >>> Kolla supports multiple Linux distros now, including
>  

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Kashyap Chamarthy]

On Thu, Sep 22, 2016 at 04:25:00PM +1000, Tony Breeds wrote:
> On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote:
> 
> > Well, the risk profile of what has to be changed for stable/liberty
> > (given that all the actual code is buried in libraries which have tons
> > of other changes). Special cherry-picked library versions would be
> > needed to fix this without openning up a ton of risk for breaking
> > stable/liberty badly.
> > 
> > That is the bit of work that no one seems to really have picked up.
> 
> So to clearly describe the work you touch on here:
> 
> We have:
>  * global-requirements.txt:
> origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0
>  * upper-constraints.txt
> origin/stable/liberty : oslo.concurrency===2.6.1
>  * compatible oslo.concurrency releases:
> 2.3.0, 2.4.0, 2.5.0, 2.6.0 and 2.6.1(patched)
> 
> So to be sure that all liberty consumers have a reasonably simple update we'd
> need to create:
> 2.3.1, 2.4.1 and 2.5.1
> releases of oslo.concurrency
> 
> To achieve this we'd need to create a 3 short lived feature branches in
> oslo.concurrency and (I'm guessing) some CI changes so we can merge/release
> these versions.
> 
> We'd also need to update global-requirements.txt to:
> oslo.concurrency>=2.3.1,!=2.4.0,!=2.5.0,!=2.6.0
> 
> This update would be propagated to all projects:
> 
> Package  : oslo-concurrency [oslo-concurrency>=2.3.0] (used by 30 
> projects)
> Re-Release   : 5 projects
> Included in  : 17 projects
> Also affects : 8 projects
> 
> (The expanded list is at http://paste.openstack.org/show/582499/)
> 
> I haven't looked into the state of the libraries that need a re-release, but 
> my
> guess is that they'll have knock on effects if we're going to do this 
> properly.
> 
> There's a reason we call this kind of thing a tangled web of onions.
> 
> I suppose the most flexible solution would be to:
> 
> 1. Release the .1 versions
> 2. Leave global-requirements.txt
> 2. Add the patch to nova to with with/without the fix
> 3. Write appropriate words in the OSSN/OSSA
> 
> That gives deployers plenty of packages they can work with and public 
> backports
> of the fixes.  Yes g-r would be sub-optimal but the only thing that needs the
> fix will function with any of the versions listed.

Thanks for the succint analysis, Tony, that gives a clear view of state
of affairs if we had to go with three short-lived .1 releases.  Probably
this thread needs to be referred to in the commit message.

>  Time passes 
> 
> So I checked and the cherry-picks to 2.[345].0 are trivial so I think
> I just talked myself around to taking the nova fix now we can decide
> if we do all the .1 releases later

So, given your above comment, we seem to be going with the "option (1)"
as mentioned in the original post[x] -- i.e.  merge the Nova backport.
 
Thanks for the review (and the test with 2.6.0)

[x] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104091.html

-- 
/kashyap

__
OpenStack Development Mailing List (not for 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][fuel][tripleo][openstack-ansible] Reference architecture to deploy OpenStack on k8s

[Jim Rollenhagen]

On Thu, Sep 22, 2016 at 7:04 AM, Flavio Percoco  wrote:
> Greetings,
>
> I've recently started looking into the container technologies around
> OpenStack.
> More specifically, I've been looking into the tools that allow for deploying
> OpenStack on containers, which is what I'm the most interested in right now
> as
> part of the TripleO efforts.

I don't believe they support k8s today, but openstack-ansible also deploys
in containers. :)

// jim

> I'm familiar with the Kolla project and the tools managed by this team. In
> fact,
> TripleO currently uses kolla images for the containerized nova-compute
> deployment.
>
> I am, however, looking beyond a docker based deployment. I'd like to explore
> in
> more depth a Kubernetes based deployment of OpenStack. I'm familiar with
> both
> kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
> have now advanced a bit in their implementations and made some decisions.
>
> As someone that started looking into this topic just recently, I'd love to
> see
> our communities collaborate more wherever possible. For example, it'd be
> great
> to see us working on a reference architecture for deploying OpenStack on
> kubernetes, letting the implementation details aside for a bit. I'd assume
> some
> folks have done this already and I bet we can all learn more from it if we
> work
> on this together.
>
> So, let me go ahead and ask some further questions here, I might be missing
> some
> history and/or context:
>
> - Is there any public documentation that acts as a reference architecture
> for
>  deploying OpenStack on kubernetes?
> - Is this something the architecture working group could help with? Or would
> it
>  be better to hijack one of kolla meetings?
>
> The restult I'd love to see from this collaboration is a reference
> architecture
> explaining how OpenStack should be run on Kubernetes.
>
> Thanks in advance. I look forward to see us collaborate more on this area,
> Flavio
>
> * thanks to all fuel and kolla contributors that helped me understand better
> the
>  work in each of these projects and the direction they are headed
> .
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Flavio Percoco]

Greetings,

I've recently started looking into the container technologies around OpenStack.
More specifically, I've been looking into the tools that allow for deploying
OpenStack on containers, which is what I'm the most interested in right now as
part of the TripleO efforts.

I'm familiar with the Kolla project and the tools managed by this team. In fact,
TripleO currently uses kolla images for the containerized nova-compute
deployment.

I am, however, looking beyond a docker based deployment. I'd like to explore in
more depth a Kubernetes based deployment of OpenStack. I'm familiar with both
kolla-kubernetes and fuel-ccp, their structure and direction*. Both projects
have now advanced a bit in their implementations and made some decisions.

As someone that started looking into this topic just recently, I'd love to see
our communities collaborate more wherever possible. For example, it'd be great
to see us working on a reference architecture for deploying OpenStack on
kubernetes, letting the implementation details aside for a bit. I'd assume some
folks have done this already and I bet we can all learn more from it if we work
on this together.

So, let me go ahead and ask some further questions here, I might be missing some
history and/or context:

- Is there any public documentation that acts as a reference architecture for
 deploying OpenStack on kubernetes?
- Is this something the architecture working group could help with? Or would it
 be better to hijack one of kolla meetings?

The restult I'd love to see from this collaboration is a reference architecture
explaining how OpenStack should be run on Kubernetes.

Thanks in advance. I look forward to see us collaborate more on this area,
Flavio

* thanks to all fuel and kolla contributors that helped me understand better the
 work in each of these projects and the direction they are headed
.
--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [tricircle]freeze date and patches to be merged for Newton release

[Shinobu Kinjo]

Please add 1 line above description of each patch.

MUST TO HAVE
or
GOOD TO HAVE

e.g.,
https://review.openstack.org/#/c/356187/

 MUST TO HAVE
 The framework of dynamic pod binding.

So that we can prioritize clearly and easily.

Ideally we should have made priority for each *MUST* case.

Regards,
Shinobu


On Thu, Sep 22, 2016 at 10:42 AM, joehuang  wrote:

> Hello,
>
> During yesterday's weekly meeting, patches were identified for these must
> be merged before freeze date for Newton release:
>
> Freeze date: Sept.30, 2016
>
> Must to have: must be merged before Sept.30, basic feature for Tricircle
> Newton release
> https://review.openstack.org/#/c/356187/ framework for dynamic pod binding
> https://review.openstack.org/354604 floating ip deletion
> https://review.openstack.org/355847 subnet deletion
> https://review.openstack.org/360848 router deletion
> https://review.openstack.org/#/c/366606/ server action part1
> https://review.openstack.org/#/c/369958/ server action part2
> https://review.openstack.org/#/c/372414/ installation update
> https://review.openstack.org/#/c/326192/ volume detach
>
> Good to have: best effort
> https://review.openstack.org/#/c/323687/ add resource_affinity_tag
> https://review.openstack.org/368529 spec for local plugin
> https://review.openstack.org/#/c/359561/
> others not mentioned here
>
> You can also refer to https://etherpad.openstack.
> org/p/TricircleNewtonFreeze  for the discussion log.
>
> Let's update patch and review in time to ensure "Must to have" get merged
> before freeze date Sept.30.
>
> Thank you for your great effort. The Newton branch will be created at UTC
> 9:00AM Sept.30.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [ptl] code churn and questionable changes

[Jordan Pittier]

On Thu, Sep 22, 2016 at 8:26 AM, Steven Dake (stdake) 
wrote:

> Folks,
>
> We want to be inviting to new contributors even if they are green.  New
> contributors reflect on OpenStack’s growth in a positive way.  The fact
> that a new-to-openstack contributor would make such and error doesn’t
> warrant such a negative response even if it a hassle for the various PTLs
> and core reviewer teams to deal with.  This is one of the many aspects of
> OpenStack projects a PTL is elected to manage (mentorship).  If mentorship
> isn’t in a leader’s personal mission, I’m not sure they should be leading
> anything.
>
Yeah you are right. We should be all welcoming and friendly. But please
(re)read the complains and issues that several reviewers raised in that
thread. Saying there's no problem and that core reviewers have to deal with
it is not the solution.

I've encountered most situations Amrith mentionned in his email, I feel the
same and sometimes I'am exhausted. I remember when I started contributing
to OpenStack, I never did that kind of useless patches. I think we have to
accept that some people could lack some common sense or could be a bit too
new to Python programming or too new to open source. I don"t feel bad about
ignoring these patches or auto -1/-2. I read somewhere that contributing to
opensource is a privileged not a right.



>
> Regards
> -steve
>
>
> On 9/21/16, 7:35 AM, "Boris Bobrov"  wrote:
>
> Hello,
>
> > in addition to this, please, PLEASE stop creating 'all project
> bugs'. i
> > don't want to get emails on updates to projects unrelated to the
> ones i
> > care about. also, it makes updating the bug impossible because it
> times
> > out. i'm too lazy to search ML but this has been raise before,
> please stop.
> >
> > let's all unite together and block these patches to bring an end to
> it. :)
>
> People who contribute to OpenStack long enough already know this.
> Usually new contributors do it. And we cannot reach out to them
> in this mailing list. There should be a way to limit this somewhere
> in Launchpad.
>
> > On 21/09/16 07:56 AM, Amrith Kumar wrote:
> >> Of late I've been seeing a lot of rather questionable changes that
> >> appear to be getting blasted out across multiple projects; changes
> that
> >> cause considerable code churn, and don't (IMHO) materially improve
> the
> >> quality of OpenStack.
> >>
> >> I’d love to provide a list of the changes that triggered this email
> but
> >> I know that this will result in a rat hole where we end up
> discussing
> >> the merits of the individual items on the list and lose sight of the
> >> bigger picture. That won’t help address the question I have below
> in any
> >> way, so I’m at a disadvantage of having to describe my issue in
> abstract
> >> terms.
> >>
> >>
> >>
> >> Here’s how I characterize these changes (changes that meet one or
> more
> >> of these criteria):
> >>
> >>
> >>
> >> -Contains little of no information in the commit message (often
> just
> >> a single line)
> >>
> >> -Makes some generic statement like “Do X not Y”, “Don’t use Z”,
> >> “Make ABC better” with no further supporting information
> >>
> >> -Fail (literally) every single CI job, clearly never tested by
> the
> >> developer
> >>
> >> -Gets blasted across many projects, literally tens with often
> the
> >> same kind of questionable (often wrong) change
> >>
> >> -Makes a stylistic python improvement that is not enforced by
> any
> >> check (causes a cottage industry of changes making the same
> correction
> >> every couple of months)
> >>
> >> -Reverses some previous python stylistic improvement with no
> clear
> >> reason (another cottage industry)
> >>
> >>
> >>
> >> I’ve tried to explain it to myself as enthusiasm, and a desire to
> >> contribute aggressively; I’ve lapsed into cynicism at times and
> tried to
> >> explain it as gaming the numbers system, but all that is merely
> >> rationalization and doesn’t help.
> >>
> >>
> >>
> >> Over time, the result generally is that these developers’ changes
> get
> >> ignored. And that’s not a good thing for the community as a whole.
> We
> >> want to be a welcoming community and one which values all
> contributions
> >> so I’m looking for some suggestions and guidance on how one can work
> >> with contributors to try and improve the quality of these changes,
> and
> >> help the contributor feel that their changes are valued by the
> project?
> >> Other more experienced PTL’s, ex-PTL’s, long time
> open-source-community
> >> folks, I’m seriously looking for suggestions and ideas.
> >>
> >>
> >>
> >> Any and all input is welcome, do other projects see this, how do you
> 

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 23 2016

[hu . zhijiang]

1) Roll Call
2) Core Code Abstraction
3) Bifrost/Ironic Integration
4) OPNFV: Daisy4nfv CI Framework Progress
5) Bare Metal Deployment(PXE/IPMI) Test


B.R.,
Zhijiang


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

[openstack-dev] [watcher] Barcelona design sessions

[Antoine Cabot]

Hi Watcher team,

As discussed on IRC, you are welcome to suggest topics for watcher
design sessions in Barcelona:
https://etherpad.openstack.org/p/watcher-ocata-design-session

Thanks,
Antoine

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

Re: [openstack-dev] tempest tests in Horizon GUI

[Masayuki Igawa]

Hi Ofer,

As Andrea said, Tempest shouldn't leave any test resource after a
Tempest run. And Horizon is not mandatory in a Tempest run. But if you
want to verify it, you can do that through your openstack-client or
Horizon dashboard just in case. And you can find your credentials in
your tempest.conf and accounts.yaml file.

If you want to know more details, some documents[1] might be helpful.

[1] 
http://docs.openstack.org/developer/tempest/configuration.html#tempest-configuration
.

Best Regards,
-- Masayuki Igawa


On Thu, Sep 22, 2016 at 7:27 AM, Andrea Frittoli
 wrote:
> Hi Ofer,
>
> Tempest tests try to cleanup after themselves, so in theory after a Tempest
> run you shouldn't see any test resource left around.
>
> If you run your tests using dynamic credentials, test accounts are created
> on the fly, and deleted after they're used. If you use preprovisioned
> credentials, you need to setup a network for them before the test run
> starts.
>
> Andrea
>
>
> On Thu, 22 Sep 2016, 7:02 a.m. Ken'ichi Ohmichi, 
> wrote:
>>
>> Hi Ofer,
>>
>> The scenario test of Horizon has been removed from Tempest since
>> https://review.openstack.org/#/c/313713/
>> And now the test[1] exists in openstack/tempest-horizon.
>> The test is very simple like
>>  * checks that the login page is available
>>  * logs in as a regular user
>>  * checks that the user home page loads without error
>>
>> > When I run a tempest test/scenario-test, should I see the components
>> > (network, subnet, router etc.) in the horizon GUI ?
>>
>> The test doesn't create any resources(network, subnet, etc), so any
>> changes would not happen during the test.
>>
>> Thanks
>> Ken Ohmichi
>>
>> ---
>> [1]:
>> https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py
>>
>> 2016-09-21 15:01 GMT+02:00 Barber, Ofer :
>> > I have a basic question about tempest.
>> >
>> >
>> >
>> > When I run a tempest test/scenario-test, should I see the components
>> > (network, subnet, router etc.) in the horizon GUI ?
>> >
>> >
>> >
>> > If yes, for what username or what project those are created ?
>> >
>> >
>> >
>> > Thank you,
>> >
>> > Ofer
>> >
>> >
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [neutron][stadium] Query regarding procedure for inclusion in Neutron Stadium

[reedip banerjee]

Dear Neutron Core members,

I have a query regarding the procedure for inclusion in the Neutron Stadium.
I wanted to know if a project can apply for Big Tent and Neutron Stadium
together ( means can a project be accepted in the Neutron Stadium and as a
result into the Big Tent )

I was checking out the checklist in  [1], and IMO , I think that we need to
conform to the checklist to be added to the Neutron Stadium ( along with
the other requirements  like keeping in sync with the core neutron concepts)

But IIUC, certain items in the checklist would be completed if a project is
already included in the Big Tent.

So my doubt is ,should a project apply for the Big Tent first, and after
inclusion, apply for Neutron Stadium ? Or can a project be integrated to
Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
this though)?


[1]
http://docs.openstack.org/developer/neutron/stadium/governance.html#checklist
-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Is there any reason we shouldn't remove nova.image.s3 now?

[Clint Byrum]

Excerpts from Matt Riedemann's message of 2016-09-21 18:43:06 -0500:
> The s3 image configuration options were deprecated for removal in newton 
> [1].
> 
> Clint has a patch up to remove the boto dependency from nova [2] which 
> is only used in the nova.image.s3 module.
> 
> Rather than remove the boto dependency, I think we should just remove 
> this code. Is there any reason to not do that now that Ocata is open and 
> it's been over the requisite 3 month window of deprecation for CD shops?
> 
> [1] https://review.openstack.org/#/c/314697/
> [2] https://review.openstack.org/#/c/374433/
> 

I went ahead and updated this review to remove the code. This is
definitely cleaner, and users of it can certainly resurrect it out of
tree if they are in need of it.

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

Re: [openstack-dev] [AODH] event-alarm timeout discussion

[Zhai, Edwin]

Gordon,
Thanks for your comments.
Pls. check my answer and flow chart below.

On Wed, 21 Sep 2016, gordon chung wrote:



=== event-alarm timeout implementation =
As it's for event-alarm, we need keep it as event-driven. Furthermore,
for quick response, we need use event for timeout handling. Periodic
worker can't meet real time requirement.

Separated queue for 'alarm.timeout.end'(indicates timeout expire) leads
tricky race condition.  e.g.  'XYZ.done' comes in queue1, and
'alarm.timeout.end' comes in queue2, so that they are handled in
parallel way:

1. In queue1, 'XYZ.done' is checking against alarm(current UNKNOWN), and
will be set ALARM in next step.
2. In queue2, 'alarm.timeout.end' is checking against same alarm(current
UNKNOWN), and will be set to OK(UNALARM) in next step.
3. In qeueu1, alarm transition happen: UNKNOWN => ALARM
4. In queue2, another alarm transition happen: ALARM =>OK(UNALARM)




can you clarify how this work? after user creates event timeout alarm
definition through API (i assume the alarm definition specify we should
see event x within y seconds).
- how does the evaluator get this alarm definition? is there an
alarm.timeout.start message?


Yes.


- what is this UNALARM state? to be honest, that isn't a real word so i
don't know what it's suppose to represent here.


It's OK - mean we have enough data to say: not trigger this alarm. Somebody 
mistaken it by ALARM, so I mark it as UN-ALARM.




biggest problem for me is the only thing i know is there's a
alarm.timeout.end event that needs to be handled by evaluator. i don't
know where it's coming from or what it's needed for.


I attached flow chart at bottom . pls. check it. 'timeout.end' and event 'X' 
comes in different ways, it's good if evaluator do not touch next one until 
previous one was handled.






So this alarm has bogus transition: UNKNOWN=>ALARM=>UNALARM, and tells
the user: required event came, then no required event came;

If put all events in one queue, evaluator handles them one by one(low
level oslo mesg should be multi-threaded) so that second event would see
alarm state as not UNKNOWN, and give up its transition.  As Gordc said,
it's slow. But only very small part of the event-alarm need timeout
handling, as it's only for telco usage model.


so the multithreaded part is what i was talking about. it's not handling
them one by one. it's handling 64 (or whatever the default is) at any
given time. whether its' one queue or two, you have a race to handle.


See https://github.com/openstack/aodh/blob/master/aodh/evaluator/event.py#L158

evaluate_events is the handler of the endpoint for 'alarm.all', it iterates the 
event list and evaluate them one by one with project alarms. If both 
'timeout.end' and 'X' are in the event list, I assume they are handled in 
sequence at different iterations of for loop. Am I right?


If we have evaluate_timeout_events as handler of another endpoint for 
'alarm.timeout', then 2 handlers can run concurrently to lead race condition. 
I'm not familiar with underline oslo notifications, and think separated queue is 
different story. Pls. correct me if I'm wrong.


for e in events:
try:
event = Event(e)
..

for id, alarm in six.iteritems(
self._get_project_alarms(event.project)):
try:
self._evaluate_alarm(alarm, event)
...



+--+   ++ +--+ ++  
+---+  ++
|  User|   | API server | | Notification bus | | Evaluator  |  
| Threads   |  | Alarm state|
+--+---+   +-+--+ ++-+ +-+--+  
++--+  +--+-+
   | | | |  
||
   +---> | | |  
||
   | +-+ | | |  
||
   | |Alarm create | | | |  
|+---+
   | |event: X | | | |  
|| UNKNOWN   |
   | |timeout: 5s  | | | |  
|+---+
   | +-+ | | |  
||
   | +-> |  
||
   | | +-+ | |  
||
   | | |Event sent:  | | |  
||
   |

Re: [openstack-dev] [ptl] code churn and questionable changes

[Steven Dake (stdake)]

Folks,

We want to be inviting to new contributors even if they are green.  New 
contributors reflect on OpenStack’s growth in a positive way.  The fact that a 
new-to-openstack contributor would make such and error doesn’t warrant such a 
negative response even if it a hassle for the various PTLs and core reviewer 
teams to deal with.  This is one of the many aspects of OpenStack projects a 
PTL is elected to manage (mentorship).  If mentorship isn’t in a leader’s 
personal mission, I’m not sure they should be leading anything.

Regards
-steve


On 9/21/16, 7:35 AM, "Boris Bobrov"  wrote:

Hello,

> in addition to this, please, PLEASE stop creating 'all project bugs'. i
> don't want to get emails on updates to projects unrelated to the ones i
> care about. also, it makes updating the bug impossible because it times
> out. i'm too lazy to search ML but this has been raise before, please 
stop.
>
> let's all unite together and block these patches to bring an end to it. :)

People who contribute to OpenStack long enough already know this.
Usually new contributors do it. And we cannot reach out to them
in this mailing list. There should be a way to limit this somewhere
in Launchpad.

> On 21/09/16 07:56 AM, Amrith Kumar wrote:
>> Of late I've been seeing a lot of rather questionable changes that
>> appear to be getting blasted out across multiple projects; changes that
>> cause considerable code churn, and don't (IMHO) materially improve the
>> quality of OpenStack.
>>
>> I’d love to provide a list of the changes that triggered this email but
>> I know that this will result in a rat hole where we end up discussing
>> the merits of the individual items on the list and lose sight of the
>> bigger picture. That won’t help address the question I have below in any
>> way, so I’m at a disadvantage of having to describe my issue in abstract
>> terms.
>>
>>
>>
>> Here’s how I characterize these changes (changes that meet one or more
>> of these criteria):
>>
>>
>>
>> -Contains little of no information in the commit message (often just
>> a single line)
>>
>> -Makes some generic statement like “Do X not Y”, “Don’t use Z”,
>> “Make ABC better” with no further supporting information
>>
>> -Fail (literally) every single CI job, clearly never tested by the
>> developer
>>
>> -Gets blasted across many projects, literally tens with often the
>> same kind of questionable (often wrong) change
>>
>> -Makes a stylistic python improvement that is not enforced by any
>> check (causes a cottage industry of changes making the same correction
>> every couple of months)
>>
>> -Reverses some previous python stylistic improvement with no clear
>> reason (another cottage industry)
>>
>>
>>
>> I’ve tried to explain it to myself as enthusiasm, and a desire to
>> contribute aggressively; I’ve lapsed into cynicism at times and tried to
>> explain it as gaming the numbers system, but all that is merely
>> rationalization and doesn’t help.
>>
>>
>>
>> Over time, the result generally is that these developers’ changes get
>> ignored. And that’s not a good thing for the community as a whole. We
>> want to be a welcoming community and one which values all contributions
>> so I’m looking for some suggestions and guidance on how one can work
>> with contributors to try and improve the quality of these changes, and
>> help the contributor feel that their changes are valued by the project?
>> Other more experienced PTL’s, ex-PTL’s, long time open-source-community
>> folks, I’m seriously looking for suggestions and ideas.
>>
>>
>>
>> Any and all input is welcome, do other projects see this, how do you
>> handle it, is this normal, …
>>
>>
>>
>> Thanks!
>>
>>
>>
>> -amrith
>>
>
> cheers,
>

__
OpenStack Development Mailing 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][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Tony Breeds]

On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote:

> Well, the risk profile of what has to be changed for stable/liberty
> (given that all the actual code is buried in libraries which have tons
> of other changes). Special cherry-picked library versions would be
> needed to fix this without openning up a ton of risk for breaking
> stable/liberty badly.
> 
> That is the bit of work that no one seems to really have picked up.

So to clearly describe the work you touch on here:

We have:
 * global-requirements.txt:
origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0
 * upper-constraints.txt
origin/stable/liberty : oslo.concurrency===2.6.1
 * compatible oslo.concurrency releases:
2.3.0, 2.4.0, 2.5.0, 2.6.0 and 2.6.1(patched)

So to be sure that all liberty consumers have a reasonably simple update we'd
need to create:
2.3.1, 2.4.1 and 2.5.1
releases of oslo.concurrency

To achieve this we'd need to create a 3 short lived feature branches in
oslo.concurrency and (I'm guessing) some CI changes so we can merge/release
these versions.

We'd also need to update global-requirements.txt to:
oslo.concurrency>=2.3.1,!=2.4.0,!=2.5.0,!=2.6.0

This update would be propagated to all projects:

Package  : oslo-concurrency [oslo-concurrency>=2.3.0] (used by 30 projects)
Re-Release   : 5 projects
Included in  : 17 projects
Also affects : 8 projects

(The expanded list is at http://paste.openstack.org/show/582499/)

I haven't looked into the state of the libraries that need a re-release, but my
guess is that they'll have knock on effects if we're going to do this properly.

There's a reason we call this kind of thing a tangled web of onions.

I suppose the most flexible solution would be to:

1. Release the .1 versions
2. Leave global-requirements.txt
2. Add the patch to nova to with with/without the fix
3. Write appropriate words in the OSSN/OSSA

That gives deployers plenty of packages they can work with and public backports
of the fixes.  Yes g-r would be sub-optimal but the only thing that needs the
fix will function with any of the versions listed.

 Time passes 

So I checked and the cherry-picks to 2.[345].0 are trivial so I think I just
talked myself around to taking the nova fix now we can decide if we do all the
.1 releases later

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