[openstack-dev] [Horizon][DataTables] how to generate a confirmation dialog

[John Calcote]

Hi all -

I don't see a better forum anywhere for this post - please correct me
if I'm wrong.

I have a django/horizon application. On one page users may delete
objects. I'd like to display a modal dialog confirming the delete
before submit. Can anyone tell me if there's a way to tie a
confirmation dialog to a table's DeleteAction?

Note - my template is a trivial table.render with multi-select enabled - e.g.,

{% block main %}
{{ table.render }}
{% endblock %}

I've searched the docs and the code, but nothing sticks out at me. I'm
not a client-side expert, but I can usually find my way around in the
chrome debugger.

Thanks,
John

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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

I’ll be completely honest in that I do not know what precisely a strategy 
plugin is.  Perhaps we should have an irc discussion on the topic so you can 
educate me ;)

That said, I assume Ansible loads the strategy plugin.  We already hide Ansible 
behind a network service (popen).  Is the issue that the strategy plugin needs 
to import a whole bunch of Ansible code?  If that is the concern, the strategy 
plugin can be written in ASL2.0, sit in our code base, and import stuff from 
Ansible proper, and it will still be sitting behind that popen once 
instantiated.  The popen I am talking about is the one used within 
kolla-ansible (the tool that used to be a shell script which is now python).

I’m pretty sure if you give Jeffrey some requirements, he can implement one 
just as Sam did with kolla_docker.py.  If its ASL2.0 it can sit in the Kolla 
repo.  If it is not ASL2.0 it needs to sit somewhere else, probably upstream in 
Ansible itself.  There are only a few strategies for parallel runtime at 
present.  They would probably take more if it was made to be generic.

One assumption I make is the strategy plugins can be specified at runtime in 
Ansible.  Is that the case?

Regards
-steve


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

Date: Friday, November 4, 2016 at 7:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3


I read what you say Steven;) strategy plugin is not module, we don't use popen 
there. Also it will require importing GPL code from Ansible itself. Clint is 
right in this context. Writing it from scratch is not an option to (way to 
complex than docker stuff we did). Imho only option will be to write GPL driver 
that will be run with popen. Question is whether this driver can sit in Kolla 
repo or not, and if not, where?

On Nov 4, 2016 6:51 PM, "Steven Dake (stdake)" 
> wrote:
Michal,

Have you read nothing I’ve said?  If its new code, write it as ASL2.0.  The 
fact that it plugs in or uses GPLv3 code is totally irrelevant since it is 
isolated by a network layer (specifically popen).

Regards
-steve


From: Michał Jastrzębski >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, November 4, 2016 at 5:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3


So as Clint mentioned, strategy plugins probably will be tainted by GPL. One of 
alternatives would be to create separate project for this single plugin, but 
I'd rather avoid that.

Any other alternatives comes to mind?

On Nov 4, 2016 5:18 PM, "Fox, Kevin M" 
> wrote:
Must be gplv3 compatible. not necessarily gpl. apache license is compatible.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Friday, November 04, 2016 4:38 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
> On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
> [...]
> > As I understand it, the challenge here is that plugins for Ansible
> > will by definition be derivative works of Ansible and thus inherit
> > their license choice. No amount of "clean room reimplementation"
> > will solve that unless you also reimplement Ansible under a
> > different license while you're at it.
> [...]
>
> Further research suggests I'm wrong on this front. I was assuming
> Ansible was providing a Python plug-in API here, in which case
> coding to that would potentially create a derivative work. Instead
> it looks like for at least some things they refer to as plug-ins
> they pass around a JSON data structure which upstream Ansible has
> said in the past they do not consider to result in plug-ins becoming
> derivative works of Ansible. For example:
>
> https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py

Modules are not plugins.

> https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk

Same here.

> https://github.com/ansible/ansible/issues/8864

This only refers to dynamic inventory, which is hardly even a plugin
interface.

Strategy plugins run in ansible itself and must import pieces of Ansible,
and thus must be GPLv3:

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy

__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Michał Jastrzębski]

I read what you say Steven;) strategy plugin is not module, we don't use
popen there. Also it will require importing GPL code from Ansible itself.
Clint is right in this context. Writing it from scratch is not an option to
(way to complex than docker stuff we did). Imho only option will be to
write GPL driver that will be run with popen. Question is whether this
driver can sit in Kolla repo or not, and if not, where?

On Nov 4, 2016 6:51 PM, "Steven Dake (stdake)"  wrote:

> Michal,
>
>
>
> Have you read nothing I’ve said?  If its new code, write it as ASL2.0.
> The fact that it plugs in or uses GPLv3 code is totally irrelevant since it
> is isolated by a network layer (specifically popen).
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *Michał Jastrzębski 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, November 4, 2016 at 5:54 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3
>
>
>
> So as Clint mentioned, strategy plugins probably will be tainted by GPL.
> One of alternatives would be to create separate project for this single
> plugin, but I'd rather avoid that.
>
> Any other alternatives comes to mind?
>
>
>
> On Nov 4, 2016 5:18 PM, "Fox, Kevin M"  wrote:
>
> Must be gplv3 compatible. not necessarily gpl. apache license is
> compatible.
>
> Thanks,
> Kevin
> 
> From: Clint Byrum [cl...@fewbar.com]
> Sent: Friday, November 04, 2016 4:38 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3
>
> Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
> > On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
> > [...]
> > > As I understand it, the challenge here is that plugins for Ansible
> > > will by definition be derivative works of Ansible and thus inherit
> > > their license choice. No amount of "clean room reimplementation"
> > > will solve that unless you also reimplement Ansible under a
> > > different license while you're at it.
> > [...]
> >
> > Further research suggests I'm wrong on this front. I was assuming
> > Ansible was providing a Python plug-in API here, in which case
> > coding to that would potentially create a derivative work. Instead
> > it looks like for at least some things they refer to as plug-ins
> > they pass around a JSON data structure which upstream Ansible has
> > said in the past they do not consider to result in plug-ins becoming
> > derivative works of Ansible. For example:
> >
> > https://github.com/ansible/ansible/blob/devel/lib/
> ansible/module_utils/basic.py
>
> Modules are not plugins.
>
> > https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk
>
> Same here.
>
> > https://github.com/ansible/ansible/issues/8864
>
> This only refers to dynamic inventory, which is hardly even a plugin
> interface.
>
> Strategy plugins run in ansible itself and must import pieces of Ansible,
> and thus must be GPLv3:
>
> https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][ironic] Instance can "migrate" to another node?

[c1]

Message: 7
Date: Thu, 3 Nov 2016 16:50:54 +
From: Jay Faulkner >
To: "OpenStack Development Mailing List (not for usage questions)"
>
Subject: Re: [openstack-dev] [nova][ironic] Instance can "migrate" to
another node?
Message-ID: <1417f96d-bea5-457a-ba27-96511cbcb...@jvf.cc 
>
Content-Type: text/plain; charset="utf-8”

Thanks a lot, this very helpful for me.
⌘

> Hey, 
> 
> This is all detailed in the release notes for nova here: 
> http://docs.openstack.org/releasenotes/nova/newton.html#new-features 
>  ? just 
> search for ?Ironic?.
> 
> Here is the relevant section:
> "Note that instances will still be owned by the same nova-compute service for 
> the entire life of the instance, and so the ironic node that instance is on 
> will also be managed by the same nova-compute service until the node is 
> deleted. This also means that removing a nova-compute service will leave 
> instances managed by that service orphaned, and as such most instance actions 
> will not work until a nova-compute service with the same hostname is brought 
> (back) online.
> 
> When nova-compute services are brought up or down, the ring will eventually 
> re-balance (when the resource tracker runs on each compute). This may result 
> in duplicate compute_node entries for ironic nodes while the nova-compute 
> service pool is re-balancing. However, because any nova-compute service 
> running the ironic virt driver can manage any ironic node, if a build request 
> goes to the compute service not currently managing the node the build request 
> is for, it will still succeed.?
> 
> So essentially what this means is that for provisioned instances, there?s no 
> way to migrate them off of a failed compute host, but unprovisioned node 
> capacity will rebalance automatically between compute hosts when you 
> provision a new one. Essentially if you have a nova compute host fail but 
> want to be able to continue managing instances deployed by it, you?ll have to 
> build another nova-compute host with the same hostname (or CONF.host setting) 
> in order to do anything beyond deleting it.
> 
> Hope this helps,
> Jay Faulkner
> OSIC
> 
>> On Nov 3, 2016, at 3:12 AM, c1 > 
>> wrote:
>> 
>> Hi al,
>> 
>> Now, nova?s ironic driver can allow multiple compute services.
>> 
>> I am not sure that, when a compute node is down. 
>> 
>> The instances running in it, whether can ?migrate? to another compute 
>> node(use ironic driver)?
>> 
>> 
>> 
>> Thanks
>> 
>> C1dx 
>> 
>> __
>> OpenStack Development Mailing 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][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

Michal,

Have you read nothing I’ve said?  If its new code, write it as ASL2.0.  The 
fact that it plugs in or uses GPLv3 code is totally irrelevant since it is 
isolated by a network layer (specifically popen).

Regards
-steve


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

Date: Friday, November 4, 2016 at 5:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3


So as Clint mentioned, strategy plugins probably will be tainted by GPL. One of 
alternatives would be to create separate project for this single plugin, but 
I'd rather avoid that.

Any other alternatives comes to mind?

On Nov 4, 2016 5:18 PM, "Fox, Kevin M" 
> wrote:
Must be gplv3 compatible. not necessarily gpl. apache license is compatible.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Friday, November 04, 2016 4:38 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
> On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
> [...]
> > As I understand it, the challenge here is that plugins for Ansible
> > will by definition be derivative works of Ansible and thus inherit
> > their license choice. No amount of "clean room reimplementation"
> > will solve that unless you also reimplement Ansible under a
> > different license while you're at it.
> [...]
>
> Further research suggests I'm wrong on this front. I was assuming
> Ansible was providing a Python plug-in API here, in which case
> coding to that would potentially create a derivative work. Instead
> it looks like for at least some things they refer to as plug-ins
> they pass around a JSON data structure which upstream Ansible has
> said in the past they do not consider to result in plug-ins becoming
> derivative works of Ansible. For example:
>
> https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py

Modules are not plugins.

> https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk

Same here.

> https://github.com/ansible/ansible/issues/8864

This only refers to dynamic inventory, which is hardly even a plugin
interface.

Strategy plugins run in ansible itself and must import pieces of Ansible,
and thus must be GPLv3:

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy

__
OpenStack Development Mailing 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] [tc][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

Clint,

I disagree that modules (which are really plugins) must be licensed under 
GPLv3.  You may license any module code as you like (i.e. ASL2.0) and include 
it in a GPLv3 project via Ansible modules because the modules act as plugins.  
The ASL2.0 license does taint, however, it does not matter.

We run Ansible via popen, which treats Ansible as a Network Service.  The 
reality is we don’t care if modules (which are really plugins as they are used 
in Kolla) taint.  The taint occurs during instation of the module (which PLUGS 
IN to Ansible during runtime), not as a fact of including the code in the 
repository.

From previous conversations with the BOD and TC, they don’t see a problem with 
this since Ansible runs as a network service, isolating the licensing concerns.

A thought experiment (with some turtles).  If Apache was licensed under GPLv3, 
would your viewing of their web content automatically make that web content and 
all their web software infrastructure for displaying content GPLv3?  Now dig a 
little further, and ask, would that make your entire operating system GPLv3?  
Now dig a little further, would that make your workstation GPLv3?  Would that 
make you GPLv3 for viewing the content?  Are we all GPLv3?

That web content is analogous to an Ansible module.  The question I’d like you 
to answer if you would indulge me is “Where does the GPLv3 license end in this 
stream?”  Not as an attorney, but purely on technical grounds.  I know what the 
attorney’s say.

Please review the thread on the legal list for more background.

Regards
-steve

From: Clint Byrum 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 4:38 PM
To: openstack-dev 
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
[...]
> As I understand it, the challenge here is that plugins for Ansible
> will by definition be derivative works of Ansible and thus inherit
> their license choice. No amount of "clean room reimplementation"
> will solve that unless you also reimplement Ansible under a
> different license while you're at it.
[...]
Further research suggests I'm wrong on this front. I was assuming
Ansible was providing a Python plug-in API here, in which case
coding to that would potentially create a derivative work. Instead
it looks like for at least some things they refer to as plug-ins
they pass around a JSON data structure which upstream Ansible has
said in the past they do not consider to result in plug-ins becoming
derivative works of Ansible. For example:
https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py

Modules are not plugins.

https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk

Same here.

https://github.com/ansible/ansible/issues/8864

This only refers to dynamic inventory, which is hardly even a plugin
interface.

Strategy plugins run in ansible itself and must import pieces of Ansible,
and thus must be GPLv3:

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy

__
OpenStack Development Mailing 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][kolla] Ansible module with GPLv3

[Michał Jastrzębski]

So as Clint mentioned, strategy plugins probably will be tainted by GPL.
One of alternatives would be to create separate project for this single
plugin, but I'd rather avoid that.

Any other alternatives comes to mind?

On Nov 4, 2016 5:18 PM, "Fox, Kevin M"  wrote:

> Must be gplv3 compatible. not necessarily gpl. apache license is
> compatible.
>
> Thanks,
> Kevin
> 
> From: Clint Byrum [cl...@fewbar.com]
> Sent: Friday, November 04, 2016 4:38 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3
>
> Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
> > On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
> > [...]
> > > As I understand it, the challenge here is that plugins for Ansible
> > > will by definition be derivative works of Ansible and thus inherit
> > > their license choice. No amount of "clean room reimplementation"
> > > will solve that unless you also reimplement Ansible under a
> > > different license while you're at it.
> > [...]
> >
> > Further research suggests I'm wrong on this front. I was assuming
> > Ansible was providing a Python plug-in API here, in which case
> > coding to that would potentially create a derivative work. Instead
> > it looks like for at least some things they refer to as plug-ins
> > they pass around a JSON data structure which upstream Ansible has
> > said in the past they do not consider to result in plug-ins becoming
> > derivative works of Ansible. For example:
> >
> > https://github.com/ansible/ansible/blob/devel/lib/
> ansible/module_utils/basic.py
>
> Modules are not plugins.
>
> > https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk
>
> Same here.
>
> > https://github.com/ansible/ansible/issues/8864
>
> This only refers to dynamic inventory, which is hardly even a plugin
> interface.
>
> Strategy plugins run in ansible itself and must import pieces of Ansible,
> and thus must be GPLv3:
>
> https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy
>
> __
> OpenStack Development Mailing 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] [tc][kolla] Ansible module with GPLv3

[Fox, Kevin M]

Must be gplv3 compatible. not necessarily gpl. apache license is compatible.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Friday, November 04, 2016 4:38 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
> On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
> [...]
> > As I understand it, the challenge here is that plugins for Ansible
> > will by definition be derivative works of Ansible and thus inherit
> > their license choice. No amount of "clean room reimplementation"
> > will solve that unless you also reimplement Ansible under a
> > different license while you're at it.
> [...]
>
> Further research suggests I'm wrong on this front. I was assuming
> Ansible was providing a Python plug-in API here, in which case
> coding to that would potentially create a derivative work. Instead
> it looks like for at least some things they refer to as plug-ins
> they pass around a JSON data structure which upstream Ansible has
> said in the past they do not consider to result in plug-ins becoming
> derivative works of Ansible. For example:
>
> https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py

Modules are not plugins.

> https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk

Same here.

> https://github.com/ansible/ansible/issues/8864

This only refers to dynamic inventory, which is hardly even a plugin
interface.

Strategy plugins run in ansible itself and must import pieces of Ansible,
and thus must be GPLv3:

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy

__
OpenStack Development Mailing 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] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Steve Martinelli]

The keystone team has a new spec being proposed for the Ocata release, it
essentially boils down to adding properties / metadata for projects (for
now) [1].

We have somewhat had support for this, we have an "extras" column defined
in our database schema, whatever a user puts in a request that doesn't
match up with our API, those key-values are dumped into the "extras"
column. It's not a pleasant user experience, since you can't really "unset"
the data easily, or grab it, or update it. There's actually been patches to
keystoneclient for getting around this, but its rather hacky and hardcodes
a lot of values [2] [3]

I've added nova and cinder here since the APIs that are being proposed are
more or less carbon copies of what is available through their APIs (for
server and volumes, respectively). What has been your project's experience
with handling metadata / properties? I assume that its been there a while
and you can't remove it. If you could go back and redo things, would you do
it another way? Would you take a more purist stance and enforce more strict
APIs, metadata be damned?

I also added horizon because i'm curious about the impact this causes when
representing a resource.

Personally, I am for the idea, we've had numerous requests from operators
about providing this support and I like to make them happy.

[1] https://review.openstack.org/#/c/36/
[2] https://review.openstack.org/#/c/375239/
[3] https://review.openstack.org/#/c/296246/
__
OpenStack Development Mailing List (not for 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][solum] is solum-infra-guestagent an unmaintained project?

[Steve Martinelli]

bump, still hoping to get feedback on this

On Fri, Oct 28, 2016 at 1:23 AM, Steve Martinelli 
wrote:

> When reviewing the projects necessary for the ocata community-wide goal,
> (to remove old oslo-incubator code [1]) I noticed that solum-infra-guest
> agent has had *very* few commits, 13 in total [2]. Almost half of which
> were project cleanup type changes that all projects did. The last patch of
> significance was over 2 years ago (Sept 2014).
>
> I'm inquiring as to the status of the project, and what we should do about
> it? It's still being maintained by the good will of some community members,
> but it's eating up time nonetheless.
>
> [1] https://etherpad.openstack.org/p/ocata-goal-oslo
> [2] https://github.com/openstack/solum-infra-guestagent/commits/master
>
__
OpenStack Development Mailing List (not for 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][kolla] Ansible module with GPLv3

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +:
> On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
> [...]
> > As I understand it, the challenge here is that plugins for Ansible
> > will by definition be derivative works of Ansible and thus inherit
> > their license choice. No amount of "clean room reimplementation"
> > will solve that unless you also reimplement Ansible under a
> > different license while you're at it.
> [...]
> 
> Further research suggests I'm wrong on this front. I was assuming
> Ansible was providing a Python plug-in API here, in which case
> coding to that would potentially create a derivative work. Instead
> it looks like for at least some things they refer to as plug-ins
> they pass around a JSON data structure which upstream Ansible has
> said in the past they do not consider to result in plug-ins becoming
> derivative works of Ansible. For example:
> 
> https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py

Modules are not plugins.

> https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk

Same here.

> https://github.com/ansible/ansible/issues/8864

This only refers to dynamic inventory, which is hardly even a plugin
interface.

Strategy plugins run in ansible itself and must import pieces of Ansible,
and thus must be GPLv3:

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy

__
OpenStack Development Mailing List (not for 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][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

Cool.

I didn’t even know ansible had a BSD licensed example module.  As we have a 
module expertise in our community already, I suspect we will start from zero 
code rather than introduce a BSD license addendum to the Kolla repo.

Regards
-steve


From: Jeremy Stanley 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 4:05 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
[...]
As I understand it, the challenge here is that plugins for Ansible
will by definition be derivative works of Ansible and thus inherit
their license choice. No amount of "clean room reimplementation"
will solve that unless you also reimplement Ansible under a
different license while you're at it.
[...]

Further research suggests I'm wrong on this front. I was assuming
Ansible was providing a Python plug-in API here, in which case
coding to that would potentially create a derivative work. Instead
it looks like for at least some things they refer to as plug-ins
they pass around a JSON data structure which upstream Ansible has
said in the past they do not consider to result in plug-ins becoming
derivative works of Ansible. For example:

https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py
https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk
https://github.com/ansible/ansible/issues/8864

So yes, as long as you don't fork or copy from a GPL'd plug-in, your
plug-in could be implemented in other licenses and could even copy
from Ansible's BSD-licensed basic module example.
--
Jeremy Stanley

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

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

[John Dickinson]

On 4 Nov 2016, at 7:50, Jim Rollenhagen wrote:

> On Thu, Nov 3, 2016 at 3:04 PM, Joshua Harlow  wrote:
>> Jay Faulkner wrote:

 On Nov 3, 2016, at 11:27 AM, Joshua Harlow  wrote:

 Just as a followup from the summit,

 One of the sessions (the new lib one) had a few proposals:

 https://etherpad.openstack.org/p/ocata-oslo-bring-ideas

 And I wanted to try to get clear owners for each part (there was some
 followup work for each); so just wanted to start this email to get the
 thoughts going on what to do for next steps.

 *A hash ring library*

 So this one it feels like we need at least a tiny oslo-spec for and for
 someone to write down the various implementations, what they share, what
 they do not share (talking to swift, nova, ironic and others? to figure 
 this
 out). I think alexis was thinking he might want to work through some of 
 that
 but I'll leave it for him to chime in on that (or others feel free to 
 also).

 This one doesn't seem very controversial and the majority of the work is
 probably on doing some analysis of what exists and then picking a library
 name and coding that up, testing it, and then integrating (pretty 
 standard).

>>>
>>> Ironic and Nova both share a hash ring implementation currently
>>> (ironic-conductor and nova-compute driver for ironic). It would be sensible
>>> to reuse this implementation, oslo-ify it, and have that code shared.
>>>
>>> I question the value of re-implementing something like this from scratch
>>> though.
>>>
>>> Thanks,
>>> Jay Faulkner
>>> OSIC
>>>
>>
>> Right I don't think the intention would be to implement it from scratch, but
>> to do some basic analysis of what exists (and think about and document the
>> patterns), and try to find the common parts (which likely involves renaming
>> some specific nova/ironic methods from what I see); especially if we can get
>> swift to perhaps (TBD) also use and contribute to this library.
>
> As the person who copied that code into Nova, the Nova code is a strict subset
> of the Ironic code.
>
> Some of us talked to John Dickinson off-list, and it seems the Swift hash ring
> has very different use cases and very different implementation. I
> think we should
> focus on pulling the Nova/Ironic code out first, and then talking to
> Swift if we can
> also make it work for them (sounds like it's not helpful today).
>
> // jim


We had some great conversations last week face to face about this. The summary 
is that the "ring" in Ironic/Nova and the placement "ring" in Swift are vastly 
different in scope, requirements, and capabilities. I don't think it makes 
sense to try to unify them at this time.

As always, I'm available to talk further about this, if you want.


--John







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

[openstack-dev] OpenStack Developer Mailing List Digest October 29 to November 4

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/11/openstack-developer-mailing-list-digest-20161104/

Cross Project Proprietary Driver Code Recap
===
* At the Barcelona design summit there was a cross-project session on the
challenge we’re running where to draw the line with proprietary driver code
[1].
* Option 1:
  - All libraries imported by the driver must be licensed such that they are
redistributable by package maintainers and must be compatible with the
Apache license [2].
  - Existing non-compliant driver code would need to be updated by Queens
release.
  - Code that’s not imported at the driver runtime (CLIs, external binaries,
remote application servers) are acceptable to not be redistributable.
* Option 2:
  - Remove all drivers that are not completely open source and contained in the
project repositories.
* Option 3:
  - Require majority of the business logic is in the open source code.
  - Allow third party, non-redistributable libraries and CLIs that are used as
more of an “RPC” type interface.
  - Reviewers should be able to review the driver and at least get some idea of
the steps the driver is doing to perform requests.
* Jeremy Stanley would like to take option 1 a step further and provide better
  guidance. We should recommend against drivers calling proprietary tools. Some
  vendors go this route because they already have a non-free CLI tool and avoid
  code cost duplication. Other vendors may do this to copy other vendors.
  - The desire of having things redistributable is so that downstream consumers
of OpenStack are not beholden to vendors just to be able to use our (free!)
software with hardware they have.
  - For example
-- Vendor decides to stop supporting a proprietary command line tool
-- You decide to stop paying support contracts to download that tool
-- Vendor disappears
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/106432.html

Ocata Release Management Communication
==
* To the PTL’s or or volunteers filling in for a PTL:
* Email
  - The “[release]” topic tag on the openstack-dev mailing list will be used
for important messages.
  - Countdown email with updates on focus, tasks, and upcoming dates.
* IRC
  - Be available on #openstack-release, especially during deadline periods.
It’s up to you to configure an IRC bouncer to ensure this.
* Written documentation
  - Read the Ocata cycle schedule [3].
  - Some projects have their own deadlines. Feel free to submit a patch to this
schedule within the openstack/release repository.
* The Ocata cycle overlaps with several major holidays. If you’re planning time
  off, please make sure your duties are covered by someone else on your team.
  Let the release team know about this so they’re not waiting for your +1.
* Failing to follow through on a needed process step may block you from
  successfully meeting deadlines or releasing.
* Releases milestones and deadlines are date-based, not feature based. When the
  date passes, so does the milestone. If you miss it, you miss it.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106509.html

Release Announcements
=
* The release team at the Barcelona summit discussed how to improve release
  announcements as posting them to openstack-dev and openstack-announce has
  proven to be pretty noisy.
* Proposed solution is to move these announcements to another mailing list. 
Choices are:
  - release-announce
  - release-announcements
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#106579

POST /api-wg/news
* API guidelines that will be merged in one week if there is no further
  feedback:
  - Complex queries [4]
  - Specify time intervals based filtering queries [5]
  - Clarify why CRUD is not a great descriptor [6]
* Guidelines under review:
  - Define pagination guidelines [7]
  - Add API capabilities discovery [8]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106671.html

Release Countdown for Week R-15
===
* Focus:
  - Teams should be focusing on wrapping up incomplete work left over from the
end of the Newton cycle.
  - Finalizing and announcing plans from the summit
  - Completing specs and blueprints
* General notes:
  - Stable and independent releases have resumed.
  - We cut time out of the Ocala schedule before the first milestone. Ocata-1
will be during R-14.
* Release actions:
  - Release liaisons should add their name and contact information to the wiki
[9].
  - Release liaisons should configure their IRC clients to join
#openstack-release.
  - Release liaisons should review the release models for all deliverables and
make any updates with patches to openstack/governance before the first
milestone.
  - PTLs should add

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Jeremy Stanley]

On 2016-11-04 23:06:05 + (+), Steven Dake (stdake) wrote:
[...]
> The correct answer here is simply to develop an ASL2.0 module that
> works with Ansible. The GPLv3 does not require us to implement
> Ansible modules in GPLv3 – we may use whatever license we like (in
> this case ASL2.0 should be used).
[...]

Yep, thanks! I started questioning this interpretation too and found
counterexamples endorsed by Ansible so this does seem like a
relatively easy way out (see my other reply to myself just now).
-- 
Jeremy Stanley


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

[openstack-dev] [nova] A note to contributors - bug triage ftw!

[Matt Riedemann]

There was a lot of discussion at the Ocata summit about new contributors 
and not so new contributors and what they can do.


Well, bug triage is a pretty simple but very effective way to help out 
and also be productive.


At about 4:30pm CST today (Friday), I was perusing the untriaged nova 
bug list [1] which was at 75. As noted in the nova meeting this week, 
that number is creeping up and we had been good about keeping it <40 for 
most of newton, so we're not doing a good job at triaging new bugs for 
the most part in Ocata.


In about an hour I've triaged 7 bugs and have put up patches for two of 
them.


For a rundown on the process involved there, just in case you're 
wondering about how to do bug triage and the thought process, this is 
how I handled these.


1. https://bugs.launchpad.net/nova/+bug/1639362

There is no log/stacktrace with the error, so its Incomplete. Ask the 
reporter for more details. I also think it's a duplicate of another one 
that I triaged.


2. https://bugs.launchpad.net/os-brick/+bug/1639350

I poked around on this one a bit, it admittedly takes a bit more 
understanding of knowing how the attach volume flow works in the libvirt 
driver, but it's pretty simple to just look at the code. I also pinged 
jgriffith in #openstack-cinder to talk about it a bit. Either way it's 
latent behavior so I marked it as opinion/wishlist for nova.


3. https://bugs.launchpad.net/nova/+bug/1639239

nova-compute fails to start if you're running on s390x - awesome!

Took a second to decide if ISER + s390x is supported in os-brick, but 
then decided that doesn't matter. The real bug here is that os-brick 
raises a ValueError for that combination and the libvirt driver doesn't 
handle it on startup, causing the nova-compute service to crash. This is 
going to be a two-part fix:


a) Land a change in os-brick to raise a more specific exception. Release 
os-brick and bump global-requirements to use that version.


b) Land a change in nova to catch that specific exception, log something 
but don't crash.


4. https://bugs.launchpad.net/nova/+bug/1638813

I didn't even know that get-password CLI existed in novaclient - 
surprise! Even the PTL doesn't know everything about Nova. :)


But from poking around in the code for the CLI and the REST API in Nova, 
it relies on the metadata service, which not every deployment runs. So 
the natural question back to the reporter is, is the metadata service 
running? Mark the bug Incomplete and move on.


5. https://bugs.launchpad.net/nova/+bug/1638381

Unicode failures, yay! This is in mitaka and we don't have a stacktrace, 
so I had to ask the reporter to try and change a LOG.error to 
LOG.exception, recreate and post the results so we can see where it 
really fails. Mark the bug Incomplete and move on.


6. https://bugs.launchpad.net/nova/+bug/1638339

Checked the docs job logs from the linked patch, yup, it fails. Checked 
kombu version in the job log versus what's in stable/mitaka 
upper-constraints, yup, the docs job doesn't use u-c. Marked it 
Confirmed, but not sure we'll actually fix it.


7. https://bugs.launchpad.net/nova/+bug/1636185

Checked the api-ref docs, checked the code, yup, it's wrong. There is 
even a TODO in the server-actions api-ref that we need an API sample for 
that addFloatingIp action. It's a pretty simple fix. Granted, I knew 
where to look, but by doing some simple grepping in the nova repo it 
should be trivial for anyone to find where those docs are generated and 
update it.




So what's the point? My point is that within about an hour I'm able to 
triage 7 bugs and put up fixes for 2 of them. That doesn't make me 
awesome. But it means that it's not as hard as maybe people think it is, 
and if everyone did just one new bug per day, we'd have far fewer bugs 
and more of the low-hanging really simple stuff cleaned up.


Getting your code reviewed by the core team...that's another issue as we 
all know and talked about at length at the summit. But these are 
definitely things that everyone can help out with, and reviewing them 
and raising them up in IRC to the core team with a simple, 'hey, this is 
a really simple bug fix, please take a look' can help move things along.


[1] https://goo.gl/RClmZb

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Jeremy Stanley]

On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
[...]
> As I understand it, the challenge here is that plugins for Ansible
> will by definition be derivative works of Ansible and thus inherit
> their license choice. No amount of "clean room reimplementation"
> will solve that unless you also reimplement Ansible under a
> different license while you're at it.
[...]

Further research suggests I'm wrong on this front. I was assuming
Ansible was providing a Python plug-in API here, in which case
coding to that would potentially create a derivative work. Instead
it looks like for at least some things they refer to as plug-ins
they pass around a JSON data structure which upstream Ansible has
said in the past they do not consider to result in plug-ins becoming
derivative works of Ansible. For example:

https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py
https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk
https://github.com/ansible/ansible/issues/8864

So yes, as long as you don't fork or copy from a GPL'd plug-in, your
plug-in could be implemented in other licenses and could even copy
from Ansible's BSD-licensed basic module example.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

Jeremy

Apologies for top post – lookout broken again.

Since Kolla uses popen to launch Ansible, and the module loads into GPLv3 code, 
the GPLv3 license ends at the Ansible end of the popen call.  Transitive 
dependencies are not a thing with network services (popen creates a network 
service).

If we are talking using someone else’s GPLv3 code, that is completely forbidden 
and I’d -2 any such review I saw in the queue that behaved in this way.

The correct answer here is simply to develop an ASL2.0 module that works with 
Ansible.  The GPLv3 does not require us to implement Ansible modules in GPLv3 – 
we may use whatever license we like (in this case ASL2.0 should be used).  The 
fact that on instantiation a transitive dependency is created inside the 
network service (at the second end of the popen call) simply means that code 
ends up with some kind of GPLv3 license *on instantiation* not on 
implementation as the plugins themselves can be developed directly in Ansible 
without interaction with the rest of the Kolla code base.

GPLv3 does not cross network boundaries, or the entire world of computing would 
be in chaos.

Regards
-steve

From: Jeremy Stanley 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 3:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

On 2016-11-04 22:22:47 + (+), Steven Dake (stdake) wrote:
[...]
The first file I examine in any repository is the LICENSE file –
if its GPLv3, I look no further.  I recommend everyone that has
signed the CLA follow the same pattern to keep OpenStack in good
legal health.

As I understand it, the challenge here is that plugins for Ansible
will by definition be derivative works of Ansible and thus inherit
their license choice. No amount of "clean room reimplementation"
will solve that unless you also reimplement Ansible under a
different license while you're at it.

If having the ICLA enforced on a repo with GPL code in it is an
issue, this could in theory be resolved by putting it in a separate
repository with no CLA enforcement. If a plug-in for Ansible being
under the same license as Ansible poses a problem for a repo as a
deliverable of an official OpenStack project team, then perhaps it
could just be distributed in an unofficial repo instead (though this
seems overly proscriptive to me).
--
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Steven Dake (stdake)]

Swapnil,

If you feel someone is lazy with not filing bugs for backports or feature 
request, with a monster feature request or something that requires a backport, 
simply -1 the review and add a polite comment “Please add a bug ID or 
blueprint”.

Regards,
-steve


From: Swapnil Kulkarni 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 5:48 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke 
> wrote:
Kolleagues,

How do people feel above removing the requirement of having TrivialFix in
commit messages where a bug/bp is not required?

I'm seeing a lot of valid and important commits being held up because of
this, in my opinion, unnecessary requirement. It also causes friction for
new contributers to the project.

Are there any major benefits we're getting from the use of this tag that I'm
missing?

Cheers,
-Paul

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

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.
It would take 1/30(I am just making highest time for a build/deploy
gate) amount of time you need to verify the (important)fix on gate.

[1] docs.openstack.org/developer/kolla/CONTRIBUTING.html

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

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Steven Dake (stdake)]

Paul,

I’ll take your request as a request for a vote of the core reviewers.

My vote is +1 in favor of removing the requirement for TrivialFix.

As per our standard policy, the voting window is open for 7 days beginning 
November 3rd, and finishing (in 7 days) on November 11th.

Regards
-steve


From: Paul Bourke 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, November 3, 2016 at 6:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

Kolleagues,

How do people feel above removing the requirement of having TrivialFix
in commit messages where a bug/bp is not required?

I'm seeing a lot of valid and important commits being held up because of
this, in my opinion, unnecessary requirement. It also causes friction
for new contributers to the project.

Are there any major benefits we're getting from the use of this tag that
I'm missing?

Cheers,
-Paul

__
OpenStack Development Mailing 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][kolla] Ansible module with GPLv3

[Jeremy Stanley]

On 2016-11-04 22:22:47 + (+), Steven Dake (stdake) wrote:
[...]
> The first file I examine in any repository is the LICENSE file –
> if its GPLv3, I look no further.  I recommend everyone that has
> signed the CLA follow the same pattern to keep OpenStack in good
> legal health.

As I understand it, the challenge here is that plugins for Ansible
will by definition be derivative works of Ansible and thus inherit
their license choice. No amount of "clean room reimplementation"
will solve that unless you also reimplement Ansible under a
different license while you're at it.

If having the ICLA enforced on a repo with GPL code in it is an
issue, this could in theory be resolved by putting it in a separate
repository with no CLA enforcement. If a plug-in for Ansible being
under the same license as Ansible poses a problem for a repo as a
deliverable of an official OpenStack project team, then perhaps it
could just be distributed in an unofficial repo instead (though this
seems overly proscriptive to me).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Steven Dake (stdake)]

Andreas,

Agree.  Asked and answered.  If Michal has some differing viewpoint, that’s his 
prerogative as the PTL of Kolla, however, I would have serious concerns with 
that model, and would request a vote of the core reviewers to solidify our 
processes to match the OpenStack way.

Regards
-steve


From: Andreas Jaeger 
Organization: SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham 
Norton, HRB 21284 (AG Nürnberg)
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 8:30 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

On 11/04/2016 04:25 PM, Jeremy Stanley wrote:
On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:
I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.
[...]
All I ask is that if the Kolla team wants to differentiate itself
from the review requirements of most OpenStack projects, please make
sure you have active and attentive liaisons who can update
mass-proposed changes for base infrastructure or other similar
horizonal and cross-project efforts to meet your special reviewing
standards. I cannot personally keep on top of the nuances of every
review team and individually adjust such mass changes myself, so
rely on you to "fix" my patches for me in such situations.

Jeremy, I do agree with your request.

I expect this to be settled by Steven Dake's email:
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105287.html

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


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

__
OpenStack Development Mailing List (not for 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][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

Define “touching GPLv3 code”.  If you mean using someone else’s work which 
creates a derived work, that is a big no-no.  This would cause your CL

If it’s a fresh implementation, then USE ASL2.0.  This creates a transitive 
dependency that taints the module on instantiation, however, since we use 
Ansible via popen rather than an import ansible line in our python code, the 
module taints as GPLv3 (even though the module may be licensed under ASL 2.0).  
This does not run afoul of the GPLv3.

Regards
-steve


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

Date: Friday, November 4, 2016 at 9:42 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Hello,

As you could see in [1], ansible is notorious with it's GPL v3
license. I have question about having single module in Kolla-ansible
project that will be GPL v3.

Kolla is licensed as Apache v2 all across the board today. To
implement one of highly requested features we would need to develop
so-called strategy plugin for ansible, and I can't see any reasonable
way to do it without touching GPL v3 code.

While I wouldn't mind having single GPL v3 licensed module in Kolla,
and this particular use case doesn't seem to affect licensing of other
parts of our project, I would like to ask for second opinion before we
run into legal issues.


[1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095489.html

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

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Steven Dake (stdake)]

Jeremy,

Kolla doesn’t want to be a special snowflake WRT patches.  TrivialFix was 
introduced to help core reviewers identify what bugs need backports vs which 
changes do not or are feature changes (which we also don’t backport).  We don’t 
always get backport tracking correctly, but I think we are running about 90% or 
better, which is GEFN.  Gaming reviews by using TrivialFix that require actual 
backports are responded to in my reviews with a polite “Please add a Bug ID” 
with a -1 associated in the review.  I believe most of the core team is on 
board with this model – if not we should have a vote on it amongst the core 
reviewer team.

Regards
-steve


From: Jeremy Stanley 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 9:31 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

On 2016-11-04 15:42:17 + (+), Paul Bourke wrote:
We have no desire to do this, that's not what is being discussed
here. On the contrary we're looking to reduce the barrier to entry
for committers. Also the team is aware that cross project efforts
should not be nit picked.

That's what it seemed like to me up to this point in the thread as
well; I was specifically replying to Swapnil's suggestion that any
important change to Kolla deliverables should have a bug filed or
should continue to add a TrivialFix header in the commit message
otherwise. (And yes, as Andreas pointed out the other thread on the
related topic of mass changes for cross-project efforts does address
the case specifically, but becomes less necessary if you end up
agreeing to drop the TrivialFix requirement.)
--
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Steven Dake (stdake)]

The general rule I follow (and would propose we stick to) is is as follows:

If it requires a backport – it requires a bug id.  (This is to facilitate the 
tracking of backports to make sure we do the job correctly)
If it doesn’t require a backport but is a feature submission, it should include 
a blueprint header (for tracking purposes, yet again)
If it doesn’t fit into the above two categories, I really don’t see a need for 
any type of extra tagging including TrivialFix.  TrivialFix was a nice idea to 
help core reviewers understand if the work needed a backport, or was a feature 
request.  Our core reviewer team is smart enough to make that determination 
during the very thorough review process we undertake on all patches.

TrivialFix can go assuming the core reviewers can determine what is needed for 
a backport (high/critical bugs only) – and request a bug ID during the review 
with an appropriate -1.

Regards
-steve


From: Swapnil Kulkarni 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 10:50 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

On Fri, Nov 4, 2016 at 10:01 PM, Jeremy Stanley 
> wrote:
On 2016-11-04 15:42:17 + (+), Paul Bourke wrote:
We have no desire to do this, that's not what is being discussed
here. On the contrary we're looking to reduce the barrier to entry
for committers. Also the team is aware that cross project efforts
should not be nit picked.

That's what it seemed like to me up to this point in the thread as
well; I was specifically replying to Swapnil's suggestion that any
important change to Kolla deliverables should have a bug filed or
should continue to add a TrivialFix header in the commit message
otherwise. (And yes, as Andreas pointed out the other thread on the
related topic of mass changes for cross-project efforts does address
the case specifically, but becomes less necessary if you end up
agreeing to drop the TrivialFix requirement.)
--
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


Jeremy,

I am sorry if I have miscommunicated earlier. I am referring to the
situation where people are using TrivialFix just to get the changes in
which is not good practice.

I agree with removing TrivialFix just that we need to be very careful
with changes that need tracking (e.g. bug/bp).

__
OpenStack Development Mailing 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][kolla] Ansible module with GPLv3

[Steven Dake (stdake)]

Wrong answer.  The correct answer is all software in the Kolla repository 
should be ASL2.0 licensed.  See legal list for a more thorough explanation 
based upon the historical discussions I’ve been through with the TC and BOD on 
this question.  If it is GPLv3 licensed code, it should be implemented from 
scratch (IMO) by someone that has never seen the original work.  I’d recommend 
Lei (jeffrey4l) for this, unless he has been tainted by viewing of the code in 
which case, ask me, and I’ll write it, since I don’t look at any GPLv3 code 
(intentionally).

The first file I examine in any repository is the LICENSE file – if its GPLv3, 
I look no further.  I recommend everyone that has signed the CLA follow the 
same pattern to keep OpenStack in good legal health.

Regards
-steve



From: Zane Bitter 
Organization: Red Hat
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, November 4, 2016 at 2:48 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

On 04/11/16 12:51, Jeremy Stanley wrote:
On 2016-11-04 11:42:25 -0500 (-0500), Michał Jastrzębski wrote:
[...]
Kolla is licensed as Apache v2 all across the board today. To
implement one of highly requested features we would need to develop
so-called strategy plugin for ansible, and I can't see any reasonable
way to do it without touching GPL v3 code.
[...]

[I am not a lawyer.] We just discussed this in #openstack-infra as
well. Since Kolla is shelling out to an Ansible executable, it's not
likely to count as being a derivative work of Ansible. Consequently,
the Kolla plug-in imported by Ansible being GPLv3 while shipped in
the same repo as Apache License 2.0 Kolla source code would simply
be aggregation of software under distinct licenses.

I agree that this would be an aggregation of software under distinct
licenses, but one of those licenses is distinctly not allowed in
OpenStack (we allow only ASLv2, MIT and BSD[1]). In fact IIUC anybody
who tried to contribute a GPLv3 file would be inadvertently in breach of
their CLA (the part where "You represent that you are legally entitled
to grant the above license.").

That said, it can't hurt to ask this again on
legal-disc...@lists.openstack.org 
where it's much more on-topic.

Also replied there, but I'm mentioning here to make sure core reviewers
are aware that they should -2 any patches containing GPL code with
extreme prejudice.

(Note that this applies only to OpenStack-proper - i.e. repos listed in
the governance repo as part of the big tent. OpenStack Infra is
specifically excluded in the policy.)

cheers,
Zane.

[1] http://governance.openstack.org/reference/licensing.html

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

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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Zane Bitter]

On 04/11/16 12:51, Jeremy Stanley wrote:

On 2016-11-04 11:42:25 -0500 (-0500), Michał Jastrzębski wrote:
[...]

Kolla is licensed as Apache v2 all across the board today. To
implement one of highly requested features we would need to develop
so-called strategy plugin for ansible, and I can't see any reasonable
way to do it without touching GPL v3 code.

[...]

[I am not a lawyer.] We just discussed this in #openstack-infra as
well. Since Kolla is shelling out to an Ansible executable, it's not
likely to count as being a derivative work of Ansible. Consequently,
the Kolla plug-in imported by Ansible being GPLv3 while shipped in
the same repo as Apache License 2.0 Kolla source code would simply
be aggregation of software under distinct licenses.


I agree that this would be an aggregation of software under distinct 
licenses, but one of those licenses is distinctly not allowed in 
OpenStack (we allow only ASLv2, MIT and BSD[1]). In fact IIUC anybody 
who tried to contribute a GPLv3 file would be inadvertently in breach of 
their CLA (the part where "You represent that you are legally entitled 
to grant the above license.").



That said, it can't hurt to ask this again on
legal-disc...@lists.openstack.org where it's much more on-topic.


Also replied there, but I'm mentioning here to make sure core reviewers 
are aware that they should -2 any patches containing GPL code with 
extreme prejudice.


(Note that this applies only to OpenStack-proper - i.e. repos listed in 
the governance repo as part of the big tent. OpenStack Infra is 
specifically excluded in the policy.)


cheers,
Zane.

[1] http://governance.openstack.org/reference/licensing.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] [nova] ocata summit unconference session recap

[Matt Riedemann]

We had a single unconference session this time at the Ocata summit. The 
full etherpad is here:


https://etherpad.openstack.org/p/ocata-nova-summit-unconference

We spent most of the session talking about three newly proposed virt 
drivers.


IBM PowerVM
---

The PowerVM driver has been getting developed out of the nova tree but 
in the openstack namespace for a couple of years now. The team working 
on it has been attending summits and meetups providing status and 
working on CI. There are some users. There is a spec proposed:


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

to start adding in some of the minimum required functionality for an 
in-tree driver and start running the PowerVM CI on Nova changes.


There was quite a bit of discussion in the room about the driver, like 
whether or not it requires cinder/neutron plugins (it doesn't), but 
ultimately there was general agreement on the plan to ease the driver in 
and iterate on adding feature parity from the out of tree driver to nova 
in later releases.


IBM zDPM


This was more socializing the driver and Q about it. There is no code 
so nothing really to talk about getting in tree. There was a note that 
it takes 10 minutes to create a server, which raised some questions.


The direction here was basically follow the PowerVM driver model, which 
is work on the driver in the open, work on CI, work on customers, and 
attend developer events / stay involved in the Nova community to provide 
updates on status.


Huawei FusionCompute


This is a driver that Huawei has had for their FusionSphere product, 
since around the Folsom release. The code has been made available on 
github. It requires a cinder driver but not a neutron ML2 plugin.


The general feeling on this driver was it's not a good fit for Nova 
given it's an abstraction to an entire other virtualization management 
system, sort of like vCenter or PowerVC. That kind of architecture 
raises issues with resource tracking and state management and while yes 
the vCenter driver is in nova, the architecture it relies on has been 
problematic and we don't really want to make the same mistake with more 
virt drivers.


There was some feedback on the other side of this to the effect that if 
there are customers / users of the FusionCompute driver, why would we 
not allow it into Nova - and if there are limitations with it then it's 
up to the vendor to deal with them, or the users to have to live with 
them. This is a debate that isn't likely to go away anytime soon given 
the platform9/omni demo at the summit which is essentially a virt driver 
for AWS.


So while it doesn't look probable for this driver to get into Nova, at 
least anytime soon, it is in Huawei's best interest to develop the 
driver in the open and work on CI.


Generalize PCI device as Host device


This was a spec mentioned during the session:

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

The intent is to generalize host PCI devices are modeled in Nova so that 
new types can be built into that model for new support, like for vGPUs.


There wasn't a lot of discussion on this during the session, and not all 
of the best people to weigh in on this were in the room, so the 
direction was to move discussion to the spec and get the 
SR-IOV/PCI/resource provider people like lbeliveau, jaypipes and moshele 
to review the spec.


--

Thanks,

Matt Riedemann


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

[openstack-dev] Can openstack/jacket be removed now?

[Matt Riedemann]

The jacket project was added to project-config several months ago:

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

To date it's more wiki:

https://wiki.openstack.org/wiki/Jacket

Than code:

https://github.com/openstack/jacket/commits/master

Given the platform9/omni [1] stuff demo'ed at the Ocata summit is 
essentially the same idea (drivers that proxy to public clouds like 
AWS), and jacket has no involvement, can we just drop it now?


I just don't like it because it causes confusion about solutions like 
this in OpenStack which don't actually even have code, and it comes up 
from time to time when talking about adding virt drivers like this into 
Nova.


[1] https://github.com/platform9/openstack-omni

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [tripleo] proposing Michele Baldessari part of core team

[mathieu bultel]

On 11/04/2016 06:40 PM, Emilien Macchi wrote:
> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
>
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
>
> As usual, feedback is welcome and please vote for this proposal!
>
> Thanks,
+1  of course ! :)

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

[openstack-dev] [nova] API work for ocata summit session recap

[Matt Riedemann]

John Garbutt led a session at the summit focusing on some of the API 
work items for Ocata. The full etherpad is here:


https://etherpad.openstack.org/p/ocata-nova-summit-api

API capabilities


We talked a bit about the cross-project discoverable API spec. There was 
also a xp session on that earlier in the week so John was reporting the 
highlights of that session. There is some general consensus on the 
approach, but the details are going to be hashed out in the API WG spec:


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

The goal for Ocata is just finding agreement in the API WG spec and 
getting that merged so we can start focusing on implementation in Pike.


Proxy APIs
--

We deprecated a lot of the proxy APIs in the 2.36 microversion in 
Newton, but there are still other proxy APIs left in Nova. Some are 
straight-forward and we've already approved specs to clean them up, like 
the image metadata proxy extension. But others like multinic and 
floating IP actions and security group handling in server create 
requests are more complicated so we've elected to defer those topics for 
Ocata as we have higher priorities.


API extension folding
-

sdague started doing some of this in Newton and while it's fairly 
mechanical it's not trivial work to do correctly or review, so it's 
probably the type of thing that's going to be deferred to Pike.


API docs


We'll continue working the api-ref cleanups. We now have docs generated 
for the sample policy file in the nova devref. The policy.yaml docs 
could use descriptions for each policy, but we said we wouldn't start on 
that until after the config option cleanup effort is done.


General loose ends and new ideas


There are several random API impacting specs up for review. We didn't 
discuss many of these in great detail. The thing to take away from this 
is we have several approved blueprints already that impact the REST API 
and will require microversions, so we already have plenty to do (and 
review). I'll also make a side note that some of the approved blueprints 
don't have code up for review yet which is concerning.


Some new things that we wanted to focus on for Ocata was json schema 
validation of query parameters, which is something we need to restrict 
server sort/filter parameters. Today you can sort on anything including 
joined tables to the instances table. We need to restrict this in 
general as it's a security issue, but also because of it's impact on 
cells v2 and how we're going to be handling querying instances across 
multiple cells. Alex Xu is working on the spec for the json schema 
validation and Kevin Zheng is working on the fixes.


Priorities
--

Not really discussed in the session, but this is the rough list if 
you're keeping track at home:


- query parameter validation
- restricting server sort/filter parameters
- agree on and get the API WG capabilities spec approved

--

Thanks,

Matt Riedemann


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

[openstack-dev] [nova] Reminder to get started on code for approved blueprints

[Matt Riedemann]

This is just a general observation and reminder. Spec freeze is November 
17th. We already have a lot of blueprints approved for Ocata:


https://blueprints.launchpad.net/nova/ocata

And several of those don't have code posted yet. Some of them are small 
enough that they can probably be done in a single patch, but I'll warn 
everyone now that review bandwidth is going to be very tight for Ocata 
so the earlier you get some code started the better.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova] Nova-MultiJob CI (non-voting) request to comment

[Matt Riedemann]

On 11/4/2016 2:04 AM, Lenny Verkhovsky wrote:

It uses 2 physical servers with 2 compute nodes
And runs migration tests only.
Other Mellanox CI jobs run on a single allinone server, thus migration tests 
are skipped.



I think this was mentioned at the summit. In general we have a major gap 
in multinode testing for NFV features like PCI so this would be a 
welcome addition. As noted elsewhere there are other ares of nova to 
expand the coverage for this, like I'd recommend any changes to 
nova/compute/* and nova/network/* to be tested under this. But starting 
small makes sense.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [tripleo] proposing Michele Baldessari part of core team

[Carlos Camacho Gonzalez]

+1 Awesome!!!

On Fri, Nov 4, 2016 at 7:49 PM, Brent Eagles  wrote:
>
>
> On Fri, Nov 4, 2016 at 3:10 PM, Emilien Macchi  wrote:
>>
>> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
>> levels of contributions in TripleO projects, specifically in High
>> Availability area where's he's for us a guru (I still don't understand
>> how pacemaker works, but hopefully he does).
>>
>> He has done incredible work on composable services and also on
>> improving our HA configuration by following reference architectures.
>> Always here during meetings, and on #tripleo to give support to our
>> team, he's a great team player and we are lucky to have him onboard.
>> I believe he would be a great core reviewer on HA-related work and we
>> expect his review stats to continue improving as his scope broadens
>> over time.
>>
>> As usual, feedback is welcome and please vote for this proposal!
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>
> +1 indeed
>
>
> __
> OpenStack Development Mailing 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] proposing Michele Baldessari part of core team

[Brent Eagles]

On Fri, Nov 4, 2016 at 3:10 PM, Emilien Macchi  wrote:

> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
>
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
>
> As usual, feedback is welcome and please vote for this proposal!
>
> Thanks,
> --
> Emilien Macchi
>
>
​+1 ​indeed
__
OpenStack Development Mailing List (not for 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] proposing Michele Baldessari part of core team

[Harry Rybacki]

+1!

On Fri, Nov 4, 2016 at 2:34 PM, Juan Antonio Osorio  wrote:
> +1 :D
>
>
> On 4 Nov 2016 20:16, "Jiří Stránský"  wrote:
>>
>> +1, Michele does great reviews, and his contributions around HA and
>> upgrades have been crucial.
>>
>> On 4.11.2016 18:40, Emilien Macchi wrote:
>>>
>>> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
>>> levels of contributions in TripleO projects, specifically in High
>>> Availability area where's he's for us a guru (I still don't understand
>>> how pacemaker works, but hopefully he does).
>>>
>>> He has done incredible work on composable services and also on
>>> improving our HA configuration by following reference architectures.
>>> Always here during meetings, and on #tripleo to give support to our
>>> team, he's a great team player and we are lucky to have him onboard.
>>> I believe he would be a great core reviewer on HA-related work and we
>>> expect his review stats to continue improving as his scope broadens
>>> over time.
>>>
>>> As usual, feedback is welcome and please vote for this proposal!
>>>
>>> Thanks,
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for 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] proposing Michele Baldessari part of core team

[Pradeep Kilambi]

On Fri, Nov 4, 2016 at 1:40 PM, Emilien Macchi  wrote:

> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
>
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
>
> As usual, feedback is welcome and please vote for this proposal!
>


+1 of course :)


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

Re: [openstack-dev] [tripleo] proposing Michele Baldessari part of core team

[Juan Antonio Osorio]

+1 :D

On 4 Nov 2016 20:16, "Jiří Stránský"  wrote:

> +1, Michele does great reviews, and his contributions around HA and
> upgrades have been crucial.
>
> On 4.11.2016 18:40, Emilien Macchi wrote:
>
>> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
>> levels of contributions in TripleO projects, specifically in High
>> Availability area where's he's for us a guru (I still don't understand
>> how pacemaker works, but hopefully he does).
>>
>> He has done incredible work on composable services and also on
>> improving our HA configuration by following reference architectures.
>> Always here during meetings, and on #tripleo to give support to our
>> team, he's a great team player and we are lucky to have him onboard.
>> I believe he would be a great core reviewer on HA-related work and we
>> expect his review stats to continue improving as his scope broadens
>> over time.
>>
>> As usual, feedback is welcome and please vote for this proposal!
>>
>> Thanks,
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Restart Congress server

[Eric K]

Hi Ruben,

Awesome to hear about your progress!

The error seems to be independent of adding a new driver.

Could you try using the unchanged congress.conf and restarting again to
see if the same problem shows up?

Also, could you give the command you¹re using the launch congress-server?

Mainly I want to understand whether you¹re using single-process congress
deployment or multi-process congress deployment. If multi-process, it¹s
possible that the datasources process was stopped but wasn¹t restarted.


If your screen listing (access by pressing Ctrl-A followed by ") shows
three congress windows like this, then you¹re running in multi-process
mode:
29 congress-api
$(L)
  30 congress-engine
  $(L)
  31 congress-datasources
  $(L)

To launch Congress, make sure all three are running properly.

A simpler alternative (but takes some time) is to deploy devstack from
scratch (saving your work somewhere of course) using the latest versions
(defaults to single process), which should reduce complications from
multiple processes and make everything easier for dev-testing.

All the best!



On 11/4/16, 4:53 AM, "Ruben"  wrote:

>Hi everyone,
>I've tried to write a datasource driver for Magnum and the unit test for
>it.
>So I've add this datasource driver in
>/opt/stack/congress/congress/datasources/ and the unit test in
>/opt/stack/congress/congress/tests/datasources/ to test it.
>Moreover, I've add the driver to /etc/congress/congress.conf, but when I
>try to restart Congress server I've some errors.
>
>
>"2016-11-04 12:13:00.390 TRACE congress.service self.service_id,
>service, table)
>2016-11-04 12:13:00.390 TRACE congress.service   File
>"/opt/stack/congress/congress/dse2/dse_node.py", line 468, in
>subscribe_table
>2016-11-04 12:13:00.390 TRACE congress.service {'table': table})
>2016-11-04 12:13:00.390 TRACE congress.service   File
>"/opt/stack/congress/congress/dse2/dse_node.py", line 355, in
>invoke_service_rpc
>2016-11-04 12:13:00.390 TRACE congress.service raise
>exception.NotFound(msg % service_id)
>2016-11-04 12:13:00.390 TRACE congress.service NotFound: service 'nova'
>could not be found
>2016-11-04 12:13:00.390 TRACE congress.service
>2016-11-04 12:13:00.537 DEBUG oslo_concurrency.lockutils [-] Acquired
>semaphore "singleton_lock" from (pid=24411) lock
>/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:212
>2016-11-04 12:13:00.538 DEBUG oslo_concurrency.lockutils [-] Releasing
>semaphore "singleton_lock" from (pid=24411) lock
>/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225"
>
>I don't know what to do to solve it and even if the driver I've written
>works.
>Maybe I make mistakes when I restart Congress server..
>What should I do to restart Congress server?
>What could I do to test the datasource and solve these problems?
>
>Ruben



__
OpenStack Development Mailing 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] Proposing Maxime Cottret as core for cloudkitty

[Christophe Sauthier]

Hello developer mailing list folks,

I'd like to propose that we add Maxime Cottret (aolwas) as an OpenStack 
cloudkitty

core reviewer.

He has been a member of our community for a few months. Working mainly 
on the stabilisation/bug fixing of our project he really showed some 
great communication capacity.


Those are all the reasons why I think Maxime Cottret would make a great 
addition to the core review team.


Current Cloudkitty cores, please respond with +1 or explain your 
opinion if voting against... If there are no objection in the next 5 
days I'll add him.


All the best,

Christophe

http://stackalytics.com/report/contribution/cloudkitty/60
http://stackalytics.com/report/contribution/cloudkitty-dashboard/60


Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

http://olib.re/pause-openstack

__
OpenStack Development Mailing 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] Proposing Zhang Guoqing as core for cloudkitty

[Christophe Sauthier]

Hello developer mailing list folks,

I'd like to propose that we add Zhang Guoqing (zhangguoqing) as an 
OpenStack cloudkitty

core reviewer.

He has been a member of our community for many months, contributing 
very seriously in cloudkitty and cloudkitty-dashboard. He also provided 
many reviews on both projects part as you can se in his activity logs


http://stackalytics.com/report/contribution/cloudkitty/60
http://stackalytics.com/report/contribution/cloudkitty-dashboard/60

During that time he learned from the mistakes he did and improved both 
his communication and participation.


Overall I think Zhang Guoqing would make a great addition to the core 
review team.


Current Cloudkitty cores, please respond with +1 or explain your 
opinion if voting against... If there are no objection in the next 5 
days I'll add him.


All the best,

Christophe


Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

http://olib.re/pause-openstack

__
OpenStack Development Mailing List (not for 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] proposing Michele Baldessari part of core team

[Jiří Stránský]

+1, Michele does great reviews, and his contributions around HA and 
upgrades have been crucial.


On 4.11.2016 18:40, Emilien Macchi wrote:

MIchele Baldessari (bandini on IRC) has consistently demonstrated high
levels of contributions in TripleO projects, specifically in High
Availability area where's he's for us a guru (I still don't understand
how pacemaker works, but hopefully he does).

He has done incredible work on composable services and also on
improving our HA configuration by following reference architectures.
Always here during meetings, and on #tripleo to give support to our
team, he's a great team player and we are lucky to have him onboard.
I believe he would be a great core reviewer on HA-related work and we
expect his review stats to continue improving as his scope broadens
over time.

As usual, feedback is welcome and please vote for this proposal!

Thanks,




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

Re: [openstack-dev] [tripleo] proposing Michele Baldessari part of core team

[Marios Andreou]

On 04/11/16 19:40, Emilien Macchi wrote:
> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
> 
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
> 
> As usual, feedback is welcome and please vote for this proposal!
> 
> Thanks,
> 


+1 very well deserved bandini


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

Re: [openstack-dev] [packstack] Proposal to add Alfredo Moralejo as core reviewer

[Javier Pena]

So after a week we have three +2, one +1, and noone against.

Alfredo, welcome to the core team!

Javier

- Original Message -
> Hi all,
> 
> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core
> reviewer for Packstack.
> 
> Alfredo has been providing consistent and quality reviews during the Newton
> cycle, and also a good number of patches [1].
> 
> Existing core reviewers, please vote now.
> 
> Regards,
> Javier
> 
> [1]
> https://review.openstack.org/#/q/status:merged+owner:%22Alfredo+Moralejo+%253Camoralej%2540redhat.com%253E%22+project:openstack/packstack
> 
> __
> OpenStack Development Mailing 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] [networking-sfc][devstack][mitaka] Chain doesn't work

[Cathy Zhang]

Hi Alioune,

SFC is working fine. Your problem is with configuration of your specific 
Service Function.
AFAIK, Farhad has responded to your question before.
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg95199.html

Thanks,
Cathy

From: Alioune [mailto:baliou...@gmail.com]
Sent: Wednesday, November 02, 2016 5:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Mohan Kumar
Subject: Re: [networking-sfc][devstack][mitaka] Chain doesn't work

Any suggestion ?

On Monday, 24 October 2016, Alioune 
> wrote:
Hi all,
I'm trying to implement service chain in OpenStack using networking-sfc 
(stable/mitaka) and OVS 2.5.90

The following is the architecture I used :

SRC DST
  ||
  == br-int 
 |
   SF1
SF1: 55.55.55.3
SRC: 55.55.55.4
DST: 55.55.55.5

I can create port-pairs, port-pair-group, classifier and chain with these 
commands:

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix 
55.55.55.4/32  --logical-source-port 
0009034f-4c39-4cbf-be7d-fcf82dad024c  --protocol icmp  FC1
neutron port-pair-create --ingress=p1 --egress=p1 PP1
neutron port-pair-group-create --port-pair PP1 PG1
neutron port-chain-create --port-pair-group PG1 --flow-classifier FC1 PC1
I could ping from SRC to DST before setting the chain, but after the chain 
creating ping doesn't work.
ICMP echo request packets arrive to SF1 port but it doesn't send back the 
packets in order to allow them to get their destination DST (see output below).
The Opendaylight/SFC project uses NSH aware service function (SF) that send 
back packets to the chains after analyzing them, I would like to know :
- How networking-sfc configures SF to send back packets to the chain as seem in 
some of your presentation ?
- What's wrong in my configurations (see commands and ovs-ofctl output below) ? 
I've followed the main steps described in your wiki page.
Best Regards,


vagrant@vagrant-ubuntu-trusty-64:~$ neutron port-list
+--+--+---+--+
| id   | name | mac_address   | fixed_ips   
 |
+--+--+---+--+
| 0009034f-4c39-4cbf-be7d-fcf82dad024c |  | fa:16:3e:dd:16:f7 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.4"}|
| 082e896d-5982-458c-96e7-0dd372d3d7d9 | p1   | fa:16:3e:90:b4:67 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.3"}|
| 2ad109e4-42a8-4554-b884-a32344e91036 |  | fa:16:3e:74:9a:fa | 
{"subnet_id": "3cf6eb27-7258-4252-8f3d-b6f9d27c948b", "ip_address": 
"192.168.105.2"} |
| 51f055c0-ff4d-47f4-9328-9a0d7ca204f3 |  | fa:16:3e:da:f9:93 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.1"}|
| 656ad901-2bc0-407a-a581-da955ecf3b59 |  | fa:16:3e:7f:44:01 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.2"}|
| b1d14a4f-cde6-4c44-b42e-0f0466dba32a |  | fa:16:3e:a6:c6:35 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.5"}|
+--+--+---+--+

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig |grep 082e896d
qbr082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvb082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvo082e896d-59 Link encap:Ethernet  HWaddr 7e:1a:7b:7d:09:df
tap082e896d-59 Link encap:Ethernet  HWaddr fe:16:3e:90:b4:67

vagrant@vagrant-ubuntu-trusty-64:~$ sudo tcpdump -i tap082e896d-59 icmp
tcpdump: WARNING: tap082e896d-59: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap082e896d-59, link-type EN10MB (Ethernet), capture size 65535 
bytes
10:51:10.229674 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 61, length 64
10:51:11.230318 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 62, length 64
10:51:12.233451 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 63, length 64
10:51:13.234496 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 64, length 64
10:51:14.235583 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 65, length 64
10:51:15.236585 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 

Re: [openstack-dev] [manila] Barcelona Design Summit summary

[Joshua Harlow]

Ben Swartzlander wrote:

Thanks to gouthamr for doing these writeups and for recording!

We had a great turn out at the manila Fishbowl and working sessions.
Important notes and Action Items are below:

===
Fishbowl 1: Race Conditions
===
Thursday 27th Oct / 11:00 - 11:40 / AC Hotel -Salon Barcelona - P1
Etherpad: https://etherpad.openstack.org/p/ocata-manila-race-conditions
Video: https://www.youtube.com/watch?v=__P7zQobAQw

Gist:
* We've some race conditions that have worsened over time:
* Deleting a share while snapshotting the share
* Two simultaneous delete-share calls
* Two simultaneous create-snapshot calls
* Though the end result of the race conditions is not terrible, we can
leave resources in untenable states, requiring administrative cleanup in
the worst scenario
* Any type of resource interaction must be protected in the database
with a test-and-set using the appropriate status fields
* Any test-and-set must be protected with a lock
* Locks must not be held over long running tasks: i.e, RPC Casts, driver
invocations etc.
* We need more granular state transitions: micro/transitional states
must be added per resource and judiciously used for state locking
* Ex: Shares need a 'snapshotting' state
* Ex: Share servers need states to signify setup phases, a la nova
compute instances


Just something that I've always wondered, and I know its not a easy 
answer, but are there any ideas on why such simultaneous issues keep on 
getting discovered so late in the software lifecycle, instead of at 
design time? Not probably just a manilla question, but it strikes me as 
somewhat confusing that keeps on popping up.



Discussion Item:
* Locks in the manila-api service (or specifically, extending usage of
locks across all manila services)
* Desirable because:
* Adding test-and-set logic at the database layer may render code
unmaintainable complicated as opposed to using locking abstractions
(oslo.concurrency / tooz)
* Cinder has evolved an elegant test-and-set solution but we may not be
able to benefit from that implementation because of the lack of being
able to do multi-table updates and because the code references OVO which
manila doesn't yet support.
* Un-desirable because:
* Most distributors (RedHat/Suse/Kubernetes-based/MOS) want to run more
than one API service in active-active H/A.
* If a true distributed locking mechanism isn't used/supported, the
current file-locks would be useless in the above scenario.
* Running file locks on shared file systems is a possibility, but
applies configuration/set-up burden
* Having all the locks on the share service would allow scale out of the
API service and the share manager is really the place where things are
going wrong
* With a limited form of test-and-set, atomic state changes can still be
achieved for the API service.

Agreed:
* File locks will not help

Action Items:
(bswartz): Will propose a spec for the locking strategy
(volunteers): Act on the spec ^ and help add more transitional states
and locks (or test-and-set if any)
(gouthamr): state transition diagrams for shares/share
instances/replicas, access rules / instance access rules
(volunteers): Review ^ and add state transition diagrams for
snapshots/snapshot instances, share servers
(mkoderer): will help with determining race conditions within
manila-share with tests

=
Fishbowl 2: Data Service / Jobs Table
=
Thursday 27th Oct / 11:50 - 12:30 / AC Hotel - Salon Barcelona - P1
Etherpad:
https://etherpad.openstack.org/p/ocata-manila-data-service-jobs-table
Video: https://www.youtube.com/watch?v=Sajy2Qjqbmk


Will https://review.openstack.org/#/c/260246/ help here instead?

It's the equivalent of:

http://docs.openstack.org/developer/taskflow/jobs.html

Something to think about...



Gist:
* Currently, a synchronous RPC call is made from the API to the
share-manager/data-service that's performing a migration to get the
progress of a migration
* We need a way to record progress of long running tasks: migration,
backup, data copy etc.
* We need to introduce a jobs table so that the respective service
performing the long running task can write to the database and the API
relies on the database

Discussion Items:
* There was a suggestion to extend the jobs table to all tasks on the
share: snapshotting, creating share from snapshot, extending, shrinking,
etc.
* We agreed not to do this because the table can easily go out of
control; and there isn't a solid use case to register all jobs. Maybe
asynchronous user messages is a better answer to this feature request
* "restartable" jobs would benefit from the jobs table
* service heartbeats could be used to react to services dying while
running long running jobs
* When running the data service in active-active mode, a service going
down can pass on its jobs to the other data service

Action Items:
(ganso): Will determine the structure of the 

Re: [openstack-dev] Nova-MultiJob CI (non-voting) request to comment

[Chris Friesen]

On 11/03/2016 02:45 AM, Lenny Verkhovsky wrote:

Hi,

We would like Mellanox[1] MultiNode CI job  to start commenting as ‘non voting’
job on partial nova[2] and tempest[3] code.

This Job runs few migration tests[4] and an example of its run can be seen 
here[5].

[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI

[2] nova/pci


If the CI system has the bandwidth, it might make sense for it to also run for 
nova/objects/pci*, nova/scheduler/filters/numa_topology_filter.py, and 
nova/scheduler/filters/pci_passthrough_filter.py


Chris

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Swapnil Kulkarni]

On Fri, Nov 4, 2016 at 10:01 PM, Jeremy Stanley  wrote:
> On 2016-11-04 15:42:17 + (+), Paul Bourke wrote:
>> We have no desire to do this, that's not what is being discussed
>> here. On the contrary we're looking to reduce the barrier to entry
>> for committers. Also the team is aware that cross project efforts
>> should not be nit picked.
>
> That's what it seemed like to me up to this point in the thread as
> well; I was specifically replying to Swapnil's suggestion that any
> important change to Kolla deliverables should have a bug filed or
> should continue to add a TrivialFix header in the commit message
> otherwise. (And yes, as Andreas pointed out the other thread on the
> related topic of mass changes for cross-project efforts does address
> the case specifically, but becomes less necessary if you end up
> agreeing to drop the TrivialFix requirement.)
> --
> 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


Jeremy,

I am sorry if I have miscommunicated earlier. I am referring to the
situation where people are using TrivialFix just to get the changes in
which is not good practice.

I agree with removing TrivialFix just that we need to be very careful
with changes that need tracking (e.g. bug/bp).

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Swapnil Kulkarni]

On Fri, Nov 4, 2016 at 9:12 PM, Paul Bourke  wrote:
> Hi Jeremy,
>
>> All I ask is that if the Kolla team wants to differentiate itself
>> from the review requirements of most OpenStack projects, please make
>
> We have no desire to do this, that's not what is being discussed here. On
> the contrary we're looking to reduce the barrier to entry for committers.
> Also the team is aware that cross project efforts should not be nit picked.
>
> -Paul
>
> On 04/11/16 15:25, Jeremy Stanley wrote:
>>
>> On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:
>>>
>>> I feel TrivialFix is consistently used by people just to avoid going
>>> to lanuchpad and filing a bug. It should only be used only if the "Fix
>>> is Trivial"
>>> This has been well documented in the contributing doc [1] and this
>>> should be referred to people when they do not have the bug/bp in the
>>> commit message.
>>>
>>> If the commits are important then there is no harm in creating a
>>> tracking bug for it.
>>
>> [...]
>>
>> All I ask is that if the Kolla team wants to differentiate itself
>> from the review requirements of most OpenStack projects, please make
>> sure you have active and attentive liaisons who can update
>> mass-proposed changes for base infrastructure or other similar
>> horizonal and cross-project efforts to meet your special reviewing
>> standards. I cannot personally keep on top of the nuances of every
>> review team and individually adjust such mass changes myself, so
>> rely on you to "fix" my patches for me in such situations.
>>
>>
>>
>> __
>> OpenStack Development Mailing 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


Nit picking was needed since the policy was followed more to avoid
creating or using a tracker more often.

__
OpenStack Development Mailing 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] proposing Michele Baldessari part of core team

[Emilien Macchi]

MIchele Baldessari (bandini on IRC) has consistently demonstrated high
levels of contributions in TripleO projects, specifically in High
Availability area where's he's for us a guru (I still don't understand
how pacemaker works, but hopefully he does).

He has done incredible work on composable services and also on
improving our HA configuration by following reference architectures.
Always here during meetings, and on #tripleo to give support to our
team, he's a great team player and we are lucky to have him onboard.
I believe he would be a great core reviewer on HA-related work and we
expect his review stats to continue improving as his scope broadens
over time.

As usual, feedback is welcome and please vote for this proposal!

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] [tc][kolla] Ansible module with GPLv3

[Michał Jastrzębski]

Yeah, I'll cross-post there, thanks Fungi.

Anyone knows of any other openstack project with more than 1 license
in their codebase?

On 4 November 2016 at 11:51, Jeremy Stanley  wrote:
> On 2016-11-04 11:42:25 -0500 (-0500), Michał Jastrzębski wrote:
> [...]
>> Kolla is licensed as Apache v2 all across the board today. To
>> implement one of highly requested features we would need to develop
>> so-called strategy plugin for ansible, and I can't see any reasonable
>> way to do it without touching GPL v3 code.
> [...]
>
> [I am not a lawyer.] We just discussed this in #openstack-infra as
> well. Since Kolla is shelling out to an Ansible executable, it's not
> likely to count as being a derivative work of Ansible. Consequently,
> the Kolla plug-in imported by Ansible being GPLv3 while shipped in
> the same repo as Apache License 2.0 Kolla source code would simply
> be aggregation of software under distinct licenses.
>
> That said, it can't hurt to ask this again on
> legal-disc...@lists.openstack.org where it's much more on-topic.
> --
> 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 Development Mailing 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] SIG-OpenStack @ Kubernetes

[Davanum Srinivas]

Folks,

fyi, there's a bunch of Stackers working on Kubernetes.
http://blog.kubernetes.io/2016/04/introducing-kubernetes-openstack-sig.html

In Kubernetes, work is organized around Special Interest Groups:
https://github.com/kubernetes/community/blob/master/README.md#special-interest-groups-sig

So the OpenStack related one is:
https://github.com/kubernetes/community/blob/master/sig-openstack/README.md

The reason for this email is that there is a lot of work to be done in
Kubernetes' OpenStack Provider and we were wondering if anyone wants
to help?

Issues : 
https://github.com/kubernetes/kubernetes/labels/area%2Fplatform%2Fopenstack
Pull Requests :
https://github.com/kubernetes/kubernetes/pulls?utf8=%E2%9C%93=is%3Aopen%20is%3Apr%20openstack

Hopefully work on these issues/PR's will make OpenStack the best
platform to run Kubernetes on and will help strengthen the cross
connections between the two foundations.

Thanks,
Dims

PS: Don't get me wrong there's enough work in
Kuryr/Magnum/Zun/Kolla-Kubernetes/fuel-ccp etc :) This is just in case
someone has some cycles!

-- 
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] [tc][kolla] Ansible module with GPLv3

[Jeremy Stanley]

On 2016-11-04 11:42:25 -0500 (-0500), Michał Jastrzębski wrote:
[...]
> Kolla is licensed as Apache v2 all across the board today. To
> implement one of highly requested features we would need to develop
> so-called strategy plugin for ansible, and I can't see any reasonable
> way to do it without touching GPL v3 code.
[...]

[I am not a lawyer.] We just discussed this in #openstack-infra as
well. Since Kolla is shelling out to an Ansible executable, it's not
likely to count as being a derivative work of Ansible. Consequently,
the Kolla plug-in imported by Ansible being GPLv3 while shipped in
the same repo as Apache License 2.0 Kolla source code would simply
be aggregation of software under distinct licenses.

That said, it can't hurt to ask this again on
legal-disc...@lists.openstack.org where it's much more on-topic.
-- 
Jeremy Stanley


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

[openstack-dev] [tc][kolla] Ansible module with GPLv3

[Michał Jastrzębski]

Hello,

As you could see in [1], ansible is notorious with it's GPL v3
license. I have question about having single module in Kolla-ansible
project that will be GPL v3.

Kolla is licensed as Apache v2 all across the board today. To
implement one of highly requested features we would need to develop
so-called strategy plugin for ansible, and I can't see any reasonable
way to do it without touching GPL v3 code.

While I wouldn't mind having single GPL v3 licensed module in Kolla,
and this particular use case doesn't seem to affect licensing of other
parts of our project, I would like to ask for second opinion before we
run into legal issues.


[1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095489.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] [release] git-upstream 0.12.1 release

[Darragh Bailey - mailing lists]

Pleased to announce the 0.12.1 release of git-upstream.

Main reason to ensure the man page is installed by default.

With source available at:

http://git.openstack.org/cgit/openstack/git-upstream Please report any
issues through launchpad: https://bugs.launchpad.net/git-upstream
git-upstream is an open source Python application that can be used to
keep in sync with upstream open source projects, mainly OpenStack. For
more info on what git-upstream is for:
https://pypi.python.org/pypi/git-upstream Full changelog available from:
https://git.openstack.org/cgit/openstack/git-upstream/tree/ChangeLog For
more details see below.

Changes in git-upstream 0.12.0..0.12.1
--
bbf2511 Update ChangeLog for 0.12.1
98b283e Include files for sphinx based documentation
b95b257 Auto build and install default man page
ac76015 Move build_manpage utility to doc area
bc9fc64 Ensure correct prog name available to manpage
d2c0306 Update authors
2455b7e Remove requirement sphinxcontrib-programoutput


Diffstat (except docs and test files)
-
 AUTHORS|   5 +
 ChangeLog  |  12 +++
 build_manpage.py   | 136 -
 doc/source/conf.py | 246 +
 doc/source/index.rst   |  21 
 doc/utils/build_manpage.py | 151 
 docs-requirements.txt  |   2 +
 git_upstream/main.py   |   3 +-
 setup.cfg  |  10 ++
 setup.py   |   5 +
 test-requirements.txt  |   1 -
 tox.ini|   4 +-
 12 files changed, 457 insertions(+), 139 deletions(-)

Requirements updates

diff --git a/test-requirements.txt b/test-requirements.txt
index 63c4a34..3f35ec1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9,5 +9,4 @@ python-subunit
 testrepository>=0.0.17
 testscenarios>=0.4
 testtools>=0.9.32
-sphinxcontrib-programoutput
 PyYAML>=3.1.0


-- 
Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown (possibly 
Douglas Adams)



0xCDD2EB9C.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Jeremy Stanley]

On 2016-11-04 15:42:17 + (+), Paul Bourke wrote:
> We have no desire to do this, that's not what is being discussed
> here. On the contrary we're looking to reduce the barrier to entry
> for committers. Also the team is aware that cross project efforts
> should not be nit picked.

That's what it seemed like to me up to this point in the thread as
well; I was specifically replying to Swapnil's suggestion that any
important change to Kolla deliverables should have a bug filed or
should continue to add a TrivialFix header in the commit message
otherwise. (And yes, as Andreas pointed out the other thread on the
related topic of mass changes for cross-project efforts does address
the case specifically, but becomes less necessary if you end up
agreeing to drop the TrivialFix requirement.)
-- 
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] [freezer] Proposing Timothy Buckley to Freezer-core

[Mathieu, Pierre-Arthur]

Hi everyone, 


I would like to propose that we promote Tim Buckley (timothyb89) core.
He has been a highly valuable developper for the past few month.

His work can be found here: [1]
And his stackalitics profile here: [2]


If you agree with this change, please approve with a +1 answer or explain your 
opinion if voting against.
If there are no objection, I plan on doing this tomorrow evening.

Thanks
- Pierre, Freezer PTL

[1] 
https://review.openstack.org/#/q/owner:%22Tim+Buckley+%253Ctimothy.jas.buckley%2540hpe.com%253E%22
[2] 
http://stackalytics.com/?module=freezer-group=all_id=timothy-jas-buckley
__
OpenStack Development Mailing List (not for 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][routed-network] Host doesn't connected any segments when creating port

[Miguel Lavalle]

Hi Zhi,

Both L2 provider networks and routed networks can have one or many
segments. In the case of a L2 provider network, all the segments in it
constitute a contiguous L2 domain. In contrast, in routed networks, each
segment in it is a separate L2 domain. One consequence of this is that in
L2 provider networks the subnets are associated to the network, whereas in
routed networks, the subnets are associated to the segments. In both cases,
though, you can have as many subnets as you want or need.

As for the gateway question, you are correct: you are going to need routers
/ gateways in your infrastructure.

Regards

Miguel

On Wed, Nov 2, 2016 at 9:38 PM, zhi  wrote:

> Hi, Miguel.
>
> Thanks for your reply.
>
> This is my thought about routed network. Please review it and give me some
> comments, thanks.
>
> In general L2 provider network, maybe one network to one subnet. If in
> real deployment, we has to create many provider networks because one
> network to one subnets. But in routed network, one network can contain more
> than one subnet. So in real deployment, we can create only one network,
> this network we created can contain many many subnets. Does my thought was
> right?
>
> According to your reply,  I think that if we create a routed network with
> two subnets, one is 10.1.0.0/24 and the other is 10.1.1.0/24. Except your
> solution, in real deployment, we need to create two gateway (10.1.0.1 and
> 10.1.1.1)  in physical network, isn't it?
>
> Hope for your reply. :)
>
>
> Thanks
> Zhi Chang
>
> 2016-11-02 22:49 GMT+08:00 Miguel Lavalle :
>
>> Hi Zhi,
>>
>> In routed networks, the routing among the segments has to be provided by
>> a router external to Neutron. It has to be provided by the deployment's
>> networking infrastructure. In the summit presentation you watched, I used
>> this Vagrant environment for the demo portion:
>> https://github.com/miguellavalle/routednetworksvagrant. Specifically,
>> look here: https://github.com/miguellavalle/routednetworksvagrant/blob/
>> master/Vagrantfile#L188. As you can see, I create a VM, "iprouter", to
>> act as the router between the two segments I use in the demo: one segment
>> on vlan tag 2016 in physnet1 and another segment on vlan tag 2016 in
>> physnet2. Please also look here how I enable the routing in the "iprouter"
>> Linux: https://github.com/miguellavalle/routednetworksvagrant/blob/
>> master/provisioning/setup-iprouter.sh.
>>
>> Of course, in a real deployment you would use a hardware router connected
>> to all the network's segments
>>
>> Hope this helps
>>
>> Miguel
>>
>> On Tue, Nov 1, 2016 at 4:42 AM, zhi  wrote:
>>
>>> Hi, shihanzhang and Neil, Thanks for your comments.
>>>
>>> In your comments. I think that Neutron router or physical network should
>>> provide routing these two subnets, doesn't it? Does my thought was right?
>>>
>>> I tried to connect these two subnets with a Neutron router but I met a
>>> strange problem. I did some operations like this:
>>>
>>> stack@devstack:~$ neutron net-list
>>> +-+-
>>> --+-
>>> ---+
>>> | id  |
>>> name | subnets
>>>  |
>>> +-+-
>>> --+-
>>> ---+
>>> | 6596da30-d7c6-4c39-b87c-295daad44123 | multinet |
>>> a998ac2b-2f50-44f1-9c1a-f4f3684ef63c 10.1.1.0/24|
>>> |
>>> |  | 26bcdfd3-6393-425e-963e-1ace6ef74e0c 10.1.0.0/24 |
>>> | 662de35c-f7a7-47cd-ba18-e5a2470935f0| net   |
>>> 9754dfe9-be48-4a38-b690-5c48cf371ba3 10.10.10.0/24  |
>>> +--+
>>> --+-
>>> ---+
>>> stack@devstack:~$ neutron router-port-list
>>> c488238d-06d7-4b85-9fa1-e0913e5bcf13
>>>
>>> stack@devstack:~$ neutron router-interface-add
>>> c488238d-06d7-4b85-9fa1-e0913e5bcf13 a998ac2b-2f50-44f1-9c1a-f4f368
>>> 4ef63c
>>> Added interface 680eb2b6-b445-4790-9610-80154dd6d909 to router
>>> c488238d-06d7-4b85-9fa1-e0913e5bcf13.
>>> stack@devstack:~$ neutron router-port-list
>>> c488238d-06d7-4b85-9fa1-e0913e5bcf13
>>> +--+
>>> +---+---
>>> +
>>> | id   |
>>> name | mac_address   | fixed_ips
>>>   |
>>> +--+
>>> ++--
>>> 

Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)

[Andy Smith]

On Fri, 2016-11-04 at 10:45 -0400, Ken Giusti wrote:
> On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow 
> wrote:
> > 
> > Hi folks,
> > 
> > There was a bunch of chatter at the summit about how there are
> > really two
> > different types of (oslo) messaging usage that exist in openstack
> > and how
> > they need not be backed by the same solution type (rabbitmq, qpid,
> > kafka...).
> > 
> > For those that were not at the oslo sessions:
> > 
> > https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo
> > 
> > The general gist was though that we need to make sure people really
> > do know
> > that there are two very different types of messaging usage in
> > openstack and
> > to ensure that operators (and developers) are picking the right
> > backing
> > technology for each type.
> > 
> > So some questions naturally arise out of this.
> > 
> > * Where are the best practices with regard to selection of the best
> > backend
> > type for rpc (and one for notifications); is this something
> > oslo.messaging
> > should work through (or can the docs team and operator group also
> > help in
> > making this)?
> > 
> > * What are the tradeoffs in using the same (or different)
> > technology for rpc
> > and notifications?
> > 
> I think the olso.messaging team should take the lead here and educate
> users as to what the options are, and  how the two supported
> messaging
> services (RPC and Notifications) differ with respect to backend
> requirements.   These topics really should be part of the
> oslo.messaging 'Theory of Operations' documentation that was
> discussed
> during the Arch WG summit meeting.
> 
> Currently the biggest functional difference between the backends is
> the support of store-and-forward (e.g. queueing) verses point-to-
> point
> message transfer.  Oslo could at least explain the pros and cons of
> each approach with respect to the RPC and Notification services so
> that folks understand what the tradeoffs and advantages are in the
> first place.
> 
> Furthermore the team should also document the functional differences
> between the various choices of backends.  For instance it would be
> useful to understand how the two supported point-to-point backends
> (zmq and dispatch router) differ in both behavior and recommended
> deployment.
> 
> 
> > 
> > * Is it even possible for all oslo.messaging consuming projects to
> > be able
> > to choose 2 different backends, are consuming projects consuming
> > the library
> > correctly so that they can use 2 different backends?
> > 
> > * Is devstack able to run with say kafka for notifications and
> > rabbitmq for
> > rpc (if not, is there any work item the oslo group can help with to
> > make
> > this possible) so that we can ensure and test that all projects can
> > work
> > correctly with appropriate (and possibly different) backends?
> > 

If the backend is considered a black box, the goal should be that from
the application's perspective, there is no functional difference
between the use of one backend over another. Rather, the differences
will be non-functional in nature (e.g. quality of service, scalability,
resilience, maintainability, ec.). This is what oslo.messaging will
need to help explain to users so that they will understand the
operational differences between deploying one backend versus another
(e.g. will they be managing a cluster of brokers or a mesh of routers).

The near term challenge will be to make it easy to configure the use of
alternative backends. The introduction of the transport_url
configuration option should help but most of the existing configuration
management frameworks continue to use the legacy (soon to be
deprecated) rpc_backend, host, port and auth configuration options. For
the most part, the configurations have "hard coded" the use of rabbit.

As an example of what will be required, an effort to update the
openstack puppet modules to introduce the transport_url configuration
options took place during Newton. This uses the the puppet-oslo
module that encapsulates the oslo.messaging configuration.

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

With this change across the core services, a packstack scenario was
prototyped that setup AMQP 1.0 backend for RPC and rabbit for
notifications. The resulting deployment was able to successfully pass
the  tempest smoke tests, etc.

A key enabler for the use of dual backends in practice will be to work
across the spectrum of installation/configuration management frameworks
to adopt the transport_url(s) options. This is a fair bit of scope but
once done, the oslo.messaging backend plug-in model can be fully
leveraged.

> > * Any other messaging, arch-wg work that we (oslo or others) can
> > help out
> > with to make sure that projects (and operators) are using the right
> > technology for the right use (and not just defaulting to RPC over
> > rabbitmq
> > because it exists, when in reality something else might be a better
> > choice)?
> > 
> 

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Paul Bourke]

Hi Jeremy,

> All I ask is that if the Kolla team wants to differentiate itself
> from the review requirements of most OpenStack projects, please make

We have no desire to do this, that's not what is being discussed here. 
On the contrary we're looking to reduce the barrier to entry for 
committers. Also the team is aware that cross project efforts should not 
be nit picked.


-Paul

On 04/11/16 15:25, Jeremy Stanley wrote:

On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.

[...]

All I ask is that if the Kolla team wants to differentiate itself
from the review requirements of most OpenStack projects, please make
sure you have active and attentive liaisons who can update
mass-proposed changes for base infrastructure or other similar
horizonal and cross-project efforts to meet your special reviewing
standards. I cannot personally keep on top of the nuances of every
review team and individually adjust such mass changes myself, so
rely on you to "fix" my patches for me in such situations.



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



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

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2016-11-04 10:50:34 -0400:
> On Thu, Nov 3, 2016 at 3:04 PM, Joshua Harlow  wrote:
> > Jay Faulkner wrote:
> >>>
> >>> On Nov 3, 2016, at 11:27 AM, Joshua Harlow  wrote:
> >>>
> >>> Just as a followup from the summit,
> >>>
> >>> One of the sessions (the new lib one) had a few proposals:
> >>>
> >>> https://etherpad.openstack.org/p/ocata-oslo-bring-ideas
> >>>
> >>> And I wanted to try to get clear owners for each part (there was some
> >>> followup work for each); so just wanted to start this email to get the
> >>> thoughts going on what to do for next steps.
> >>>
> >>> *A hash ring library*
> >>>
> >>> So this one it feels like we need at least a tiny oslo-spec for and for
> >>> someone to write down the various implementations, what they share, what
> >>> they do not share (talking to swift, nova, ironic and others? to figure 
> >>> this
> >>> out). I think alexis was thinking he might want to work through some of 
> >>> that
> >>> but I'll leave it for him to chime in on that (or others feel free to 
> >>> also).
> >>>
> >>> This one doesn't seem very controversial and the majority of the work is
> >>> probably on doing some analysis of what exists and then picking a library
> >>> name and coding that up, testing it, and then integrating (pretty 
> >>> standard).
> >>>
> >>
> >> Ironic and Nova both share a hash ring implementation currently
> >> (ironic-conductor and nova-compute driver for ironic). It would be sensible
> >> to reuse this implementation, oslo-ify it, and have that code shared.
> >>
> >> I question the value of re-implementing something like this from scratch
> >> though.
> >>
> >> Thanks,
> >> Jay Faulkner
> >> OSIC
> >>
> >
> > Right I don't think the intention would be to implement it from scratch, but
> > to do some basic analysis of what exists (and think about and document the
> > patterns), and try to find the common parts (which likely involves renaming
> > some specific nova/ironic methods from what I see); especially if we can get
> > swift to perhaps (TBD) also use and contribute to this library.
> 
> As the person who copied that code into Nova, the Nova code is a strict subset
> of the Ironic code.
> 
> Some of us talked to John Dickinson off-list, and it seems the Swift hash ring
> has very different use cases and very different implementation. I
> think we should
> focus on pulling the Nova/Ironic code out first, and then talking to
> Swift if we can
> also make it work for them (sounds like it's not helpful today).
> 
> // jim
> 

Thanks for the background, Jim. I thought the code shared more with
Swift's implementation than it sounds like it does, so I agree with your
proposed plan.

Doug

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Andreas Jaeger]

On 11/04/2016 04:25 PM, Jeremy Stanley wrote:
> On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:
>> I feel TrivialFix is consistently used by people just to avoid going
>> to lanuchpad and filing a bug. It should only be used only if the "Fix
>> is Trivial"
>> This has been well documented in the contributing doc [1] and this
>> should be referred to people when they do not have the bug/bp in the
>> commit message.
>>
>> If the commits are important then there is no harm in creating a
>> tracking bug for it.
> [...]
> 
> All I ask is that if the Kolla team wants to differentiate itself
> from the review requirements of most OpenStack projects, please make
> sure you have active and attentive liaisons who can update
> mass-proposed changes for base infrastructure or other similar
> horizonal and cross-project efforts to meet your special reviewing
> standards. I cannot personally keep on top of the nuances of every
> review team and individually adjust such mass changes myself, so
> rely on you to "fix" my patches for me in such situations.

Jeremy, I do agree with your request.

I expect this to be settled by Steven Dake's email:
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105287.html

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


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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Jeremy Stanley]

On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:
> I feel TrivialFix is consistently used by people just to avoid going
> to lanuchpad and filing a bug. It should only be used only if the "Fix
> is Trivial"
> This has been well documented in the contributing doc [1] and this
> should be referred to people when they do not have the bug/bp in the
> commit message.
> 
> If the commits are important then there is no harm in creating a
> tracking bug for it.
[...]

All I ask is that if the Kolla team wants to differentiate itself
from the review requirements of most OpenStack projects, please make
sure you have active and attentive liaisons who can update
mass-proposed changes for base infrastructure or other similar
horizonal and cross-project efforts to meet your special reviewing
standards. I cannot personally keep on top of the nuances of every
review team and individually adjust such mass changes myself, so
rely on you to "fix" my patches for me in such situations.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [Zun] Propose a change of Zun core team

[Hongbin Lu]

Hi all,

Thanks for your votes. According to the feedback, the proposal was approved. 
Welcome Shubham to join the core team.

Best regards,
Hongbin

> -Original Message-
> From: Fei Long Wang [mailto:feil...@catalyst.net.nz]
> Sent: October-20-16 8:31 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Zun] Propose a change of Zun core team
> 
> +1
> 
> 
> On 20/10/16 16:59, Shuu Mutou wrote:
> > +1 for both.
> >
> > Regards,
> > Shu Muto
> >
> >> -Original Message-
> >> From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
> >> Sent: Thursday, October 20, 2016 12:33 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [Zun] Propose a change of Zun core team
> >>
> >> +1 for both. Shubham will be a great addition to team.
> >>
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> Madhuri
> >>
> >>
> >>
> >> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> >> Sent: Thursday, October 20, 2016 2:49 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: [openstack-dev] [Zun] Propose a change of Zun core team
> >>
> >>
> >>
> >> Hi team,
> >>
> >>
> >>
> >> I am going to propose an exchange of the core team membership as
> below:
> >>
> >>
> >>
> >> + Shubham Kumar Sharma (shubham)
> >>
> >> - Chandan Kumar (chandankumar)
> >>
> >>
> >>
> >> Shubham contributed a lot for the container image feature and active
> >> on reviews and IRC. I think he is a good addition to the core team.
> >> Chandan became inactive for a long period of time so he didn’t meet
> >> the expectation of a core reviewer anymore. However, thanks for his
> >> interest to join the core team when the team was found. He is
> >> welcomed to re-join the core team if he become active in the future.
> >>
> >>
> >>
> >> According to the OpenStack Governance process [1], we require a
> >> minimum of 4 +1 votes from Zun core reviewers within a 1 week voting
> >> window (consider this proposal as a +1 vote from me). A vote of -1
> is
> >> a veto. If we cannot get enough votes or there is a veto vote prior
> >> to the end of the voting window, this proposal is rejected and
> >> Shubham is not able to join the core team and needs to wait 30 days
> to reapply.
> >>
> >>
> >>
> >> [1]
> >> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> >> 
> >>
> >>
> >>
> >> Best regards,
> >>
> >> Hongbin
> >
> >
> __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> --
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> ---
> ---
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> ---
> ---
> 
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] rolling upgrade demo and virtual design session

[Brian Rosmaita]

As discussed at the Summit and at yesterday's Glance meeting, Alex
Bashmakov and Hemanth Makkapati will present a virtual design session
(including a demo!) of the work they're doing toward zero downtime rolling
upgrades on Friday, 11 November 2016.  Please fill in your availability on
a doodle poll Alex put together: http://doodle.com/poll/tybifi4qyk8stbgz

Please respond before 23:59 UTC on Tuesday, 8 November.

cheers,
brian




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

Re: [openstack-dev] [monasca] License for monasca-statsd

[Jeremy Stanley]

On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> I was looking at packaging monasca-statsd since it is a dependency for
> designate, however when I look at the license for it,it says Apache-2.
> However the LICENSE file included in the source  is that the software is
> provided as is...etc etc. Could we get some clarification please?

To increase visibility with the Monasca team, I've also opened this
as:

https://launchpad.net/bugs/1639265

...and for additional safety, the Release Team has decided to hold
off further releases of Monasca deliverables until the copyright
situation you've raised gets sorted out:

http://eavesdrop.openstack.org/meetings/releaseteam/2016/releaseteam.2016-11-04-14.00.html
-- 
Jeremy Stanley


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

Re: [openstack-dev] [monasca] License for monasca-statsd

[Doug Hellmann]

Excerpts from Chuck Short's message of 2016-11-03 15:03:44 -0400:
> Hi,
> 
> I was looking at packaging monasca-statsd since it is a dependency for
> designate, however when I look at the license for it,it says Apache-2.
> However the LICENSE file included in the source  is that the software is
> provided as is...etc etc. Could we get some clarification please?
> 
> Thanks
> chuck

In the release team meeting today we agreed to freeze Monasca releases
until this question is resolved, just to avoid making the situation
"worse" with more releases. Given how close we are to the summit, I
don't expect that to really cause any issues.

When it is fixed, we should go ahead and backport the change to any open
stable branches and prepare new releases from those, too.

Doug

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

Re: [openstack-dev] [openstack][ironic] Event processing for async task improvement

[Mario Villaplana]

I agree with the strategy Yuriy outlined. This has the added benefit
of mitigating potential future bugs related to callbacks in the task
manager since state "rollback" behavior will be implicitly built into
the task manager.

Details on the potential race condition with provision state change
notifications are noted in L511 here:
https://review.openstack.org/#/c/348437/20/ironic/conductor/task_manager.py

I find the risks in the notifications patch set acceptable for now,
but this would be a good general improvement afterwards, in my
opinion.

Mario

On Sat, Oct 22, 2016 at 12:57 PM, Yuriy Zveryanskyy
 wrote:
> Hi.
>
> There is state rollback mechanism in ironic if conductor work thread can not
> be started for change provision state via API. And looks like we need the
> same for
> cleaning [1].
> This mechanism can not be clearly integrated with provision state
> notifications,
> in the start -> (end or error) scheme imlemented for async task error is
> "permanent" externally visible error like provision error, cleaning error,
> there is no FSM event that triggered this rollback etc. Due to these reasons
> current implementation of provision state notifications is overcomplex and
> potentially raceable [2].
> I propose do not change provision state until work thread is started. RFC
> 7231 does not require any type of "sync start" [3].
> All needed changes look like internal refactoring, no changes visible from
> external world.
> Details:
> - remove all callback related parameters from process_event() method. This
> is not
> breaking change because these parameters should be only used for conductor
> and not for drivers;
> - add event and related parameter to spawn_after() method. This method
> should only process event on the FSM and does not apply state changes to the
> node
> object and DB;
> - add new method post_process_event() (apply_states?) to task manager.
> Create
> a decorator that calls this method using task instance from args before main
> function. Not needed to add this decorator in the code manually to each
> function,
> callback functions can be decorated inside task manager;
> - remove hooks function for provision and cleaning, logging and last error
> setting
> can be done inside task manager.
>
> Have a nice time on the Summit.
> Note that I'm on PTO until Oct 31.
>
> [1] https://bugs.launchpad.net/ironic/+bug/1635619
> [2] https://review.openstack.org/#/c/348437/
> [3] https://tools.ietf.org/html/rfc7231#section-6.3.3
>
> Yuriy Zveryanskyy
>
>
> __
> OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

Absolutely, the default would be disabled and those who want it can enable
it. There will be a cost; hashing and signing aren't cheap and we shouldn't
have to pay the cost when we don't have to.

-amrith

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Friday, November 4, 2016 8:22 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][dev][python] constructing a
deterministic
> representation of a python data structure
> 
> 
> 
> On 04/11/16 08:02 AM, Amrith Kumar wrote:
> > [Amrith Kumar] I wasn't sure I'd be able to do this before (the only
> > place where this model will work is in oslo.messaging) but thanks to
> > the links that Dims forwarded, there may be a chance to make this part
of
> oslo!
> 
> if you do this in oslo.messaging, can i suggest you disable it by default.
i
> haven't tried this in quite a while but i do remember it made message
> sending a few times slower when signing messages with hmac. i imagine it
> also added the same overhead on receiving end.
> 
> 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


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

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

[Jim Rollenhagen]

On Thu, Nov 3, 2016 at 3:04 PM, Joshua Harlow  wrote:
> Jay Faulkner wrote:
>>>
>>> On Nov 3, 2016, at 11:27 AM, Joshua Harlow  wrote:
>>>
>>> Just as a followup from the summit,
>>>
>>> One of the sessions (the new lib one) had a few proposals:
>>>
>>> https://etherpad.openstack.org/p/ocata-oslo-bring-ideas
>>>
>>> And I wanted to try to get clear owners for each part (there was some
>>> followup work for each); so just wanted to start this email to get the
>>> thoughts going on what to do for next steps.
>>>
>>> *A hash ring library*
>>>
>>> So this one it feels like we need at least a tiny oslo-spec for and for
>>> someone to write down the various implementations, what they share, what
>>> they do not share (talking to swift, nova, ironic and others? to figure this
>>> out). I think alexis was thinking he might want to work through some of that
>>> but I'll leave it for him to chime in on that (or others feel free to also).
>>>
>>> This one doesn't seem very controversial and the majority of the work is
>>> probably on doing some analysis of what exists and then picking a library
>>> name and coding that up, testing it, and then integrating (pretty standard).
>>>
>>
>> Ironic and Nova both share a hash ring implementation currently
>> (ironic-conductor and nova-compute driver for ironic). It would be sensible
>> to reuse this implementation, oslo-ify it, and have that code shared.
>>
>> I question the value of re-implementing something like this from scratch
>> though.
>>
>> Thanks,
>> Jay Faulkner
>> OSIC
>>
>
> Right I don't think the intention would be to implement it from scratch, but
> to do some basic analysis of what exists (and think about and document the
> patterns), and try to find the common parts (which likely involves renaming
> some specific nova/ironic methods from what I see); especially if we can get
> swift to perhaps (TBD) also use and contribute to this library.

As the person who copied that code into Nova, the Nova code is a strict subset
of the Ironic code.

Some of us talked to John Dickinson off-list, and it seems the Swift hash ring
has very different use cases and very different implementation. I
think we should
focus on pulling the Nova/Ironic code out first, and then talking to
Swift if we can
also make it work for them (sounds like it's not helpful today).

// jim

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

Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)

[Ken Giusti]

On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow  wrote:
> Hi folks,
>
> There was a bunch of chatter at the summit about how there are really two
> different types of (oslo) messaging usage that exist in openstack and how
> they need not be backed by the same solution type (rabbitmq, qpid,
> kafka...).
>
> For those that were not at the oslo sessions:
>
> https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo
>
> The general gist was though that we need to make sure people really do know
> that there are two very different types of messaging usage in openstack and
> to ensure that operators (and developers) are picking the right backing
> technology for each type.
>
> So some questions naturally arise out of this.
>
> * Where are the best practices with regard to selection of the best backend
> type for rpc (and one for notifications); is this something oslo.messaging
> should work through (or can the docs team and operator group also help in
> making this)?
>
> * What are the tradeoffs in using the same (or different) technology for rpc
> and notifications?
>

I think the olso.messaging team should take the lead here and educate
users as to what the options are, and  how the two supported messaging
services (RPC and Notifications) differ with respect to backend
requirements.   These topics really should be part of the
oslo.messaging 'Theory of Operations' documentation that was discussed
during the Arch WG summit meeting.

Currently the biggest functional difference between the backends is
the support of store-and-forward (e.g. queueing) verses point-to-point
message transfer.  Oslo could at least explain the pros and cons of
each approach with respect to the RPC and Notification services so
that folks understand what the tradeoffs and advantages are in the
first place.

Furthermore the team should also document the functional differences
between the various choices of backends.  For instance it would be
useful to understand how the two supported point-to-point backends
(zmq and dispatch router) differ in both behavior and recommended
deployment.


> * Is it even possible for all oslo.messaging consuming projects to be able
> to choose 2 different backends, are consuming projects consuming the library
> correctly so that they can use 2 different backends?
>
> * Is devstack able to run with say kafka for notifications and rabbitmq for
> rpc (if not, is there any work item the oslo group can help with to make
> this possible) so that we can ensure and test that all projects can work
> correctly with appropriate (and possibly different) backends?
>
> * Any other messaging, arch-wg work that we (oslo or others) can help out
> with to make sure that projects (and operators) are using the right
> technology for the right use (and not just defaulting to RPC over rabbitmq
> because it exists, when in reality something else might be a better choice)?
>

Ultimately there should be recommendations for which backends are
optimal for a range of different deployment scenarios, but at this
point we really don't have enough data and experience with these
backends to create such recommendations.

> * More(?)
>
> Just wanted to get this conversation started, because afaik it's one that
> has not been widely circulated (and operators have been setting up rabbitmq
> in various HA and clustered and ... modes, when in reality thinking through
> what and how it is used may be more appropriate); this also applies to
> developers since some technical solutions in openstack seem to be created
> due to (in-part) rabbitmq shortcomings (cells v1 afaik was *in* part created
> due to scaling issues).
>
> -Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Ken Giusti  (kgiu...@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] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

[Mohammed Naser]

Just a bit of feedback on our side:

We have been using Puppet 4 for quite sometime from the Puppetlabs repos 
without any issues. The OpenStack modules all work fine for us and I haven't 
ran into any issues around other modules having any major Puppet 4 
compatibility issues. 

Sent from my iPhone

> On Nov 3, 2016, at 11:58 AM, Alex Schultz  wrote:
> 
> Hey everyone,
> 
> Puppet 3 is reaching it's end of life at the end of this year[0].
> Because of this we are planning on dropping official puppet 3 support
> as part of the Ocata cycle.  While we currently are not planning on
> doing any large scale conversion of code over to puppet 4 only syntax,
> we may allow some minor things in that could break backwards
> compatibility.  Based on feedback we've received, it seems that most
> people who may still be using puppet 3 are using older (< Newton)
> versions of the modules.  These modules will continue to be puppet 3.x
> compatible but we're using Ocata as the version where Puppet 4 should
> be the target version.
> 
> If anyone has any concerns or issues around this, please let us know.
> 
> Thanks,
> -Alex
> 
> [0] https://puppet.com/misc/puppet-enterprise-lifecycle
> 
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Eduardo Gonzalez]

+1


2016-11-04 13:32 GMT+00:00 Jeffrey Zhang :

> +1
>
> On Fri, Nov 4, 2016 at 8:51 PM, Ryan Hallisey  wrote:
>
>> +1
>>
>> -Ryan
>>
>> - Original Message -
>> From: "Swapnil Kulkarni" 
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Sent: Friday, November 4, 2016 8:48:49 AM
>> Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix
>> requirement
>>
>> On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke 
>> wrote:
>> > Kolleagues,
>> >
>> > How do people feel above removing the requirement of having TrivialFix
>> in
>> > commit messages where a bug/bp is not required?
>> >
>> > I'm seeing a lot of valid and important commits being held up because of
>> > this, in my opinion, unnecessary requirement. It also causes friction
>> for
>> > new contributers to the project.
>> >
>> > Are there any major benefits we're getting from the use of this tag
>> that I'm
>> > missing?
>> >
>> > Cheers,
>> > -Paul
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> I feel TrivialFix is consistently used by people just to avoid going
>> to lanuchpad and filing a bug. It should only be used only if the "Fix
>> is Trivial"
>> This has been well documented in the contributing doc [1] and this
>> should be referred to people when they do not have the bug/bp in the
>> commit message.
>>
>> If the commits are important then there is no harm in creating a
>> tracking bug for it.
>> It would take 1/30(I am just making highest time for a build/deploy
>> gate) amount of time you need to verify the (important)fix on gate.
>>
>> [1] docs.openstack.org/developer/kolla/CONTRIBUTING.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Jeffrey Zhang]

+1

On Fri, Nov 4, 2016 at 8:51 PM, Ryan Hallisey  wrote:

> +1
>
> -Ryan
>
> - Original Message -
> From: "Swapnil Kulkarni" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Friday, November 4, 2016 8:48:49 AM
> Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix
> requirement
>
> On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke 
> wrote:
> > Kolleagues,
> >
> > How do people feel above removing the requirement of having TrivialFix in
> > commit messages where a bug/bp is not required?
> >
> > I'm seeing a lot of valid and important commits being held up because of
> > this, in my opinion, unnecessary requirement. It also causes friction for
> > new contributers to the project.
> >
> > Are there any major benefits we're getting from the use of this tag that
> I'm
> > missing?
> >
> > Cheers,
> > -Paul
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I feel TrivialFix is consistently used by people just to avoid going
> to lanuchpad and filing a bug. It should only be used only if the "Fix
> is Trivial"
> This has been well documented in the contributing doc [1] and this
> should be referred to people when they do not have the bug/bp in the
> commit message.
>
> If the commits are important then there is no harm in creating a
> tracking bug for it.
> It would take 1/30(I am just making highest time for a build/deploy
> gate) amount of time you need to verify the (important)fix on gate.
>
> [1] docs.openstack.org/developer/kolla/CONTRIBUTING.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Ryan Hallisey]

+1

-Ryan

- Original Message -
From: "Swapnil Kulkarni" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, November 4, 2016 8:48:49 AM
Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix  
requirement

On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke  wrote:
> Kolleagues,
>
> How do people feel above removing the requirement of having TrivialFix in
> commit messages where a bug/bp is not required?
>
> I'm seeing a lot of valid and important commits being held up because of
> this, in my opinion, unnecessary requirement. It also causes friction for
> new contributers to the project.
>
> Are there any major benefits we're getting from the use of this tag that I'm
> missing?
>
> Cheers,
> -Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.
It would take 1/30(I am just making highest time for a build/deploy
gate) amount of time you need to verify the (important)fix on gate.

[1] docs.openstack.org/developer/kolla/CONTRIBUTING.html

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

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Swapnil Kulkarni]

On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke  wrote:
> Kolleagues,
>
> How do people feel above removing the requirement of having TrivialFix in
> commit messages where a bug/bp is not required?
>
> I'm seeing a lot of valid and important commits being held up because of
> this, in my opinion, unnecessary requirement. It also causes friction for
> new contributers to the project.
>
> Are there any major benefits we're getting from the use of this tag that I'm
> missing?
>
> Cheers,
> -Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.
It would take 1/30(I am just making highest time for a build/deploy
gate) amount of time you need to verify the (important)fix on gate.

[1] docs.openstack.org/developer/kolla/CONTRIBUTING.html

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Michał Jastrzębski]

Yeah I was thinking of it myself.

+1 from me

On 3 November 2016 at 09:08, Christian Berendt
 wrote:
>
>> On 3 Nov 2016, at 14:33, Mauricio Lima  wrote:
>>
>> I Agree. +1
>
> +1
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 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][dev][python] constructing a deterministic representation of a python data structure

[gordon chung]

On 04/11/16 08:02 AM, Amrith Kumar wrote:
> [Amrith Kumar] I wasn't sure I'd be able to do this before (the only place
> where this model will work is in oslo.messaging) but thanks to the links
> that Dims forwarded, there may be a chance to make this part of oslo!

if you do this in oslo.messaging, can i suggest you disable it by 
default. i haven't tried this in quite a while but i do remember it made 
message sending a few times slower when signing messages with hmac. i 
imagine it also added the same overhead on receiving end.

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

[openstack-dev] [requirements][infra] Fwd: [TIP] new tox-dev mailing list on python

[Doug Hellmann]

At the summit last week there were some discussions about limitations of
tox and how they affect our use of constraints. It looks like
contributing to tox may be getting easier, so it's possible that some of
the ideas floated at the summit (like adding separate install commands
or a "prepare virtualenv" command setting) could be possible.

Doug

--- Begin forwarded message from holger krekel ---
From: holger krekel 
To: Testing in Python , pytest-dev 

Date: Fri, 04 Nov 2016 10:53:16 +0100
Subject: [TIP] new tox-dev mailing list on python

Hey all,

thanks to Mark Sapiro we now have a dedicated mailing list (tox-dev at 
python.org) and it's even using Mailman3 :) Please subscribe here:

https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org

We also recently moved tox development to github:

https://github.com/tox-dev/tox

I am more than happy to give people commit/push/merge rights, especially those 
who contributed already.

I take the opportunity to thank Oliver Bestwalter for stepping up to sort 
through issueslately.  Some of the activity around tox also was possible thanks 
to the 2016 python testing sprint which was crowdfunded.  So thanks to those 
who contributed at the sprint and for the sprint.  Next up is getting a nice 
logo for tox[1].  So don't hesitate to join tox-dev ML to influence what logo 
tox is going to have :)

best,
holger

[1] I suggest we use a bit of the remaining crowd-funds to give some money to 
whoever comes up with a nice logo design.

--- End forwarded message ---

__
OpenStack Development Mailing List (not for 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][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: Thursday, November 3, 2016 6:04 PM
> To: openstack-dev 
> Subject: Re: [openstack-dev] [all][dev][python] constructing a
deterministic
> representation of a python data structure
> 
> Excerpts from Amrith Kumar's message of 2016-11-03 20:50:01 +:
> > Josh,
> >
> > I have the key management part figured out and in actuality I will be
> > signing the messages.
> >
> > But step 1 is getting a deterministic representation and step 2 is
hashing.
> > Step 3 would be signing.
> >
> > So, steps 2 and 3 are all set; just need step 1 :) And I'm marveling
> > at the link that Morgan provided, it may have what I need.
> >
> 
> Please please please do not invent your own home rolled cryptographic
> envelope!!

[Amrith Kumar] Of course, did it once, have the badge and don't need another
:)

> 
> sender.py:
> 
> 
> to_send = {
>   'fact': 'red is the best color'
> }
> payload = json.dumps(to_send)
> message = gpg_sign(payload, key)
> send_message(message)
> 
> 
> receiver.py:
> 
> message = recv_message()
> (payload, key) = gpg_verify_message(message) if key not in trusted_keys:
>   raise Exception('Untrusted sender!')
> operate_on_payload(payload)
> 
> With all due respect, any of us are almost guaranteed to screw it up
> otherwise. Just use a thing known to work. There are plenty already.

[Amrith Kumar] I wasn't sure I'd be able to do this before (the only place
where this model will work is in oslo.messaging) but thanks to the links
that Dims forwarded, there may be a chance to make this part of oslo!


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


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

[openstack-dev] [Congress] Restart Congress server

[Ruben]

Hi everyone,
I've tried to write a datasource driver for Magnum and the unit test for it.
So I've add this datasource driver in /opt/stack/congress/congress/datasources/ 
and the unit test in /opt/stack/congress/congress/tests/datasources/ to test it.
Moreover, I've add the driver to /etc/congress/congress.conf, but when I try to 
restart Congress server I've some errors.


"2016-11-04 12:13:00.390 TRACE congress.service self.service_id, service, 
table)
2016-11-04 12:13:00.390 TRACE congress.service   File 
"/opt/stack/congress/congress/dse2/dse_node.py", line 468, in subscribe_table
2016-11-04 12:13:00.390 TRACE congress.service {'table': table})
2016-11-04 12:13:00.390 TRACE congress.service   File 
"/opt/stack/congress/congress/dse2/dse_node.py", line 355, in invoke_service_rpc
2016-11-04 12:13:00.390 TRACE congress.service raise exception.NotFound(msg 
% service_id)
2016-11-04 12:13:00.390 TRACE congress.service NotFound: service 'nova' could 
not be found
2016-11-04 12:13:00.390 TRACE congress.service 
2016-11-04 12:13:00.537 DEBUG oslo_concurrency.lockutils [-] Acquired semaphore 
"singleton_lock" from (pid=24411) lock 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:212
2016-11-04 12:13:00.538 DEBUG oslo_concurrency.lockutils [-] Releasing 
semaphore "singleton_lock" from (pid=24411) lock 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225"

I don't know what to do to solve it and even if the driver I've written works.
Maybe I make mistakes when I restart Congress server..
What should I do to restart Congress server?
What could I do to test the datasource and solve these problems?

Ruben

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

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

[Mehdi Abaakouk]

Le 2016-11-03 19:27, Joshua Harlow a écrit :

*Next-gen oslo.service replacement*

This one may require a little more of a plan on how to make it work,
but the gist is that medhi (and others) has created
https://github.com/sileht/cotyledon which is a nice replacement for
oslo.service that ceilometer is using (and others?) and the idea was
to start to figure out how to move away from (or replace with?)
olso.service with that library.


If people are interested, the doc is here [0]


I'd like to see a spec with some of the details/thoughts on how that
could be possible, what changes would still be needed. I think from
that session that the following questions were raised:

- Can multiprocessing (or subprocess?) be used (instead of os.fork)
- What to do about windows?


I have already solved those two by using multiprocessing, disable 
SIGHUP and write down the limitation [1]


- Is it possible to create a oslo.service compat layer that preserves 
the oslo.service API but uses cotyledon under the covers to smooth the 
transition/adoption of other projects to cotyledon


Not sure it's easy to do, cotyledon API encourages user to not create 
any python objects before the process is forked to ensure we didn't have 
any rpc/mysql/... connections open and unused, FDs open, lock acquired, 
(put any thing here that can result in race when using os.fork()). While 
oslo.service forces the user to create objects before the fork occurs.


- Perhaps in general we should write how an adoption could happen for a 
consuming project (maybe just writing down how ceilometer made the 
switch would be a good start, what issues were encountered, how they 
were resolved...)


This is avialable here [2]

[0] http://cotyledon.readthedocs.io/en/latest/
[1] http://cotyledon.readthedocs.io/en/latest/non-posix-support.html
[2] http://cotyledon.readthedocs.io/en/latest/oslo-service-migration.html
--
Mehdi Abaakouk
mail: sil...@sileht.net
:w
irc: sileht

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

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Nov. 4 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-04-08.00.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-04-08.00.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-04-08.00.log.html
 


B.R.,
Zhijiang


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

[openstack-dev] [infra]multi-region devstack gate job

[joehuang]

Hello,

Is multi-region devstack gate job supported in openstack-infra?

Devstack itself supports multi-region setup, i.e, multiple OpenStack clouds 
with shared KeyStone[1]. Tricircle wants to add multi-region gate job for cross 
Neutron networking automation, but did not find some example on how to setup 
multi-region gate job, it makes me confused, as far as I know, many projects 
like Heat, Shade, Senlin, Murano etc provide multi-region related features, so 
I think multi-region gate job should be a quite common job.

If this type of job has not been supported, is it possible to provide a 
multi-region devstack gate job framework in openstack-infra?

http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup

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

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 4 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction

B.R.,
Zhijiang


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

Re: [openstack-dev] [nova] Nova-MultiJob CI (non-voting) request to comment

[Lenny Verkhovsky]

It uses 2 physical servers with 2 compute nodes
And runs migration tests only. 
Other Mellanox CI jobs run on a single allinone server, thus migration tests 
are skipped.

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Friday, November 04, 2016 1:45 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Nova-MultiJob CI (non-voting) request
> to comment
> 
> On 11/3/2016 3:45 AM, Lenny Verkhovsky wrote:
> > Hi,
> >
> > We would like Mellanox[1] MultiNode CI job  to start commenting as
> > 'non voting' job on partial nova[2] and tempest[3] code.
> >
> > This Job runs few migration tests[4] and an example of its run can be
> > seen here[5].
> >
> >
> >
> > [1] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI
> >
> > [2] nova/pci
> >
> > [3] tempest/ scenario
> >
> > [4]
> > http://13.69.151.247/98/348498/6/check-sriov-tempest/Nova-ML2-Sriov-
> Mu
> > ltinode/46e401e/testr_results.html.gz
> >
> > [5] https://review.openstack.org/#/c/348498/6
> >
> >
> >
> >
> >
> > Thanks
> >
> > Lenny (aka lennyb on irc)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> What's different about this job configuration from the other Mellanox CIs
> that already run against nova?
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

[Tim Bell]

On 4 Nov 2016, at 06:31, Sam Morrison 
> wrote:


On 4 Nov. 2016, at 1:33 pm, Emilien Macchi 
> wrote:

On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison 
> wrote:
Wow I didn’t realise puppet3 was being deprecated, is anyone actually using 
puppet4?

I would hope that the openstack puppet modules would support puppet3 for a 
while still, at lest until the next ubuntu LTS is out else we would get to the 
stage where the openstack  release supports Xenial but the corresponding puppet 
module would not? (Xenial has puppet3)

I'm afraid we made a lot of communications around it but you might
have missed it, no problem.
I have 3 questions for you:
- for what reasons would you not upgrade puppet?

Because I’m a time poor operator with more important stuff to upgrade :-)
Upgrading puppet *could* be a big task and something we haven’t had time to 
look into. Don’t follow along with puppetlabs so didn’t realise puppet3 was 
being deprecated. Now that this has come to my attention we’ll look into it for 
sure.

- would it be possible for you to use puppetlabs packaging if you need
puppet4 on Xenial? (that's what upstream CI is using, and it works
quite well).

OK thats promising, good to know that the CI is using puppet4. It’s all my 
other dodgy puppet code I’m worried about.

- what version of the modules do you deploy? (and therefore what
version of OpenStack)

We’re using a mixture of newton/mitaka/liberty/kilo, sometimes the puppet 
module version is newer than the openstack version too depending on where we’re 
at in the upgrade process of the particular openstack project.

I understand progress must go on, I am interested though in how many operators 
use puppet4. We may be in the minority and then I’ll be quiet :-)

Maybe it should be deprecated in one release and then dropped in the next?


We’re running Puppet 3 at the moment with around 25,000 hosts. There is ongoing 
work testing Puppet 4 but it takes some time to make sure that the results are 
the same. The performance is looking promising.

I think we’ll be done with the migration by the time we get to Ocata (currently 
between Liberty and Mitaka)

Tim


Cheers,
Sam






My guess is that this would also be the case for RedHat and other distros too.

Fedora is shipping Puppet 4 and we're going to do the same for Red Hat
and CentOS7.

Thoughts?



On 4 Nov. 2016, at 2:58 am, Alex Schultz 
> wrote:

Hey everyone,

Puppet 3 is reaching it's end of life at the end of this year[0].
Because of this we are planning on dropping official puppet 3 support
as part of the Ocata cycle.  While we currently are not planning on
doing any large scale conversion of code over to puppet 4 only syntax,
we may allow some minor things in that could break backwards
compatibility.  Based on feedback we've received, it seems that most
people who may still be using puppet 3 are using older (< Newton)
versions of the modules.  These modules will continue to be puppet 3.x
compatible but we're using Ocata as the version where Puppet 4 should
be the target version.

If anyone has any concerns or issues around this, please let us know.

Thanks,
-Alex

[0] https://puppet.com/misc/puppet-enterprise-lifecycle

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
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] [new][neutron] neutron-lib 1.0.0 release (ocata)

[no-reply]

We are ecstatic to announce the release of:

neutron-lib 1.0.0: Neutron shared routines and utilities

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/neutron-lib

Download the package from:

https://pypi.python.org/pypi/neutron-lib

Please report issues through launchpad:

http://bugs.launchpad.net/neutron

For more details, please see below.

1.0.0
^


New Features


* The ExtensionDescriptor class moved from neutron.api.extensions to
  neutron_lib.api.extensions.

* Introduced neutron_lib.plugins.directory to get references for
  loaded plugins in a neutron server process. For example:

 from neutron_lib import constants
 from neutron_lib.plugins import directory

 core_plugin = directory.get_plugin()
 l3_plugin = directory.get_plugin(constants.L3)

  For more examples, see: https://review.openstack.org/#/c/386845/

* API reference for the trunk extension.


Other Notes
***

* Provide API definition framework for Neutron Stadium APIs to be
  consolidated into neutron-lib. For more details see review
  https://review.openstack.org/#/c/353131/.

Changes in neutron-lib 0.4.0..1.0.0
---

6f944bf Updated from global requirements
bbd71c4 Add ExtensionDescriptor to neutron-lib
b95c1dd Add release note for plugin directory
763fe5e Introduce Plugin Directory for Neutron
08cefc5 Updated from global requirements
69443d6 Updated from global requirements
0e80e41 Initial seed for neutron-lib release notes
256411c Updated from global requirements
e1bda4e Revise coverage guidelines
4fbf121 Add release notes target
ff2bb74 api-ref: Fix api-ref for service-providers
cd0802f Enable fatal exceptions during tests
4da1998 Introduce API definition for trunk/trunk_details extensions
645fd18 Updated from global requirements
87fbf52 [doc] Allow creating loadbalancer with network_id
b065a28 Change wording around router:external
0c3959d Add segments to v2 API reference
abeb5c4 Enhance valid_values to use __contains__
6584de1 Add missing tenant_id/project_id request parameter
4c7a75c Add unit test for test_exceptions
5145ea4 [api-ref] Corrected the redirect URL to Openstack Identity Service
429e5c2 api-ref: Update to current state of Keystone V3 support
990a5d7 Rehome populate_project_info() from neutron
4b02ff4 api-ref: remove notion of supported xml format
3385108 Add unit test for test_helpers
bb88c5a Simplify method convert_to_boolean with strutils.bool_from_string
2151fea Deprecate method ensure_dir
9ca5306 Trivial: Remove 'MANIFEST.in'
168b1d0 Config logABug feature for Neutron-lib api-ref
7026399 Fix typo: remove redundant 'the'
2b99fac Updated from global requirements
c0cb29c Do not make project depends on Babel by default
c4610ce Correct test_tenant_id_attribute
090dee5 Updated from global requirements
6cf9c87 Updated from global requirements
b5454ed Add support for upper-constraints.txt for all tox targets
6a73e97 api-ref: Add Networking v2.0 API versions response parameters
b06a428 Updated from global requirements
35bcd60 Add info about API method to get default quotas
0681c39 [api-ref] Remove temporary block
3d043c0 Fix regression in validate_uuid_list()
00439e9 Add  docstrings for api.validators
ecab656 Fix confusion between Neutron and FWaaS versions
6569169 Add eventlet hacking check UT
efa0198 api-ref: added a note to lbaasv1 about its removal in N+
adef52e Move valuable API info from neutron-specs repo
ba7dee0 api-ref: introduced a stub sub-page to cover general info
9a81fde Updated from global requirements
bb397df Trivial DevRef Spelling corrections
e1ef4a6 api-ref: Correcting parameters type


Diffstat (except docs and test files)
-

.gitignore |   3 +
MANIFEST.in|   6 -
api-ref/source/conf.py |  40 +-
api-ref/source/v2/flavors.inc  |  14 +-
api-ref/source/v2/floatingips.inc  |  22 +-
api-ref/source/v2/fwaas.inc|  69 +-
api-ref/source/v2/index.rst|   4 +
api-ref/source/v2/intro.inc| 433 
api-ref/source/v2/lbaas-v1.inc |  67 +-
api-ref/source/v2/lbaas-v2.inc | 173 +++--
api-ref/source/v2/metering.inc |  15 +-
api-ref/source/v2/network-ip-availability.inc  |   6 +-
api-ref/source/v2/network-provider.inc |  20 +-
api-ref/source/v2/networks-multi-provider-ext.inc  |  16 +-
.../source/v2/networks-vlan-transparency-ext.inc   |  12 +-
api-ref/source/v2/networks.inc |  22 +-
api-ref/source/v2/parameters.yaml  | 749 +
api-ref/source/v2/port-binding.inc |   2 +-
api-ref/source/v2/ports.inc|  28 +-
api-ref/source/v2/qos.inc  

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

[Jianghua Wang]

Thanks Ihar, Thierry and Bob. I think we've agreed to go with the 1st option - 
"Get Neutron to call XenAPI directly rather than trying to use a daemon".
I will refine the POC patch to make it ready for the formal review.

R.g.t the test, I did some basic test in a real lab manually and it worked as 
expected. For sure more tests will be done forwarding. We will evaluate if to 
change the XenServer CI to use the daemon mode once this fix got merged.

Regards,
Jianghua

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, November 03, 2016 10:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem 
for XenServer

Bob Ball  wrote:

> Hi Ihar,
>
>> I am puzzled. Is Neutron the only component that need to call to dom0?
>
> No it's not.  Nova has similar code to call plugins in dom0[1], and 
> Ceilometer will also need to make the calls for some metrics not 
> exposed through the formal API.
>
> We don't want code duplication, and are working on a common os-xenapi 
> library which will include session management.
> It would, of course, make sense for Neutron to use this common library 
> when it is available to replace the session management already 
> existing[2], but I'd argue that as there is existing XenAPI session 
> management code, the refactor to avoid using a per-command rootwrap 
> should be independent of using the session code from os-xenapi.

Seems like you are in a position that requires you to hook into neutron 
processes somehow, and it’s either neutron itself (your solution), or a library 
used by neutron (oslo.rootwrap or similar). I understand why you picked the 
first option.

>
>> I would think that Neutron is not in business of handling hypervisor 
>> privilege isolation mechanics, and that some other components will 
>> handle that for Neutron (and other services that may need it), that’s 
>> why I suggested to consider oslo.* realm for the proposed code.
>
> This is less about hypervisor privilege isolation and more about the 
> location of the logical component being updated.  Neutron is assuming 
> that the OVS being updated is running in the same location as Neutron 
> itself.  For XenAPI that is not true; the OVS is running in the 
> hypervisor, whereas Neutron is running in a VM (or potentially 
> elsewhere entirely).
>
> If oslo.* is going to decide whether to run a command using a specific 
> abstraction or locally, then it would need some way of making that 
> decision - perhaps either command-based (very ugly and fragile) or 
> with the caller telling oslo.* what logical component was being 
> affected by the call.  The latter sounds to me much more as a 
> Neutron-specific decision.

I believe os-xenapi is a nice path forward. I understand it will take some time 
to shape.

As for the dom0/domU routing decision, yes, it’s indeed on Neutron to make it. 
But it does not mean that we could not rely on existing filtering mechanisms 
(oslo.rootwrap ‘.filters’ files) to define that decision. The fact that current 
netwrap script for Xen duplicates filters from rootwrap is unfortunate. It 
should be a single source of truth.

It would probably require some extensive work in the library, and considering 
that oslo folks moved the library into maintenance mode, it probably won’t 
happen. As for oslo.privsep, that would be a better place for such a feature, 
but we won’t get there in Ocata. Bummer…

I guess I will unblock the patch, and we’ll see what others think. I left some 
initial review comments.

>
>> Side note: if we are going to make drastic changes to existing Xen-wrap  
>> script, we should first have Xen
>> third-party CI testing running against it, not to introduce regressions.  
>> AFAIK it’s not happening right now.
>
> It already is running, and has been for several months - see "Citrix  
> XenServer CI"s "dsvm-tempest-neutron-network" job on  
> https://review.openstack.org/#/c/391308/ as an example.  The CI is  
> non-voting but if it were added to the neutron-ci group we would be very  
> happy to make it voting.

Oh right. It does not validate the new change though. Would be nice to see  
the new ‘daemon’-ic mode behaves in real world.

Ihar

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