[openstack-dev] [vitrage] Next Vitrage IRC meeting will be SKIPPED

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

As many Vitrage developers will be on vacation next week, the IRC meeting on 
April 12 will be SKIPPED.
We will meet again on April 19.

Thanks,
Ifat.

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

[openstack-dev] [QA] Meeting Thursday April 6th at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, April 6th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_6th_2017_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
OpenStack Development Mailing List (not for 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] Risk prediction model for OpenStack

[林泽燕]

Hi Jeremy,
I did ignore the impact of code review. Thank you for reminding. 

Zoey Lin


> -原始邮件-
> 发件人: "Jeremy Stanley" 
> 发送时间: 2017-04-05 22:00:28 (星期三)
> 收件人: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 抄送: 
> 主题: Re: [openstack-dev] [nova] Risk prediction model for OpenStack
> 
> On 2017-04-05 14:00:59 +0800 (+0800), 林泽燕 wrote:
> [...]
> > I wonder if I could show you my study, including some metrics for
> > the prediction model and a visualization tool.
> [...]
> 
> I want to start out thanking you for your research and interest in
> OpenStack's development practices. I love that our contribution
> model enables such scientific analysis, a sometimes less recognized
> benefit of our community's choice to work entirely in the open. This
> specific study is also very insightful and well-presented.
> 
> > In this release, 36 developers left the development of this file
> > (they made contributions in last release but not this one).
> > Developers leaving a code file deprive the file of the knowledge
> > of the decisions they have made.
> [...]
> 
> One potentially influential aspect of our development model is that
> we place a heavy importance on code review. For any patch to make it
> into a branch under official revision control, it must first be
> reviewed by multiple experienced, long-standing contributors to that
> repository. Our hope is that even though some developers may cease
> contributing new patches to a file, some of them would still be
> reviewing, guiding and refining changes proposed by newer
> contributors. It doesn't seem like this behavior was captured in
> your analysis, or alternatively the fact that your model yielded
> relatively accurate predictions could imply that our review process
> has little impact on defects introduced by new commits.
> 
> If you do at some point wish to try integrating review metrics into
> your analysis, our code review system has a REST API you can
> leverage, and much of the data you'd likely be interested in can be
> queried via anonymous methods such that you wouldn't even need to
> create an account. Documentation for the interface is available at
> https://review.openstack.org/Documentation/rest-api.html and we also
> have documentation of our general developer workflow at
> https://docs.openstack.org/infra/manual/developers.html as well as
> some background on our development model at
> https://docs.openstack.org/project-team-guide/open-development.html
> if that helps.
> -- 
> 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



Best regards!
——
Zeyan Lin
Department of Computer Science
School of Electronics Engineering & Computer Science
Peking University
Beijing 100871, China
E-mail：linze...@pku.edu.cn
__
OpenStack Development Mailing List (not for 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] How to get all detail RPC message and detail context in neutron docs?

[Sam]

For example, detail of the messages of topics.L3_AGENT

2017-04-06 9:38 GMT+08:00 Sam :

> Thank you all.
>
> For 'context', I got it.
> For RPCs, is there some document or blog or some debug method to get its
> detal contains in neutron L3 Agent?
>
> 2017-04-06 9:33 GMT+08:00 김기석 [Kiseok Kim] :
>
>> Hi Sam,
>>
>>
>>
>> that 'context' is olso_context and neutron use it with addition
>> attributes.
>>
>>
>>
>> oslo.context has to_dict method,
>>
>> so you could add debug log in 'agent_updated' method like:
>>
>>
>>
>>LOG.debug("context in agent_updated: %s", context.to_dict())
>>
>>
>>
>> and you can find out the attributes of context in
>>
>> https://github.com/openstack/neutron-lib/blob/master/neutron
>> _lib/context.py#L83-L92,
>>
>> https://github.com/openstack/oslo.context/blob/master/oslo_c
>> ontext/context.py#L310-L332
>>
>> .
>>
>>
>>
>> *From:* Sam [mailto:batmanu...@gmail.com]
>> *Sent:* Wednesday, April 05, 2017 7:10 PM
>> *To:* OpenStack General; OpenStack Development Mailing List (not for
>> usage questions)
>> *Subject:* [Openstack] How to get all detail RPC message and detail
>> context in neutron docs?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I'm working on neutron L3 Agent and some other Agent. I found that there
>> are lots of RPCs including RPC call and notification and lots of 'context'
>> as bellow. But I don't know its detail context, can I get these from some
>> docs?
>>
>>
>>
>> If there are no docs, could I get these using some debug method? Like
>> '--debug' option or using pdb or something?
>>
>>
>>
>> RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.
>>
>>
>>
>> context: it's param in some function like 'def
>> router_added_to_agent(self, context, payload):' in
>> neutron/neutron/agent/l3/agent.py.
>>
>
>
__
OpenStack Development Mailing List (not for 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] How to get all detail RPC message and detail context in neutron docs?

[Sam]

Thank you all.

For 'context', I got it.
For RPCs, is there some document or blog or some debug method to get its
detal contains in neutron L3 Agent?

2017-04-06 9:33 GMT+08:00 김기석 [Kiseok Kim] :

> Hi Sam,
>
>
>
> that 'context' is olso_context and neutron use it with addition attributes.
>
>
>
> oslo.context has to_dict method,
>
> so you could add debug log in 'agent_updated' method like:
>
>
>
>LOG.debug("context in agent_updated: %s", context.to_dict())
>
>
>
> and you can find out the attributes of context in
>
> https://github.com/openstack/neutron-lib/blob/master/
> neutron_lib/context.py#L83-L92,
>
> https://github.com/openstack/oslo.context/blob/master/oslo_
> context/context.py#L310-L332
>
> .
>
>
>
> *From:* Sam [mailto:batmanu...@gmail.com]
> *Sent:* Wednesday, April 05, 2017 7:10 PM
> *To:* OpenStack General; OpenStack Development Mailing List (not for
> usage questions)
> *Subject:* [Openstack] How to get all detail RPC message and detail
> context in neutron docs?
>
>
>
> Hi all,
>
>
>
> I'm working on neutron L3 Agent and some other Agent. I found that there
> are lots of RPCs including RPC call and notification and lots of 'context'
> as bellow. But I don't know its detail context, can I get these from some
> docs?
>
>
>
> If there are no docs, could I get these using some debug method? Like
> '--debug' option or using pdb or something?
>
>
>
> RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.
>
>
>
> context: it's param in some function like 'def router_added_to_agent(self,
> context, payload):' in neutron/neutron/agent/l3/agent.py.
>
__
OpenStack Development Mailing List (not for 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] How to get all detail RPC message and detail context in neutron docs?

[김기석 [Kiseok Kim]]

Hi Sam,

that 'context' is olso_context and neutron use it with addition attributes.

oslo.context has to_dict method,
so you could add debug log in 'agent_updated' method like:

   LOG.debug("context in agent_updated: %s", context.to_dict())

and you can find out the attributes of context in
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py#L83-L92,
https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L310-L332
.

From: Sam [mailto:batmanu...@gmail.com]
Sent: Wednesday, April 05, 2017 7:10 PM
To: OpenStack General; OpenStack Development Mailing List (not for usage 
questions)
Subject: [Openstack] How to get all detail RPC message and detail context in 
neutron docs?

Hi all,

I'm working on neutron L3 Agent and some other Agent. I found that there are 
lots of RPCs including RPC call and notification and lots of 'context' as 
bellow. But I don't know its detail context, can I get these from some docs?

If there are no docs, could I get these using some debug method? Like '--debug' 
option or using pdb or something?

RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.

context: it's param in some function like 'def router_added_to_agent(self, 
context, payload):' in neutron/neutron/agent/l3/agent.py.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] experimenting with systemd for services

[Matt Riedemann]

On 4/5/2017 3:09 PM, Sean Dague wrote:

At the PTG clayg brought up an excellent question about what the
expected flow was to restart a bunch of services in devstack after a
code changes that impacts many of them (be it common code, or a
library). People had created a bunch of various screen hacks over the
years, but screen is flakey, and this is definitely not an ideal workflow.

Over lunch clayg, clarkb, and I chatted about some options. Clark
brought up the idea of doing systemd units for all of the services. A
couple of weeks ago I decided it was time for me to understand systemd
better anyway, and started playing around with what this might look like.

The results landed here https://review.openstack.org/#/c/448323/.
Documentation is here
http://git.openstack.org/cgit/openstack-dev/devstack/tree/SYSTEMD.rst

This is currently an opt in. All the services in base devstack however
do work in this new model, and I and a few others have been using this
mode the last week or so. It's honestly really great. Working on
oslo.log changes it's now:

pip install -U .
sudo systemctl restart devstack@*

And the change is now in all your services.

There is also an oslo.log change for native systemd journal support
(https://review.openstack.org/#/c/451525/), which once that has landed
and been released, will let us do some neat query of the journal during
development to see slices across services like this
https://dague.net/2017/03/30/in-praise-of-systemd/.

ACTION REQUIRED:

If you maintain a devstack plugin that starts any services, now would be
a great time to test to see if this works for them. The biggest issue is
that the commands sent to run_process need to be absolute pathed.


My hope is that by end of cycle this is going to be the default mode in
devstack for *both* the gate and development, which eliminates one major
difference between the two. I'm also hoping that we'll be able to keep
and archive the journals from the runs, so you can download and query
those directly. Especially once the oslo.log enhancements are there to
add the additional structured data.

-Sean



Cool. I've always wanted this. When I started on OpenStack I was used to 
using sysv-init files and service commands with RHEL and wasn't used to 
screen, so pretty much hated that in devstack but felt like I couldn't 
ever express that because all of the cool kids loved screen so much.


Well well well, how the tables have turned.

--

Thanks,

Matt

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

Re: [openstack-dev] [tripleo] pingtest vs tempest

[Joe Talerico]

On Wed, Apr 5, 2017 at 4:49 PM, Emilien Macchi  wrote:
> Greetings dear owls,
>
> I would like to bring back an old topic: running tempest in the gate.
>
> == Context
>
> Right now, TripleO gate is running something called pingtest to
> validate that the OpenStack cloud is working. It's an Heat stack, that
> deploys a Nova server, some volumes, a glance image, a neutron network
> and sometimes a little bit more.
> To deploy the pingtest, you obviously need Heat deployed in your overcloud.
>
> == Problems:
>
> Although pingtest has been very helpful over the last years:
> - easy to understand, it's an Heat template, like an OpenStack user
> would do to deploy their apps.
> - fast: the stack takes a few minutes to be created and validated
>
> It has some limitations:
> - Limitation to what Heat resources support (example: some OpenStack
> resources can't be managed from Heat)
> - Impossible to run a dynamic workflow (test a live migration for example)
>
> == Solutions
>
> 1) Switch pingtest to Tempest run on some specific tests, with feature
> parity of what we had with pingtest.
> For example, we could imagine to run the scenarios that deploys VM and
> boot from volume. It would test the same thing as pingtest (details
> can be discussed here).
> Each scenario would run more tests depending on the service that they
> run (scenario001 is telemetry, so it would run some tempest tests for
> Ceilometer, Aodh, Gnocchi, etc).
> We should work at making the tempest run as short as possible, and the
> close as possible from what we have with a pingtest.
>
> 2) Run custom scripts in TripleO CI tooling, called from the pingtest
> (heat template), that would run some validations commands (API calls,
> etc).
> It has been investigated in the past but never implemented AFIK.
>
> 3) ?

Browbeat isn't a "validation" tool, like Tempest, however we have
Browbeat integrated in some CI systems already. We could create a very
targeted test to sniff out any issues with the Cloud.

>
> I tried to make this text short and go straight to the point, please
> bring feedback now. I hope we can make progress on $topic during Pike,
> so we can increase our testing coverage and detect deployment issues
> sooner.
>
> 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

__
OpenStack Development Mailing List (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] Save the Date- Queens PTG

[Erin Disney]

We are excited to announce the September Project Teams Gathering in Denver, CO 
at the Denver Renaissance Stapleton Hotel this September 11th-15th.

As mentioned at the Atlanta PTG feedback session in February, we had narrowed 
down our PTG location options to Denver and Montreal. Based on attendee 
feedback we received in Atlanta, we knew keeping room rates down was a priority 
and are excited we were able to negotiate a $149/night for attendees in Denver 
versus nearly $200/night in Montreal.

We are sensitive to international travel and have heard and understand concerns 
regarding both travel to and from the U.S. amidst political uncertainty. We are 
reviewing options for remote participation for those unable to join us in 
person. Moving forward, we are planning to host the February/March 2018 PTG in 
Europe. Stay tuned for additional information on future locations for the PTG 
and look forward to Sydney in November 2017 and Vancouver in May 2018 for the 
upcoming OpenStack Summits.

We will share registration and sponsorship information soon on this mailing 
list. Mark your calendars and we hope to see you in Denver!

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

Re: [openstack-dev] [ironic] New contributor

[Rochelle Grober]

Welcome!

And, of course, writing tests that demonstrate some of those more difficult 
open bugs would help make sure they don't resurface once fixed ;-)  so, if you 
can't get a handle yet on the intricacies of the the code that contains the 
issue, you still might be able to demonstrate the breakage and get kudos for 
that.

At least, I'd give you kudos for that!

--Rocky

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com] 
Sent: Wednesday, April 05, 2017 4:42 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [ironic] New contributor

On 03/30/2017 05:13 AM, Julian Edwards wrote:
> Hi all

Hi and welcome!

>
> I'm looking to start contributing to Ironic, and in fact I did a 
> couple of small patches already which are still waiting to be 
> landed/reviewed. [1]
>
> I'm finding it a little hard to find some more reasonable bugs to get 
> started with fixing, so if any of you guys can point me at a few I 
> would appreciate it, or indeed if someone is willing to do more 
> involved mentoring.  (I am in the +10 time zone so this may be 
> awkward, sadly)

Indeed, as Jay already mentioned, we have a competitions for easier bugs right 
now :) Please keep in mind, though, that carefully reviewing others patches is 
often more valuable, than adding more patches to the queue. This may be a good 
way to both help the project and learn it better.

>
> Cheers
> J
>
> PS  Some of you may remember me as the original Ubuntu MAAS lead, so I 
> am pretty familiar with bare metal stuff generally.
>
> [1] https://review.openstack.org/#/c/449454/ and 
> https://review.openstack.org/#/c/450492/
>
> __
>  OpenStack Development Mailing List (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] [policy][nova][keystone] policy meeting next week

[Lance Bragstad]

We ended up cancelling today's policy meeting, but policy discussions
carried on throughout the day in #openstack-keystone [0]. We have several
specs up for review [1][2][3][4]. Some are nova specs and a couple are
proposed to keystone. With keystone's spec proposal freeze coming up next
week [5], this is our last shot to collaborate on new ideas if we want to
propose any for Pike.

I'm sending out this note to ask folks interested in the policy discussions
to have a look at the proposed specs. Next week's meeting will be focused
on having detailed discussions about them.

If you just can't wait to start talking about policy until next week, come
find me in #openstack-dev. Pre-discussions might help maximize our meeting
next week.

Thanks!

[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-04-05.log.html#t2017-04-05T16:24:29
[1] https://review.openstack.org/#/c/427872/
[2] https://review.openstack.org/#/c/433037/
[3] https://review.openstack.org/#/c/452198/
[4] https://review.openstack.org/#/c/453739/
[5]
https://releases.openstack.org/pike/schedule.html#p-keystone-spec-proposal-freeze
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] experimenting with systemd for services

[Clay Gerrard]

On Wed, Apr 5, 2017 at 1:30 PM, Andrea Frittoli 
wrote:
>
>
> I just want to say thank you! to you clarkb clayg and everyone involved :)
> This is so much better!
>
> andreaf
>
>
Sean is throwing credit at me where none is due.  IIRC I was both in the
room and in a very-normal-for-me state of confusion while he and clark
talked about this - but I did not know they were working on it.
Nevertheless, I am dusting off my devstack vm with USE_SYSTEMD=True and
found his blog post interesting ;)

Kudos!

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

[openstack-dev] [tripleo] pingtest vs tempest

[Emilien Macchi]

Greetings dear owls,

I would like to bring back an old topic: running tempest in the gate.

== Context

Right now, TripleO gate is running something called pingtest to
validate that the OpenStack cloud is working. It's an Heat stack, that
deploys a Nova server, some volumes, a glance image, a neutron network
and sometimes a little bit more.
To deploy the pingtest, you obviously need Heat deployed in your overcloud.

== Problems:

Although pingtest has been very helpful over the last years:
- easy to understand, it's an Heat template, like an OpenStack user
would do to deploy their apps.
- fast: the stack takes a few minutes to be created and validated

It has some limitations:
- Limitation to what Heat resources support (example: some OpenStack
resources can't be managed from Heat)
- Impossible to run a dynamic workflow (test a live migration for example)

== Solutions

1) Switch pingtest to Tempest run on some specific tests, with feature
parity of what we had with pingtest.
For example, we could imagine to run the scenarios that deploys VM and
boot from volume. It would test the same thing as pingtest (details
can be discussed here).
Each scenario would run more tests depending on the service that they
run (scenario001 is telemetry, so it would run some tempest tests for
Ceilometer, Aodh, Gnocchi, etc).
We should work at making the tempest run as short as possible, and the
close as possible from what we have with a pingtest.

2) Run custom scripts in TripleO CI tooling, called from the pingtest
(heat template), that would run some validations commands (API calls,
etc).
It has been investigated in the past but never implemented AFIK.

3) ?

I tried to make this text short and go straight to the point, please
bring feedback now. I hope we can make progress on $topic during Pike,
so we can increase our testing coverage and detect deployment issues
sooner.

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

Re: [openstack-dev] [devstack] experimenting with systemd for services

[Andrea Frittoli]

On Wed, Apr 5, 2017 at 9:14 PM Sean Dague  wrote:

> At the PTG clayg brought up an excellent question about what the
> expected flow was to restart a bunch of services in devstack after a
> code changes that impacts many of them (be it common code, or a
> library). People had created a bunch of various screen hacks over the
> years, but screen is flakey, and this is definitely not an ideal workflow.
>
> Over lunch clayg, clarkb, and I chatted about some options. Clark
> brought up the idea of doing systemd units for all of the services. A
> couple of weeks ago I decided it was time for me to understand systemd
> better anyway, and started playing around with what this might look like.
>
> The results landed here https://review.openstack.org/#/c/448323/.
> Documentation is here
> http://git.openstack.org/cgit/openstack-dev/devstack/tree/SYSTEMD.rst
>
> This is currently an opt in. All the services in base devstack however
> do work in this new model, and I and a few others have been using this
> mode the last week or so. It's honestly really great. Working on
> oslo.log changes it's now:
>
> pip install -U .
> sudo systemctl restart devstack@*
>
> And the change is now in all your services.
>
> There is also an oslo.log change for native systemd journal support
> (https://review.openstack.org/#/c/451525/), which once that has landed
> and been released, will let us do some neat query of the journal during
> development to see slices across services like this
> https://dague.net/2017/03/30/in-praise-of-systemd/.
>

I just want to say thank you! to you clarkb clayg and everyone involved :)
This is so much better!

andreaf


> ACTION REQUIRED:
>
> If you maintain a devstack plugin that starts any services, now would be
> a great time to test to see if this works for them. The biggest issue is
> that the commands sent to run_process need to be absolute pathed.
>
>
> My hope is that by end of cycle this is going to be the default mode in
> devstack for *both* the gate and development, which eliminates one major
> difference between the two. I'm also hoping that we'll be able to keep
> and archive the journals from the runs, so you can download and query
> those directly. Especially once the oslo.log enhancements are there to
> add the additional structured data.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] New upgrade test tool proposal.

[Martinez, Castulo]

Hi,

As you might know, the TC introduced new tags [1] for upgrade processes
quite some time ago, which reflect the level of maturity of an upgrade.
Therefore there is the growing need of test tools which help to exercise
and validate the upgrade approaches defined by the community.

During the PTG at Atlanta there were discussions around options for
covering this gap in testing tools, one proposal was to add this
functionality to Grenade, but this idea was dismissed since it was
determined that Grenade was originally designed for a different purpose
and is already pushing its limits, so the consensus was towards
creating a new tool to fill this gap.

We are proposing a new toolset for testing an OpenStack environment
before, during, and after an upgrade process. The toolset answers the
question ³how does OpenStack behave across upgrades from one release N
to a release N+1, or from the latest official release to master?². It
also provides information that can be used to assess if an upgrade
complies with the requirements for being recognized as a rolling
upgrade, a zero downtime upgrade or a zero impact upgrade.

Before starting this effort, we would like to hear feedback from
everybody, are there any concerns with this approach? Are we missing
something?

You can find details of this proposal here:
https://review.openstack.org/#/c/449295/3

Thanks

--
Castulo J. Martinez


[1] 
https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-
upgrade.html

https://governance.openstack.org/tc/reference/tags/assert_supports-zero-dow
ntime-upgrade.html

https://governance.openstack.org/tc/reference/tags/assert_supports-zero-imp
act-upgrade.html


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

[openstack-dev] [devstack] experimenting with systemd for services

[Sean Dague]

At the PTG clayg brought up an excellent question about what the
expected flow was to restart a bunch of services in devstack after a
code changes that impacts many of them (be it common code, or a
library). People had created a bunch of various screen hacks over the
years, but screen is flakey, and this is definitely not an ideal workflow.

Over lunch clayg, clarkb, and I chatted about some options. Clark
brought up the idea of doing systemd units for all of the services. A
couple of weeks ago I decided it was time for me to understand systemd
better anyway, and started playing around with what this might look like.

The results landed here https://review.openstack.org/#/c/448323/.
Documentation is here
http://git.openstack.org/cgit/openstack-dev/devstack/tree/SYSTEMD.rst

This is currently an opt in. All the services in base devstack however
do work in this new model, and I and a few others have been using this
mode the last week or so. It's honestly really great. Working on
oslo.log changes it's now:

pip install -U .
sudo systemctl restart devstack@*

And the change is now in all your services.

There is also an oslo.log change for native systemd journal support
(https://review.openstack.org/#/c/451525/), which once that has landed
and been released, will let us do some neat query of the journal during
development to see slices across services like this
https://dague.net/2017/03/30/in-praise-of-systemd/.

ACTION REQUIRED:

If you maintain a devstack plugin that starts any services, now would be
a great time to test to see if this works for them. The biggest issue is
that the commands sent to run_process need to be absolute pathed.


My hope is that by end of cycle this is going to be the default mode in
devstack for *both* the gate and development, which eliminates one major
difference between the two. I'm also hoping that we'll be able to keep
and archive the journals from the runs, so you can download and query
those directly. Especially once the oslo.log enhancements are there to
add the additional structured data.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

[Monty Taylor]

The tone of this in inappropriate and not in keeping with our community 
code of conduct:


https://www.openstack.org/legal/community-code-of-conduct/

It is neither friendly, patient, welcoming, considerate or respectful. 
No attempt has been made to collaborate openly on a solution, or to 
understand why there is a disagreement.


There are legitimate issues that can be discussed on this topic, and 
legitimate areas of disagreement that can be explored. I would kindly 
request that in the future you engage with the team to try to understand 
what problem is being solved and if there is any way it could be improved.


I have behaved similarly inappropriately in the past, and it was 
important that I was called out for it.


On 04/05/2017 11:55 AM, Clay Gerrard wrote:

I hate this stuff.

Not just pbr (tho I do have a long history of being kicked in the nuts
by pbr for no good reason I can ascertain).  But when suddenly some
process OpenStack invented I've never *heard of in two years* breaks -
and overnight me and 100's of other folks have to stop what their doing
to read up on some esoteric thing they never bought into.

https://blueprints.launchpad.net/pbr/+spec/pbr-semver
https://review.openstack.org/#/c/108270/

"My use-case is to pretend every commit is a release.  And since I can't
expect you're going to manage something as complicated as your projects
*version* in between releases (obvs.).  Only possible solution is a new
esoteric procedure no one as ever heard of baked into your commit messages."

What could go wrong?

This in all my package build infrastructure *so hard*:

# Shut up, pbr, we know what we're doing
export PBR_VERSION="$DOWNSTREAM_VERSION"

As long as that doesn't break - I should probably just +2 the thing and
go back to keeping my mouth shut.  But ... why after 2 years of blissful
ignorance do I have to suddenly care about this nonsense?  I'm grepping
git logs from Nova, Cinder, Keystone, Swift - what am I missing - who's
using this!?

Please forgive my obviously frustrated tone - I do understand form the
spec and reviews that folks have over time put a lot of thought into
this and I'm not going to fully understand it in an hour of cursory
glance.  Which is... kinda of why I'm frustrated.  This stuff is
maddness and it's in my way.

-Clay

On Wed, Apr 5, 2017 at 9:08 AM, Akihiro Motoki > wrote:

I see Emilien proposed a number of patches to individual projects with
"Sem-Ver: api-break" in the commit message.
As far as I understand the pbr documentation [1] correctly (see the
forth paragraph in the section) which is pointed by Emilien,
the change looks reasonable.

Honestly it would be great if we have a green signal for the similar
change as a community
as not all developers are familiar with this kind of changes.

Can all developers get the green signal for the similar change?

Akihiro

[1] https://docs.openstack.org/developer/pbr/#version



2017-04-05 10:36 GMT+09:00 Emilien Macchi >:
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi
> wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec > wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley >:
 In the past we addressed this by automatically merging the release
 tag back into master, but we stopped doing that a cycle ago because
 it complicated release note generation.
>>>
>>> Also this was including RC >= 2 and final tags so as soon as the
first
>>> stable maintenance version was released, master was again lower
>>> version.
>>
>> topic sounds staled.
>> Alan,  do we have an ETA on the RDO workaround?
>
> Without progress on RDO tooling and the difficulty of implementing it,
> I went ahead and proposed a semver bump for some projects:
>
> https://review.openstack.org/#/q/topic:sem-ver/pike

>
> Except for Swift where I don't know if they'll bump X, I proposed
to bump Y.
> For all other projects, I bumped X as they did from Newton to Ocata.
> (where version is X.Y.Z).
>
> Please give any feedback on the reviews if you prefer another kind
of bump.
> Thanks for reviewing that asap, so TripleO CI can test upgrades from
> Ocata to Pike soon.
>
> Thanks,
>
>> Thanks,
>>
>>> Cheers,
>>> Alan
>>>
>>>
__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:

[openstack-dev] [nova] Heads up: novaclient 8.0 is dropping a bunch of proxy code

[Matt Riedemann]

We deprecated a bunch of proxy APIs and CLIs with the 2.36 microversion 
in the Newton release. We bent over backward to make the CLI fall back 
to 2.35 if using a deprecated proxy in novaclient but that code is all 
removed now, and will be gone in the upcoming novaclient 8.0.0 release [1].


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

--

Thanks,

Matt

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

[openstack-dev] [election] [tc] TC candidacy

[Chris Dent]

Hi, I'm Chris Dent, cdent on IRC.

I'm once again nominating myself to be your representative on the
Technical Committee. I've been around OpenStack for about three
years, most recently visible as the guy who writes those weekly
updates about the placement API service and talks about the
API-WG.

In the past several months we've seen the TC starting to take a more
active role in describing and shaping the technical and cultural
environment of OpenStack. Initiatives like release goals, TC and
OpenStack vision exercises, discussions on how to reasonably
constrain growth and increased attention to writing things down are
all positives.

Meanwhile the economic environment for cloud technology and for
technical contributors has been a roller coaster. Lots of things are
changing in the world of OpenStack.

OpenStack must adapt. Doing so without losing the progress that's
been made will be hard and requires input from a diversity of
voices; people who are willing and able to critique and investigate
the status quo but also understand the importance of consensus and
value of compromise.

Voting for the TC is weird: people nominate themselves and then a
small segment of the electorate places their votes based on some
combination of "have I heard of this person before", "have I
witnessed some of their work and liked it", and, sometimes,
discussion that happens as a result of these candidacy statements. I
hope you'll ask me some questions in the week before the election,
but in an effort to illustrate the biases and concerns I would bring
to the TC here are some opinions I have related to governance:

* Telling stories that explain what and why are more useful in the
  long run than listing rules of how because they lead to a more
  complete understanding.

* It is always better to over communicate than under communicate and
  it is best to do so in a written and discoverable fashion. Not just
  because this helps to keep everyone already involved up to date
  but because it also enables connections with new people and other
  communities.

* The OpenStack ecosystem needs to open up to allow and encourage
  those connections. Open ecosystems can evolve and benefit from
  exchange of ideas. So yes, of course, we should use some golang.
  Of course we should party with kubernetes and trade ideas with
  them.

* OpenStack is better when its people and its projects have opinions
  about lots of things, share those opinions widely, and use them to
  make better stuff and make better decisions.

* There are too many boundaries (some real, some perceived) between
  developers _of_ OpenStack, developers _using_ OpenStack, users,
  and operators. We're all in this together. All of those people
  should be encouraged and able to be contributors and all of those
  people should be users.

* OpenStack can and should do a lot of complicated stuff for big
  enterprises (things like NFV and high performance VMs) but the
  changes required to satisfy those use cases must always be
  balanced and measured against providing a useful and usable cloud
  for individual humans.

* As we move forward on the idea of OpenStack as one platform made
  with many pieces, we have an opportunity to re-evaluate and
  refactor our architecture and project structure to make it easier
  for improvement to happen. We need to ask ourselves if the
  boundaries we currently maintain, technical and social, are the
  right ones, and change the ones that are not.

* For a lot of people, contributing to OpenStack is a job. Working
  on OpenStack should be a good experience for everyone. I think
  of being a TC member as something akin to a union representative:
  striving to keep things sane and positive for the individual
  contributor in the face of change and conflict.

With the TC positioning itself to take a more active role, these
elections could be more important than you've come to expect.  The
people you choose, the attitudes they have, will shape that new
activism. If you feel like I'm talking some sense above, I'd
appreciate your vote. If you need some clarification, please ask me
some questions. After that, if you're still not convinced, please
vote for someone else. But please vote.

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

[openstack-dev] [election][tc] TC candidacy

[Dean Troyer]

I am Dean Troyer and would like to nominate myself as a candidate for
re-election to the Technical Committee.

I have been around OpenStack for a long time, primarily working on
DevStack, Grenade and OpenStackClient.

OpenStack has been going through the maturation process in the last
year or two and the explosive growth we experienced in our early years
has subsided.  As a community, we threw a lot of things against the
wall to see what would stick, and those answers are continuing to
become evident.  In come cases we can re-affirm the direction taken,
in others it has been time wrap up and move on.  All of which is a
long-winded way to say we have already begun making some hard
decisions about projects and future and direction.

The TC has begun a process of defining a vision[0] of where we want to
be by describing the OpenStack world as we see it in two years.  One
big part of that vision involved how we operate in the world around
us, ie, other related-but-not-OpenStack projects in the Open Source
cloud world.  We have already seen a good amount of time and effort
expended by OpenStack community members getting involved with other
projects such as Kubernetes and vendor-related products like
OpenShift.  It is imperative that we position ourselves to complement
and not compete with others in our greater community.

And yes, I am going exactly where most of you thought I was with this.
In recent months the TC has taken steps to define how languages that
are not Python might be used in OpenStack projects.  The language
addition process[1] was approved, the first use case analysis to use
Golang team was approved[2], a golang test inteface (CTI) has been
approved[3] and work is underway for implementing the required support
in our CI to test golang projects at the scale we need.

The world around us has changed and OpenStack needs to continue to
grow and adapt with it.  This is an important priority for me, having
written and prototyped the golang CTI.  OpenStack does not need to own
and control everything about building and deploying clouds, but there
are some critical things that we do need to keep close tabs on for the
sake of our deployers and users.  I am excited about some of the
things the OpenStack Foundation staff are working on with regards to
our external relationships, some of which is already visible in the
Boston Summit promotion.

I would be honored to continue serving the community on the Technical Committee.

Thank you
dt


[0] The first draft that came out of our session last month:
https://review.openstack.org/453262
[1] 
https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis
[2] 
https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.html
[3] https://governance.openstack.org/tc/reference/cti/golang_cti.html

-- 

Dean Troyer
dtro...@gmail.com

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

[openstack-dev] [ironic][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

[Nisha Agarwal]

Hi,

I suggested to add few pci devices related attributes to ironic
inspection(out-of-band as well inband).
https://review.openstack.org/#/c/338138.

I got the suggestion to convert them to standard pci device format which
nova understands. For example( as given in Nova code):
[{"count": 5, "vendor_id": "8086", "product_id": "1520",
 "extra_info":'{}'}],

For above to be supported for ironic scheduling, we will require changes at
two places:
1. nova - This should require a small code changes as pci_passthrough
filter already exists in nova. The ironic virt driver should be able to
consume the pci_device structure from ironic node/database and pass it on
to scheduler for scheduling and it should add pci_passthrough filter in
ironic nodes filter list.
2. ironic - this definitely needs a spec which will suggest to add the
pci_device data structure to ironic node.


The ironic side work may take some time but Nova side looks to be a small
change. IMO we can have the nova side changes and ironic database changes
(to add pci_device field) parallely.
Inspection can populate that new pci_device field for the node to get
scheduled.

AFAIK, ironic-inspector already has the plugin to discover pci devices in
the format nova has it today. If we get the scheduling enabled based on
pci_devices for ironic nodes, then inspector can write this data to ironic
node object by default.

What do you people think on this idea? Does it make sense? If its worth to
do this way i can own up this work.

Regards
Nisha

-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (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] [trove] today weekly meeting canceled

[Amrith Kumar]

There's nothing to discuss on the agenda today so I'm canceling the meeting
for today.

-amrith

--
Amrith Kumar
amrith.ku...@gmail.com




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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

[Davanum Srinivas]

Clay,

So the moral of the story is to "pay attention to what's happening
around you"? or something else?

Thanks,
Dims

On Wed, Apr 5, 2017 at 12:55 PM, Clay Gerrard  wrote:
> I hate this stuff.
>
> Not just pbr (tho I do have a long history of being kicked in the nuts by
> pbr for no good reason I can ascertain).  But when suddenly some process
> OpenStack invented I've never *heard of in two years* breaks - and overnight
> me and 100's of other folks have to stop what their doing to read up on some
> esoteric thing they never bought into.
>
> https://blueprints.launchpad.net/pbr/+spec/pbr-semver
> https://review.openstack.org/#/c/108270/
>
> "My use-case is to pretend every commit is a release.  And since I can't
> expect you're going to manage something as complicated as your projects
> *version* in between releases (obvs.).  Only possible solution is a new
> esoteric procedure no one as ever heard of baked into your commit messages."
>
> What could go wrong?
>
> This in all my package build infrastructure *so hard*:
>
> # Shut up, pbr, we know what we're doing
> export PBR_VERSION="$DOWNSTREAM_VERSION"
>
> As long as that doesn't break - I should probably just +2 the thing and go
> back to keeping my mouth shut.  But ... why after 2 years of blissful
> ignorance do I have to suddenly care about this nonsense?  I'm grepping git
> logs from Nova, Cinder, Keystone, Swift - what am I missing - who's using
> this!?
>
> Please forgive my obviously frustrated tone - I do understand form the spec
> and reviews that folks have over time put a lot of thought into this and I'm
> not going to fully understand it in an hour of cursory glance.  Which is...
> kinda of why I'm frustrated.  This stuff is maddness and it's in my way.
>
> -Clay
>
> On Wed, Apr 5, 2017 at 9:08 AM, Akihiro Motoki  wrote:
>>
>> I see Emilien proposed a number of patches to individual projects with
>> "Sem-Ver: api-break" in the commit message.
>> As far as I understand the pbr documentation [1] correctly (see the
>> forth paragraph in the section) which is pointed by Emilien,
>> the change looks reasonable.
>>
>> Honestly it would be great if we have a green signal for the similar
>> change as a community
>> as not all developers are familiar with this kind of changes.
>>
>> Can all developers get the green signal for the similar change?
>>
>> Akihiro
>>
>> [1] https://docs.openstack.org/developer/pbr/#version
>>
>>
>> 2017-04-05 10:36 GMT+09:00 Emilien Macchi :
>> > adding [all] for more visibility... See comments inline:
>> >
>> > On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi 
>> > wrote:
>> >> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>> >>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
>>  In the past we addressed this by automatically merging the release
>>  tag back into master, but we stopped doing that a cycle ago because
>>  it complicated release note generation.
>> >>>
>> >>> Also this was including RC >= 2 and final tags so as soon as the first
>> >>> stable maintenance version was released, master was again lower
>> >>> version.
>> >>
>> >> topic sounds staled.
>> >> Alan,  do we have an ETA on the RDO workaround?
>> >
>> > Without progress on RDO tooling and the difficulty of implementing it,
>> > I went ahead and proposed a semver bump for some projects:
>> >
>> > https://review.openstack.org/#/q/topic:sem-ver/pike
>> >
>> > Except for Swift where I don't know if they'll bump X, I proposed to
>> > bump Y.
>> > For all other projects, I bumped X as they did from Newton to Ocata.
>> > (where version is X.Y.Z).
>> >
>> > Please give any feedback on the reviews if you prefer another kind of
>> > bump.
>> > Thanks for reviewing that asap, so TripleO CI can test upgrades from
>> > Ocata to Pike soon.
>> >
>> > Thanks,
>> >
>> >> Thanks,
>> >>
>> >>> Cheers,
>> >>> Alan
>> >>>
>> >>>
>> >>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >>
>> >> --
>> >> Emilien Macchi
>> >
>> >
>> >
>> > --
>> > Emilien Macchi
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for 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][TripleO][release][deployment] Packaging problems due to branch/release ordering

[Clay Gerrard]

I hate this stuff.

Not just pbr (tho I do have a long history of being kicked in the nuts by
pbr for no good reason I can ascertain).  But when suddenly some process
OpenStack invented I've never *heard of in two years* breaks - and
overnight me and 100's of other folks have to stop what their doing to read
up on some esoteric thing they never bought into.

https://blueprints.launchpad.net/pbr/+spec/pbr-semver
https://review.openstack.org/#/c/108270/

"My use-case is to pretend every commit is a release.  And since I can't
expect you're going to manage something as complicated as your projects
*version* in between releases (obvs.).  Only possible solution is a new
esoteric procedure no one as ever heard of baked into your commit messages."

What could go wrong?

This in all my package build infrastructure *so hard*:

# Shut up, pbr, we know what we're doing
export PBR_VERSION="$DOWNSTREAM_VERSION"

As long as that doesn't break - I should probably just +2 the thing and go
back to keeping my mouth shut.  But ... why after 2 years of blissful
ignorance do I have to suddenly care about this nonsense?  I'm grepping git
logs from Nova, Cinder, Keystone, Swift - what am I missing - who's using
this!?

Please forgive my obviously frustrated tone - I do understand form the spec
and reviews that folks have over time put a lot of thought into this and
I'm not going to fully understand it in an hour of cursory glance.  Which
is... kinda of why I'm frustrated.  This stuff is maddness and it's in my
way.

-Clay

On Wed, Apr 5, 2017 at 9:08 AM, Akihiro Motoki  wrote:

> I see Emilien proposed a number of patches to individual projects with
> "Sem-Ver: api-break" in the commit message.
> As far as I understand the pbr documentation [1] correctly (see the
> forth paragraph in the section) which is pointed by Emilien,
> the change looks reasonable.
>
> Honestly it would be great if we have a green signal for the similar
> change as a community
> as not all developers are familiar with this kind of changes.
>
> Can all developers get the green signal for the similar change?
>
> Akihiro
>
> [1] https://docs.openstack.org/developer/pbr/#version
>
>
> 2017-04-05 10:36 GMT+09:00 Emilien Macchi :
> > adding [all] for more visibility... See comments inline:
> >
> > On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi 
> wrote:
> >> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
> >>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
>  In the past we addressed this by automatically merging the release
>  tag back into master, but we stopped doing that a cycle ago because
>  it complicated release note generation.
> >>>
> >>> Also this was including RC >= 2 and final tags so as soon as the first
> >>> stable maintenance version was released, master was again lower
> >>> version.
> >>
> >> topic sounds staled.
> >> Alan,  do we have an ETA on the RDO workaround?
> >
> > Without progress on RDO tooling and the difficulty of implementing it,
> > I went ahead and proposed a semver bump for some projects:
> >
> > https://review.openstack.org/#/q/topic:sem-ver/pike
> >
> > Except for Swift where I don't know if they'll bump X, I proposed to
> bump Y.
> > For all other projects, I bumped X as they did from Newton to Ocata.
> > (where version is X.Y.Z).
> >
> > Please give any feedback on the reviews if you prefer another kind of
> bump.
> > Thanks for reviewing that asap, so TripleO CI can test upgrades from
> > Ocata to Pike soon.
> >
> > Thanks,
> >
> >> Thanks,
> >>
> >>> Cheers,
> >>> Alan
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> --
> >> Emilien Macchi
> >
> >
> >
> > --
> > Emilien Macchi
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (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] [CNCF] Networking and Storage work groups

[Davanum Srinivas]

Looks like CNCF is setting up work groups around CNI and CSI, in case
anyone is interested

https://github.com/cncf/toc#working-groups
https://github.com/cncf/wg-storage/blob/master/README.md#members
https://github.com/cncf/wg-networking/blob/master/README.md#members

https://docs.google.com/document/d/1JMNVNP-ZHz8cGlnqckOnpJmHF-DNY7IYP-Di7iuVhQI/edit#
https://docs.google.com/document/d/15uuifCseiyUk5kPfnX5Cdj4VNjo79KkmFxm-_HisR3M/edit
https://docs.google.com/document/d/1rtbk27edum429Q5sEM5IP5FIu2i3qm7naXhZxFFJWs4/edit#

Thanks,
Dims

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

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

Re: [openstack-dev] [all] [tc] Technical Committee Vision draft

[Sean Dague]

On 04/05/2017 05:46 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> Last year in Ann Arbor, a group of OpenStack community members
> (including 6 current TC members) attended a Servant Leadership training
> at ZingTrain organized by Colette Alexander and funded by the OpenStack
> Foundation. We found that these concepts adapted quite well to our
> unique environment. The Stewardship working group was created to try to
> further those and decided to further those efforts. One of the tools we
> learned about there is the concept of building a "vision" to define a
> desirable future for a group of people, and to inform future choices on
> our way there.
> 
> In any virtual and global community, there are challenges around
> confusion, isolation and fragmentation. OpenStack does not escape those,
> and confusion on where we are going and what we are trying to achieve is
> common. Vision is a tool that can help with that. We decided to start
> with creating a vision for the Technical Committee. What would success
> for that group of people look like ? If that exercise is successful (and
> useful), we could move on to write a vision for OpenStack itself.
> 
> Members of the Technical Committee met in person around a Board+TC
> meeting in Boston last month, to start building this vision. Then over
> the last month we refined this document with the TC members that could
> not make it in person in Boston. Sean Dague polished the wording and
> posted the resulting draft at:
> 
> https://review.openstack.org/#/c/453262/
> 
> Now we are entering a (long) comment phase. This includes comments on
> the review, face-to-face discussions at the Forum, but also (soon) an
> open survey for confidential feedback. We'd very much like to hear your
> opinion on it.
> 

An important addendum. It was a group effort with Dims, John Garbutt,
and myself to do merge all the piece part documents into one flow.

-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] How to get all detail RPC message and detail context in neutron docs?

[Akihiro Motoki]

Hi Sam,

'context' is an object of neutron.context.Context which inherits
oslo_context.RequestContext.
When you see 'context' as a method signature like
router_added_to_agent(self, context, payload),
'context' is Context object.

oslo_messaging serializes the context object and sends to RPC consumer(s).
The serialization conveys the object content to a receiver.

In neutron case, the 'context' object is usually created from keystone
context [1]
or get_admin_context(_without_session) [2].

Does this answer to your question?

[1] https://github.com/openstack/neutron/blob/master/neutron/auth.py#L30
[2] 
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py#L161


2017-04-05 19:09 GMT+09:00 Sam :
> Hi all,
>
> I'm working on neutron L3 Agent and some other Agent. I found that there are
> lots of RPCs including RPC call and notification and lots of 'context' as
> bellow. But I don't know its detail context, can I get these from some docs?
>
> If there are no docs, could I get these using some debug method? Like
> '--debug' option or using pdb or something?
>
> RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.
>
> context: it's param in some function like 'def router_added_to_agent(self,
> context, payload):' in neutron/neutron/agent/l3/agent.py.
>
> __
> OpenStack Development Mailing List (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][ui] [heat] i18n proposal for heat templates 'description' help strings

[Julie Pichon]

Hi,

Peng, thank you for looking into how we might be able to provide
translations for the THT content in TripleO UI! I think this would be
helpful for users, and we have a couple of translators interested in
helping as well.

On 23 March 2017 at 09:07, Thomas Herve  wrote:
> On Thu, Mar 23, 2017 at 9:39 AM, Peng Wu  wrote:
>> Hi,
>>
>>   For TripleO UI project, some users requested to translate the web UI.
>> But some web UI string are from heat template files in tripleo-heat-
>> templates project.
>>
>>   In order to get translated templates displayed in tripleo-ui, we
>> propose a blueprint as follows, which needs to change code in heat,
>> tripleo-heat-tempates and tripleo-ui projects.
>>
>>   I18n proposal for heat templates 'description' help strings
>>
>>   1. Update heat project to accept "translation-domain" header in
>> RESTful request, like "translation-domain: tripleo-heat-templates"
>>
>>  a. With "translation-domain" header, heat will try to translate
>> "title" and "description" field using "tripleo-heat-templates.po"
>>
>>  b. Without "translation-domain" header, heat will return the
>> fields like before
>>
>>  c. Add some field in config file for security to have a list of
>> allowed "translation-domain",
>> like "allowed-translation-domains: ['tripleo-heat-templates',
>> ...]"
>
> From the Heat side of things, that sounds like a big no-no to me.
> While we've done many things to cater to TripleO, this is way too
> specific of a use case. It doesn't even make sense for the general use
> case of passing user templates to Heat.

I would have thought maybe providing a standard mechanism for Heat
users to share templates with descriptions in multiple languages would
be interesting to Heat as well, but it looks like the workflow isn't
quite the same as I thought so that's fair enough.

>>   2. Update tripleo-heat-templates to generate the translation files,
>>  like "tripleo-heat-templates.pot"
>>
>>  a. May need to write python script to extract "title" and
>> "description" field from yaml files
>>
>>  b. May need to integrate into python babel config or use separate
>> po files
>>
>>
>>   3. Update tripleo-ui to use locale API with "translation-domain"
>> header to ask the RESTful response with translated "title" and
>> "description" fields from heat services
>>
>>  a. tripleo-ui will send request with two additional headers:
>> "Accept-Language" and "translation-domain: tripleo-heat-
>> templates"
>
> Those last 2 steps may make more sense. Possibly try to store those
> translation files somewhere and manage them in the UI?

If it's at all possible, I think it'd be good to figure out a mechanism
where we can keep the translations together with the templates that
have the original strings (so in the THT repo itself), rather than
store them all in the UI repository where it could easily get out of
sync and could never be reused outside of the UI use case.

Of course this means the translations would likely be stored in
standard PO files, while the tripleo-ui i18n library only understands
JSON for the message catalogues... so there'll probably be some
interesting things to figure out here. I imagine the PO files would end
up stored in Swift with the rest of the plan, maybe we could get to
them via a Mistral action that would convert them to JSON? Or modify
the current action that gets the titles/descriptions to look for the
new Accept-Language header, I'm not familiar with how it currently works.

If there is a blueprint or bug or spec where you're tracking the work,
I'd love to know so I can follow what's happening and see if there are
places where I might be able to help. If the new Python script requires
some additional infra work, I also have some experience with updating
the translation proposal jobs to work with different formats.

Thanks,

Julie

__
OpenStack Development Mailing List (not for 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][TripleO][release][deployment] Packaging problems due to branch/release ordering

[Akihiro Motoki]

I see Emilien proposed a number of patches to individual projects with
"Sem-Ver: api-break" in the commit message.
As far as I understand the pbr documentation [1] correctly (see the
forth paragraph in the section) which is pointed by Emilien,
the change looks reasonable.

Honestly it would be great if we have a green signal for the similar
change as a community
as not all developers are familiar with this kind of changes.

Can all developers get the green signal for the similar change?

Akihiro

[1] https://docs.openstack.org/developer/pbr/#version


2017-04-05 10:36 GMT+09:00 Emilien Macchi :
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
 In the past we addressed this by automatically merging the release
 tag back into master, but we stopped doing that a cycle ago because
 it complicated release note generation.
>>>
>>> Also this was including RC >= 2 and final tags so as soon as the first
>>> stable maintenance version was released, master was again lower
>>> version.
>>
>> topic sounds staled.
>> Alan,  do we have an ETA on the RDO workaround?
>
> Without progress on RDO tooling and the difficulty of implementing it,
> I went ahead and proposed a semver bump for some projects:
>
> https://review.openstack.org/#/q/topic:sem-ver/pike
>
> Except for Swift where I don't know if they'll bump X, I proposed to bump Y.
> For all other projects, I bumped X as they did from Newton to Ocata.
> (where version is X.Y.Z).
>
> Please give any feedback on the reviews if you prefer another kind of bump.
> Thanks for reviewing that asap, so TripleO CI can test upgrades from
> Ocata to Pike soon.
>
> Thanks,
>
>> Thanks,
>>
>>> Cheers,
>>> Alan
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 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] Roadmap for Container CI work

[Steven Hardy]

On Tue, Apr 04, 2017 at 04:01:48PM -0400, Emilien Macchi wrote:
> After our weekly meeting of today, I found useful to share and discuss
> our roadmap for Container CI jobs in TripleO.
> They are ordered by priority from the highest to lowest:
> 
> 1. Swap ovb-nonha job with ovb-containers, enable introspection on the
> container job and shuffle other coverage (e.g ssl) to other jobs
> (HA?). It will help us to get coverage for ovb-containers scenario
> again, without consuming more rh1 resources and keep existing
> coverage.
> 2. Get multinode coverage of deployments - this should integrate with
> the scenarios we already have defined for non-container deployment.
> This is super important to cover all overcloud services, like we did
> with classic deployments. It should be non voting to start and then
> voting once it works. We should find a way to keep the same templates
> as we have now, and just include the docker environment. In other
> words, find a way to keep using:
> https://github.com/openstack/tripleo-heat-templates/blob/master/ci/environments/scenario001-multinode.yaml
> so we don't duplicate scenario environments.
> 3. Implement container upgrade job, which for Pike will be deploy a
> baremetal overcloud, then migrate on upgrade to containers. Use
> multinode jobs for this task. Start with a non-voting job and move to
> the gate once it work. I also suggest to use scenarios framework, so
> we keep good coverage.
> 4. After we implement the workflow for minor updates, have a job with
> tests container-to-container updates for minor (rolling) updates, this
> ideally should add some coverage to ensure no downtime of APIs and
> possibly checks for service restarts (ref recent bugs about bouncing
> services on minor updates)
> 5. Once Pike is released and Queens starts, let's work on container to
> containers upgrade job.
> 
> Any feedback or question is highly welcome,

+1, I think this makes sense and is well aligned with what we discussed in
the meeting.

I agree the priority is roughly in the order listed above, but provided we
have sufficient folks willing to help we can probably work on some of these
tasks in parallel, as really we need at least (1), (2) and (3) ASAP.

I've started looking at (4) but there is significant work required to
enable this as our current breakpoint based update workflow won't work, and
it looks like we also can't use the rolling update feature of
SoftwareDeploymentGroup, because we want each node to be fully updated
before moving on to the next.

Steve

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

Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

[Russell Bryant]

On Thu, Mar 30, 2017 at 12:40 PM, Armando M.  wrote:

> On 30 March 2017 at 08:47, Saverio Proto  wrote:
>
>> Hello,
>>
>> I am trying to use the neutron l2gw plugin, but I am not using a bare
>> metal switch to bridge.
>>
>> I am using a server with Openvswitch.
>>
>
> I am not aware of any effort to implement L2GW purely in software, in fact
> this was one key missing pieces that prevented the project to have CI
> solely dealt with the upstream infra resources. Perhaps OVN may come to the
> rescue here, I recall at some point the team was looking at the L2GW API.
>

networking-ovn still does not support the networking-l2gw API.

OVN itself does support two types of L2 gateways.

1) hardware_vtep based gateways.  We do have this exposed through
networking-ovn, but only via an undocumented custom binding:profile.  The
intention was to eventually support the networking-l2gw API, but it hasn't
been prioritized.

https://bugs.launchpad.net/networking-ovn/+bug/1457569

2) Software based L2 gateways.

You can configure OVN to use any host as an L2 gateway.  We haven't looked
at Neutron integration of this at all.  Perhaps it maps into the
networking-l2gw API as well, though?

​I'm happy to provide pointers if anyone is interested in working in this
area.​

-- 
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] [nova] Risk prediction model for OpenStack

[Matt Riedemann]

On 4/5/2017 9:00 AM, Jeremy Stanley wrote:

On 2017-04-05 14:00:59 +0800 (+0800), 林泽燕 wrote:
[...]

I wonder if I could show you my study, including some metrics for
the prediction model and a visualization tool.

[...]

I want to start out thanking you for your research and interest in
OpenStack's development practices. I love that our contribution
model enables such scientific analysis, a sometimes less recognized
benefit of our community's choice to work entirely in the open. This
specific study is also very insightful and well-presented.


In this release, 36 developers left the development of this file
(they made contributions in last release but not this one).
Developers leaving a code file deprive the file of the knowledge
of the decisions they have made.

[...]

One potentially influential aspect of our development model is that
we place a heavy importance on code review. For any patch to make it
into a branch under official revision control, it must first be
reviewed by multiple experienced, long-standing contributors to that
repository. Our hope is that even though some developers may cease
contributing new patches to a file, some of them would still be
reviewing, guiding and refining changes proposed by newer
contributors. It doesn't seem like this behavior was captured in
your analysis, or alternatively the fact that your model yielded
relatively accurate predictions could imply that our review process
has little impact on defects introduced by new commits.

If you do at some point wish to try integrating review metrics into
your analysis, our code review system has a REST API you can
leverage, and much of the data you'd likely be interested in can be
queried via anonymous methods such that you wouldn't even need to
create an account. Documentation for the interface is available at
https://review.openstack.org/Documentation/rest-api.html and we also
have documentation of our general developer workflow at
https://docs.openstack.org/infra/manual/developers.html as well as
some background on our development model at
https://docs.openstack.org/project-team-guide/open-development.html
if that helps.



Jeremy pointed out what I was going to mention, which was the lack of 
input on code reviews. Each major component of Nova, or virt drivers, 
generally have subteams, or some sort of subject domain expert, that is 
consulted or at least involved in reviewing code contributions. So while 
they may not be making the changes themselves to a component, they 
should be reviewing those changes. For example, with the 
nova/virt/libvirt/driver.py, danpb was the main core reviewer and 
maintainer for that code in the past, so while he didn't write 
everything, he was reviewing a lot of the contributions.


Some of the files are also skewed a bit, and you might want to take into 
account logic paths in a module to exclude it. For example, exception.py 
and the various opts.py modules are outliers. They are basically files 
that contain constants but not logic code so the chance of those having 
an actual owner is small, but so should be the risk for bugs. They will 
also have a high diversity given how common they are.


I'm not sure I understood the timeline graphs, or the point those are 
making. We definitely have an ebb and flow of contributions based on the 
release schedule where feature development and new code is loaded toward 
the front of the release, and then that is supposed to be cut off toward 
the 3rd milestone at the end of the release so we can stabilize and 
focus on bugs.


In general some of this is common sense. When one person "owns" most of 
a module in a piece of software they are the expert and therefore bugs 
due to lack of understanding the bigger picture of that module, or how 
it fits into the bigger system, should be mitigated. When that person 
leaves, if others on the team don't have the domain knowledge, there are 
going to be mistakes. We definitely have parts of the nova codebase that 
fall into areas that we know are just very touchy and error prone and we 
avoid changing those if at all possible (block device mappings, quotas, 
neutronv2.api, nova-network and cells v1 come to mind). This is hard in 
a big open source project, but is also why we have high standards for 
core reviewers (those that can approve code contributions) and a 
ridiculous amount of continuous integration testing.


--

Thanks,

Matt

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

[openstack-dev] [Sahara][APIv2] Microversions

[Telles Nobrega]

Hey Saharans and interested folks,

On the intent to move our API version to v2 there has been a lot of work
going on this cycle following
https://wiki.openstack.org/wiki/Sahara/api-v2 defined
a while back.

One of the new features defined on the document is the addition of
microversion support. The idea is to allow addition of new features without
breaking current API version and not needing to bump API major version on a
small change as well as allow different features to be available on the
same deploy depending on the API version requested.

In Sahara, we don't see many API changes on the horizon but this seems like
a good point to work on to make our API more stable and easily changeable
in the future. The work will be based on Nova, Ironic and Manila's work
which are already done.

My question here is, do we have any concerns about this work? Can we move
on or should this be put on the background?

Thanks, I will be waiting your input so we can make a decision.
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

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

Re: [openstack-dev] [Valence] Nominate Anusha and Bian for Valence core reviewers

[Potter, Nathaniel]

+1 from me, they've both been very helpful and have been doing good work :).

-Nate

_
From: Yang, Lin A
Sent: Monday, April 3, 2017 3:04 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [Valence] Nominate Anusha and Bian for Valence core reviewers


Hi,

I would like to nominate Anusha Ramineni and Bian Hu as core reviewer for 
Valence.

They are excellent contributor to our project since the project's creation, and 
have shown great knowledge in Valence, OpenStack and Python. Please response 
with your +1 or any objections.

Thanks,
Lin.

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

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[Monty Taylor]

On 04/05/2017 09:39 AM, Akihiro Motoki wrote:

I noticed this thread by Monty's reply. Sorry for my late :(

I think we need to think 'id' separately for API modeling and DB modeling.

In the API perspective, one of the important things is that 'id' is
not predictable
and it rarely conflict. From this perspective, UUID works.

In the DB perspective, the context will be different.
Efficiency is another important point.
auto-incremental way brings us a good efficiency.

In most OpenStack projects, we use 'id' in a database as 'id' in an API layer.
I am okay with using incremental integer as 'id' in DB, but I don't think
it is not a good idea to use predictable 'id' in the API layer.

I don't know how 'id' in API and DB layer are related in Zun implementation
but I believe this is one of the important point.


Yes! Very well said. UUID is the excellent choice for API - auto-inc is 
the excellent choice for the database.



2017-04-05 22:00 GMT+09:00 Monty Taylor :

On 02/21/2017 07:28 AM, gordon chung wrote:




On 21/02/17 01:28 AM, Qiming Teng wrote:


in mysql[2].


Can someone remind me the benefits we get from Integer over UUID as
primary key? UUID, as its name implies, is meant to be an identifier for
a resource. Why are we generating integer key values?



this ^. use UUID please. you can google why auto increment is a probably
not a good idea.

from a selfish pov, as gnocchi captures data on all resources in
openstack, we store everything as a uuid anyways. even if your id
doesn't clash in zun, it has a higher chance of clashing when you
consider all the other resources from other services.

cheers,



sorry - I just caught this.

Please do NOT use uuid as a primary key in MySQL:

* UUID has 36 characters which makes it bulky.
* InnoDB stores data in the PRIMARY KEY order and all the secondary keys
also contain PRIMARY KEY. So having UUID as PRIMARY KEY makes the index
bigger which can not be fit into the memory
* Inserts are random and the data is scattered.

In cases where data has a large natural key (like a uuid) It is considered a
best practice to use an auto-increment integer as the primary key and to put
a second column in the table to store the uuid, potentially with a unique
index applied to it for consistency.

That way the external identifier for things like gnocchi can still be the
UUID, but the internal id for the database can be an efficient
auto-increment primary key.



__
OpenStack Development Mailing List (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] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[gordon chung]

On 05/04/17 09:00 AM, Monty Taylor wrote:
>
> Please do NOT use uuid as a primary key in MySQL:
>
> * UUID has 36 characters which makes it bulky.

you can store it as a binary if space is a concern.

> * InnoDB stores data in the PRIMARY KEY order and all the secondary keys
> also contain PRIMARY KEY. So having UUID as PRIMARY KEY makes the index
> bigger which can not be fit into the memory
> * Inserts are random and the data is scattered.

can store a ordered uuid (uuid1) for performance but arguably not much 
diff from just autoincrement

>
> In cases where data has a large natural key (like a uuid) It is
> considered a best practice to use an auto-increment integer as the
> primary key and to put a second column in the table to store the uuid,
> potentially with a unique index applied to it for consistency.
>
> That way the external identifier for things like gnocchi can still be
> the UUID, but the internal id for the database can be an efficient
> auto-increment primary key.

very good points. i guess ultimately should probably just test to the 
scale you hope for

cheers,

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

Re: [openstack-dev] [nova] Removing BDM devices from POST requests

[Matt Riedemann]

On 4/4/2017 10:07 PM, Feodor Tersin wrote:

I raised the question though, could we move forward with removing the



device field from the "POST /servers/{server_id}/os-volume_attachments"
API since that doesn't do anything with image BDM overrides.


Will this affect detaching/attaching of root volume
(https://review.openstack.org/#/c/340874/2/specs/ocata/approved/detach-boot-volume.rst)?

I do not know if and how the spec is implemented, but it says:
---
The usual attach volume API call will be used to attach the boot volume.
The volume attach operation allows a user to specify the name of the device.
The boot device name of an instance is known so that is used to determine
that the user is attempting to attach the volume as the root device.
---




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



That blueprint never got implemented nor is being re-proposed for Pike. 
Having said that, I wasn't aware of that part of it. I suppose the idea 
is to provide the device name of the root device and then the API would 
validate that the matching BDM for the instance based on device name has 
boot_index=0 and detach it, otherwise fail because it's not the root 
device BDM.


Anyway, I've abandoned my spec for Pike. It's a distraction at this 
point and we have other things that need to get done first for BDMs in 
the API before we can consider removing device name in the requests.


--

Thanks,

Matt

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

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[Akihiro Motoki]

I noticed this thread by Monty's reply. Sorry for my late :(

I think we need to think 'id' separately for API modeling and DB modeling.

In the API perspective, one of the important things is that 'id' is
not predictable
and it rarely conflict. From this perspective, UUID works.

In the DB perspective, the context will be different.
Efficiency is another important point.
auto-incremental way brings us a good efficiency.

In most OpenStack projects, we use 'id' in a database as 'id' in an API layer.
I am okay with using incremental integer as 'id' in DB, but I don't think
it is not a good idea to use predictable 'id' in the API layer.

I don't know how 'id' in API and DB layer are related in Zun implementation
but I believe this is one of the important point.

Akihiro


2017-04-05 22:00 GMT+09:00 Monty Taylor :
> On 02/21/2017 07:28 AM, gordon chung wrote:
>>
>>
>>
>> On 21/02/17 01:28 AM, Qiming Teng wrote:

 in mysql[2].
>>>
>>> Can someone remind me the benefits we get from Integer over UUID as
>>> primary key? UUID, as its name implies, is meant to be an identifier for
>>> a resource. Why are we generating integer key values?
>>
>>
>> this ^. use UUID please. you can google why auto increment is a probably
>> not a good idea.
>>
>> from a selfish pov, as gnocchi captures data on all resources in
>> openstack, we store everything as a uuid anyways. even if your id
>> doesn't clash in zun, it has a higher chance of clashing when you
>> consider all the other resources from other services.
>>
>> cheers,
>>
>
> sorry - I just caught this.
>
> Please do NOT use uuid as a primary key in MySQL:
>
> * UUID has 36 characters which makes it bulky.
> * InnoDB stores data in the PRIMARY KEY order and all the secondary keys
> also contain PRIMARY KEY. So having UUID as PRIMARY KEY makes the index
> bigger which can not be fit into the memory
> * Inserts are random and the data is scattered.
>
> In cases where data has a large natural key (like a uuid) It is considered a
> best practice to use an auto-increment integer as the primary key and to put
> a second column in the table to store the uuid, potentially with a unique
> index applied to it for consistency.
>
> That way the external identifier for things like gnocchi can still be the
> UUID, but the internal id for the database can be an efficient
> auto-increment primary key.
>
>
>
> __
> OpenStack Development Mailing List (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] [tc] version document for project navigator

[Jimmy McArthur]

FWIW, from my perspective on the Project Navigator side, this format 
works great. We can actually derive the age of the project from this 
information as well by identifying the first release that has API data 
for a particular project. I'm indifferent about where it lives, so I'd 
defer to you all to determine the best spot.


I really appreciate you all putting this together!

Jimmy


Thierry Carrez 
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made elsewhere:

This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the project
navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that would
be great.

Monty Taylor 
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document 
format for reporting versions to the project navigator. I stuck it in 
the releases repo:


  https://review.openstack.org/453361

Because there was already per-release information there, and the 
governance repo did not have that structure.


I've included pseudo-code and a human explanation of how to get from a 
service's version discovery document to the data in this document, but 
also how it can be maintained- which is likely to be easier by hand 
than by automation - but who knows, maybe we decide we want to make a 
devstack job for each service that runs on tag events that submits a 
patch to the releases repo. That sounds like WAY more work than once a 
cycle someone adding a few lines of json to a repo - but *shrug*.


Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery 
Document" is a thing people might want to do and want to do 
consistently across services.


* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few 
minor ways that do not actually matter but make life harder for our 
users.


Thoughts and feedback more than welcome!
Monty

__ 


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

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


__
OpenStack Development Mailing List (not for 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] Risk prediction model for OpenStack

[Jeremy Stanley]

On 2017-04-05 14:00:59 +0800 (+0800), 林泽燕 wrote:
[...]
> I wonder if I could show you my study, including some metrics for
> the prediction model and a visualization tool.
[...]

I want to start out thanking you for your research and interest in
OpenStack's development practices. I love that our contribution
model enables such scientific analysis, a sometimes less recognized
benefit of our community's choice to work entirely in the open. This
specific study is also very insightful and well-presented.

> In this release, 36 developers left the development of this file
> (they made contributions in last release but not this one).
> Developers leaving a code file deprive the file of the knowledge
> of the decisions they have made.
[...]

One potentially influential aspect of our development model is that
we place a heavy importance on code review. For any patch to make it
into a branch under official revision control, it must first be
reviewed by multiple experienced, long-standing contributors to that
repository. Our hope is that even though some developers may cease
contributing new patches to a file, some of them would still be
reviewing, guiding and refining changes proposed by newer
contributors. It doesn't seem like this behavior was captured in
your analysis, or alternatively the fact that your model yielded
relatively accurate predictions could imply that our review process
has little impact on defects introduced by new commits.

If you do at some point wish to try integrating review metrics into
your analysis, our code review system has a REST API you can
leverage, and much of the data you'd likely be interested in can be
queried via anonymous methods such that you wouldn't even need to
create an account. Documentation for the interface is available at
https://review.openstack.org/Documentation/rest-api.html and we also
have documentation of our general developer workflow at
https://docs.openstack.org/infra/manual/developers.html as well as
some background on our development model at
https://docs.openstack.org/project-team-guide/open-development.html
if that helps.
-- 
Jeremy Stanley

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

[openstack-dev] [murano][k8s] Fwd: Re: [kubernetes-users] how to upgrade kubectl version

[Jay Pipes]

Just in case any Murano developers are also on the Kubernetes users 
list, this came up. Might be good to reach out to our Kubernetes friends 
here if we have some insights that could help them.


Here's a list to the Google Groups message if it's easier to read than 
the mangled email below:


https://groups.google.com/forum/#!topic/kubernetes-users/NNunHIvx1yE

Best,
-jay

 Forwarded Message 
Subject:Re: [kubernetes-users] how to upgrade kubectl version
Date:   Wed, 5 Apr 2017 08:55:26 +0100
From:   YASMINE CHEIKHROUHOU 
Reply-To:   kubernetes-us...@googlegroups.com
To: kubernetes-us...@googlegroups.com



oh god :/

2017-04-05 8:43 GMT+01:00 Christian Koep >:


It looks like this is not supported by murano:


https://github.com/openstack/k8s-docker-suite-app-murano/blob/master/Kubernetes/README.rst#upgrade





On Wed, Apr 5, 2017 at 9:34 AM, YASMINE CHEIKHROUHOU
>
wrote:
 > I have murano installed in openstack and then i have deployed 
cluster

 > kubernetes
 >
 > 2017-04-05 8:13 GMT+01:00 Christian Koep >:
 >>
 >> Yes, this is possible too!
 >>
 >> It is slightly more complicated and it depends on your setup.
 >>
 >> How did you set up your Cluster? On AWS? GKE? Vagrant?
 >>
 >>
 >> On Tue, Apr 4, 2017 at 5:23 PM, YASMINE CHEIKHROUHOU
 >> > wrote:
 >> > good it works
 >> > Can i upgrade version of Server Version
 >> >
 >> >
 >> > 2017-04-04 15:54 GMT+01:00 Christian Koep >:
 >> >>
 >> >> Try this:
 >> >>
 >> >> curl -LO
 >> >>
https://storage.googleapis.com/kubernetes-release/release/$(curl

 >> >> -s
 >> >>
 >> >>

https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl


 >> >> chmod +x kubectl
 >> >> sudo mv kubectl $(which kubectl)
 >> >>
 >> >> On Tue, Apr 4, 2017 at 4:47 PM, Christian Koep
>
 >> >> wrote:
 >> >> > Whats the output of
 >> >> >
 >> >> > which kubectl
 >> >> >
 >> >> > ?
 >> >> >
 >> >> > On Tue, Apr 4, 2017 at 4:19 PM, jasmin
>
 >> >> > wrote:
 >> >> >> i have installed kubectl using curl -LO
 >> >> >>
https://storage.googleapis.com/kubernetes-release/release/$(curl
 -s
 >> >> >>
 >> >> >>
 >> >> >>

https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl


 >> >> >> But i always have the same version of kubectl 1.3.0 and i
want to
 >> >> >> upgrade it
 >> >> >> to 1.5.6
 >> >> >> can someone help me pleaase
 >> >> >> Thank you all
 >> >> >>
 >> >> >> --
 >> >> >> You received this message because you are subscribed to
the Google
 >> >> >> Groups
 >> >> >> "Kubernetes user discussion and Q" group.
 >> >> >> To unsubscribe from this group and stop receiving emails
from it,
 >> >> >> send
 >> >> >> an
 >> >> >> email to kubernetes-users+unsubscr...@googlegroups.com
.
 >> >> >> To post to this group, send email to
 >> >> >> kubernetes-us...@googlegroups.com
.
 >> >> >> Visit this group at
 >> >> >> https://groups.google.com/group/kubernetes-users
.
 >> >> >> For more options, visit https://groups.google.com/d/optout
.
 >> >> >
 >> >> >
 >> >> >
 >> >> > --
 >> >> > Christian Koep
 >> >> > ---
 >> >> > 4096R / BB97 7DE2 9669 2F4D EC3A  3481 8899 70BE 1295 5732
 >> >>
 >> >>
 >> >>
 >> >> --
 >> >> Christian Koep
 >> >> ---
 >> >> 4096R / BB97 7DE2 9669 2F4D EC3A  3481 8899 70BE 1295 5732
 >> >>
 >> >> --
 >> >> You received this message because you are subscribed to a
topic in the
 >> >> Google Groups "Kubernetes user discussion and Q" group.
 >> >> To unsubscribe from this topic, visit
 >> >>
 >> >>

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[Monty Taylor]

On 02/21/2017 07:28 AM, gordon chung wrote:



On 21/02/17 01:28 AM, Qiming Teng wrote:

in mysql[2].

Can someone remind me the benefits we get from Integer over UUID as
primary key? UUID, as its name implies, is meant to be an identifier for
a resource. Why are we generating integer key values?


this ^. use UUID please. you can google why auto increment is a probably
not a good idea.

from a selfish pov, as gnocchi captures data on all resources in
openstack, we store everything as a uuid anyways. even if your id
doesn't clash in zun, it has a higher chance of clashing when you
consider all the other resources from other services.

cheers,



sorry - I just caught this.

Please do NOT use uuid as a primary key in MySQL:

* UUID has 36 characters which makes it bulky.
* InnoDB stores data in the PRIMARY KEY order and all the secondary keys 
also contain PRIMARY KEY. So having UUID as PRIMARY KEY makes the index 
bigger which can not be fit into the memory

* Inserts are random and the data is scattered.

In cases where data has a large natural key (like a uuid) It is 
considered a best practice to use an auto-increment integer as the 
primary key and to put a second column in the table to store the uuid, 
potentially with a unique index applied to it for consistency.


That way the external identifier for things like gnocchi can still be 
the UUID, but the internal id for the database can be an efficient 
auto-increment primary key.



__
OpenStack Development Mailing List (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] [acceleration]Cyborg Team Weekly Meeting 2017.04.05

[Zhipeng Huang]

Hi Team,

Just a kind reminder for the team meeting today on EST 11:00am on
#openstack-cyborg .

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [ironic] New contributor

[Dmitry Tantsur]

On 03/30/2017 05:13 AM, Julian Edwards wrote:

Hi all


Hi and welcome!



I'm looking to start contributing to Ironic, and in fact I did a
couple of small patches already which are still waiting to be
landed/reviewed. [1]

I'm finding it a little hard to find some more reasonable bugs to get
started with fixing, so if any of you guys can point me at a few I
would appreciate it, or indeed if someone is willing to do more
involved mentoring.  (I am in the +10 time zone so this may be
awkward, sadly)


Indeed, as Jay already mentioned, we have a competitions for easier bugs right 
now :) Please keep in mind, though, that carefully reviewing others patches is 
often more valuable, than adding more patches to the queue. This may be a good 
way to both help the project and learn it better.




Cheers
J

PS  Some of you may remember me as the original Ubuntu MAAS lead, so I
am pretty familiar with bare metal stuff generally.

[1] https://review.openstack.org/#/c/449454/ and
https://review.openstack.org/#/c/450492/

__
OpenStack Development Mailing List (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] [ironic] Translations removal

[Dmitry Tantsur]

On 03/30/2017 08:36 PM, Doug Hellmann wrote:

Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:

On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:

On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:

However, pep8 does not accept passing variable to translation
functions,  so this results in ‘H701 Empty localization string’ error.

Possible options to handle that:

1)  Duplicate messages:

LOG.error(“”, {: })

raise Exception(_(“”) % {: })

2)  Ignore this error

3)  Talk to hacking people about possible upgrade of this check

4)  Pass translated text to LOG in such cases



I’d personally vote for 2. What are your thoughts?


When the translators go to translate, they generally only get to see
what's inside _(), so #2 is a no-go for translations, and #3 also is a
no-go.
--


I think the appropriate thing here is to do something like:

msg = _('') % {: }
LOG.error(msg)
raise Exception(msg)

This results in a translated string going to the log, but I think that's
OK.



Why is the error being logged and then thrown? If it's a true exception,
won't the outer-most part of the application loop log the error? And if
it's something that the application is catching and handling, that makes
it seem like it's not an operator-facing error.


This sounds nice, and we did it for some time. But it ends up being a 
debugability nightmare, so now I usually -1 people for not having this 
LOG.error. This is because every re-raise loses some valuable information; 
crossing the RPC border probably loses even more. It is particularly bad, when 
the error messages from innermost exceptions are not helpful (hello, KeyError).


My personal favorite case was something like:

 "Failed to power off the node . Unable to parse XML."

Getting something like that in ironic-api logs would probably not be too 
helpful.



Doug

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




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

Re: [openstack-dev] [tc] version document for project navigator

[Thierry Carrez]

Monty Taylor wrote:
> As per our discussion in today's TC meeting, I have made a document
> format for reporting versions to the project navigator. I stuck it in
> the releases repo:
> 
>   https://review.openstack.org/453361
> 
> Because there was already per-release information there, and the
> governance repo did not have that structure.

Somehow missed this thread, so will repost here comments I made elsewhere:

This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the project
navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that would
be great.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] How to get all detail RPC message and detail context in neutron docs?

[Sam]

Hi all,

I'm working on neutron L3 Agent and some other Agent. I found that there
are lots of RPCs including RPC call and notification and lots of 'context'
as bellow. But I don't know its detail context, can I get these from some
docs?

If there are no docs, could I get these using some debug method? Like
'--debug' option or using pdb or something?

RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.

context: it's param in some function like 'def router_added_to_agent(self,
context, payload):' in neutron/neutron/agent/l3/agent.py.
__
OpenStack Development Mailing List (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] [tc] Technical Committee Vision draft

[Thierry Carrez]

Hi everyone,

Last year in Ann Arbor, a group of OpenStack community members
(including 6 current TC members) attended a Servant Leadership training
at ZingTrain organized by Colette Alexander and funded by the OpenStack
Foundation. We found that these concepts adapted quite well to our
unique environment. The Stewardship working group was created to try to
further those and decided to further those efforts. One of the tools we
learned about there is the concept of building a "vision" to define a
desirable future for a group of people, and to inform future choices on
our way there.

In any virtual and global community, there are challenges around
confusion, isolation and fragmentation. OpenStack does not escape those,
and confusion on where we are going and what we are trying to achieve is
common. Vision is a tool that can help with that. We decided to start
with creating a vision for the Technical Committee. What would success
for that group of people look like ? If that exercise is successful (and
useful), we could move on to write a vision for OpenStack itself.

Members of the Technical Committee met in person around a Board+TC
meeting in Boston last month, to start building this vision. Then over
the last month we refined this document with the TC members that could
not make it in person in Boston. Sean Dague polished the wording and
posted the resulting draft at:

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

Now we are entering a (long) comment phase. This includes comments on
the review, face-to-face discussions at the Forum, but also (soon) an
open survey for confidential feedback. We'd very much like to hear your
opinion on it.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [openstack-ansible] Adding a scenario for shade's functional tests

[Jean-Philippe Evrard]

Hey,

My two cents.

JP

On 04/04/2017, 13:39, "Monty Taylor"  wrote:

Hey all!

I woke up early this morning and found myself thinking "I clearly don't
have enough work on my plate, why don't I add some more?"

I'd love to make a gate job that:
- Deploys a cloud with openstack-ansible
- Runs shade's functional tests against that cloud

How do you run these functional tests? Do you expect this as a simple tox run, 
a tempest scenario, or anything else?

Which makes me think it just needs to be an additional scenario perhaps?

I think a scenario is good, but we could consider this test as part of a basic 
end-to-end testing. If the tests aren’t too long, we could include them at the 
end of an AIO run to make sure everything “works as expected” for both tempest 
and shade. Sadly, our jobs are already long and hitting timeouts on some 
distros.

As I started to poke, I need to figure out the best way to accomplish
something. Namely, shade's functional tests expect a clouds.yaml that
defines two entires - one admin and one non-admin.

OSA already creates a clouds.yaml with admin creds, so that's done. And
there is already tempest setup that creates a demo user, so that's done
too. Here's where I could use some advice:

- What's the best way to plumb through an option to also write an entry
to clouds.yaml for the demo user? I'm thinking a boolean in
openstack-ansible-openstack_openrc like
"openrc_clouds_yml_add_demo_user" that can be wrapped around a second
entry in clouds.yaml.j2?

I’d agree with Jesse definition there: have vars defined in utility_all group 
vars (or like jesse said, something in the AIO prep).
These vars would:
- override the openstack_openrc default vars (we need to adapt the tasks in 
openstack_openrc “Create openrc” to include a loop + “Create clouds.yaml” to 
generate a more complete clouds.yaml according to the users defined in the dict)
- override the tempest user creation (we need to adapt the tasks in tempest to 
be a var + at the same time we could maybe move to ansible os_ modules there, 
that would also be a win for shade)

- Can we create the demo user and not run tempest? It's in the
os_tempest role at the moment. Should I split out the user creation bits
into a "test_setup" role that tempest depends on - and then also make a
shade_test role that also depends on the test_setup role?

I like this approach.
If you want a shorter path, you can still define in the user variables 
``tempest_run: False`` for the scenario, and we could have an include 
shade_run. I guess it all depends on shade_run content and if that deserves the 
burden of a role to maintain.
If you think shade_test deserves a role, we could transfer the maintenance 
burden to you by including it in the ansible-role-requirements, but not under 
the openstack-ansible umbrella, like we do for some external roles. We could 
then adapt the plays, or use an include_role inside tempest role for laziness.

- If we do a test_setup role, should that maybe just write a whole
additional clouds.yaml out that has the admin and the demo user so that
we don't have to put conditionals in places that also get used for prod
deploys?

We used to need the openrc role to happen before the tempest role IIRC.
We couldn’t have one role fits all. However, I see in that model that tempest 
or shade roles could both have a meta dep on openrc, and openrc being the 
source of truth for generating openrc like files (openrc + clouds.yaml). Openrc 
could then be used for production deploys to have a more complete clouds.yaml 
file.
Maybe it’s worth splitting the clouds.yaml with a secure.yaml in that case too. 
But that’s another topic.

I think that's about all the questions I have for now ...

Thanks!
Monty

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




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

[openstack-dev] [tricircle]weekly meeting of Apr.5

[joehuang]

Hello, team,

Agenda of Apr.5 weekly meeting:

  1.  feature implementation review
  2.  Pike-2 planning
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


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


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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

[James Page]

Hi Clark

On Tue, 4 Apr 2017 at 00:08 Clark Boylan  wrote:

> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>

tl;dr - Christian (cpaelzer) is working towards resolution of the libvirt
1.3.1 issues in Xenial, but right now we're stuck on reproduction of the
issues outside of the gate.


> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
>
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
>

+1 on taking this approach - this also aligned with what we deploy and test
with for the OpenStack Charms.

Please stick to using the updates pockets from the Ubuntu Cloud Archive
(which I can see in the review referenced that you are doing); all UCA
testing of packaging and version updates is done in the proposed pockets so
this should ensure a better level of stability for the OpenStack gate.

[...]

> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.


Worth noting that in the same way that we update OpenStack packages in the
UCA for new minor and patch releases, we also do the same for Open vSwitch
patch releases - so the Ocata UCA will get released Open vSwitch versions
on the 2.6.x series.

The Pike UCA will (probably) get a newer version of Ceph which might be of
interest for gate testing as well.

Cheers

James
__
OpenStack Development Mailing List (not for 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] Switching gate testing to use Ubuntu Cloud Archive

[James Page]

On Tue, 4 Apr 2017 at 14:38 Daniel P. Berrange  wrote:

> On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> > Hello,
> >
> > One of the major sets of issues currently affecting gate testing is
> > Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> > and they happen frequently [0][1][2]. These issues appear to only affect
> > Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> > #openstack-nova it is clear that Libvirt isn't interested in debugging
> > such an old version of Libvirt (1.3.1). And while it isn't entirely
> > clear to me which exact version would be acceptable to them the Ubuntu
> > Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>
> If going to the libvirt upstream community for help, we'd generally want
> to see the latest upstream release being used. Ideally along with
> willingness
> to test git master if investigating a troublesome issue, but we understand
> using git master is not practical for many people.
>
> If using an old version provided by an OS distro, then we would generally
> expect the OS distro maintainers to lead the investigation, and take the
> responsibility for reproducing on latest upstream. Upstream libvirt simply
> doesn't have bandwidth to do the OS distro maintainers job for them when
> using old distro versions.
>

Agree on the responsibility for maintenance of libvirt in Ubuntu. Christian
Ehrhardt (cpaelzer) has been working to help resolve the libvirt 1.3.1 bugs
currently impacting the gate and does have updated packages available for
testing, but right now we're not able to reproduce the bugs outside of the
gate environment so verifying that these actually resolve the underlying
issues is proving problematic.
__
OpenStack Development Mailing List (not for 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] stepping down from puppet-openstack core

[Denis Egorenko]

Thank you Matt for all your work and help :) Good luck!

2017-04-05 4:20 GMT+04:00 Emilien Macchi :

> On Tue, Apr 4, 2017 at 5:23 PM, Matt Fischer  wrote:
> > I am stepping down as core in the puppet openstack project. This is the
> > culmination of a long and slow refocus of my work efforts into other
> areas.
> > Additionally I'm not sure what the future holds for me at this point, and
> > although it's possible that I will be doing puppet again but it's not
> fair
> > for me to hold this role when I'm not active.
> >
> > I am very proud of what we, the community, accomplished with these
> modules
> > since I started hacking on them in 2014. The modules went from needing
> lots
> > of work to being very stable and mostly bug free. It took a lot of work
> and
> > some tough decisions from the community to get us to this point and I was
> > honored to be a part of it.
> >
> > Thanks
>
> Thank *you* !
>
> I'll miss the time where you gave strong operator feedback and when we
> got issue / solution / patch merged the same day :-)
> Anyway, enjoy the next things and thanks for your work here.
>
> PS: I remain available on IRC anytime if you want to continue to
> practice your french ;-)
>
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [neutron][networking-l2gw] bug in case of switch replacement

[Saverio Proto]

Hello,

I am testing the neutron l2gw plugin for production use.

I found a bug, that I think is either a design problem or feature that
is not implemented.

When we configure the l2gateways with the Openstack API, some state is
stored in the mysql database, and the neutron-l2gateway-agent implements
this changes in the OVSDB of the l2gw node.

AFAIK the neutron-l2gateway-agent acts only when triggered by an API
call. If you reboot this service, there is no check between the state
stored in the mysql database, and the actual state of the l2gw node.

Now if the l2gw node is a real switch, and it brakes so that you have to
replace it with a new chassis (real production use-case), you will end
up with some state in the mysql database, and a empty OVSDB on the
switch, and there is no way to resync the OVSDB.

I even tried to delete stuff using the API commands 'neutron
l2-gateway-delete' or 'neutron l2-gateway-connection-delete', but I get
python stacktraces in logs, because it tries to delete stuff from the
OVSDB of the switch that is already empty.. and you are stuck.

Can anyone clarify if what I say is right ?
Do you think I should open a bug about this ?

thanks for the feedback

Saverio


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing List (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] [horizon-plugin] Django Updates - Raising upper constraint to 1.9.13

[Rob Cresswell]

Hi everyone,

It's update time and we need to start raising the upper bounds on Django in 
global-requirements. We're currently capped at <1.9, which will shortly be 
raised to <1.10. This will raise the upper-constraint to 1.9.13. See 
https://review.openstack.org/#/c/453482/

Following a couple of weeks of stability testing, we'll move to 1.10.x (<1.11 
in g-r), and eventually 1.11.x (<2.0 in g-r) before the end of the Pike release 
cycle. I'll send out further emails as these patches go up.

If you are maintaining a plugin, please ensure it is functioning on Django 1.9, 
and feel free to leave comments on the requirements patch above.

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

Re: [openstack-dev] [neutron] Engine facade

[Takashi Yamamoto]

hi,

On Tue, Apr 4, 2017 at 4:09 PM, Gary Kotton  wrote:
> Hi,
>
> The problem that we have is that any foreign key usage under transactions is
> now broken. An example of an exception that is raised is:
>
>
>
> DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint failed
> [SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings (created_at,
> updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)'] [parameters:
> ('2017-04-04 06:48:25.595118', None, '6a086bf1-b1c9-495f-bfca-810d6638e3fa',
> '2563cd05-edd9-4c7f-9708-857a129e2642')]
>
>
>
> This is a major refactor in the plugin (which I guess is part and parcel of
> rolling with the punches). I am just concerned if we are the only folks that
> have affected by this.

networking-midonet is affected as well.

>
> Thanks
>
> Gary
>
>
>
> From: Gary Kotton 
> Reply-To: OpenStack List 
> Date: Monday, April 3, 2017 at 3:14 PM
>
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Hi,
>
> We needed to make all of those changes to just get the plugin to pass unit
> tests and CI. We are still seeing lots of issues and need to look deeper.
> The façade changes have caused a lot of instability issues. I am not 100%
> sure why. Issues that we have seen:
>
> 1. object creation under a transaction broke
>
> 2. deleting DB entries under transaction also broke
>
> Thanks
>
> Gary
>
>
>
>
>
> From: Anna Taraday 
> Reply-To: OpenStack List 
> Date: Monday, April 3, 2017 at 11:53 AM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Hi!
>
> I'm a little confused change https://review.openstack.org/#/c/452539/ is
> about switching for new facade, does the master branch fails the same?
>
>
>
> On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton  wrote:
>
> Yes, sorry my bad for not adding it -
> http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
>
> Please see the test test_create_port_dns_name
>
> Thanks
>
> Gary
>
>
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Monday, April 3, 2017 at 12:56 AM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Do you have a link to a traceback?
>
>
>
> On Apr 2, 2017 09:25, "Gary Kotton"  wrote:
>
> Hi,
>
> The change https://review.openstack.org/#/c/402750/ has broken the
> vmware-nsx plugin. I am not sure if this has had effect on any other
> decomposed plugins.
>
> One of the issues that we have is when we create a PortDNS object under a
> transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError)
> FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id,
> current_dns_name, current_dns_domain, previous_dns_name,
> previous_dns_domain, dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters:
> ('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'',
> u'port-dns-name')]
>
> Any ideas?
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> Regards,
> Ann Taraday
>
>
> __
> OpenStack Development Mailing List (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] [election] TC non-candidacy

[Steven Dake (stdake)]

Mike,

Thank you for your service.

Regards
-steve


-Original Message-
From: Mike Perez 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, April 4, 2017 at 1:20 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [election] TC non-candidacy

Hi all,

Thanks for letting me serve as a TC member. I will not be running this time
around since fungi is serving from the OpenStack Foundation on the
committee and ttx is more deserving for re-election.

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