date:20170410


On 4/10/2017 5:20 AM, sfinu...@redhat.com wrote:

On Mon, 2017-04-10 at 10:24 +0100, John Garbutt wrote:

On 10 April 2017 at 01:56, Matt Riedemann 
wrote:

I found a fun little legacy nugget of compute API non-
interoperability joy
tonight.

The "allow_instance_snapshots" config option disables the
createImage server
action API. Completely config driven and therefore not
discoverable.

What intrigues me is that this isn't applied to the createBackup or
shelve
APIs, which also create a snapshot of the instance. Is this by
design? I'm
guessing probably not. In fact, this predates the use of Gerrit [1]
so this
was probably just something hacked in so long ago it makes zero
sense now.
The way to disable any of these APIs now is via policy.

Unless anyone has an issue with this, I'm going to deprecate it for
removal.

[1]
https://github.com/openstack/nova/commit/9633e9877c7836c18c30b51c84
94abfb025e64ca


+1 for deprecate it.

That looks like something we did before we had policy.
Not that policy is that discoverable yet either, but it seems better.

Thanks,
john


I concur. Policy seems a far better way of configuring this.

Stephen

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



The question about deprecation was really just rhetorical. :)

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

--

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] [Keystone][Token expiration]

2017-04-10 Thread Dolph Mathews

The token itself is still expired, regardless of where it's persisted, if
at all. Expired tokens are only considered valid when presented as an
X-Auth-Token to keystonemiddleware.auth_token along with a valid
X-Service-Token, or when validating an X-Subject-Token against keystone
directly using either:

  HEAD /v3/auth/token?allow_expired
  GET /v3/auth/token?allow_expired

No configuration is required in keystone.conf to enable the feature.

More documentation is available in the release notes [1][2] and in the
sample configuration file [3] (see [token] allow_expired_window).

[1] https://docs.openstack.org/releasenotes/keystone/ocata.html#new-features
[2]
https://docs.openstack.org/releasenotes/keystone/ocata.html#upgrade-notes
[3]
https://docs.openstack.org/ocata/config-reference/identity/samples/keystone.conf.html

On Mon, Apr 3, 2017 at 7:58 AM lương hữu tuấn  wrote:

> Hi Dolph,
>
> Thanks for reply, it means that from the db point of view, token is
> expired but it is still passed to other service users in request (token
> stored in memory?) and keystone allows this expired token? And to make this
> feature working, we should apply the header of "X-Service-Token" and change
> of "allow_expired" in keystone.conf.
>
> Br,
>
> Tuan/Nokia
>
> On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews 
> wrote:
>
> > does it mean that the token now will live forever
>
> No; it behaves as described in the document you linked. If you have any
> specific security concerns, please raise them appropriately (such as a
> security bug, if necessary).
>
> On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn 
> wrote:
>
> Hi keystone folks,
>
> I have had a chance to take a look to this below patch for allowing the
> expired token and it was merged in Octaka:
>
>
> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/allow-expired.html
>
> In our project, we also have problem with token expiration when running
> mistral workflow. I have a concern that if this patch works as it does,
> does it mean that the token now will live forever ("forever" seems so
> sloppy, but it seems like the token is no longer expired). In this case, it
> seems not good for security purpose.
>
> Br,
>
> Tuan/Nokia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> -Dolph
>
> __
> OpenStack Development Mailing 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
>
-- 
-Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][kolla] extended start and hostpath persistent dirs

2017-04-10 Thread Jiří Stránský

Responses inline :) I started snipping parts out because the quotations
are getting long.

tl;dr use kolla images and bootsrap OR upstream images with
direct
commands:

.. code-block:: yaml
kolla_config:
/var/lib/kolla/config_files/foo.json
command: /usr/bin/foo

We insist on using kolla extended start, if only it can't function
w/o Kolla extended start using Kolla images (like Mysql and Rabbitmq
have some extra initialization)

I don't think we need to insist on this, in fact i'd even prefer not
using kolla_start in cases where it doesn't provide significant value.

In addition to the Kolla flavor that Dan mentioned earlier, using these
entrypoints also increases chance of TripleO being broken by a commit to
Kolla, because Kolla commits aren't gated on deploying TripleO.

If the only thing we need is the file permissions setup, we don't even
need to use kolla_start for that, we can use kolla_set_configs [4]
directly in an init container. (But again, i don't think we need to
force this as a rule.)

.. code-block:: yaml
foo:
image: upstream/foo:latest
command: /usr/bin/foo

We accept direct commands as well, if it works w/o "user: root" for
Kolla containers omitting extended start OR if it just works as is with
upstream containers (non Kolla), like etcd [2] and perhaps redis

I think using direct commands is fine.

However, i think we should avoid targeting any images that we can't
build ourselves easily. One of the benefits of using Kolla images is a
uniform way how to build them.

* Custom entrypoints for containers adds complexity and head ache.

Good point. But the entry points Kolla uses for many containers don't
match what our systemd services already use on baremetal. As we are
striving for update path that does not break end users upgrading from
baremetal to containers we have to have a mechanism that gives us
configuration parity across the implementions. Controlling the entry
point either by injecting it into the container (via something like
Kolla's template overrides mechanism) or via tripleo-heat-templates
direction (much more hackable) is where we ended up.

Yea i'd very much prefer using entrypoints that are easily amendable by
TripleO developers, and are gated on deploying TripleO.

As for having them in-image or externally passed from t-h-t, that could
almost be a thread on its own :) The benefit of t-h-t approach is
hackability. The benefit of in-image approach is being sure that the
image version is compatible with its entrypoint (for rollbacks and such)
and generally the image being more self contained (being able to use it
easier manually, without Heat/t-h-t, should the need arise).

I think we may still be forming our opinion on this matter as we hit
issues with one or the other approach, maybe we'll even continue using
different approaches for different use cases.

In general we like Kolla images at the moment for what they provide.
But there are some cases where we need to control things that have too
much of a "kolla flavor" and would potentially break upgrades/features
if we used them directly.

We accept custom entry points for some tricky cases as well.

Having that said, I'd really like to see a final call for that topic.
Otherwise it's really hard to do a code review and perhaps to maintain
changes to t-h-t for future releases as well.

Cheers

Jirka

[4]
https://github.com/openstack/kolla/blob/77903c70cd651ad97a6a918f6889e5120d85b8d1/docker/base/start.sh#L14

Re: [openstack-dev] Boston Forum Schedule

2017-04-10 Thread David Medberry

Are the three rooms roughly the same size?

On Mon, Apr 10, 2017 at 3:35 AM, Tom Fifield  wrote:

> Hi everyone,
>
> Thank you for the many excellent topics submitted for our first Forum. We
> have updated the topic submission site with the status of each - please
> check yours.
>
> Please also find attached in PDF the proposed schedule for the Forum in
> Boston.
>
>
> Let us know if you see major issues with it. As Thierry said in design
> summits past; "It's difficult to make too many changes at this stage as
> they quickly cascade into breaking all sorts of constraints, but we may
> still be able to accommodate some." :)
>
> Eagle-eyed readers will see that there are a number of slots in gray (on
> Thursday afternoon). These are being deliberately kept aside for the usual
> few critical topics that come up in the next few weeks and also for the
> discoveries we make in the first 3 days of the summit.
>
> We'll soon publish the Forum sessions on the main schedule, using the
> title, abstracts and moderators you submitted, but look forward to your
> feedback in the mean-time!
>
> Thank you all very much for making our first Forum a success.
>
>
> Regards,
>
> Doug, Emilien, Melvin, Mike, Shamail & Tom
> Forum Scheduling Committee
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Amrith Kumar

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, April 10, 2017 5:17 AM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [tc] [elections] Available time and top priority
> 
> Hi everyone,
> 
> New in this TC election round, we have a few days between nominations and
> actual voting to ask questions and get to know the candidates a bit better.
> I'd like to kick off this new "campaigning period" with a basic question on
> available time and top priority.
> 
> All the candidates are top community members with a lot of responsibilities
> on their shoulders already. My experience tells me that it is easy to
> overestimate the time we can dedicate to Technical Committee matters, and how
> much we can push and get done in six months or one year. At the same time,
> our most efficient way to make progress is always when someone "owns" a
> particular initiative and pushes it through the governance process.
> 
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing proposed
> changes and pushing your own) ? If there was ONE thing, one initiative, one
> change you will actively push in the six months between this election round
> and the next, what would it be ?
> 

[Amrith Kumar] I have the (somewhat) luxury of being able to devote a 
significant portion of my time to activities of OpenStack and the technical 
committee in the new role that I will be entering into. I will therefore be 
able to devote at least 20% of my time to activities related to the technical 
committee.

The one initiative that I would drive would be to build community for projects 
that (like Trove) face a declining participation, and are facing the same 
kind(s) of challenges when it comes to the mechanics of reviewing changes, 
keeping up with the rest of OpenStack, and continuing to make forward progress 
on their own deliverables.

It will be part of my new role to establish a core group of OpenStack talent 
who will participate in a number of projects (including, of course Trove). This 
initiative is not something new for me, I've been doing this for some time now. 
I gratefully acknowledge the help I've received in this area from many in the 
community, and most of all from dims (also candidate for election to the TC 
this cycle, please also vote for him) and want to build a larger group of 
motivated contributors who are willing to take time out of their schedules and 
participate in the effort of growing the community and the leadership. I've 
been participating in the activities of the SWG (since its inception) and I see 
this not so much as an 'election campaign' but rather a continuation of what 
I've been espousing for some time now.

The success of OpenStack in its mission to be the ubiquitous cloud computing 
platform depends in large part on the vibrant community in all of the projects 
that form part of OpenStack, not just the high profile ones. For this mission 
to be fulfilled, it will be essential that this community which has been 
weakened by recent corporate redirections be rebuilt through the introduction 
of new participants and participating companies.

> Thanks in advance for your answers !
> 

[Amrith Kumar] Thanks for the question.

> --
> 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 Development Mailing 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] Boston Forum Schedule

2017-04-10 Thread Thierry Carrez

David Medberry wrote:
> Are the three rooms roughly the same size?

102 and 103 are slightly larger than 104.
Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-03-29 5:06 GMT+09:00 Matt Riedemann :
> On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
>>
>> Hi,
>>
>> I would like to raise a topic when horizon nova-network support can be
>> dropped.
>> I added [tc] tag as it is related to
>> "assert:follows-standard-deprecation" tag in the governance.
>>
>> Can horizon drop nova-network support based on the deprecation of
>> nova-network
>> from the nova team?
>> or does horizon need to deprecate nova-network support in horizon
>> explicitly?
>>
>> Let me summarize the current situation:
>> - nova team deprecated nova-network in Newton release. [1]
>> - horizon team has not deprecated it so far (just forgot to do it).
>> - nova-network security group and floating IP support has been dropped
>> from novaclient few days ago [2].
>> - When a new release of novaclient comes, horizon security group
>> support will be broken (if neutron is not used)
>> - Nova microversion also allows to use nova-network but old version of
>> novaclient is required for horizon to
>>   support it and it is not realistic.
>
>
> This is the tricky part. You can specify a microversion to use novaclient
> with the nova-network behavior. If you're using the python API bindings in
> novaclient, which I think Horizon is, then you have to specify a
> microversion anyway. The nova-network API bindings in novaclient will work
> up until 2.35.

Sorry for my late.

Yes, nova supports nova-network API in API version up to 2.35.
Horizon now consumes python bindings from novaclient with version 2
(not latest API version) unless we need to use more recent version.
Horizon just started micro versioning support in Pile and most work is
under development.

> The messy part about this is when we release novaclient 8.0 then that code
> is gone and microversions don't matter. So you'd have to use an older
> version, 7.1.0 at this point. To do that, we have to essentially cap
> novaclient to 7.1.0 in upper-constraints in the requirements repo for the
> rest of Pike since Horizon won't work with 8.0.

Yeah, this is the most tricky part.

Is there any deprecation policy in novaclient python binding?
I was not aware of deprecation warnings.
If novaclient follows nova deprecation, it sounds reasonable to me.

> I don't want to cap novaclient in upper-constraints for the rest of Pike,
> but at the same time, it's not great to just drop features out of a UI
> without first telling users they are deprecated first. However, having said
> that, isn't Horizon really the portal for the tenant user? I know admins use
> it also, but the admin/operator should already know about the nova-network
> deprecation. If they are just finding out about this because their Horizon
> features all of a sudden don't work in Pike, that's pretty bad on their
> part, in my opinion anyway. In this perspective, I think it might be OK to
> drop nova-network support without a deprecation period in Horizon for the
> things we've removed from novaclient.

Horizon is both for tenant users and admin/operators.
In my understanding, operators need to know deprecation notices of various
projects and decide which version they should provide.
This applies to horizon too. If they want to provide nova-network
support in horizon,
they can choose a way not to upgrade horizon to Pike.
Nova already deprecated nova-network after Nova API 2.36 and this means
users cannot use newer features anymore as if a newer API version is used
nova-network is not take into account. What is the merit of upgrading
nova and horizon?

Considering the above, it looks okay to me to drop nova-network support
from horizon in Pike based on nova-team deprecation of nova-network in Newton.

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.

Akihiro

>
>>
>> It would be nice that horizon team is allowed to drop some feature
>> aligning with feature deprecation
>> and drop in backend project(s) (without explicit deprecation notices
>> in horizon side).
>>
>> It is not easy that horizon team is aware of all feature deprecations
>> in other projects
>> and the horizon team tends to be aware of them when the deprecated
>> features are
>> actually dropped.
>>
>> Thought?
>>
>> There may be things and solutions I am not aware of. Any feedback
>> would be appreciated.
>
>
> Me too. :)
>
>>
>> Best Regards,
>> Akihiro
>>
>> [1]
>> https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
>> [2] https://review.openstack.org/#/c/447707/
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Developm

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

I am okay to drop nova-network feature in Pike.

More generally, can we horizon team say the following?

 A feature deprecated in a back-end project is automatically
deprecated in Horizon
 and a feature in horizon will be dropped if a corresponding support
is dropped in
 a back-end project and/or its support library (like python bindings)
 even though horizon may provide an extended supports.

Akihiro

2017-03-29 7:02 GMT+09:00 Rob Cresswell :
> Frankly, it sounds like we can pretty comfortably drop support for nova-net
> in Pike. I'm fine with that, from a Horizon point of view.
>
> Rob
>
> On 28 March 2017 at 21:06, Matt Riedemann  wrote:
>>
>> On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
>> > Hi,
>> >
>> > I would like to raise a topic when horizon nova-network support can be
>> > dropped.
>> > I added [tc] tag as it is related to
>> > "assert:follows-standard-deprecation" tag in the governance.
>> >
>> > Can horizon drop nova-network support based on the deprecation of
>> > nova-network
>> > from the nova team?
>> > or does horizon need to deprecate nova-network support in horizon
>> > explicitly?
>> >
>> > Let me summarize the current situation:
>> > - nova team deprecated nova-network in Newton release. [1]
>> > - horizon team has not deprecated it so far (just forgot to do it).
>> > - nova-network security group and floating IP support has been dropped
>> > from novaclient few days ago [2].
>> > - When a new release of novaclient comes, horizon security group
>> > support will be broken (if neutron is not used)
>> > - Nova microversion also allows to use nova-network but old version of
>> > novaclient is required for horizon to
>> >   support it and it is not realistic.
>>
>> This is the tricky part. You can specify a microversion to use
>> novaclient with the nova-network behavior. If you're using the python
>> API bindings in novaclient, which I think Horizon is, then you have to
>> specify a microversion anyway. The nova-network API bindings in
>> novaclient will work up until 2.35.
>>
>> The messy part about this is when we release novaclient 8.0 then that
>> code is gone and microversions don't matter. So you'd have to use an
>> older version, 7.1.0 at this point. To do that, we have to essentially
>> cap novaclient to 7.1.0 in upper-constraints in the requirements repo
>> for the rest of Pike since Horizon won't work with 8.0.
>>
>> I don't want to cap novaclient in upper-constraints for the rest of
>> Pike, but at the same time, it's not great to just drop features out of
>> a UI without first telling users they are deprecated first. However,
>> having said that, isn't Horizon really the portal for the tenant user? I
>> know admins use it also, but the admin/operator should already know
>> about the nova-network deprecation. If they are just finding out about
>> this because their Horizon features all of a sudden don't work in Pike,
>> that's pretty bad on their part, in my opinion anyway. In this
>> perspective, I think it might be OK to drop nova-network support without
>> a deprecation period in Horizon for the things we've removed from
>> novaclient.
>>
>> >
>> > It would be nice that horizon team is allowed to drop some feature
>> > aligning with feature deprecation
>> > and drop in backend project(s) (without explicit deprecation notices
>> > in horizon side).
>> >
>> > It is not easy that horizon team is aware of all feature deprecations
>> > in other projects
>> > and the horizon team tends to be aware of them when the deprecated
>> > features are
>> > actually dropped.
>> >
>> > Thought?
>> >
>> > There may be things and solutions I am not aware of. Any feedback
>> > would be appreciated.
>>
>> Me too. :)
>>
>> >
>> > Best Regards,
>> > Akihiro
>> >
>> > [1]
>> > https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
>> > [2] https://review.openstack.org/#/c/447707/
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> --
>>
>> 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 Development Mailing 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.ope

Re: [openstack-dev] Boston Forum Schedule

2017-04-10 Thread Emilien Macchi

On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco  wrote:
> On 10/04/17 17:35 +0800, Tom Fifield wrote:
>>
>> Hi everyone,
>>
>> Thank you for the many excellent topics submitted for our first Forum. We
>> have updated the topic submission site with the status of each - please
>> check yours.
>>
>> Please also find attached in PDF the proposed schedule for the Forum in
>> Boston.
>>
>>
>> Let us know if you see major issues with it. As Thierry said in design
>> summits past; "It's difficult to make too many changes at this stage as they
>> quickly cascade into breaking all sorts of constraints, but we may still be
>> able to accommodate some." :)
>>
>> Eagle-eyed readers will see that there are a number of slots in gray (on
>> Thursday afternoon). These are being deliberately kept aside for the usual
>> few critical topics that come up in the next few weeks and also for the
>> discoveries we make in the first 3 days of the summit.
>>
>> We'll soon publish the Forum sessions on the main schedule, using the
>> title, abstracts and moderators you submitted, but look forward to your
>> feedback in the mean-time!
>>
>> Thank you all very much for making our first Forum a success.
>>
>>
>
> Hey Folks,
>
> Thanks for working on this.
>
> The topic "Future of configuration management tools" seems to have been
> scheduled twice. Is that expected or a mistake? In the schedule it's not
> explicit whether it's a 2 parts topic or not.

Good point. I think 1 session to keep is enough and I checked both
slots, we can pick one of those, I don't see much conflict that would
prevent folks to have to make an hard choice.

Tom, any chance to remove the second slot please?

Thanks!

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



-- 
Emilien Macchi

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:
> (question not directly related to this topic)
> I am not sure there is a case where users still use API 2.36 for
> network management
> and newer API versions for other compute operation.

This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [Keystone][Token expiration]

2017-04-10 Thread lương hữu tuấn

Thanks Dolph,

I now have a pretty clear picture about it.

Br,

Tuan/Nokia

On Mon, Apr 10, 2017 at 2:58 PM, Dolph Mathews 
wrote:

> The token itself is still expired, regardless of where it's persisted, if
> at all. Expired tokens are only considered valid when presented as an
> X-Auth-Token to keystonemiddleware.auth_token along with a valid
> X-Service-Token, or when validating an X-Subject-Token against keystone
> directly using either:
>
>   HEAD /v3/auth/token?allow_expired
>   GET /v3/auth/token?allow_expired
>
> No configuration is required in keystone.conf to enable the feature.
>
> More documentation is available in the release notes [1][2] and in the
> sample configuration file [3] (see [token] allow_expired_window).
>
> [1] https://docs.openstack.org/releasenotes/keystone/ocata.
> html#new-features
> [2] https://docs.openstack.org/releasenotes/keystone/ocata.
> html#upgrade-notes
> [3] https://docs.openstack.org/ocata/config-reference/
> identity/samples/keystone.conf.html
>
> On Mon, Apr 3, 2017 at 7:58 AM lương hữu tuấn 
> wrote:
>
>> Hi Dolph,
>>
>> Thanks for reply, it means that from the db point of view, token is
>> expired but it is still passed to other service users in request (token
>> stored in memory?) and keystone allows this expired token? And to make this
>> feature working, we should apply the header of "X-Service-Token" and change
>> of "allow_expired" in keystone.conf.
>>
>> Br,
>>
>> Tuan/Nokia
>>
>> On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews 
>> wrote:
>>
>> > does it mean that the token now will live forever
>>
>> No; it behaves as described in the document you linked. If you have any
>> specific security concerns, please raise them appropriately (such as a
>> security bug, if necessary).
>>
>> On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn 
>> wrote:
>>
>> Hi keystone folks,
>>
>> I have had a chance to take a look to this below patch for allowing the
>> expired token and it was merged in Octaka:
>>
>> https://specs.openstack.org/openstack/keystone-specs/
>> specs/keystone/ocata/allow-expired.html
>>
>> In our project, we also have problem with token expiration when running
>> mistral workflow. I have a concern that if this patch works as it does,
>> does it mean that the token now will live forever ("forever" seems so
>> sloppy, but it seems like the token is no longer expired). In this case, it
>> seems not good for security purpose.
>>
>> Br,
>>
>> Tuan/Nokia
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> -Dolph
>>
>> 
>> __
>> OpenStack Development Mailing 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
>>
> --
> -Dolph
>
> __
> OpenStack Development Mailing 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] Boston Forum Schedule

2017-04-10 Thread Tom Fifield


On 10/04/17 22:19, Emilien Macchi wrote:

On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco  wrote:

On 10/04/17 17:35 +0800, Tom Fifield wrote:


Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. We
have updated the topic submission site with the status of each - please
check yours.

Please also find attached in PDF the proposed schedule for the Forum in
Boston.


Let us know if you see major issues with it. As Thierry said in design
summits past; "It's difficult to make too many changes at this stage as they
quickly cascade into breaking all sorts of constraints, but we may still be
able to accommodate some." :)

Eagle-eyed readers will see that there are a number of slots in gray (on
Thursday afternoon). These are being deliberately kept aside for the usual
few critical topics that come up in the next few weeks and also for the
discoveries we make in the first 3 days of the summit.

We'll soon publish the Forum sessions on the main schedule, using the
title, abstracts and moderators you submitted, but look forward to your
feedback in the mean-time!

Thank you all very much for making our first Forum a success.




Hey Folks,

Thanks for working on this.

The topic "Future of configuration management tools" seems to have been
scheduled twice. Is that expected or a mistake? In the schedule it's not
explicit whether it's a 2 parts topic or not.


Good point. I think 1 session to keep is enough and I checked both
slots, we can pick one of those, I don't see much conflict that would
prevent folks to have to make an hard choice.

Tom, any chance to remove the second slot please?



Yup, this was a mistake, sorry!


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

[openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for
neutron stadium projects?
There are several projects under neutron stadium and they are trying
to add dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard
(VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a
single repository
 for testing and translation supports. Each project needs to
explore the way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and
possible makes things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository
are implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

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

Re: [openstack-dev] [tripleo][ui] another i18n proposal for heat templates 'description' help strings

2017-04-10 Thread Julie Pichon

Hi Peng,

I added some thoughts in-line, let me know what you think.

On 10 April 2017 at 08:10, Peng Wu  wrote:
> Hi,
>
>   In TripleO UI project users requested translation of the web UI. But
> some web UI strings are displayed from heat template files in tripleo-
> heat-templates project.
>
>   In order to get translated templates displayed in tripleo-ui, we
> propose another solution as follows, which needs to change code in
> tripleo-heat-templates and tripleo-ui projects.
>
>   I18n proposal for Heat templates 'description' help strings
>
>   1. Update tripleo-heat-templates to generate the javascript files to
> include all translation strings, like "tripleo-heat-templates.js"
>
>  a. Need to write python script to extract "title" and
> "description" field from yaml files and generate "tripleo-heat-
> templates.js" for react-intl usage in tripleo-ui

I think extracting the strings directly into js/json format may be not
be a viable option, because it isn't a format supported by
Zanata [1].

For tripleo-ui itself we use react-intl which expects json, and work
with scripts to convert to/from pot and po (see [2]) which are fully
supported by Zanata.

Or is the idea that we'd also generate pot/po as intermediary steps and
only store json in the repo?

>  b. Use default message as message id or consider nodejs-i18n for
> tripleo-ui

I'm wary of considering a library change considering the amount of
churn it would cause in the code base for all the existing strings,
plus that would then make backports more difficult. It really needs to
be considered carefully.

>
>   2. Update tripleo-ui to use "tripleo-heat-templates.js"
>
>  a. Write some script to sync "tripleo-heat-templates.js" from
> tripleo-heat-templates
>
>  b. Call formatMessage function for "title" and "description" field
> with message id (use default message) and default message or consider
> nodejs-i18n for tripleo-ui
>
>   Refer URL for message id: https://github.com/yahoo/react-intl/issues/
> 912

Could you explain a bit more the issue with the ids? I see us defining
an id in every message [3] and this is how they are referenced in the
locale json [4] (the mapping is not done by message, but by ID).

When it comes to the THT message, I think they all have a hierarchy
that perhaps could be used as a key to map between the original string
and the translation? Something along the lines of
OS::TripleO::Services::Apache::ApacheMaxRequestWorkers::description,
whichever form the API gives us at the moment.

>   Please evaluate it, thanks!

Thank you!

Julie

[1] 
http://docs.zanata.org/en/release/user-guide/projects/project-types/#supported-types
[2] 
https://github.com/openstack/tripleo-ui/blob/master/docs/translation.rst#extracting-messages-from-components
[3] 
https://github.com/openstack/tripleo-ui/blob/master/src/js/components/nodes/Nodes.js#L17
[4] https://github.com/openstack/tripleo-ui/blob/master/i18n/locales/es.json#L3

__
OpenStack Development Mailing 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][nova][tc] nova-network deprecation in horizon


On 4/10/2017 8:58 AM, Akihiro Motoki wrote:


Is there any deprecation policy in novaclient python binding?
I was not aware of deprecation warnings.
If novaclient follows nova deprecation, it sounds reasonable to me.


Yes we deprecated the CLIs in this change in Newton:

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

That would emit a deprecation warning if you're using the CLIs. If you 
were using the latest microversion on those CLIs and it wasn't 
supported, we softened the blow by falling back to 2.35 so things would 
still work. That was dropped in the novaclient 8.0.0 release in Pike. 
There was also a pretty massive release note with that change.


The change to deprecate the API bindings came after it, but also in Newton:

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

I guess we weren't emitting a DeprecationWarning using the warnings.warn 
method on those, maybe we should have. That's what Horizon would have 
seen though, and probably why Horizon never noticed. The APIs were 
capped at 2.35 though, and a client specifically opting into >2.35 on 
those APIs would fail. Since Horizon hasn't been using nova 
microversions with the novaclient API bindings until now, again that is 
probably why no one in Horizon noticed.


--

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] [horizon][nova][tc] nova-network deprecation in horizon


On 4/10/2017 9:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt



As noted in my reply to Akihiro, the CLIs/APIs were deprecated in 
novaclient back in Newton in the 6.0.0 release of python-novaclient. We 
left them through Ocata and dropped them here in Pike in 8.0.0.


How long are we expected to be carrying this deprecated bridge code? If 
you need these CLIs/API bindings in the client, then don't upgrade to 
8.0.0, or run different versions of novaclient in venvs or containers if 
you need to really workaround this.


I feel like the signaling on all of this was pretty clear back in 
Newton. What else are people expecting or that we missed? I don't really 
see why python-openstackclient needs to start adding this API binding 
code back in locally, that's just extending the lifespan of this busted 
code that we're really trying to make uncomfortable for people to be 
using because like it or not, nova-network is going away. We did the 
fallback thing in the CLI in newton as a way to soften that blow for CLI 
users, but really at some point this just needs to be broken and people 
either stay on old tools or upgrade to what is supported.


--

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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-10 Thread Doug Hellmann

Excerpts from Akihiro Motoki's message of 2017-04-11 00:09:10 +0900:
> Hi neutrinos (and horizoners),
> 
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
> 
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
> 
> Possible approaches
> 
> 
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
> 
> Which one sounds better?
> 
> Pros and Cons
> 
> 
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
> 
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
> 
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
> 
> 
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
> 
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
> 
> Thanks,
> Akihiro
> 

From the release team's perspective, we would prefer (a), because
having one deliverable per package simplifies packaging and makes
more sense for deployments (no one would end up with dashboard
panels for features not supported by the backend).

Doug

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 23:19 GMT+09:00 Dean Troyer :
> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:
>> (question not directly related to this topic)
>> I am not sure there is a case where users still use API 2.36 for
>> network management
>> and newer API versions for other compute operation.
>
> This is probably true for Horizon, where the app install likely
> matches the cloud it is configured to use.  However, many other use
> cases for the Python libraries are meant to talk to multiple versions
> of clouds and the 8.0 release of novaclient causes problems there.
>
> Even after nova-net support is EOL officially OSC plans to support the
> use of nova-net for some time.  We are re-implementing the removed
> functionality locally.  And anticipating some of the questions why,
> consider an operator working on the long migration/upgrade from a
> deployed nova-net cloud to a Neutron cloud, and needing to keep at
> least one foot in both worlds.  There are other similar uses.

This topic on novaclient 8.0.0 raised me a question on our python
binding support policy.
I see two points:

- The one is which API version should be supported by a python binding
from a same release.
For example, Pike novaclient supports >2.36 of Nova API while Nova
still supports <=2.35 API.
Python bindings should support a whole set of supported API or a
subset of supported API
(of course including 'latest' version of API).

- The other is about multi cloud use cases. Different OpenStack clouds
may use different releases
and client libraries need to support

The latter covers broader range of use cases.

Akihiro

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

__
OpenStack Development Mailing 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][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Sean Dague

On 04/10/2017 11:19 AM, Matt Riedemann wrote:
> On 4/10/2017 9:19 AM, Dean Troyer wrote:
>> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
>> wrote:
>>> (question not directly related to this topic)
>>> I am not sure there is a case where users still use API 2.36 for
>>> network management
>>> and newer API versions for other compute operation.
>>
>> This is probably true for Horizon, where the app install likely
>> matches the cloud it is configured to use.  However, many other use
>> cases for the Python libraries are meant to talk to multiple versions
>> of clouds and the 8.0 release of novaclient causes problems there.
>>
>> Even after nova-net support is EOL officially OSC plans to support the
>> use of nova-net for some time.  We are re-implementing the removed
>> functionality locally.  And anticipating some of the questions why,
>> consider an operator working on the long migration/upgrade from a
>> deployed nova-net cloud to a Neutron cloud, and needing to keep at
>> least one foot in both worlds.  There are other similar uses.
>>
>> dt
>>
> 
> As noted in my reply to Akihiro, the CLIs/APIs were deprecated in
> novaclient back in Newton in the 6.0.0 release of python-novaclient. We
> left them through Ocata and dropped them here in Pike in 8.0.0.
> 
> How long are we expected to be carrying this deprecated bridge code? If
> you need these CLIs/API bindings in the client, then don't upgrade to
> 8.0.0, or run different versions of novaclient in venvs or containers if
> you need to really workaround this.
> 
> I feel like the signaling on all of this was pretty clear back in
> Newton. What else are people expecting or that we missed? I don't really
> see why python-openstackclient needs to start adding this API binding
> code back in locally, that's just extending the lifespan of this busted
> code that we're really trying to make uncomfortable for people to be
> using because like it or not, nova-network is going away. We did the
> fallback thing in the CLI in newton as a way to soften that blow for CLI
> users, but really at some point this just needs to be broken and people
> either stay on old tools or upgrade to what is supported.

Right, I guess I'm confused why the operator in that case would just
keep the older version installed. It's not being deleted from pypi.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] Boston Forum Schedule


On 4/10/2017 4:35 AM, Tom Fifield wrote:

Hi everyone,

Thank you for the many excellent topics submitted for our first Forum.
We have updated the topic submission site with the status of each -
please check yours.

Please also find attached in PDF the proposed schedule for the Forum in
Boston.


Let us know if you see major issues with it. As Thierry said in design
summits past; "It's difficult to make too many changes at this stage as
they quickly cascade into breaking all sorts of constraints, but we may
still be able to accommodate some." :)

Eagle-eyed readers will see that there are a number of slots in gray (on
Thursday afternoon). These are being deliberately kept aside for the
usual few critical topics that come up in the next few weeks and also
for the discoveries we make in the first 3 days of the summit.

We'll soon publish the Forum sessions on the main schedule, using the
title, abstracts and moderators you submitted, but look forward to your
feedback in the mean-time!

Thank you all very much for making our first Forum a success.


Regards,

Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee


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



There are some forum topic sessions still marked as Incomplete, like in 
some cases asking for a rewrite of the abstract. Assuming people 
addressed the comments associated with the Incomplete status, when is 
the next round of reviews on those proposed sessions to see if they are 
going to be accepted now?


--

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] Boston Forum Schedule

2017-04-10 Thread Thiago da Silva

Looks like " Swift cluster level metrics and analytics" is also scheduled
twice.

Thiago

>
On Mon, Apr 10, 2017 at 11:03 AM, Tom Fifield  wrote:

> On 10/04/17 22:19, Emilien Macchi wrote:
>
>> On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco 
>> wrote:
>>
>>> On 10/04/17 17:35 +0800, Tom Fifield wrote:
>>>

 Hi everyone,

 Thank you for the many excellent topics submitted for our first Forum.
 We
 have updated the topic submission site with the status of each - please
 check yours.

 Please also find attached in PDF the proposed schedule for the Forum in
 Boston.

 Let us know if you see major issues with it. As Thierry said in design
 summits past; "It's difficult to make too many changes at this stage as
 they
 quickly cascade into breaking all sorts of constraints, but we may
 still be
 able to accommodate some." :)

 Eagle-eyed readers will see that there are a number of slots in gray (on
 Thursday afternoon). These are being deliberately kept aside for the
 usual
 few critical topics that come up in the next few weeks and also for the
 discoveries we make in the first 3 days of the summit.

 We'll soon publish the Forum sessions on the main schedule, using the
 title, abstracts and moderators you submitted, but look forward to your
 feedback in the mean-time!

 Thank you all very much for making our first Forum a success.

>>> Hey Folks,
>>>
>>> Thanks for working on this.
>>>
>>> The topic "Future of configuration management tools" seems to have been
>>> scheduled twice. Is that expected or a mistake? In the schedule it's not
>>> explicit whether it's a 2 parts topic or not.
>>>
>>
>> Good point. I think 1 session to keep is enough and I checked both
>> slots, we can pick one of those, I don't see much conflict that would
>> prevent folks to have to make an hard choice.
>>
>> Tom, any chance to remove the second slot please?
>>
>>
> Yup, this was a mistake, sorry!

>
>
> __
> OpenStack Development Mailing 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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Pavlo Shchelokovskyy

Hi infra team,

on order to test a piece of functionality I am developing, during the
devstack plugin run I need to create an extra user with password-less sudo
permissions. As I am not sure of intricacies of our infra setup, I'd like
to clarify if it is acceptable.

TL;DR
There is 'openstack/networking-generic-switch' project that mainly aims to
provide a Neutron ML2 plugin suitable to manage cheap HW switches that only
allow configuration over SSH. The problem with those is that these switches
usually have limitations on the number of concurrent SSH sessions open on
the switch.

In order to overcome this, I am attempting to introduce DLM to
networking-generic-switch to globally limit the number of active SSH
connections to a given switch across all threads of neutron-service on all
hosts [0].

To test this locally in my Xenial DevStack VM, I am creating and
configuring "ovsmanager" user with password-less sudo permissions (so it is
able to manage OVS), limit the number of allowed sessions for that user in
/etc/security/limits.d/ and configure networking-generic-switch to access
localhost via that user to simulate a switch with limited number
of allowed SSH sessions.

My questions is is it ok if I replicate this logic in the devstack plugin
of networking-generic-switch to set up gate testing for this feature?
In the end it seems it boils down to whether infra re-uses VMs it creates
to run gate jobs for anything else and if such changes can affect those
re-using these VMs, but I might be missing something else.

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

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon


On 04/10/2017 09:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.


I agree - I think it is not important for horizon to support backward 
compat - it's most commonly deployed with a cloud, so one expects it to 
support the software in the cloud in question.



However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


Similarly, shade intends to support nova-net for as long as shade 
exists. We have already re-implemented most of nova-net support with 
direct calls as part of our current project to delete use of python-*client.


It turns out there are humans out there who are consuming old clouds - 
and end-user client tools should be supporting those humans, even when 
the current releases of OpenStack deprecate/remove things.


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

[openstack-dev] [puppet] Meeting April 11, 2017 @1500 UTC

2017-04-10 Thread Alex Schultz

Just a reminder, we have a meeting scheduled tomorrow April 11, 2017
@1500UTC[0]. Please add something to the agenda[1] if you have
something you would like to talk about.

Thanks,
-Alex

[0] https://docs.openstack.org/developer/puppet-openstack-guide/meetings.html
[1] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170411

__
OpenStack Development Mailing 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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Clark Boylan

On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> Hi infra team,
> 
> on order to test a piece of functionality I am developing, during the
> devstack plugin run I need to create an extra user with password-less
> sudo
> permissions. As I am not sure of intricacies of our infra setup, I'd like
> to clarify if it is acceptable.
> 
> TL;DR
> There is 'openstack/networking-generic-switch' project that mainly aims
> to
> provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> only
> allow configuration over SSH. The problem with those is that these
> switches
> usually have limitations on the number of concurrent SSH sessions open on
> the switch.
> 
> In order to overcome this, I am attempting to introduce DLM to
> networking-generic-switch to globally limit the number of active SSH
> connections to a given switch across all threads of neutron-service on
> all
> hosts [0].
> 
> To test this locally in my Xenial DevStack VM, I am creating and
> configuring "ovsmanager" user with password-less sudo permissions (so it
> is
> able to manage OVS), limit the number of allowed sessions for that user
> in
> /etc/security/limits.d/ and configure networking-generic-switch to access
> localhost via that user to simulate a switch with limited number
> of allowed SSH sessions.
> 
> My questions is is it ok if I replicate this logic in the devstack plugin
> of networking-generic-switch to set up gate testing for this feature?
> In the end it seems it boils down to whether infra re-uses VMs it creates
> to run gate jobs for anything else and if such changes can affect those
> re-using these VMs, but I might be missing something else.
> 
> [0] https://review.openstack.org/#/c/452959/

The test instances that run devstack are single use VMs that are not
reused. Every job running on these instances starts with sudo access,
but by default we remove sudo access for the stack user which is what
the OpenStack services run as. We do this to force those services to use
rootwrap (or its equivalent) and test that the rootwrap rules are
functional.

As long as you create your new user during the initial devstack run you
shouldn't have any issues with this.

It wasn't mentioned above, but I would run a separate sshd for this
rather than modify the existing one as ssh is the control mechanism for
the test jobs. Better to run a separate independent service that won't
conflict with job control.

Hope this helps,
Clark

__
OpenStack Development Mailing 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][nova][tc] nova-network deprecation in horizon


On 04/10/2017 10:37 AM, Monty Taylor wrote:

On 04/10/2017 09:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.


I agree - I think it is not important for horizon to support backward
compat - it's most commonly deployed with a cloud, so one expects it to
support the software in the cloud in question.


However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


Similarly, shade intends to support nova-net for as long as shade
exists. We have already re-implemented most of nova-net support with
direct calls as part of our current project to delete use of
python-*client.



It turns out there are humans out there who are consuming old clouds -
and end-user client tools should be supporting those humans, even when
the current releases of OpenStack deprecate/remove things.


Quick clarification ...

When I say "shade intends to support nova-net" - I mean a specific thing 
that is almost certainly not what you might at first assume.


From the beginning, shade has hidden the nova-net/neutron difference - 
but shade is focused on the end-user primarily. This means the 
difference is "do you use nova or neutron API to deal with floating IPs 
and security groups" We do not expose any nova-net functionality 
directly - we expose FIPs and Security Groups, and we hide from the user 
what service provides them.


We will continue to do that to the best of our ability - although 
functional testing in devstack will have to give way to only 
requests-mock based testing once we don't have old stable branches that 
can install nova-net.


I may have also given the impression that I'm unhappy about novaclient 
dropping support - which is also not the case. I am firmly of the 
opinion that python-*client do not have end-users of OpenStack clouds as 
primary users in mind. The release model and design just isn't right for 
that. They are clearly, to me, designed to aid intra-service 
communication. As such, I think it's 100% appropriate for novaclient to 
have dropped nova-net support.


I, for one, welcome all things about the removal of nova-net, and I am 
quite happy to do the support actions in shade.


__
OpenStack Development Mailing 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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Pavlo Shchelokovskyy

Clark,

thanks for reply.

On Mon, Apr 10, 2017 at 6:49 PM, Clark Boylan  wrote:

> On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> > Hi infra team,
> >
> > on order to test a piece of functionality I am developing, during the
> > devstack plugin run I need to create an extra user with password-less
> > sudo
> > permissions. As I am not sure of intricacies of our infra setup, I'd like
> > to clarify if it is acceptable.
> >
> > TL;DR
> > There is 'openstack/networking-generic-switch' project that mainly aims
> > to
> > provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> > only
> > allow configuration over SSH. The problem with those is that these
> > switches
> > usually have limitations on the number of concurrent SSH sessions open on
> > the switch.
> >
> > In order to overcome this, I am attempting to introduce DLM to
> > networking-generic-switch to globally limit the number of active SSH
> > connections to a given switch across all threads of neutron-service on
> > all
> > hosts [0].
> >
> > To test this locally in my Xenial DevStack VM, I am creating and
> > configuring "ovsmanager" user with password-less sudo permissions (so it
> > is
> > able to manage OVS), limit the number of allowed sessions for that user
> > in
> > /etc/security/limits.d/ and configure networking-generic-switch to access
> > localhost via that user to simulate a switch with limited number
> > of allowed SSH sessions.
> >
> > My questions is is it ok if I replicate this logic in the devstack plugin
> > of networking-generic-switch to set up gate testing for this feature?
> > In the end it seems it boils down to whether infra re-uses VMs it creates
> > to run gate jobs for anything else and if such changes can affect those
> > re-using these VMs, but I might be missing something else.
> >
> > [0] https://review.openstack.org/#/c/452959/
>
> The test instances that run devstack are single use VMs that are not
> reused. Every job running on these instances starts with sudo access,
> but by default we remove sudo access for the stack user which is what
> the OpenStack services run as. We do this to force those services to use
> rootwrap (or its equivalent) and test that the rootwrap rules are
> functional.
>
> As long as you create your new user during the initial devstack run you
> shouldn't have any issues with this.
>
> It wasn't mentioned above, but I would run a separate sshd for this
> rather than modify the existing one as ssh is the control mechanism for
> the test jobs. Better to run a separate independent service that won't
> conflict with job control.
>
> Hope this helps,
> Clark
>
>
I'm not going to control the number of sessions via SSH itself and change
the /etc/ssh/sshd_config, instead I'm going to create a file
/etc/security/limits.d/ovsmanager.conf (this is the place on Ubuntu Xenial)
with

# 
ovsmanager -   maxlogins   2

AFAIU this should not interfere with any other users and the number of
sessions/connections they are allowed (I would even prepend "ngs_" to the
created user name so it is clear what created it).

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon


On 04/10/2017 10:24 AM, Sean Dague wrote:

On 04/10/2017 11:19 AM, Matt Riedemann wrote:

On 4/10/2017 9:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt



As noted in my reply to Akihiro, the CLIs/APIs were deprecated in
novaclient back in Newton in the 6.0.0 release of python-novaclient. We
left them through Ocata and dropped them here in Pike in 8.0.0.

How long are we expected to be carrying this deprecated bridge code? If
you need these CLIs/API bindings in the client, then don't upgrade to
8.0.0, or run different versions of novaclient in venvs or containers if
you need to really workaround this.

I feel like the signaling on all of this was pretty clear back in
Newton. What else are people expecting or that we missed? I don't really
see why python-openstackclient needs to start adding this API binding
code back in locally, that's just extending the lifespan of this busted
code that we're really trying to make uncomfortable for people to be
using because like it or not, nova-network is going away. We did the
fallback thing in the CLI in newton as a way to soften that blow for CLI
users, but really at some point this just needs to be broken and people
either stay on old tools or upgrade to what is supported.


Right, I guess I'm confused why the operator in that case would just
keep the older version installed. It's not being deleted from pypi.


I think it's, as usual, two different use cases. The operator and the 
end-user are different. I think nova has done an excellent job signaling 
this for operators.


However, one of the places where it may have fallen down is that users 
of python-openstackclient are not necessarily deployers, and they may 
also have accounts on clouds that still force people through the nova 
proxy apis - (and hell no to having a copy of python-openstackclient for 
each cloud, that's crazy)- AND - python-openstackclient depends on 
python-novaclient.


python-openstackclient is fixing this the same way as shade - not using 
python-novaclient but instead using REST calls. I think this is the 
right solution.


But right solution or not right solution, python-*client have 
historically been the thing we've pointed end-users at as a way to 
consume our clouds, and as much as we've been pushing moving the 
services forward, we haven't been as agressive in communicating to our 
end users to NEVER EVER EVER use python-*client for ANY REASON but 
instead to use python-openstackclient for command line and either shade 
or openstacksdk for python programming. A lot of that is inertia - 
people are used to typing "nova boot" - but the time is long past and 
this is a really great example of why it's really REALLY important to 
communicate strongly and clearly that end-users should not use the 
legacy python clients.


Monty

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon


On 04/10/2017 10:23 AM, Akihiro Motoki wrote:

2017-04-10 23:19 GMT+09:00 Dean Troyer :

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


This topic on novaclient 8.0.0 raised me a question on our python
binding support policy.
I see two points:

- The one is which API version should be supported by a python binding
from a same release.
For example, Pike novaclient supports >2.36 of Nova API while Nova
still supports <=2.35 API.
Python bindings should support a whole set of supported API or a
subset of supported API
(of course including 'latest' version of API).


I think that because we use python-*client for intraservice 
communication, a release of a client needs to support the previous 
release (otherwise rolling upgrades can go poorly) I think given 
structure at this point trying to support more is a thing we should not 
bother doing and we should be clear about that.


- The other is about multi cloud use cases. Different OpenStack clouds
may use different releases
and client libraries need to support

The latter covers broader range of use cases.


If you are a user who wants to use multi-clouds - use shade. As an end 
user, trying to use our python client bindings directly for multi-cloud 
is very painful.


__
OpenStack Development Mailing 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] [HA] HA Discussion at Boston Forum

2017-04-10 Thread Sam P

Hi All,

 I proposed a session [1] to Boston Forum and it is now at incomplete state.
 This is good opportunity for all of us to get together and discuss
our HA related issues.
 I need your help to reform this session.
 Please put comments on [1] or replay to this with your comments.

[1] http://forumtopics.openstack.org/cfp/details/117

--- Regards,
Sampath

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

[openstack-dev] [horizon] Unknown provider resource-type-registry.service test error

2017-04-10 Thread Beth Elwell

Hi all,

Thanks very much in advance for any help you are able to offer.

I have been working on developing the QoS Policies panel for horizon and have 
the panel working, however I am struggling with the qos.service.spec.js file. 
In advance of going into my findings and issues so far, the related patch is 
located at https://review.openstack.org/#/c/418828/ 
 

The error log is as follows: 

http://paste.openstack.org/show/606058/ 


 From that error log it looks to me 
like the resource-type-registry for neutron is not being defined, and the error 
appears with the link to the network_qos module as per line 19 
https://review.openstack.org/#/c/418828/28/openstack_dashboard/static/app/core/network_qos/qos.service.spec.js
 

 

However the resource-type-registry is definitely defined and I cannot see why 
this should be throwing errors.

It could well be I have just looked at this code for too long and my brain is 
skipping over something, but any help anyone can give on this would be 
massively appreciated.

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

Re: [openstack-dev] [tc] [elections] Available time and top priority

On Mon, Apr 10, 2017 at 4:16 AM, Thierry Carrez  wrote:
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

In the last six months of my abbreviated term on the TC I was able to
increase the amount of time I was able to spend on TC work, and most
of that time went toward the work for additional language supprot, and
specifically golang support with the creation of the Golang Consistent
Testing Interface.

I plan to continue that work whether I am re-elected to the TC or not.
There has been a lot of concern expressed regarding the community
impact of any alternate languages.  Specific experiences with projects
that have already been down that path (eg Horizon with Javascript)
indicate that these concerns can not be ignored.  Part of the
challenge is to not create a situation where the resulting
multi-language environment is totally foreign to any of the
communities involved.  We already have some of that problem in
OpenStack with the broader Python community (I'm looking at you, pbr),
I want to work to minimize that for the new environments and their
existing communities, but also for an OpenStack developer to feel
comfortable and for OpenStack practices to be as consistent as
possible to minimize the pain of moving among our projects.  This is a
tricky proposition but is even trickier without conscious and
intentional coordination.

Some of my other priorities for the TC include refining OpenStack's
identity and focus as we continue to adjust to our current realities.
I was excited to see the TC vision proposal released for general
comment and think this is a great opportunity to come together on
goals and ideals for our future.  Please read it if you have not
already!  https://review.openstack.org/#/c/453262

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [tripleo][manila] Ganesha deployment

2017-04-10 Thread Ben Nemec

I'm not really an expert on composable roles so I'll leave that to 
someone else, but see my thoughts inline on the networking aspect.


On 04/10/2017 03:22 AM, Jan Provaznik wrote:

2) define a new VIP (for IP failover) and 2 networks for NfsStorage role:
a) a frontend network between users and ganesha servers (e.g.
NfsNetwork name), used by tenants to mount nfs shares - this network
should be accessible from user instances.


Adding a new network is non-trivial today, so I think we want to avoid 
that if possible.  Is there a reason the Storage network couldn't be 
used for this?  That is already present on compute nodes by default so 
it would be available to user instances, and it seems like the intended 
use of the Storage network matches this use case.  In a Ceph deployment 
today that's the network which exposes data to user instances.



b) a backend network between ganesha servers ans ceph cluster -
this could just map to the existing StorageNetwork I think.


This actually sounds like a better fit for StorageMgmt to me.  It's 
non-user-facing storage communication, which is what StorageMgmt is used 
for in the vanilla Ceph case.



What i'm not sure at all is how network definition should look like.
There are following Overcloud deployment options:
1) no network isolation is used - then both direct ceph mount and
mount through ganesha should work because StorageNetwork and
NfsNetwork are accessible from user instances (there is no restriction
in accessing other networks it seems).


There are no other networks without network-isolation.  Everything runs 
over the provisioning network.  The network-isolation templates should 
mostly handle this for you though.



2) network isolation is used:
a) ceph is used directly - user instances need access to the ceph
public network (which is StorageNetwork in Overcloud) - how should I
enable access to this network? I filled a bug for this deployment
variant here [3]


So does this mean that the current manila implementation is completely 
broken in network-isolation?  If so, that's rather concerning.


If I'm understanding correctly, it sounds like what needs to happen is 
to make the Storage network routable so it's available from user 
instances.  That's not actually something TripleO can do, it's an 
underlying infrastructure thing.  I'm not sure what the security 
implications of it are either.


Well, on second thought it might be possible to make the Storage network 
only routable within overcloud Neutron by adding a bridge mapping for 
the Storage network and having the admin configure a shared Neutron 
network for it.  That would be somewhat more secure since it wouldn't 
require the Storage network to be routable by the world.  I also think 
this would work today in TripleO with no changes.


Alternatively I guess you could use ServiceNetMap to move the public 
Ceph traffic to the public network, which has to be routable.  That 
seems like it might have a detrimental effect on the public network's 
capacity, but it might be okay in some instances.



b) ceph is used through ganesha - user instances need access to
ganesha servers (NfsNetwork in previous paragraph) - how should I
enable access to this network?


I think the answer here will be the same as for vanilla Ceph.  You need 
to make the network routable to instances, and you'd have the same 
options as I discussed above.




The ultimate (and future) plan is to deploy ganesha-nfs in VMs (which
will run in Overcloud, probably managed by manila ceph driver), in
this deployment mode a user should have access to ganesha servers and
only ganesha server VMs should have access to ceph public network.
Ganesha VMs would run in a separate tenant so I wonder if it's
possible to manage access to the ceph public network (StorageNetwork
in Overcloud) on per-tenant level?


This would suggest that the bridged Storage network approach is the 
best.  In that case access to the ceph public network is controlled by 
the overcloud Neutron, so you would just need to only give access to it 
to the tenant running the Ganesha VMs.  User VMs would only get access 
to a separate shared network providing access to the public Ganesha API, 
and the Ganesha VMs would straddle both networks.




Any thoughts and hints?

Thanks, Jan

[1] https://github.com/nfs-ganesha/nfs-ganesha/wiki
[2] https://github.com/ceph/ceph-ansible/tree/master/roles/ceph-nfs
[3] https://bugs.launchpad.net/tripleo/+bug/1680749


__
OpenStack Development Mailing 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] [os-upstream-institute] Meeting Reminder

2017-04-10 Thread Kendall Nelson

Hello!

Just wanted to remind everyone of our meeting today at 20:00 UTC in
#openstack-meeting-3

Please feel free to add items to the agenda:
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

Also, please take a look at the slides so we can focus on improvements
rather than discussing what is already there.

https://docs.openstack.org/upstream-training/

All the Best,

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

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Chris Dent


On Mon, 10 Apr 2017, Thierry Carrez wrote:


So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I've been regularly reviewing changes in the governance repo and
attending the weekly TC meeting for well over a year now. Increasing
that commitment to include shepherding new initiatives, either ones
I start myself or work on in concert with others, is why I'm running
for the TC and I wouldn't be doing so if I didn't think I had the
time and energy to support that.

Making a specific prediction on how much time that will take is
challenging; some weeks will take more time than others. I intend to
do what's needed to do the job well.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


Just ONE initiative is difficult because from my perspective what
matters is that whatever initiatives happen to be in progress, they
are transparent, inclusive and actually make some kind of
difference. But since ONE is the request:

My hallmark complaint with the TC since I was first aware of it has
been that, often, resolutions or plans can emerge from the TC so
late in their development that engaging them in a way that allows
consideration of completely different options is hard. Hard for a
variety of reasons; one is that it can feel a bit rude to criticize
a complete seeming idea that someone clearly put a lot of effort
into. This means discussion proceeds as an evaluation of the
proposal rather than as analysis of the root causes of the problems
to be solved or the full consequences of the goals being described.

This situation has improved over the years, I think there is at
least increased awareness, and some concrete efforts to allow people
to be involved, but we can do more to make it easier and lighter.

I would prefer that the TC's constituency was more actively made
aware of pending work and ongoing debates prior to the creation of
resolutions (even if WIP) in gerrit or having big sessions at the
Forum.  One way to do this would be to follow the growing trend of
weekly newsletters and updates and do one for the TC. I recall this
was tried (in the form of blog posts, and to some extent in response
to my prompting) a while back, but didn't really take off. I
wonder if that format was too heavyweight?

I'm proud of having played a part in the newsletter trend and I
think the results for the API-WG and the placement project have been
very positive. Doing something similar for the TC -- in a
lightweight, just-the-highlights kind of way -- is something I could
do (I hope with the occasional help of the rest of the TC) and is
something I think would be useful. With luck the newsletter would
operate as a catalyst around which casual discussion and idea
sharing would accrete.

What I hope would happen as a result is that people would feel more
aware of and able to participate in the discussion and processes
working to shape the future of OpenStack.

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

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread German Eichberger

Hi,

I am well aware that being on the TC is a serious time commitment and that 
there is more to do than a given day has hours. So I read your question more 
about prioritizing and how I would do that. A fair part of how I prioritize 
depends on input from others. That’s why I said listening to operators, 
developers, and end users is key. This will inform where I will try to spend my 
time. As for my big initiative, I want to push my heart is with small or 
underfunded projects and making life easier for them. I don’t think this can be 
done with one big thing but rather small steps like better mentoring, 
documentation,  better visibility by inviting them to say the Forum in Boston, 
but first and foremost helping them to have a voice at the TC.  

Thanks,
German

On 4/10/17, 5:16 AM, "Thierry Carrez"  wrote:

Hi everyone,

New in this TC election round, we have a few days between nominations
and actual voting to ask questions and get to know the candidates a bit
better. I'd like to kick off this new "campaigning period" with a basic
question on available time and top priority.

All the candidates are top community members with a lot of
responsibilities on their shoulders already. My experience tells me that
it is easy to overestimate the time we can dedicate to Technical
Committee matters, and how much we can push and get done in six months
or one year. At the same time, our most efficient way to make progress
is always when someone "owns" a particular initiative and pushes it
through the governance process.

So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ? If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?

Thanks in advance for your answers !

-- 
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Ed Leafe

On Apr 10, 2017, at 4:16 AM, Thierry Carrez  wrote:

> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ?

Well, as you know I have been active with the TC for years now, even though 
I've never been elected to a position on the TC. Since so many of the issues 
that the TC deals with are important to OpenStack's future, I like to 
contribute to bettering that wherever I can. So if elected to serve on the TC, 
I would be able to focus even more of my time, going from maybe 5-10% now, to 
50% if elected.

> If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

Just one? If I had to choose, I would like to see a clear separation between 
the core services that provide IaaS, and the products that then build on that 
core. They occupy very different places in the OpenStack picture, and should be 
treated differently. The IaaS parts (and yes, I know that just which parts 
these are is a whole debate in itself) should be rock-solid, slow-moving, and, 
well, boring. Reliability is the key for them. But for the services and 
applications that are built on top of this base? I'd like to see allowing them 
a much more open approach: let them develop in whatever language they like, 
release when they feel the timing is right, and define their own CI testing. In 
other words, if you want to develop in a language other than Python, go for it! 
If you want to use a particular NoSQL database, sure thing! However, the price 
of that freedom is that the burden will be on the project to ensure that it is 
adequately tested, instead of laying that responsibility on our infra team. 
Such projects will also have to accept a tag such as 'experimental' or 
'untested' until they can demonstrate otherwise. This can also serve to 
encourage the development of additional testing resources around, say, Golang 
projects, so that the Golang community can all pitch in and develop the sort of 
infrastructure needed to adequately test their products, both alone and in 
conjunction with the IaaS core of OpenStack. The only thing that should be 
absolute is a project's commitment to the Four Opens. There will be winners, 
and there will be losers, and that's not only OK, it's how it should be.

-- Ed Leafe

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

[openstack-dev] [ironic] this week's priorities and subteam reports

2017-04-10 Thread Yeleswarapu, Ramamani

Hi,

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

This Week's Priorities (as of the weekly ironic meeting)

1. rolling upgrades
1.1. make a change to the grenade job to only upgrade conductor
1.2. fix issues in the next patch https://review.openstack.org/#/c/412397/
2. review next BFV patch:
2.1. next: https://review.openstack.org/#/c/453839/
2.2. then: https://review.openstack.org/#/c/366197/
3. update/review next rescue patches:
3.1. https://review.openstack.org/#/c/350831/
3.2. https://review.openstack.org/#/c/353156/
4. review e-tags spec: https://review.openstack.org/#/c/381991/
5. next driver comp client patch: https://review.openstack.org/#/c/419274/


Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 03 Apr 2017 and 10 Apr 2017)
- Ironic: 251 bugs (+10) + 250 wishlist items (+1). 26 new (+11), 202 in 
progress (+1), 0 critical, 27 high (+1) and 28 incomplete (-1)
- Inspector: 15 bugs (-2) + 32 wishlist items (+1). 2 new, 20 in progress (+2), 
0 critical, 1 high (-1) and 4 incomplete
- Nova bugs with Ironic tag: 12. 2 new, 0 critical, 0 high

Essential Priorities


CI refactoring and missing test coverage

- Standalone CI tests (vsaienk0)
- patch to be reviewed: https://review.openstack.org/#/c/437549 MERGED
- next patch to be reviewed: https://review.openstack.org/#/c/429770/
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- blocked by: https://review.openstack.org/#/c/440719/ MERGED

Generic boot-from-volume (TheJulia, dtantsur)
-
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- TheJulia will be unavailable the week of April 10th and the following 
week.
- joanna has volunteered to run the meeting in TheJulia's absence.
- mjturek is working on getting together devstack config updates/script 
changes in order to support this configuration
- hshiina is looking in Nova side changes and is attempting to obtain 
clarity on some of the issues that tenant network separation introduced into 
the deployment workflow.
- Patch/note tracking etherpad: https://etherpad.openstack.org/p/Ironic-BFV
Ironic Patches:
https://review.openstack.org/#/c/355625/  - Merged - Has Follow-up 
that requires reviews https://review.openstack.org/#/c/453839/
https://review.openstack.org/#/c/366197/
https://review.openstack.org/#/c/406290
https://review.openstack.org/#/c/413324
https://review.openstack.org/#/c/454243/ - WIP logic changes for 
deployment process.  Tenant network separation introduced some additional 
complexity, quick conceptual feedback requested.
https://review.openstack.org/#/c/214586/ - Volume Connection 
Information Rest API Change
Additional patches exist, for python-ironicclient and one for nova.  
Links in the patch/note tracking etherpad.

Rolling upgrades and grenade-partial (rloo, jlvillal)
-
- spec approved; code patches: 
https://review.openstack.org/#/q/topic:bug/1526283
- status as of most recent weekly meeting:
- next patch 'Add version column' 
(https://review.openstack.org/#/c/412397/) was updated but seems to have one 
issue still; should be ready tomorrow
- Testing work:
- 27-Mar-2017: Grenade multi-node is non-voting
- need to change it to only upgrade the conductor

Reference architecture guide (jroll)

- no updates

Python 3.5 compatibility (JayF, hurricanerix)
-
- no updates

Deploying with Apache and WSGI in CI (vsaienk0)
---
- seems like we can deploy with WSGI, but it still uses a fixed port, instead 
of sub-path
- next one is https://review.openstack.org/#/c/444337/
- inspector is TODO and depends on https://review.openstack.org/435517

Driver composition (dtantsur, jroll)

* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- TODO as of 10 Apr 2017
- install guide / admin guide docs
- client changes:
- driver commands update: https://review.openstack.org/419274
- node-update update: https://review.openstack.org/#/c/431542/
- new hardware types:
- ilo: https://review.openstack.org/#/c/439404/
- this is blocked by iLO drivers refactoring - see the whole 
patch chai

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann  wrote:
> How long are we expected to be carrying this deprecated bridge code? If you
> need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or
> run different versions of novaclient in venvs or containers if you need to
> really workaround this.

Oh how I wish this were as easy in practice as it sounds.

> I feel like the signaling on all of this was pretty clear back in Newton.
> What else are people expecting or that we missed? I don't really see why
> python-openstackclient needs to start adding this API binding code back in
> locally, that's just extending the lifespan of this busted code that we're
> really trying to make uncomfortable for people to be using because like it
> or not, nova-network is going away. We did the fallback thing in the CLI in
> newton as a way to soften that blow for CLI users, but really at some point
> this just needs to be broken and people either stay on old tools or upgrade
> to what is supported.

Matt, I am not questioning the signalling nor the actual removal, that
is the right thing for novaclient at some point.  I did miss the early
indications of the timing of 8.0, only seeing it two weeks before the
release, but that is on me.

The fact that this causes us problems is not your problem, but
highlights why OSC and Shade and other things really do not want to
use the project clients because the use cases and assumptions and
other things are different.  I started 3 years ago to start replacing
those things, the SDK came long to replace that work but is still not
at a 1.0 release.  So I'm playing catch-up.

Upgrading old nova-net clouds has been deemed impossible, which is why
we don't do it.  But you might be unhappy about the removal of py27
from distros just yet, as not all of OpenStack is py3 ready.  We
should just upgrade all that code...

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [tc] [elections] Available time and top priority


On 4/10/2017 1:18 PM, Chris Dent wrote:

On Mon, 10 Apr 2017, Thierry Carrez wrote:


So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I've been regularly reviewing changes in the governance repo and
attending the weekly TC meeting for well over a year now. Increasing
that commitment to include shepherding new initiatives, either ones
I start myself or work on in concert with others, is why I'm running
for the TC and I wouldn't be doing so if I didn't think I had the
time and energy to support that.

Making a specific prediction on how much time that will take is
challenging; some weeks will take more time than others. I intend to
do what's needed to do the job well.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


Just ONE initiative is difficult because from my perspective what
matters is that whatever initiatives happen to be in progress, they
are transparent, inclusive and actually make some kind of
difference. But since ONE is the request:

My hallmark complaint with the TC since I was first aware of it has
been that, often, resolutions or plans can emerge from the TC so
late in their development that engaging them in a way that allows
consideration of completely different options is hard. Hard for a
variety of reasons; one is that it can feel a bit rude to criticize
a complete seeming idea that someone clearly put a lot of effort
into. This means discussion proceeds as an evaluation of the
proposal rather than as analysis of the root causes of the problems
to be solved or the full consequences of the goals being described.

This situation has improved over the years, I think there is at
least increased awareness, and some concrete efforts to allow people
to be involved, but we can do more to make it easier and lighter.

I would prefer that the TC's constituency was more actively made
aware of pending work and ongoing debates prior to the creation of
resolutions (even if WIP) in gerrit or having big sessions at the
Forum.  One way to do this would be to follow the growing trend of
weekly newsletters and updates and do one for the TC. I recall this
was tried (in the form of blog posts, and to some extent in response
to my prompting) a while back, but didn't really take off. I
wonder if that format was too heavyweight?

I'm proud of having played a part in the newsletter trend and I
think the results for the API-WG and the placement project have been
very positive. Doing something similar for the TC -- in a
lightweight, just-the-highlights kind of way -- is something I could
do (I hope with the occasional help of the rest of the TC) and is
something I think would be useful. With luck the newsletter would
operate as a catalyst around which casual discussion and idea
sharing would accrete.

What I hope would happen as a result is that people would feel more
aware of and able to participate in the discussion and processes
working to shape the future of OpenStack.



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



Thanks Chris. This reminded me of something I wanted to ask about, to 
all TC members, or those running for a seat.


Lots of projects have alternating meeting times to accommodate 
contributors in different time zones, especially Europe and Asia.


The weekly TC meeting, however, does not.

I have to assume this has come up before and if so, why hasn't the TC 
adopted an alternating meeting schedule?


For example, it's 4am in Beijing when the TC meeting happens. It's 
already hard to get people from Asia into leadership roles within 
projects and especially across the community, in large part because of 
the timezone barrier.


How will the TC grow a diverse membership if it's not even held, at 
least every other week, in a timezone where the other half of the world 
can attend?


--

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] UC Meeting 04/10/17 Cancelled

2017-04-10 Thread Melvin Hillsman

Hey everyone,

Apologies for the late notice. We are cancelling the meeting today. We have
moved to a weekly cadence with meetings being subject to new agenda items
having to be proposed/added by the Friday before the meeting. In other
words, for UC meeting scheduled for 04/17/17 agenda items will need to be
proposed/added by this Friday 04/14/17

Thanks very much,

OpenStack UC
__
OpenStack Development Mailing 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] [qa][cinder] critical fix for ceph job

2017-04-10 Thread Jon Bernard

* Matt Riedemann  wrote:
> On 4/7/2017 9:43 AM, Jordan Pittier wrote:
> > 
> > 
> > On Fri, Apr 7, 2017 at 4:15 PM, Ghanshyam Mann  > > wrote:
> > 
> > Thanks. I am not sure these kind of driver specific behavior on APIs
> > side. This bring up question that should not cinder APIs be consistent
> > from usage point. In this case[1], create backup API can accept
> > 'container' param and do/don't create pool as per configured driver?
> > Then have better documentation for that what all driver honor that or
> > not.
> > 
> > Any suggestion ?
> > 
> > ..1 https://review.openstack.org/#/c/454321/3
> > 
> > 
> > 
> > Yeah, I've left a comment on that review. And another comment on
> > https://review.openstack.org/#/c/454722 :
> > 
> > "I'd rather we revert the change completely than to see this merged.
> > 
> > If the Ceph backup driver doesn't support the container argument it
> > should either grow support for it, or ignore that argument, or we change
> > Cinder's API completely so that the container argument is not part of
> > the public API anymore.
> > 
> > Do we expect each and every user to know what each and every drivers
> > support ? I don"t think so, so Tempest shouldn"t either."
> > 
> > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> I left a comment in there too. This wasn't the right way to get around this.
> I've tried the same thing before, back when the encrypted volume tests were
> failing for ceph because it simply wasn't supported in nova.
> 
> Jon, as we discussed at the PTG, you need to get a whitelist or blacklist
> file into nova like we have for the cells v1 job and we can use that on the
> ceph job config to control the tests that are run, so we don't need to make
> changes like this in Tempest. Let's work on that and then we can revert this
> workaround to Tempest.

Ok, I understand the logic and I'm happy work towards this.  For
reference, this commit https://review.openstack.org/#/c/345411/ added
support for container names to the ceph backup driver and I think a
discussion within Cinder is needed.  I will first create an analogous
patch for nova's whitelist, and then revert this one.  And if we decide
to change cinder's behaviour then all of it can go away.

-- 
Jon

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

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Davanum Srinivas

Matt,

I second this request. At least one person i talked to, pointed this
as a primary reason for not standing for the TC election.

Thanks,
Dims

On Mon, Apr 10, 2017 at 2:52 PM, Matt Riedemann  wrote:
> On 4/10/2017 1:18 PM, Chris Dent wrote:
>>
>> On Mon, 10 Apr 2017, Thierry Carrez wrote:
>>
>>> So my question is the following: if elected, how much time do you think
>>> you'll be able to dedicate to Technical Committee affairs (reviewing
>>> proposed changes and pushing your own) ?
>>
>>
>> I've been regularly reviewing changes in the governance repo and
>> attending the weekly TC meeting for well over a year now. Increasing
>> that commitment to include shepherding new initiatives, either ones
>> I start myself or work on in concert with others, is why I'm running
>> for the TC and I wouldn't be doing so if I didn't think I had the
>> time and energy to support that.
>>
>> Making a specific prediction on how much time that will take is
>> challenging; some weeks will take more time than others. I intend to
>> do what's needed to do the job well.
>>
>>> If there was ONE thing, one
>>> initiative, one change you will actively push in the six months between
>>> this election round and the next, what would it be ?
>>
>>
>> Just ONE initiative is difficult because from my perspective what
>> matters is that whatever initiatives happen to be in progress, they
>> are transparent, inclusive and actually make some kind of
>> difference. But since ONE is the request:
>>
>> My hallmark complaint with the TC since I was first aware of it has
>> been that, often, resolutions or plans can emerge from the TC so
>> late in their development that engaging them in a way that allows
>> consideration of completely different options is hard. Hard for a
>> variety of reasons; one is that it can feel a bit rude to criticize
>> a complete seeming idea that someone clearly put a lot of effort
>> into. This means discussion proceeds as an evaluation of the
>> proposal rather than as analysis of the root causes of the problems
>> to be solved or the full consequences of the goals being described.
>>
>> This situation has improved over the years, I think there is at
>> least increased awareness, and some concrete efforts to allow people
>> to be involved, but we can do more to make it easier and lighter.
>>
>> I would prefer that the TC's constituency was more actively made
>> aware of pending work and ongoing debates prior to the creation of
>> resolutions (even if WIP) in gerrit or having big sessions at the
>> Forum.  One way to do this would be to follow the growing trend of
>> weekly newsletters and updates and do one for the TC. I recall this
>> was tried (in the form of blog posts, and to some extent in response
>> to my prompting) a while back, but didn't really take off. I
>> wonder if that format was too heavyweight?
>>
>> I'm proud of having played a part in the newsletter trend and I
>> think the results for the API-WG and the placement project have been
>> very positive. Doing something similar for the TC -- in a
>> lightweight, just-the-highlights kind of way -- is something I could
>> do (I hope with the occasional help of the rest of the TC) and is
>> something I think would be useful. With luck the newsletter would
>> operate as a catalyst around which casual discussion and idea
>> sharing would accrete.
>>
>> What I hope would happen as a result is that people would feel more
>> aware of and able to participate in the discussion and processes
>> working to shape the future of OpenStack.
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Thanks Chris. This reminded me of something I wanted to ask about, to all TC
> members, or those running for a seat.
>
> Lots of projects have alternating meeting times to accommodate contributors
> in different time zones, especially Europe and Asia.
>
> The weekly TC meeting, however, does not.
>
> I have to assume this has come up before and if so, why hasn't the TC
> adopted an alternating meeting schedule?
>
> For example, it's 4am in Beijing when the TC meeting happens. It's already
> hard to get people from Asia into leadership roles within projects and
> especially across the community, in large part because of the timezone
> barrier.
>
> How will the TC grow a diverse membership if it's not even held, at least
> every other week, in a timezone where the other half of the world can
> attend?
>
> --
>
> 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



-- 
Davanum Sr

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Edward Leafe

On Apr 10, 2017, at 1:52 PM, Matt Riedemann  wrote:
> 
> How will the TC grow a diverse membership if it's not even held, at least 
> every other week, in a timezone where the other half of the world can attend?

+1

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

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread German Eichberger

Agreed but not only for the TC. I also heard privately from some contributors 
that meetings times prevent them from fully engage with a project. This is 
something where we as the TC can lead by example.

German

On 4/10/17, 3:06 PM, "Davanum Srinivas"  wrote:

Matt,

I second this request. At least one person i talked to, pointed this
as a primary reason for not standing for the TC election.

Thanks,
Dims

On Mon, Apr 10, 2017 at 2:52 PM, Matt Riedemann  wrote:
> On 4/10/2017 1:18 PM, Chris Dent wrote:
>>
>> On Mon, 10 Apr 2017, Thierry Carrez wrote:
>>
>>> So my question is the following: if elected, how much time do you think
>>> you'll be able to dedicate to Technical Committee affairs (reviewing
>>> proposed changes and pushing your own) ?
>>
>>
>> I've been regularly reviewing changes in the governance repo and
>> attending the weekly TC meeting for well over a year now. Increasing
>> that commitment to include shepherding new initiatives, either ones
>> I start myself or work on in concert with others, is why I'm running
>> for the TC and I wouldn't be doing so if I didn't think I had the
>> time and energy to support that.
>>
>> Making a specific prediction on how much time that will take is
>> challenging; some weeks will take more time than others. I intend to
>> do what's needed to do the job well.
>>
>>> If there was ONE thing, one
>>> initiative, one change you will actively push in the six months between
>>> this election round and the next, what would it be ?
>>
>>
>> Just ONE initiative is difficult because from my perspective what
>> matters is that whatever initiatives happen to be in progress, they
>> are transparent, inclusive and actually make some kind of
>> difference. But since ONE is the request:
>>
>> My hallmark complaint with the TC since I was first aware of it has
>> been that, often, resolutions or plans can emerge from the TC so
>> late in their development that engaging them in a way that allows
>> consideration of completely different options is hard. Hard for a
>> variety of reasons; one is that it can feel a bit rude to criticize
>> a complete seeming idea that someone clearly put a lot of effort
>> into. This means discussion proceeds as an evaluation of the
>> proposal rather than as analysis of the root causes of the problems
>> to be solved or the full consequences of the goals being described.
>>
>> This situation has improved over the years, I think there is at
>> least increased awareness, and some concrete efforts to allow people
>> to be involved, but we can do more to make it easier and lighter.
>>
>> I would prefer that the TC's constituency was more actively made
>> aware of pending work and ongoing debates prior to the creation of
>> resolutions (even if WIP) in gerrit or having big sessions at the
>> Forum.  One way to do this would be to follow the growing trend of
>> weekly newsletters and updates and do one for the TC. I recall this
>> was tried (in the form of blog posts, and to some extent in response
>> to my prompting) a while back, but didn't really take off. I
>> wonder if that format was too heavyweight?
>>
>> I'm proud of having played a part in the newsletter trend and I
>> think the results for the API-WG and the placement project have been
>> very positive. Doing something similar for the TC -- in a
>> lightweight, just-the-highlights kind of way -- is something I could
>> do (I hope with the occasional help of the rest of the TC) and is
>> something I think would be useful. With luck the newsletter would
>> operate as a catalyst around which casual discussion and idea
>> sharing would accrete.
>>
>> What I hope would happen as a result is that people would feel more
>> aware of and able to participate in the discussion and processes
>> working to shape the future of OpenStack.
>>
>>
>>
>> 
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Thanks Chris. This reminded me of something I wanted to ask about, to all 
TC
> members, or those running for a seat.
>
> Lots of projects have alternating meeting times to accommodate 
contributors
> in different time zones, especially Europe and Asia.
>
> The weekly TC meeting, however, does not.
>
> I have to assume this has come up before and if so, why hasn't the TC
> adopted an alternating meeting schedule?
>
> For example, it's 4am in Beijing when the TC meeting happens. It's already

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon


On 4/10/2017 1:51 PM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann  wrote:

How long are we expected to be carrying this deprecated bridge code? If you
need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or
run different versions of novaclient in venvs or containers if you need to
really workaround this.


Oh how I wish this were as easy in practice as it sounds.


I feel like the signaling on all of this was pretty clear back in Newton.
What else are people expecting or that we missed? I don't really see why
python-openstackclient needs to start adding this API binding code back in
locally, that's just extending the lifespan of this busted code that we're
really trying to make uncomfortable for people to be using because like it
or not, nova-network is going away. We did the fallback thing in the CLI in
newton as a way to soften that blow for CLI users, but really at some point
this just needs to be broken and people either stay on old tools or upgrade
to what is supported.


Matt, I am not questioning the signalling nor the actual removal, that
is the right thing for novaclient at some point.  I did miss the early
indications of the timing of 8.0, only seeing it two weeks before the
release, but that is on me.

The fact that this causes us problems is not your problem, but
highlights why OSC and Shade and other things really do not want to
use the project clients because the use cases and assumptions and
other things are different.  I started 3 years ago to start replacing
those things, the SDK came long to replace that work but is still not
at a 1.0 release.  So I'm playing catch-up.

Upgrading old nova-net clouds has been deemed impossible, which is why
we don't do it.  But you might be unhappy about the removal of py27
from distros just yet, as not all of OpenStack is py3 ready.  We
should just upgrade all that code...

dt



Thanks for the clarification Dean. I was obviously a bit defensive and I 
apologize for that.


--

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] [horizon][nova][tc] nova-network deprecation in horizon


On 4/10/2017 11:14 AM, Monty Taylor wrote:

On 04/10/2017 10:37 AM, Monty Taylor wrote:

On 04/10/2017 09:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.


I agree - I think it is not important for horizon to support backward
compat - it's most commonly deployed with a cloud, so one expects it to
support the software in the cloud in question.


However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


Similarly, shade intends to support nova-net for as long as shade
exists. We have already re-implemented most of nova-net support with
direct calls as part of our current project to delete use of
python-*client.



It turns out there are humans out there who are consuming old clouds -
and end-user client tools should be supporting those humans, even when
the current releases of OpenStack deprecate/remove things.


Quick clarification ...

When I say "shade intends to support nova-net" - I mean a specific thing
that is almost certainly not what you might at first assume.

From the beginning, shade has hidden the nova-net/neutron difference -
but shade is focused on the end-user primarily. This means the
difference is "do you use nova or neutron API to deal with floating IPs
and security groups" We do not expose any nova-net functionality
directly - we expose FIPs and Security Groups, and we hide from the user
what service provides them.

We will continue to do that to the best of our ability - although
functional testing in devstack will have to give way to only
requests-mock based testing once we don't have old stable branches that
can install nova-net.

I may have also given the impression that I'm unhappy about novaclient
dropping support - which is also not the case. I am firmly of the
opinion that python-*client do not have end-users of OpenStack clouds as
primary users in mind. The release model and design just isn't right for
that. They are clearly, to me, designed to aid intra-service
communication. As such, I think it's 100% appropriate for novaclient to
have dropped nova-net support.

I, for one, welcome all things about the removal of nova-net, and I am
quite happy to do the support actions in shade.

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


Thanks for the clarification and continuing to keep end users in mind.

--

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] [tc] [elections] Available time and top priority

On Mon, Apr 10, 2017 at 1:52 PM, Matt Riedemann  wrote:
> How will the TC grow a diverse membership if it's not even held, at least
> every other week, in a timezone where the other half of the world can
> attend?

This is something we do need to sort out. The experiences I have seen
with a number of other meetings that do the alternating time is you
mostly get attendees showing up during their 'local' time slot. This
of course is not how the TC operates, requiring a quorum, and holding
in-meeting votes at times.  I do think that my experience is not
representative of meetings attended by elected members.  Also, we
already ask our close-to-UTC-TZ members to give up evening time
(family time for many) for the meetings.  It might be worthwhile to
look at more than two times for alternation.

There is an additional question around language.  The board has seen
where some members may not be comfortable in a non-native language
meeting and may not speak up like they might otherwise.  The current
board makeup is such that regional meetings (not official board
meetings) in Chinese have become feasible and the feedback is that the
participation is much greater for those in attendance.

The TC meetings are held in IRC and that may somewhat mitigate the
issue for non-native English speakers, but I've had problems myself
keeping up at times with the flurry of comments.  In any case, I think
it would be good to include language in the pile of concerns over
world-wide participation

(I read ahead)  Dims mentions personal conversations with some backing
away from running for the TC due to the meeting time, I wonder how
much language has been a factor for others?

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [tc] [elections] Available time and top priority


On 04/10/2017 01:52 PM, Matt Riedemann wrote:

On 4/10/2017 1:18 PM, Chris Dent wrote:

On Mon, 10 Apr 2017, Thierry Carrez wrote:


So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I've been regularly reviewing changes in the governance repo and
attending the weekly TC meeting for well over a year now. Increasing
that commitment to include shepherding new initiatives, either ones
I start myself or work on in concert with others, is why I'm running
for the TC and I wouldn't be doing so if I didn't think I had the
time and energy to support that.

Making a specific prediction on how much time that will take is
challenging; some weeks will take more time than others. I intend to
do what's needed to do the job well.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


Just ONE initiative is difficult because from my perspective what
matters is that whatever initiatives happen to be in progress, they
are transparent, inclusive and actually make some kind of
difference. But since ONE is the request:

My hallmark complaint with the TC since I was first aware of it has
been that, often, resolutions or plans can emerge from the TC so
late in their development that engaging them in a way that allows
consideration of completely different options is hard. Hard for a
variety of reasons; one is that it can feel a bit rude to criticize
a complete seeming idea that someone clearly put a lot of effort
into. This means discussion proceeds as an evaluation of the
proposal rather than as analysis of the root causes of the problems
to be solved or the full consequences of the goals being described.

This situation has improved over the years, I think there is at
least increased awareness, and some concrete efforts to allow people
to be involved, but we can do more to make it easier and lighter.

I would prefer that the TC's constituency was more actively made
aware of pending work and ongoing debates prior to the creation of
resolutions (even if WIP) in gerrit or having big sessions at the
Forum.  One way to do this would be to follow the growing trend of
weekly newsletters and updates and do one for the TC. I recall this
was tried (in the form of blog posts, and to some extent in response
to my prompting) a while back, but didn't really take off. I
wonder if that format was too heavyweight?

I'm proud of having played a part in the newsletter trend and I
think the results for the API-WG and the placement project have been
very positive. Doing something similar for the TC -- in a
lightweight, just-the-highlights kind of way -- is something I could
do (I hope with the occasional help of the rest of the TC) and is
something I think would be useful. With luck the newsletter would
operate as a catalyst around which casual discussion and idea
sharing would accrete.

What I hope would happen as a result is that people would feel more
aware of and able to participate in the discussion and processes
working to shape the future of OpenStack.



__

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



Thanks Chris. This reminded me of something I wanted to ask about, to
all TC members, or those running for a seat.

Lots of projects have alternating meeting times to accommodate
contributors in different time zones, especially Europe and Asia.

The weekly TC meeting, however, does not.

I have to assume this has come up before and if so, why hasn't the TC
adopted an alternating meeting schedule?

For example, it's 4am in Beijing when the TC meeting happens. It's
already hard to get people from Asia into leadership roles within
projects and especially across the community, in large part because of
the timezone barrier.

How will the TC grow a diverse membership if it's not even held, at
least every other week, in a timezone where the other half of the world
can attend?



I think this is a great question, and one that I believe to be 
fundamentally important.


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

Re: [openstack-dev] [Openstack-operators] FW: [quotas] Unified Limits Conceptual Spec RFC

2017-04-10 Thread Lance Bragstad

Sending out a heads up that the initial spec [0] merged.

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

On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell  wrote:

>
> For those that are interested in nested quotas, there is proposal on how
> to address this forming in openstack-dev (and any comments on the review
> should be made to https://review.openstack.org/#/c/363765).
>
> This proposal has the benefits (if I can summarise) that
>
> - Quota limits will be centrally managed in Keystone so the quota data
> will be close to the project for creation/deletion/admin.
> - The usage data remains within each project avoiding dependencies and
> risks of usage data getting out of sync.
> - With a central store for quotas, there is increased opportunity for
> consistency. Given the complexity of quotas and nested projects, this would
> improve operator and end user understanding. The exact model is still for
> confirmation though.
>
> We’ll have a forum discussion (http://forumtopics.openstack.
> org/cfp/details/9) in Boston too but feel free to give input to
> https://review.openstack.org/#/c/363765 so we can use Boston as the
> opportunity to agree on the approach and next steps.
>
> Tim
>
> On 30.03.17, 19:52, "Sean Dague"  wrote:
>
> The near final draft of the unified limits spec is up now -
> https://review.openstack.org/#/c/440815/
>
> If you have not yet wandered in, now is the time, we're going to make
> the final go / no go the end of this week.
>
> -Sean
>
> On 03/17/2017 06:36 AM, Sean Dague wrote:
> > Background:
> >
> > At the Atlanta PTG there was yet another attempt to get hierarchical
> > quotas more generally addressed in OpenStack. A proposal was put
> forward
> > that considered storing the limit information in Keystone
> > (https://review.openstack.org/#/c/363765/). While there were some
> > concerns on details that emerged out of that spec, the concept of the
> > move to Keystone was actually really well received in that room by a
> > wide range of parties, and it seemed to solve some interesting
> questions
> > around project hierarchy validation. We were perilously close to
> having
> > a path forward for a community request that's had a hard time making
> > progress over the last couple of years.
> >
> > Let's keep that flame alive!
> >
> >
> > Here is the proposal for the Unified Limits in Keystone approach -
> > https://review.openstack.org/#/c/440815/. It is intentionally a high
> > level spec that largely lays out where the conceptual levels of
> control
> > will be. It intentionally does not talk about specific quota models
> > (there is a follow on that is doing some of that, under the
> assumption
> > that the exact model(s) supported will take a while, and that the
> > keystone interfaces are probably not going to substantially change
> based
> > on model).
> >
> > We're shooting for a 2 week comment cycle here to then decide if we
> can
> > merge and move forward during this cycle or not. So please
> > comment/question now (either in the spec or here on the mailing
> list).
> >
> > It is especially important that we get feedback from teams that have
> > limits implementations internally, as well as any that have started
> on
> > hierarchical limits/quotas (which I believe Cinder is the only one).
> >
> > Thanks for your time, and look forward to seeing comments on this.
> >
> >   -Sean
> >
>
>
> --
> Sean Dague
> http://dague.net
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [elections] Available time and top priority


On 4/10/2017 2:55 PM, Dean Troyer wrote:


The TC meetings are held in IRC and that may somewhat mitigate the
issue for non-native English speakers, but I've had problems myself
keeping up at times with the flurry of comments.  In any case, I think
it would be good to include language in the pile of concerns over
world-wide participation


I don't attend many TC meetings, it's usually on accident, but yeah, 
when I do I always note the flurry of cross-talk chatter that just 
drowns everything out. I feel like there are usually at least 3 parallel 
conversations going on during a TC meeting and it's pretty frustrating 
to follow along, or get a thought in the mix. That has to be much worse 
for a non-native English speaker.


So yeah, slow down folks. :)

I'm not advocating splitting the meetings though. It's possible to have 
your cake and eat it to if done properly. For example, Alex Xu runs the 
Nova API subteam meeting and we have people from China, India, Japan, UK 
and USA and get through it fine, but it does involve slowing down to get 
an acknowledgement from people that they are OK with any decisions being 
made.


This might also tie back in with what cdent was mentioning, and if the 
flurry of conversation during a TC meeting throws people off, maybe the 
minutes should be digested after the meeting in the mailing list. I know 
the meeting is logged, but it can be hard to read through that without 
one's eyes glazing over due to the cross-talk and locker-room towel 
whipping going on.


--

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] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

2017-04-10 Thread Martinx - ジェームズ

On 8 April 2017 at 00:37, Martinx - ジェームズ  wrote:

> Guys,
>
>  I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time
> ever, today!
>
>  It looks very, very good... OVN L3 Router is working, OVN DHCP working...
> bridge mappings "br-ex" on each compute node... All good!
>
>  Then, I've said: time for DPDK!
>
>  I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
> Archive) with plain KVM, no OpenStack, so, I have experience about how to
> setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...
>
>  After configuring DPDK on a compute node, I tried the following
> instructions:
>
>  https://docs.openstack.org/developer/networking-ovn/dpdk.html
>
>  It looks quite simple!
>
>  To make things even simpler, I have just 1 controller, and 1 compute
> node, to begin with, before enabling DPDK at the compute node and changing
> the "br-int" datapath, I deleted all OVN Routers and all Neutron Networks
> and Subnets, that was previously working with regular OVS (no DPDK).
>
>  Then, after enabling DPDK and updating the "br-int" and the "br-ex"
> interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
> br-ex" network, the following errors appeared on OpenvSwitch logs of the
> related compute node (OpenFlow error):
>
>
>  * After connecting OVN L3 Router against the "ext-net / br-ex" Flat /
> VLAN Network:
>
>  ovs-vswitchd.log:
>
>  http://paste.openstack.org/show/605800/
>
>  ovn-controller.log:
>
>  http://paste.openstack.org/show/605801/
>
>
>  Also, after connecting the OVN L3 Router into the local (GENEVE) network,
> very similar error messages appeared on OpenvSwitch logs...
>
>
>  * After connecting OVN L3 Router on a "local" GENEVE Network:
>
>  ovs-vswitchd.log:
>
>  http://paste.openstack.org/show/605804/
>
>  ovn-controller.log:
>
>  http://paste.openstack.org/show/605805/
>
>
>  * Output of "ovs-vsctl show" at the single compute node, after plugging
> the OVN L3 Router against the two networks (external / GENEVE):
>
>  http://paste.openstack.org/show/605806/
>
>
>  Then, I tried to launch an Instance anyway and, for my surprise, the
> Instance was created! Using vhostuser OVS+DPDK socket!
>
>  Also, the Instance got its IP! Which is great!
>
>  However, the Instance can not ping its OVN L3 Router (its default
> gateway), with or without any kind of security groups applied, no deal...
> :-(
>
>  BTW, the Instance did not received the ARP stuff of the OVN L3 Router, I
> mean, for the instance, the gateway IP on "arp -an" shows "".
>
>
>  * The ovs-vswitchd.log after launching an Instance on top of OVN/OVS+DPDK:
>
>  http://paste.openstack.org/show/605807/
>
>  * The output of "ovs-vsctl show" after launching the above instance:
>
>  http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser
>
>
>  Just to give another try, I started a second Instance, to see if the
> Instances can ping each other... Also did not worked, the Instances can not
> ping each other.
>
>
>  So, from what I'm seeing, OVN on top of DPDK does not work.
>
>  Any tips?
>
>
>  NOTE:
>
>  I tried to enable "hugepages" on my OpenStack's flavor, just in case...
> Then, I found another bug, it doesn't even boot the Instance:
>
>  https://bugs.launchpad.net/cloud-archive/+bug/1680956
>
>
>  For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
> this cloud is for high performance networks, so, I need DPDK, and I also
> need GENEVE and Provider Networks, everything on top of DPDK.
>
> ---
>  After researching more about this "high perf networks", I found this:
>
>  * DPDK-like performance in Linux kernel with XDP !
>
>  http://openvswitch.org/support/ovscon2016/7/0930-pettit.pdf
>
>  https://www.iovisor.org/technology/xdp
>  https://www.iovisor.org/technology/ebpf
>
>  https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/
>
>  But I have no idea about how to use OpenvSwitch with this thing, however,
> if I can achieve DPDK-Like performance, without DPDK, using just plain
> Linux, I'm a 100% sure that I'll prefer it!
>
>  I'm okay to give OpenvSwitch + DPDK another try, even knowing that it
> [OVS] STILL have serious problems (https://bugs.launchpad.net/
> ubuntu/+source/openvswitch/+bug/1577088)...
> ---
>
>  OpenStack on Ubuntu rocks!   :-D
>
> Thanks!
> Thiago
>

I just realized how cool IO Visor is!

Sorry about mixing subjects, let's keep this one clear for OVN on top of
DPDK.

I found a opened bug on RedHat's Bugzilla, I updated it with the info from
this e-mail:

https://bugzilla.redhat.com/show_bug.cgi?id=1410565

Looks like that, OVN doc say that it is supported on top of any OpenvSwitch
Datapath but, it is not the case... Right?

I would be happy to be able to use GENEVE on top of regular Linux datapath,
and only Provider Networks on top of DPDK but, it also doesn't work. I'll
post more details about this later.

Cheers!
Thiago
__
OpenStack Development Mailing List (

[openstack-dev] [stable] What's the plan for mitaka-eol?