[openstack-dev] Requirements freeze exception: urllib3

[Thomas Goirand]

Hi,

Please see this:
https://review.openstack.org/122993

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [nova][vmware] Juno update

[Gary Kotton]

Hi,

Below is a short update of the current status of the driver in Juno.

We managed to complete the following specs:

  *   Integration with oslo.vmware 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/use-oslo-vmware.rst)
  *   Hot plug interface 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-hot-plug.rst)
  *   Span refactor 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-spawn-refactor.rst)

The following specs were implemented but did not manage to land:

  *   Ephemeral disk support 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-ephemeral-disk-support.rst)
  *   Storage based policies 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-spbm-support.rst)

The following specs were partially implemented - they need to be rebased after 
the spawn refactor:

  *   Spawning an OVA image 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-driver-ova-support.rst)
  *   VSAN support 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-vsan-support.rst)

In addition to this the ESX driver is no longer supported.

In addition to this we have a number of critical bugs that are in review:

  *   Update to latest oslo.vmware (https://review.openstack.org/#/c/121614/)
  *   VMware: Convert file_size to int 
(https://review.openstack.org/#/c/120309/)
  *   VMware: fix exception when multiple compute nodes are running 
(https://review.openstack.org/#/c/108225)
  *   VMware: fix regression for 'TaskInProgress' 
(https://review.openstack.org/#/c/121479/)
  *   VMware: prevent race condition with VNC port allocation 
(https://review.openstack.org/#/c/114548/)
  *   VMware: fix VM rescue problem with VNC console 
(https://review.openstack.org/#/c/113908/)
  *   VMware: support inventory folders 
(https://review.openstack.org/#/c/122017/)
  *   vc driver breaks instances.hypervisor_hostname value 
(https://review.openstack.org/#/c/99623/)

Hopefully we can get the above patches in (some may require a rebase ...)

Thanks
Gary



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

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

[Thomas Goirand]

Hi Ian and Donald,

I've read the full thread, and couldn't help to reply to it still, even
though I previously thought I shouldn't, as what I care is OpenStack,
not really requests, and more largely, the topic of the wrong reasons
why upstream are embedding foreign library code copies. I completely
agree with someone else who wrote that this thread is nearly
uninteresting for OpenStack itself. However, it is IMO my role, as a
package maintainer, to let you know about my view on your argumentation.

If you ignore my argumentation, then at least I'll have tried! :)

On 09/18/2014 03:42 AM, Ian Cordasco wrote:
> Circling back to the issue of vendoring though: it’s a conscious decision
> to do this, and in the last two years there have been 2 CVEs reported for
> requests. There have been none for urllib3 and none for chardet. (Frankly
> I don’t think either urllib3 or chardet have had any CVEs reported against
> them, but let’s ignore that for now.) While security is typically the
> chief concern with vendoring, none of the libraries we use have had
> security issues rendering it a moot point in my opinion. The benefits of
> vendoring for us as a team have been numerous and we will likely continue
> to do it until it stops benefiting us and our users.

Could you please list the benefits *for end users*? I'm really saying
users, as in, not developers. Because I don't see any benefit at all for
the end users. I don't think any of them would like to see many version
of the same thing on their system.

Also, the issue is not only security. Let me give you an example. Simply
do this in a Debian sid machine:

apt-file search six.py | grep -v python3 | grep -v pyshared | wc -l

We have in Debian, about 50 versions of six.py around, embedded in
packages. And this doesn't even counts those where only bits of six are
just embedded in a file which isn't called six.py.

Of course, we (in Debian) would like them to be removed. Why? Because
it's a useless complexity, with so many different version, some with
embedded bugs which have been fixed upstream, and the like. That's not
even about security at this point (I hardly would see how six.py would
have security issue).

There is also a waste of server resources (install time, size of
packages in the Debian archive, increased download time, RAM footprint
of everything, etc.). We don't need to install (and compile as .pyc at
install time) 50 versions of six.py, a single one is enough. We're
trying to address this as much as we can, and you'll see lots of
packages were we did, but it's not always easy for various reasons, like
upstream code not up-to-date with latest version, or lack of time from
the Debian package maintainer.

Also, consider the fact that six is small: a quite small single file.
It's still unacceptable from a Unix distribution stand point, but this
makes the "vendorizing" less of an absurdity. Now, for urllib3, it's a
WAY bigger. There's about 25 Python files. So multiply the resulting
waste and issues...

This was a simple example for six. Now just generalize to all. There's
numerous upstream authors who also think that it's ok, and they can be
one of the few exception. But really, every upstream who does this think
that he's "special". That's not the case. Requests isn't more special
than any other Python module.

On 09/18/2014 04:31 AM, Ian Cordasco wrote:
> Isn’t the whole point of distributing a library to let people use it
> as they see fit?

The point of a library, is that it is shared among multiple consumers.
Oh, maybe not if you're using Windows, but that's maybe out of the scope
of this debate. Maintaining a coherent distribution with a single
version of every library, is what distributions do as much as possible.
It is unfortunately not always possible, but we do it as much as we can.

On 09/18/2014 04:31 AM, Ian Cordasco wrote:
> Project X pins a version of requests. Alice doesn’t know anything
> about requests and does pip install X. Until Alice takes a more
> active role in the development of Project X and looks into requests,
> she will never know she’s installed software that has exposures in
> it. In all likelihood, any person who just uses something that pins
> requests will never check for it. If they just use pip and Project X
> never updates, it’s not our responsibility for anything that happens
> to the user.

This is exactly why we should, at all costs, avoid using pinning. This
is very dangerous, and leads to all sorts of issues. We should make sure
that we stay current with absolutely all libraries, and when possible,
support both the old and the new version of some incompatible API when
possible.

On 09/18/2014 04:31 AM, Ian Cordasco wrote:
> I think more applications bundle it than you realize. You’re likely
> using one daily that does it.

It's not because stupidity is wide spread that it becomes smartness.
(nothing personal, just making a general statement...)

On 09/18/2014 04:31 AM, Ian Cordasco wrote:
> The reality is that by

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

[Thomas Goirand]

On 09/18/2014 05:22 AM, Dean Troyer wrote:
> On Wed, Sep 17, 2014 at 3:53 PM, Robert Collins
> mailto:robe...@robertcollins.net>> wrote:
> 
> On 18 September 2014 08:01, Dean Troyer  > wrote:
> > Interestingly enough, the distros are doing exactly what they don't 
> want us
> > to do, ie, rebuilding things to use 'their' tested version of 
> dependencies
> > rather than the included one...

We don't use "our" tested version, we use upstream's, and a single
version of it.

> Indeed - but the distros are solving for two specific issues:
> 
> 
> No argument, just observing the recursive nature of this...
> 
> Also, if we pin to a version, is the downstream consequence different?
>  IIRC Thomas has had to do this with Django (1.7?) and Horizon, probably
> with others too.

Correct. And there's still some open issues with it, though mostly it
has been dealt with. There was also SQLAlchemy 0.8 then 0.9 a year ago
as well. Though since Mike Bayer works on OpenStack support now, I'm
sure I wont have to deal with any SQLA issue again.

It's a common mistake to think that "we just need to pin". Pinning (the
upper bound) doesn't solve any issue, apart from having the tests pass
the gate. This is sometimes urgent to "fix" the gate, so I understand
why this is done. The reality is that packages in a distribution share
common dependency, and OpenStack isn't alone in the distro.

Lucky, (almost?) everyone in the OpenStack community understand this,
and so far, I've received *a lot* of help from everyone. You have no
idea how much this is important to me. Kudos to everyone who do help or
who is at least gives moral support! :)

> As a provider of an app package directly to users, dealing with the
> front-line consequences of changing dependencies falls on me.  And its
> one reason with this hat on I want static linking, or a Python
> equivalent of it (bundling/vendoring) at the app level.

Since a few days, the Debian policy manual explicitly forbids static
linking. I fully agree with the decision to make it explicit.

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

[Ian Cordasco]

Hi Thomas,

Several people, many of whom are core contributors to other projects, have
asked that this discussion not be continued in this venue. Discussion of
the decisions of the core-developers of requests are not appropriate for
this list. All three of us have email addresses that you can retrieve from
anywhere you please. There’s a mailing list for request, albeit very
lightly trafficked, and there’s twitter. Further, I’m disappointed that
you felt it appropriate or necessary to result to personal attacks on this
list. At the very least you could have contained those to Twitter like
others in this thread have done. I expected a more civil response on the
openstack-dev mailing list.

Cheers,
Ian

On 9/21/14, 7:21 AM, "Thomas Goirand"  wrote:

>Hi Ian and Donald,
>
>I've read the full thread, and couldn't help to reply to it still, even
>though I previously thought I shouldn't, as what I care is OpenStack,
>not really requests, and more largely, the topic of the wrong reasons
>why upstream are embedding foreign library code copies. I completely
>agree with someone else who wrote that this thread is nearly
>uninteresting for OpenStack itself. However, it is IMO my role, as a
>package maintainer, to let you know about my view on your argumentation.
>
>If you ignore my argumentation, then at least I'll have tried! :)
>
>On 09/18/2014 03:42 AM, Ian Cordasco wrote:
>> Circling back to the issue of vendoring though: it’s a conscious
>>decision
>> to do this, and in the last two years there have been 2 CVEs reported
>>for
>> requests. There have been none for urllib3 and none for chardet.
>>(Frankly
>> I don’t think either urllib3 or chardet have had any CVEs reported
>>against
>> them, but let’s ignore that for now.) While security is typically the
>> chief concern with vendoring, none of the libraries we use have had
>> security issues rendering it a moot point in my opinion. The benefits of
>> vendoring for us as a team have been numerous and we will likely
>>continue
>> to do it until it stops benefiting us and our users.
>
>Could you please list the benefits *for end users*? I'm really saying
>users, as in, not developers. Because I don't see any benefit at all for
>the end users. I don't think any of them would like to see many version
>of the same thing on their system.
>
>Also, the issue is not only security. Let me give you an example. Simply
>do this in a Debian sid machine:
>
>apt-file search six.py | grep -v python3 | grep -v pyshared | wc -l
>
>We have in Debian, about 50 versions of six.py around, embedded in
>packages. And this doesn't even counts those where only bits of six are
>just embedded in a file which isn't called six.py.
>
>Of course, we (in Debian) would like them to be removed. Why? Because
>it's a useless complexity, with so many different version, some with
>embedded bugs which have been fixed upstream, and the like. That's not
>even about security at this point (I hardly would see how six.py would
>have security issue).
>
>There is also a waste of server resources (install time, size of
>packages in the Debian archive, increased download time, RAM footprint
>of everything, etc.). We don't need to install (and compile as .pyc at
>install time) 50 versions of six.py, a single one is enough. We're
>trying to address this as much as we can, and you'll see lots of
>packages were we did, but it's not always easy for various reasons, like
>upstream code not up-to-date with latest version, or lack of time from
>the Debian package maintainer.
>
>Also, consider the fact that six is small: a quite small single file.
>It's still unacceptable from a Unix distribution stand point, but this
>makes the "vendorizing" less of an absurdity. Now, for urllib3, it's a
>WAY bigger. There's about 25 Python files. So multiply the resulting
>waste and issues...
>
>This was a simple example for six. Now just generalize to all. There's
>numerous upstream authors who also think that it's ok, and they can be
>one of the few exception. But really, every upstream who does this think
>that he's "special". That's not the case. Requests isn't more special
>than any other Python module.
>
>On 09/18/2014 04:31 AM, Ian Cordasco wrote:
>> Isn’t the whole point of distributing a library to let people use it
>> as they see fit?
>
>The point of a library, is that it is shared among multiple consumers.
>Oh, maybe not if you're using Windows, but that's maybe out of the scope
>of this debate. Maintaining a coherent distribution with a single
>version of every library, is what distributions do as much as possible.
>It is unfortunately not always possible, but we do it as much as we can.
>
>On 09/18/2014 04:31 AM, Ian Cordasco wrote:
>> Project X pins a version of requests. Alice doesn’t know anything
>> about requests and does pip install X. Until Alice takes a more
>> active role in the development of Project X and looks into requests,
>> she will never know she’s installed software that has exposures in
>> it. In all likel

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

[Jay Pipes]

On 09/21/2014 11:30 AM, Ian Cordasco wrote:

Hi Thomas,

Several people, many of whom are core contributors to other projects, have
asked that this discussion not be continued in this venue. Discussion of
the decisions of the core-developers of requests are not appropriate for
this list. All three of us have email addresses that you can retrieve from
anywhere you please. There’s a mailing list for request, albeit very
lightly trafficked, and there’s twitter. Further, I’m disappointed that
you felt it appropriate or necessary to result to personal attacks on this
list. At the very least you could have contained those to Twitter like
others in this thread have done. I expected a more civil response on the
openstack-dev mailing list.


For those of us interested in this conversation, I ask that whatever 
decisions (if any) that come out of those discussions, that somebody 
please do post to the openstack-dev ML a summary of those decisions or 
actions.


Thanks much in advance,
-jay

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

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

[Dolph Mathews]

Querying keystone for tenant names is certainly fair game.

Keystone should be considered the only source of truth for tenant names
though, as they are mutable and not globally unique on their own, so other
services should not stash any names from keystone into long term
persistence (users, projects, domains, groups, etc-- roles might be an odd
outlier worth a separate conversation if anyone is interested).

Store IDs where necessary, and use IDs on the wire where possible though,
as they are immutable.

On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton  wrote:

> Hello all,
>
> A patch has come up to query keystone for tenant names in the IBM
> plugin.[1] As I understand it, this was one of the reasons another
> mechanism driver was reverted.[2] Can we get some clarity on the level
> of integration with Keystone that is permitted?
>
> Thanks
>
> 1. https://review.openstack.org/#/c/122382
> 2. https://review.openstack.org/#/c/118456
>
> --
> Kevin Benton
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

[Kevin Benton]

So based on those guidelines there would be a problem with the IBM patch
because it's storing the tenant name in a backend controller, right?
On Sep 21, 2014 12:18 PM, "Dolph Mathews"  wrote:

> Querying keystone for tenant names is certainly fair game.
>
> Keystone should be considered the only source of truth for tenant names
> though, as they are mutable and not globally unique on their own, so other
> services should not stash any names from keystone into long term
> persistence (users, projects, domains, groups, etc-- roles might be an odd
> outlier worth a separate conversation if anyone is interested).
>
> Store IDs where necessary, and use IDs on the wire where possible though,
> as they are immutable.
>
> On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton  wrote:
>
>> Hello all,
>>
>> A patch has come up to query keystone for tenant names in the IBM
>> plugin.[1] As I understand it, this was one of the reasons another
>> mechanism driver was reverted.[2] Can we get some clarity on the level
>> of integration with Keystone that is permitted?
>>
>> Thanks
>>
>> 1. https://review.openstack.org/#/c/122382
>> 2. https://review.openstack.org/#/c/118456
>>
>> --
>> Kevin Benton
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] devstack - horizon dashboard issues

[Alex Leonhardt]

Hi guys,

trying to get a devstack up and running, on a VM, but I keep getting this:

Error during template rendering

In template
/opt/stack/horizon/openstack_dashboard/templates/context_selection/_project_list.html,
error at line *7*
Reverse for ''switch_tenants'' with arguments
'(u'ca0fd29936a649e59850d7bb8c17e44c',)' and keyword arguments '{}' not
found.

Any pointers ?

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

Re: [openstack-dev] [Heat] naming of provider template for docs

[Angus Salkeld]

Thanks for the suggestions, I'll give that patch another crack.

-Angus

On Sat, Sep 20, 2014 at 10:11 AM, Qiming Teng 
wrote:

> On Fri, Sep 19, 2014 at 11:20:43AM +0200, Thomas Spatzier wrote:
> > > From: Mike Spreitzer 
> > > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > > 
> > > Date: 19/09/2014 07:15
> > > Subject: Re: [openstack-dev] [Heat] naming of provider template for
> docs
> > >
> > > Angus Salkeld  wrote on 09/18/2014 09:33:56 PM:
> > >
> > > > Hi
> > >
> > > > I am trying to add some docs to openstack-manuals hot_guide about
> > > > using provider templates : https://review.openstack.org/#/c/121741/
> > >
> > > > Mike has suggested we use a different term, he thinks "provider" is
> > > > confusing.
> > > > I agree that at the minimum, it is not very descriptive.
> > >
> > > > Mike has suggested "nested stack", I personally think this means
> > > something a
> > > > bit more general to many of us (it includes the concept of aws
> > > stacks) and may
> > > > I suggest "template resource" - note this is even the class name for
> > > > this exact functionality.
> > > >
> > > > Thoughts?
> > >
> > > > Option 1) stay as is "provider templates"
> > > > Option 2) "nested stack"
> > > > Option 3) "template resource"
> >
> > Out of those 3 I like #3 the most, even though not perfect as Mike
> > discussed below.
>
> > >
> > > Thanks for rising to the documentation challenge and trying to get
> > > good terminology.
> > >
> > > I think your intent is to describe a category of resources, so your
> > > option 3 is superior to option 1 --- the thing being described is
> > > not a template, it is a resource (made from a template).
> > >
> > > I think
> > >
> > > Option 4) "custom resource"
> >
> > That one sound too generic to me, since also custom python based resource
> > plugins are custom resources.
>
> +1.
>
> 'Custom resource' may cause more confusion.
>
> > >
> > > would be even better.  My problem with "template resource" is that,
> > > to someone who does not already know what it means, this looks like
> > > it might be a kind of resource that is a template (e.g., for
> > > consumption by some other resource that does something with a
> > > template), rather than itself being something made from a template.
> > > If you want to follow this direction to something perfectly clear,
> > > you might try "templated resource" (which is a little better) or
> > > "template-based resource" (which I think is pretty clear but a bit
> > > wordy) --- but an AWS::CloudFormation::Stack is also based on a
> > > template.  I think that if you try for a name that really says all
> > > of the critical parts of the idea, you will get something that is
> > > too wordy and/or awkward.  It is true that "custom resource" begs
> > > the question of how the user accomplishes her customization, but at
> > > least now we have the reader asking the right question instead of
> > > being misled.
> >
> > I think "template-based resource" really captures the concept best. And
> it
> > is not too wordy IMO.
> > If it helps to explain the concept intuitively, I would be in favor of
> it.
>
> Agreed. If it sounds too wordy, just use 'template resource' would be
> okay.
>
> > Regards,
> > Thomas
> >
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] Announcing my candidacy for PTL

[Angus Salkeld]

I would like to announce my candidacy for the position of Orchestration PTL.

After contributing to Heat since it was created, I feel like I know what
Heat is and can do.
We have some really big challenges ahead to ensure that Heat is scalable
and stays relevant.

The big issues for Heat that I want to focus on are:

The TripleO project have used Heat extensively and found it to be lacking
in a number of
areas, I believe that this is great feedback that we need to respond to
very quickly.
We are starting some of this (the convergence work) but I'd like to get
more involved with this
to make sure we can get to a solution in a timely manner.

How do other projects that have been working hard in the orchestration area
(TOSCA, Murano and Mistral) fit into OpenStack, and in particular, how they
integrate
with Heat and the Orchestration program. There is obviously lots of talk in
this area
(tent sizes), but I think we need to start looking forward to understand
how these
projects could fit together to form a cohesive product for OpenStack.

How do we integrate better with existing OpenSource orchestration tools
that users
are familiar with using. Hopefully OpenStack orchestration does not begin
and end
with a CloudFormation based solution. I look forward to some fun
discussions in this
area;)

In conclusion these are exciting times for OpenStack and in particular
Orchestration.
I'd love the opportunity to face these challenges head on with our great
community.


Regards
Angus Salkeld
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

[Matt Riedemann]

On 9/19/2014 8:13 AM, Sean Dague wrote:

I've spent the better part of the last 2 weeks in the Nova bug tracker
to try to turn it into something that doesn't cause people to run away
screaming. I don't remember exactly where we started at open bug count 2
weeks ago (it was north of 1400, with > 200 bugs in new, but it might
have been north of 1600), but as of this email we're at < 1000 open bugs
(I'm counting Fix Committed as closed, even though LP does not), and ~0
new bugs (depending on the time of the day).

== Philosophy in Triaging ==

I'm going to lay out the philosophy of triaging I've had, because this
may also set the tone going forward.

A bug tracker is a tool to help us make a better release. It does not
exist for it's own good, it exists to help. Which means when evaluating
what stays in and what leaves we need to evaluate if any particular
artifact will help us make a better release. But also more importantly
realize that there is a cost for carrying every artifact in the tracker.
Resolving duplicates gets non linearly harder as the number of artifacts
go up. Triaging gets non-linearly hard as the number of artifacts go up.

With this I was being somewhat pragmatic about closing bugs. An old bug
that is just a stacktrace is typically not useful. An old bug that is a
vague sentence that we should refactor a particular module (with no
specifics on the details) is not useful. A bug reported against a very
old version of OpenStack where the code has changed a lot in the
relevant area, and there aren't responses from the author, is not
useful. Not useful bugs just add debt, and we should get rid of them.
That makes the chance of pulling a random bug off the tracker something
that you could actually look at fixing, instead of mostly just stalling out.

So I closed a lot of stuff as Invalid / Opinion that fell into those camps.

== Keeping New Bugs at close to 0 ==

After driving the bugs in the New state down to zero last week, I found
it's actually pretty easy to keep it at 0.

We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20%
aren't actually a bug, and can be closed immediately. ~30% look like a
bug, but don't have anywhere near enough information in them, and
flipping them to incomplete with questions quickly means we have a real
chance of getting the right info. ~10% are fixable in < 30 minutes worth
of work. And the rest are real bugs, that seem to have enough to dive
into it, and can be triaged into Confirmed, set a priority, and add the
appropriate tags for the area.

But, more importantly, this means we can filter bug quality on the way
in. And we can also encourage bug reporters that are giving us good
stuff, or even easy stuff, as we respond quickly.

Recommendation #1: we adopt a 0 new bugs policy to keep this from
getting away from us in the future.

== Our worse bug reporters are often core reviewers ==

I'm going to pick on Dan Prince here, mostly because I have a recent
concrete example, however in triaging the bug queue much of the core
team is to blame (including myself).

https://bugs.launchpad.net/nova/+bug/1368773 is a terrible bug. Also, it
was set incomplete and no response. I'm almost 100% sure it's a dupe of
the multiprocess bug we've been tracking down but it's so terse that you
can't get to the bottom of it.

There were a ton of 2012 nova bugs that were basically "post it notes".
Oh, "we should refactor this function". Full stop. While those are fine
for personal tracking, their value goes to zero probably 3 months after
they are files, especially if the reporter stops working on the issue at
hand. Nova has plenty of "wouldn't it be great if we... " ideas. I'm not
convinced using bugs for those is useful unless we go and close them out
aggressively if they stall.

Also, if Nova core can't file a good bug, it's hard to set the example
for others in our community.

Recommendation #2: hey, Nova core, lets be better about filing the kinds
of bugs we want to see! mkay!

Recommendation #3: Let's create a tag for "personal work items" or
something for these class of TODOs people are leaving themselves that
make them a ton easier to cull later when they stall and no one else has
enough context to pick them up.

== Tags ==

The aggressive tagging that Tracy brought into the project has been
awesome. It definitely helps slice out into better functional areas.
Here is the top of our current official tag list (and bug count):

95 compute
83 libvirt
74 api
68 vmware
67 network
41 db
40 testing
40 volumes
36 ec2
35 icehouse-backport-potential
32 low-hanging-fruit
31 xenserver
25 ironic
23 hyper-v
16 cells
14 scheduler
12 baremetal
9 ceph
9 security
8 oslo
...

So, good stuff. However I think we probably want to take a further step
and attempt to get champions for tags. So that tag owners would ensure
their bug list looks sane, and actually spend some time fixing them.
It's pretty clear, for instance, that the ec2 bugs are just piling up,
and very few fixes comin

Re: [openstack-dev] [nova] expected behaviour of _report_state() on rabbitmq failover

[Matt Riedemann]

On 9/10/2014 3:33 PM, Chris Friesen wrote:

On 09/10/2014 02:13 PM, Chris Friesen wrote:


As it stands, it seems that waiting for the RPC call to time out
blocks _report_state() from running again in report_interval seconds,
which delays the service update until the RPC timeout period expires.


Just noticed something...

In the case of _report_state(), does it really make sense to wait 60
seconds for RPC timeout when we're going to send a new service update in
10 seconds anyway?

More generally, the RPC timeout on the service_update() call should be
less than or equal to service.report_interval for the service.

Chris

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



Maybe completely unrelated, but FYI while you're looking at this code path:

https://bugs.launchpad.net/neutron/+bug/1357055

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova] expected behaviour of _report_state() on rabbitmq failover

[Matt Riedemann]

On 9/21/2014 7:56 PM, Matt Riedemann wrote:



On 9/10/2014 3:33 PM, Chris Friesen wrote:

On 09/10/2014 02:13 PM, Chris Friesen wrote:


As it stands, it seems that waiting for the RPC call to time out
blocks _report_state() from running again in report_interval seconds,
which delays the service update until the RPC timeout period expires.


Just noticed something...

In the case of _report_state(), does it really make sense to wait 60
seconds for RPC timeout when we're going to send a new service update in
10 seconds anyway?

More generally, the RPC timeout on the service_update() call should be
less than or equal to service.report_interval for the service.

Chris

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



Maybe completely unrelated, but FYI while you're looking at this code path:

https://bugs.launchpad.net/neutron/+bug/1357055



Oops, completely wrong bug.  Here is the correct one:

https://bugs.launchpad.net/nova/+bug/1331537

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Heat] Announcing my candidacy for PTL

[Tristan Cacqueray]

confirmed

On 21/09/14 08:15 PM, Angus Salkeld wrote:
> I would like to announce my candidacy for the position of Orchestration PTL.
> 
> After contributing to Heat since it was created, I feel like I know what
> Heat is and can do.
> We have some really big challenges ahead to ensure that Heat is scalable
> and stays relevant.
> 
> The big issues for Heat that I want to focus on are:
> 
> The TripleO project have used Heat extensively and found it to be lacking
> in a number of
> areas, I believe that this is great feedback that we need to respond to
> very quickly.
> We are starting some of this (the convergence work) but I'd like to get
> more involved with this
> to make sure we can get to a solution in a timely manner.
> 
> How do other projects that have been working hard in the orchestration area
> (TOSCA, Murano and Mistral) fit into OpenStack, and in particular, how they
> integrate
> with Heat and the Orchestration program. There is obviously lots of talk in
> this area
> (tent sizes), but I think we need to start looking forward to understand
> how these
> projects could fit together to form a cohesive product for OpenStack.
> 
> How do we integrate better with existing OpenSource orchestration tools
> that users
> are familiar with using. Hopefully OpenStack orchestration does not begin
> and end
> with a CloudFormation based solution. I look forward to some fun
> discussions in this
> area;)
> 
> In conclusion these are exciting times for OpenStack and in particular
> Orchestration.
> I'd love the opportunity to face these challenges head on with our great
> community.
> 
> 
> Regards
> Angus Salkeld
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

[Adam Young]

On 09/19/2014 01:43 PM, Doug Hellmann wrote:

On Sep 19, 2014, at 6:56 AM, David Chadwick  wrote:



On 18/09/2014 22:14, Doug Hellmann wrote:

On Sep 18, 2014, at 4:34 PM, David Chadwick 
wrote:



On 18/09/2014 21:04, Doug Hellmann wrote:

On Sep 18, 2014, at 12:36 PM, David Chadwick
 wrote:


Our recent work on federation suggests we need an improvement
to the way the policy engine works. My understanding is that
most functions are protected by the policy engine, but some are
not. The latter functions are publicly accessible. But there is
no way in the policy engine to specify public access to a
function and there ought to be. This will allow an
administrator to configure the policy for a function to range
from very lax (publicly accessible) to very strict (admin
only). A policy of "" means that any authenticated user can
access the function. But there is no way in the policy to
specify that an unauthenticated user (i.e. public) has access
to a function.

We have already identified one function (get trusted IdPs
"identity:list_identity_providers") that needs to be publicly
accessible in order for users to choose which IdP to use for
federated login. However some organisations may not wish to
make this API call publicly accessible, whilst others may wish
to restrict it to Horizon only etc. This indicates that that
the policy needs to be set by the administrator, and not by
changes to the code (i.e. to either call the policy engine or
not, or to have two different API calls).

I don’t know what list_identity_providers does.

it lists the IDPs that Keystone trusts to authenticate users


Can you give a little more detail about why some providers would
want to make it not public

I am not convinced that many cloud services will want to keep this
list secret. Today if you do federated login, the public web page
of the service provider typically lists the logos or names of its
trusted IDPs (usually Facebook and Google). Also all academic
federations publish their full lists of IdPs. But it has been
suggested that some commercial cloud providers may not wish to
publicise this list and instead require the end users to know which
IDP they are going to use for federated login. In which case the
list should not be public.



if we plan to make it public by default? If we think there’s a
security issue, shouldn’t we just protect it?


Its more a commercial in confidence issue (I dont want the world to
know who I have agreements with) rather than a security issue,
since the IDPs are typically already well known and already protect
themselves against attacks from hackers on the Internet.

OK. The weak “someone might want to” requirement aside, and again
showing my ignorance of implementation details, do we truly have to
add a new feature to disable the policy check? Is there no way to
have an “always allow” policy using the current syntax?

You tell me. If there is, then problem solved. If not, then my request
still stands

 From looking at the code, it appears that something like True:”True” (or 
possibly True:True) would always pass, but I haven’t tested that.


Nope;  it errors out before it ever gets to the policy check, when it 
unpacks the token.


Doug


regards

David


Doug


regards

David


If we can invent some policy syntax that indicates public
access, e.g. reserved keyword of public, then Keystone can
always call the policy file for every function and there would
be no need to differentiate between protected APIs and
non-protected APIs as all would be protected to a greater or
lesser extent according to the administrator's policy.

Comments please

It seems reasonable to have a way to mark a function as fully
public, if we expect to really have those kinds of functions.

Doug


regards

David






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




___ OpenStack-dev mailing

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




___

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


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


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


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



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listi

[openstack-dev] About the question "Switch firewall_driver control from Neutron to Nova"

[Tien-Trung Trinh]

Dear OpenStack-dev,

 

I've posted a question on
https://ask.openstack.org/en/question/47819/switch-firewall_driver-control-f
rom-neutron-to-nova/ 

It's suggested that I should forward this question to OpenStack-dev mailing
list for discussion.

 

Any feedback/answer would be very appreciated.

 

Thanks and regards

Trung

 

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

[openstack-dev] pycharm license?

[Manickam, Kanagaraj]

Hi,

Does anyone has pycharm license for openstack project development? Thanks.

Regards
Kanagaraj M
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO][elections] Not running as PTL this cycle

[Robert Collins]

I'm not running as PTL for the TripleO program this cycle.

There are a couple of reasons for this. Firstly, I think its good for
intense multi-year efforts like we're all involved in here to have
leadership spread around: for the folk wearing the leadership hat, its
hard work keeping everything paged in all the time, and folk can
easily burn out. I don't like burning out :). For projects, having
folk that have different views avoids us getting stuck in a rut and
increases experimentation and learning, IME.

Secondly, I joined OpenStack to help it move forward as a whole, but
I've done relatively little other than deployment - and we've
consistently hit limitations and issues outside of the deployment code
- in all sorts of areas - testing, performance, other APIs and so on.
I personally feel a need to correct this - I'm currently running into
the risk of myopia, solving things just in the deployment context, and
I need to do better than that :).

I look forward to other TripleO folk putting their hat into the ring -
I'll support whoever wins in anyway I can, and I'm still going to be
here hacking on TripleO and reviewing what folk are working on:)

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

[Nader Lahouti]

Thanks Kevin for bring it up in the ML, I was looking for a guideline or
any document to clarify issues on this subject.

I was told, even using keystone API in neutron is not permitted.

Thanks,
Nader.


On Sun, Sep 21, 2014 at 12:58 PM, Kevin Benton  wrote:

> So based on those guidelines there would be a problem with the IBM patch
> because it's storing the tenant name in a backend controller, right?
> On Sep 21, 2014 12:18 PM, "Dolph Mathews"  wrote:
>
>> Querying keystone for tenant names is certainly fair game.
>>
>> Keystone should be considered the only source of truth for tenant names
>> though, as they are mutable and not globally unique on their own, so other
>> services should not stash any names from keystone into long term
>> persistence (users, projects, domains, groups, etc-- roles might be an odd
>> outlier worth a separate conversation if anyone is interested).
>>
>> Store IDs where necessary, and use IDs on the wire where possible though,
>> as they are immutable.
>>
>> On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton  wrote:
>>
>>> Hello all,
>>>
>>> A patch has come up to query keystone for tenant names in the IBM
>>> plugin.[1] As I understand it, this was one of the reasons another
>>> mechanism driver was reverted.[2] Can we get some clarity on the level
>>> of integration with Keystone that is permitted?
>>>
>>> Thanks
>>>
>>> 1. https://review.openstack.org/#/c/122382
>>> 2. https://review.openstack.org/#/c/118456
>>>
>>> --
>>> Kevin Benton
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] ./run_tests issue

[Deepak Shetty]

Thats incorrect, as i said in my original mail.. I am usign devstack+manila
and it wasn't very clear to me that mysql-devel needs to be installed and
it didn't get installed. I am on F20, not sure if that causes this , if
yes, then we need to debug and fix this.

Maybe its a good idea to put a comment in requirements.txt statign that the
following C libs needs to be installed for  the venv to work smoothly. That
would help too for the short term.

On Sun, Sep 21, 2014 at 12:12 PM, Valeriy Ponomaryov <
vponomar...@mirantis.com> wrote:

> Dep "MySQL-python" is already in test-requirements.txt file. As Andreas
> said, second one "mysql-devel" is C lib and can not be installed via pip.
> So, project itself, as all projects in OpenStack, can not install it.
>
> C lib deps are handled by Devstack, if it is used. See:
> https://github.com/openstack-dev/devstack/tree/master/files/rpms
>
> https://github.com/openstack-dev/devstack/blob/2f27a0ed3c609bfcd6344a55c121e56d5569afc9/functions-common#L895
>
> Yes, Manila could have its files in the same way in
> https://github.com/openstack/manila/tree/master/contrib/devstack , but
> this lib is already exist in deps for other projects. So, I guess you used
> Manila "run_tests.sh" file on host without devstack installation, in that
> case all other projects would fail in the same way.
>
> On Sun, Sep 21, 2014 at 2:54 AM, Alex Leonhardt 
> wrote:
>
>> And yet it's a dependency so I'm with Deepak and it should at least be
>> mentioned in the prerequisites on a webpage somewhere .. :) I might even
>> try and update/add that myself as it caught me out a few times too..
>>
>> Alex
>>  On 20 Sep 2014 12:44, "Andreas Jaeger"  wrote:
>>
>>> On 09/20/2014 09:34 AM, Deepak Shetty wrote:
>>> > thanks , that worked.
>>> > Any idea why it doesn't install it automatically and/or it isn't
>>> present
>>> > in requirements.txt ?
>>> > I thought that was the purpose of requirements.txt ?
>>>
>>> AFAIU requirements.txt has only python dependencies while
>>> mysql-devel is a C development package,
>>>
>>> Andreas
>>> --
>>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>>>   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>>GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
>>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomar...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] ./run_tests issue

[Deepak Shetty]

Even better, whenever ./run_tests fail... maybe put a msg stating the
following C libs needs to be installed, have the user check the
same..something like that would help too.

On Mon, Sep 22, 2014 at 11:59 AM, Deepak Shetty  wrote:

> Thats incorrect, as i said in my original mail.. I am usign
> devstack+manila and it wasn't very clear to me that mysql-devel needs to be
> installed and it didn't get installed. I am on F20, not sure if that causes
> this , if yes, then we need to debug and fix this.
>
> Maybe its a good idea to put a comment in requirements.txt statign that
> the following C libs needs to be installed for  the venv to work smoothly.
> That would help too for the short term.
>
> On Sun, Sep 21, 2014 at 12:12 PM, Valeriy Ponomaryov <
> vponomar...@mirantis.com> wrote:
>
>> Dep "MySQL-python" is already in test-requirements.txt file. As Andreas
>> said, second one "mysql-devel" is C lib and can not be installed via
>> pip. So, project itself, as all projects in OpenStack, can not install it.
>>
>> C lib deps are handled by Devstack, if it is used. See:
>> https://github.com/openstack-dev/devstack/tree/master/files/rpms
>>
>> https://github.com/openstack-dev/devstack/blob/2f27a0ed3c609bfcd6344a55c121e56d5569afc9/functions-common#L895
>>
>> Yes, Manila could have its files in the same way in
>> https://github.com/openstack/manila/tree/master/contrib/devstack , but
>> this lib is already exist in deps for other projects. So, I guess you used
>> Manila "run_tests.sh" file on host without devstack installation, in that
>> case all other projects would fail in the same way.
>>
>> On Sun, Sep 21, 2014 at 2:54 AM, Alex Leonhardt 
>> wrote:
>>
>>> And yet it's a dependency so I'm with Deepak and it should at least be
>>> mentioned in the prerequisites on a webpage somewhere .. :) I might even
>>> try and update/add that myself as it caught me out a few times too..
>>>
>>> Alex
>>>  On 20 Sep 2014 12:44, "Andreas Jaeger"  wrote:
>>>
 On 09/20/2014 09:34 AM, Deepak Shetty wrote:
 > thanks , that worked.
 > Any idea why it doesn't install it automatically and/or it isn't
 present
 > in requirements.txt ?
 > I thought that was the purpose of requirements.txt ?

 AFAIU requirements.txt has only python dependencies while
 mysql-devel is a C development package,

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

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

>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kind Regards
>> Valeriy Ponomaryov
>> www.mirantis.com
>> vponomar...@mirantis.com
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Design Summit planning

[Tom Fifield]

On 18/09/14 16:03, Thierry Carrez wrote:
> Maish Saidel-Keesing wrote:
>> On 17/09/2014 23:12, Anita Kuno wrote:
>>> On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote:
 This looks great - but I am afraid that something might be missing.

 As part of the Design summit in Atlanta there was an Ops Meetup track.
 [1] I do not see where this fits into the current planning process that
 has been posted.
 I would like to assume that part of the purpose of the summit is to also
 collect feedback from Enterprise Operators and also from smaller ones as
 well.

 If that is so then I would kindly request that there be some other way
 of allowing that part of the community to voice their concerns, and
 provide feedback.

 Perhaps a track that is not only Operator centric - but also an End-user
 focused one as well (mixing the two would be fine as well)

 Most of them are not on the openstack-dev list and they do not
 participate in the IRC team meetings, simply because they have no idea
 that these exist or maybe do not feel comfortable there. So they will
 not have any exposure to the process.

 My 0.02 Shekels.

 [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup

>>> Hi Maish:
>>>
>>> This thread is about the Design Summit, the Operators Track is a
>>> different thing.
>>>
>>> In Atlanta the Operators Track was organized by Tom Fifield and I have
>>> every confidence he is working hard to ensure the operators have a voice
>>> in Paris and that those interested can participate.
>>>
>>> Last summit the Operators Track ran on the Monday and the Friday giving
>>> folks who usually spend most of the time at the Design summit to
>>> participate and hear the operator's voices. I know I did and I found it
>>> highly educational.
>>>
>>> Thanks,
>>> Anita.
>> Thanks for the clarification Anita :)
> 
> I think the plan is to have the Ops summit run on Monday, with an extra
> day on Thursday to continue the discussions. I CCed Tom for more input
> on that.


Sorry for the delay all, and thanks for the kind notes. The ops meetup
will indeed return in Paris. Standby for details and planning etherpad
any day now - on the openstack-operators mailing list.


Regards,


Tom


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

[openstack-dev] Group-Based Policy Understanding and Queries

[Sachi Gupta]

Hi All,

Request you all to provide inputs on below understanding:

Openstack: Group-based policy is a blueprint for Juno-3 release of 
Openstack. It will extend OpenStack Networking with policy and 
connectivity abstractions that enable significantly more simplified and 
application-oriented interfaces than with the current Neutron API model. 
When will be the code ready for Group-based policy as an open source?

Openstack group policy API will be an extension to the Neutron APIs. There 
will be a policy manager to manage the policy and policy rules. Will GBP a 
part of neutron?? If yes, then will GBP be a part of Horizon under 
neutron?

Policy driver which will act as an interface(ODL Policy Driver). For eg. 
we used neutron ML2 plugin as an interface between Openstack neutron and 
ODL neutron northbound. When will the policy driver for ODL available?

Openstack policy driver for ODL will act as an interface to ODL. Which API 
in ODL, Policy calls from Openstack ODL Policy driver will be hitting??


Thanks & Regards
Sachi Gupta
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

[openstack-dev] [Zaqar] PTL Candidacy

[Flavio Percoco]

Greetings,

I'd like to announce my candidacy for the Message Program PTL position.

I've been part of this program since its inception. Along with a really
amazing team, I've been working on changing the openstack messaging
service reality for the last 2 years.

Zaqar has a set of features that I consider essential for different use
cases. However, some of this features are very specific and could be
supported differently.

Therefore, my focus for the next cycle will be working on shrinking
Zaqar's feature set down to what's really essential for most of the use
cases.

In addition to the above, I'd like to focus on expanding Zaqar's
adoption by starting from the world it belongs to, OpenStack. We've
identified a set of projects and use-cases that we need/can cover. I
believe working together with those projects will help Zaqar to improve
and the rest of the ecosystem.

Last but not least, I'm planning to dedicate extra time into supporting
our development community and make sure Zaqar's mission, vision, goals
and internals are clear to everyone. I believe we're all working in a
community full of very talented folks and the feedback from each one of
them has an immense value for the project, team and the rest of the
ecosystem.

Thanks for reading,
Flavio


-- 
@flaper87
Flavio Percoco

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