Re: [openstack-dev] [all][monasca] pysnmp autogenerated code

[Ilya Etingof]

On 05/10/2018 05:01 PM, Stefano Canepa wrote:
> 
> On 10 May 2018 at 10:55, Ilya Etingof  > wrote:
> 
> 
> Hi Stefano,
> 
> The best solution would be of course to fix pysmi code generator [1] to
> behave. ;-)
> 
> 
> ​This is something that pysmi author already gives for granted in the
> Release notes.
> I bet you know this better then me ;-)​
>  
>  
> 
> On the other hand, if you won't include the autogenerated code into your
> package, the code generation would happen just once at run time - the
> autogenerated module would get cached on the file system and loaded from
> there ever after.
> 
> Theoretically, not pinning Python MIB in your package has an advantage
> of letting pysmi pulling newer ASN.1 MIB and turning it into Python
> whenever newer MIB revision becomes available.
> 
> 
> ​Ilya you're confusing me. Do you mean that, even if I load my MIB and
> all other it depends on from ASN.1, they are compiled into python byte
> code and cached and blah blah? ​

The workflow is this:

* pysnmp wants to load a MY-MIB by name (e.g. evaluate the contents of
MY-MIB.py, turn it into Python objects and link them up to its in-memory
MIB tree)
* pysnmp searches for MY-MIB.py[co] in its search path
* if pysnmp is successful, we are done
* if pysnmp does not find MY-MIB.py[co] and pysmi package is present,
pysnmp calls pysmi with MY-MIB name on input
* pysmi tries to find MY-MIB (e.g. in ASN.1 form) in its search path
(possibly including remote locations), compile it into MY-MIB.py[co] and
cache it somewhere within pysnmp search path
* if pysmi is successful, pysnmp starts over loading MY-MIB.py[co]

Hope this is helpful. ;)

__
OpenStack Development Mailing 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][monasca] pysnmp autogenerated code

[Stefano Canepa]

On 11 May 2018 at 08:26, Ilya Etingof  wrote:

> On 05/10/2018 05:01 PM, Stefano Canepa wrote:
> >
> > On 10 May 2018 at 10:55, Ilya Etingof  > > wrote:
> >
> >
> > Hi Stefano,
> >
> > The best solution would be of course to fix pysmi code generator [1]
> to
> > behave. ;-)
> >
> >
> > ​This is something that pysmi author already gives for granted in the
> > Release notes.
> > I bet you know this better then me ;-)​
> >
> >
> >
> > On the other hand, if you won't include the autogenerated code into
> your
> > package, the code generation would happen just once at run time - the
> > autogenerated module would get cached on the file system and loaded
> from
> > there ever after.
> >
> > Theoretically, not pinning Python MIB in your package has an
> advantage
> > of letting pysmi pulling newer ASN.1 MIB and turning it into Python
> > whenever newer MIB revision becomes available.
> >
> >
> > ​Ilya you're confusing me. Do you mean that, even if I load my MIB and
> > all other it depends on from ASN.1, they are compiled into python byte
> > code and cached and blah blah? ​
>
> The workflow is this:
>
> * pysnmp wants to load a MY-MIB by name (e.g. evaluate the contents of
> MY-MIB.py, turn it into Python objects and link them up to its in-memory
> MIB tree)
> * pysnmp searches for MY-MIB.py[co] in its search path
> * if pysnmp is successful, we are done
> * if pysnmp does not find MY-MIB.py[co] and pysmi package is present,
> pysnmp calls pysmi with MY-MIB name on input
> * pysmi tries to find MY-MIB (e.g. in ASN.1 form) in its search path
> (possibly including remote locations), compile it into MY-MIB.py[co] and
> cache it somewhere within pysnmp search path
> * if pysmi is successful, pysnmp starts over loading MY-MIB.py[co]
>
> Hope this is helpful. ;)
>

Super helpful.

Copy this into my notebook for future reference.

All the best
Stefano

​
__
OpenStack Development Mailing 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] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Zane Bitter wrote:
> [...]
> How can we avoid (or get out of) the local maximum trap and ensure that
> OpenStack will meet the needs of all the users we want to serve, not
> just those whose needs are similar to those of the users we already have?

It'a a good question, and a topic I raised a couple years ago.

Back then we had (and we arguably still have) a critical mass of
medium-sized private clouds, which makes most contributions gravitate to
that middle area of the potential usage spectrum.

But for the success of OpenStack we need the two extremes to be served:
the "giant public cloud" use case (because we all need that giant public
cloud to burst infinite capacity to in hybrid scenarios), but also the
"lab deployment" use case because that's a great on-boarding tool.
Currently it's still too complex to use OpenStack in those two ends of
the use case spectrum.

How do we solve that ? We can't rely on natural open collaboration
dynamics ("show up and be the change you want to see in the world") --
that one will continue to feed the medium use case. We can continue to
wait for proponents of the "small deployment" or the "massive public
cloud" to suddenly invest hundreds of FTEs to cover their use case. Or
we can be aware of the local maximum trap, go a bit out of our ways to
serve both ends of the spectrum, and realize that it puts us in a lot
better place.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [nova] [placement] placement update 18-19

[Chris Dent]

HTML: https://anticdent.org/placement-update-18-19.html

This is placement update 18-19. 18 was skipped because I was on
holiday. With this issue I'm going to start cross-posting to my blog
to increase exposure, double up the archiving, and get the content
showing up on the OpenStack [Planet](http://planet.openstack.org/).

One upshot of this change is that the content will now be formatted
more fully as Markdown.

I'll be travelling next week so there won't be one of these for weeks
20 or 21, unless someone else feels like it.

# Most Important

We're continuing to hope that granular and nested resource providers
will be fully merged by Summit (a bit more than a week from now).
Not clear if this will happen as last I checked it seemed we have
multiple threads of changes in progress, many of which will merge
conflict with one another. But then again, I may be out of date,
it's been difficult to find all those threads while trying to catch
up this week.

If you're going to be at summit there are (at least) two
placement-related forum sessions:

* 
* 

Please add to those etherpads if you have thoughts.

Also a summit, Ed and Eric will be presenting [Placement, Present
and Future, in Nova and
Beyond](https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/20813/placement-present-and-future-in-nova-and-beyond).

# What's Changed

Granular requests can now be made to GET /allocation_candidates
(meaning resourcesN and requiredN are now accepted). A bug with the
safe_connect handler masking real problems has been fixed. The spec
for [Network Bandwidth Resource
Provider](https://review.openstack.org/#/c/502306/) has finally
merged after a lot of thinking and discussion. The spec for [Return
resources of entire trees in
Placement](https://review.openstack.org/#/c/559466/) has merged.
This allows the inclusion of resource providers which are not
providing inventory, but are part of the current tree, in the provider
summaries of a /allocation_candidates response.

There are some new specs (see the end of the specs list, below)
which extend required traits handling to be able to say "I need
at least one of these traits".

# Bugs

* Placement related [bugs not yet in
  progress](https://goo.gl/TgiPXb): 16, -1 on two weeks ago
* [In progress placement bugs](https://goo.gl/vzGGDQ) 10, +2 two
  weeks ago

# Specs

Total two weeks ago: 11. Now: 13

* 
  VMware: place instances on resource pool (using update_provider_tree)

* 
  Proposes NUMA topology with RPs

* 
  Account for host agg allocation ratio in placement

* 
  Support default allocation ratios

* 
  Spec on preemptible servers

* 
  Proposes Multiple GPU types

* 
  Standardize CPU resource tracking

* 
  Propose counting quota usage from placement

* 
  Add history behind nullable project_id and user_id

* 
  update add-consumer-generation to focus on API

* 
  Placement: any traits in allocation_candidate query

* 
  Placement: support mixing required traits with any traits

* 
  [WIP] Support Placement in Cinder

# Main Themes

## Nested providers in allocation candidates

Unfortunately I'm really unclear on what the current state of this
is. If someone else can give a quick overview that would be
excellent. There's code in progress at both of the following topics,
some of it is old and in merge conflict:

* 

* 

## Mirror nova host aggregates to placement

This makes it so some kinds of aggregate filtering can be done
"placement side" by mirroring nova host aggregates into placement
aggregates.

* 

This is still in progress but is still on its attention break.

## Consumer Generations

This allows multiple agents to "safely" update allocations for a
single consumer. The code is in progress:

* 

There's also a related change for ensuring [consumer
records](https://review.openstack.org/#/c/567678/).

## Granular

Ways and means of addressing granular requests when dealing with
nested resource providers. Granular in this sense is grouping
resource classes and traits together in their own lumps 

Re: [openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Dmitry Tantsur]

Hi,

Funny, I was just about to ask you about it :) Jim is a former PTL, so I cannot 
see why we wouldn't add him to the stable team.


On 05/11/2018 01:50 PM, Julia Kreger wrote:

Greetings folks,

Is there any objection if we re-add Jim to the ironic-stable-maint
team?  He was a member prior to his brief departure and I think it
would be good to have another set of hands that can approve the
changes as three doesn't seem like quite enough when everyone is busy.

If there are no objections, I'll re-add him next week.


I don't remember if we actually can add people to these teams or it has to be 
done by the main stable team.




-Julia

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




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

Re: [openstack-dev] [neutron][ml2 plugin] unit test errors

[Neil Jerram]

On Fri, May 11, 2018 at 10:09 AM Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:

> So what you need to do first is to make a patch for networking-onos that
> does ONLY the following
>
>
> replace all occurrences of
>
> * neutron.callbacks  by neutron_lib.callbacks
> * neutron.plugins.ml2.driver_api by neutron_lib.plugins.ml2.api
>

FYI here's what networking-calico has for the second of these points:

try:
from neutron_lib.plugins.ml2 import api
except ImportError:
# Neutron code prior to a2c36d7e (10th November 2017).
from neutron.plugins.ml2 import driver_api as api

(
http://git.openstack.org/cgit/openstack/networking-calico/tree/networking_calico/plugins/ml2/drivers/calico/mech_calico.py#n49
)

However, we do it like this because we want the master networking-calico
code to work with many past Neutron releases, and I understand that that is
not a common approach; so for networking-onos you may only want the "from
neutron_lib.plugins.ml2 import api" line.

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

[openstack-dev] [kolla] Building Kolla containers with 3rd party vendor drivers

[Paul Bourke]

Hi Sandhya,

Thanks for starting this thread. I've moved it to the mailing list so 
the discussion can be available to anyone else who is interested, I hope 
you don't mind.


If your requirement is to have third party plugins (such as Cisco) that 
are not available on tarballs.openstack.org, available in Kolla, then 
this is already possible.


Using the Cisco case as an example, you would simply need to submit the 
following patch to 
https://github.com/openstack/kolla/blob/master/kolla/common/config.py


"""
'neutron-server-plugin-networking-cisco': {
'type': 'git',
'location': ('https://github.com/openstack/networking-cisco')},
"""

This will then include that plugin as part of the future neutron-server 
builds.


If the requirement is to have Kolla publish a neutron-server container 
with *only* the Cisco plugin, then this is where it gets a little more 
tricky. Sure, we can go the route that's proposed in your patch, but we 
end up then maintaining a massive number of neutron-server containers, 
one per plugin. It also does not address then the issue of what people 
want to do when they want a combination or mix of plugins together.


So right now I feel Kolla takes a middle ground, where we publish a 
neutron-server container with a variety of common plugins. If operators 
have specific requirements, they should create their own config file and 
build their own images, which we expect any serious production setup to 
be doing anyway.


-Paul

On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:

Yes, I think there is some misunderstanding on what I am trying to accomplish 
here.

I am utilizing existing Kolla constructs to prove that they work for 3rd party 
out of tree vendor drivers too.
At this point, anything that a 3rd party vendor driver does (the way they build 
their containers, where they publish it and how they generate config) is 
completely out of scope of Kolla.

I want to use the spec as a place to articulate and discuss best practices and 
figure out what part of supporting 3rd party vendor drivers can stay within the 
Kolla tree and what should be out.
I have witnessed many discussions on this topic but they only take away I get 
is “there are ways to do it but it can’t be part of Kolla”.

Using the existing kolla constructs of template-override, plugin-archive and 
config-dir, let us say the 3rd party vendor builds a container.
OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the 
Kolla project.
If these 3rd party vendor drivers publish to Dockerhub they will have to 
publish under a different project. So, an OpenStack installation that needs 
these drivers will have to pull images from 2 or more Dokerhub projects?!

Or do you prefer if the OpenStack operator build their own images using the 
out-of-tree Dockerfile for that vendor?

Again, should the config changes to support these drivers be part of the 
kolla-ansible repo or should they be out-of-tree?

It is hard to have this type of discussion on IRC so I started this email 
thread.

Thanks,
Sandhya

On 5/10/18, 5:59 AM, "Paul Bourke (pbourke) (Code Review)" 
 wrote:

 Paul Bourke (pbourke) has posted comments on this change. ( 
https://review.openstack.org/567278 )
 
 Change subject: Building Kolla containers with 3rd party vendor drivers

 ..
 
 
 Patch Set 2: Code-Review-1
 
 Hi Sandhya, after reading the spec most of my thoughts echo Eduardo's. I'm wondering if there's some misunderstanding on how the current plugin functionality works? Feels free to ping me on irc I'd be happy to discuss further - maybe there's still some element of what's there that's not working for your use case.
 
 --

 To view, visit https://review.openstack.org/567278
 To unsubscribe, visit https://review.openstack.org/settings
 
 Gerrit-MessageType: comment

 Gerrit-Change-Id: I681d6a7b38b6cafe7ebe88a1a1f2d53943e1aab2
 Gerrit-PatchSet: 2
 Gerrit-Project: openstack/kolla
 Gerrit-Branch: master
 Gerrit-Owner: Sandhya Dasu 
 Gerrit-Reviewer: Duong Ha-Quang 
 Gerrit-Reviewer: Eduardo Gonzalez 
 Gerrit-Reviewer: Paul Bourke (pbourke) 
 Gerrit-Reviewer: Zuul
 Gerrit-HasComments: No
 



__
OpenStack Development Mailing 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][ml2 plugin] unit test errors

[Andreas Scheuring]

So what you need to do first is to make a patch for networking-onos that does 
ONLY the following


replace all occurrences of 

* neutron.callbacks  by neutron_lib.callbacks
* neutron.plugins.ml2.driver_api by neutron_lib.plugins.ml2.api


Push this patch for review. After that tests should succeed again in the check 
queue - merge it.

Then you can put your new great custom code on top of this patch.

---
Andreas Scheuring (andreas_s)



On 9. May 2018, at 10:04, Andreas Scheuring  wrote:

neutron.plugins.ml2.driver_api got moved to neutron-lib. You probably need to 
update the networking-onos code and fix all imports there and push the 
changes...


---
Andreas Scheuring (andreas_s)



On 9. May 2018, at 10:00, Sangho Shin > wrote:

Hello, 

I am getting the following unit test error in Zuul test. See below.
The error is caused only in the pike version, and in stable/ocata version, I do 
not have the error.
( If you can give me any clue, it would be very helpful )

BTW, in nosetests, there is no error.
However, in tox -e py27 tests, I am getting different errors like below. 
Actually, it is caused because the tests are using different version of neutron 
library somehow. Actual neutron is installed in /opt/stack/neutron path, and it 
has correct python files such as callbacks and driver api, which are complained 
below.

So, I would like to know how to specify the correct neutron location in tox 
tests.

Thank you,

Sangho


tox -e py27 errors.

-


=
Failures during discovery
=
--- import errors ---
Failed to import test module: networking_onos.tests.unit.extensions.test_driver
Traceback (most recent call last):
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "networking_onos/tests/unit/extensions/test_driver.py", line 25, in 

import networking_onos.extensions.securitygroup as onos_sg_driver
  File "networking_onos/extensions/securitygroup.py", line 21, in 
from networking_onos.extensions import callback
  File "networking_onos/extensions/callback.py", line 15, in 
from neutron.callbacks import events
ImportError: No module named callbacks

Failed to import test module: networking_onos.tests.unit.plugins.ml2.test_driver
Traceback (most recent call last):
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "networking_onos/tests/unit/plugins/ml2/test_driver.py", line 24, in 

from neutron.plugins.ml2 import driver_api as api
ImportError: cannot import name driver_api






Zuul errors.

---

Traceback (most recent call last):
2018-05-09 05:12:30.077594 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py
 
",
 line 1182, in _execute_context
2018-05-09 05:12:30.077653 

 | ubuntu-xenial | context)
2018-05-09 05:12:30.077964 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py
 
",
 line 470, in do_execute
2018-05-09 05:12:30.078065 

 | ubuntu-xenial | cursor.execute(statement, parameters)
2018-05-09 05:12:30.078210 

 | ubuntu-xenial | InterfaceError: Error binding parameter 0 - probably 
unsupported type.
2018-05-09 05:12:30.078282 

 | ubuntu-xenial | 

[openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Julia Kreger]

Greetings folks,

Is there any objection if we re-add Jim to the ironic-stable-maint
team?  He was a member prior to his brief departure and I think it
would be good to have another set of hands that can approve the
changes as three doesn't seem like quite enough when everyone is busy.

If there are no objections, I'll re-add him next week.

-Julia

__
OpenStack Development Mailing 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] [edge][keystone][forum]: Keystone edge brainstorming etherpad

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

Thanks for your comments I've added some reactions. Also thanks for the 
advertisement.

Br,
Gerg0

From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Friday, May 11, 2018 4:48 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [edge][keystone][forum]: Keystone edge 
brainstorming etherpad


On 05/10/2018 06:30 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
Hi,

I've added some initial text to the Etherpad 
[1] of the 
Possible edge architectures for Keystone Forum session 
[2].

Awesome, I added some of my initial thoughts, too. A very similar thread was 
brought up in Syndey, and more recently in Dublin, so a lot of those 
discussions are still fresh in my mind.



Please add your comments and also indicate your willingness to participate.

The keystone project update is scheduled for Monday [0], which gives us a good 
opportunity to advertise other important keystone-related sessions. I've added 
your forum session to it.

Thanks for proposing this. I'm looking forward to it.

[0] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21584/keystone-project-update



Thanks,
Gerg0

[1]: https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming
[2]: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21737/possible-edge-architectures-for-keystone





__

OpenStack Development Mailing 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] Topics for the Board+TC+UC meeting in Vancouver

[Jay Pipes]

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to serve, 
not just those whose needs are similar to those of the users we 
already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do you 
ensure that you're meeting the needs of the users who are most important 
to the long-term sustainability of the project, and not just the ones 
who were easiest to bootstrap?


Who gets to decide who the users are "that are most important to the 
long-term sustainability of the project"?


Assuming there is a single definition of what "the project" actually is...

Best,
-jay

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

Re: [openstack-dev] [edge][keystone][forum]: Keystone edge brainstorming etherpad

[Lance Bragstad]

On 05/10/2018 06:30 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
>
> Hi,
>
>  
>
> I’ve added some initial text to the Etherpad [1
> ] of
> the Possible edge architectures for Keystone Forum session [2
> ].
>
>

Awesome, I added some of my initial thoughts, too. A very similar thread
was brought up in Syndey, and more recently in Dublin, so a lot of those
discussions are still fresh in my mind.

>  
>
> Please add your comments and also indicate your willingness to
> participate.
>

The keystone project update is scheduled for Monday [0], which gives us
a good opportunity to advertise other important keystone-related
sessions. I've added your forum session to it.

Thanks for proposing this. I'm looking forward to it.

[0]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21584/keystone-project-update

>  
>
> Thanks,
>
> Gerg0
>
>  
>
> [1]: https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming
>
> [2]:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21737/possible-edge-architectures-for-keystone
>
>  
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

Hi zigo and horizon plugin maintainers,

Horizon itself already supports Django 2.0 and horizon unit test covers
Django 2.0 with Python 3.5.

A question to all is whether we change the upper bound of Django from <2.0
to <2.1.
My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
(Note that Django 1.11 will continue to be used for python 2.7 environment.)

There are several points we should consider:
- If we change it in global-requirements.txt, it means Django 2.0 will be
used for python3.5 environment.
- Not a small number of horizon plugins still do not support Django 2.0, so
bumping the upper bound to <2.1 will break their py35 tests.
- From my experience of Django 2.0 support in some plugins, the required
changes are relatively simple like [1].

I created an etherpad page to track Django 2.0 support in horizon plugins.
https://etherpad.openstack.org/p/django20-support

I proposed Django 2.0 support patches to several projects which I think are
major.
# Do not blame me if I don't cover your project :)

Thought?

Thanks,
Akihiro

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

2018年5月8日(火) 17:45 Thomas Goirand :

> Hi,
>
> It has been decided that, in Debian, we'll switch to Django 2.0 after
> Buster will be released. Buster is to be frozen next February. This
> means that we have roughly one more year before Django 1.x goes away.
>
> Hopefully, Horizon will be ready for it, right?
>
> Hoping this helps,
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Ruby Loo]

On Fri, May 11, 2018 at 7:50 AM, Julia Kreger 
wrote:

> Greetings folks,
>
> Is there any objection if we re-add Jim to the ironic-stable-maint
> team?  He was a member prior to his brief departure and I think it
> would be good to have another set of hands that can approve the
> changes as three doesn't seem like quite enough when everyone is busy.
>
>
Glad you brought it up cuz I wanted to re-add him to this, when we re-added
him back as an ironic core :)

Thanks for making it happen,
--ruby
__
OpenStack Development Mailing 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] Should we add a tempest-slow job?

[Matthew Treinish]

On Fri, May 11, 2018 at 08:45:39AM -0500, Matt Riedemann wrote:
> The tempest-full job used to run API and scenario tests concurrently, and if
> you go back far enough I think it also ran slow tests.

Well it's a bit more subtle than that. Skipping slow tests was added right
before we introduced parallel execution to tempest ~5 years ago:

https://github.com/openstack/tempest/commit/68a8060b24abd6b6bf99c4f9296bf418a8349a2d

Note those are in separate testr jobs which we migrated to the full job a bit
later in that cycle. The full job back then ran using nose and ran things
serially. But back then we didn't actually have any tests tagged as slow. It was
more of a future proofing thing because we were planning to add a bunch of
really slow heat tests we didn't want to run on every commit to each project.
The slow tags were first added for heat tests which came later in the havana
cycle.

> 
> Sometime in the last year or so, the full job was changed to run the
> scenario tests in serial and exclude the slow tests altogether. So the API
> tests run concurrently first, and then the scenario tests run in serial.
> During that change, some other tests were identified as 'slow' and marked as
> such, meaning they don't get run in the normal tempest-full job.

It was changed in:

https://github.com/openstack/tempest/commit/49505df20f3dc578506e479c2afa4a4f02e464bf

> 
> There are some valuable scenario tests marked as slow, however, like the
> only encrypted volume testing we have in tempest is marked slow so it
> doesn't get run on every change for at least nova.
> 
> There is only one job that can be run against nova changes which runs the
> slow tests but it's in the experimental queue so people forget to run it.
> 
> As a test, I've proposed a nova-slow job [1] which only runs the slow tests
> and only the compute API and scenario tests. Since there currently no
> compute API tests marked as slow, it's really just running slow scenario
> tests. Results show it runs 37 tests in about 37 minutes [2]. The overall
> job runtime was 1 hour and 9 minutes, which is on average less than the
> tempest-full job. The nova-slow job is also running scenarios that nova
> patches don't actually care about, like the neutron IPv6 scenario tests.
> 
> My question is, should we make this a generic tempest-slow job which can be
> run either in the integrated-gate or at least in nova/neutron/cinder
> consistently (I'm not sure if there are slow tests for just keystone or
> glance)? I don't know if the other projects already have something like this
> that they gate on. If so, a nova-specific job for nova changes is fine for
> me.

So there used to be an experimental queue tempest-all job which ran everything
in tempest, including the slow tests. I can't find it in the .zuul.yaml in the
tempest repo, so my assumption is that got dropped during the v3 migration.

I'm fine with adding a general purpose job for just running the slow tests to
the integrated gate if we think there is enough value from that. It's mostly
just a question of weighing the potential value from the increased coverage vs
the increased resource consumption for adding yet another job to the integrated
gate. Personally, I'm fine with that tradeoff.

-Matt Treinish

> 
> [1] https://review.openstack.org/#/c/567697/
> [2] 
> http://logs.openstack.org/97/567697/1/check/nova-slow/bedfafb/job-output.txt.gz#_2018-05-10_23_46_47_588138
> 



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

[openstack-dev] Should we add a tempest-slow job?

[Matt Riedemann]

The tempest-full job used to run API and scenario tests concurrently, 
and if you go back far enough I think it also ran slow tests.


Sometime in the last year or so, the full job was changed to run the 
scenario tests in serial and exclude the slow tests altogether. So the 
API tests run concurrently first, and then the scenario tests run in 
serial. During that change, some other tests were identified as 'slow' 
and marked as such, meaning they don't get run in the normal 
tempest-full job.


There are some valuable scenario tests marked as slow, however, like the 
only encrypted volume testing we have in tempest is marked slow so it 
doesn't get run on every change for at least nova.


There is only one job that can be run against nova changes which runs 
the slow tests but it's in the experimental queue so people forget to 
run it.


As a test, I've proposed a nova-slow job [1] which only runs the slow 
tests and only the compute API and scenario tests. Since there currently 
no compute API tests marked as slow, it's really just running slow 
scenario tests. Results show it runs 37 tests in about 37 minutes [2]. 
The overall job runtime was 1 hour and 9 minutes, which is on average 
less than the tempest-full job. The nova-slow job is also running 
scenarios that nova patches don't actually care about, like the neutron 
IPv6 scenario tests.


My question is, should we make this a generic tempest-slow job which can 
be run either in the integrated-gate or at least in nova/neutron/cinder 
consistently (I'm not sure if there are slow tests for just keystone or 
glance)? I don't know if the other projects already have something like 
this that they gate on. If so, a nova-specific job for nova changes is 
fine for me.


[1] https://review.openstack.org/#/c/567697/
[2] 
http://logs.openstack.org/97/567697/1/check/nova-slow/bedfafb/job-output.txt.gz#_2018-05-10_23_46_47_588138


--

Thanks,

Matt

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

Re: [openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Julia Kreger]

On Fri, May 11, 2018 at 8:20 AM, Dmitry Tantsur  wrote:
> Hi,
[trim]
>> If there are no objections, I'll re-add him next week.
>
>
> I don't remember if we actually can add people to these teams or it has to
> be done by the main stable team.
>
I'm fairly sure I'm the person who deleted him from the group in the
first place :(   As such, I think I has the magical powers... maybe
;)

__
OpenStack Development Mailing 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] [placement] low hanging bug for a new contributor

[Jay Pipes]

Hi Stackers,

Here's a small bug that would be ideal for a new contributor to pick up:

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

Come find us on #openstack-placement on Freenode if you'd like to pick 
it up and run with it.


Best,
-jay

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

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Fox, Kevin M]

Who are your users, what do they need, are you meeting those needs, and what 
can you do to better things?

If that can't be answered, how do you know if you are making progress or 
staying relevant?

Lines of code committed is not a metric of real progress.
Number of reviews isn't.
Feature addition metrics aren't necessarily if the features are not relevant.
Developer community size is not really a metric of progress either. (not a bad 
thing. just doesn't grantee progress if devs are going in different directions)

If you can't answer them, how do separate things like, "devs are leaving 
because the project is mature, from the overall project is really broken and 
folks are just leaving?"

Part of the disconnect to me has been that these questions have been left up to 
the projects by and large. But, users don't use the projects. Users use 
OpenStack. Or, moving forward, they at least use a Constellation. But 
Constellation is still just a documentation construct. Not really a first class 
entity.

Currently the isolation between the Projects and the thing that the users use, 
the Constellation allows for user needs to easily slip through the cracks. 
Cause "Project X: we agree that is a problem, but its Y projects problem. 
Project Y: we agree that is a problem, but its X projects problem." No, 
seriously, its OpenStacks problem. Most of the major issues I've hit in my many 
years of using OpenStack were in that category. And there wasn't a good forum 
for addressing them.

A related effect of the isolation is also that the projects don't work on the 
commons nor look around too much what others are doing. Either within OpenStack 
or outside. They solve problems at the project level and say, look, I've solved 
it, but don't look at what happens when all the projects do that independently 
and push more work to the users. The end result of this lack of Leadership is 
more work for the users compared to competitors.

IMO, OpenStack really needs some Leadership at a higher level. It seems to be 
lacking some things:
1. A group that performs... lacking a good word reconnaissance? How is 
OpenStack fairing in the world. How is the world changing and how must 
OpenStack change to continue to be relevant. If you don't know you have a 
problem you can't correct it.
2. A group that decides some difficult political things, like who the users 
are. Maybe at a per constellation level. This does not mean rejecting use cases 
from "non users". just helping the projects sort out priorities.
3. A group that decides on a general direction for OpenStack's technical 
solutions, encourages building up the commons, helps break down the project 
communication walls and picks homes for features when it takes too long for a 
user need to be met (users really don't care what OpenStack project does what 
feature. They just that they are suffering, things don't get addressed in a 
timely manner, and will maybe consider looking outside of OpenStack for a 
solution)

The current governance structure is focused on hoping the individual projects 
will look at the big picture and adjust to it, and commit the relevant common 
code to the commons rather then one-offing a solution and discussing solutions 
between projects to gain consensus. But that's generally not happening. The 
projects have a narrow view of the world and just wanna make progress on their 
code. I get that. The other bits are hard. Guidance to the projects on how they 
are are, or are not fitting, would help them make better choices and better 
code.

The focus so much on projects has made us loose sight of why they exist. To 
serve the Users. Users don't use projects as OpenStack has defined them though. 
And we can't even really define what a user is. This is a big problem.

Anyway, more Leadership please! Ready. GO! :)

Thanks,
Kevin


From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, May 11, 2018 9:31 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in 
Vancouver

On 05/11/2018 12:21 PM, Zane Bitter wrote:
> On 11/05/18 11:46, Jay Pipes wrote:
>> On 05/10/2018 08:12 PM, Zane Bitter wrote:
>>> On 10/05/18 16:45, Matt Riedemann wrote:
 On 5/10/2018 3:38 PM, Zane Bitter wrote:
> How can we avoid (or get out of) the local maximum trap and ensure
> that OpenStack will meet the needs of all the users we want to
> serve, not just those whose needs are similar to those of the users
> we already have?

 The phrase "jack of all trades, master of none" comes to mind here.
>>>
>>> Stipulating the constraint that you can't please everybody, how do
>>> you ensure that you're meeting the needs of the users who are most
>>> important to the long-term sustainability of the project, and not
>>> just the ones who were easiest to bootstrap?
>>
>> Who gets to decide who the users are "that are most important to the
>> long-term sustainability of 

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> Hi zigo and horizon plugin maintainers,
> 
> Horizon itself already supports Django 2.0 and horizon unit test covers
> Django 2.0 with Python 3.5.
> 
> A question to all is whether we change the upper bound of Django from <2.0
> to <2.1.
> My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> (Note that Django 1.11 will continue to be used for python 2.7 environment.)

Do we need to cap it at all? We've been trying to express our
dependencies without caps and rely on the constraints list to
test using a common version because this offers the most flexibility as
we move to newer versions over time.

> There are several points we should consider:
> - If we change it in global-requirements.txt, it means Django 2.0 will be
> used for python3.5 environment.
> - Not a small number of horizon plugins still do not support Django 2.0, so
> bumping the upper bound to <2.1 will break their py35 tests.
> - From my experience of Django 2.0 support in some plugins, the required
> changes are relatively simple like [1].
> 
> I created an etherpad page to track Django 2.0 support in horizon plugins.
> https://etherpad.openstack.org/p/django20-support
> 
> I proposed Django 2.0 support patches to several projects which I think are
> major.
> # Do not blame me if I don't cover your project :)
> 
> Thought?

It seems like a good goal for the horizon-plugin author community
to bring those projects up to date by supporting a current version
of Django (and any other dependencies), especially as we discuss
the impending switch over to python-3-first and then python-3-only.

If this is an area where teams need help, updating that etherpad
with notes and requests for assistance will help us split up the
work.

Doug

> 
> Thanks,
> Akihiro
> 
> [1] https://review.openstack.org/#/c/566476/
> 
> 2018年5月8日(火) 17:45 Thomas Goirand :
> 
> > Hi,
> >
> > It has been decided that, in Debian, we'll switch to Django 2.0 after
> > Buster will be released. Buster is to be frozen next February. This
> > means that we have roughly one more year before Django 1.x goes away.
> >
> > Hopefully, Horizon will be ready for it, right?
> >
> > Hoping this helps,
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

__
OpenStack Development Mailing 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] Keystone Team Update - Week of 7 May 2018

[Colleen Murphy]

# Keystone Team Update - Week of 7 May 2018

## News

### Patrole in CI

With all the work that has been happening around fixing policy, it would be 
good to have better policy validation in CI[1]. However, there are some 
concerns that using Patrole in a voting gate job will lock us in to unwanted 
behavior. We agreed to start setting up the framework but to keep the jobs 
nonvoting until 968696[2] is fully fixed.

[1] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-05-08-16.00.log.html#l-51
[2] https://bugs.launchpad.net/keystone/+bug/968696

### Multi-Site Keystone

Keystone has never been able to provide straightforward guidance on 
implementing multi-region/multi-site clouds. We discussed an implementation 
proposal to "stretch" over existing clouds[3] with a combination of Galera 
syncing and orchestration around keystone-manage commands. A proof of concept 
already exists[4] and a spec will be forthcoming. We had also discussed[5] 
tying this into the default roles spec[6] by perhaps assigning static, non-UUID 
IDs to the new default roles in order to gain uniformity across distinct sites, 
but migrating existing clouds would be a challenge and we would need to come up 
with a solution for domain-specific roles.

[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-05-08-16.00.log.html#l-156
[4] https://github.com/zzzeek/stretch_cluster/tree/standard_tripleo_version
[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-05-07.log.html#t2018-05-07T17:23:29
[6] https://review.openstack.org/566377

## Open Specs

Search query: https://bit.ly/2G8Ai5q

As discussed last week, the default roles spec has been reproposed to 
keystone-specs[7]. We also need to prioritize reviews of the unified limits 
specs[8][9]. The remaining specs are likely to be deferred until next cycle.

[7] https://review.openstack.org/566377
[8] https://review.openstack.org/540803
[9] https://review.openstack.org/565412

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 19 changes this week. Among these were patches to enhance service 
discovery in keystoneauth using service-types-authority.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 43 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

Launchpad report generator: https://github.com/lbragstad/launchpad-toolkit

These week we opened 5 new bugs and closed 4.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

We have about four weeks to get our current spec proposals in shape to be 
merged, and six weeks to start seeing implementation proposals for those specs.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
OpenStack Development Mailing 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] Building Kolla containers with 3rd party vendor drivers

[Sandhya Dasu (sadasu)]

Hi Paul,
I am happy to use the changes you proposed to
 https://github.com/openstack/kolla/blob/master/kolla/common/config.py

I was under the impression that this was disallowed for drivers that weren’t
considered “reference drivers”. If that is no longer the case, I am happy to go
this route and abandon the approach I took in my diffs in:
https://review.openstack.org/#/c/552119/.

I agree with the reasoning that Kolla cannot possibly maintain a large
number of neutron-server containers, one per plugin.

To support operators that want to build their own images, I was hoping that
we could come up with a mechanism by which the 3rd party driver owners
provide the code (template-override.j2 or Dockerfile.j2 as the case maybe)
to build their containers. This code can definitely live out-of-tree with the
drivers themselves.

Optionally, we could have them reside in-tree in Kolla in a separate directory, 
say “additional drivers”. Kolla will not be responsible for building a container
per driver or for building a huge (neutron-server) container containing all
interested drivers.

Operators that need one or more of these “additional drivers” will be provided
with documentation on how the code in the “additional drivers” path can be
used to build their own containers. This documentation will also detail how
to combine more than one 3rd party drivers into their own container.

I would like the community’s input on what approach best aligns with Kolla’s
and the larger OpenStack community’s goals.

Thanks,
Sandhya

On 5/11/18, 5:35 AM, "Paul Bourke"  wrote:

Hi Sandhya,

Thanks for starting this thread. I've moved it to the mailing list so 
the discussion can be available to anyone else who is interested, I hope 
you don't mind.

If your requirement is to have third party plugins (such as Cisco) that 
are not available on tarballs.openstack.org, available in Kolla, then 
this is already possible.

Using the Cisco case as an example, you would simply need to submit the 
following patch to 
https://github.com/openstack/kolla/blob/master/kolla/common/config.py

"""
 'neutron-server-plugin-networking-cisco': {
 'type': 'git',
 'location': ('https://github.com/openstack/networking-cisco')},
"""

This will then include that plugin as part of the future neutron-server 
builds.

If the requirement is to have Kolla publish a neutron-server container 
with *only* the Cisco plugin, then this is where it gets a little more 
tricky. Sure, we can go the route that's proposed in your patch, but we 
end up then maintaining a massive number of neutron-server containers, 
one per plugin. It also does not address then the issue of what people 
want to do when they want a combination or mix of plugins together.

So right now I feel Kolla takes a middle ground, where we publish a 
neutron-server container with a variety of common plugins. If operators 
have specific requirements, they should create their own config file and 
build their own images, which we expect any serious production setup to 
be doing anyway.

-Paul

On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:
> Yes, I think there is some misunderstanding on what I am trying to 
accomplish here.
> 
> I am utilizing existing Kolla constructs to prove that they work for 3rd 
party out of tree vendor drivers too.
> At this point, anything that a 3rd party vendor driver does (the way they 
build their containers, where they publish it and how they generate config) is 
completely out of scope of Kolla.
> 
> I want to use the spec as a place to articulate and discuss best 
practices and figure out what part of supporting 3rd party vendor drivers can 
stay within the Kolla tree and what should be out.
> I have witnessed many discussions on this topic but they only take away I 
get is “there are ways to do it but it can’t be part of Kolla”.
> 
> Using the existing kolla constructs of template-override, plugin-archive 
and config-dir, let us say the 3rd party vendor builds a container.
> OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the 
Kolla project.
> If these 3rd party vendor drivers publish to Dockerhub they will have to 
publish under a different project. So, an OpenStack installation that needs 
these drivers will have to pull images from 2 or more Dokerhub projects?!
> 
> Or do you prefer if the OpenStack operator build their own images using 
the out-of-tree Dockerfile for that vendor?
> 
> Again, should the config changes to support these drivers be part of the 
kolla-ansible repo or should they be out-of-tree?
> 
> It is hard to have this type of discussion on IRC so I started this email 
thread.
> 
> Thanks,
> 

[openstack-dev] [requirements][glare][mogan][solum][compute-hyperv][kingbird][searchlight][swauth][networking-powervm][rpm-packaging][os-win] uncaping eventlet

[Matthew Thode]

Please review your particular uncaping patch (all but rpm-packaging are
passing gate it looks like).  We'd like to move on to a newer eventlet
for rocky.

https://review.openstack.org/#/q/topic:uncap-eventlet+status:open

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Zane Bitter]

On 11/05/18 11:46, Jay Pipes wrote:

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to 
serve, not just those whose needs are similar to those of the users 
we already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do you 
ensure that you're meeting the needs of the users who are most 
important to the long-term sustainability of the project, and not just 
the ones who were easiest to bootstrap?


Who gets to decide who the users are "that are most important to the 
long-term sustainability of the project"?


The thing I'm hoping to convince people of here is that the question is 
interesting independently of how you define that.


- ZB

__
OpenStack Development Mailing 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] Topics for the Board+TC+UC meeting in Vancouver

[Jay Pipes]

On 05/11/2018 12:21 PM, Zane Bitter wrote:

On 11/05/18 11:46, Jay Pipes wrote:

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to 
serve, not just those whose needs are similar to those of the users 
we already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do 
you ensure that you're meeting the needs of the users who are most 
important to the long-term sustainability of the project, and not 
just the ones who were easiest to bootstrap?


Who gets to decide who the users are "that are most important to the 
long-term sustainability of the project"?


The thing I'm hoping to convince people of here is that the question is 
interesting independently of how you define that.


Agreed. The question is interesting regardless, but how seriously people 
take the answers to the question will depend on how much they agree with 
the people that decide who the "important users" are.


Best,
-jay

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

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Jimmy McArthur]

Fox, Kevin M wrote:

Who are your users, what do they need, are you meeting those needs, and what 
can you do to better things?

IMO, OpenStack really needs some Leadership at a higher level. It seems to be 
lacking some things:
1. A group that performs... lacking a good word reconnaissance? How is 
OpenStack fairing in the world. How is the world changing and how must 
OpenStack change to continue to be relevant. If you don't know you have a 
problem you can't correct it.
2. A group that decides some difficult political things, like who the users are. Maybe at 
a per constellation level. This does not mean rejecting use cases from "non 
users". just helping the projects sort out priorities.
3. A group that decides on a general direction for OpenStack's technical 
solutions, encourages building up the commons, helps break down the project 
communication walls and picks homes for features when it takes too long for a 
user need to be met (users really don't care what OpenStack project does what 
feature. They just that they are suffering, things don't get addressed in a 
timely manner, and will maybe consider looking outside of OpenStack for a 
solution)
This is a big reason we're excited that the Ops & Users Meetup are 
co-locating at the next PTG.  Some of the breakdown is getting 
actionable items from Ops Meetups and UC back to the devs in time for 
the next development cycle.


The current governance structure is focused on hoping the individual projects 
will look at the big picture and adjust to it, and commit the relevant common 
code to the commons rather then one-offing a solution and discussing solutions 
between projects to gain consensus. But that's generally not happening. The 
projects have a narrow view of the world and just wanna make progress on their 
code. I get that. The other bits are hard. Guidance to the projects on how they 
are are, or are not fitting, would help them make better choices and better 
code.
Keep in mind, UC also has governance :)  I think it's really important 
to start looking to the UC to help craft the big picture and be part of 
the conversation. This serves the purpose of getting Ops & Devs working 
together towards a better OpenStack.  It also helps broaden the 
perspective of everyone involved in the project, from all sides.


The focus so much on projects has made us loose sight of why they exist. To 
serve the Users. Users don't use projects as OpenStack has defined them though. 
And we can't even really define what a user is. This is a big problem.

Anyway, more Leadership please! Ready. GO! :)

Thanks,
Kevin


From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, May 11, 2018 9:31 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in 
Vancouver

On 05/11/2018 12:21 PM, Zane Bitter wrote:

On 11/05/18 11:46, Jay Pipes wrote:

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:

How can we avoid (or get out of) the local maximum trap and ensure
that OpenStack will meet the needs of all the users we want to
serve, not just those whose needs are similar to those of the users
we already have?

The phrase "jack of all trades, master of none" comes to mind here.

Stipulating the constraint that you can't please everybody, how do
you ensure that you're meeting the needs of the users who are most
important to the long-term sustainability of the project, and not
just the ones who were easiest to bootstrap?

Who gets to decide who the users are "that are most important to the
long-term sustainability of the project"?

The thing I'm hoping to convince people of here is that the question is
interesting independently of how you define that.


Agreed. The question is interesting regardless, but how seriously people
take the answers to the question will depend on how much they agree with
the people that decide who the "important users" are.

Best,
-jay

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

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


__
OpenStack Development Mailing 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] Topics for the Board+TC+UC meeting in Vancouver

[Lance Bragstad]

On 05/11/2018 02:00 PM, Fox, Kevin M wrote:
> Who are your users, what do they need, are you meeting those needs, and what 
> can you do to better things?
>
> If that can't be answered, how do you know if you are making progress or 
> staying relevant?
>
> Lines of code committed is not a metric of real progress.
> Number of reviews isn't.
> Feature addition metrics aren't necessarily if the features are not relevant.
> Developer community size is not really a metric of progress either. (not a 
> bad thing. just doesn't grantee progress if devs are going in different 
> directions)
>
> If you can't answer them, how do separate things like, "devs are leaving 
> because the project is mature, from the overall project is really broken and 
> folks are just leaving?"
>
> Part of the disconnect to me has been that these questions have been left up 
> to the projects by and large. But, users don't use the projects. Users use 
> OpenStack. Or, moving forward, they at least use a Constellation. But 
> Constellation is still just a documentation construct. Not really a first 
> class entity.
>
> Currently the isolation between the Projects and the thing that the users 
> use, the Constellation allows for user needs to easily slip through the 
> cracks. Cause "Project X: we agree that is a problem, but its Y projects 
> problem. Project Y: we agree that is a problem, but its X projects problem." 
> No, seriously, its OpenStacks problem. Most of the major issues I've hit in 
> my many years of using OpenStack were in that category. And there wasn't a 
> good forum for addressing them.

I can think of a couple good example problems that probably fall into
the category you've described. But, I wouldn't say it was solely because
two or more projects were convinced the problem exists and it wasn't
their responsibility (IMO, that at least seems like a broad
generalization of the root of why cross-project issues take a long time).

For example, the push for default roles surfaced in 2015 as an
OpenStack-wide specification, but lost steam when we realized just how
terrible the migration path would be for users. Eventually, a solution
for that migration issue made it's way into the commons (oslo.policy)
and enabled a Queens community goal. I think the leadership established
through community goals makes this kind of work possible, even if it
does take a while.

>
> A related effect of the isolation is also that the projects don't work on the 
> commons nor look around too much what others are doing. Either within 
> OpenStack or outside. They solve problems at the project level and say, look, 
> I've solved it, but don't look at what happens when all the projects do that 
> independently and push more work to the users. The end result of this lack of 
> Leadership is more work for the users compared to competitors.
>
> IMO, OpenStack really needs some Leadership at a higher level. It seems to be 
> lacking some things:
> 1. A group that performs... lacking a good word reconnaissance? How is 
> OpenStack fairing in the world. How is the world changing and how must 
> OpenStack change to continue to be relevant. If you don't know you have a 
> problem you can't correct it.
> 2. A group that decides some difficult political things, like who the users 
> are. Maybe at a per constellation level. This does not mean rejecting use 
> cases from "non users". just helping the projects sort out priorities.
> 3. A group that decides on a general direction for OpenStack's technical 
> solutions, encourages building up the commons, helps break down the project 
> communication walls and picks homes for features when it takes too long for a 
> user need to be met (users really don't care what OpenStack project does what 
> feature. They just that they are suffering, things don't get addressed in a 
> timely manner, and will maybe consider looking outside of OpenStack for a 
> solution)

This sounds like the group of people who propose, review, and implement
community goals.

>
> The current governance structure is focused on hoping the individual projects 
> will look at the big picture and adjust to it, and commit the relevant common 
> code to the commons rather then one-offing a solution and discussing 
> solutions between projects to gain consensus. But that's generally not 
> happening. The projects have a narrow view of the world and just wanna make 
> progress on their code. I get that. The other bits are hard. Guidance to the 
> projects on how they are are, or are not fitting, would help them make better 
> choices and better code.
>
> The focus so much on projects has made us loose sight of why they exist. To 
> serve the Users. Users don't use projects as OpenStack has defined them 
> though. And we can't even really define what a user is. This is a big problem.
>
> Anyway, more Leadership please! Ready. GO! :)
>
> Thanks,
> Kevin
>
> 
> From: Jay Pipes [jaypi...@gmail.com]
> 

Re: [openstack-dev] [keystone] keystoneauth version auto discovery for internal endpoints in queens

[Morgan Fainberg]

Typically speaking if we broke a behavior via a change in KeystoneAuth
(not some behavior change in openstackclient or the way osc processes
requests), we are in the wrong and we will need to go back through and
fix the previous behavior.

I'll spend some time going through this to verify if this really is a
KSA change bug or something else. If it is in-fact a KSA
(keystoneauth) bug, we'll work to restore the previous behavior(s) as
reasonably quickly as possible.

Cheers,
--Morgan

On Fri, May 11, 2018 at 1:37 PM, Vlad Gusev  wrote:
> Hello.
>
> We faced a bug in keystoneauth, which haven't existed before Queens.
>
> In our OpenStack deployments we use urls like http://controller:5000/v3 for
> internal and admin endpoints and urls like
> https://api.example.org/identity/v3 for public endpoints. We set option
> public_endpoint in [default] section of the
> keystone.conf/nova.conf/cinder.conf/glance.conf/neutron.conf. For example,
> for keystone it is 'public_endpoint=https://api.example.org/identity/'.
>
> Since keystoneauth 3.2.0 or commit
> https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c
> all internal client requests to the internal endpoints (for example,
> openstack server list from controller node) fail with 404 error, because it
> tries to do auto discovery at the http://controller:5000/v3. It gets
> {"href": "https://api.example.org/identity/v3/;, "rel": "self"} because of
> the public_endpoint option, and then in function _combine_relative_url()
> (keystoneauth1/discover.py:405) keystoneauth combines
> http://controller:5000/ with the path from public href. So after auto
> discovery attempt it goes to the wrong path
> http://controller:5000/identity/v3/
>
> Before this commit openstackclient made auth request to the
> https://api.example.org/identity/v3/auth/tokens (and it worked, because in
> our deployment internal services and console clients can access this public
> url). At best, we expect openstackclient always go to the
> http://controller:5000/v3/
>
> This problem partially could be solved by explicitly passing public
> --os-auth-url https://api.example.org/identity/identity/v3 to the console
> clients even if we want to use internal endpoints.
>
> I found similiar bug in launchpad, but it haven't received any attention:
> https://bugs.launchpad.net/keystoneauth/+bug/1733052
>
> What could be done with this behavior of keystoneauth auto discovery?
>
> - Vlad
>
> __
> OpenStack Development Mailing 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] keystoneauth version auto discovery for internal endpoints in queens

[Vlad Gusev]

Hello.

We faced a bug in keystoneauth, which haven't existed before Queens.

In our OpenStack deployments we use urls like http://controller:5000/v3 for
internal and admin endpoints and urls like
https://api.example.org/identity/v3 for public endpoints. We set option
public_endpoint in [default] section of the
keystone.conf/nova.conf/cinder.conf/glance.conf/neutron.conf. For example,
for keystone it is 'public_endpoint=https://api.example.org/identity/'.

Since keystoneauth 3.2.0 or commit
https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c
all internal client requests to the internal endpoints (for example,
openstack server list from controller node) fail with 404 error, because it
tries to do auto discovery at the http://controller:5000/v3. It gets
{"href": "https://api.example.org/identity/v3/;, "rel": "self"} because of
the public_endpoint option, and then in function _combine_relative_url()
(keystoneauth1/discover.py:405) keystoneauth combines
http://controller:5000/ with the path from public href. So after auto
discovery attempt it goes to the wrong path
http://controller:5000/identity/v3/

Before this commit openstackclient made auth request to the
https://api.example.org/identity/v3/auth/tokens (and it worked, because in
our deployment internal services and console clients can access this public
url). At best, we expect openstackclient always go to the
http://controller:5000/v3/

This problem partially could be solved by explicitly passing public
--os-auth-url https://api.example.org/identity/identity/v3 to the console
clients even if we want to use internal endpoints.

I found similiar bug in launchpad, but it haven't received any attention:
https://bugs.launchpad.net/keystoneauth/+bug/1733052

What could be done with this behavior of keystoneauth auto discovery?

- Vlad
__
OpenStack Development Mailing 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] Topics for the Board+TC+UC meeting in Vancouver

[Matt Riedemann]

On 5/11/2018 2:00 PM, Fox, Kevin M wrote:

Currently the isolation between the Projects and the thing that the users use, the 
Constellation allows for user needs to easily slip through the cracks. Cause 
"Project X: we agree that is a problem, but its Y projects problem. Project Y: we 
agree that is a problem, but its X projects problem." No, seriously, its OpenStacks 
problem. Most of the major issues I've hit in my many years of using OpenStack were in 
that category. And there wasn't a good forum for addressing them.


Agree, and we'll be talking about this during the volume multi-attach 
talk at the summit [1]. Because once we got it out the door in Queens, 
there was a lot of "what took so long?" feedback, and the answer to that 
question pulls from a lot of the stuff you're talking about in this 
thread, i.e. big changes are hard, big changes across multiple projects 
are hard, finding people to sustain the efforts for those big changes is 
hard, not dumping a steaming pile on the operators and users is hard 
(think smooth upgrades), etc. So things take time to do them correctly 
and even then people are not satisfied because "it took too long". 
Anyway, there are hopefully some nuggets of wisdom we can share in that 
talk to make stuff like this smoother in the future. I know this isn't 
the only example (by far), it's just a recent one. Lance has some other 
good ones in his reply.


[1] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/20850/the-multi-release-multi-project-road-to-volume-multi-attach


--

Thanks,

Matt

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

[openstack-dev] [forum] [keystone] unified limits etherpad

[Lance Bragstad]

Hi all,

I've created an etherpad for the unified limits session at the forum
[0]. I've bootstrapped it with some basic context so that we can spend
as much time as possible on the session goals.

If you have questions, comments, or additional session goals, please
feel free to add them to the etherpad.

Thanks and see you there,

Lance

[0] https://etherpad.openstack.org/p/YVR-rocky-unified-limits



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] [forum] [keystone] default roles etherpad

[Lance Bragstad]

Hey everyone,

I've created an etherpad for the default roles discussion in Vancouver
[0]. It currently contains basic context and some session goals.

If you have any input or additional session goals, please don't hesitate
to add to the etherpad.

Thanks and hope to see you there,

Lance

[0] https://etherpad.openstack.org/p/YVR-rocky-default-roles



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