Re: [openstack-dev] [vitrage] vitrage topology show

[Eyal B]

I agree,

The client should pass the query

Eyal

On Tue, Apr 5, 2016 at 9:23 AM, Afek, Ifat (Nokia - IL)  wrote:

> Hi,
>
> vitrage topology show has a different behavior for a tree and a graph.
>
> In case it is called with no query:
> * For a tree it returns the node, zone, host and instances
> * For a graph it returns everything
>
> I don't think that the selected topology representation should affect the
> type of entities returned by the API. I would expect to get the same
> entities, just organized differently. However, I understand that returning
> all entities might not result in a tree structure.
>
> Maybe we force the client to call it with query, and then fail if the
> result is not a tree?
> Other thoughts?
>
> Ifat.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev][Manila] BP https://blueprints.launchpad.net/manila/+spec/access-group

[nidhi.hada]

Hi Everyone,

https://wiki.openstack.org/wiki/Manila/design/access_groups

Created a wiki page to describe different approaches, their comparison,
to achieve the goal.

It would be helpful to receive your comments, based on your experiences,
which approach suits real life needs better.

Thanks
Nidhi


From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Friday, March 25, 2016 6:14 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 

Cc: 'bswa...@netapp.com' ; 'Ben Swartzlander' 

Subject: RE: [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-group

Hi All,

A gentle reminder..

Could you please share your thoughts on the approach proposed here ..

https://etherpad.openstack.org/p/access_group_nidhimittalhada

Thanks
Nidhi











From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, March 09, 2016 2:22 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 
mailto:openstack-dev@lists.openstack.org>>
Cc: 'bswa...@netapp.com' mailto:bswa...@netapp.com>>; 'Ben 
Swartzlander' mailto:b...@swartzlander.org>>
Subject: RE: [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-groups

Hi All,

This is just a gentle reminder to the previous mail ..

PFA is revised doc.

Same is pasted here also.
https://etherpad.openstack.org/p/access_group_nidhimittalhada

Kindly share your thoughts on this..

Thanks
Nidhi



From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Friday, February 26, 2016 3:22 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 
mailto:openstack-dev@lists.openstack.org>>
Cc: 'bswa...@netapp.com' mailto:bswa...@netapp.com>>; 'Ben 
Swartzlander' mailto:b...@swartzlander.org>>
Subject: [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-groups

Hi Manila Team,

I am working on
https://blueprints.launchpad.net/manila/+spec/access-groups

For this I have created initial document as attached with the mail.
It contains DB CLI REST API related changes.

Could you please have a look and share your opinion.

Kindly let me know, if there is some understanding gap,
or something I have missed to document or
share your comments in general to make it better.

Thank you.
Nidhi Mittal Hada
Architect | PES / COE - Kolkata India
Wipro Limited
M +91 74 3910 9883 | O +91 33 3095 4767 | VOIP +91 33 3095 4767



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.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] [vitrage] vitrage topology show

[Afek, Ifat (Nokia - IL)]

Hi,

vitrage topology show has a different behavior for a tree and a graph.

In case it is called with no query:
* For a tree it returns the node, zone, host and instances 
* For a graph it returns everything 

I don't think that the selected topology representation should affect the type 
of entities returned by the API. I would expect to get the same entities, just 
organized differently. However, I understand that returning all entities might 
not result in a tree structure.

Maybe we force the client to call it with query, and then fail if the result is 
not a tree?
Other thoughts?

Ifat.



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

[openstack-dev] [cross-project] Meeting SKIPPED, Tue April 5th, 21:00 UTC

[Mike Perez]

Hi all!

We will be skipping the cross-project meeting since there are no agenda items
to discuss, but someone can add one [1] to call a meeting next time. Thanks!

[1] - 
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda

-- 
Mike Perez__
OpenStack Development Mailing List (not for 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] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jay Pipes]

On 04/04/2016 08:45 PM, Jeremy Stanley wrote:

On 2016-04-04 20:06:03 -0400 (-0400), Jay Pipes wrote:

I'm really not sure why you are being so hostile to my proposal.
Essentially, I wanted to involve the upstream Infra team in this
so they can advise on the project and ensure that the 3rd party CI
system that gets built matches what is used for the upstream
system.

I'm not trying to add load to the infra team. Quite the opposite,
I am attempting to gain a level of coordination to ensure an
aligned CI system is produced that won't be a giant pain for all
involved.


I didn't intend to come across as hostile. My concern was over what
sounded like a proposal for the OpenStack Foundation to hire some
systems administrators for the purpose of running a CI environment
to test hardware-specific features within the scope of the Infra
team. Your original suggestion[*] said things like "OpenStack
Foundation [with help] hire 2 or more systems administrators to
maintain this lab environment" and "upstream Infrastructure team
works with the hired system administrators to create a single CI
system".

If the actual proposal is for member companies to set up a CI system
using the documentation and support our community already
collectively provides to that end, I welcome their participation in
and contributions to the existing third-party CI ecosystem. If the
proposal is for integrating a hardware test environment into the
upstream CI directly, having the Infra team responsible for its care
and feeding and getting the OpenStack Foundation to dedicate staff
to that end, then my concerns stand as stated.


The proposal is to have the hardware companies donate hardware and 
sysadmins to setup and maintain a *single* third-party CI lab 
environment running the *upstream infra CI toolset* in one datacenter at 
first, moving to multiple datacenters eventually. This lab environment 
would contain hardware that the vendors intend to ensure is functionally 
tested in certain projects -- mostly Nova and Neutron around specialized 
PCI devices and SR-IOV NICs that have zero chance of being tested 
functionally in the cloudy gate CI environments.


The thing I am proposing the upstream Infra team members would be 
responsible for is guiding/advising on the creation and installation of 
the CI tools and helping to initially get the CI system reporting to the 
upstream Jenkins/Zuul system. That's it. No long-term maintenance, no 
long-term administration of the hardware in this lab environment. Just 
advice and setup help.


The vendors would continue to be responsible for keeping the CI jobs 
healthy and the lab environment up and running. It's just instead of 12 
different external CI systems, there would be 1 spawning jobs on lots of 
different types of hardware. I'm hoping that reducing the number of 
external CI systems will enable the vendors to jointly improve the 
quality of the tests because they will be able to focus on creating 
tests instead of keeping 12 different CI systems up and running.


Hope that better explains the proposal.

Best,
-jay

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

[openstack-dev] [Openstack-operators] - Containers Sessions in Austin Ops@Summit

[Gal Sagie]

Hello all,

We are going to have two sessions in the ops summit about containers
deployment with
OpenStack. (Monday, probably going to be 4:40-6:10)

In order to make these sessions useful i think the most important topic
that i want
to tackle is feedback from operators running OpenStack and containers (Bare
metal, nested containers with/without Magnum, with/without Kuryr).

Problems, use cases, networking strategy, storage, combining bare metal and
Openstack, multi tenancy networking, Kubernetes, Mesos, Swarm and more..

If you are deploying OpenStack with containers or thinking about it, or
designing solutions for
such use cases please add topics and challenges you would like to discuss
in the following etherpad:
===

https://etherpad.openstack.org/p/austin-ops-containers



Understanding use cases/challenges and real world deployments will greatly
help prioritise
tasks and features in containers related OpenStack projects, your
cooperation is appreciated.

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

Re: [openstack-dev] [mistral] Bi-weekly team meetings

[Renat Akhmerov]

Ok, thanks guys. I’m going to wait for a few more days and then aggregate all 
info.

Renat Akhmerov
@Nokia

> On 05 Apr 2016, at 09:57, Hardik Parekh  wrote:
> 
> HI,
> 
> I am ok with following timimings.
> Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
> Mon 16.00 UTC at #openstack-meeting (current time slot)
> 
> On Tue, Apr 5, 2016 at 8:26 AM, Hardik Parekh  > wrote:
> HI,
> 
> I am ok with following time.
> 
> 
> On Mon, Apr 4, 2016 at 3:45 PM, Lingxian Kong  > wrote:
> seems like only this one suits for me(UTC+12).
> 
> * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
> 
> On Mon, Apr 4, 2016 at 9:14 PM, Renat Akhmerov  > wrote:
> > Hi,
> >
> > Our team meeting time slot (Mondays 16.00 UTC) doesn’t work for lots of team
> > members well anymore. The issue is that we have team members from completely
> > time zones.
> >
> > So we came up with an idea of having bi-weekly meetings similar to how, for
> > example, Kolla team does [1]. We can decide that on odd weeks we use a time
> > slot convenient for folks in Europe/Asia and on even weeks we make it more
> > convenient for folks in North America.
> >
> > Below are the options we see
> >
> > Europe/Asia, odd weeks
> >
> > * Mon 16.00 UTC at #openstack-meeting (current time slot)
> > * Mon 15.00 UTC at #openstack-meeting-3
> >
> > North America, even weeks
> >
> > * Tue 17.00 UTC at #openstack-meeting-4
> > * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
> >
> > Please share your thoughts.
> >
> > [1] https://wiki.openstack.org/wiki/Meetings/Kolla 
> > 
> >
> > Renat Akhmerov
> > @Nokia
> >
> >
> > __
> > OpenStack Development Mailing 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!
> ---
> Lingxian Kong
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tricircle] Hello

[joehuang]

Hi, Lige,

Welcome to join Tricircle. You can start  from 
https://wiki.openstack.org/wiki/Tricircle, and the todo-list is listed in 
https://etherpad.openstack.org/p/TricircleToDo, and last week we just discussed 
the cross OpenStack  L2 networking: 
https://etherpad.openstack.org/p/TricircleCrossPodL2Networking.

You can have a look and pickup one interesting topic to work on.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 李戈 [mailto:lgmcglm...@126.com]
Sent: Tuesday, April 05, 2016 11:41 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle] Hello

Hello Team，
  I am lige, a openstack coder in China UnionPay and glad to join our team.

   thx.



__
OpenStack Development Mailing 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] Newton blueprints call for action

[Armando M.]

Hi Neutrinos,

During today's team meeting [0], we went through the current milestone
workload [1].

This is mostly made of Mitaka backlog items, amongst which we discussed two
blueprints [2, 3]. These two efforts had their spec approved during the
Mitaka timeframe, but code lagged behind, and hence got deferred [4].

I would like to understand if these need new owners (both assignees and
approvers). Code submitted [5,6] has not been touched in a while, and
whilst I appreciate people have been busy focussing on Mitaka (myself
included), the Newton master branch has been open for a while.

With this email I would like to appeal to the people in CC to report back
their interest in continuing working on these items in their respective
capacities, and/or the wider community, in case new owners need to be
identified.

I look forward to hearing back, hoping we can find the right resources to
resume progress, and bring these important requirements to completion in
time for Newton.

Many thanks,
Armando

[0]
http://eavesdrop.openstack.org/meetings/networking/2016/networking.2016-04-04-21.00.log.html
[1] https://launchpad.net/neutron/+milestone/newton-1
[2] https://blueprints.launchpad.net/neutron/+spec/fwaas-api-2.0
[3] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[4]
https://github.com/openstack/neutron-specs/tree/master/specs/backlog/mitaka
[5] https://review.openstack.org/#/q/status:open+topic:bp/vlan-aware-vms
[6] https://review.openstack.org/#/q/status:open+topic:fwaas_v2_api
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Hello

[李戈]

Hello Team，
  I am lige, a openstack coder in China UnionPay and glad to join our team.
  
   thx.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Bi-weekly team meetings

[Hardik Parekh]

HI,

I am ok with following timimings.
Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
Mon 16.00 UTC at #openstack-meeting (current time slot)

On Tue, Apr 5, 2016 at 8:26 AM, Hardik Parekh 
wrote:

> HI,
>
> I am ok with following time.
>
>
> On Mon, Apr 4, 2016 at 3:45 PM, Lingxian Kong 
> wrote:
>
>> seems like only this one suits for me(UTC+12).
>>
>> * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
>>
>> On Mon, Apr 4, 2016 at 9:14 PM, Renat Akhmerov 
>> wrote:
>> > Hi,
>> >
>> > Our team meeting time slot (Mondays 16.00 UTC) doesn’t work for lots of
>> team
>> > members well anymore. The issue is that we have team members from
>> completely
>> > time zones.
>> >
>> > So we came up with an idea of having bi-weekly meetings similar to how,
>> for
>> > example, Kolla team does [1]. We can decide that on odd weeks we use a
>> time
>> > slot convenient for folks in Europe/Asia and on even weeks we make it
>> more
>> > convenient for folks in North America.
>> >
>> > Below are the options we see
>> >
>> > Europe/Asia, odd weeks
>> >
>> > * Mon 16.00 UTC at #openstack-meeting (current time slot)
>> > * Mon 15.00 UTC at #openstack-meeting-3
>> >
>> > North America, even weeks
>> >
>> > * Tue 17.00 UTC at #openstack-meeting-4
>> > * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
>> >
>> > Please share your thoughts.
>> >
>> > [1] https://wiki.openstack.org/wiki/Meetings/Kolla
>> >
>> > Renat Akhmerov
>> > @Nokia
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing 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!
>> ---
>> Lingxian Kong
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Bi-weekly team meetings

[Hardik Parekh]

HI,

I am ok with following time.


On Mon, Apr 4, 2016 at 3:45 PM, Lingxian Kong  wrote:

> seems like only this one suits for me(UTC+12).
>
> * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
>
> On Mon, Apr 4, 2016 at 9:14 PM, Renat Akhmerov 
> wrote:
> > Hi,
> >
> > Our team meeting time slot (Mondays 16.00 UTC) doesn’t work for lots of
> team
> > members well anymore. The issue is that we have team members from
> completely
> > time zones.
> >
> > So we came up with an idea of having bi-weekly meetings similar to how,
> for
> > example, Kolla team does [1]. We can decide that on odd weeks we use a
> time
> > slot convenient for folks in Europe/Asia and on even weeks we make it
> more
> > convenient for folks in North America.
> >
> > Below are the options we see
> >
> > Europe/Asia, odd weeks
> >
> > * Mon 16.00 UTC at #openstack-meeting (current time slot)
> > * Mon 15.00 UTC at #openstack-meeting-3
> >
> > North America, even weeks
> >
> > * Tue 17.00 UTC at #openstack-meeting-4
> > * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
> >
> > Please share your thoughts.
> >
> > [1] https://wiki.openstack.org/wiki/Meetings/Kolla
> >
> > Renat Akhmerov
> > @Nokia
> >
> >
> >
> __
> > OpenStack Development Mailing 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!
> ---
> Lingxian Kong
>
> __
> OpenStack Development Mailing 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] [Tricircle] Naming convention

[Shinobu Kinjo]

Hi Chaoyi,

> In the experience of development, using full name as far as possible to 
> reduce the PEP8 naming convention prompt ion. But if the naming will make us 
> hard to write one clause less than 80 characters(ensure one clause in one 
> line), then sometimes the abbreviation has to be done to balance the code 
> readability. 

That is fine.

If we decide that how many characters in one word are not acceptable and need 
to be shortened beforehand, we can make more better rule for other members who 
will be in this project in the future.
But once we get more people and make more lines in source(current: only 16483 
lines), it's going to be difficult.

Any thought would be appreciated.

Cheers,
Shinobu 

- Original Message -
From: "joehuang" 
To: ski...@redhat.com, "OpenStack Development Mailing List (not for usage 
questions)" 
Sent: Tuesday, April 5, 2016 11:09:38 AM
Subject: RE: [openstack-dev] [Tricircle] Naming convention

Hi, Shinobu, 

Fully agree with you that this is a dilemma situation: If we use full word, for 
example "availaibility_zone_aggregate", then the length of one line easily 
exceed 80 characters, especially if there are several indents, if we don't use 
short name, it's very difficult to make sure one clause in one line as far as 
possible. Even after we use shorter name, sometimes, this issue is still there 
:(

In the experience of development, using full name as far as possible to reduce 
the PEP8 naming convention prompt ion. But if the naming will make us hard to 
write one clause less than 80 characters(ensure one clause in one line), then 
sometimes the abbreviation has to be done to balance the code readability. 

How do you think about this?

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Tuesday, April 05, 2016 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Tricircle] Naming convention

Hi Chaoyi,

Thank you for your reply.
How about this:

# tricircle/api/pod.py
94 aggregate = az_ag.create_ag_az(context,

 95
ag_name=ag_name,
96az_name=az_name)
 ...
161ag = az_ag.get_ag_by_name(context, ag_name)

Since there is zero impact on the system, you could ignore though.

Cheers,
Shinobu


On Tue, Apr 5, 2016 at 10:08 AM, joehuang  wrote:
> Hi, Shinobu,
>
> Thanks for your suggestion. When using PyCharm as the IDE, one issue is that 
> if we use abbreviation for the word to name the function or variables, there 
> is some PEP8 promotion that you'd better to name it in a whole word, but not 
> abbreviation.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, April 02, 2016 7:40 AM
> To: joehuang; OpenStack Development Mailing List (not for usage 
> questions)
> Subject: Re: [openstack-dev] [Tricircle] Naming convention
>
> One of examples is:
>
> """
>  tricircle/db/api.py
> """
> authorize_quota_class_context(context, class_name):
>
> # This could become:
>
> auth_quota_class_ctx(ctx, class_name):
>
> # If we put some comment for this, this also could become:
>
> """
>   Function: Ensure a request has right permission to given the project.
>   @ctx: user context
>   @class: class name
> """
> auth_quota_ctx(ctx, class):
>
> Point here is, honestly not only name but also appropriate length of comment.
> What do you think?
>
> Cheers,
> Shinobu
>
>
> On Sat, Apr 2, 2016 at 8:20 AM, joehuang  wrote:
>> yes, good idea, could you point out or  report a bug which are not 
>> good naming.
>>
>> thanks.
>>
>> Sent from HUAWEI AnyOffice
>> 发件人：shinobu.kj
>> 收件人：openstack-dev,
>> 时间：2016-04-02 06:21:50
>> 主题:[openstack-dev] [Tricircle] Naming convention
>>
>> Hi Team,
>>
>> Probably it's worth thinking of naming convention for classes, 
>> methods or whatever we define in source codes.
>>
>> Some names are lengthy and there might be no consistency. At the 
>> moment it's fine. But once this project gets growing, situation would 
>> become chaotic and could cause bugs.
>>
>> What do you think?
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> _
>> _  OpenStack Development Mailing 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
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource 
> __
>  OpenStack Development Mail

Re: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer team

[Vilobh Meshram]

+1

On Sat, Apr 2, 2016 at 7:24 AM, Kai Qiang Wu  wrote:

> + 1 for Eli :)
>
>
> Thanks
>
> Best Wishes,
>
> 
> Kai Qiang Wu (吴开强 Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: wk...@cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
>
> 
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for Hongbin Lu ---01/04/2016 02:20:17
> am---Hi all, Eli Qiao has been consistently contributed to Magnum f]Hongbin
> Lu ---01/04/2016 02:20:17 am---Hi all, Eli Qiao has been consistently
> contributed to Magnum for a while. His contribution started f
>
> From: Hongbin Lu 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 01/04/2016 02:20 am
> Subject: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core
> reviewer team
> --
>
>
>
> Hi all,
>
> Eli Qiao has been consistently contributed to Magnum for a while. His
> contribution started from about 10 months ago. Along the way, he
> implemented several important blueprints and fixed a lot of bugs. His
> contribution covers various aspects (i.e. APIs, conductor, unit/functional
> tests, all the COE templates, etc.), which shows that he has a good
> understanding of almost every pieces of the system. The feature set he
> contributed to is proven to be beneficial to the project. For example, the
> gate testing framework he heavily contributed to is what we rely on every
> days. His code reviews are also consistent and useful.
>
> I am happy to propose Eli Qiao to be a core reviewer of Magnum team.
> According to the OpenStack Governance process [1], we require a minimum of
> 4 +1 votes within a 1 week voting window (consider this proposal as a +1
> vote from me). A vote of -1 is a veto. If we cannot get enough votes or
> there is a veto vote prior to the end of the voting window, Eli is not able
> to join the core team and needs to wait 30 days to reapply.
>
> The voting is open until Thursday April 7st.
>
> [1] *https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess*
> 
>
> Best regards,
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing 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] [Tricircle] Naming convention

[joehuang]

Hi, Shinobu, 

Fully agree with you that this is a dilemma situation: If we use full word, for 
example "availaibility_zone_aggregate", then the length of one line easily 
exceed 80 characters, especially if there are several indents, if we don't use 
short name, it's very difficult to make sure one clause in one line as far as 
possible. Even after we use shorter name, sometimes, this issue is still there 
:(

In the experience of development, using full name as far as possible to reduce 
the PEP8 naming convention prompt ion. But if the naming will make us hard to 
write one clause less than 80 characters(ensure one clause in one line), then 
sometimes the abbreviation has to be done to balance the code readability. 

How do you think about this?

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Tuesday, April 05, 2016 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Tricircle] Naming convention

Hi Chaoyi,

Thank you for your reply.
How about this:

# tricircle/api/pod.py
94 aggregate = az_ag.create_ag_az(context,

 95
ag_name=ag_name,
96az_name=az_name)
 ...
161ag = az_ag.get_ag_by_name(context, ag_name)

Since there is zero impact on the system, you could ignore though.

Cheers,
Shinobu


On Tue, Apr 5, 2016 at 10:08 AM, joehuang  wrote:
> Hi, Shinobu,
>
> Thanks for your suggestion. When using PyCharm as the IDE, one issue is that 
> if we use abbreviation for the word to name the function or variables, there 
> is some PEP8 promotion that you'd better to name it in a whole word, but not 
> abbreviation.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, April 02, 2016 7:40 AM
> To: joehuang; OpenStack Development Mailing List (not for usage 
> questions)
> Subject: Re: [openstack-dev] [Tricircle] Naming convention
>
> One of examples is:
>
> """
>  tricircle/db/api.py
> """
> authorize_quota_class_context(context, class_name):
>
> # This could become:
>
> auth_quota_class_ctx(ctx, class_name):
>
> # If we put some comment for this, this also could become:
>
> """
>   Function: Ensure a request has right permission to given the project.
>   @ctx: user context
>   @class: class name
> """
> auth_quota_ctx(ctx, class):
>
> Point here is, honestly not only name but also appropriate length of comment.
> What do you think?
>
> Cheers,
> Shinobu
>
>
> On Sat, Apr 2, 2016 at 8:20 AM, joehuang  wrote:
>> yes, good idea, could you point out or  report a bug which are not 
>> good naming.
>>
>> thanks.
>>
>> Sent from HUAWEI AnyOffice
>> 发件人：shinobu.kj
>> 收件人：openstack-dev,
>> 时间：2016-04-02 06:21:50
>> 主题:[openstack-dev] [Tricircle] Naming convention
>>
>> Hi Team,
>>
>> Probably it's worth thinking of naming convention for classes, 
>> methods or whatever we define in source codes.
>>
>> Some names are lengthy and there might be no consistency. At the 
>> moment it's fine. But once this project gets growing, situation would 
>> become chaotic and could cause bugs.
>>
>> What do you think?
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> _
>> _  OpenStack Development Mailing 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
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource 
> __
>  OpenStack Development Mailing 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
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] OVSDB native interface as default in gate jobs

[Russell Bryant]

On Mon, Apr 4, 2016 at 5:32 PM, Sean M. Collins  wrote:

> Inessa Vasilevskaya wrote:
> > different configurations of of_interface and ovsdb_interface options
> > (dsvm-fullstack [2] and rally tests are by now all I can think of).
>
> Wait, we have *two* different configuration options???
>
> WHY WHY WHY
>

​because they are related to two different command line utilities
(ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs
OpenFlow) that talk to two different daemons on the system (ovsdb-server vs
ovs-vswitchd) ?

With that said, I see no reason to keep two methods if one is clearly
better.  I just don't think combining them into one config option makes
much sense.
​

-- 
Russell Bryant
__
OpenStack Development Mailing List (not for 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] Naming convention

[Shinobu Kinjo]

Hi Chaoyi,

Thank you for your reply.
How about this:

# tricircle/api/pod.py
94 aggregate = az_ag.create_ag_az(context,

 95
ag_name=ag_name,
96az_name=az_name)
 ...
161ag = az_ag.get_ag_by_name(context, ag_name)

Since there is zero impact on the system, you could ignore though.

Cheers,
Shinobu


On Tue, Apr 5, 2016 at 10:08 AM, joehuang  wrote:
> Hi, Shinobu,
>
> Thanks for your suggestion. When using PyCharm as the IDE, one issue is that 
> if we use abbreviation for the word to name the function or variables, there 
> is some PEP8 promotion that you'd better to name it in a whole word, but not 
> abbreviation.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, April 02, 2016 7:40 AM
> To: joehuang; OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Tricircle] Naming convention
>
> One of examples is:
>
> """
>  tricircle/db/api.py
> """
> authorize_quota_class_context(context, class_name):
>
> # This could become:
>
> auth_quota_class_ctx(ctx, class_name):
>
> # If we put some comment for this, this also could become:
>
> """
>   Function: Ensure a request has right permission to given the project.
>   @ctx: user context
>   @class: class name
> """
> auth_quota_ctx(ctx, class):
>
> Point here is, honestly not only name but also appropriate length of comment.
> What do you think?
>
> Cheers,
> Shinobu
>
>
> On Sat, Apr 2, 2016 at 8:20 AM, joehuang  wrote:
>> yes, good idea, could you point out or  report a bug which are not
>> good naming.
>>
>> thanks.
>>
>> Sent from HUAWEI AnyOffice
>> 发件人：shinobu.kj
>> 收件人：openstack-dev,
>> 时间：2016-04-02 06:21:50
>> 主题:[openstack-dev] [Tricircle] Naming convention
>>
>> Hi Team,
>>
>> Probably it's worth thinking of naming convention for classes, methods
>> or whatever we define in source codes.
>>
>> Some names are lengthy and there might be no consistency. At the
>> moment it's fine. But once this project gets growing, situation would
>> become chaotic and could cause bugs.
>>
>> What do you think?
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>>  OpenStack Development Mailing 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
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
> __
> OpenStack Development Mailing 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
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing List (not for 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][api] advanced search criteria

[Hirofumi Ichihara]

Hi Ihar,

On 2016/04/05 7:57, Ihar Hrachyshka wrote:

Hi all,

in neutron, we have a bunch of configuration options to control 
advanced filtering features for API, f.e. allow_sorting, 
allow_pagination, allow_bulk, etc. Those options have default False 
values.
I saw allow_bulk option is set default True in 
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L66

Well, I don't think there's someone sets False to the option.



In the base API controller class, we have support for both native 
sorting/pagination/bulk operations [implemented by the plugin itself], 
as well as a generic implementation for plugins without native 
support. But if corresponding allow_* options are left with their 
default False values, those advanced search/filtering criteria just 
don’t work, no matter whether the plugin support native filters, or not.


It seems weird to me that our API behaves differently depending on 
configuration options, and that we have those useful features disabled 
by default.


My immediate interest is to add native support for sorting/pagination 
for QoS service plugin; I have a patch for that, and I planned to add 
some API tests to validate that the features work, but I hit failures 
because those features are not enabled for the -api job.


Some questions:
- can we enable those features in -api job?
- is there any reason to keep default values for allow_* as False, and 
if not, can we switch to True?
- why do we even need to control those features with configuration 
options? can we deprecate and remove them?
I agree we will deprecate and remove the option but I think that we need 
more tests if we support it as default.

It looks like there are very few tests(UT only).

Thanks,
Hirofumi



Ihar

__ 


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

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





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

Re: [openstack-dev] [Tricircle] Naming convention

[joehuang]

Hi, Shinobu,

Thanks for your suggestion. When using PyCharm as the IDE, one issue is that if 
we use abbreviation for the word to name the function or variables, there is 
some PEP8 promotion that you'd better to name it in a whole word, but not 
abbreviation.

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Saturday, April 02, 2016 7:40 AM
To: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Tricircle] Naming convention

One of examples is:

"""
 tricircle/db/api.py
"""
authorize_quota_class_context(context, class_name):

# This could become:

auth_quota_class_ctx(ctx, class_name):

# If we put some comment for this, this also could become:

"""
  Function: Ensure a request has right permission to given the project.
  @ctx: user context
  @class: class name
"""
auth_quota_ctx(ctx, class):

Point here is, honestly not only name but also appropriate length of comment.
What do you think?

Cheers,
Shinobu


On Sat, Apr 2, 2016 at 8:20 AM, joehuang  wrote:
> yes, good idea, could you point out or  report a bug which are not 
> good naming.
>
> thanks.
>
> Sent from HUAWEI AnyOffice
> 发件人：shinobu.kj
> 收件人：openstack-dev,
> 时间：2016-04-02 06:21:50
> 主题:[openstack-dev] [Tricircle] Naming convention
>
> Hi Team,
>
> Probably it's worth thinking of naming convention for classes, methods 
> or whatever we define in source codes.
>
> Some names are lengthy and there might be no consistency. At the 
> moment it's fine. But once this project gets growing, situation would 
> become chaotic and could cause bugs.
>
> What do you think?
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
>  OpenStack Development Mailing 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
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource
__
OpenStack Development Mailing 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] [Infra] Meeting Tuesday April 5th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday April 5th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-29-19.03.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-29-19.03.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-29-19.03.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing List (not for 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] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jeremy Stanley]

On 2016-04-04 20:06:03 -0400 (-0400), Jay Pipes wrote:
> I'm really not sure why you are being so hostile to my proposal.
> Essentially, I wanted to involve the upstream Infra team in this
> so they can advise on the project and ensure that the 3rd party CI
> system that gets built matches what is used for the upstream
> system.
> 
> I'm not trying to add load to the infra team. Quite the opposite,
> I am attempting to gain a level of coordination to ensure an
> aligned CI system is produced that won't be a giant pain for all
> involved.

I didn't intend to come across as hostile. My concern was over what
sounded like a proposal for the OpenStack Foundation to hire some
systems administrators for the purpose of running a CI environment
to test hardware-specific features within the scope of the Infra
team. Your original suggestion[*] said things like "OpenStack
Foundation [with help] hire 2 or more systems administrators to
maintain this lab environment" and "upstream Infrastructure team
works with the hired system administrators to create a single CI
system".

If the actual proposal is for member companies to set up a CI system
using the documentation and support our community already
collectively provides to that end, I welcome their participation in
and contributions to the existing third-party CI ecosystem. If the
proposal is for integrating a hardware test environment into the
upstream CI directly, having the Infra team responsible for its care
and feeding and getting the OpenStack Foundation to dedicate staff
to that end, then my concerns stand as stated.

[*] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090513.html
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron][api] advanced search criteria

[Armando M.]

On 4 April 2016 at 17:08, Jay Pipes  wrote:

> On 04/04/2016 06:57 PM, Ihar Hrachyshka wrote:
>
>> - why do we even need to control those features with configuration
>> options? can we deprecate and remove them?
>>
>
> This would be my choice. Configuration options that make the Neutron API
> behave differently from one deployment to another should be put out to
> pasture.
>

So long as we figure out a way to provide support these capabilities
natively, I agree that we should stop using config options to alter API
behavior. This is undiscoverable by the end user, who is left with the only
choice of poking at the API to see how it responds.

Cheers,
Armando


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

[openstack-dev] [horizon] mitaka mid-cycle report

[Tripp, Travis S]

Hello everybody,

I know this is a bit late, but I just now came across a blog that our very own 
Cindy Lu wrote about the Mitaka Horizon mid-cycle. It looks to me as though 
this never made it out to the mailing list. So, I just wanted to send it along 
to the ML. Thanks, Cindy!

https://developer.ibm.com/opentech/2016/03/03/horizon-mitaka-midcycle-sprint-recap/

-Travis

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

Re: [openstack-dev] [neutron][api] advanced search criteria

[Jay Pipes]

On 04/04/2016 06:57 PM, Ihar Hrachyshka wrote:

- why do we even need to control those features with configuration
options? can we deprecate and remove them?


This would be my choice. Configuration options that make the Neutron API 
behave differently from one deployment to another should be put out to 
pasture.


Best,
-jay

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

Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jay Pipes]

On 04/04/2016 06:56 PM, Jeremy Stanley wrote:

On 2016-04-04 13:54:34 -0400 (-0400), Jay Pipes wrote:

On 03/30/2016 11:00 PM, Robert Collins wrote:

On 26 March 2016 at 09:08, Jeremy Stanley  wrote:

On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
[...]

3) The upstream Infrastructure team works with the hired system
administrators to create a single CI system that can spawn
functional test jobs on the lab hardware and report results back
to upstream Gerrit

[...]

This bit is something the TripleO team has struggled to accomplish
over the past several years (running a custom OpenStack deployment
tied directly into our CI), so at a minimum we'd want to know how
the proposed implementation would succeed in ways that they've so
far found a significant challenge even with a larger sysadmin team
than you estimate being required.


I think what Jay is getting at is to have the *exact same approach*
third-party CI for NFV and PCI have been using - so whatever
$behind-the-abstraction setup they are using, but community accessible
and visible, unlike the current behind-corprorate-firewall setups.

I'm not saying this is better or worse, but it is different to the
tripleo approach of providing a Nova API endpoint for zuul.


Yes, thank you Rob, that is precisely what I'm getting at.


In that case, I'm not sure a third-party CI system needs close
coordination with "The upstream Infrastructure team" nor "hired
system administrators" employed by the OpenStack Foundation, which
were the parts of the original proposal I was concerned with. Set
up a third-party CI system and start voting on changes (with the
consent of those projects anyway).


I'm really not sure why you are being so hostile to my proposal. 
Essentially, I wanted to involve the upstream Infra team in this so they 
can advise on the project and ensure that the 3rd party CI system that 
gets built matches what is used for the upstream system.


I'm not trying to add load to the infra team. Quite the opposite, I am 
attempting to gain a level of coordination to ensure an aligned CI 
system is produced that won't be a giant pain for all involved.


-jay

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

[openstack-dev] [neutron][api] advanced search criteria

[Ihar Hrachyshka]

Hi all,

in neutron, we have a bunch of configuration options to control advanced  
filtering features for API, f.e. allow_sorting, allow_pagination,  
allow_bulk, etc. Those options have default False values.


In the base API controller class, we have support for both native  
sorting/pagination/bulk operations [implemented by the plugin itself], as  
well as a generic implementation for plugins without native support. But if  
corresponding allow_* options are left with their default False values,  
those advanced search/filtering criteria just don’t work, no matter whether  
the plugin support native filters, or not.


It seems weird to me that our API behaves differently depending on  
configuration options, and that we have those useful features disabled by  
default.


My immediate interest is to add native support for sorting/pagination for  
QoS service plugin; I have a patch for that, and I planned to add some API  
tests to validate that the features work, but I hit failures because those  
features are not enabled for the -api job.


Some questions:
- can we enable those features in -api job?
- is there any reason to keep default values for allow_* as False, and if  
not, can we switch to True?
- why do we even need to control those features with configuration options?  
can we deprecate and remove them?


Ihar

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

Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jeremy Stanley]

On 2016-04-04 13:54:34 -0400 (-0400), Jay Pipes wrote:
> On 03/30/2016 11:00 PM, Robert Collins wrote:
> >On 26 March 2016 at 09:08, Jeremy Stanley  wrote:
> >>On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
> >>[...]
> >>>3) The upstream Infrastructure team works with the hired system
> >>>administrators to create a single CI system that can spawn
> >>>functional test jobs on the lab hardware and report results back
> >>>to upstream Gerrit
> >>[...]
> >>
> >>This bit is something the TripleO team has struggled to accomplish
> >>over the past several years (running a custom OpenStack deployment
> >>tied directly into our CI), so at a minimum we'd want to know how
> >>the proposed implementation would succeed in ways that they've so
> >>far found a significant challenge even with a larger sysadmin team
> >>than you estimate being required.
> >
> >I think what Jay is getting at is to have the *exact same approach*
> >third-party CI for NFV and PCI have been using - so whatever
> >$behind-the-abstraction setup they are using, but community accessible
> >and visible, unlike the current behind-corprorate-firewall setups.
> >
> >I'm not saying this is better or worse, but it is different to the
> >tripleo approach of providing a Nova API endpoint for zuul.
> 
> Yes, thank you Rob, that is precisely what I'm getting at.

In that case, I'm not sure a third-party CI system needs close
coordination with "The upstream Infrastructure team" nor "hired
system administrators" employed by the OpenStack Foundation, which
were the parts of the original proposal I was concerned with. Set
up a third-party CI system and start voting on changes (with the
consent of those projects anyway).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

[Eugene Nikanorov]

May be you just don't have enough pain, Sean :)

I'd agree that these should be coalesced, with a deprecation period then...

E.

On Mon, Apr 4, 2016 at 2:32 PM, Sean M. Collins  wrote:

> Inessa Vasilevskaya wrote:
> > different configurations of of_interface and ovsdb_interface options
> > (dsvm-fullstack [2] and rally tests are by now all I can think of).
>
> Wait, we have *two* different configuration options???
>
> WHY WHY WHY
>
> --
> 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

[openstack-dev] [NFV][Telco] Telco Working Group meeting for Wednesday April 6th CANCELLED

[Steve Gordon]

Hi all,

I will be on a flight during the meeting slot for Wednesday April 6th and have 
been unable to source someone else to run the meeting, as a result it is 
canceled. I would also like to highlight that at this point I believe all of 
the active Telco Working Group use cases have been submitted/moved to the 
Product Working Group repository. The Product Working Group also now has an 
alternative [1][2] timeslot available for those who were unable to make the 
PDT/EDT friendly time used for the Monday session. Product Working Group 
meetings are now at:

  Weekly on Monday at 2100 UTC in #openstack-meeting-alt (IRC webclient)
  Weekly on Tuesday at 0200 UTC in #openstack-meeting-alt (IRC webclient) 

Going forward I would like to suggest suspending the weekly Telco Working Group 
meetings (or having them on a less frequent basis) with a view to concentrating 
on attending the Product Working Group calls to assist with prioritization 
discussions, gap analysis, and next steps.

Thanks,

Steve

[1] http://lists.openstack.org/pipermail/product-wg/2016-April/001056.html
[2] http://eavesdrop.openstack.org/#OpenStack_Product_WG

__
OpenStack Development Mailing List (not for 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] -2'ing all patches on every gate breakage

[Carl Baldwin]

On Mon, Apr 4, 2016 at 3:22 PM, Doug Wiegley
 wrote:
> I don’t know, -1 really means, “there is something wrong, the submitter
> should fix it and clear the slate.”  Whereas -2 has two meanings.  The first
> is “procedural block”, and the second is “f*** you.”
>
> I really don’t see a reason not to use the procedural block as a procedural
> block. Are you not trusting the other cores to remove them or something?
> It’s literally what it’s there for.

I'm not complaining.  I've had plenty of these -2s and I understanding
the reason behind it.  But, I thought I'd chime in.

I interpret a -2 on a patch as a procedural block because of something
related to the patch.  It is awkward as a procedural block when it is
being applied due to circumstances that have nothing to do with the
patch itself and the only person who can remove the block is the
person who applied it in the first place.  That person might get
distracted, leave for the week-end, go on vacation, etc.

Would it be nice if the project itself had an easy procedural block?
A single switch that turns off entering the gate queue for the entire
project?  Wouldn't it also be nice if the switch could be toggled by
any one of a group responsible for it?  I think it would be nice but
I'm not sure how it could be easily implemented.

Carl

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

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

On 4/1/2016 10:50 AM, Matt Riedemann wrote:



On 3/31/2016 8:42 AM, Sahid Orentino Ferdjaoui wrote:

On Wed, Mar 30, 2016 at 09:46:45PM -0500, Matt Riedemann wrote:



On 3/30/2016 5:55 PM, Armando M. wrote:



On 29 March 2016 at 18:55, Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>> wrote:



On 3/29/2016 4:44 PM, Armando M. wrote:



On 29 March 2016 at 08:08, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>
>> wrote:

 Nova has had some long-standing bugs that Sahid is trying
to fix
 here [1].

 You can create a network in neutron with
 port_security_enabled=False. However, the bug is that
since
Nova
 adds the 'default' security group to the request (if
none are
 specified) when allocating networks, neutron raises an
error when
 you try to create a port on that network with a 'default'
security
 group.

 Sahid's patch simply checks if the network that we're
going
to use
 has port_security_enabled and if it does not, no security
groups are
 applied when creating the port (regardless of what's
requested for
 security groups, which in nova is always at least
'default').

 There has been a similar attempt at fixing this [2]. That
change
 simply only added the 'default' security group when
allocating
 networks with nova-network. It omitted the default
security
group if
 using neutron since:

 a) If the network does not have port security enabled,
we'll blow up
 trying to add a port on it with the default security
group.

 b) If the network does have port security enabled,
neutron will
 automatically apply a 'default' security group to the
port,
nova
 doesn't need to specify one.

 The problem both Feodor's and Sahid's patches ran into was
that the
 nova REST API adds a 'default' security group to the
server
create
 response when using neutron if specific security groups
weren't on
 the server create request [3].

 This is clearly wrong in the case of
 network.port_security_enabled=False. When listing security
groups
 for an instance, they are correctly not listed, but the
server
 create response is still wrong.

 So the question is, how to resolve this?  A few options
come to mind:

 a) Don't return any security groups in the server create
response
 when using neutron as the backend. Given by this point
we've cast
 off to the compute which actually does the work of network
 allocation, we can't call back into the network API to
see what
 security groups are being used. Since we can't be sure,
don't
 provide what could be false info.

 b) Add a new method to the network API which takes the
requested
 networks from the server create request and returns a best
guess if
 security groups are going to be applied or not. In the
case of
 network.port_security_enabled=False, we know a security
group won't
 be applied so the method returns False. If there is
 port_security_enabled, we return whatever security
group was
 requested (or 'default'). If there are multiple
networks on the
 request, we return the security groups that will be
applied
to any
 networks that have port security enabled.

 Option (b) is obviously more intensive and requires
hitting the
 neutron API from nova API before we respond, which we'd
like to
 avoid if possible. I'm also not sure what it means for the
 auto-allocated-topology (get-me-a-network) case. With a
standard
 devstack setup, a network created via the
auto-allocated-topology
 API has port_security_enabled=True, but I also have the
'Port
 Security' extension enabled and the default public
external
network
 has port_security_enabled=True. What if either of those
are
False
 (or the port security extension is disabled)? Does the
 auto-allocated network inherit
port_security_enabled=False?
We could
 duplicate that logic in Nova, but it's more proxy work
that
we would
 like to avoid.


Port security on the external network has no role in this
because this
is not the network you'd be creating ports on. Even if it had
port-security=False, an auto-allocated 

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[John Belamaric]

I was on vacation last week so I am just seeing this now. I agree that now that 
we are in Newton we should just remove the non-pluggable code and move forward 
with the migration.

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

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

[Sean M. Collins]

Inessa Vasilevskaya wrote:
> different configurations of of_interface and ovsdb_interface options
> (dsvm-fullstack [2] and rally tests are by now all I can think of).

Wait, we have *two* different configuration options??? 

WHY WHY WHY

-- 
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] [neutron] -2'ing all patches on every gate breakage

[Doug Wiegley]

> On Apr 4, 2016, at 10:37 AM, Armando M.  wrote:
> 
> 
> 
> On 4 April 2016 at 09:22, Ihar Hrachyshka  > wrote:
> Armando M. mailto:arma...@gmail.com>> wrote:
> 
> 
> 
> On 4 April 2016 at 09:01, Ihar Hrachyshka  > wrote:
> Hi all,
> 
> I noticed that often times we go and -2 all the patches in the review queue 
> on every neutron specific gate breakage spotted. This is allegedly done to 
> make sure that nothing known to be broken land in merge gate until we fix the 
> breakage on our side.
> 
> This is not allegedly done. When I do it, I put a comment next to my action.
> 
> 
> 
> While I share the goal of not resetting the gate if we can avoid it, I find 
> the way we do it a bit too aggressive. Especially considering that often 
> times those -2 votes sit there not cleared even days after the causing 
> breakage is fixed, needlessly blocking patches landing.
> 
> That's a blatant lie: I am aggressive at putting -2s as well as removing 
> them. Other changes for those the -2 stick is probably because they aren't 
> worth the hassle. We've been also in feature freeze so slowing things down 
> should have hurt anyway.
> 
> 
> I suggest we either make sure that we remove those -2 votes right after gate 
> fixes land, or we use other means to communicate to core reviewers that there 
> is a time window when nothing should land in the merge queue.
> 
> Initially I tried sending emails ahead of time alerting for gate breakages, 
> but that doesn't work for obvious reasons: there is a lag that can still be 
> fatal.
> 
> On the specific circumstance, gate broke on Friday late afternoon PDT. It 
> didn't seem that was anything critical worth merging at all cost that 
> couldn't wait until Monday morning and I didn't bother check that things 
> merged safely in the middle of my weekend.
> 
> Yeah, but it’s already up to two working days in some places.
> 
> I hear ya, but I only blocked 6 patches with one +2, none of which were 
> critical, so I really didn't see much of a disruption; that said, I 
> appreciate your note, and I'll be even more cautious next time.
>  
> 
> Note that I don’t mean you should check anything on your weekend. Instead, I 
> think we should avoid -2’s in this case and teach core reviewers to check 
> some source of gate state truth. An email would actually work as long as 
> everyone actively checks it [if for some reason people are not reading 
> openstack-dev@, let’s To: everyone in the group].
> 
> Perhaps we could try using -1, rather than -2, hoping it gets the same level 
> of attention. Having tried the entire past cycle with emails I don't see how 
> they could work at all.

I don’t know, -1 really means, “there is something wrong, the submitter should 
fix it and clear the slate.”  Whereas -2 has two meanings.  The first is 
“procedural block”, and the second is “f*** you.”

I really don’t see a reason not to use the procedural block as a procedural 
block. Are you not trusting the other cores to remove them or something? It’s 
literally what it’s there for.

Thanks,
doug



> 
> 
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for 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] fyi, continued tenant -> project changes in devstack

[Darek Smigiel]

On 04/04/2016 02:52 PM, Sean Dague wrote:

The following patches are making changes to shift from tenant -> project
for all the  references in devstack (it's not quite done yet, but this
was done as a lot of small patches to make potential reverts easy) -
https://review.openstack.org/#/q/topic:project_id+project:openstack-dev/devstack+status:open

For the most part this shouldn't impact folks, as nothing in here should
really be used outside of devstack. However some plugins might be
impacted if they work off of variables that were not expected.

https://review.openstack.org/#/c/301122/ - which makes changes to some
of lib/neutron-legacy is the patch I would most expect to have that kind
of side effects.


In the meantime similar work is happening in Neutron, so in the future, 
there would be possibility to remove all occurences of 'tenant_id' from 
this place.


https://review.openstack.org/#/q/topic:bp/keystone-v3+status:open



If breaks happen, please let us know. The response is mostly going to be
'please update your plugins' unless there turns out to be a really bad
issue.

-Sean




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

Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

[Vikram Hosakote (vhosakot)]

Thanks a lot for the opportunity Steve, the kolla core team, and the kolla 
community! :)

Regards,
Vikram Hosakote
IRC: vhosakot

From: "Steven Dake (stdake)" mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 4, 2016 at 4:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

The vote is unanimous in favor of Vikram joining the core reviewer team.  I 
have made the appropriate permission changes in gerrit.

Welcome to the core reviewer team Vikram!

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, March 29, 2016 at 9:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

Hey folks,

Consider this proposal a +1 in favor of Vikram joining the core reviewer team.  
His reviews are outstanding.  If he doesn't have anything useful to add to a 
review, he doesn't pile on the review with more -1s which are slightly 
disheartening to people.  Vikram has started a trend amongst the core reviewers 
of actually diagnosing gate failures in peoples patches as opposed to saying 
gate failed please fix.  He does this diagnosis in nearly every review I see, 
and if he is stumped  he says so.  His 30 days review stats place him in pole 
position and his 90 day review stats place him in second position.  Of critical 
notice is that Vikram is ever-present on IRC which in my professional 
experience is the #1 indicator of how well a core reviewer will perform long 
term.   Besides IRC and review requirements, we also have code requirements for 
core reviewers.  Vikram has implemented only 10 patches so far, butI feel he 
could amp this up if he had feature work to do.  At the moment we are in a 
holding pattern on master development because we need to fix Mitaka bugs.  That 
said Vikram is actively working on diagnosing root causes of people's bugs in 
the IRC channel pretty much 12-18 hours a day so we can ship Mitaka in a 
working bug-free state.

Our core team consists of 11 people.  Vikram requires at minimum 6 +1 votes, 
with no veto -2 votes within a 7 day voting window to end on April 7th.  If 
there is a veto vote prior to April 7th I will close voting.  If there is a 
unanimous vote prior to April 7th, I will make appropriate changes in gerrit.

Regards
-steve

[1] http://stackalytics.com/report/contribution/kolla-group/30
[2] http://stackalytics.com/report/contribution/kolla-group/90
__
OpenStack Development Mailing List (not for 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] -2'ing all patches on every gate breakage

[Darek Smigiel]

On 04/04/2016 11:41 AM, Armando M. wrote:



On 4 April 2016 at 09:36, Ihar Hrachyshka > wrote:


Graham mailto:graham.ha...@hpe.com>> wrote:

On 04/04/2016 17:11, Ihar Hrachyshka wrote:

Hi all,

I noticed that often times we go and -2 all the patches in
the review queue
on every neutron specific gate breakage spotted. This is
allegedly done to
make sure that nothing known to be broken land in merge
gate until we fix
the breakage on our side.

While I share the goal of not resetting the gate if we can
avoid it, I find
the way we do it a bit too aggressive. Especially
considering that often
times those -2 votes sit there not cleared even days after
the causing
breakage is fixed, needlessly blocking patches landing.

I suggest we either make sure that we remove those -2
votes right after
gate fixes land, or we use other means to communicate to
core reviewers
that there is a time window when nothing should land in
the merge queue.

Thanks,
Ihar


I recently submitted https://review.openstack.org/295253 as an
idea for
designate to prioritize reviews.

Something similar could be a good solution, in conjunction
with a bot.

So, when a gate breakage starts, saying "!gate breakage" would
apply a
"-1 Procedural Block" that gets removed when "!gate fixed" was
said?

This removes the need for humans to do the removal (and try and
remember which reviews were really -2'd or they had had a -1 on)


Thanks for the idea, that’s indeed an interesting approach. It
also helps in that now any core member would be able to
consistently block project patches for merge gate, or cancel the
alert.

Armando, do you think we could try to adopt the approach? If yes,
I may look into a patch for that.


Um, not sure, it feels over-engineered.


My $0.02
Recently, we had several gate breakages, so it would be nice to have 
automatic tool to block/unblock patchsets without any problem.


I don't know if this is a good solution, but could give *power* to all 
core reviewers to immediately give "STOP" sign for all patchsets.


--
Darek





Ihar


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

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




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


__
OpenStack Development Mailing List (not for 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] -2'ing all patches on every gate breakage

[Darek Smigiel]

One of these patchsets was mine, so I feel qualified to send a response :)

On 04/04/2016 12:06 PM, Armando M. wrote:



On 4 April 2016 at 09:51, Ihar Hrachyshka > wrote:


Doug Wiegley mailto:doug...@parksidesoftware.com>> wrote:

On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka
mailto:ihrac...@redhat.com>> wrote:

Armando M. mailto:arma...@gmail.com>>
wrote:

On 4 April 2016 at 09:01, Ihar Hrachyshka
mailto:ihrac...@redhat.com>> wrote:
Hi all,

I noticed that often times we go and -2 all the
patches in the review queue on every neutron specific
gate breakage spotted. This is allegedly done to make
sure that nothing known to be broken land in merge
gate until we fix the breakage on our side.

This is not allegedly done. When I do it, I put a
comment next to my action.



While I share the goal of not resetting the gate if we
can avoid it, I find the way we do it a bit too
aggressive. Especially considering that often times
those -2 votes sit there not cleared even days after
the causing breakage is fixed, needlessly blocking
patches landing.

That's a blatant lie: I am aggressive at putting -2s
as well as removing them. Other changes for those the
-2 stick is probably because they aren't worth the
hassle. We've been also in feature freeze so slowing
things down should have hurt anyway.


I suggest we either make sure that we remove those -2
votes right after gate fixes land, or we use other
means to communicate to core reviewers that there is a
time window when nothing should land in the merge queue.

Initially I tried sending emails ahead of time
alerting for gate breakages, but that doesn't work for
obvious reasons: there is a lag that can still be fatal.



Emails don't work. Or work just occasionally.
Openstack Dev mailing list is pretty crowded, so sometimes to read 
everything, takes hours. In this situation, important message can be 
easily skipped.




On the specific circumstance, gate broke on Friday
late afternoon PDT. It didn't seem that was anything
critical worth merging at all cost that couldn't wait
until Monday morning and I didn't bother check that
things merged safely in the middle of my weekend.


Yeah, but it’s already up to two working days in some places.


Not that -2’s sitting around is good, but what is so urgent
that two days affects the overall flow of things, and didn’t
get escalated?  Review chains can address collaboration
issues.  Monster syntax churns with lots of conflicts get more
annoying, but they’re annoying for everyone anyway. The worst
part of two days with a -2 is the fact that no one will look
at it and give feedback during that time period, IMO, not that
it takes longer to merge.  Velocity is about throughput, not
latency.


It is definitely not the end of the world. The process of -2
cancellation is just non-transparent, and I am not sure whether I
need to reach the vote owner to remove it, or it will just
magically vanish. I had inconsistent experiences with freezing
-2’s in OpenStack.


If the vote doesn't magically vanish when you expect to, you can 
simply reach out the person. When has that become a problem, 
especially when that person is usually available on irc and generally 
very responsive?


The -2 keeps you on your toes and aware of the state of the gate, 
which to me is a good thing :)


I'll shortly describe the situation.
My patchset got approved. It had +W and gate pre-approved it, but failed 
on final merge. So at the end landed as +2, +W and -2 from gate.


I didn't know what happened until I've seen Armando's "-2" with 
explanation. Even though I'm trying to be proactive on IRC channel about 
possible gate problems.


So it's definitely good method to "be aware". But, in the same time it 
was very strange to me. I had everything prepared to be merged, but it 
didn't got merge.




Landing a patch earlier lowers the chance of git conflict for
other patches being crafted in parallel with it; it also removes
the need for a core reviewer to get back to it and +W later, in
case enough +2 votes are there. 



I like the idea of adopting -1 instead of -2 and looking whether
it still works for the initial goal of avoiding gate resets.



I don't think "-1" would work in case described by me.
Patchset was already approved, and woul

Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

[Steven Dake (stdake)]

The vote is unanimous in favor of Vikram joining the core reviewer team.  I 
have made the appropriate permission changes in gerrit.

Welcome to the core reviewer team Vikram!

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, March 29, 2016 at 9:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

Hey folks,

Consider this proposal a +1 in favor of Vikram joining the core reviewer team.  
His reviews are outstanding.  If he doesn't have anything useful to add to a 
review, he doesn't pile on the review with more -1s which are slightly 
disheartening to people.  Vikram has started a trend amongst the core reviewers 
of actually diagnosing gate failures in peoples patches as opposed to saying 
gate failed please fix.  He does this diagnosis in nearly every review I see, 
and if he is stumped  he says so.  His 30 days review stats place him in pole 
position and his 90 day review stats place him in second position.  Of critical 
notice is that Vikram is ever-present on IRC which in my professional 
experience is the #1 indicator of how well a core reviewer will perform long 
term.   Besides IRC and review requirements, we also have code requirements for 
core reviewers.  Vikram has implemented only 10 patches so far, butI feel he 
could amp this up if he had feature work to do.  At the moment we are in a 
holding pattern on master development because we need to fix Mitaka bugs.  That 
said Vikram is actively working on diagnosing root causes of people's bugs in 
the IRC channel pretty much 12-18 hours a day so we can ship Mitaka in a 
working bug-free state.

Our core team consists of 11 people.  Vikram requires at minimum 6 +1 votes, 
with no veto -2 votes within a 7 day voting window to end on April 7th.  If 
there is a veto vote prior to April 7th I will close voting.  If there is a 
unanimous vote prior to April 7th, I will make appropriate changes in gerrit.

Regards
-steve

[1] http://stackalytics.com/report/contribution/kolla-group/30
[2] http://stackalytics.com/report/contribution/kolla-group/90
__
OpenStack Development Mailing List (not for 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][networking-ovn] Changing OVN plugin release model for Newton

[Russell Bryant]

On Mon, Apr 4, 2016 at 12:22 PM, Kyle Mestery  wrote:

> On Mon, Apr 4, 2016 at 8:15 AM, Russell Bryant  wrote:
> > Hello, everyone.
> >
> > While bootstrapping networking-ovn, the release model has been
> > "release:independent" [1], though we haven't actually made any releases.
> > This follows the state of OVN itself, which is still fast moving and
> > developed in OVS master.
> >
> > On the OVN side, we're now targeting a first production release in time
> for
> > the OpenStack Newton release.  We aim to branch OVS (which includes OVN)
> in
> > July and release by September or so.
> >
> > I think it's time to start making releases of the Neutron plugin.  I
> suggest
> > we adopt "release:cycle-with-milestones" [2] to match the primary Neutron
> > repositories.
> >
> > Thoughts?
> >
> +1, this makes sense to me. As you say, the eminent release of an OVN
> release itself should trigger changes in the release model for the
> plugin as well.
>
> Are you going to propose a governance patch to reflect this?
>

​Thanks, Kyle.  I just wanted to raise awareness of the proposed change
first.

https://review.openstack.org/301325

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

Re: [openstack-dev] [horizon][all] How to properly depend on Horizon

[Doug Hellmann]

> On Apr 4, 2016, at 3:32 PM, Rob Cresswell  
> wrote:
> 
> When you refer to publishing horizon on PyPI, did you mean the entire service 
> (horizon + openstack_dashboard), or just the horizon package?
> 
> My advice would be to add the horizon tarball to requirements.txt rather than 
> test-requirements, and just use stable-* tarball when creating stable plugin 
> releases. I'm not sure what the tox method achieves; it seems like it 
> obscures the dependency to me.

Linking to tarballs in dependency lists doesn’t let us express which versions 
are actually compatible, and it doesn’t help packagers understand the true 
interdependencies of our projects.

It seems to me that it’s time to split the horizon library (or framework, or 
whatever) out so we can publish it to PyPI and treat it as a dependency of all 
of the UI projects we’re spawning.

Doug

> 
> Rob
> 
> On 4 April 2016 at 02:37, Serg Melikyan  > wrote:
> Hi folks,
> 
> while I was working on bug [0] with incorrect dependency to horizon in
> stable/mitaka I discovered at least three different ways how people
> add such dependency:
> 
> 1. tarball dependency in tox.ini [1]
> 2. tarball dependency in test-requirements.txt [2]
> 3. git repo dependency in  test-requirements.txt [3]
> 
> Question: How to properly depend on horizon?
> 
> P.S. Looks like update.py in openstack/requirements simply ignores #2
> and #3 and don't count as extra dependency.
> 
> P.P.S Why we can't publish horizon to pypi.openstack.org 
> ?
> 
> Reference:
> [0] https://bugs.launchpad.net/bugs/1565577 
> 
> [1] 
> https://github.com/openstack/designate-dashboard/blob/dfa2fc6660467da2f1c53e12aeb7d7aab5d7531e/tox.ini#L20
>  
> 
> [2] 
> https://github.com/openstack/monasca-ui/blob/8861bede7e06d19b265d3425208b4865c480eb69/test-requirements.txt#L25
>  
> 
> [3] 
> https://github.com/openstack/manila-ui/blob/bf382083b281a77f77df9e0bd51376df49d53b2e/test-requirements.txt#L5
>  
> 
> 
> --
> Serg Melikyan, Development Manager at Mirantis, Inc.
> http://mirantis.com  | smelik...@mirantis.com 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] fyi, continued tenant -> project changes in devstack

[Sean Dague]

The following patches are making changes to shift from tenant -> project
for all the  references in devstack (it's not quite done yet, but this
was done as a lot of small patches to make potential reverts easy) -
https://review.openstack.org/#/q/topic:project_id+project:openstack-dev/devstack+status:open

For the most part this shouldn't impact folks, as nothing in here should
really be used outside of devstack. However some plugins might be
impacted if they work off of variables that were not expected.

https://review.openstack.org/#/c/301122/ - which makes changes to some
of lib/neutron-legacy is the patch I would most expect to have that kind
of side effects.

If breaks happen, please let us know. The response is mostly going to be
'please update your plugins' unless there turns out to be a really bad
issue.

-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] [horizon][all] How to properly depend on Horizon

[Rob Cresswell]

When you refer to publishing horizon on PyPI, did you mean the entire service 
(horizon + openstack_dashboard), or just the horizon package?

My advice would be to add the horizon tarball to requirements.txt rather than 
test-requirements, and just use stable-* tarball when creating stable plugin 
releases. I'm not sure what the tox method achieves; it seems like it obscures 
the dependency to me.

Rob

On 4 April 2016 at 02:37, Serg Melikyan 
mailto:smelik...@mirantis.com>> wrote:
Hi folks,

while I was working on bug [0] with incorrect dependency to horizon in
stable/mitaka I discovered at least three different ways how people
add such dependency:

1. tarball dependency in tox.ini [1]
2. tarball dependency in test-requirements.txt [2]
3. git repo dependency in  test-requirements.txt [3]

Question: How to properly depend on horizon?

P.S. Looks like update.py in openstack/requirements simply ignores #2
and #3 and don't count as extra dependency.

P.P.S Why we can't publish horizon to 
pypi.openstack.org?

Reference:
[0] https://bugs.launchpad.net/bugs/1565577
[1] 
https://github.com/openstack/designate-dashboard/blob/dfa2fc6660467da2f1c53e12aeb7d7aab5d7531e/tox.ini#L20
[2] 
https://github.com/openstack/monasca-ui/blob/8861bede7e06d19b265d3425208b4865c480eb69/test-requirements.txt#L25
[3] 
https://github.com/openstack/manila-ui/blob/bf382083b281a77f77df9e0bd51376df49d53b2e/test-requirements.txt#L5

--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

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

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

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Kenny Johnston]

On Mon, Apr 4, 2016 at 1:41 PM, Andreas Jaeger  wrote:

> On 04/04/2016 12:12 PM, Thierry Carrez wrote:
> > Doug Hellmann wrote:
> >>> [...]
> >>> We would love to add all sufficiently mature projects to the
> >>> installation
> >>> guide because it increases visibility and adoption by operators, but we
> >>> lack resources to develop a source installation mechanism that
> >>> retains as
> >>> much simplicity as possible for our audience.
> >>
> >> I think it would be a big mistake to try to create one guide for
> >> installing all OpenStack projects. As you say, testing what we have
> >> now is already a monumental task and impedes your ability to make
> >> changes.  Adding more projects, with ever more dependencies and
> >> configuration issues to the work the same team is doing would bury
> >> the current documentation team. So I think focusing on the DefCore
> >> list, or even a smaller list of projects with tight installation
> >> integration requirements, makes sense for the team currently producing
> >> the installation guide.
> >
> > Yes, the base install guide should ideally serve as a reference to reach
> > that first step where you have all the underlying services (MySQL,
> > Rabbit) and a base set of functionality (starterkit:compute ?) installed
> > and working. That is where we need high-quality, proactively-checked,
> > easy to understand content.
> >
> > Then additional guides (ideally produced by each project team with
> > tooling and mentoring from the docs team) can pick up from that base
> > first step, assuming their users have completed that first step
> > successfully.
> >
>
> Fully agreed.
>
> I just wrote a first draft spec for all of this and look forward to
> reviews.
>
> I'll enhance some more tomorrow, might copy a bit from above (saw this
> too late).
>
> https://review.openstack.org/301284
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I commented on the review, but is an alternative solution to appropriately
rename the Install Guide to something like "OpenStack Proof of Concept
Guide" or "OpenStack Starter Kit Guide" and then create the centralized
docs.o.o/install-guides that references both project-specific and
deployment-project install guides?

These guides could then offer more flexibility in install options and
advice.

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

Re: [openstack-dev] [fuel] Unrelated changes in patches

[Dmitry Borodaenko]

On Mon, Apr 04, 2016 at 04:05:28PM +0300, Matthew Mosesohn wrote:
> I've seen several cases where core reviewers bully contributors into
> refactoring a particular piece of logic because it contains common
> lines relating to some non-ideal code, even if the change doesn't
> relate to this logic.
> In general, I'm ok with formatting issues, but changing how a piece of
> existing code works is over the line. It should be handled as a
> separate bug.

It's a judgement call, not a clear either-or. Core reviewers are people
who know better than others when particular code needs refactoring, and
they are more motivated than others to get it refactored, but if they
end up being the only ones ever doing refactoring, they end up
overwhelmed and the code rots.

So I think it's ok for core reviewers to enourage (although definitely
not to bully) other contributors to include well-isolated refactorings
with functional changes. The deciding factor shouldn't be whether the
changes are at all related to the bug in question, because this can and
will be taken ad absurdum and will encourage irresponsible patches that
quickly fix bugs by multiplying technical debt.

The deciding factor should be how much risk and how much additional
burden on reviewers would the requested refactoring add to the commit.
If it makes it easier to understand the affected code and doesn't have
functional impact outside of scope of the review, it's worth including
in the commit. If it has non-trivial functional impact, it can't really
be called a refactoring anyway, and in that case it does need a separate
bug or blueprint.

> But yes, in general, if someone complains about something unrelated to
> your patch, he or she should just file a bug with what is required.
> 
> -Matthew
> 
> 
> On Mon, Apr 4, 2016 at 3:46 PM, Dmitry Guryanov  
> wrote:
> > Hello, colleagues!
> >
> > It's often not so easy to decide, if you should include some unrelated
> > changes to your patch, like fixing spaces, renaming variables or something
> > else, which don't change logic. On the one hand you see something's wrong
> > with the code and you'd like to fix it, on the other hand reviewers can vote
> > of -1 and you'll have to fix you patch and upload it again and this is very
> > annoying. You can also create separate review for such changes, but it will
> > require additional effort from you and reviewers.
> >
> > If you are a reviewer, and you've noted unrelated changes you may hesitate,
> > if you should ask an author to remove them and upload new version of the
> > patch or not. Also such extra changes may confuse you sometimes.
> >
> > So I suggest creating separate patches for unrelated changes if they add new
> > chucks to patch. And I'd like to ask authors to clearly state in the subject
> > of a commit message, that this patch just fixes formatting. And reviewers
> > shouldn't check such patches too severely, so that they'll get into repo as
> > soon as possible.
> >
> > What do you think?
> >
> >
> > --
> > Dmitry Guryanov
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Cinder] About snapshot Rollback?

[Erlon Cruz]

Hi Chen,

Not sure if I got you right but I brought this topic in #openstack-cinder
some days ago. The idea is to be able to rollback a snapshot in Cinder.
Today what is possible to do is to create a volume from a snapshot. From
the user point of view, this is not ideal, as there are several cases, if
not the majority of, that the purpose of the snapshot is to revert to a
desired state, and not keep the original volume. For some backends, keeping
the original volume means space consumption. This space problem becomes
bold when we think about consistency groups. For consistency groups, some
backends might have to copy an entire filesystem for each snapshot,
consuming space and time. So, I think it would be desired to have the
ability to revert snapshots.

I know there have been efforts in the past[1] to implement that, but for
some reason the work was stopped. If you want to retake the effort please
create a spec[2]  sol everybody can provide feedback.

Erlon


[1]
https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot
[2] https://github.com/openstack/cinder-specs

On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang 
wrote:

> Hi all:
>
> We are condering add a fucntion rollback_snapshot when we use backup.
> In the end user's scenario. If a vm fails, we hope that we can use snapshot
> to to recovery the volume's data.
>
> Beacuse it can quickly recovery our vm. But if we use the remote data
> to recovery. We will spend more time.
>
> But i'm not sure if the data was recoveried from the backend. whether
> the host need to rescan the volumes? At the same time. If a volume have
> been extended, whether it can be roolback?
>
>
>
>I want to know whether the topic have been discussed or have other
> recommendations to us?
>
>
>
>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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Andreas Jaeger]

On 04/04/2016 12:12 PM, Thierry Carrez wrote:
> Doug Hellmann wrote:
>>> [...]
>>> We would love to add all sufficiently mature projects to the
>>> installation
>>> guide because it increases visibility and adoption by operators, but we
>>> lack resources to develop a source installation mechanism that
>>> retains as
>>> much simplicity as possible for our audience.
>>
>> I think it would be a big mistake to try to create one guide for
>> installing all OpenStack projects. As you say, testing what we have
>> now is already a monumental task and impedes your ability to make
>> changes.  Adding more projects, with ever more dependencies and
>> configuration issues to the work the same team is doing would bury
>> the current documentation team. So I think focusing on the DefCore
>> list, or even a smaller list of projects with tight installation
>> integration requirements, makes sense for the team currently producing
>> the installation guide.
> 
> Yes, the base install guide should ideally serve as a reference to reach
> that first step where you have all the underlying services (MySQL,
> Rabbit) and a base set of functionality (starterkit:compute ?) installed
> and working. That is where we need high-quality, proactively-checked,
> easy to understand content.
> 
> Then additional guides (ideally produced by each project team with
> tooling and mentoring from the docs team) can pick up from that base
> first step, assuming their users have completed that first step
> successfully.
> 

Fully agreed.

I just wrote a first draft spec for all of this and look forward to reviews.

I'll enhance some more tomorrow, might copy a bit from above (saw this
too late).

https://review.openstack.org/301284

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


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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are merry to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 28.03.2016):
- Ironic: 196 bugs (+17) + 163 wishlist items (-1). 28 new (+3), 135 in
progress (+11), 0 critical, 26 high (+2) and 16 incomplete (+2)
- Inspector: 14 bugs (+4) + 16 wishlist items (+1). 1 new, 7 in progress
(+1), 0 critical, 4 high (+1) and 1 incomplete (+1)
- Nova bugs with Ironic tag: 15 (-1). 0 new, 0 critical, 0 high
- Monthly diff (with 07.03):
- Ironic: 196 bugs (+39) + 163 wishlist items (-12), 135 in progress (+20)
- Inspector: 14 bugs (+5) + 16 wishlist items (+1), 7 in progress (+1)
- New bugs are coming so fast :(

Network isolation (Neutron/Ironic work) (jroll)
===
- tests are green, let's review things :)

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work

Nova Liaisons (jlvillal & mrda)
===
- Bug scrub conducted.

Doc (jroll, liliars)

- http://lists.openstack.org/pipermail/openstack-dev/2016-March/090274.html

Testing/Quality (jlvillal/krtaylor)
===
- Grenade work was done due to stable/mitaka release. jlvillal now has it
to state as it was before stable/mitaka release. There are some patches
waiting to be merged.
- Grenade. Currently at state where Ironic bare-metal VM does not get its
IP address. Need to investigate why dnsmasq is configured incorrectly at
that point.

webclient (krotscheck / betherly)
=
- Incorporating UX Feedback in progress:
https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient+branch:master+topic:ux

Drivers:

CIMC (sambetts)
---
- Third party CI for this driver is stable and voting

UCSM (sambetts)
---
- Third party CI for this driver is non-voting right now while network
issues are resolved

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
OpenStack Development Mailing List (not for 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] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jay Pipes]

On 03/30/2016 11:00 PM, Robert Collins wrote:

On 26 March 2016 at 09:08, Jeremy Stanley  wrote:

On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
[...]

3) The upstream Infrastructure team works with the hired system
administrators to create a single CI system that can spawn
functional test jobs on the lab hardware and report results back
to upstream Gerrit

[...]

This bit is something the TripleO team has struggled to accomplish
over the past several years (running a custom OpenStack deployment
tied directly into our CI), so at a minimum we'd want to know how
the proposed implementation would succeed in ways that they've so
far found a significant challenge even with a larger sysadmin team
than you estimate being required.


I think what Jay is getting at is to have the *exact same approach*
third-party CI for NFV and PCI have been using - so whatever
$behind-the-abstraction setup they are using, but community accessible
and visible, unlike the current behind-corprorate-firewall setups.

I'm not saying this is better or worse, but it is different to the
tripleo approach of providing a Nova API endpoint for zuul.


Yes, thank you Rob, that is precisely what I'm getting at.

Best,
-jay

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

Re: [openstack-dev] [puppet][ec2api] - Official EC2 puppet module repo

[Alex Schultz]

On Mon, Apr 4, 2016 at 9:12 AM, Denis Egorenko 
wrote:

> Hi Marcos,
>
> Are you still working on your initial commit to puppet-ec2api [1] ?
>
> [1] https://review.openstack.org/#/c/276103/
>


It might be a good idea to redo this review with a newer version of the
cookiecutter and split the ec2api specific additions into their own
reviews.  it would make it easier to review and land. Also we'd be able to
assist in getting things added.  I know the baribican module is currently
going a similar initial bootstrap process and it seems be going better as
far as getting incremental items added in.

-Alex



>
>
2016-01-29 22:02 GMT+03:00 Emilien Macchi :
>
>>
>>
>> On 01/29/2016 10:35 AM, Marcos Fermin Lobo wrote:
>> > Hi,
>> >
>> > Since I finished to "apply" for puppet-ec2api module as official puppet
>> > module in OpenStack (see https://review.openstack.org/#/c/252959/ and
>> > https://review.openstack.org/#/c/251857/), I saw that the puppet module
>> > repository is created https://github.com/openstack/puppet-ec2api
>> >
>> > But the repository is still empty.
>>
>> Yeah, you have two options:
>>
>> #1 Import your code
>>
>> If you do that, please iterate your patches so you'll have reviews more
>> quickly. You can look how puppet-mistral was created [1], I like the
>> iterative approach (step by step).
>>
>> #2 Generate a new module with this procedure [2]
>>
>> Run the procedure, and follow-up with new patches to add the classes
>> that you had in our module.
>>
>> [1] https://review.openstack.org/#/q/project:openstack/puppet-mistral
>> [2]
>> https://wiki.openstack.org/wiki/Puppet/New_module#On_the_technical_side
>>
>> > (...)
>>
>> Both approaches work for us, but please iterate with small chunks, which
>> is easier to test and review.
>>
>>
>> Thanks a lot for your efforts, very appreciated.
>> --
>> 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
>>
>>
>
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing 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] [openstack-ansible][security] Update: Host security hardening

[Major Hayden]

Howdy folks,

I wanted to take a few moments to update everyone on the host security 
hardening work in the openstack-ansible-security[1] role for OpenStack-Ansible.

Current status
--

The role has run in every Mitaka gate job for OpenStack-Ansible since January 
2016 and seems to be stable.  Other than issues with overzealous auditd rules 
and an improved check for unlocked system accounts, the role has worked well.  
The auditd issues are fixed and the unlocked system account fix is pending a 
Mitaka backport now. 

Release status
--

Newton:
  * Available, but not enabled by default
  * Patch submitted[2] to make it enabled on all deployments by default

Mitaka:
  * Available, but not enabled by default
  * Plan to backport Newton's "enabled by default" change to Mitaka soon

Liberty:
  * Not available, but can be added easily (docs exist for this)
  * Need input on whether this should be backported
  * If backported, I suggest we leave it disabled by default (much like we did 
for LBaaS v2)

Request for feedback


Would there be opposition to backporting openstack-ansible-security into 
OpenStack-Ansible's Liberty release with it being disabled by default?

The only impact from this change to an existing deployment would be an 
additional role downloaded via ansible-galaxy within the bootstrap-ansible.sh 
script.  Deployers would need to change 'apply_security_hardening' to 'true' in 
order to activate the role.

Thanks!

[1] http://docs.openstack.org/developer/openstack-ansible-security/
[2] https://review.openstack.org/#/c/301152/

--
Major Hayden

__
OpenStack Development Mailing List (not for 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] New resource tracker

[Jay Pipes]

On 04/04/2016 01:21 PM, Rayson Ho wrote:

I found that even in the latest git tree, the resource_tracker is still
marked as "deprecated and will be removed in the 14.0.0" in
releasenova/conf/compute.py . With the Mitaka release coming up this
week, is it still true that the code will be removed?

I googled and found this status update sent to the list (
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
), but I was wondering if the new resource tracker is documented or
should I just refer to the blueprints.


The resource tracker has not been deprecated. Only the extensible 
resource tracker code has been deprecated in Mitaka. The extensible 
resource tracker code allowed a deployer to override and extend the set 
of resources that were tracked by the resource tracker. It was 
determined this functionality was leading the scheduler and resource 
tracker code to a place where it was not possible to have consistency in 
how resources were tracked and thus it was deprecated and removed.


Best,
-jay

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

Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

[Martin André]

+1
Nice work Vikram.

On Thu, Mar 31, 2016 at 4:04 PM, Jeff Peeler  wrote:

> +1
>
> On Tue, Mar 29, 2016 at 12:07 PM, Steven Dake (stdake) 
> wrote:
> > Hey folks,
> >
> > Consider this proposal a +1 in favor of Vikram joining the core reviewer
> > team.  His reviews are outstanding.  If he doesn’t have anything useful
> to
> > add to a review, he doesn't pile on the review with more –1s which are
> > slightly disheartening to people.  Vikram has started a trend amongst the
> > core reviewers of actually diagnosing gate failures in peoples patches as
> > opposed to saying gate failed please fix.  He does this diagnosis in
> nearly
> > every review I see, and if he is stumped  he says so.  His 30 days review
> > stats place him in pole position and his 90 day review stats place him in
> > second position.  Of critical notice is that Vikram is ever-present on
> IRC
> > which in my professional experience is the #1 indicator of how well a
> core
> > reviewer will perform long term.   Besides IRC and review requirements,
> we
> > also have code requirements for core reviewers.  Vikram has implemented
> only
> > 10 patches so far, butI feel he could amp this up if he had feature work
> to
> > do.  At the moment we are in a holding pattern on master development
> because
> > we need to fix Mitaka bugs.  That said Vikram is actively working on
> > diagnosing root causes of people's bugs in the IRC channel pretty much
> 12-18
> > hours a day so we can ship Mitaka in a working bug-free state.
> >
> > Our core team consists of 11 people.  Vikram requires at minimum 6 +1
> votes,
> > with no veto –2 votes within a 7 day voting window to end on April 7th.
> If
> > there is a veto vote prior to April 7th I will close voting.  If there
> is a
> > unanimous vote prior to April 7th, I will make appropriate changes in
> > gerrit.
> >
> > Regards
> > -steve
> >
> > [1] http://stackalytics.com/report/contribution/kolla-group/30
> > [2] http://stackalytics.com/report/contribution/kolla-group/90
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] Cinder-Nova API meeting

[Ildikó Váncsa]

Hi All,

As we have much to do, our next meeting about improving the Cinder-Nova API 
interaction will take place __April 6th, 2100UTC__ on the #openstack-meeting-cp 
channel.

You can follow up the recent activities on this etherpad: 
https://etherpad.openstack.org/p/cinder-nova-api-changes 

Best Regards,
/Ildikó

> -Original Message-
> From: Ildikó Váncsa
> Sent: March 24, 2016 10:01
> To: openstack-dev@lists.openstack.org
> Subject: [cinder][nova] Cinder-Nova API meeting
> 
> Hi All,
> 
> As it was discussed several times on this mailing list there is room for 
> improvements regarding the Cinder-Nova interaction. To fix
> these issues we would like to create a cross-project spec to capture the 
> problems and ways to solve them. The current activity is
> captured on this etherpad: 
> https://etherpad.openstack.org/p/cinder-nova-api-changes
> 
> Before writing up several specs we will have a meeting next Wednesday to 
> synchronize and discuss with the two teams and everyone
> who's interested in this work the way forward.
> 
> The meeting will be held on the #openstack-meeting-cp channel, on March 30, 
> 2100UTC.
> 
> Please let me know if you have any questions.
> 
> See you next week!
> Best Regards,
> /Ildikó

__
OpenStack Development Mailing 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] [Announce]Bandit 1.0 stable released

[Kelsey, Timothy John]

Bandit release 1.0 stable
-

This milestone release includes a number of major new features, as follow:

- Test IDs: bandit tests are now given unique IDs. These IDs can be used in
  all situations where a test name would have been used previously
  (include, exclude, etc). Additionally new CLI options "-t/-s" take a list
  of test IDs to include or exclude respectively. Terse test IDs are much
  more convenient then long winded names. Support for referring to tests by
  name is now deprecated and will be removed in a future version.

- Configuration Overhaul: The bandit configuration file is now optional. All
  test plugins ship with good defaults that will be used if not overridden.
  The configuration file format has also been re-worked to be much simpler
  and make good use of the new test IDs. While the old config file format is
  still supported, it is deprecated and this support will be removed in a
  future version. Please see the documentation for info on the new format.

- Configuration tool: A new style configuration file may be generated using
  the included configuration generator tool. This contains defaults for all
  discovered plugins. It provides a good base that can then be hand edited
  as needed.

- Profiles Deprecated: Bandit's configuration files previously contained named
  lists of test to include and exclude, known as a "profile". This concept has
  been deprecated in 1.0 and will be removed in future versions when support
  for legacy configurations is dropped. In place of profiles we encourage
  adopters to use several separate config files and pick one using the -c
  command line option. This has the advantage of permitting test configuration
  defaults to be overridden as needed. Adopters may find that the new -t and
  -s CLI options completely remove the need for a "profile" or equivalent.

- Blacklists: Blacklisted items (function calls, module imports) now have test
  IDs. Fine control of blacklisting is now possible using these IDs to include
  or exclude items. A new plugin interface has been created to allow third
  party adopters to extend blacklist items if desired. Suport for legacy
  blacklist data is part of the deprecated legacy configuration support.
  Please see the Configuration Overhaul item.

The plugin API, CLI and configuration scheme should now be considered stable.
No new version of bandit will break this contract without incrementing the
major release number.

This release also includes a number of important bug fixes, we encourage
adopters to upgrade to bandit 1.0 as soon as they are able.

What this means for adopters


In most cases you will simply need to delete your bandit.yaml file and
adjust the invocation used in your tox.ini, adding -t or -s options as needed.
In more advance scenarios, generating a minimal configuration file using the
included config generation tool and tweaking as needed will be sufficient.

Finally, new integration tests have been added bandit in an effort to maintain
good compatibility with projects using bandit in the gate. The following
projects are included:

- barbican
- glance
- keystone
- keystonemiddleware
- magnum
- oslo.config
- oslo.log
- oslo.service
- oslo.utils
- python-keystoneclient
- python-magnumclient
- sahara

If your project would like to use bandit and be included in these tests,
please contact the bandit team.

—

Thank you,

The bandit dev team


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

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Dan Prince]

On Mon, 2016-04-04 at 16:16 +, Fox, Kevin M wrote:
> config management systems are another piece to the puzzle. If your
> using them to mange your containers, you still may end up needing two
> different, incompatible versions of the recipes to run on the same
> host during upgrades. Its doable, but care has to be done.

As it stands TripleO is considering Puppet only for generation of
config files with containers. Nothing else ATM. Furthermore the puppet
modules themselves can be versioned independently from each other
(meaning you can upgrade or downgrade puppet-nova seperately from
puppet-swift for example)

Given this why would I need say two different version of puppet-swift
in my Agent container (which is used to generate configs) for a given
upgrade?

Dan

> 
> Thanks,
> Kevin
> From: Dan Prince [dpri...@redhat.com]
> Sent: Sunday, April 03, 2016 4:54 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen
> of Heat, containers, and the future of TripleO
> 
> On Thu, 2016-03-31 at 08:22 +, Steven Dake (stdake) wrote:
> > Kevin,
> > 
> > I am not directly answering your question, but from the perspective
> > of Kolla, our upgrades are super simple because we don't make a big
> > mess in the first place to upgrade from.  In my experience, this is
> > the number one problem with upgrades – everyone makes a mess of the
> > first deployment, so upgrading from there is a minefield.  Better
> > to walk straight through that minefield by not making a mess of the
> > system in the first place using my favorite deployment tool: Kolla
> > ;-)
> I think any containers based solution (Kolla or not) would be
> naturally "less messy" than a baremetal deployment that isn't
> containerized. So I think TripleO would achieve much of the same by
> switching to any containerized deployment architecture right? Is
> there something special about the Kolla/Ansible approach that I'm
> missing here?
> 
> > 
> > Kolla upgrades rock.  I have no doubt we will have some minor
> > issues in the field, but we have tested 1 month old master to
> > master upgrades with database migrations of the services we deploy,
> > and it takes approximately 10 minutes on a 64 (3 control rest
> > compute) node cluster without VM downtime or loss of networking
> > service to the virtual machines.  This is because our upgrades,
> > while not totally atomic across the clsuter, are pretty darn close
> > and upgrade the entire filesystem runtime in one atomic action per
> > service while rolling the ugprade in the controller nodes.
> > 
> > During the upgrade process there may be some transient failures for
> > API service calls, but they are typically repeated by clients and
> > no real harm is done.  Note we follow project's best practices for
> > handling upgrades, without the mess of dealing with packaging or
> > configuration on the filesystem and migration thereof.
> > 
> > Regards
> > -steve
> > 
> > 
> > From: "Fox, Kevin M" 
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" 
> > Date: Wednesday, March 30, 2016 at 9:12 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen
> > of Heat, containers, and the future of TripleO
> > 
> > The main issue is one of upgradability, not stability. We all know
> > tripleo is stable. Tripleo cant do upgrades today. We're looking
> > for ways to get there. So "upgrading" to ansible isnt nessisary for
> > sure since folks deploying tripleo today must assume they cant
> > upgrade anyway.
> > 
> > Honestly I have doubts any config management system from puppet to
> > heat software deployments can be coorced to do a cloud upgrade
> > without downtime without a huge amount of workarounds. You really
> > either need a workflow oriented system with global knowledge like
> > ansible or a container orchestration system like kubernes to ensure
> > you dont change too many things at once and break things. You need
> > to be able to run some old things and some new, all at the same
> > time. And in some cases different versions/config of the same
> > service on different machines. 
> > 
> > Thoughts on how this may be made to work with puppet/heat?
> > 
> > Thanks,
> > Kevin
> >  
> > From: Dan Prince
> > Sent: Monday, March 28, 2016 12:07:22 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen
> > of Heat, containers, and the future of TripleO
> > 
> > On Wed, 2016-03-23 at 07:54 -0400, Ryan Hallisey wrote:
> > > *Snip*
> > > 
> > > > 
> > > > Indeed, this has literally none of the benefits of the ideal
> > Heat 
> > > > deployment enumerated above save one: it may be entirely the
> > wrong
> > > > tool 
> > > > in every way for the job it's being asked to do, but at least
> > it
> > > > is 
> > > > still well-int

[openstack-dev] [nova] New resource tracker

[Rayson Ho]

I found that even in the latest git tree, the resource_tracker is still
marked as "deprecated and will be removed in the 14.0.0" in
releasenova/conf/compute.py . With the Mitaka release coming up this week,
is it still true that the code will be removed?

I googled and found this status update sent to the list (
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
), but I was wondering if the new resource tracker is documented or should
I just refer to the blueprints.

Thanks,
Rayson

==
Open Grid Scheduler - The Official Open Source Grid Engine
http://gridscheduler.sourceforge.net/
http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.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] [neutron] -2'ing all patches on every gate breakage

[Armando M.]

On 4 April 2016 at 09:51, Ihar Hrachyshka  wrote:

> Doug Wiegley  wrote:
>
> On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka  wrote:
>>>
>>> Armando M.  wrote:
>>>
>>> On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:
 Hi all,

 I noticed that often times we go and -2 all the patches in the review
 queue on every neutron specific gate breakage spotted. This is allegedly
 done to make sure that nothing known to be broken land in merge gate until
 we fix the breakage on our side.

 This is not allegedly done. When I do it, I put a comment next to my
 action.



 While I share the goal of not resetting the gate if we can avoid it, I
 find the way we do it a bit too aggressive. Especially considering that
 often times those -2 votes sit there not cleared even days after the
 causing breakage is fixed, needlessly blocking patches landing.

 That's a blatant lie: I am aggressive at putting -2s as well as
 removing them. Other changes for those the -2 stick is probably because
 they aren't worth the hassle. We've been also in feature freeze so slowing
 things down should have hurt anyway.


 I suggest we either make sure that we remove those -2 votes right after
 gate fixes land, or we use other means to communicate to core reviewers
 that there is a time window when nothing should land in the merge queue.

 Initially I tried sending emails ahead of time alerting for gate
 breakages, but that doesn't work for obvious reasons: there is a lag that
 can still be fatal.

 On the specific circumstance, gate broke on Friday late afternoon PDT.
 It didn't seem that was anything critical worth merging at all cost that
 couldn't wait until Monday morning and I didn't bother check that things
 merged safely in the middle of my weekend.

>>>
>>> Yeah, but it’s already up to two working days in some places.
>>>
>>
>> Not that -2’s sitting around is good, but what is so urgent that two days
>> affects the overall flow of things, and didn’t get escalated?  Review
>> chains can address collaboration issues.  Monster syntax churns with lots
>> of conflicts get more annoying, but they’re annoying for everyone anyway.
>> The worst part of two days with a -2 is the fact that no one will look at
>> it and give feedback during that time period, IMO, not that it takes longer
>> to merge.  Velocity is about throughput, not latency.
>>
>
> It is definitely not the end of the world. The process of -2 cancellation
> is just non-transparent, and I am not sure whether I need to reach the vote
> owner to remove it, or it will just magically vanish. I had inconsistent
> experiences with freezing -2’s in OpenStack.
>

If the vote doesn't magically vanish when you expect to, you can simply
reach out the person. When has that become a problem, especially when that
person is usually available on irc and generally very responsive?

The -2 keeps you on your toes and aware of the state of the gate, which to
me is a good thing :)


>
> Landing a patch earlier lowers the chance of git conflict for other
> patches being crafted in parallel with it; it also removes the need for a
> core reviewer to get back to it and +W later, in case enough +2 votes are
> there.




> I like the idea of adopting -1 instead of -2 and looking whether it still
> works for the initial goal of avoiding gate resets.
>
> btw does anyone know whether other projects apply a similar cautious
> approach when dealing with their gate breakages?
>
>

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

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Adam Harwell]

+1

From: Brandon Logan 
Sent: Thursday, March 31, 2016 8:04 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as 
Octavia Core

+1

On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
> Octavia core reviewer.
> His contributions [1] are in line with other cores and he has been an
> active member of our community.  I have been impressed with the
> insight and quality of his reviews.
>
> Current Octavia cores, please vote by replying to this e-mail.
>
> Michael
>
>
> [1] http://stackalytics.com/report/contribution/octavia/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Ihar Hrachyshka]

Doug Wiegley  wrote:


On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka  wrote:

Armando M.  wrote:


On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:
Hi all,

I noticed that often times we go and -2 all the patches in the review  
queue on every neutron specific gate breakage spotted. This is  
allegedly done to make sure that nothing known to be broken land in  
merge gate until we fix the breakage on our side.


This is not allegedly done. When I do it, I put a comment next to my  
action.




While I share the goal of not resetting the gate if we can avoid it, I  
find the way we do it a bit too aggressive. Especially considering that  
often times those -2 votes sit there not cleared even days after the  
causing breakage is fixed, needlessly blocking patches landing.


That's a blatant lie: I am aggressive at putting -2s as well as  
removing them. Other changes for those the -2 stick is probably because  
they aren't worth the hassle. We've been also in feature freeze so  
slowing things down should have hurt anyway.



I suggest we either make sure that we remove those -2 votes right after  
gate fixes land, or we use other means to communicate to core reviewers  
that there is a time window when nothing should land in the merge queue.


Initially I tried sending emails ahead of time alerting for gate  
breakages, but that doesn't work for obvious reasons: there is a lag  
that can still be fatal.


On the specific circumstance, gate broke on Friday late afternoon PDT.  
It didn't seem that was anything critical worth merging at all cost  
that couldn't wait until Monday morning and I didn't bother check that  
things merged safely in the middle of my weekend.


Yeah, but it’s already up to two working days in some places.


Not that -2’s sitting around is good, but what is so urgent that two days  
affects the overall flow of things, and didn’t get escalated?  Review  
chains can address collaboration issues.  Monster syntax churns with lots  
of conflicts get more annoying, but they’re annoying for everyone anyway.  
The worst part of two days with a -2 is the fact that no one will look at  
it and give feedback during that time period, IMO, not that it takes  
longer to merge.  Velocity is about throughput, not latency.


It is definitely not the end of the world. The process of -2 cancellation  
is just non-transparent, and I am not sure whether I need to reach the vote  
owner to remove it, or it will just magically vanish. I had inconsistent  
experiences with freezing -2’s in OpenStack.


Landing a patch earlier lowers the chance of git conflict for other patches  
being crafted in parallel with it; it also removes the need for a core  
reviewer to get back to it and +W later, in case enough +2 votes are there.


I like the idea of adopting -1 instead of -2 and looking whether it still  
works for the initial goal of avoiding gate resets.


btw does anyone know whether other projects apply a similar cautious  
approach when dealing with their gate breakages?


Ihar

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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Armando M.]

On 4 April 2016 at 09:36, Ihar Hrachyshka  wrote:

> Graham  wrote:
>
> On 04/04/2016 17:11, Ihar Hrachyshka wrote:
>>
>>> Hi all,
>>>
>>> I noticed that often times we go and -2 all the patches in the review
>>> queue
>>> on every neutron specific gate breakage spotted. This is allegedly done
>>> to
>>> make sure that nothing known to be broken land in merge gate until we fix
>>> the breakage on our side.
>>>
>>> While I share the goal of not resetting the gate if we can avoid it, I
>>> find
>>> the way we do it a bit too aggressive. Especially considering that often
>>> times those -2 votes sit there not cleared even days after the causing
>>> breakage is fixed, needlessly blocking patches landing.
>>>
>>> I suggest we either make sure that we remove those -2 votes right after
>>> gate fixes land, or we use other means to communicate to core reviewers
>>> that there is a time window when nothing should land in the merge queue.
>>>
>>> Thanks,
>>> Ihar
>>>
>>
>> I recently submitted https://review.openstack.org/295253 as an idea for
>> designate to prioritize reviews.
>>
>> Something similar could be a good solution, in conjunction with a bot.
>>
>> So, when a gate breakage starts, saying "!gate breakage" would apply a
>> "-1 Procedural Block" that gets removed when "!gate fixed" was said?
>>
>> This removes the need for humans to do the removal (and try and
>> remember which reviews were really -2'd or they had had a -1 on)
>>
>
> Thanks for the idea, that’s indeed an interesting approach. It also helps
> in that now any core member would be able to consistently block project
> patches for merge gate, or cancel the alert.
>
> Armando, do you think we could try to adopt the approach? If yes, I may
> look into a patch for that.


Um, not sure, it feels over-engineered.


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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Armando M.]

On 4 April 2016 at 09:22, Ihar Hrachyshka  wrote:

> Armando M.  wrote:
>
>
>>
>> On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:
>> Hi all,
>>
>> I noticed that often times we go and -2 all the patches in the review
>> queue on every neutron specific gate breakage spotted. This is allegedly
>> done to make sure that nothing known to be broken land in merge gate until
>> we fix the breakage on our side.
>>
>> This is not allegedly done. When I do it, I put a comment next to my
>> action.
>>
>>
>>
>> While I share the goal of not resetting the gate if we can avoid it, I
>> find the way we do it a bit too aggressive. Especially considering that
>> often times those -2 votes sit there not cleared even days after the
>> causing breakage is fixed, needlessly blocking patches landing.
>>
>> That's a blatant lie: I am aggressive at putting -2s as well as removing
>> them. Other changes for those the -2 stick is probably because they aren't
>> worth the hassle. We've been also in feature freeze so slowing things down
>> should have hurt anyway.
>>
>>
>> I suggest we either make sure that we remove those -2 votes right after
>> gate fixes land, or we use other means to communicate to core reviewers
>> that there is a time window when nothing should land in the merge queue.
>>
>> Initially I tried sending emails ahead of time alerting for gate
>> breakages, but that doesn't work for obvious reasons: there is a lag that
>> can still be fatal.
>>
>> On the specific circumstance, gate broke on Friday late afternoon PDT. It
>> didn't seem that was anything critical worth merging at all cost that
>> couldn't wait until Monday morning and I didn't bother check that things
>> merged safely in the middle of my weekend.
>>
>
> Yeah, but it’s already up to two working days in some places.
>

I hear ya, but I only blocked 6 patches with one +2, none of which were
critical, so I really didn't see much of a disruption; that said, I
appreciate your note, and I'll be even more cautious next time.


>
> Note that I don’t mean you should check anything on your weekend. Instead,
> I think we should avoid -2’s in this case and teach core reviewers to check
> some source of gate state truth. An email would actually work as long as
> everyone actively checks it [if for some reason people are not reading
> openstack-dev@, let’s To: everyone in the group].


Perhaps we could try using -1, rather than -2, hoping it gets the same
level of attention. Having tried the entire past cycle with emails I don't
see how they could work at all.


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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Doug Wiegley]

> On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka  wrote:
> 
> Armando M.  wrote:
> 
>> 
>> 
>> On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:
>> Hi all,
>> 
>> I noticed that often times we go and -2 all the patches in the review queue 
>> on every neutron specific gate breakage spotted. This is allegedly done to 
>> make sure that nothing known to be broken land in merge gate until we fix 
>> the breakage on our side.
>> 
>> This is not allegedly done. When I do it, I put a comment next to my action.
>> 
>> 
>> 
>> While I share the goal of not resetting the gate if we can avoid it, I find 
>> the way we do it a bit too aggressive. Especially considering that often 
>> times those -2 votes sit there not cleared even days after the causing 
>> breakage is fixed, needlessly blocking patches landing.
>> 
>> That's a blatant lie: I am aggressive at putting -2s as well as removing 
>> them. Other changes for those the -2 stick is probably because they aren't 
>> worth the hassle. We've been also in feature freeze so slowing things down 
>> should have hurt anyway.
>> 
>> 
>> I suggest we either make sure that we remove those -2 votes right after gate 
>> fixes land, or we use other means to communicate to core reviewers that 
>> there is a time window when nothing should land in the merge queue.
>> 
>> Initially I tried sending emails ahead of time alerting for gate breakages, 
>> but that doesn't work for obvious reasons: there is a lag that can still be 
>> fatal.
>> 
>> On the specific circumstance, gate broke on Friday late afternoon PDT. It 
>> didn't seem that was anything critical worth merging at all cost that 
>> couldn't wait until Monday morning and I didn't bother check that things 
>> merged safely in the middle of my weekend.
> 
> Yeah, but it’s already up to two working days in some places.

Not that -2’s sitting around is good, but what is so urgent that two days 
affects the overall flow of things, and didn’t get escalated?  Review chains 
can address collaboration issues.  Monster syntax churns with lots of conflicts 
get more annoying, but they’re annoying for everyone anyway. The worst part of 
two days with a -2 is the fact that no one will look at it and give feedback 
during that time period, IMO, not that it takes longer to merge.  Velocity is 
about throughput, not latency.

Thanks,
doug


> 
> Note that I don’t mean you should check anything on your weekend. Instead, I 
> think we should avoid -2’s in this case and teach core reviewers to check 
> some source of gate state truth. An email would actually work as long as 
> everyone actively checks it [if for some reason people are not reading 
> openstack-dev@, let’s To: everyone in the group].
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [monasca][release] missing build artifacts

[Davanum Srinivas]

Please see below:

On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann  wrote:
> Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:
>> Hi Doug, You had mentioned issues with three repos:
>>
>> 1. monasca-ceilometer
>> 2. monasca-log-api
>> 3. monasca-thresh
>>
>> All the repos that have Python code I believe are in reasonable shape with 
>> respect to the Python deliverables except for the following two repos:
>>
>> 1. monasca-ceilometer
>> 2. monasca-log-api
>>
>> I'm not sure we should attempt to resolve these two repos for the Mitaka 
>> release, but we can try. It might be too late. They aren't in heavy usage 
>> and are relatively new.
>
> I think for those you were missing the "venv" environment in tox.ini
> that the jobs use to run arbitrary commands. Have a look at some of the
> other repos for an example of how to set that up, or ask the infra team
> (I'm not sure where it's documented, unfortunately, or I would direct
> you there).

The monasca-log-api venv problem has been fixed in:
https://review.openstack.org/#/c/299936/


>>
>>
>> monasca-thresh is a pure Java component.
>>
>> In the process of looking at monasca-thresh it looks like there is a general 
>> issue with all the Java deliverables. All the Java jars are built and 
>> uploaded in their respective folders such as, 
>> http://tarballs.openstack.org/ci/monasca-thresh/. Note the "ci". However, we 
>> don't move the jars that are in this directory up a level to 
>> http://tarballs.openstack.org/monasca-thresh/. It looks like that needs to 
>> get resolved.
>>
>>
>> A proposal that I think would resolve this is as follows:
>>
>> 1. Update versions of Java jars in the pom.xml for each project to something 
>> like 2.0 on the stable/mitaka branch. This will result in a new jar file 
>> being created with a nice version and name. Note, this step isn't necessary, 
>> but if we did this we would have a nice version for Mitaka.
>
> If the artifacts exist but are in the "wrong" place, maybe someone
> from the infra team can copy them into place for you. Then if you
> give us an example of what the filenames are, the release team can
> update the tools in the releases repo to generate links to them (I
> assume, for example, they are not .tar.gz files).
>
>> 2. Figure out how to copy the jars over to their respective folders in 
>> http://tarballs.openstak.org. For Python I think the script that does this 
>> is publish-to-pypi, but for Java code, not sure exactly what needs to be 
>> done.
>
> Yes, you need to work with infra to set up the necessary build scripts.
> It's probably not realistic to do this in the next week, but if you get
> the existing files copied into place then you can work on updating the
> job before the Newton-1 milestone tagging deadline.
>
> Doug
>
>>
>> I think the two steps above would get us in compliance again for 
>> monasca-thresh and all the Java code in the other repos.
>>
>> Does that seem like a reasonable plan at this point?
>>
>> Regards --Roland
>>
>> On 4/1/16, 2:36 PM, "Doug Hellmann"  wrote:
>>
>> >Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
>> >> Hi Doug, Sorry, this is our first release and we want to do the right 
>> >> thing.
>> >>
>> >> monasca-ceilometer is the code that plugs into the Ceilometer publisher 
>> >> and Ceilometer storage driver to allow Ceilometer to send metrics to the 
>> >> Monasca API and use Monasca as a storage backend. We don't create a pypi 
>> >> for this component.
>> >
>> >How do you users receive that code and install it? We at least need
>> >a tarball built. If you don't want to publish to pypi, you can use
>> >the job definitions that the Python server projects use to build
>> >artifacts.
>> >
>> >> monasca-log-api is probably not set up completely, but it should be 
>> >> similar to the monasca-api.
>> >>
>> >> monasca-thresh remains purely Java code. There is a build, but it isn't a 
>> >> Python build so there isn't a tox.ini. Not sure how to deliver this, but 
>> >> the current java build overwrites the jar each time it builds so it 
>> >> sounds like that would need to be fixed.
>> >
>> >Are those JAR files going somewhere we could link to?
>> >
>> >>
>> >> I guess, judging by the issues, I don't quite understand what 
>> >> "deliverables" are. I was thinking it was the tagged code, but obviously 
>> >> it includes the build too. It sounds like we have more work ahead of us.
>> >
>> >Most of our distributors want a tarball or sdist or other artifact they
>> >can use to build a package from. For the Python-based apps, we have
>> >templates you can use in the zuul/layout.yaml file to introduce those
>> >jobs into the right zuul queues. The release or infra teams can help you
>> >identify the right template to use.
>> >
>> >> Let me know how you want to proceed.
>> >
>> >We only want to be linking to things we're actually publishing. The
>> >first patch I mentioned removes the links so the Monasca projects
>> >that don't have

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Ihar Hrachyshka]

Graham  wrote:


On 04/04/2016 17:11, Ihar Hrachyshka wrote:

Hi all,

I noticed that often times we go and -2 all the patches in the review  
queue

on every neutron specific gate breakage spotted. This is allegedly done to
make sure that nothing known to be broken land in merge gate until we fix
the breakage on our side.

While I share the goal of not resetting the gate if we can avoid it, I  
find

the way we do it a bit too aggressive. Especially considering that often
times those -2 votes sit there not cleared even days after the causing
breakage is fixed, needlessly blocking patches landing.

I suggest we either make sure that we remove those -2 votes right after
gate fixes land, or we use other means to communicate to core reviewers
that there is a time window when nothing should land in the merge queue.

Thanks,
Ihar


I recently submitted https://review.openstack.org/295253 as an idea for
designate to prioritize reviews.

Something similar could be a good solution, in conjunction with a bot.

So, when a gate breakage starts, saying "!gate breakage" would apply a
"-1 Procedural Block" that gets removed when "!gate fixed" was said?

This removes the need for humans to do the removal (and try and
remember which reviews were really -2'd or they had had a -1 on)


Thanks for the idea, that’s indeed an interesting approach. It also helps  
in that now any core member would be able to consistently block project  
patches for merge gate, or cancel the alert.


Armando, do you think we could try to adopt the approach? If yes, I may  
look into a patch for that.


Ihar

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

[openstack-dev] [mistral] Team meeting minutes - 04/04/2016

[Renat Akhmerov]

Thanks for joining our meeting today!

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-04-04-16.01.html
 

Meeting log: 
http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-04-04-16.01.log.html
 


The next meeting will be on Apr 11

Welcome to join!

Renat Akhmerov
@Nokia

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

[openstack-dev] [Fuel] Broken plugins.

[Stanislaw Bogatkin]

Hi guys,

if you develop or testing Fuel plugins with current Fuel master ISOs - be
aware that with last changes into Fuel tasks serialize system plugins are
currently broken. There is a patch [0] which partially fixes this from
nailgun side and I am working on library part of it. I believe that we need
1-2 days more to get this done.

Sorry for inconvenience.

[0] https://review.openstack.org/#/c/300637/

-- 
with best regards,
Stan.
__
OpenStack Development Mailing List (not for 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][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Fox, Kevin M]

Yeah, they were really slammed for 1.0 and were rejecting a lot of good ideas. 
1.2 is significantly better since they had time to start to pull in some of 
those ideas. While its still marked beta, their Deployment api 
(http://kubernetes.io/docs/user-guide/deployments/) seems to be a very good 
solution to the upgrade issue. Between it, the terminationGracePeriodSeconds 
flag and a lifecycle: preStop: exec hook it looks like it has everything needed 
to properly drain a stateful service during a rolling upgrade.

You'd still need some kind of workflow on top, such as Mistral or Ansible to 
drive the rolling upgrades across the multiple Deployments, but a lot of the 
heavy lifting could be done by Kubernetes itself.

Thanks,
Kevin

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Monday, April 04, 2016 8:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, 
containers, and the future of TripleO

On 4/4/16, 5:53 AM, "Dan Prince"  wrote:

>On Mon, 2016-04-04 at 02:31 +, Steven Dake (stdake) wrote:
>>
>> On 4/3/16, 6:38 PM, "Dan Prince"  wrote:
>>
>> >
>> >
>> >
>> >
>> > On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote:
>> > >
>> > > As of the Liberty release, Magnum now supports provisioning Mesos
>> > > clusters, so TripleO wouldn't have to maintain the installer for
>> > > that
>> > > either. (The choice of Mesos is somewhat unfortunate in our case,
>> > > because Magnum's Kubernetes support is much more mature than its
>> > > Mesos
>> > > support, and because the reasons for the decision are about to be
>> > > or
>> > > have already been overtaken by events - I've heard reports that
>> > > the
>> > > features that Kubernetes was missing to allow it to be used for
>> > > controller nodes, and maybe even compute nodes, are now
>> > > available.
>> > > Nonetheless, I expect the level of Magnum support for Mesos is
>> > > likely
>> > > workable.) This is where the TripleO strategy of using OpenStack
>> > > to
>> > > deploy OpenStack can really pay dividends: because we use Ironic
>> > > all
>> > > of
>> > > our servers are accessible through the Nova API, so in theory we
>> > > can
>> > > just run Magnum out of the box.
>> > >
>> > >
>> > > The chances of me personally having time to prototype this are
>> > > slim-to-zero, but I think this is a path worth investigating.
>> > Looking at Magnum more closely... At a high level I like the idea
>> > of
>> > Magnum. And interestingly it could be a surprisingly good fit for
>> > someone wanting containers on baremetal to consider using the
>> > TripleO
>> > paving machine (instack-undercloud).
>> Dan,
>>
>> When I originally got involved in Magnum and submitted the first 100
>> or so
>> patches to the repository to kick off development, my thinking was to
>> use
>> Magnum as an integration point for Kubernetes for Kolla (whiich at
>> the
>> time had no ansible but kubernetes pod files instead) running an
>> atomic
>> distro.
>>
>> It looked good on paper but in practice, all those layers and
>> dependencies
>> introduced unnecessary complexity making the system I had envisioned
>> unwieldy and more complex then the U.S. Space Shuttle.
>>
>> When I finally took off my architecture astronaut helmet, I went back
>> to
>> basics and dismissed the idea of a Magnum and a tripleo integration.
>>
>> Remember, that was my idea - and I gave up on it - for a reason.
>>
>> Magnum standalone, however, is still very viable and I like where the
>> core
>> reviewer team has taken Magnum since I stopped participation in that
>> project.
>>
>> I keep telling people underlays for OpenStack deployment are much
>> more
>> complex then they look and are 5-10 years down the road.  Yet people
>> keep
>> trying - good for them ;)
>>
>> Regards
>> -steve
>
>
>I don't think we can just leave it at "it is complex". For me
>understanding the services it uses, the architecture that it sets up,
>and how we would probably try to consume that is the required
>information. Perhaps there are other docs out there on these things but
>nobody pointed me to them so I just went and looked at Magnum myself.
>
>The reason I listed these things is because Magnum continually comes up
>as the go-to project for container integration within TripleO. I wanted
>some details about why... not just the fact that it had been tried
>before and didn't work out for Kolla in past months or years.

Magnum hasn't been tried with Kolla.  Kubernetes has.  Kubernetes at the
time had technical gaps making it impossible to execute that mission.  I
or others implemented the gaps so we could make OpenStack on k8s a
reality, and the Kubernetes community rejected them.  To be fair they were
working on getting 1.0 out the door, so Kolla's needs weren't at the top
of their list.

If the Kubernetes developers were focused on such an integration, or
significant collaboration that CoreOS and 

[openstack-dev] [Fuel] Broken plugins.

[Stanislaw Bogatkin]

Hi guys,

if you develop or testing Fuel plugins with current Fuel master ISOs - be
aware that with last changes into Fuel tasks serialize system plugins are
currently broken. There is a patch [0] which partially fixes this from
nailgun side and I am working on library part of it. I believe that we need
1-2 days more to get this done.

Sorry for inconvenience.

[0] https://review.openstack.org/#/c/300637/


-- 
with best regards,
Stan.
__
OpenStack Development Mailing List (not for 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] -2'ing all patches on every gate breakage

[Ihar Hrachyshka]

Armando M.  wrote:




On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:
Hi all,

I noticed that often times we go and -2 all the patches in the review  
queue on every neutron specific gate breakage spotted. This is allegedly  
done to make sure that nothing known to be broken land in merge gate  
until we fix the breakage on our side.


This is not allegedly done. When I do it, I put a comment next to my  
action.




While I share the goal of not resetting the gate if we can avoid it, I  
find the way we do it a bit too aggressive. Especially considering that  
often times those -2 votes sit there not cleared even days after the  
causing breakage is fixed, needlessly blocking patches landing.


That's a blatant lie: I am aggressive at putting -2s as well as removing  
them. Other changes for those the -2 stick is probably because they  
aren't worth the hassle. We've been also in feature freeze so slowing  
things down should have hurt anyway.



I suggest we either make sure that we remove those -2 votes right after  
gate fixes land, or we use other means to communicate to core reviewers  
that there is a time window when nothing should land in the merge queue.


Initially I tried sending emails ahead of time alerting for gate  
breakages, but that doesn't work for obvious reasons: there is a lag that  
can still be fatal.


On the specific circumstance, gate broke on Friday late afternoon PDT. It  
didn't seem that was anything critical worth merging at all cost that  
couldn't wait until Monday morning and I didn't bother check that things  
merged safely in the middle of my weekend.


Yeah, but it’s already up to two working days in some places.

Note that I don’t mean you should check anything on your weekend. Instead,  
I think we should avoid -2’s in this case and teach core reviewers to check  
some source of gate state truth. An email would actually work as long as  
everyone actively checks it [if for some reason people are not reading  
openstack-dev@, let’s To: everyone in the group].


Ihar

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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Hayes, Graham]

On 04/04/2016 17:11, Ihar Hrachyshka wrote:
> Hi all,
>
> I noticed that often times we go and -2 all the patches in the review queue
> on every neutron specific gate breakage spotted. This is allegedly done to
> make sure that nothing known to be broken land in merge gate until we fix
> the breakage on our side.
>
> While I share the goal of not resetting the gate if we can avoid it, I find
> the way we do it a bit too aggressive. Especially considering that often
> times those -2 votes sit there not cleared even days after the causing
> breakage is fixed, needlessly blocking patches landing.
>
> I suggest we either make sure that we remove those -2 votes right after
> gate fixes land, or we use other means to communicate to core reviewers
> that there is a time window when nothing should land in the merge queue.
>
> Thanks,
> Ihar
>

I recently submitted https://review.openstack.org/295253 as an idea for
designate to prioritize reviews.

Something similar could be a good solution, in conjunction with a bot.

So, when a gate breakage starts, saying "!gate breakage" would apply a
"-1 Procedural Block" that gets removed when "!gate fixed" was said?

This removes the need for humans to do the removal (and try and
remember which reviews were really -2'd or they had had a -1 on)

- Graham


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

Re: [openstack-dev] [Neutron][networking-ovn] Changing OVN plugin release model for Newton

[Kyle Mestery]

On Mon, Apr 4, 2016 at 8:15 AM, Russell Bryant  wrote:
> Hello, everyone.
>
> While bootstrapping networking-ovn, the release model has been
> "release:independent" [1], though we haven't actually made any releases.
> This follows the state of OVN itself, which is still fast moving and
> developed in OVS master.
>
> On the OVN side, we're now targeting a first production release in time for
> the OpenStack Newton release.  We aim to branch OVS (which includes OVN) in
> July and release by September or so.
>
> I think it's time to start making releases of the Neutron plugin.  I suggest
> we adopt "release:cycle-with-milestones" [2] to match the primary Neutron
> repositories.
>
> Thoughts?
>
+1, this makes sense to me. As you say, the eminent release of an OVN
release itself should trigger changes in the release model for the
plugin as well.

Are you going to propose a governance patch to reflect this?

Thanks!
Kyle

> [1] http://governance.openstack.org/reference/tags/release_independent.html
> [2]
> http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing 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][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Fox, Kevin M]

config management systems are another piece to the puzzle. If your using them 
to mange your containers, you still may end up needing two different, 
incompatible versions of the recipes to run on the same host during upgrades. 
Its doable, but care has to be done.

Thanks,
Kevin

From: Dan Prince [dpri...@redhat.com]
Sent: Sunday, April 03, 2016 4:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, 
containers, and the future of TripleO

On Thu, 2016-03-31 at 08:22 +, Steven Dake (stdake) wrote:
Kevin,

I am not directly answering your question, but from the perspective of Kolla, 
our upgrades are super simple because we don't make a big mess in the first 
place to upgrade from.  In my experience, this is the number one problem with 
upgrades – everyone makes a mess of the first deployment, so upgrading from 
there is a minefield.  Better to walk straight through that minefield by not 
making a mess of the system in the first place using my favorite deployment 
tool: Kolla ;-)

I think any containers based solution (Kolla or not) would be naturally "less 
messy" than a baremetal deployment that isn't containerized. So I think TripleO 
would achieve much of the same by switching to any containerized deployment 
architecture right? Is there something special about the Kolla/Ansible approach 
that I'm missing here?


Kolla upgrades rock.  I have no doubt we will have some minor issues in the 
field, but we have tested 1 month old master to master upgrades with database 
migrations of the services we deploy, and it takes approximately 10 minutes on 
a 64 (3 control rest compute) node cluster without VM downtime or loss of 
networking service to the virtual machines.  This is because our upgrades, 
while not totally atomic across the clsuter, are pretty darn close and upgrade 
the entire filesystem runtime in one atomic action per service while rolling 
the ugprade in the controller nodes.

During the upgrade process there may be some transient failures for API service 
calls, but they are typically repeated by clients and no real harm is done.  
Note we follow project's best practices for handling upgrades, without the mess 
of dealing with packaging or configuration on the filesystem and migration 
thereof.

Regards
-steve


From: "Fox, Kevin M" mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, March 30, 2016 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, 
containers, and the future of TripleO

The main issue is one of upgradability, not stability. We all know tripleo is 
stable. Tripleo cant do upgrades today. We're looking for ways to get there. So 
"upgrading" to ansible isnt nessisary for sure since folks deploying tripleo 
today must assume they cant upgrade anyway.

Honestly I have doubts any config management system from puppet to heat 
software deployments can be coorced to do a cloud upgrade without downtime 
without a huge amount of workarounds. You really either need a workflow 
oriented system with global knowledge like ansible or a container orchestration 
system like kubernes to ensure you dont change too many things at once and 
break things. You need to be able to run some old things and some new, all at 
the same time. And in some cases different versions/config of the same service 
on different machines.

Thoughts on how this may be made to work with puppet/heat?

Thanks,
Kevin


From: Dan Prince
Sent: Monday, March 28, 2016 12:07:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, 
containers, and the future of TripleO

On Wed, 2016-03-23 at 07:54 -0400, Ryan Hallisey wrote:
> *Snip*
>
> >
> > Indeed, this has literally none of the benefits of the ideal Heat
> > deployment enumerated above save one: it may be entirely the wrong
> > tool
> > in every way for the job it's being asked to do, but at least it
> > is
> > still well-integrated with the rest of the infrastructure.
> >
> > Now, at the Mitaka summit we discussed the idea of a 'split
> > stack',
> > where we have one stack for the infrastructure and a separate one
> > for
> > the software deployments, so that there is no longer any tight
> > integration between infrastructure and software. Although it makes
> > me a
> > bit sad in some ways, I can certainly appreciate the merits of the
> > idea
> > as well. However, from the argument above we can deduce that if
> > this is
> > the *only* thing we do then we will end up in the very worst of
> > all
> > possible worlds: the wrong tool for the job, poorly integrated.
> > E

Re: [openstack-dev] [Designate] Tempest Tests - in-repo or separate

[Andrea Frittoli]

I look forward to the first (as far as I know) tempest plugin for a service
in its own repo! :)


On Mon, Apr 4, 2016 at 4:49 PM Hayes, Graham  wrote:

> On 04/04/2016 16:36, Jordan Pittier wrote:
> >
> > On Mon, Apr 4, 2016 at 5:01 PM, Hayes, Graham  > > wrote:
> >
> > As we have started to move to a tempest plugin for our functional
> test
> > suite, we have 2 choices about where it lives.
> >
> > 1 - In repo (as we have [0] currently)
> > 2 - In a repo of its own (something like openstack/designate-tempest)
> >
> > There are several advantages to a separate repo:
> >
> > * It will force us to make API changes compatable
> > * * This could cause us to be slower at merging changes [1]
> > * It allows us to be branchless (like tempest is)
> > * It can be its own installable package, and a (much) shorter list
> > of requirements.
> >
> > I am not a Designate contributor, but as a Tempest contributor we
> > recommend to use a separate repo. See
> >
> http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin
> > for more details.
>
> Yeap - that was one of the reasons I will leaning towards the separate
> repo. The only thing stopping us was that I cannot see any other project
> who does it [2]
>
> We just had a quick discussion in IRC[3] and we are going to go with
> the separate repo anyway.
>
> 2 -
> http://codesearch.openstack.org/?q=%5Etempest&i=nope&files=setup.cfg&repos=
> 3 -
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2016-04-04.log.html#t2016-04-04T15:05:38
>
>
> > If everyone is OK with a separate repo, I will go ahead and start the
> > creation process.
> >
> > Thanks
> >
> > - Graham
> >
> >
> > 0 - https://review.openstack.org/283511
> > 1 -
> >
> http://docs.openstack.org/developer/tempest/HACKING.html#branchless-tempest-considerations
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> __
> OpenStack Development Mailing 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] -2'ing all patches on every gate breakage

[Armando M.]

On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:

> Hi all,
>
> I noticed that often times we go and -2 all the patches in the review
> queue on every neutron specific gate breakage spotted. This is allegedly
> done to make sure that nothing known to be broken land in merge gate until
> we fix the breakage on our side.


This is not allegedly done. When I do it, I put a comment next to my action.


>


> While I share the goal of not resetting the gate if we can avoid it, I
> find the way we do it a bit too aggressive. Especially considering that
> often times those -2 votes sit there not cleared even days after the
> causing breakage is fixed, needlessly blocking patches landing.
>

That's a blatant lie: I am aggressive at putting -2s as well as removing
them. Other changes for those the -2 stick is probably because they aren't
worth the hassle. We've been also in feature freeze so slowing things down
should have hurt anyway.


>
> I suggest we either make sure that we remove those -2 votes right after
> gate fixes land, or we use other means to communicate to core reviewers
> that there is a time window when nothing should land in the merge queue.
>

Initially I tried sending emails ahead of time alerting for gate breakages,
but that doesn't work for obvious reasons: there is a lag that can still be
fatal.

On the specific circumstance, gate broke on Friday late afternoon PDT. It
didn't seem that was anything critical worth merging at all cost that
couldn't wait until Monday morning and I didn't bother check that things
merged safely in the middle of my weekend.


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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Anita Kuno]

On 04/04/2016 12:01 PM, Ihar Hrachyshka wrote:
> Hi all,
> 
> I noticed that often times we go and -2 all the patches in the review
> queue on every neutron specific gate breakage spotted. This is allegedly
> done to make sure that nothing known to be broken land in merge gate
> until we fix the breakage on our side.
> 
> While I share the goal of not resetting the gate if we can avoid it, I
> find the way we do it a bit too aggressive. Especially considering that
> often times those -2 votes sit there not cleared even days after the
> causing breakage is fixed, needlessly blocking patches landing.
> 
> I suggest we either make sure that we remove those -2 votes right after
> gate fixes land, or we use other means to communicate to core reviewers
> that there is a time window when nothing should land in the merge queue.
> 
> Thanks,
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Well one thing that could be done is that one of the core reviewers go
into gerrit and remove everyone else from the core review group until
merging is permitted again.

It avoids the -2'ing everything and then having to clean up, but would
really have to be socialized and accepted by everyone affected prior to
being implemented, lest it create issues of a different kind.

Thanks,
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] [Neutron] Adding amuller to the neutron-drivers team

[Assaf Muller]

On Fri, Apr 1, 2016 at 7:58 PM, Edgar Magana  wrote:
> Congratulations Assaf!
>
> From: "Armando M." 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Thursday, March 31, 2016 at 5:48 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers
> team
>
> Hi folks,
>
> Assaf's tenacity is a great asset for the Neutron team at large. I believe
> that the drivers team would benefit from that tenacity, and therefore I
> would like to announce him to be a new member of the Neutron Drivers team
> [1].

Thank you everyone :)

I'm very excited to join the team! I'm bringing in a lot of energy and
hope to bring valuable contributions to the table.

>
> At the same time, I would like to thanks mestery as he steps down. Mestery
> has been instrumental in many decisions taken by this team and for
> spearheading the creation of the very team back in the Juno days.
>
> As I mentioned in the past, having a propension to attendance, and desire to
> review of RFEs puts you on the right foot to join the group, whose members
> are rotated regularly so that everyone is given the opportunity to grow, and
> no-one burns out.
>
> The team [1] meets regularly on Thursdays [2], and anyone is welcome to
> attend.
>
> Please, join me in welcome Assaf to the team.
>
> Cheers,
> Armando
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.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: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] -2'ing all patches on every gate breakage

[Ihar Hrachyshka]

Hi all,

I noticed that often times we go and -2 all the patches in the review queue  
on every neutron specific gate breakage spotted. This is allegedly done to  
make sure that nothing known to be broken land in merge gate until we fix  
the breakage on our side.


While I share the goal of not resetting the gate if we can avoid it, I find  
the way we do it a bit too aggressive. Especially considering that often  
times those -2 votes sit there not cleared even days after the causing  
breakage is fixed, needlessly blocking patches landing.


I suggest we either make sure that we remove those -2 votes right after  
gate fixes land, or we use other means to communicate to core reviewers  
that there is a time window when nothing should land in the merge queue.


Thanks,
Ihar

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

Re: [openstack-dev] [murano][release] missing build artifacts

[Doug Hellmann]

> On Apr 3, 2016, at 3:07 PM, Serg Melikyan  wrote:
> 
> Hi Doug,
> 
> I +1 your commit with removing build artifacts for
> openstack/murano-apps repo, we indeed don't have artifacts for
> murano-apps.
> 
>> It would be good to understand what your intent is for builds. Can you 
>> follow up here on this thread with some details?
> 
> openstack/murano-apps contains set of working applications for murano
> intended to be used as examples and as well as production working
> apps. Using stable branches (stable/liberty, stable/mitaka) we
> separate applications working on corresponding version of OpenStack.
> Hopefully at some point of time our built artifact is going to be each
> application published to apps.openstack.org.
> 
> I believe we don't plan to have artifacts in this repo which are part
> of the OpenStack release itself. Is there other steps that we need to
> take regarding this?

If you intend for folks to use the code as examples, and even deploy them, it 
might be best to set them up so they can be packaged. We can remove the repo 
from the mitaka list to give you time to set up the builds for newton.

Doug

> 
> On Fri, Apr 1, 2016 at 12:16 PM, Doug Hellmann  wrote:
>> Murano team,
>> 
>> We noticed in our audit of the links on
>> http://releases.openstack.org/mitaka/index.html that the links to the
>> build artifacts for murano-apps point to missing files. The murano-apps
>> repository doesn't seem to have any real build jobs configured in
>> openstack-infra/project-config/zuul/layout.yaml, so it's not clear how
>> tagging is producing a release for you.
>> 
>> For now, we are disabling links to the artifacts for that repo via
>> https://review.openstack.org/300457 but we're also planning to remove
>> murano-apps from the official Mitaka page since there don't appear to be
>> any actual related deliverables (https://review.openstack.org/300473).
>> 
>> It would be good to understand what your intent is for builds. Can
>> you follow up here on this thread with some details?
>> 
>> Thanks,
>> Doug
> 
> 
> 
> -- 
> Serg Melikyan, Development Manager at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.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] [nova] the bugs team needs (more) members

[Markus Zoeller]

> From: Adam Lawson 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 04/01/2016 09:58 PM
> Subject: Re: [openstack-dev] [nova] the bugs team needs (more) members
> 
> Markus,
> 
> If you van connect me with someone who can tell me what needs the most
> attention and how to get started, I'd be happy to help.
> 
> //adam

Checking new bug reports if they can be reproduced is an important 
and valuable task. For example:

https://bugs.launchpad.net/nova/+bug/1564905
https://bugs.launchpad.net/nova/+bug/1524301
https://bugs.launchpad.net/nova/+bug/1484081

It's a bit intimidating at the beginning, so don't worry if it doesn't
bring results immediately. Just add the link to the bug and your name 
at [1] to signal others that you're working on that and give it a try.

A bit easier is the task to double-check the current status of "stale
in progress" bug reports [2]. It's mainly pinging the current assignees
in IRC (or in a comment) if they are still working on this.

If you have questions, ping me in IRC (my name is "markus_z").

References:
[1] https://etherpad.openstack.org/p/nova-bugs-team
[2] http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale


> 
> Adam Lawson
> 
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
> 
> On Fri, Apr 1, 2016 at 3:46 AM, Markus Zoeller  
wrote:
> TL;DR: * The Nova bugs team needs more members
>* Tasks: https://wiki.openstack.org/wiki/BugTriage
>* Cleanup: http://45.55.105.55:8082/bugs-dashboard.html
>* Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
>* Etherpad: https://etherpad.openstack.org/p/nova-bugs-team
> 
> 
> The Nova project has a large backlog of open bug reports. Around 5 new
> bug reports get created everyday. It is not possible to make a
> reasonable progress with the current number of people. The nova bugs
> team needs to play a more active role and it needs more people for that.
> 
> 
> What's in for you?
> --
> As bugs are in every software in every place, you will get around a lot.
> Having a specific issue makes it also easier to ping other folks to
> discuss this issue. Bug fixes also don't have the hard deadlines
> imposed on feature patches. Being once on the bug triage side will
> improve the quality of your future bug reports which will make them
> more likely to get solved.
> 
> 
> Current Status
> --
> The main issue which slows down all following steps are bug reports
> without the essential informations [1]:
> * versions (nova, hypervisor, database, ...)
> * steps-to-reproduce (with actual data)
> * expected behavior
> * actual observed behavior
> * logs (in debug mode)
> * topology (for example: nova-network vs. neutron)
> Although this gets asked for when creating a bug report, the vast
> majority of bug reports lack this information. Usually it takes one
> to three roundtrips to get this information from the reporter. This
> is time consuming. As we focus less on new features in Newton [2] I
> have the hope that the bug list will get more attention.
> 
> 
> Tasks
> -
> The tasks are listed in the wiki [3]. They "just" need to be done.
> Repeatedly. Some on a daily basis, some less frequently. The cleanup
> dashboard [4] is a tool I use personally but can be used by you too.
> 
> The Neutron folks introduced a weekly rotating bug skimming duty and
> they've made good experiences with it. This involves 1-3 people who
> check new bugs reports if they are valid and provide the essential
> information. We should adapt that [5].
> 
> In general we should aim for:
> * respond to new bugs in a timely manner to get high quality reports
> * clean up the "old stuff" (>= 1.5 years)
> * spread the effort to multiple shoulders
> * rotate the different efforts to prevent exhaustion and tunnel vision
> 
> There is an ongoing effort to move the RFEs (request for feature
> enhancements) away from the bug list [6] to allow us to be more
> focused on faulty behavior of existing features people already rely on.
> 
> 
> Organization
> 
> * The nova bugs team has an IRC meeting [7] which allows us to sync
>   with each other.
> * The cleanup dashboard [4] shows bug reports which need a check
>   based on the tasks [3].
> * The etherpad [8] can be used to avoid an overlap of efforts of
>   different people.
> 
> 
> Education
> -
> It's possible to use the nova bugs team IRC meeting for education
> sessions if this helps you.
> I will also attend the summit in Austin in a few weeks. We can do an
> unofficial "bugs mgmt process" crash course there if you like. Just
> talk to me there (or beforehand in IRC) and we will find the time
> and space.
> At last I can offer a Google Hangout session if some are interested
> in that.
> 
> 
> How to Join?
> 
> *

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Steven Dake (stdake)]

On 4/4/16, 5:53 AM, "Dan Prince"  wrote:

>On Mon, 2016-04-04 at 02:31 +, Steven Dake (stdake) wrote:
>> 
>> On 4/3/16, 6:38 PM, "Dan Prince"  wrote:
>> 
>> > 
>> > 
>> > 
>> > 
>> > On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote:
>> > > 
>> > > As of the Liberty release, Magnum now supports provisioning Mesos
>> > > clusters, so TripleO wouldn't have to maintain the installer for
>> > > that 
>> > > either. (The choice of Mesos is somewhat unfortunate in our case,
>> > > because Magnum's Kubernetes support is much more mature than its
>> > > Mesos 
>> > > support, and because the reasons for the decision are about to be
>> > > or
>> > > have already been overtaken by events - I've heard reports that
>> > > the
>> > > features that Kubernetes was missing to allow it to be used for
>> > > controller nodes, and maybe even compute nodes, are now
>> > > available.
>> > > Nonetheless, I expect the level of Magnum support for Mesos is
>> > > likely 
>> > > workable.) This is where the TripleO strategy of using OpenStack
>> > > to
>> > > deploy OpenStack can really pay dividends: because we use Ironic
>> > > all
>> > > of 
>> > > our servers are accessible through the Nova API, so in theory we
>> > > can
>> > > just run Magnum out of the box.
>> > > 
>> > > 
>> > > The chances of me personally having time to prototype this are
>> > > slim-to-zero, but I think this is a path worth investigating.
>> > Looking at Magnum more closely... At a high level I like the idea
>> > of
>> > Magnum. And interestingly it could be a surprisingly good fit for
>> > someone wanting containers on baremetal to consider using the
>> > TripleO
>> > paving machine (instack-undercloud).
>> Dan,
>> 
>> When I originally got involved in Magnum and submitted the first 100
>> or so
>> patches to the repository to kick off development, my thinking was to
>> use
>> Magnum as an integration point for Kubernetes for Kolla (whiich at
>> the
>> time had no ansible but kubernetes pod files instead) running an
>> atomic
>> distro.
>> 
>> It looked good on paper but in practice, all those layers and
>> dependencies
>> introduced unnecessary complexity making the system I had envisioned
>> unwieldy and more complex then the U.S. Space Shuttle.
>> 
>> When I finally took off my architecture astronaut helmet, I went back
>> to
>> basics and dismissed the idea of a Magnum and a tripleo integration.
>> 
>> Remember, that was my idea - and I gave up on it - for a reason.
>> 
>> Magnum standalone, however, is still very viable and I like where the
>> core
>> reviewer team has taken Magnum since I stopped participation in that
>> project.
>> 
>> I keep telling people underlays for OpenStack deployment are much
>> more
>> complex then they look and are 5-10 years down the road.  Yet people
>> keep
>> trying - good for them ;)
>> 
>> Regards
>> -steve
>
>
>I don't think we can just leave it at "it is complex". For me
>understanding the services it uses, the architecture that it sets up,
>and how we would probably try to consume that is the required
>information. Perhaps there are other docs out there on these things but
>nobody pointed me to them so I just went and looked at Magnum myself.
>
>The reason I listed these things is because Magnum continually comes up
>as the go-to project for container integration within TripleO. I wanted
>some details about why... not just the fact that it had been tried
>before and didn't work out for Kolla in past months or years.

Magnum hasn't been tried with Kolla.  Kubernetes has.  Kubernetes at the
time had technical gaps making it impossible to execute that mission.  I
or others implemented the gaps so we could make OpenStack on k8s a
reality, and the Kubernetes community rejected them.  To be fair they were
working on getting 1.0 out the door, so Kolla's needs weren't at the top
of their list.

If the Kubernetes developers were focused on such an integration, or
significant collaboration that CoreOS and Intel are doing to run OpenStack
on k8s in tectonic were tried again in the Kolla community, a positive
outcome could result - a non-baremetal underlay based upon a proven
container architecture.  The kolla-mesos developers are pretty close and
have tried things we didn't try in our original 18 month go at running
OpenStack on Kubernetes.

Regards
-steve

>
>Anyways, If you read all of my reply you'll see that I also reach a
>similar conclusions on where Magnum stands today. And if we added
>Magnum support (which again would be a cool thing to do I think) it
>would probably be targeted for use as a generic standalone baremetal
>containers installer. And not as an OpenStack deployment tool. At least
>not until Magnum matures a bit...
>
>Dan
>
>> 
>> 
>> 
>> > 
>> > 
>> > We would need to add a few services I think to instack to supply
>> > the
>> > Magnum heat templates with the required API's. Specifically:
>> > 
>> > -barbican
>> > -neutron L3 agent
>> > -neutron Lbaas
>> > -Magnum (API, and conductor)
>> > 
>

Re: [openstack-dev] [Designate] Tempest Tests - in-repo or separate

[Hayes, Graham]

On 04/04/2016 16:36, Jordan Pittier wrote:
>
> On Mon, Apr 4, 2016 at 5:01 PM, Hayes, Graham  > wrote:
>
> As we have started to move to a tempest plugin for our functional test
> suite, we have 2 choices about where it lives.
>
> 1 - In repo (as we have [0] currently)
> 2 - In a repo of its own (something like openstack/designate-tempest)
>
> There are several advantages to a separate repo:
>
> * It will force us to make API changes compatable
> * * This could cause us to be slower at merging changes [1]
> * It allows us to be branchless (like tempest is)
> * It can be its own installable package, and a (much) shorter list
> of requirements.
>
> I am not a Designate contributor, but as a Tempest contributor we
> recommend to use a separate repo. See
> http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin
> for more details.

Yeap - that was one of the reasons I will leaning towards the separate
repo. The only thing stopping us was that I cannot see any other project
who does it [2]

We just had a quick discussion in IRC[3] and we are going to go with
the separate repo anyway.

2 - 
http://codesearch.openstack.org/?q=%5Etempest&i=nope&files=setup.cfg&repos=
3 - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2016-04-04.log.html#t2016-04-04T15:05:38


> If everyone is OK with a separate repo, I will go ahead and start the
> creation process.
>
> Thanks
>
> - Graham
>
>
> 0 - https://review.openstack.org/283511
> 1 -
> 
> http://docs.openstack.org/developer/tempest/HACKING.html#branchless-tempest-considerations
>
> __
> OpenStack Development Mailing 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] [Ceilometer] Doubt about data recollection

[Alberto Gutiérrez Torre]

Hello,

In the end the RabbitMQ approach would not suffice our requirements as
in our installation we have RabbitMQ in the controller.

I'm trying to do it with the pipeline approach but trying to maintain
the API working. I did the following with cpu_util:

- name: cpu_sink
  transformers:
  - name: "rate_of_change"
parameters:
target:
name: "cpu_util"
unit: "%"
type: "gauge"
scale: "100.0 / (10**9 *
(resource_metadata.cpu_number or 1))"
  publishers:
  - notifier://
  - udp://127.0.0.1:31337

I want to publish it in both channels but, when this is done, neither
work. If I try sending only data thought UDP it also refuses to work.
Any clues on this? I'm testing it with netcat listening to that port.


Also, is it possible to send an AMQP message to other IP that is not the
one of the controller? In the documentation only makes reference to the
options available for this kind of message, there is no place to specify
the host.

Thanks for your support,
Alberto.


On 15/03/16 16:48, gordon chung wrote:
>
> On 15/03/2016 11:01 AM, Alberto Gutiérrez Torre wrote:
>> What we would like to have is access to the data available in Ceilometer
>> API but by local access. For instance, CPU metrics produced at a given
>> node will be consumed in that same node. Probably we will not need all
>> the available data we're yet finding which variables are of our
>> interest. To start with, CPU usage and memory usage are mandatory.
>>
>> I believe that what we are searching is to access directly to compute
>> agent data. Is this possible, for example, subscribing to  the RabbitMQ
>> queue where the data is being published by the agent? Is there any other
>> way to do so?
> that's exactly one way to do it. the (compute) polling agents build a 
> set of metrics for each poll and publishes them to message queue. the 
> default consumer of these messages is the notification agent which 
> processes the data further (if necessary) and redirects it to a storage 
> or alternative target.
>
> you can configure your compute agent publish to multiple queues by 
> setting notification_topic = notifications, . or you can 
> just disable notification agent and all other non compute agent services 
> if all you want is the data
>
> alternatively, you can use all the services and have the notification 
> agent publish the data to a specific target. to do this, you'll need to 
> edit pipeline.yaml file to send just compute agent metrics to where you 
> want.
>
> cheers,
>


WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

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

Re: [openstack-dev] [Designate] Tempest Tests - in-repo or separate

[Jordan Pittier]

On Mon, Apr 4, 2016 at 5:01 PM, Hayes, Graham  wrote:

> As we have started to move to a tempest plugin for our functional test
> suite, we have 2 choices about where it lives.
>
> 1 - In repo (as we have [0] currently)
> 2 - In a repo of its own (something like openstack/designate-tempest)
>
> There are several advantages to a separate repo:
>
> * It will force us to make API changes compatable
> * * This could cause us to be slower at merging changes [1]
> * It allows us to be branchless (like tempest is)
> * It can be its own installable package, and a (much) shorter list
>of requirements.
>
>
I am not a Designate contributor, but as a Tempest contributor we recommend
to use a separate repo. See
http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin
for more details.

If everyone is OK with a separate repo, I will go ahead and start the
> creation process.
>
> Thanks
>
> - Graham
>
>
> 0 - https://review.openstack.org/283511
> 1 -
>
> http://docs.openstack.org/developer/tempest/HACKING.html#branchless-tempest-considerations
>
> __
> OpenStack Development Mailing 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] [Fuel] Mitaka SCF is coming. Here is bugs status for python and library

[Dmitry Pyzhov]

Guys, we have a soft code freeze it two days. Here is our status for bugs
with medium, low and wishlist priorities. 29 bugs are already moved

to the Newton release.

Oo 6sh of April we'll move to the Newton release:
98 bugs in python

and 25 in library

.
81 bugs marked as feature requests

in
python and 18 in library

.
12 bugs in 

Re: [openstack-dev] [fuel] Unrelated changes in patches

[Igor Kalnitsky]

Dmitry Guryanov wrote:
> It's often not so easy to decide, if you should include some unrelated
> changes to your patch, like fixing spaces, renaming variables or
> something else, which don't change logic.

I'd say it depends. If, for example, variable name is used inside one
function - it's ok to rename it within a patch. On the other hand, if
this variable is used across the code and it requires to change it in
few places - I'd prefer to do not do it within the patch. Any
unrelated change complicates review (if we're taking about thorough
review).

The things go worse when patch authors tries to implement two business
changes in one patch. In that case, it's really hard to distinguish
those both changes one from another in order to understand what's
going on.

So generally I'd prefer to see all unrelated changes in separate
patches. It's not necessary to create a bug for them, it's ok to
submit them with detailed commit message why this should be done.

Dmitry Guryanov wrote:
> On the one hand you see something's wrong with the code and you'd like
> to fix it, on the other hand reviewers can vote of -1 and you'll have
> to fix you patch and upload it again and this is very annoying.

You can fix it in first patch, and make *business* changes in the second one.

Dmitry Guryanov wrote:
> You can also create separate review for such changes, but it will
> require additional effort from you and reviewers.

As reviewer I can say: I'm spending more time trying to figure out
what's going on in patch that changes two (or even more) unrelated
things, than I'd spend if I review those changes in independent
patches.

On Mon, Apr 4, 2016 at 3:46 PM, Dmitry Guryanov  wrote:
> Hello, colleagues!
>
> It's often not so easy to decide, if you should include some unrelated
> changes to your patch, like fixing spaces, renaming variables or something
> else, which don't change logic. On the one hand you see something's wrong
> with the code and you'd like to fix it, on the other hand reviewers can vote
> of -1 and you'll have to fix you patch and upload it again and this is very
> annoying. You can also create separate review for such changes, but it will
> require additional effort from you and reviewers.
>
> If you are a reviewer, and you've noted unrelated changes you may hesitate,
> if you should ask an author to remove them and upload new version of the
> patch or not. Also such extra changes may confuse you sometimes.
>
> So I suggest creating separate patches for unrelated changes if they add new
> chucks to patch. And I'd like to ask authors to clearly state in the subject
> of a commit message, that this patch just fixes formatting. And reviewers
> shouldn't check such patches too severely, so that they'll get into repo as
> soon as possible.
>
> What do you think?
>
>
> --
> Dmitry Guryanov
>
> __
> OpenStack Development Mailing 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] [cross-project] New Quotas WG meeting time

[Nikhil Komawar]

Hi all,

We recently changed the meeting time to accommodate more expected
regular visitors to the meeting. Please find the updated info at
http://eavesdrop.openstack.org/#Cross-project_Quotas_and_Nested_Quotas_Working_Group_Virtual_Standup

Cheers

-- 

Thanks,
Nikhil


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

[openstack-dev] [Nova] live migration meeting Tuesday

[Murray, Paul (HP Cloud)]

The live migration meeting is at the usual time on Tuesday, please feel free to 
add items to the agenda.
https://wiki.openstack.org/wiki/Meetings/NovaLiveMigration

Regards,
Paul

Paul Murray
Technical Lead, HPE Cloud
Hewlett Packard Enterprise
+44 117 316 2527
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][ec2api] - Official EC2 puppet module repo

[Denis Egorenko]

Hi Marcos,

Are you still working on your initial commit to puppet-ec2api [1] ?

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

2016-01-29 22:02 GMT+03:00 Emilien Macchi :

>
>
> On 01/29/2016 10:35 AM, Marcos Fermin Lobo wrote:
> > Hi,
> >
> > Since I finished to "apply" for puppet-ec2api module as official puppet
> > module in OpenStack (see https://review.openstack.org/#/c/252959/ and
> > https://review.openstack.org/#/c/251857/), I saw that the puppet module
> > repository is created https://github.com/openstack/puppet-ec2api
> >
> > But the repository is still empty.
>
> Yeah, you have two options:
>
> #1 Import your code
>
> If you do that, please iterate your patches so you'll have reviews more
> quickly. You can look how puppet-mistral was created [1], I like the
> iterative approach (step by step).
>
> #2 Generate a new module with this procedure [2]
>
> Run the procedure, and follow-up with new patches to add the classes
> that you had in our module.
>
> [1] https://review.openstack.org/#/q/project:openstack/puppet-mistral
> [2]
> https://wiki.openstack.org/wiki/Puppet/New_module#On_the_technical_side
>
> > (...)
>
> Both approaches work for us, but please iterate with small chunks, which
> is easier to test and review.
>
>
> Thanks a lot for your efforts, very appreciated.
> --
> 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
>
>


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

[openstack-dev] [Designate] Tempest Tests - in-repo or separate

[Hayes, Graham]

As we have started to move to a tempest plugin for our functional test
suite, we have 2 choices about where it lives.

1 - In repo (as we have [0] currently)
2 - In a repo of its own (something like openstack/designate-tempest)

There are several advantages to a separate repo:

* It will force us to make API changes compatable
* * This could cause us to be slower at merging changes [1]
* It allows us to be branchless (like tempest is)
* It can be its own installable package, and a (much) shorter list
   of requirements.

If everyone is OK with a separate repo, I will go ahead and start the
creation process.

Thanks

- Graham


0 - https://review.openstack.org/283511
1 - 
http://docs.openstack.org/developer/tempest/HACKING.html#branchless-tempest-considerations

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

Re: [openstack-dev] [Heat] Meeting time

[Thomas Herve]

On Wed, Mar 30, 2016 at 10:26 AM, Thomas Herve  wrote:
> On Wed, Mar 30, 2016 at 10:13 AM, Thomas Herve  wrote:
>> Hi all,
>>
>> I'd like to be able to attend at least one of the IRC meeting, and it
>> doesn't really work right now. So if you'd like to come to meetings,
>> please fill the following doodle:
>> http://doodle.com/poll/4m6aicfnwuug86rs
>
> The times are in UTC!

All right, results are in. It's fairly spread out as expected, but
I'll move the morning one up to 8UTC and the other to 15UTC; We'll try
for a bit and change if necessary.

We're going to fix our alignment with the calendar too, so next
meeting Wednesday at 8UTC.

Thanks!

-- 
Thomas

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

Re: [openstack-dev] [magnum] Split k8s-client in separate python package

[Hongbin Lu]

Thanks Dims.

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: April-02-16 8:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Split k8s-client in separate python 
package

Hongbin,

Here's what i came up with based on your feedback:
https://review.openstack.org/#/c/300729/

Thanks,
Dims

On Fri, Apr 1, 2016 at 6:19 PM, Hongbin Lu  wrote:
> Dims,
>
> Thanks for splitting the k8sclient code out. Below is my answer to your 
> question.
>
> - Should this be a new openstack/ repo?
> Yes, I think so. We need it in openstack namespace in order to leverage the 
> openstack infra for testing and packaging.
>
> - Would the Magnum team own the repo and use the new python package?
> If this library is mainly used by Magnum, I think Magnum team has no problem 
> to own it. If it is also used by other projects, I am afraid Magnum team 
> won't have enough bandwidth to support it. In such case, it is better to have 
> other teams to share the ownership.
>
> Best regards,
> Hongbin
>
> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: April-01-16 3:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [magnum] Split k8s-client in separate python 
> package
>
> Team,
>
> I've been meaning to do this for a while. Short version, see repo:
> https://github.com/dims/python-k8sclient/
>
> Long version:
> - Started from the magnum repo.
> - pulled out just ./magnum/common/pythonk8sclient
> - preserved entire history in case we had to go back
> - reorganized directory structure
> - ran openstack cookie cutter and added generated files
> - added a test that actually works against a live k8s :)
>   
> https://github.com/dims/python-k8sclient/blob/master/k8sclient/tests/t
> est_k8sclient.py
>
> Question:
> - Should this be a new openstack/ repo?
> - Would the Magnum team own the repo and use the new python package?
>
> 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



--
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] [fuel] API changes for Nailgun openstack config

[Alexander Saprykin]

Hi all,

Please be informed that in accordance to bug [1] openstack config API will
support bulk operations for 9.0 release. 'node_id' integer parameter is
replaced by 'node_ids' list in all related handlers.

* URL query parameter in GET /openstack-config/
* POST /openstack-config/
* PUT /openstack-config/execute/

'node_id' parameter will be deprecated since Fuel 9.0 and will be removed
in 10.
API change is introduced in patch [2].

[1]: https://launchpad.net/bugs/1558561
[2]: https://review.openstack.org/#/c/296646/10

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

Re: [openstack-dev] [fuel] Unrelated changes in patches

[Jason Rist]

On 04/04/2016 07:05 AM, Matthew Mosesohn wrote:
> Hi Dmitry,
>
> I've seen several cases where core reviewers bully contributors into
> refactoring a particular piece of logic because it contains common
> lines relating to some non-ideal code, even if the change doesn't
> relate to this logic.
> In general, I'm ok with formatting issues, but changing how a piece of
> existing code works is over the line. It should be handled as a
> separate bug.
>
> But yes, in general, if someone complains about something unrelated to
> your patch, he or she should just file a bug with what is required.
>
> -Matthew
>
>
> On Mon, Apr 4, 2016 at 3:46 PM, Dmitry Guryanov  
> wrote:
> > Hello, colleagues!
> >
> > It's often not so easy to decide, if you should include some unrelated
> > changes to your patch, like fixing spaces, renaming variables or something
> > else, which don't change logic. On the one hand you see something's wrong
> > with the code and you'd like to fix it, on the other hand reviewers can vote
> > of -1 and you'll have to fix you patch and upload it again and this is very
> > annoying. You can also create separate review for such changes, but it will
> > require additional effort from you and reviewers.
> >
> > If you are a reviewer, and you've noted unrelated changes you may hesitate,
> > if you should ask an author to remove them and upload new version of the
> > patch or not. Also such extra changes may confuse you sometimes.
> >
> > So I suggest creating separate patches for unrelated changes if they add new
> > chucks to patch. And I'd like to ask authors to clearly state in the subject
> > of a commit message, that this patch just fixes formatting. And reviewers
> > shouldn't check such patches too severely, so that they'll get into repo as
> > soon as possible.
> >
> > What do you think?
> >
> >
> > --
> > Dmitry Guryanov
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
I agree with Matthew, but huge +1 to separate patch/bug for 
formatting/whitespace issues.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

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

Re: [openstack-dev] [sahara][release] missing build artifacts

[michael mccune]

On 04/01/2016 04:48 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2016-04-01 16:27:42 -0400:

Sahara team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for sahara-extras point to missing files. The
repository doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear
how tagging is producing a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't appear
to be any actual related deliverables
(https://review.openstack.org/300647).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?


the sahara-extras repository holds mainly examples for working with 
sahara. it does, however, contain a crucial part of our image 
deployments, namely the hadoop-openstack connector for accessing swift 
with keystone v3 authentication from within hadoop.


with that said though, i think you are correct that we do not actually 
produce a build from this repo. i'm not 100% sure on that, and would 
like to hear from our build wizards. this repository is useful to our 
users though, i'm just not sure how we should be fitting it into the 
larger picture of releases.




Thanks,
Doug



I forgot to mention that https://review.openstack.org/#/c/300474
includes some changes to add the simple server publishing jobs. If you
want to use those, please +1 the patch.

Doug

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




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

[openstack-dev] [Neutron][networking-ovn] Changing OVN plugin release model for Newton

[Russell Bryant]

Hello, everyone.

While bootstrapping networking-ovn, the release model has been
"release:independent" [1], though we haven't actually made any releases.
This follows the state of OVN itself, which is still fast moving and
developed in OVS master.

On the OVN side, we're now targeting a first production release in time for
the OpenStack Newton release.  We aim to branch OVS (which includes OVN) in
July and release by September or so.

I think it's time to start making releases of the Neutron plugin.  I
suggest we adopt "release:cycle-with-milestones" [2] to match the primary
Neutron repositories.

Thoughts?

[1] http://governance.openstack.org/reference/tags/release_independent.html
​[2]
http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
​

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

Re: [openstack-dev] [fuel] Unrelated changes in patches

[Matthew Mosesohn]

Hi Dmitry,

I've seen several cases where core reviewers bully contributors into
refactoring a particular piece of logic because it contains common
lines relating to some non-ideal code, even if the change doesn't
relate to this logic.
In general, I'm ok with formatting issues, but changing how a piece of
existing code works is over the line. It should be handled as a
separate bug.

But yes, in general, if someone complains about something unrelated to
your patch, he or she should just file a bug with what is required.

-Matthew


On Mon, Apr 4, 2016 at 3:46 PM, Dmitry Guryanov  wrote:
> Hello, colleagues!
>
> It's often not so easy to decide, if you should include some unrelated
> changes to your patch, like fixing spaces, renaming variables or something
> else, which don't change logic. On the one hand you see something's wrong
> with the code and you'd like to fix it, on the other hand reviewers can vote
> of -1 and you'll have to fix you patch and upload it again and this is very
> annoying. You can also create separate review for such changes, but it will
> require additional effort from you and reviewers.
>
> If you are a reviewer, and you've noted unrelated changes you may hesitate,
> if you should ask an author to remove them and upload new version of the
> patch or not. Also such extra changes may confuse you sometimes.
>
> So I suggest creating separate patches for unrelated changes if they add new
> chucks to patch. And I'd like to ask authors to clearly state in the subject
> of a commit message, that this patch just fixes formatting. And reviewers
> shouldn't check such patches too severely, so that they'll get into repo as
> soon as possible.
>
> What do you think?
>
>
> --
> Dmitry Guryanov
>
> __
> OpenStack Development Mailing 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][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Dan Prince]

On Mon, 2016-04-04 at 02:31 +, Steven Dake (stdake) wrote:
> 
> On 4/3/16, 6:38 PM, "Dan Prince"  wrote:
> 
> > 
> > 
> > 
> > 
> > On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote:
> > > 
> > > As of the Liberty release, Magnum now supports provisioning Mesos
> > > clusters, so TripleO wouldn't have to maintain the installer for
> > > that 
> > > either. (The choice of Mesos is somewhat unfortunate in our case,
> > > because Magnum's Kubernetes support is much more mature than its
> > > Mesos 
> > > support, and because the reasons for the decision are about to be
> > > or
> > > have already been overtaken by events - I've heard reports that
> > > the
> > > features that Kubernetes was missing to allow it to be used for
> > > controller nodes, and maybe even compute nodes, are now
> > > available.
> > > Nonetheless, I expect the level of Magnum support for Mesos is
> > > likely 
> > > workable.) This is where the TripleO strategy of using OpenStack
> > > to
> > > deploy OpenStack can really pay dividends: because we use Ironic
> > > all
> > > of 
> > > our servers are accessible through the Nova API, so in theory we
> > > can
> > > just run Magnum out of the box.
> > > 
> > > 
> > > The chances of me personally having time to prototype this are
> > > slim-to-zero, but I think this is a path worth investigating.
> > Looking at Magnum more closely... At a high level I like the idea
> > of
> > Magnum. And interestingly it could be a surprisingly good fit for
> > someone wanting containers on baremetal to consider using the
> > TripleO
> > paving machine (instack-undercloud).
> Dan,
> 
> When I originally got involved in Magnum and submitted the first 100
> or so
> patches to the repository to kick off development, my thinking was to
> use
> Magnum as an integration point for Kubernetes for Kolla (whiich at
> the
> time had no ansible but kubernetes pod files instead) running an
> atomic
> distro.
> 
> It looked good on paper but in practice, all those layers and
> dependencies
> introduced unnecessary complexity making the system I had envisioned
> unwieldy and more complex then the U.S. Space Shuttle.
> 
> When I finally took off my architecture astronaut helmet, I went back
> to
> basics and dismissed the idea of a Magnum and a tripleo integration.
> 
> Remember, that was my idea - and I gave up on it - for a reason.
> 
> Magnum standalone, however, is still very viable and I like where the
> core
> reviewer team has taken Magnum since I stopped participation in that
> project.
> 
> I keep telling people underlays for OpenStack deployment are much
> more
> complex then they look and are 5-10 years down the road.  Yet people
> keep
> trying - good for them ;)
> 
> Regards
> -steve


I don't think we can just leave it at "it is complex". For me
understanding the services it uses, the architecture that it sets up,
and how we would probably try to consume that is the required
information. Perhaps there are other docs out there on these things but
nobody pointed me to them so I just went and looked at Magnum myself.

The reason I listed these things is because Magnum continually comes up
as the go-to project for container integration within TripleO. I wanted
some details about why... not just the fact that it had been tried
before and didn't work out for Kolla in past months or years.

Anyways, If you read all of my reply you'll see that I also reach a
similar conclusions on where Magnum stands today. And if we added
Magnum support (which again would be a cool thing to do I think) it
would probably be targeted for use as a generic standalone baremetal
containers installer. And not as an OpenStack deployment tool. At least
not until Magnum matures a bit...

Dan

> 
> 
> 
> > 
> > 
> > We would need to add a few services I think to instack to supply
> > the
> > Magnum heat templates with the required API's. Specifically:
> > 
> > -barbican
> > -neutron L3 agent
> > -neutron Lbaas
> > -Magnum (API, and conductor)
> > 
> > This isn't hard and would be a cool thing to have supported withing
> > instack (although I wouldn't enable these services by default I
> > think... at least not for now).
> > 
> > So again, at a high level things look good. Taking a closer look at
> > how
> > Magnum architects its network things start to fall apart a bit I
> > think.
> > From what I can tell the Magnum network architecture with its usage
> > of
> > the L3 agent, and Lbaas the undercloud itself would be much more
> > important. Depending on the networking vendor we would possibly
> > need to
> > make the Undercloud itself HA in order to ensure anything built on
> > top
> > was also HA. Contrast this with the fact that you can deploy an
> > Overcloud today that will continue to function should the
> > undercloud
> > (momentarily) go down.
> > 
> > Then there is the fact that Magnum would be calling Heat to create
> > our
> > baremetal servers (Magnum creates the OS::Nova::Server resources...
> > not
> > our own Heat templa

[openstack-dev] [fuel] Unrelated changes in patches

[Dmitry Guryanov]

Hello, colleagues!

It's often not so easy to decide, if you should include some unrelated
changes to your patch, like fixing spaces, renaming variables or something
else, which don't change logic. On the one hand you see something's wrong
with the code and you'd like to fix it, on the other hand reviewers can
vote of -1 and you'll have to fix you patch and upload it again and this is
very annoying. You can also create separate review for such changes, but it
will require additional effort from you and reviewers.

If you are a reviewer, and you've noted unrelated changes you may hesitate,
if you should ask an author to remove them and upload new version of the
patch or not. Also such extra changes may confuse you sometimes.

So I suggest creating separate patches for unrelated changes if they add
new chucks to patch. And I'd like to ask authors to clearly state in the
subject of a commit message, that this patch just fixes formatting. And
reviewers shouldn't check such patches too severely, so that they'll get
into repo as soon as possible.

What do you think?


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

[openstack-dev] [puppet] weekly meeting #77

[Emilien Macchi]

Hi,

We'll have our weekly meeting tomorrow at 3pm UTC on
#openstack-meeting4.

https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack

As usual, free free to bring topics in this etherpad:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160405

We'll also have open discussion for bugs & reviews, so anyone is welcome
to join.

Note: I'll be away this day, Denis will chair the meeting.

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