Re: [openstack-dev] [Fuel] API services available on public VIP

[Matthew Mosesohn]

I haven't seen any more discussion on this topic. It looks like since we
default to enabling SSL/TLS on deployments, there's no reason to block
access to public API endpoints.

On Fri, Nov 13, 2015 at 5:15 PM, Vladimir Kuklin 
wrote:

> Adam
>
> I think, the answer is realtively simple - if user does not want to expose
> those APIs, he can easily configure his infra to filter this traffic. We
> just need to mention this in Ops Guide.
>
> On Fri, Nov 13, 2015 at 4:02 PM, Adam Heczko  wrote:
>
>> Hello fuelers,
>>
>> today I'd like to raise a questions about Fuel deployment practice
>> related to Public (external) network.
>> Current approach is to expose by default over public IP openstack API
>> endpoints like nova, cinder, glance, neutron etc. These API services are
>> exposed through HAProxy with TLS support, so this approach seems to be
>> relatively secure.
>> OTOH industry practice is to don't expose over public IPs too much and
>> rather rely on user action / decision to expose API access to the public.
>> I'd like to ask for your opinions regarding this topic and approach taken
>> by Fuel.
>>
>> Thank you,
>>
>> --
>> Adam Heczko
>> Security Engineer @ Mirantis Inc.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Paul Carver]

On 11/13/2015 7:03 PM, Henry Fourie wrote:



  I wonder whether just pushing flows into the existing tables at random points 
in time can be unstable and break the usual flow assumed by the main agent loop.
LF> No not expect any issues.

Am I making sense?

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion



I attempted to describe a possible issue at the bottom of the Etherpad 
in the bullet point "Overall requirement - Flow prioritization mechanism"




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

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2015-11-16 12:37:15 +0100:
> On 11/16/2015 12:28 PM, Davanum Srinivas wrote:
> > Dmitry,
> >
> > i was trying to bring sanity to the tox.ini(s). +1 to documenting this
> > step somewhere prominent.
> 
> Please don't get me wrong, I really appreciate it. I'm not sure why 
> "usedevelop" is not the default, though. Maybe we at least make sure to 
> communicate this to people first? Because the error message is really 
> vague to anyone who is not aware of these version tags.

When the Oslo libraries depended on namespace packages, we couldn't have
usedevelop = True because it broke importing other libraries. Now that
we've removed namespace packages from most of the libraries, we could
set it true everywhere except oslo.middleware (I think that's the only
one that was left, because of having to wait to roll out paste.ini
changes this cycle -- does anyone want to sign up to remove that last
namespace package?).

Doug

> 
> >
> > -- Dims
> >
> > On Mon, Nov 16, 2015 at 5:37 AM, Dmitry Tantsur  wrote:
> >> On 11/16/2015 11:35 AM, Julien Danjou wrote:
> >>>
> >>> On Mon, Nov 16 2015, Dmitry Tantsur wrote:
> >>>
>  Before you ask: using 'sudo pip install -U setuptools pbr' is out of
>  question
>  in binary distributions :) so please make sure to remove this line only
>  when
>  everyone is updated to whatever version is required for understanding
>  these
>  ;python_version=='2.7 bits.
> >>>
> >>>
> >>> But:
> >>> pip install --user setuptools pbr
> >>> might not be out of the question.
> >>>
> >>
> >> Yeah, this (with added -U) fixes the problem. But then we have to add it to
> >> *all* contribution documentation. I'm pretty sure a lot of people won't
> >> realize they need it.
> >>
> >>
> >> __
> >> OpenStack Development Mailing 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] REST API collation and visualization

[Neil Jerram]

Hi there,

I'm interested in collating all the REST API exchanges to and between
OpenStack components, and presenting / visualizing all those in an
easily comprehensible way.  Is there already some tool to do that?

Many thanks,
Neil


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

[openstack-dev] [all] [ptls] Time to make some assertions about your projects

[Thierry Carrez]

Hi PTLs,

Over the last months the Technical Committee defined a number of
"assert" tags which are assertions that project teams make about their
own deliverables:

* assert:follows-standard-deprecation
* assert:supports-upgrade
* assert:supports-rolling-upgrade

You can find their definition at:
http://governance.openstack.org/reference/tags/index.html

You should read those and see if they apply to your service projects. If
those are commitments that your project follow already, please propose
an update to the projects.yaml file to add the corresponding tag(s) to
your service deliverable:

http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

The Foundation is expected to include those "assert" tags very soon in
the Project Navigator display, so it would be great to have a pretty
current picture of where we stand by then. I know of several projects
that follow standard deprecation and support rolling upgrade that
haven't asserted the corresponding tags yet.

For the time being we are looking at applying such tags only to
"type:service" deliverables (main user-facing services).

Thanks in advance,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Fuel] Deprecation of GRE network segmentation in Fuel 8.0

[Artem Roma]

Hi all!

AFAIK, GRE network segmentation option has been deprecated for clusters
with Neutron since 7.0 release, both on UI and Library side. One still can
use the option via CLI as no relevant changes were made to Nailgun API.
Though appropriate warning is displayed in the case.

So I wanted to ask: are we going to carry such behavior of the API in 8.0
or should we also remove processing of the option?

In my opinion we should at least forbid cluster creation via API with the
parameter as this is the only stage it is accepted. Enhancing of input data
validation for appropriate handler will do the trick. Relevant internal
Nailgun logic (serialization, networking etc.) will be unchanged in order
to support compatibility with already existing clusters after master node
upgrade.

FYI, there is a relevant bug [1] on Lauchpad.

[1] https://bugs.launchpad.net/fuel/7.0.x/+bug/1478924

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

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

[gord chung]

in Liberty, we did a virtual meetup in for the telemetry team so i 
thought i'd share experience.


On 16/11/2015 9:05 AM, Jim Rollenhagen wrote:

Then we can set up some hangouts (or similar) to get people in the same
"room" working on things. Time zones will get weird, but we tend to
hangouts is limited to 10 people -- you will hit the capacity. arguably 
not everyone needs to be on video or will talk but you should probably 
find a service that accommodates your expected attendance.



split into smaller groups at the midcycle anyway; this is just more
timezone-aligned. We can also find windows where time zones overlap when
we want to go across those boundaries. Disclaimer: people may need to
work some weird hours to do this well.
ask your company for a coffee budget, a few of you are going to be 
working at 3am.


--
gord


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

[openstack-dev] [Neutron] Team meeting this Tuesday at 1400 UTC

[Armando M.]

Hi folks,

A kind reminder for tomorrow's meeting. Please add agenda items to the
meeting here [1].

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings
__
OpenStack Development Mailing 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][devstack]Openstack devstack installation failing.

[Sean M. Collins]

Attach to the screen session Devstack sets up, and verify that the Nova
compute service is running. It's running in the screen session named
n-api.

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [freezer] Proposal to add Pierre-Arthur Mathieu to freezer-core

[Fresco, Fabrizio]

+1



Fabrizio





From: Marzi, Fausto

Sent: 13 November 2015 16:45

To: OpenStack Development Mailing List (not for usage questions)

Subject: [openstack-dev] [freezer] Proposal to add Pierre-Arthur Mathieu to 
freezer-core



Hi All,



I'd like to propose Pierre as core in Freezer.



Pierre dedication was amazing on code review, documentation, architectural 
decision and overall greatly improving the quality of the Freezer Project.

Freezer wouldn't be to the point where it is without Pierre.



Please respond with comments, +1s, or objections within one week.



Many thanks,

Fausto

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

Re: [openstack-dev] [oslo][all] Oslo libraries dropping python 2.6 compatability

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2015-11-16 09:23:39 -0500:
> Gordon,
> 
> When we stop the py26 jobs, the next version we release should have
> major bumps by semver definition. liberty does not have version caps
> unfortunately, but i'll let Doug and others chime in on that.
> 
> yes, i know major bumps are hard

Yes, I would expect major version number increases and trove
classifier updates (in setup.cfg) to indicate that some support has
been dropped. It's simpler to do it now, than to do it at some point
in the future when we introduce a syntactic or standard library
dependency that is not available in 2.6.

The constraints file in liberty should protect us from introducing
versions that are actually incompatible. If we need to go back and add a
few caps, or add environment markers to support different ranges on 2.6
and >=2.7, we can do that as we discover the need.

Doug

> 
> thanks,
> dims
> 
> On Mon, Nov 16, 2015 at 9:07 AM, gord chung  wrote:
> > do we require a major versioning bump for this? i'm wondering how 'breaking'
> > this is in real life if all the services have dropped py2.6 already. maybe
> > this just requires an upper-cap in appropriate stable branches?
> >
> > to be devils advocate, one (arguably terrible) reason for not doing a major
> > bump is that a lot of libs just did one for the Mitaka cycle.
> >
> > On 11/11/2015 2:14 PM, Davanum Srinivas wrote:
> >>
> >> Folks,
> >>
> >> Any concerns? please chime in:
> >> https://review.openstack.org/244275
> >>
> >> Thanks
> >> -- Dims
> >>
> >
> > --
> > gord
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

[Doug Hellmann]

Excerpts from Kekane, Abhishek's message of 2015-11-16 07:33:48 +:
> Hi,
> 
> As apiclient is now removed from oslo-incubator, to proceed with request-id 
> spec [1] I have two options in mind,
> 
> 
> 1.   Use keystoneauth1 + cliff in all python-clients (add request-id 
> support in cliff library)

cliff is being used outside of OpenStack, and is not at all related to
REST API access, so I don't think that's the right place.

> 
> 2.   apiclient code is available in all python-*clients, modify this code 
> in individual clients and add support to return request-id.

Yes, I think that makes sense.

> 
> Please let me know your opinion on the same.
> 
> [1] https://review.openstack.org/#/c/156508/
> 
> Thanks & Regards,
> 
> Abhishek Kekane
> 
> > On Nov 11, 2015, at 3:54 AM, Andrey Kurilin  > mirantis.com>
> >  wrote:
> 
> >
> 
> >
> 
> >
> 
> > On Tue, Nov 10, 2015 at 4:25 PM, Sean Dague  > dague.net
> >   > dague.net>>
> >  wrote:
> 
> > On 11/10/2015 08:24 AM, Andrey Kurilin wrote:
> 
> > >>It was also proposed to reuse openstackclient or the openstack SDK.
> 
> > >
> 
> > > Openstack SDK was proposed a long time ago(it looks like it was several
> 
> > > cycles ago) as "alternative" for cliutils and apiclient, but I don't
> 
> > > know any client which use it yet. Maybe openstacksdk cores should try to
> 
> > > port any client as an example of how their project should be used.
> 
> >
> 
> > The SDK is targeted for end user applications, not service clients. I do
> 
> > get there was lots of confusion over this, but SDK is not the answer
> 
> > here for service clients.
> 
> >
> 
> > Ok, thanks for explanation, but there is another question in my head: If 
> > openstacksdk is not for python-*clients, why apiclient(which is actually 
> > used by python-*clients) was marked as deprecated due to openstacksdk?
> 
> 
> 
> The Oslo team wanted to deprecate the API client code because it wasn't being 
> maintained. We thought at the time we did so that the SDK would replace the 
> clients, but discussions since that time have changed direction.
> 
> >
> 
> > The service clients are *always* going to have to exist in some form.
> 
> > Either as libraries that services produce, or by services deciding they
> 
> > don't want to consume the libraries of other clients and just put a
> 
> > targeted bit of rest code in their own tree to talk to other services.
> 
> >
> 
> > -Sean
> 
> >
> 
> > --
> 
> > Sean Dague
> 
> > http://dague.net 
> 
> >
> 
> > __
> 
> > OpenStack Development Mailing List (not for usage questions)
> 
> > Unsubscribe: OpenStack-dev-request at 
> > lists.openstack.org?subject:unsubscribe
> >  
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> >
> 
> >
> 
> >
> 
> > --
> 
> > Best regards,
> 
> > Andrey Kurilin.
> 
> > __
> 
> > OpenStack Development Mailing List (not for usage questions)
> 
> > Unsubscribe: OpenStack-dev-request at 
> > lists.openstack.org
> >   > lists.openstack.org>?subject:unsubscribe
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> -- next part --
> 
> An HTML attachment was scrubbed...
> 
> URL: 
> 
> 

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

[openstack-dev] [tripleo] When to use parameters vs parameter_defaults

[Steven Hardy]

Hi all,

I wanted to start some discussion re $subject, because it's been apparrent
that we have a lack of clarity on this issue (and have done ever since we
started using parameter_defaults).

Some context:

- Historically TripleO has provided a fairly comprehensive "top level"
  parameters interface, where many per-role and common options are
  specified, then passed in to the respective ResourceGroups on deployment

https://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/overcloud-without-mergepy.yaml#n14

The nice thing about this approach is it gives a consistent API to the
operator, e.g the parameters schema for the main overcloud template defines
most of the expected inputs to the deployment.

The main disadvantage is a degree of template bloat, where we wire dozens
of parameters into each ResourceGroup, and from there into whatever nested
templates consume them.

- When we started adding interfaces (such as all the OS::TripleO::*ExtraConfig*
  interfaces, there was a need to enable passing arbitrary additional
  values to nested templates, with no way of knowing what they are (e.g to
  enable wiring in third-party pieces we have no knowledge of or which
  require implementation-specific arguments which don't make sense for all
  deployments.

To do this, we made use of the heat parameter_defaults interface, which
(unlike normal parameters) have global scope (visible to all nested stacks,
without explicitly wiring in the values from the parent):

http://docs.openstack.org/developer/heat/template_guide/environment.html#define-defaults-to-parameters

The nice thing about this approach is its flexibility, any arbitrary
values can be provided without affecting the parent templates, and it can
allow for a terser implementation because you only specify the parameter
definition where it's actually used.

The main disadvantage of this approach is it becomes very much harder to
discover an API surface for the operator, e.g the parameters that must be
provided on deployment by any CLI/UI tools etc.  This has been partially
addressed by the new-for-liberty nested validation heat feature, but
there's still a bunch of unsolved complexity around how to actually consume
that data and build a coherent consolidated API for user interaction:

https://github.com/openstack/heat-specs/blob/master/specs/liberty/nested-validation.rst

My question is, where do we draw the line on when to use each interface?

My position has always been that we should only use parameter_defaults for
the ExtraConfig interfaces, where we cannot know what reasonable parameters
are.  And for all other "core" functionality, we should accept the increased
template verbosity and wire arguments in from overcloud-without-mergepy.

However we've got some patches which fall into a grey area, e.g this SSL
enablement patch:

https://review.openstack.org/#/c/231930/46/overcloud-without-mergepy.yaml

Here we're actually removing some existing (non functional) top-level
parameters, and moving them to parameter_defaults.

I can see the logic behind it, it does make the templates a bit cleaner,
but at the expense of discoverablility of those (probably not
implementation dependent) parameters.

How do people feel about this example, and others like it, where we're
enabling common, but not mandatory functionality?

In particular I'm keen to hear from Mainn and others interested in building
UIs on top of TripleO as to which is best from that perspective, and how
such arguments may be handled relative to the capabilities mapping proposed
here:

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

Thanks!

Steve

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

[openstack-dev] [release] making release notes jobs voting

[Doug Hellmann]

Now that we have several projects successfully using reno, and notes are
being published, we are going to turn the release notes jobs back to
voting and add a job to the gate queue. If you have issues in your
project with the job passing, please add a follow-up to the patch that
changes the default [1] to set the voting flag to false *just for your
project*.

Thanks,
Doug

[1] https://review.openstack.org/245841

__
OpenStack Development Mailing 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] [api] consolidate IRC change with #openstack-sdk?

[michael mccune]

On 11/16/2015 09:42 AM, Sean Dague wrote:

On 11/16/2015 09:34 AM, michael mccune wrote:

On 11/13/2015 07:58 AM, Sean Dague wrote:

The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)


i don't necessarily have an outright objection to this, but i would like
explore the future possibilities of this change.

i think there is possibility for the api-wg to grow and take on more
responsibility within the openstack community and i'm curious about the
net effect down the road if that expansion were to occur. are there any
side-effects we should be aware of as we merge the two
channels/communities into one namespace?

i realize there is some overlap of engineering/design that takes place
on these channels, i'm just concerned about the idea of merging the two
and then at some point in the future wanting to separate them. i'm not
proposing these thoughts to quash the idea of joining, i'd just like to
more fully understand the longer term implications of a merge.

anyone with more experience in this community-oriented side of things
have some light to shed?


Typically the only real reason to spin off another channel is that there
are now too many conversations happening all at once that are unrelated
and people are finding it is impeding their ability to get work done. I
can't imagine this happening any time within the next couple of years.
An average day in #openstack-api is < 20 messages (from a quick spot
check in IRC logs).

I feel there is a lot of benefits in having these groups that do related
work all doing it in one channel. Even though it's a number of discreet
outputs, the "hallway track" of having api producers and consumers doing
their business all in front of each other should quite help in ensuring
that we all make something better.


thanks for the clarifications Sean, i appreciate the extra resolution 
and i agree that having both these groups able to comment on similar 
issues in a common place seems ideal.


regards,
mike


__
OpenStack Development Mailing 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] [freezer] Proposal to add Eldar Nugaev to freezer-core

[Fresco, Fabrizio]

+1


From: Marzi, Fausto
Sent: 13 November 2015 16:39
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [freezer] Proposal to add Eldar Nugaev to freezer-core

Hi All,

I'd like to propose Eldar as core in Freezer, as his help, dedication and 
contribution was incredible for the last 6 months.

Eldar not only worked on improving performances overall, but also on making our 
code more portable, abstracted and implemented outstanding features like the 
parallel backup upload engine.

Please respond with comments, +1s, or objections within one week.

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

Re: [openstack-dev] [openstack-ansible][security] Next steps: openstack-ansible-security

[Major Hayden]

On 11/16/2015 07:47 AM, Jesse Pretorius wrote:
> Based on the spec's proposed change section [1] I would say that items 4 & 5 
> are the next steps. Those steps, however, are kind-of waiting for the gate 
> split work. Perhaps the best way to get this done that doesn't have the 
> dependency is to implement an additional option for gate-check-commit option 
> to turn on using the security role, but leave it off by default. The current 
> job will then continue to run and we can add an additional gate check to run 
> it with the security bits on as a comparison.

That sounds good.  I'll hopefully get time to take a crack at that along with 
the check mode enhancements this week.

--
Major Hayden

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

Re: [openstack-dev] [openstack-ansible][security] Next steps: openstack-ansible-security

[Jesse Pretorius]

On 9 November 2015 at 19:38, Major Hayden  wrote:

>
> What would you propose as the final steps to get the blueprint marked as
> completed?  Should documentation be added into openstack-ansible about
> integrating openstack-ansible-security or should a script be provided for
> quicker integration?
>

Based on the spec's proposed change section [1] I would say that items 4 &
5 are the next steps. Those steps, however, are kind-of waiting for the
gate split work. Perhaps the best way to get this done that doesn't have
the dependency is to implement an additional option for gate-check-commit
option to turn on using the security role, but leave it off by default. The
current job will then continue to run and we can add an additional gate
check to run it with the security bits on as a comparison.

[1]
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/security-hardening.html#proposed-change
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Sean Dague]

On 11/16/2015 06:57 AM, Korzeniewski, Artur wrote:
> Thanks Sean D. for explanation!
> 
>  
> 
> I’ve taken a look into old Russell patches, and it seems that the
> project-config was already modified by him:
> 
> Add check-grenade-dsvm-partial-ncpu-neutron: (project-config)
> 
> https://review.openstack.org/#/c/189426
> 
> Add check-grenade-dsvm-partial-ncpu-neutron-dvr (project-config)
> 
> https://review.openstack.org/#/c/189727

These are not the project-config changes you want. The old partial
method is deprecated, instead you should be using multinode + grenade
(per the conversation at the top of this thread).

> Another 2 patches are introducing the Neutron partial job to devstack-gate
> 
> Add partial-ncpu-neutron grenade mode (devstack-gate)
> 
> https://review.openstack.org/#/c/189424/
> 
> Add partial-ncpu-neutron-dvr grenade mode (devstack-gate)
> 
> https://review.openstack.org/#/c/189715

Again, you don't want these patches. These are the wrong direction.

> I haven’t tested that yet, but it looks like it does the job.
> 
>  
> 
> Also, there is still one patch in Devstack needed for L3 agent separate
> start/stop:
> 
> Separate start/stop control of the Neutron L3 agent. (Devstack)
> 
> https://review.openstack.org/#/c/189710/

No, we don't need that patch.

> 
>  
> 
> From what Sean D. talked about, following patches should not be resurrected:
> 
> Support partial upgrades of Neutron in DVR mode: (Grenade)
> 
> https://review.openstack.org/#/c/189712
> 
>  Support partial Neutron upgrades. (Grenade)
> 
> https://review.openstack.org/#/c/189417/

No, you don't want those either.

> In order to test the RPC right, we should be able to decouple the
> neutron server from its agents – L2, L3, DHCP and metadata agents.
> 
> Current scenario will let us to test :
> 
> 1.   Legacy:
> 
> a.   Controller & network node: neutron server, L2, L3, Metadata and
> DHCP agents
> 
> b.  Compute node: L2 agent.
> 
> 2.   DVR:
> 
> a.   Controller & network node: neutron server, L2, L3, Metadata and
> DHCP agents
> 
> b.  Compute node: L2, L3, Metadata(?) agents
> 
>  
> 
> We can start with current scenario, but this does not guarantee us to
> test of DHCP RPC.
> 
>  
> 
> The ideal upgrade scenario should look like this:
> 
> 1.   Legacy:
> 
> a.   Controller node: neutron server
> 
> b.  Network node: L2, L3, Metadata and DHCP server
> 
> c.   Compute node: L2 agent
> 
> 2.   DVR:
> 
> a.   Controller node: neutron server
> 
> b.  Network node: L2, L3, Metadata and DHCP server
> 
> c.   Compute node: L2, L3 and Metadata agent
> 
>  
> 
> The job still to be done in order to fully test partial upgrades:
> 
> -  Decouple the DHCP and metadata agent from devstack neutron
> restart
> 
> -  Look through the grenade Neutron code in order to identify if
> we are creating the all the resources critical to test the upgrades
> 
> -  Debug, debug, debug…
> 
>  
> 
> Regards,
> 
> Artur
> 
> *From:*Armando M. [mailto:arma...@gmail.com]
> *Sent:* Friday, November 13, 2015 9:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova][neutron][upgrade] Grenade
> multinode partial upgrade
> 
>  
> 
>  
> 
>  
> 
> On 13 November 2015 at 11:46, Sean Dague  > wrote:
> 
> On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> > On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
> >> Ok, I top responded with the details of the job, honestly I think
> it's
> >> just a project-config change to get up and running, and then
> hacking at
> >> the bugs that fall out.
> >
> > Thanks - that was super helpful.
> >
> > I'm thinking of working on the following on Monday:
> >
> > 1) capture that somewhere in the upgrade docs we're putting
> together in neutron's devref
> >
> > 2) Adding the stanza to project-config to get grenade running for
> > Neutron
> >
> > 3) Take a look at the patches that Armando linked a couple emails back
> > in this thread.
> 
> I don't think that any of the patches listed there are needed. This was
> part of the reason I -2ed that direction in the last cycle. It required
> a separate special code path for partial upgrade setup which was very
> synthetic (and honestly kind of confusing to debug).
> 
>  
> 
> I don't disagree. I didn't meant to imply 'resume the patches', I was
> only providing the backdrop.
> 
>  
> 
> 
> The new approach means if you did upgrade for the all-in-one case, and
> you did multinode setup with worker processes on the subnode, you just
> make a config where you do them both at the same time, and you have
> partial upgrade.
> 
> -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __
> OpenStack 

[openstack-dev] [nova] config options: location and help text

[Markus Zoeller]

target audience
===
* Code contributors who introduce new or change existing config options
* Newbies who are looking for a starter friendly task

Why am I receiving this?

With bp [1] we got some aggreement on how we should handle the config
options of Nova. Long story short, move/put them to "/nova/conf" and
provide a proper help text. Commit [2] is the first one which does it.

With this ML post I'd like to ask you to put new config options to the
"nova/conf/" folder. If you have any questions on how to do this, just
ping me in IRC (markus_z).

The other existing config options will be moved and refactored like
in [2]. The etherpad [3] lists all of them. If you want to contribute
there (it's a newbie friendly task), ping me in IRC (markus_z)

References
==
[1] https://blueprints.launchpad.net/nova/+spec/centralize-config-options
[2] Gerrit, "config options: centralize section "serial_console";
https://review.openstack.org/#/c/244177/
[3] https://etherpad.openstack.org/p/config-options

Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [nova] config options: location and help text

[Markus Zoeller]

Markus Zoeller/Germany/IBM@IBMDE wrote on 11/16/2015 02:37:14 PM:

> From: Markus Zoeller/Germany/IBM@IBMDE
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 11/16/2015 02:38 PM
> Subject: [openstack-dev] [nova] config options: location and help text
> 
> target audience
> ===
> * Code contributors who introduce new or change existing config options
> * Newbies who are looking for a starter friendly task
> 
> Why am I receiving this?
> 
> With bp [1] we got some aggreement on how we should handle the config
> options of Nova. Long story short, move/put them to "/nova/conf" and
> provide a proper help text. Commit [2] is the first one which does it.
> 
> With this ML post I'd like to ask you to put new config options to the
> "nova/conf/" folder. If you have any questions on how to do this, just
> ping me in IRC (markus_z).
> 
> The other existing config options will be moved and refactored like
> in [2]. The etherpad [3] lists all of them. If you want to contribute
> there (it's a newbie friendly task), ping me in IRC (markus_z)
> 
> References
> ==
> [1] 
https://blueprints.launchpad.net/nova/+spec/centralize-config-options
> [2] Gerrit, "config options: centralize section "serial_console";
> https://review.openstack.org/#/c/244177/
> [3] https://etherpad.openstack.org/p/config-options
> 
> Regards, Markus Zoeller (markus_z)

The Nova code review guide is going to state this as well with the
merge of https://review.openstack.org/#/c/245789/

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing 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] [mistral] Team meeting - 11/16/2015

[Renat Akhmerov]

Hi,

This is just a reminder that we’ll have a team meeting today at 
#openstack-meeting at 16.00 UTC.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Open discussion

Put your own items at https://wiki.openstack.org/wiki/Meetings/MistralAgenda 
 if you’re interested 
in discussing something.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [openstack-ansible] Converting the AIO bootstrap script to Ansible

[Jesse Pretorius]

On 6 November 2015 at 21:34, Major Hayden  wrote:

> Feel free to critique it and I'll get to work on making the changes.  The
> spec[2] should answer most of the questions about the effort.
>
> Thanks! :)
>
> [1] https://review.openstack.org/#/c/239525/
> [2]
> http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/convert-aio-bootstrap-to-ansible.html


This is excellent work, thanks Major!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][all] Oslo libraries dropping python 2.6 compatability

[Davanum Srinivas]

Gordon,

When we stop the py26 jobs, the next version we release should have
major bumps by semver definition. liberty does not have version caps
unfortunately, but i'll let Doug and others chime in on that.

yes, i know major bumps are hard

thanks,
dims

On Mon, Nov 16, 2015 at 9:07 AM, gord chung  wrote:
> do we require a major versioning bump for this? i'm wondering how 'breaking'
> this is in real life if all the services have dropped py2.6 already. maybe
> this just requires an upper-cap in appropriate stable branches?
>
> to be devils advocate, one (arguably terrible) reason for not doing a major
> bump is that a lot of libs just did one for the Mitaka cycle.
>
> On 11/11/2015 2:14 PM, Davanum Srinivas wrote:
>>
>> Folks,
>>
>> Any concerns? please chime in:
>> https://review.openstack.org/244275
>>
>> Thanks
>> -- Dims
>>
>
> --
> gord
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

[michael mccune]

On 11/13/2015 07:58 AM, Sean Dague wrote:

The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)


i don't necessarily have an outright objection to this, but i would like 
explore the future possibilities of this change.


i think there is possibility for the api-wg to grow and take on more 
responsibility within the openstack community and i'm curious about the 
net effect down the road if that expansion were to occur. are there any 
side-effects we should be aware of as we merge the two 
channels/communities into one namespace?


i realize there is some overlap of engineering/design that takes place 
on these channels, i'm just concerned about the idea of merging the two 
and then at some point in the future wanting to separate them. i'm not 
proposing these thoughts to quash the idea of joining, i'd just like to 
more fully understand the longer term implications of a merge.


anyone with more experience in this community-oriented side of things 
have some light to shed?


thanks,
mike


__
OpenStack Development Mailing 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] [api] consolidate IRC change with #openstack-sdk?

[Sean Dague]

On 11/16/2015 09:34 AM, michael mccune wrote:
> On 11/13/2015 07:58 AM, Sean Dague wrote:
>> The #openstack-api IRC channel is quite quiet most days. As such it's
>> not something that people are regularly checking in on, or often forget
>> about (I know I've been guilty of that). Plus we don't always have the
>> right people in a conversation to make a decision.
>>
>> I'd like to propose we drop the channel entirely and make #openstack-sdk
>> the home of API working group conversations. That's where all the
>> openstackclient, openstackclientconfig, and sdk conversations are
>> happening. It's where the end consumers of any API WG effort are, so are
>> incredibly good sounding boards for things we are doing. There is
>> already a large overlap between the two channels, so just pushing
>> forward on that means more critical mass for conversations around the
>> whole space of a more usable API for users.
>>
>> This came up at the last API WG meeting, but those are pretty low quorum
>> events, so this is a thing we should definitely decide over ML instead.
>>
>> Please express your feelings here and lets make it happen. :)
> 
> i don't necessarily have an outright objection to this, but i would like
> explore the future possibilities of this change.
> 
> i think there is possibility for the api-wg to grow and take on more
> responsibility within the openstack community and i'm curious about the
> net effect down the road if that expansion were to occur. are there any
> side-effects we should be aware of as we merge the two
> channels/communities into one namespace?
> 
> i realize there is some overlap of engineering/design that takes place
> on these channels, i'm just concerned about the idea of merging the two
> and then at some point in the future wanting to separate them. i'm not
> proposing these thoughts to quash the idea of joining, i'd just like to
> more fully understand the longer term implications of a merge.
> 
> anyone with more experience in this community-oriented side of things
> have some light to shed?

Typically the only real reason to spin off another channel is that there
are now too many conversations happening all at once that are unrelated
and people are finding it is impeding their ability to get work done. I
can't imagine this happening any time within the next couple of years.
An average day in #openstack-api is < 20 messages (from a quick spot
check in IRC logs).

I feel there is a lot of benefits in having these groups that do related
work all doing it in one channel. Even though it's a number of discreet
outputs, the "hallway track" of having api producers and consumers doing
their business all in front of each other should quite help in ensuring
that we all make something better.

-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] [Ironic] Do we need to have a mid-cycle?

[Jim Rollenhagen]

On Wed, Nov 11, 2015 at 12:16:34PM -0500, Ruby Loo wrote:
> On 10 November 2015 at 12:08, Dmitry Tantsur  wrote:
> 
> > On 11/10/2015 05:45 PM, Lucas Alvares Gomes wrote:
> >
> >> Hi,
> >>
> >> In the last Ironic meeting [1] we started a discussion about whether
> >> we need to have a mid-cycle meeting for the Mitaka cycle or not. Some
> >> ideas about the format of the midcycle were presented in that
> >> conversation and this email is just a follow up on that conversation.
> >>
> >> The ideas presented were:
> >>
> >> 1. Normal mid-cycle
> >>
> >> Same format as the previous ones, the meetup will happen in a specific
> >> venue somewhere in the world.
> >>
> >
> > I would really want to see you all as often as possible. However, I don't
> > see much value in proper face-to-face mid-cycles as compared to improving
> > our day-to-day online communications.
> 
> 
> +2.
> 
> My take on mid-cycles is that if folks want to have one, that is fine, I
> might not attend :)
> 
> My preference is 4) no mid-cycle -- and try to work more effectively with
> people in different locations and time zones.

++ that was part of my thought process when I proposed not having an
official midcycle.

Another idea I floated last week was to do a virtual midcycle of sorts.
Treat it like a normal midcycle in that everyone tells their management
"I'm out for 3-4 days for the midcycle", but they don't travel anywhere.
We come up with an agenda, see if there's any planning/syncing work to
do, or if it's all just hacking on code/reviews.

Then we can set up some hangouts (or similar) to get people in the same
"room" working on things. Time zones will get weird, but we tend to
split into smaller groups at the midcycle anyway; this is just more
timezone-aligned. We can also find windows where time zones overlap when
we want to go across those boundaries. Disclaimer: people may need to
work some weird hours to do this well.

I think this might get a little bit bumpy, but if it goes relatively
well we can try to improve on it for the future. Worst case, it's a
total failure and is roughly equivalent to the "no midcycle" option.

// jim

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

Re: [openstack-dev] [oslo][all] Oslo libraries dropping python 2.6 compatability

[gord chung]

do we require a major versioning bump for this? i'm wondering how 
'breaking' this is in real life if all the services have dropped py2.6 
already. maybe this just requires an upper-cap in appropriate stable 
branches?


to be devils advocate, one (arguably terrible) reason for not doing a 
major bump is that a lot of libs just did one for the Mitaka cycle.


On 11/11/2015 2:14 PM, Davanum Srinivas wrote:

Folks,

Any concerns? please chime in:
https://review.openstack.org/244275

Thanks
-- Dims



--
gord


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

Re: [openstack-dev] [stackalytics] Review metrics: average numbers

[Alexis Lee]

Hi Mike,

Not 100% sure what you're asking for but have you seen these stats?

http://russellbryant.net/openstack-stats/


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

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

Re: [openstack-dev] [oslo][all] Oslo libraries dropping python 2.6 compatability

[Robert Collins]

Yes, major version bump. As long as we don't have to change any consumers,
we have no backwards compatibility concerns because we deprecated 2.6 in
Juno. However i suspect we will have to change consumers specifically we
still had 2.6 jobs in liberty
On 17 Nov 2015 3:23 AM, "Davanum Srinivas"  wrote:

> Gordon,
>
> When we stop the py26 jobs, the next version we release should have
> major bumps by semver definition. liberty does not have version caps
> unfortunately, but i'll let Doug and others chime in on that.
>
> yes, i know major bumps are hard
>
> thanks,
> dims
>
> On Mon, Nov 16, 2015 at 9:07 AM, gord chung  wrote:
> > do we require a major versioning bump for this? i'm wondering how
> 'breaking'
> > this is in real life if all the services have dropped py2.6 already.
> maybe
> > this just requires an upper-cap in appropriate stable branches?
> >
> > to be devils advocate, one (arguably terrible) reason for not doing a
> major
> > bump is that a lot of libs just did one for the Mitaka cycle.
> >
> > On 11/11/2015 2:14 PM, Davanum Srinivas wrote:
> >>
> >> Folks,
> >>
> >> Any concerns? please chime in:
> >> https://review.openstack.org/244275
> >>
> >> Thanks
> >> -- Dims
> >>
> >
> > --
> > gord
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [stable] Making stable maintenance its own OpenStack project team

[Dave Walker]

On 13 November 2015 at 14:10, Thierry Carrez  wrote:
> So.. quick summary of this thread so far.
>
> (-)
> * Not enough work to warrant a designated "team", now that the work is
> decentralized and the cats are mostly herding themselves
> * The change is unlikely to bring a meaningful improvement to the
> situation, or sudden new resources
>
> (+)
> * An empowered team could tackle new coordination tasks, like engaging
> more directly in converging stable branch rules across teams, or
> producing tools
> * Release management doesn't overlap anymore with stable branch, so
> having them under that PTL is limiting and inefficient
> * Reinforcing the branding (by giving it its own team) may encourage
> more organizations to affect new resources to it
>
> In summary, I think this is worth a try. If the team fails, at least it
> will be on its own rather than as the 5th squeaky wheel of release
> management (where lack of leadership and focus could be rightly blamed
> for failure).
>
> For this to succeed, we need someone to own the effort and push it
> forward, and a number of people caring enough about it to attend regular
> meetings about it and to lurk on #openstack-stable. I'm fine helping the
> team in the spin-off effort but I don't want to lead it (I proved I was
> unable to make it my top priority in the past, so I think the team
> deserves a more focused lead).
>
> Erno has volunteered to lead. Ihar, Alan (Pevec) and myself don't have
> enough time to lead but are happy to help. Anyone else interested to
> join that initial group ? Flavio ? Matt ?
>
> Once we have a list of key members we should set up a meeting to discuss
> the details.

I think this summary is pretty reflective of the thread so far.  I
also agree that I see very little benefit from transitioning the
stable-maint-core team into a recognised project team, I can't imagine
there being any measurable benefit from this.. feels more like a paper
exercise..  however, I don't feel strongly enough to try and stop
this.

Due to limited time, I'd not like to be a driver... but would like to
be part of the seed group of cores.  If this is to happen, it  seems
reasonable to map stable-maint-core -> stable-maint project.

We've traditionally been pretty bad with discussion and engaging with
fellow stable-maint members, so a standing (short) meeting might help
improve this.

--
Kind Regards,
Dave Walker

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

Re: [openstack-dev] [Ironic][Nova][Neutron] Multi-tenancy support

[Vasyl Saienko]

Hello Community,

There is 'raw' version of Generic ML2 Driver [0]. It uses 'Netmiko' [1]
library. At the moment it supports Cisco Catalyst switches but it can be
easily extended with ANY ssh enabled switch.

[0] https://github.com/jumpojoy/neutron
[1] https://github.com/ktbyers/netmiko

On Wed, Nov 11, 2015 at 3:15 PM, Sukhdev Kapur 
wrote:

> Hi Vasyl,
>
> I have not cross checked every patch in your list, but, the list looks
> about right.
> From the Ironic, Nova, and Neutron point of the code is pretty much in
> place with these patches.
>
> In this week's meeting we discussed the plan for merging these patches.
> Couple of things are holding us - namely the CI and documentation. We are
> working on getting the CI addressed so that automated testing can be kicked
> off, which will enable us to merge these patches (hopefully in M1).
> Documentation is also underway.
>
> As to ML2 driver (which you are looking for), in order make the CI work,
> we are considering couple of options - either write a canned ML2 driver to
> test this or enhance OVS driver to allow/accept/deal with new interface. We
> did not have full quorum in this week's meeting. Hopefully, we will have
> some concrete plans by the next week. But, this ML2 driver is being
> considered to deal with devstack/CI related testing only.
>
> In order to test the real world scenarios, you will need real HW and
> vendor ML2 driver. The only two vendors that I am aware of who has this
> working are HP and Arista. I do not know if HP is in a position to release
> it yet. Arista will take some time to release it, as we follow very strict
> quality control guidelines before releasing any software. I am only techie
> and do not control the release of software, but, my guess is, its release
> will be aligned with release of Mitaka.
>
> If you believe you can be good with canned ML2 driver for devstack
> initially, that may become available much earlier.
> We meet every Monday at 1700 UTC (8am Pacific time) on
> #openstack-meeting-4. Feel free to drop by or join us - as this is one of
> the things we plan on discussing next Monday's meeting. This will give you
> a better feel.
>
> Hope this helps.
>
> -Sukhdev
> P.S. feel free to ping me on IRC (IRC handle: Sukhdev) on neutron or
> Ironic channels
>
>
> On Tue, Nov 10, 2015 at 3:05 AM, Vasyl Saienko 
> wrote:
>
>> Hello community,
>>
>> I would like to start preliminary testing of Ironic multi-tenant network
>> setup which is supported by Neutron in Liberty according to [1]. I found
>> the following patches that are on review. Also neutron ML2 plugin is
>> needed. I can't find any plugin that supports multi-tenancy and Cisco
>> (Catalyst)/Arista switches. I would be grateful for any information on
>> the matter.
>>
>> *Ironic:*
>>
>> https://review.openstack.org/#/c/206232/
>>
>> https://review.openstack.org/#/c/206238/
>>
>> https://review.openstack.org/#/c/206243/
>>
>> https://review.openstack.org/#/c/206244/
>>
>> https://review.openstack.org/#/c/206245/
>>
>> https://review.openstack.org/#/c/139687/
>>
>> https://review.openstack.org/#/c/213262/
>> https://review.openstack.org/#/c/228496/
>>
>> *Nova:*
>>
>> https://review.openstack.org/#/c/186855/
>> https://review.openstack.org/#/c/194413/
>>
>> *python-ironicclient*:
>> https://review.openstack.org/#/c/206144
>>
>>
>> [1]
>> https://blueprints.launchpad.net/neutron/+spec/neutron-ironic-integration
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ironic] Ironic-Neutron meeting cancellation notice

[Ruby Loo]

On 15 November 2015 at 16:47, Sukhdev Kapur  wrote:

> Folks,
>
> We are canceling this week's Ironic-neutron integration meeting. I have a
> family obligation to take care of and I have not been able to find a
> replacement person who can chair this meeting. Therefore, we will cancel
> this week's meeting.
>
> Next meeting will take place on Monday, January 23 at the usual time at
> usual place.
>
>
That's Monday, November 23, not January 23 :D

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

[openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Duarte Cardoso, Igor]

Hi networking-sfc folks,

I can't seem to be able to deploy the current networking-sfc using DevStack and 
my hint is that the latest review stack is dependent on previous patches that 
have not been updated/rebased yet ([1] and [2]) - and are depending on outdated 
patches.

In [3] you can see the output of q-svc after a clean DevStack installation 
(based on master) with the local.conf specified in [4].
I have pointed /opt/stack/networking-sfc to the last patch in the 
networking-sfc review stack, [5].

Please advise on how to proceed in order to get networking-sfc to work.

[1] https://review.openstack.org/#/c/227285
[2] https://review.openstack.org/#/c/227100
[3] http://paste.openstack.org/show/479020/
[4] http://paste.openstack.org/show/479021/
[5] https://review.openstack.org/#/c/238428/

Best regards,

[intel]

Igor Duarte Cardoso
Software Engineer
+353 61 777 858
SIE1-2-170
Intel Shannon Ltd.
Dromore House, East Park
Shannon, Co. Clare
IRELAND

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing 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] weekly subteam status report

[Ruby Loo]

Hi,

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

Bugs (dtantsur)

(diff with Nov 9)
- Open: 167 (-4). 10 new (-2), 61 in progress (-2), 0 critical, 14 high and
11 incomplete (+1)
- Nova bugs with Ironic tag: 24 (-1). 1 new, 0 critical, 0 high
- Inspector bugs: 14 (-1). 0 new, 0 critical, 7 high (+1)

Network isolation (Neutron/Ironic work) (jroll)
==
- code still in review

Manual cleaning (rloo)
=
- spec approved:
http://specs.openstack.org/openstack/ironic-specs/specs/approved/manual-cleaning.html

Live upgrades (lucasagomes, lintan)

- Working on isolation ir-api from DB
- https://review.openstack.org/#/c/243497/

Boot interface refactor (jroll)
==
- patch landed: Refactor iscsi_ilo driver to use new boot interface
https://review.openstack.org/#/c/216538/
- 3 more patches to land - https://review.openstack.org/#/c/221371/
(iscsi_irmc), https://review.openstack.org/#/c/221577/ (agent_irmc),
https://review.openstack.org/#/c/217102/ (agent_ilo)

Node filter API and claims endpoint (jroll, devananda)
=
- spec under review
- planning to split to two specs this week - the api and the db things

Multiple compute hosts (jroll, devananda)
- waiting on claims api

ironic-lib adoption (rloo)
==
- patch for ironic to use ironic-lib: https://review.openstack.org/184443.
It is currently blocked due to rloo (and deva) being unhappy with how
configs are being handled between ironic & ironic-lib.
- We will migrate (and deprecate) deploy's 'efi_system_partition_size',
'dd_block_size', 'iscsi_verify_attempts' configs to ironic-lib.
- ironic-lib includes code that makes system calls (via oslo's
processutils.execute()). For ironic, some of these calls need to be run as
root and rootwrap/filter information. Apparently, for IPA, none of them
need to be run as root. So we're going to modify ironic-lib as follows:
- modify ironic-lib to take one 'root_helper' config instead of having
'rootwrap_config' & 'rootwrap_helper_cmd' configs:
https://bugs.launchpad.net/ironic-lib/+bug/1515943. ironic will set this
value as 'sudo ironic-wrap /etc/ironic/rootwrap.conf'
- ironic-lib will need to provide sample rootwrap_filters file and will
need to document usage of if. ironic will modify /etc/ironic/rootwrap.d to
include the new file.
- All executes that had (when in ironic) 'run_as_root' set will only
have it set if root_helper is set.
- do we deprecate ironic's rootwrap_config?
- In (almost) hindsight, I wonder if it would have been useful to have had
a spec to point out/resolve these issues before we created ironic-lib or
maybe these are the details to be hammered out when coding.

Oslo (lintan)
==
- oslo libraries will drop python 2.6 compatibility, but
python-ironicclient are still support py2.6. We should drop this recently,
any objections?
- https://review.openstack.org/244275
- let's drop it with the rest of the clients, which seems like right
about now :) // jroll
- I'll investigate if there's any additional details here and do
whatever is needed
- Oslo remove apiclient from oslo-incubation recently, apiclient and clutil
were widely used by python-*-clients. As suggested by oslo team, here is
the plan:
- Make a local copy of clituils and apiclient and maintain by ourself
- Adopt cliff+keystoneauth when it is necessary in future
- https://review.openstack.org/#/c/243578/

Doc (jroll, liliars)
=
- no updates from jroll
- initial discussion on splitting/improving install guide /liliars
- haven't contacted openstack docs team yet /liliars

Testing/Quality (jlvillal/lekha/krtaylor)

- meeting held last Wed at 1700UTC
- CI spec making good progress, documenting/agreement on details, krtaylor
to rev spec with all latest comments
- no update on grenade or functional testing

Inspector (dtansur)
===
- added non-voting IPA job. does not pass, something seems wrong around
TFTP/PXE. Investigating.

Drivers
==
AMT (lintan)
-
- (deva) in-tree AMT driver has been working reliably for past few weeks,
so I may stop maintaining my out-of-tree driver

iLO (wanyen)
--
- Need reviews on some iLO driver specs that have been around for a while:
- Add Zapping support to iLO drivers -
https://review.openstack.org/145404
- Add support for UEFI iSCSI boot - https://review.openstack.org/207337
- Enhance ilo drivers to do inband inspection -
https://review.openstack.org/201904

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- 

Re: [openstack-dev] [puppet] weekly meeting #59

[Iury Gregory]

Hi Emilien, the link for the agenda is
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-2015111 or
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117 ?
Thanks o/


2015-11-16 14:04 GMT-03:00 Emilien Macchi :

> Hello!
>
> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
> in #openstack-meeting-4:
>
> https
> 
> ://
> 
> etherpad.openstack.org
> 
> /p/puppet-openstack-weekly-meeting-2015111
> 
> 7
>
> I'm back online tomorrow morning.
>
> Thanks,
> ---
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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] When to use parameters vs parameter_defaults

[Giulio Fidente]

On 11/16/2015 04:25 PM, Steven Hardy wrote:

Hi all,

I wanted to start some discussion re $subject, because it's been apparrent
that we have a lack of clarity on this issue (and have done ever since we
started using parameter_defaults).


[...]


How do people feel about this example, and others like it, where we're
enabling common, but not mandatory functionality?


At first I was thinking about something as simple as: "don't use 
top-level params for resources which the registry doesn't enable by 
default".


It seems to be somewhat what we tried to do with the existing pluggable 
resources.


Also, not to hijack the thread but I wanted to add another question 
related to a similar issue:


  Is there a reason to prefer use of parameters: instead of 
parameter_defaults: in the environment files?


It looks to me that by defaulting to parameter_defaults: users won't 
need to update their environment files in case the parameter is moved 
from top-level into a specific nested stack so I'm inclined to prefer 
this. Are there reasons not to?

--
Giulio Fidente
GPG KEY: 08D733BA

__
OpenStack Development Mailing 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] weekly meeting #59

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
in #openstack-meeting-4:

https

://

etherpad.openstack.org

/p/puppet-openstack-weekly-meeting-2015111
7

I'm back online tomorrow morning.

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

Re: [openstack-dev] REST API collation and visualization

[Neil Jerram]

On 16/11/15 16:37, Neil Jerram wrote:
> Hi there,
>
> I'm interested in collating all the REST API exchanges to and between
> OpenStack components, and presenting / visualizing all those in an
> easily comprehensible way.  Is there already some tool to do that?
>
> Many thanks,
> Neil

Well here's a start anyway, for capturing requests into Neutron:

$ sudo tshark -i any -d tcp.port==9696,http -f 'tcp port 9696' -V -Y
http | awk -f filter.awk > pcap.txt

where filter.awk is:

--cut here---
BEGIN {
disp = 0;
}

/^[A-Z]/ {
disp = 0;
}

/^Hypertext/ {
disp = 1;
}

/^Java/ {
disp = 1;
}

{
if (disp) print;
}
--cut here---

But I'm guessing that more developed things already exist?

Neil


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

Re: [openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

[Ruby Loo]

On 10 November 2015 at 11:31, Dmitry Tantsur  wrote:

> On 11/10/2015 05:21 PM, Brad P. Crochet wrote:
>
>> On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur 
>> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to seek consensus (or at least some opinions) on patch
>>> https://review.openstack.org/#/c/206119/
>>> It proposed the following command:
>>>
>>>
>> I think it's time to actually just write up a spec on this. I think we
>> would be better served to spell it out now, and then more people can
>> contribute to both the spec and to the actual implementation once the
>> spec is approved.
>>
>> WDYT?
>>
>
> +1
>
> I'll block the first patch until we get consensus. Thanks for working on
> it!
>
>
+2. Sorry for not paying attention to this. In retrospect, it would have
been good to have had a spec before we landed any of the code.

When the subject has 'Quick' in it, it isn't quick, but thanks for raising
the issue Dmitry! :)

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

Re: [openstack-dev] REST API collation and visualization

[Neil Jerram]

On 16/11/15 17:54, Neil Jerram wrote:
> On 16/11/15 16:37, Neil Jerram wrote:
>> Hi there,
>>
>> I'm interested in collating all the REST API exchanges to and between
>> OpenStack components, and presenting / visualizing all those in an
>> easily comprehensible way.  Is there already some tool to do that?
>>
>> Many thanks,
>> Neil
> Well here's a start anyway [...]

Latest evolution below, for anyone else interested in this.  This
version captures REST API for all OpenStack endpoints on the local node.

Neil

#!/bin/bash

set - `openstack catalog list --format csv | gawk '{ if (match($0,
"publicURL: http://[^:]*:([^/]*)/", arr)) { print arr[1]; } }' | sort |
uniq`

display_filter_for_port () {
echo "-d tcp.port==$1,http"
}

capture_filter_for_port() {
echo "tcp port $1"
}

display_filters=`display_filter_for_port $1`
capture_filters=`capture_filter_for_port $1`
shift

for port in $*; do
display_filters="$display_filters `display_filter_for_port $port`"
capture_filters="$capture_filters or `capture_filter_for_port $port`"
done

sudo tshark -i any $display_filters -f "$capture_filters" -V -Y http | awk '

BEGIN {
disp = 0;
}

/^[A-Z]/ {
disp = 0;
}

/^Hypertext/ {
disp = 1;
}

/^Java/ {
disp = 1;
}

{
if (disp) print;
}
'


__
OpenStack Development Mailing 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] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Hello folks,

I have updated the spec, please review and share your thoughts on it:
https://review.openstack.org/#/c/243340/

Thanks.

On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov 
wrote:

> Matthew,
>
> sorry, didn't mean to butcher your name :(
>
> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov 
> wrote:
>
>> Matther,
>>
>> I totally agree that each daemon should have it's own user which should
>> be created during installation of the relevant package. Probably I didn't
>> state this clear enough in the spec.
>>
>> However, there are security requirements in place that root should not be
>> used at all. This means that there should be a some kind of maintenance or
>> system user ('fueladmin'), which would have enough privileges to configure
>> and manage Fuel node (e.g. run "sudo puppet apply" without password, create
>> mirrors etc). This also means that certain fuel- packages would be required
>> to have their files accessible to that user. That's the idea behind having
>> a package which would create 'fueladmin' user and including it into other
>> fuel- packages requirements lists.
>>
>> So this part of the feature comes down to having a non-root user with
>> sudo privileges and passwordless sudo for certain commands (like 'puppet
>> apply ') for scripting.
>>
>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn > > wrote:
>>
>>> Dmitry,
>>>
>>> We really shouldn't put "user" creation into a single package and then
>>> depend on it for daemons. If we want nailgun service to run as nailgun
>>> user, it should be created in the fuel-nailgun package.
>>> I think it makes the most sense to create multiple users, one for each
>>> service.
>>>
>>> Lastly, it makes a lot of sense to tie a "fuel" CLI user to
>>> python-fuelclient package.
>>>
>>> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov >> > wrote:
>>>
 Stanislaw,

 I agree that this approch would work well. However, does Puppet allow
 managing capabilities and/or file ACLs? Or can they be easily set up when
 installing RPM package? (is there a way to specify capabilities/ACLs in the
 RPM spec file?) This doesn't seem to be supported out of the box.

 I'm going to research if it is possible to manage capabilities and
  ACLs with what we have out of the box (RPM, Puppet).

 On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Dmitry, I propose to give needed linux capabilities
> (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
> then start these processes from non-privileged user. It will give you
> ability to run each process without 'sudo' at all with well fine-grained
> permissions.
>
> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <
> dnikis...@mirantis.com> wrote:
>
>> Stanislaw,
>>
>> I've been experimenting with 'capsh' on the 6.1 master node and it
>> doesn't seem to preserve any capabilities when setting SECURE_NOROOT bit,
>> even if explicitely told to do so (via either --keep=1 or
>> "SECURE_KEEP_CAPS" bit).
>>
>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <
>> dnikis...@mirantis.com> wrote:
>>
>>> Bartolomiej, Adam,
>>> Stanislaw is correct. And this is going to be ported to master. The
>>> goal currently is to reach an agreement on the implementation so that
>>> there's going to be a some kinf of compatibility during upgrades.
>>>
>>> Stanislaw,
>>> Do I understand correctly that you propose using something like
>>> sucap to launch from root, switch to a different user and then drop
>>> capabilities which are not required?
>>>
>>> On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
 Bartolomiej, it's customer-related patches, they, I think, have to
 be done for 6.1 prior to 8+ release.

 Dmitry, it's nice to hear about it. Did you consider to use linux
 capabilities on fuel-related processes instead of just using 
 non-extended
 POSIX privileged/non-privileged permission checks?

 On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
 bpiotrow...@mirantis.com> wrote:

> We don't develop features for already released versions… It should
> be done for master instead.
>
> BP
>
> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko  > wrote:
>
>> Dmitry,
>> +1
>>
>> Do you plan to port your patchset to future Fuel releases?
>>
>> A.
>>
>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <
>> dnikis...@mirantis.com> wrote:
>>
>>> Hey guys.
>>>
>>> I've been working on making Fuel 

Re: [openstack-dev] [Ironic][Nova][Neutron] Multi-tenancy support

[Sean M. Collins]

On Mon, Nov 16, 2015 at 12:47:13PM EST, Vasyl Saienko wrote:
> [0] https://github.com/jumpojoy/neutron

The way you created the repository in GitHub, it is impossible to diff
it against master to see what you did.

https://github.com/jumpojoy/neutron/compare

-- 
Sean M. Collins

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Sean M. Collins]

Chatted with Sean D. on IRC, pushed up a patch 

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

-- 
Sean M. Collins

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

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[gord chung]

On 16/11/2015 11:13 AM, Doug Hellmann wrote:

  does anyone want to sign up to remove that last
namespace package?

already in action: https://review.openstack.org/#/c/243255/

--
gord


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

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Doug Hellmann]

Excerpts from gord chung's message of 2015-11-16 12:04:27 -0500:
> 
> On 16/11/2015 11:13 AM, Doug Hellmann wrote:
> >   does anyone want to sign up to remove that last
> > namespace package?
> already in action: https://review.openstack.org/#/c/243255/
> 

Thanks, Gordon!

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

[openstack-dev] [Glance] M-1 Bugs/Reviews squash day

[Flavio Percoco]

Greetings,

At our last meeting, we discussed the idea of having a Bug/Reviews
squash day before the end of M-1. I'm sending this email out to
propose that we do this work on one of the following dates:

- Friday November 20th (ALL TZs)
- Monday November 23rd (ALL TZs)

I realize that next week is Thanksgiving in the US and some folks
might want to take the whole week. Please, do vote before Wednesday
18th so we can prepare for Friday and/or monday.

Poll link: http://doodle.com/poll/mt7hwswtmcvmetdn

Thanks,
Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Networking-sfc not just a shell. It has API, DB, DB Migration, Common Driver 
Manager, OVS Driver, OVS Agent, CLI, Horizon etc. codes uploaded for review for 
over one month. The project team is in the final review stage. And a patch for 
adding DevStack support for networking-sfc has also been uploaded for review. 
Once these codes are merged, the codes will be ready for download and 
deployment. 

Thanks,
Cathy

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Monday, November 16, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

Networking-sfc is still just a shell - there is no functional code.

-- 
Sean M. Collins

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

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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Hi Duarte,

We have just rebased the patches. We are in the stage of more comprehensive 
testing, bug fixes, review, and incorporating review comments. The code patches 
including the devstack patch will be merged once they are properly reviewed, 
and you can then download and deploy this functionality.

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, November 16, 2015 10:34 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

Hi networking-sfc folks,

I can't seem to be able to deploy the current networking-sfc using DevStack and 
my hint is that the latest review stack is dependent on previous patches that 
have not been updated/rebased yet ([1] and [2]) - and are depending on outdated 
patches.

In [3] you can see the output of q-svc after a clean DevStack installation 
(based on master) with the local.conf specified in [4].
I have pointed /opt/stack/networking-sfc to the last patch in the 
networking-sfc review stack, [5].

Please advise on how to proceed in order to get networking-sfc to work.

[1] https://review.openstack.org/#/c/227285
[2] https://review.openstack.org/#/c/227100
[3] http://paste.openstack.org/show/479020/
[4] http://paste.openstack.org/show/479021/
[5] https://review.openstack.org/#/c/238428/

Best regards,

[intel]

Igor Duarte Cardoso
Software Engineer
+353 61 777 858
SIE1-2-170
Intel Shannon Ltd.
Dromore House, East Park
Shannon, Co. Clare
IRELAND


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
__
OpenStack Development Mailing 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] [DefCore] Request for comments: Is booting Linux VM required for OpenStack interoperability?

[Egle Sigler]

Hello Everyone,

DefCore committee would like to hear your input on this issue: 
https://review.openstack.org/#/c/244782/
The issue is not really vendor specific. At the heart of the issue is this 
question: for interoperability reasons, should certified OpenStack powered 
compute clouds be able to boot a Linux VM? And if so, would OpenStack based 
clouds running only Linux based containers be excluded? How about bare metal 
clouds?

Please comment, and let me know if you have any questions.


Thank you,

Egle Sigler

DefCore Committee Co-Chair


DefCore sets base requirements by defining 1) capabilities, 2) code and 3) 
must-pass tests for all OpenStack products. This definition uses community 
resources and involvement to drive interoperability by creating the minimum 
standards for products labeled "OpenStack."

Our mission is to define "OpenStack Core" as chartered by the by-laws.

How to get involved in DefCore:

Join the mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Find us on IRC (chat.freenode.net): #openstack-defcore

Submit, review, comment: 
https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Join our weekly meetings on IRC: 
https://wiki.openstack.org/wiki/Governance/DefCoreCommittee#Meetings


New to DefCore?  Some pointers:

Intro to DefCore with heavy references to Dr. Who 
http://www.slideshare.net/markvoelker/defcore-the-interoperability-standard-for-openstack-53040869

DefCore 101 Tokyo presentation and slides: 
https://www.youtube.com/watch?v=MfUAuObSkK8  
http://www.slideshare.net/rhirschfeld/tokyo-defcore-presentation

Wiki: https://wiki.openstack.org/wiki/DefCore

Hacking file: https://github.com/openstack/defcore/blob/master/HACKING.rst


__
OpenStack Development Mailing 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] [tacker] Proposing Sripriya Seetharam to Tacker core

[Sripriya Seetharam]

Thank you. Will try to do my best!

-Sripriya

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Monday, November 16, 2015 11:42 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [tacker] Proposing Sripriya Seetharam to Tacker 
core

Thanks everyone.

Sripriya - welcome to the tacker-core!

- Sridhar

On Wed, Nov 11, 2015 at 1:09 AM, Bharath Thiruveedula 
> 
wrote:
+1

On Tue, Nov 10, 2015 at 10:42 PM, Stephen Wong 
> wrote:
+1

On Mon, Nov 9, 2015 at 6:22 PM, Sridhar Ramaswamy 
> wrote:
I'd like to propose Sripriya Seetharam to join the Tacker core team. Sripriya
ramped up quickly in early Liberty cycle and had become an expert in the Tacker
code base. Her major contributions include landing MANO API blueprint,
introducing unit test framework along with the initial unit-tests and tirelessly
squashing hard to resolve bugs (including chasing the recent nova-neutron goose
hunt). Her reviews are solid fine tooth comb and constructive [1].

I'm glad to welcome Sripriya to the core team. Current cores members, please 
vote
with your +1 / -1.

[1] 
http://stackalytics.com/?release=libertyuser_id=sseethaproject_type=openstack-others

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


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


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

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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Kyle Mestery]

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant  wrote:

> On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> > On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
> >> This is a challenge. Personally, I haven't been able to get it all
> working
> >> yet. But we're in a dilemma because we want to get good reviews of the
> code
> >> before merging. Since the full functionality is quite a lot of code we
> >> wanted to chop it into more easily reviewable chunks. Unfortunately that
> >> makes it more difficult to pull it all in at once to test the whole
> thing
> >> prior to completing the review and merge.
> >
> > I would be concerned about that. I am sympathetic to the chicken and egg
> > problem of a new repo and new code, but I briefly looked at both of
> > those reviews and they both are quite large. 1K LOC is usually the upper
> > limit for a sane patch set. It may be worth trying to break into
> > smaller, more manageable pieces - even if the initial commits just
> > create some empty classes and stubbed methods, and then later start
> > introducing the actual method bodies in small pieces with good unit
> > tests for each one. Small pieces. Tiny steps.
>
> Another thing I've been thinking about is the difference between having
> a repo like networking-sfc where a sub-group is able to try out new
> things while also managing expectations with consumers of Neutron.  How
> does someone know the difference between something a bit more
> experimental vs. when an API is established and can be considered stable
> and maintained with backwards copmatibility like any other OpenStack
> REST API?
>
> In the case of SFC, consumers of the API should know it's tagged as
"release:independent" [1], and also it should be clear there is no release
made and the code isn't stable in the docs, but that isn't currently the
case looking here [2]. Thus, I've submitted [3] to make this a bit more
clear, comments welcome.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] http://docs.openstack.org/developer/networking-sfc/
[3] https://review.openstack.org/246001


> I think networking-sfc should be able to keep merging code, including
> the proposed API, but I think it should be clearly marked as
> experimental and subject to change.  That's based on my experience so
> far studying this proposal, SFC more generally, and watching other
> efforts happening within Neutron that affect this.
>
> How can we manage these expectations more clearly?
>
> Well, since it hasn't released yet, I agree, lets experiment and let other
backends try this out, and at the same time not lock things down. We just
need to be clear about the intent here.

Thanks,
Kyle


> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [OSSN 0059] Trusted VM can be powered on untrusted hosts

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Trusted VM can be powered on untrusted hosts
- ---

### Summary ###
A trusted VM that has been launched earlier on a trusted host can
still be powered on from the same host even after the trusted host is
compromised.

### Affected Services / Software ###
Nova, Trusted Computing Pools

### Discussion ###
Trusted Computing Pools aim to ensure the trustworthiness of the hosts
leveraging hardware-based security features. When an instance is
scheduled, the scheduler finds a trusted host by calling the remote
Attestation API for each host to check whether it is trusted or not.
Then, the scheduler calls the corresponding compute node to launch
the VM. Once the VM is launched, the scheduler is no longer involved
unless a migration, a resize or an evacuation is asked for that VM.

Malicious users can bypass the trust check by the Attestation API using
these steps: 1) Launch a trusted VM on a trusted host; 2) Stop the
VM on the trusted host; 3) Compromise the host; 4) Power on the VM from
the compromised host. There is no check by the Attestation API for
powering on the VM in this case.

### Recommended Actions ###
We recommend investigating further if the trust check by Attestation
API fails but the VM still boots. Another approach is to combine
secure boot with trusted boot. At the same time, Nova team has
discussed deprecating Trusted Filter.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0059
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1456228
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Nova Team Email Proposing Deprecation:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/067766.html
CR Demoting TrustedFilter to "experimental":
https://review.openstack.org/#/c/194592
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWSkwBAAoJEJa+6E7Ri+EVu3YH/00Q2zKoTBh1DydSs9HNREJk
NCaQ+T7Imiwwb4AQzSVcyyQsr46RlQNL2d5J0/dS1+Xdv1i/agpPYhaM1tlHQETE
dM70JjJrBOnRlbMSLY2dleIQRdSatBAHD1XXyJGWU906GmUbY1WAmdMqFV5Xbg5A
GsIFmIQJJiH+ZsT0ByU1FeAgeIfAlPM75cy2estDSnsxuv4V36vrKCgAJ4jfHsfY
ZWl5v0S6FcEuygiwqDNSUmrR2iYiZGdyM20CATRSME/LH1JTWP+wNxLqJrcG2vIL
ztJOBduMAm/qdekeAu3aqFpWDq7n8fVlI2ma6XqE3Ygrb5dDbF6KYuCAwBafmSU=
=ZUVf
-END PGP SIGNATURE-

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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Sean M. Collins]

On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
> This is a challenge. Personally, I haven't been able to get it all working
> yet. But we're in a dilemma because we want to get good reviews of the code
> before merging. Since the full functionality is quite a lot of code we
> wanted to chop it into more easily reviewable chunks. Unfortunately that
> makes it more difficult to pull it all in at once to test the whole thing
> prior to completing the review and merge.

I would be concerned about that. I am sympathetic to the chicken and egg
problem of a new repo and new code, but I briefly looked at both of
those reviews and they both are quite large. 1K LOC is usually the upper
limit for a sane patch set. It may be worth trying to break into
smaller, more manageable pieces - even if the initial commits just
create some empty classes and stubbed methods, and then later start
introducing the actual method bodies in small pieces with good unit
tests for each one. Small pieces. Tiny steps.

My $0.02 USD

-- 
Sean M. Collins

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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Russell Bryant]

On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
>> This is a challenge. Personally, I haven't been able to get it all working
>> yet. But we're in a dilemma because we want to get good reviews of the code
>> before merging. Since the full functionality is quite a lot of code we
>> wanted to chop it into more easily reviewable chunks. Unfortunately that
>> makes it more difficult to pull it all in at once to test the whole thing
>> prior to completing the review and merge.
> 
> I would be concerned about that. I am sympathetic to the chicken and egg
> problem of a new repo and new code, but I briefly looked at both of
> those reviews and they both are quite large. 1K LOC is usually the upper
> limit for a sane patch set. It may be worth trying to break into
> smaller, more manageable pieces - even if the initial commits just
> create some empty classes and stubbed methods, and then later start
> introducing the actual method bodies in small pieces with good unit
> tests for each one. Small pieces. Tiny steps.

Another thing I've been thinking about is the difference between having
a repo like networking-sfc where a sub-group is able to try out new
things while also managing expectations with consumers of Neutron.  How
does someone know the difference between something a bit more
experimental vs. when an API is established and can be considered stable
and maintained with backwards copmatibility like any other OpenStack
REST API?

I think networking-sfc should be able to keep merging code, including
the proposed API, but I think it should be clearly marked as
experimental and subject to change.  That's based on my experience so
far studying this proposal, SFC more generally, and watching other
efforts happening within Neutron that affect this.

How can we manage these expectations more clearly?

-- 
Russell Bryant

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

[openstack-dev] [Oslo] Virtual sprint! End of this week!! (get'm while they are hot)

[Joshua Harlow]

Howdy folks,

This week the oslo team will be offering a one time deal that everyone
will be interested in!

We will be offering 100% off on documentation changes during this
week's documentation (*virtual*) sprint[1].

Starting this Thursday and Friday we will (as a group/team) be
accepting all natural organic reviews made by local craftspersons with
minimial delivery (and review) time. We would like to see you there
(in #openstack-oslo and/or #openstack-sprint channel) if you are
willing and able to attend this 'once' in a 'lifetime' event.

In other words, *virtual* documentation sprint, this Thursday and
Friday; we as the oslo team will be focusing on documentation so
if you are capable and want to help make the oslo docs better
(more examples, more tweaks, better docstrings...) please feel
free to attend.

Last time[2] we merged around 88 reviews, let's see if we can do
better this time!

See you then,

Joshua Harlow

[1]: https://etherpad.openstack.org/p/oslo-mitaka-1-virtual-doc-sprint
[2]: https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint

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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Sean M. Collins]

Networking-sfc is still just a shell - there is no functional code.

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

I have updated the etherpad to add "Overall requirement - API cross check among 
the features that can manipulate the same flow's forwarding behavior".

Thanks,
Cathy

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Monday, November 16, 2015 7:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

On 11/13/2015 7:03 PM, Henry Fourie wrote:

>
>   I wonder whether just pushing flows into the existing tables at random 
> points in time can be unstable and break the usual flow assumed by the main 
> agent loop.
> LF> No not expect any issues.
>
> Am I making sense?
>
> [1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
>

I attempted to describe a possible issue at the bottom of the Etherpad in the 
bullet point "Overall requirement - Flow prioritization mechanism"



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

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

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

[Jay Dobies]

Hi all,

I wanted to start some discussion re $subject, because it's been apparrent
that we have a lack of clarity on this issue (and have done ever since we
started using parameter_defaults).

Some context:

- Historically TripleO has provided a fairly comprehensive "top level"
   parameters interface, where many per-role and common options are
   specified, then passed in to the respective ResourceGroups on deployment

https://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/overcloud-without-mergepy.yaml#n14

The nice thing about this approach is it gives a consistent API to the
operator, e.g the parameters schema for the main overcloud template defines
most of the expected inputs to the deployment.

The main disadvantage is a degree of template bloat, where we wire dozens
of parameters into each ResourceGroup, and from there into whatever nested
templates consume them.

- When we started adding interfaces (such as all the OS::TripleO::*ExtraConfig*
   interfaces, there was a need to enable passing arbitrary additional
   values to nested templates, with no way of knowing what they are (e.g to
   enable wiring in third-party pieces we have no knowledge of or which
   require implementation-specific arguments which don't make sense for all
   deployments.

To do this, we made use of the heat parameter_defaults interface, which
(unlike normal parameters) have global scope (visible to all nested stacks,
without explicitly wiring in the values from the parent):

http://docs.openstack.org/developer/heat/template_guide/environment.html#define-defaults-to-parameters

The nice thing about this approach is its flexibility, any arbitrary
values can be provided without affecting the parent templates, and it can
allow for a terser implementation because you only specify the parameter
definition where it's actually used.

The main disadvantage of this approach is it becomes very much harder to
discover an API surface for the operator, e.g the parameters that must be
provided on deployment by any CLI/UI tools etc.  This has been partially
addressed by the new-for-liberty nested validation heat feature, but
there's still a bunch of unsolved complexity around how to actually consume
that data and build a coherent consolidated API for user interaction:

https://github.com/openstack/heat-specs/blob/master/specs/liberty/nested-validation.rst

My question is, where do we draw the line on when to use each interface?

My position has always been that we should only use parameter_defaults for
the ExtraConfig interfaces, where we cannot know what reasonable parameters
are.  And for all other "core" functionality, we should accept the increased
template verbosity and wire arguments in from overcloud-without-mergepy.

However we've got some patches which fall into a grey area, e.g this SSL
enablement patch:

https://review.openstack.org/#/c/231930/46/overcloud-without-mergepy.yaml

Here we're actually removing some existing (non functional) top-level
parameters, and moving them to parameter_defaults.

I can see the logic behind it, it does make the templates a bit cleaner,
but at the expense of discoverablility of those (probably not
implementation dependent) parameters.

How do people feel about this example, and others like it, where we're
enabling common, but not mandatory functionality?

In particular I'm keen to hear from Mainn and others interested in building
UIs on top of TripleO as to which is best from that perspective, and how
such arguments may be handled relative to the capabilities mapping proposed
here:

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

Thanks!

Steve



(in re-reading this, I realize I'm not providing an answer to how I feel 
about the example as I am adding some more thoughts in general; 
apologies for that)


I see there being a few issues with the current approach:

- I'll get this one out of the way first, even though it's not the 
biggest issue. The name 'parameter_defaults' tends to confuse new 3rd 
party integrators since we're not using it as a default per se. I 
understand from Heat's point of view it's defaulting a parameter value, 
but from the user's standpoint, they are setting an actual value to be 
used. Perhaps this can be solved with better docs, and I largely mention 
it because I can see most of what you wrote in here turning into 
documentation, so it'll be good to have it mentioned.


- Back to the point of your e-mail, there are two ways to view it.

-- If you define too few parameters at the top level, you end up with a 
lot of comments like the following inside of nested templates:


ControlPlaneSubnetCidr: # Override this via parameter_defaults

or

# To be defined via a local or global environment in parameter_defaults
  rhel_reg_activation_key:
type: string

There are other examples too, but the thing to note is that we've so far 
been pretty good about adding those comments. It's not a programmatic 
marker, which may be a problem for a UX, but at least the 

Re: [openstack-dev] [tripleo] Location of TripleO REST API

[Jay Dobies]

On 11/10/2015 10:08 AM, Tzu-Mainn Chen wrote:

Hi all,

At the last IRC meeting it was agreed that the new TripleO REST API
should forgo the Tuskar name, and simply be called... the TripleO
API.  There's one more point of discussion: where should the API
live?  There are two possibilities:

a) Put it in tripleo-common, where the business logic lives.  If we
do this, it would make sense to rename tripleo-common to simply
tripleo.


+1

If the exercise is to move the logic behind an API, let's not have two 
avenues into that logic.



b) Put it in its own repo, tripleo-api


The first option made a lot of sense to people on IRC, as the proposed
API is a very thin layer that's bound closely to the code in tripleo-
common.  The major objection is that renaming is not trivial; however
it was mentioned that renaming might not be *too* bad... as long as
it's done sooner rather than later.

What do people think?


Thanks,
Tzu-Mainn Chen

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



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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Paul Carver]

On 11/16/2015 3:39 PM, Sean M. Collins wrote:

Networking-sfc is still just a shell - there is no functional code.



To be more clear, most of the code has not yet been merged. Click here 
for a link to all the pending reviews that contain lots of functional 
code targetted at merging into the networking-sfc repo:


https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc,n,z

I believe Igor is aware of this and is trying to figure out how to pull 
all the necessary pending changes that are targetted at the 
networking-sfc repo but which haven't merged yet.


This is a challenge. Personally, I haven't been able to get it all 
working yet. But we're in a dilemma because we want to get good reviews 
of the code before merging. Since the full functionality is quite a lot 
of code we wanted to chop it into more easily reviewable chunks. 
Unfortunately that makes it more difficult to pull it all in at once to 
test the whole thing prior to completing the review and merge.


Either way, there's a whole lot of code. It just* needs to be reviewed.

* Ok, "just" may downplay the amount of effort needed.


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

Re: [openstack-dev] [Ironic][Nova][Neutron] Multi-tenancy support

[Jim Rollenhagen]

On Mon, Nov 16, 2015 at 06:38:28PM +, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 12:47:13PM EST, Vasyl Saienko wrote:
> > [0] https://github.com/jumpojoy/neutron
> 
> The way you created the repository in GitHub, it is impossible to diff
> it against master to see what you did.
> 
> https://github.com/jumpojoy/neutron/compare

FWIW, it appears to just be a single commit on top of Neutron from about
a week ago.

https://github.com/jumpojoy/neutron/commits/generic_switch
https://github.com/jumpojoy/neutron/commit/96de518c30459c91c06789fcc6d17a5d29ed3adc

This should totally be a separate repo with just the plugin, though.

// jim

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

Re: [openstack-dev] [Fuel][Infra] HA deployment tests on nodepool

[James E. Blair]

Aleksandra Fedorova  writes:

> Hi, everyone,
>
> 
>
> in Fuel project we run two HA deployment tests for every commit in
> openstack/fuel-library repository. Currently these tests are run by
> Fuel CI - the standalone Third-Party CI system, which can vote on
> openstack/fuel* projects. But we'd like it to be the part of the gate.
> As these tests require several vms to be available for the test run,
> we'd like to use nodepool multinode support for that.
>
> 



Cool!  In the long run I think this is technically possible and I think
we are at a stage where you can start to make forward progress, but the
current state is not plug-and-play because a lot of the work so far has
been focused on devstack.  It will be great to have more people looking
at this and helping us make it generic.



> How this can be addressed in nodepool
> =
>
> The nodepool driver approach
> 
>
> fuel-devops is essentially a wrapper and vm's manager, and it was
> originally planned as a tool which can use multiple backends, taking
> libvirt as a default one. There is an still-on-discussion task to
> implement the 'bare-metal driver' for fuel-devops, which would make it
> possible to use vm's from different servers for one particular test
> run.
>
> We can consider implementing nodepool as a driver, so it provides
> vm's, which then are wrapped by fuel-devops and are sent further to
> fuel-qa framework.
>
> Then to run the test we would need a 'manager vm' where fuel-devops
> code is executed, and several empty nodes from nodepool. We'd register
> those empty nodes in fuel-devops database and run the test as usual.

We want our nodes to be supplied by Nodepool and our jobs to be
controlled by Zuul -- we don't want to have a node provisioning system
specific to a single kind of job.  In Zuulv3 [1] we are proposing to make
this more flexible, but still want to keep with that approach.  Your
next suggestion looks more compatible.

[1] http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html

> No fuel-devops approach
> ---
>
> Direct approach would be to use the nodepool's service for pre-built images.
>
> Given by Fuel ISO image, we regularly generate one vm with deployed
> Fuel node (step 1.), and one with the basic node deployed with
> bootstrap image (step 2.). This images are stored in Glance or another
> storage as usual.
>
> Then for each fuel-library test we request 1 Fuel node and several
> basic nodes, and then operate on them directly without wrappers.
>
> For this scenario to work we need to change a lot in fuel-qa code. But
> this approach seems to be aligned with the initiative [8], which is
> currently in development: if we manage to describe devops environments
> in YAML files, we'd probably be able to map these descriptions to the
> multinode configurations, and then support them in nodepool.

If you need this to boot in a top-level VM (rather than a VM inside of a
VM, which is what happens for trove jobs and others like it), then yes,
this might work as a custom image type for nodepool.

We are trying to reduce the number of custom images we have in nodepool,
but perhaps this is a compelling reason to add one.

Note that right now nodepool multi-node support only lets us get groups
of nodes from identical images.  I think that can change with the Zuulv3
work, so it's good to have potential requirements like this as we get
started on that.

On another subject, you might also want to look at the devstack
multinode documentation[2].

It's obviously very devstack specific, but we might want to pull that
out of devstack and put it in nodepool ready scripts or something similar.

[2] 
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/multinode_setup_info.txt

> Side Question
> =
>
> Can we build package from a change request so that package is then
> used in test? Are there any best practices?

You can start a job by building a package and then provide it by
building a local package archive.

-Jim

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

Re: [openstack-dev] [Fuel] Deprecation of GRE network segmentation in Fuel 8.0

[Igor Kalnitsky]

Hey Artem,

> GRE network segmentation option has been deprecated for clusters
> with Neutron since 7.0 release, both on UI and Library side

What do you mean by "deprecated"? Was it removed? If so, why did we
have a chance to create GRE if it wasn't supported?

If so, we definitely have to forbid creation of GRE clusters, but only
when it's stop being supportable. Old envs should support it.

Regards,
Igor

On Mon, Nov 16, 2015 at 8:55 AM, Artem Roma  wrote:
> Hi all!
>
> AFAIK, GRE network segmentation option has been deprecated for clusters with
> Neutron since 7.0 release, both on UI and Library side. One still can use
> the option via CLI as no relevant changes were made to Nailgun API. Though
> appropriate warning is displayed in the case.
>
> So I wanted to ask: are we going to carry such behavior of the API in 8.0 or
> should we also remove processing of the option?
>
> In my opinion we should at least forbid cluster creation via API with the
> parameter as this is the only stage it is accepted. Enhancing of input data
> validation for appropriate handler will do the trick. Relevant internal
> Nailgun logic (serialization, networking etc.) will be unchanged in order to
> support compatibility with already existing clusters after master node
> upgrade.
>
> FYI, there is a relevant bug [1] on Lauchpad.
>
> [1] https://bugs.launchpad.net/fuel/7.0.x/+bug/1478924
>
> --
> Regards!)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Dmitry Tantsur]

On 11/16/2015 12:28 PM, Davanum Srinivas wrote:

Dmitry,

i was trying to bring sanity to the tox.ini(s). +1 to documenting this
step somewhere prominent.


Please don't get me wrong, I really appreciate it. I'm not sure why 
"usedevelop" is not the default, though. Maybe we at least make sure to 
communicate this to people first? Because the error message is really 
vague to anyone who is not aware of these version tags.




-- Dims

On Mon, Nov 16, 2015 at 5:37 AM, Dmitry Tantsur  wrote:

On 11/16/2015 11:35 AM, Julien Danjou wrote:


On Mon, Nov 16 2015, Dmitry Tantsur wrote:


Before you ask: using 'sudo pip install -U setuptools pbr' is out of
question
in binary distributions :) so please make sure to remove this line only
when
everyone is updated to whatever version is required for understanding
these
;python_version=='2.7 bits.



But:
pip install --user setuptools pbr
might not be out of the question.



Yeah, this (with added -U) fixes the problem. But then we have to add it to
*all* contribution documentation. I'm pretty sure a lot of people won't
realize they need it.


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







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

Re: [openstack-dev] [networking-ovs-dpdk] ovs-appctl doesn't function correctly

[Hui Xiang]

That is helpful, thanks Sean !

On Mon, Nov 16, 2015 at 7:12 PM, Mooney, Sean K 
wrote:

> To use the ovs-appctl application you have to specify the socket path to
> the ovs-vswitchd process.
>
> ovs-appctl -t /var/run/openvswitch/ list-commands
>
> e.g.
>
> ovs-appctl -t /var/run/openvswitch/ovs-vswitchd.10110.ctl list-commands
>
>
>
>
>
>
>
> *From:* Hui Xiang [mailto:hui.xi...@canonical.com]
> *Sent:* Monday, November 16, 2015 10:01 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [networking-ovs-dpdk] ovs-appctl doesn't
> function correctly
>
>
>
> Hi all,
>
>
>
>   I have managed to setup ovs-dpdk on Ubuntu, commands
> 'ovs-vsctl/ovs-ofctl' all work well excep 'ovs-appctl', could anyone help
> me to figure it out? Thanks in advance.
>
>
>
>
>
> xianghui@xianghui:~$ sudo ovs-ofctl show br-int
>
> OFPT_FEATURES_REPLY (xid=0x2): dpid:264fa4e1f24f
>
> n_tables:254, n_buffers:256
>
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>
>  1(int-br-eth1): addr:2e:23:93:7f:54:14
>
>  config: 0
>
>  state:  0
>
>  speed: 0 Mbps now, 0 Mbps max
>
>  2(tap7a2317aa-90): addr:0c:52:ff:7f:00:00
>
>  config: PORT_DOWN
>
>  state:  LINK_DOWN
>
>  speed: 0 Mbps now, 0 Mbps max
>
>  12(vhu5392206b-dc): addr:00:00:00:00:00:00
>
>  config: PORT_DOWN
>
>  state:  LINK_DOWN
>
>  speed: 0 Mbps now, 0 Mbps max
>
>  LOCAL(br-int): addr:26:4f:a4:e1:f2:4f
>
>  config: PORT_DOWN
>
>  state:  LINK_DOWN
>
>  current:10MB-FD COPPER
>
>  speed: 10 Mbps now, 0 Mbps max
>
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>
>
>
> xianghui@xianghui:~$ sudo ovs-appctl vlog/set dbg
>
> 2015-11-16T09:50:28Z|1|daemon_unix|WARN|/var/run/openvswitch/ovs-vswitchd.pid:
> open: No such file or directory
>
> ovs-appctl: cannot read pidfile "/var/run/openvswitch/ovs-vswitchd.pid"
> (No such file or directory)
>
>
>
> Also tried as below, failed as well.
>
>
>
> xianghui@xianghui:~$ sudo ovs-appctl -t /opt/stack/logs/ovs-vswitchd.pid
> vlog/set dbg
>
> 2015-11-16T09:58:15Z|1|unixctl|WARN|failed to connect to
> /opt/stack/logs/ovs-vswitchd.pid
>
> ovs-appctl: cannot connect to "/opt/stack/logs/ovs-vswitchd.pid"
> (Connection refused)
>
> xianghui@xianghui:~$ sudo ovs-appctl -t /var/run/openvswitch/db.sock
> vlog/set dbg
>
> unknown methodovs-appctl: /var/run/openvswitch/db.sock: server returned an
> error
>
>
>
>
>
>
>
> --
>
> Best Regards.
>
> Hui.
>
>
>
> OpenStack Engineer
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards.
Hui.

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

Re: [openstack-dev] [networking-ovs-dpdk]

[Prathyusha Guduri]

Hi Sean,

Thanks for your response.

in your case though you are using 1GB hugepages so I don’t think this is
related to memory fragmentation
or a lack of free hugepages.



to use preallocated 1GB page with ovs you should instead set the following
in your local.conf



OVS_HUGEPAGE_MOUNT_PAGESIZE=1G
OVS_ALLOCATE_HUGEPAGES=False


Added the above two parameters to the local.conf. The same problem again.
Basically it throws this error -
2015-11-16 11:31:44.741 | starting vswitchd
2015-11-16 11:31:44.863 | sudo RTE_SDK=/opt/stack/DPDK-v2.0.0
RTE_TARGET=build /opt/stack/DPDK-v2.0.0/tools/dpdk_nic_bind.py -b igb_uio
:07:00.0
2015-11-16 11:31:45.169 | sudo ovs-vsctl --no-wait --may-exist add-port
br-eth1 dpdk0 -- set Interface dpdk0 type=dpdk
2015-11-16 11:31:46.314 | Waiting for ovs-vswitchd to start...
2015-11-16 11:31:47.442 | libvirt-bin stop/waiting
2015-11-16 11:31:49.473 | libvirt-bin start/running, process 2255
2015-11-16 11:31:49.477 | [ERROR] /etc/init.d/ovs-dpdk:563 ovs-vswitchd
application failed to start


manually mounting /mnt/huge and then commenting that part from the
/etc/init.d/ovs-dpdk script also throws the same error.

Using 1G hugepagesize should not give any memory related problem. I dont
understand why it is not mounting then.
Here is the /opt/stack/networking-ovs-dpdk/devstack/ovs-dpdk/ovs-dpdk.conf

RTE_SDK=${RTE_SDK:-/opt/stack/DPDK}
RTE_TARGET=${RTE_TARGET:-x86_64-ivshmem-linuxapp-gcc}

OVS_INSTALL_DIR=/usr
OVS_DB_CONF_DIR=/etc/openvswitch
OVS_DB_SOCKET_DIR=/var/run/openvswitch
OVS_DB_CONF=$OVS_DB_CONF_DIR/conf.db
OVS_DB_SOCKET=OVS_DB_SOCKET_DIR/db.sock

OVS_SOCKET_MEM=2048,2048
OVS_MEM_CHANNELS=4
OVS_CORE_MASK=${OVS_CORE_MASK:-2}
OVS_PMD_CORE_MASK=${OVS_PMD_CORE_MASK:-4}
OVS_LOG_DIR=/tmp
OVS_LOCK_DIR=''
OVS_SRC_DIR=/opt/stack/ovs
OVS_DIR=${OVS_DIR:-${OVS_SRC_DIR}}
OVS_UTILS=${OVS_DIR}/utilities/
OVS_DB_UTILS=${OVS_DIR}/ovsdb/
OVS_DPDK_DIR=$RTE_SDK
OVS_NUM_HUGEPAGES=${OVS_NUM_HUGEPAGES:-5}
OVS_HUGEPAGE_MOUNT=${OVS_HUGEPAGE_MOUNT:-/mnt/huge}
OVS_HUGEPAGE_MOUNT_PAGESIZE=''
OVS_BOND_MODE=$OVS_BOND_MODE
OVS_BOND_PORTS=$OVS_BOND_PORTS
OVS_BRIDGE_MAPPINGS=eth1
OVS_PCI_MAPPINGS=:07:00.0#eth1
OVS_DPDK_PORT_MAPPINGS=''
OVS_TUNNEL_CIDR_MAPPING=''
OVS_ALLOCATE_HUGEPAGES=True
OVS_INTERFACE_DRIVER='igb_uio'

Verified the OVS_DB_SOCKET_DIR and all others. conf.db and db.sock exist.
So why ovs-vswitchd is failing to start??? Am I missing something???



Thanks,
Prathyusha


On Mon, Nov 16, 2015 at 4:39 PM, Mooney, Sean K 
wrote:

>
>
> Hi
>
>
>
> Yes sorry for the delay in responding to you and samta.
>
>
>
> In your case assuming you are using 2mb hugepages it is easy to hit dpdks
> default max memory segments
>
>
>
> This can be changed by setting OVS_DPDK_MEM_SEGMENTS= number that you will never hit>
>
> In the local.conf and recompiling. To do this simply remove the build
> complete file in /opt/stack/ovs
>
> rm –f /opt/stack/BUILD_COMPLETE
>
>
>
> in your case though you are using 1GB hugepages so I don’t think this is
> related to memory fragmentation
> or a lack of free hugepages.
>
>
>
> to use preallocated 1GB page with ovs you should instead set the following
> in your local.conf
>
>
>
> OVS_HUGEPAGE_MOUNT_PAGESIZE=1G
>
> OVS_ALLOCATE_HUGEPAGES=False
>
>
>
> Regards
>
> sean
>
>
>
> *From:* Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
> *Sent:* Monday, November 16, 2015 6:20 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [networking-ovs-dpdk]
>
>
>
> Hi all,
>
> I have a similar problem as Samta. Am also stuck at the same place. The
> following command
>
> $sudo ovs-vsctl br-set-external-id br-ex bridge-id br-ex
>
> hangs forever. As Sean said, it might be because of ovs-vswitchd proces.
>
> > The vswitchd process may exit if it  failed to allocate memory (due to
> memory fragmentation or lack of free hugepages)
> > if the ovs-vswitchd.log is not available can you check the the hugepage
> mount point was created in
> > /mnt/huge And that Iis mounted
> > Run
> > ls -al /mnt/huge
> > and
> > mount
> >
>
> $mount
>
> /dev/sda6 on / type ext4 (rw,errors=remount-ro)
> proc on /proc type proc (rw,noexec,nosuid,nodev)
> sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
> none on /sys/fs/cgroup type tmpfs (rw)
> none on /sys/fs/fuse/connections type fusectl (rw)
> none on /sys/kernel/debug type debugfs (rw)
> none on /sys/kernel/security type securityfs (rw)
> udev on /dev type devtmpfs (rw,mode=0755)
> devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
> tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
> none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
> none on /run/shm type tmpfs (rw,nosuid,nodev)
> none on /run/user type tmpfs
> (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
> none on /sys/fs/pstore type pstore (rw)
> cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
> cgroup on /sys/fs/cgroup/cpu type cgroup 

Re: [openstack-dev] [heat] Questions about BP for enable/disable heat-engine

[Manickam, Kanagaraj]

Ethan Lynn,

This blue-print has two parts , one to perform the graceful-shutdown to make 
sure all IN_PROGRESS resources/stacks in the given engine to reach its final 
state..
Other one, expose this feature as disable engine to support the maintenance.
I was planning to re-write the spec to provide the graceful shutdown only and 
remove the api part ( and requested to abandon this spec)
Please review the spec and please let me know, I will restore it and will work 
together to implement it. Thanks.

Regards
Kanagaraj M

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Tuesday, November 10, 2015 5:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] Questions about BP for enable/disable 
heat-engine

Ethan,

I can see, that it was assigned on Kanagaraj, but he is now in vacation (afaik).
Also corresponding patch with specification was abandoned by his request, so I 
suggest wait answer here or may be ping him in IRC directly on the next week.

On 8 November 2015 at 17:26, Ethan Lynn  wrote:
> Hi,
>   I notice that there is a BP for enable/disable heat-engine, 
> https://blueprints.launchpad.net/heat/+spec/heat-manage-service-disable-enable
>   This feature is important when maintain heat-engine in HA 
> production, if one controller node needs to be replaced, we can 
> disable heat-engine in this node and then replace this node.
>   I would like to know the reasons why this BP stops working, is there 
> any technical issues to implement it? I don’t quite understand the 
> issues raised by inc0, any one can explain it?
>   I would like to see this feature come into heat, and I would like to 
> pay some effort on it.
>
> Best Regards,
> Ethan Lynn
>
>
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Regards,
Sergey.

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

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Sean Dague]

On 11/16/2015 01:03 AM, Jamie Lennox wrote:
> 
> 
> On 14 November 2015 at 19:09, Xav Paice  > wrote:
> 
> Hi,
> 
> I'm sure I'm not the only one that likes to use SSL everywhere
> possible, and doesn't like to pay for 'real' ssl certs for dev
> environments.  Figuring out how to get requests to allow connection
> to the self signed cert would have paid for a real cert many times over.
> 
> When I use an SSL cert with a CA not in the Mozilla bundle, and use
> keystonemiddleware to access Keystone endpoints, the ssl
> verification rightly fails.  It turns out requests doesn't use the
> system ca cert bundle, but has it's own.  It's also got a nice easy
> config option to set which ca cert bundle you want to use -
> 
> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
> 
> How do people feel about having that as a config option set
> somewhere, so we can specify a ca cert in, say, heat.conf, so that
> we can continue with the self signed certs of cheapness without
> needing to hack up the cacert.pem that comes with requests, or find
> a way to pass in environment variables?
> 
> Am I barking up the wrong tree here?  How would I go about writing a
> blueprint for this, and for which project?  I guess it's something
> that would need to be added to all the projects in the
> keystone_authtoken section?  Or is there a central place where
> common configs like this can live?
> 
>  
> So this is an area that requests upstream and distros have fought about
> for a while now, that and bundling. Typically the distros patch the
> requests package so that it correctly reflects the system environment,
> so if you yum install or apt-get install python-requests then it will
> work with the system CAs. If you are running from a virtualenv/pip
> installed python-requests it wont.
> 
> Ideally we are moving everything to using keystoneclient/keystoneauth
> sessions. These have support for cafile from the built in options
> loader, so in future there should be config options that will allow you
> to always specify a CA file to use if you're willing to chase down all
> the config values.
> 
> For now the easiest way i know to do this is using the
> REQUESTS_CA_BUNDLE environment variable. If found (and nothing else
> specified) this will be used as the default CA bundle file instead of
> the inbuilt one. It also respects the CURL_CA_BUNDLE variable.
> 
> I'm not sure if people would mind if we did some OS discovery and just
> overrode the requests defaults to always find the system CA. It doesn't
> bother me. But we could really easily add our own OS_CA_BUNDLE env
> variable to do the same things as requests and override a system location.

That sounds pretty reasonable to me. I definitely support the idea that
we should be using system CA by default, even if that means overriding
requests in our tools.

I definitely don't want to be adding a ton of server params to set this.
Servers talking to other servers through clients should use the system
CA for sure.

That will have a knock on effect about using it for python clients
directly, but that seems like the right option.

What's the expected way that a user would add a cert for a self signed
cloud to their laptop? It seems like if the answer involves config
outside of certutil (on a linux environment) then it's probably on the
wrong track.

-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] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

Thanks Sean D. for explanation!

I’ve taken a look into old Russell patches, and it seems that the 
project-config was already modified by him:

Add check-grenade-dsvm-partial-ncpu-neutron: (project-config)

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

Add check-grenade-dsvm-partial-ncpu-neutron-dvr (project-config)

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



Another 2 patches are introducing the Neutron partial job to devstack-gate

Add partial-ncpu-neutron grenade mode (devstack-gate)

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

Add partial-ncpu-neutron-dvr grenade mode (devstack-gate)

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

I haven’t tested that yet, but it looks like it does the job.

Also, there is still one patch in Devstack needed for L3 agent separate 
start/stop:

Separate start/stop control of the Neutron L3 agent. (Devstack)

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

From what Sean D. talked about, following patches should not be resurrected:

Support partial upgrades of Neutron in DVR mode: (Grenade)

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

 Support partial Neutron upgrades. (Grenade)

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

In order to test the RPC right, we should be able to decouple the neutron 
server from its agents – L2, L3, DHCP and metadata agents.
Current scenario will let us to test :

1.   Legacy:

a.   Controller & network node: neutron server, L2, L3, Metadata and DHCP 
agents

b.  Compute node: L2 agent.

2.   DVR:

a.   Controller & network node: neutron server, L2, L3, Metadata and DHCP 
agents

b.  Compute node: L2, L3, Metadata(?) agents

We can start with current scenario, but this does not guarantee us to test of 
DHCP RPC.

The ideal upgrade scenario should look like this:

1.   Legacy:

a.   Controller node: neutron server

b.  Network node: L2, L3, Metadata and DHCP server

c.   Compute node: L2 agent

2.   DVR:

a.   Controller node: neutron server

b.  Network node: L2, L3, Metadata and DHCP server

c.   Compute node: L2, L3 and Metadata agent

The job still to be done in order to fully test partial upgrades:

-  Decouple the DHCP and metadata agent from devstack neutron restart

-  Look through the grenade Neutron code in order to identify if we are 
creating the all the resources critical to test the upgrades

-  Debug, debug, debug…

Regards,
Artur
From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, November 13, 2015 9:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade



On 13 November 2015 at 11:46, Sean Dague 
> wrote:
On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
>> Ok, I top responded with the details of the job, honestly I think it's
>> just a project-config change to get up and running, and then hacking at
>> the bugs that fall out.
>
> Thanks - that was super helpful.
>
> I'm thinking of working on the following on Monday:
>
> 1) capture that somewhere in the upgrade docs we're putting together in 
> neutron's devref
>
> 2) Adding the stanza to project-config to get grenade running for
> Neutron
>
> 3) Take a look at the patches that Armando linked a couple emails back
> in this thread.

I don't think that any of the patches listed there are needed. This was
part of the reason I -2ed that direction in the last cycle. It required
a separate special code path for partial upgrade setup which was very
synthetic (and honestly kind of confusing to debug).

I don't disagree. I didn't meant to imply 'resume the patches', I was only 
providing the backdrop.


The new approach means if you did upgrade for the all-in-one case, and
you did multinode setup with worker processes on the subnode, you just
make a config where you do them both at the same time, and you have
partial upgrade.

-Sean

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

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

Re: [openstack-dev] [oslo][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

[Robert Collins]

On 17 November 2015 at 16:25, Jay Pipes  wrote:
> On 11/15/2015 08:10 PM, Robert Collins wrote:
...
>
> Thanks, Robert, but unfortunately that didn't work. I still get the same
> problem:
>
> Downloading/unpacking .[fixtures]
>   Could not find any downloads that satisfy the requirement .[fixtures]
>
> Is ".[fixtures]" really the correct name of the requirement?

It means 'the fixtures extra of the project found in the current
working directory.

You can check setup.cfg if the project is a pbr using one, to see the
defined extras.

> Here is proof that I'm running the right versions of pip and virtualenv
> (installed from scratch with sudo -H python get-pip.py and sudo -H pip
> install virtualenv after clearing the system packages for both)
>
> http://paste.openstack.org/show/479076/
>
> Any other ideas? This is getting quite frustrating :(

Can you attach/pastebin your log files?

/home/jaypipes/repos/oslo.versionedobjects/.tox/py34/log/py34-1.log and

/home/jaypipes/repos/oslo.versionedobjects/.tox/py34/log/py34-0.log ?

also

. .tox/py34/bin/activate
pip list

Thanks!
-Rob





-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [puppet] weekly meeting #59

[Emilien Macchi]

The second one. Sorry for confusion, I sent it from my phone.

See you tomorrow!
---
Emilien Macchi
On Nov 16, 2015 1:24 PM, "Iury Gregory"  wrote:

> Hi Emilien, the link for the agenda is
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-2015111
>  or
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117
>  ?
> Thanks o/
>
>
> 2015-11-16 14:04 GMT-03:00 Emilien Macchi :
>
>> Hello!
>>
>> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
>> in #openstack-meeting-4:
>>
>> https
>> 
>> ://
>> 
>> etherpad.openstack.org
>> 
>> /p/puppet-openstack-weekly-meeting-2015111
>> 
>> 7
>>
>> I'm back online tomorrow morning.
>>
>> Thanks,
>> ---
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> ~
>
>
> *Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science
> at UFCG*
> *E-mail:  iurygreg...@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] [oslo][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

[Jay Pipes]

Just a quick note to say thank you to Robert, who helped me through my 
troubles on #openstack-dev. Robert, you rock. Thanks much!


FWIW, the problem was indeed a bad version of virtualenv (the old Ubuntu 
one), and this is what I needed to do to resolve the issue:


sudo apt-get remove -y python3-virtualenv python3-pip python3-tox
wget https://bootstrap.pypa.io/get-pip.py
sudo -H python3 get-pip.py
sudo -H python3 -m pip install virtualenv
sudo -H python3 -m pip install tox

Best,
-jay

On 11/16/2015 08:02 PM, Robert Collins wrote:

On 17 November 2015 at 16:25, Jay Pipes  wrote:

On 11/15/2015 08:10 PM, Robert Collins wrote:

...


Thanks, Robert, but unfortunately that didn't work. I still get the same
problem:

Downloading/unpacking .[fixtures]
   Could not find any downloads that satisfy the requirement .[fixtures]

Is ".[fixtures]" really the correct name of the requirement?


It means 'the fixtures extra of the project found in the current
working directory.

You can check setup.cfg if the project is a pbr using one, to see the
defined extras.


Here is proof that I'm running the right versions of pip and virtualenv
(installed from scratch with sudo -H python get-pip.py and sudo -H pip
install virtualenv after clearing the system packages for both)

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

Any other ideas? This is getting quite frustrating :(


Can you attach/pastebin your log files?

/home/jaypipes/repos/oslo.versionedobjects/.tox/py34/log/py34-1.log and

/home/jaypipes/repos/oslo.versionedobjects/.tox/py34/log/py34-0.log ?

also

. .tox/py34/bin/activate
pip list

Thanks!
-Rob







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

[openstack-dev] [Infra] Meeting Tuesday November 17th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday November 17th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-11-10-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-11-10-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-11-10-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Hi Kyle,

Thanks for adding patch [3] to clarify the current API status.

Cathy

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Monday, November 16, 2015 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant 
> wrote:
On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
>> This is a challenge. Personally, I haven't been able to get it all working
>> yet. But we're in a dilemma because we want to get good reviews of the code
>> before merging. Since the full functionality is quite a lot of code we
>> wanted to chop it into more easily reviewable chunks. Unfortunately that
>> makes it more difficult to pull it all in at once to test the whole thing
>> prior to completing the review and merge.
>
> I would be concerned about that. I am sympathetic to the chicken and egg
> problem of a new repo and new code, but I briefly looked at both of
> those reviews and they both are quite large. 1K LOC is usually the upper
> limit for a sane patch set. It may be worth trying to break into
> smaller, more manageable pieces - even if the initial commits just
> create some empty classes and stubbed methods, and then later start
> introducing the actual method bodies in small pieces with good unit
> tests for each one. Small pieces. Tiny steps.

Another thing I've been thinking about is the difference between having
a repo like networking-sfc where a sub-group is able to try out new
things while also managing expectations with consumers of Neutron.  How
does someone know the difference between something a bit more
experimental vs. when an API is established and can be considered stable
and maintained with backwards copmatibility like any other OpenStack
REST API?
In the case of SFC, consumers of the API should know it's tagged as 
"release:independent" [1], and also it should be clear there is no release made 
and the code isn't stable in the docs, but that isn't currently the case 
looking here [2]. Thus, I've submitted [3] to make this a bit more clear, 
comments welcome.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] http://docs.openstack.org/developer/networking-sfc/
[3] https://review.openstack.org/246001

I think networking-sfc should be able to keep merging code, including
the proposed API, but I think it should be clearly marked as
experimental and subject to change.  That's based on my experience so
far studying this proposal, SFC more generally, and watching other
efforts happening within Neutron that affect this.

How can we manage these expectations more clearly?
Well, since it hasn't released yet, I agree, lets experiment and let other 
backends try this out, and at the same time not lock things down. We just need 
to be clear about the intent here.
Thanks,
Kyle

--
Russell Bryant

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

__
OpenStack Development Mailing 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] [Oslo] taskflow 2.0 and its changes

[Joshua Harlow]

Since I am hoping to get taskflow 2.0 out in mitaka I wanted to share 
with folks some of the debt collected items that have been/are scheduled 
for removal.


Most of these have been removed in 6+ months (some have been around from 
2014) and with the 2.0 release it seems like the best time to clean out 
the trash and finally delete them.


So here is the analysis of this (it includes some other reviews 
scheduled for 2.0) and I would just like to ensure people are aware of 
the removals/moved attributes... and if some of the described removals 
are still needed we can (as needed) work through a plan so that taskflow 
2.0 can get out and your project won't be affected...


(Personally I don't think anyone is depending on these 'features' but I 
just wanted to send this out just in-case).


Changes listed @ https://etherpad.openstack.org/p/mitaka-taskflow-2.0

-Josh

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

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Rochelle Grober]

I would like to make a plea that while Juno is locked down so as no changes can 
be made against it, the branch remains on the git.openstack.org site.  Please?  
One area that could be better investigated with the branch in place is upgrade. 
 Kilo will continue to get patches, as will Liberty, so an occasional grenade 
run (once a week?  more often?  Less often) could help operators understand 
what is in store for them when they finally can upgrade from Juno.  Yes, it 
will require occasional resources for the run, but I think this is one of the 
cheapest forms of insurance in support of the installed base of users, before a 
Stable Release team is put together.

My $.02

--Rocky

> -Original Message-
> From: Gary Kotton [mailto:gkot...@vmware.com]
> Sent: Friday, November 13, 2015 6:04 AM
> To: Flavio Percoco; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re:
> [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> 
> 
> On 11/13/15, 3:23 PM, "Flavio Percoco"  wrote:
> 
> >On 10/11/15 16:11 +0100, Alan Pevec wrote:
> >>Hi,
> >>
> >>while we continue discussion about the future of stable branches in
> >>general and stable/juno in particular, I'd like to execute the
> current
> >>plan which was[1]
> >>
> >>2014.2.4 (eol) early November, 2015. release manager: apevec
> >>
> >>Iff there's enough folks interested (I'm not) in keep Juno alive
> 
> +1 I do not see any reason why we should still invest time and effort
> here. Lets focus on stable/kilo
> 
> >>longer, they could resurrect it but until concrete plan is done let's
> >>be honest and stick to the agreed plan.
> >>
> >>This is a call to stable-maint teams for Nova, Keystone, Glance,
> >>Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to
> review
> >>open stable/juno changes[2] and approve/abandon them as appropriate.
> >>Proposed timeline is:
> >>* Thursday Nov 12 stable/juno freeze[3]
> >>* Thursday Nov 19 release 2014.2.1
> >>
> >
> >General ack from a stable-maint point of view! +1 on the above
> >
> >Flavio
> >
> >>Cheers,
> >>Alan
> >>
> >>[1]
> >>https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2F
> juno
> >>_releases_.2812_months.29
> >>
> >>[2]
> >>https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+A
> ND+%
> >>28project:openstack/nova+OR+project:openstack/keystone+OR+project:ope
> nsta
> >>ck/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR
> +pro
> >>ject:openstack/horizon+OR+project:openstack/heat+OR+project:openstack
> /cei
> >>lometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z
> >>
> >>[3] documented  in
> >>https://wiki.openstack.org/wiki/StableBranch#Stable_release_managers
> >>TODO add in new location
> >>http://docs.openstack.org/project-team-guide/stable-branches.html
> >>
> >>_
> 
> >>_
> >>OpenStack Development Mailing List (not for usage questions)
> >>Unsubscribe:
> >>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >--
> >@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

__
OpenStack Development Mailing 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] [Barbican] Enabling GET of secrets to work irrespective of Tenant name in login

[Dave McCowan (dmccowan)]

Hi Vijay--
The recommended way for supporting that use case is to use Barbican's
ACLs.  It allows user's from another project/tenant to access specific
secrets 

If the "demo admin" owns a secret and wants to give read access to
"admin admin", the "demo admin" should create a ACL for the secret.
If an LBaaS user needs access to a tenant secret, the tenant admin can
create an ACL granting read access to the LBaaS user.

http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

--Dave



On 11/10/15, 3:41 AM, "Vijay Venkatachalam"
 wrote:

>Hi,
>
>Can we enable GET of secrets to work irrespective of Tenant name in the
>login?
>
>Consider there is an "admin" with "admin" role in "demo" tenant. I tried
>to query the "demo" tenant's secret using  a login token which was
>generated from "admin" user  & "admin" tenant. And I am getting a
>Forbidden error. Could we make this scenario work?
>
>UseCase:
> 
>LBaaS extension has admin credentials and generates a token and uses it
>to contact services like nova, barbican etc. It is currently using  the
>same token to get the tenant's secret/certificates with the href and it
>is not working.
>
>Thanks,
>Vijay V.
>
>__
>OpenStack Development Mailing 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Matt Riedemann]

On 11/16/2015 8:49 PM, Rochelle Grober wrote:

I would like to make a plea that while Juno is locked down so as no changes can 
be made against it, the branch remains on the git.openstack.org site.  Please?  
One area that could be better investigated with the branch in place is upgrade. 
 Kilo will continue to get patches, as will Liberty, so an occasional grenade 
run (once a week?  more often?  Less often) could help operators understand 
what is in store for them when they finally can upgrade from Juno.  Yes, it 
will require occasional resources for the run, but I think this is one of the 
cheapest forms of insurance in support of the installed base of users, before a 
Stable Release team is put together.

My $.02

--Rocky


-Original Message-
From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Friday, November 13, 2015 6:04 AM
To: Flavio Percoco; OpenStack Development Mailing List (not for usage
questions)
Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re:
[Openstack-operators] [stable][all] Keeping Juno "alive" for longer.



On 11/13/15, 3:23 PM, "Flavio Percoco"  wrote:


On 10/11/15 16:11 +0100, Alan Pevec wrote:

Hi,

while we continue discussion about the future of stable branches in
general and stable/juno in particular, I'd like to execute the

current

plan which was[1]

2014.2.4 (eol) early November, 2015. release manager: apevec

Iff there's enough folks interested (I'm not) in keep Juno alive


+1 I do not see any reason why we should still invest time and effort
here. Lets focus on stable/kilo


longer, they could resurrect it but until concrete plan is done let's
be honest and stick to the agreed plan.

This is a call to stable-maint teams for Nova, Keystone, Glance,
Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to

review

open stable/juno changes[2] and approve/abandon them as appropriate.
Proposed timeline is:
* Thursday Nov 12 stable/juno freeze[3]
* Thursday Nov 19 release 2014.2.1



General ack from a stable-maint point of view! +1 on the above

Flavio


Cheers,
Alan

[1]
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2F

juno

_releases_.2812_months.29

[2]
https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+A

ND+%

28project:openstack/nova+OR+project:openstack/keystone+OR+project:ope

nsta

ck/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR

+pro

ject:openstack/horizon+OR+project:openstack/heat+OR+project:openstack

/cei

lometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z

[3] documented  in
https://wiki.openstack.org/wiki/StableBranch#Stable_release_managers
TODO add in new location
http://docs.openstack.org/project-team-guide/stable-branches.html

_



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


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


__
OpenStack Development Mailing 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'm assuming you mean grenade runs on stable/kilo. A grenade job on 
stable/kilo is installing stable/juno and then upgrading to stable/kilo 
(the change being tested is on stable/kilo). The grenade jobs for 
stable/juno were stopped when icehouse-eol happened.


Arguably we could still be testing grenade on stable/kilo by just 
installing Juno 2014.2.4 (last Juno point release before EOL) and then 
upgrading to stable/kilo.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [oslo][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

[Jay Pipes]

On 11/15/2015 08:10 PM, Robert Collins wrote:

On 16 November 2015 at 15:29, Jay Pipes  wrote:

Hi all,

Really getting frustrated with a particular problem. I'm trying to build
oslo.versionedobjects locally (this problem occurs on both my lappie and my
desktop, running Ubuntu 15.04 and 15.10 respectively.

When running tox -epy34, I'm getting an error about not being able to
install a dependency called ".[fixtures]":

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

Matt Riedemann thought that it had something to do with me using an old
version of setuptools, but I've upgraded both my site packages setuptools
and the one in the tox virtualenv to the latest 18.5 setuptools (see proof
in paste above) and still getting the same problem.

Any help would be appreciated!


It probably means you're installing with an old pip. The most common
way that happens is using distribution versions of virtualenv, because
of how pip gets installed in tox virtualenvs:

virtualenv makes the environment
virtualenv takes a cached wheel from the environment *that virtualenv
ran from* and unpacks it into the tox environment.

tl;dr: sudo apt-get remove python-pip python-virtualenv; install pip
using get-pip.py; sudo -H pip install virtualenv

More info here:
https://rbtcollins.wordpress.com/2015/07/12/bootstrapping-developer-environments-for-openstack/


Thanks, Robert, but unfortunately that didn't work. I still get the same 
problem:


Downloading/unpacking .[fixtures]
  Could not find any downloads that satisfy the requirement .[fixtures]

Is ".[fixtures]" really the correct name of the requirement?

Here is proof that I'm running the right versions of pip and virtualenv 
(installed from scratch with sudo -H python get-pip.py and sudo -H pip 
install virtualenv after clearing the system packages for both)


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

Any other ideas? This is getting quite frustrating :(

Best,
-jay

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

Re: [openstack-dev] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

[Igor Kalnitsky]

Hey Julia,

Thank you for feedback. I took a look over the bug and here's my thoughts:

* [1] Looks like Invalid to me. I'm not sure, but it looks like you
VMs just wrongly configures. It's a pretty common mistake for VBox
scripts. Did you use them?
* [2] Partially Invalid. I left my comments, so I agree only with one point.
* [3], [4] and [5] looks like pretty easy to fix, and honestly
shouldn't be considered as feature blockers.

Please, feel free to comment them back ;)

Thanks,
Igor

[1] https://bugs.launchpad.net/fuel/+bug/1515903
[2] https://bugs.launchpad.net/fuel/+bug/1515898
[3] https://bugs.launchpad.net/fuel/+bug/1515895
[4] https://bugs.launchpad.net/fuel/+bug/1515891
[5] https://bugs.launchpad.net/fuel/+bug/1515893

On Fri, Nov 13, 2015 at 12:46 AM, Julia Aranovich
 wrote:
> Hi fuelers,
>
> Currently Fuel UI team is working on blueprint [1] to give Fuel UI user an
> ability to launch provisioning of environment nodes separately from
> deployment (without choosing particular nodes for now).
>
> In the process we were faced with the following issues. Some of them block
> the blueprint:
>
> deployment constantly failed on environment with pre-provisioned nodes [2]
> node pending_addition flag is reset to False for provisioned nodes [3]. This
> causes a lot of UX problems: provisioned node roles, disks, interfaces can
> not be reconfigured, node can not be deleted from environment, just can be
> marked as pending deletion (that requires environment deployment)
> completed provisioning task has Null message. So, there is no to show the
> user after provisioning finished [4]
> no notification comes on UI after provisioned finished [5]
> fake provisioning task is also should be fixed: environment nodes stay in
> 'provisioning' status after provisioning finished [6]. This breaks fake Fuel
> UI workflow and brings difficulties in Fuel UI development.
>
> Could you please consider/fix the tickets and help to unblock the blueprint
> targeted for the current release.
>
> Also, you can check how provisioning works in Fuel UI on #547 custom 8.0
> ISO.
>
> Thank you!
> Julia
>
> [1]
> https://blueprints.launchpad.net/fuel/+spec/support-separate-provisioning-and-deployment-in-ui
> [2] https://bugs.launchpad.net/fuel/+bug/1515903
> [3] https://bugs.launchpad.net/fuel/+bug/1515898
> [4] https://bugs.launchpad.net/fuel/+bug/1515895
> [5] https://bugs.launchpad.net/fuel/+bug/1515891
> [6] https://bugs.launchpad.net/fuel/+bug/1515893
>
>
> __
> OpenStack Development Mailing 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] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral

[WANG, Ming Hao (Tony T)]

Dear Murano developers and testers,

I want to put some files that Mistral workflow needs into Murano package, and 
hope Murano can transmit them to Mistral before it calls Mistral workflow.
The flow should be as following:

1.   User uploads one Murano package which includes both Murano 
artifacts and Mistral artifacts to Murano;

2.   Murano transmits the Mistral artifacts to Mistral, and 
Mistral does its work.

After study, I thought muranoagent may be helpful and plan to install a 
muranoagent on the Mistral server since it can put files into nova server, and 
can run scripts on the nova server.
After further study, I found muranoagent solution may be not feasible:

1.   muranoagent and murano-engine(dsl) uses rabbitMQ to 
communicate.

2.   When an Agent object is created in DSL, murano-engine 
creates a unique message queue to communicate with the muranoagent in nova 
instance:
The queue name consists of current murano environment id, and the nova instance 
murano object id.

3.   During murano creates the nova instance, it passes this 
unique queue name via nova user_data to muranoagent on guest.
In this way, muranoagents on different guests can communicate with 
murano-engine separately.
This doesn’t suit the muranoagent + Mistral server solution.
We only want to install one muranoagent in Mistral server, and it should only 
listen on one message queue.
We can’t create  new muranoagent for each murano environment.
To achieve this, one solution that I can think is to modify murano code to 
implement a new MistralAgent to listen on a pre-defined message queue.

Could you please share your ideas about this?
If you have other solution, please also help to share it.  ☺

Thanks in advance,
Tony

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

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting this week. The meeting is being held
Tuesday UTC1200.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

[openstack-dev] [QA][Tempest] Deprecate or drop about Tempest CLI

[Masayuki Igawa]

Hi tempest CLI users and developers,

Now, we are improving Tempest CLI as we discussed at the summit[1] and
 migrating legacy commands to tempest cli[2].

In this situation, my concern is 'CLI compatibility'.
If we'll drop old CLIs support(like my patch), it might break existing
workflows.

So I think there are two options.
 1. Deprecate old tempest CLIs in this Mitaka cycle and we'll drop them at
the beginning of the N cycle.
 2. Drop old tempest CLIs in this Mitaka cycle when new CLIs will be
implemented.
# Actually, I'd like to just drop old CLIs. :)

If you have question and/or opinion, please let me know.

[1] https://etherpad.openstack.org/p/tempest-cli-improvements
[2] https://review.openstack.org/#/c/240399/

Best Regards,
-- Masayuki Igawa
__
OpenStack Development Mailing 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] Handling of 202 response code

[Saravanan KR]

Thanks Matthias for educating me. As there is no universal solution to 
this issue, I will check if launch instance page strategy will work out 
for this case.


Regards,
Saravanan KR

On 11/04/2015 03:47 PM, Matthias Runge wrote:

On 04/11/15 09:25, Saravanan KR wrote:


There may be multiple solutions:
1) Waiting for the synchronous and then respond
2) Do not trigger page refresh and respond with Operation in progress
3) If there is a mechanism to know delete in progress, do not list the
interface

To decide on the solution, it is important to know how 202 responses
should be handled. Can anyone can help with understanding?

Asynchronous operations are handled in horizon as synchronous
operations. To illustrate that: launch an instance, you'll get
immediately a feedback ("launch instance issued").
But, you don't get a status feedback directly. Horizon pulls nova api
for status updates via ajax calls.

So: there is no solution yet for this. You could duplicate the same
update strategy as in launch instance (on instances page), create a
volume (on volumes table), etc.

In ideal case, one would use something like a message bus to get
notified on changes.

Matthias



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




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

Re: [openstack-dev] [neutron][heat][magnum] LBaaS of Neutron

[Egor Guz]

Eli,

you are correct Swarm support only one active/passive deployment model, but 
according to Docker documentation 
https://docs.docker.com/swarm/multi-manager-setup/
even replica can handle user request “You can use the docker command on any 
Docker Swarm primary manager or any replica."

it means "round-robin" should works.

—
Egor

From: "Qiao,Liyong" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Sunday, November 15, 2015 at 23:50
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][heat][magnum] LBaaS of Neutron

Hi Sergey

Thanks for your information, it's really help.
Actually I am from Magnum team and we are using heat to do orchestration on 
docker swarm bay.

Swarm master only support A-P mode (active-passive), I wonder if there any 
workaround to
implement my requirement :

VIP : 192.168.0.10

master-1 192.168.0.100 (A)
master-2 192.168.0.101 (P)

if I want to make VIP to alway connect with master-1(since it is A mode),
only switch to master-2 when master-1 down. what should I do?
---

Below link is the heat template of k8s(k8s supports A-A mode, so it can use 
ROUND_ROBIN).
https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L343

P.S Copy to Magnum team.

thanks
Eli.


On 2015年11月16日 15:15, Sergey Kraynev wrote:
On 16 November 2015 at 09:46, Qiao,Liyong 
> wrote:
hi, I have some questions about neutorn LBaas.

seen from the wiki, the load balancer only support:


Table 4.6. Load Balancing Algorithms

Name
LEAST_CONNECTIONS
ROUND_ROBIN

https://wiki.openstack.org/wiki/Neutron/LBaaS/API

think about if I have a A-P mode HA

VIP : 192.168.0.10

master-1 192.168.0.100 (A)
master-2 192.168.0.101 (P)

if I want to use VIP to alway connect with master-1(since it is A mode),
only switch to master-2 when master-1 down. what should I do?
any plan to support more algorithms for neutron lbaas?

BTW, the usage is from heat:

  etcd_pool:
type: OS::Neutron::Pool
properties:
  protocol: HTTP
  monitors: [{get_resource: etcd_monitor}]
  subnet: {get_resource: fixed_subnet}
  lb_method: ROUND_ROBIN
  vip:
protocol_port: 2379



thanks,
Eli.

--
BR, Eli(Li Yong)Qiao

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



Hi, Qiao,Liyong

I can not say about LBaaS team plans for supporting some additional algorithms 
:)
AFAIK, they do not plan add it to v1 API.
As I understand it may be discussed as part of v2 API [1]

In the Heat we have related BP [2], with several patches on review. So if it 
will be implemented on Neutron side, we may add such functionality too.

[1] http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
[2] https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport

--
Regards,
Sergey.



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


--
BR, Eli(Li Yong)Qiao
__
OpenStack Development Mailing 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][heat][magnum] LBaaS of Neutron

[Qiao,Liyong]

Egor,
thanks for pointing me out, I read it before,  I didn't notice that words.
hmm.. then that would be fine

On 2015年11月16日 16:28, Egor Guz wrote:

Eli,

you are correct Swarm support only one active/passive deployment model, but 
according to Docker documentation 
https://docs.docker.com/swarm/multi-manager-setup/
even replica can handle user request “You can use the docker command on any Docker 
Swarm primary manager or any replica."

it means "round-robin" should works.

—
Egor

From: "Qiao,Liyong" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Sunday, November 15, 2015 at 23:50
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][heat][magnum] LBaaS of Neutron

Hi Sergey

Thanks for your information, it's really help.
Actually I am from Magnum team and we are using heat to do orchestration on 
docker swarm bay.

Swarm master only support A-P mode (active-passive), I wonder if there any 
workaround to
implement my requirement :

VIP : 192.168.0.10

master-1 192.168.0.100 (A)
master-2 192.168.0.101 (P)

if I want to make VIP to alway connect with master-1(since it is A mode),
only switch to master-2 when master-1 down. what should I do?
---

Below link is the heat template of k8s(k8s supports A-A mode, so it can use 
ROUND_ROBIN).
https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L343

P.S Copy to Magnum team.

thanks
Eli.


On 2015年11月16日 15:15, Sergey Kraynev wrote:
On 16 November 2015 at 09:46, Qiao,Liyong 
> wrote:
hi, I have some questions about neutorn LBaas.

seen from the wiki, the load balancer only support:


Table 4.6. Load Balancing Algorithms

Name
LEAST_CONNECTIONS
ROUND_ROBIN

https://wiki.openstack.org/wiki/Neutron/LBaaS/API

think about if I have a A-P mode HA

VIP : 192.168.0.10

master-1 192.168.0.100 (A)
master-2 192.168.0.101 (P)

if I want to use VIP to alway connect with master-1(since it is A mode),
only switch to master-2 when master-1 down. what should I do?
any plan to support more algorithms for neutron lbaas?

BTW, the usage is from heat:

   etcd_pool:
 type: OS::Neutron::Pool
 properties:
   protocol: HTTP
   monitors: [{get_resource: etcd_monitor}]
   subnet: {get_resource: fixed_subnet}
   lb_method: ROUND_ROBIN
   vip:
 protocol_port: 2379



thanks,
Eli.

--
BR, Eli(Li Yong)Qiao

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



Hi, Qiao,Liyong

I can not say about LBaaS team plans for supporting some additional algorithms 
:)
AFAIK, they do not plan add it to v1 API.
As I understand it may be discussed as part of v2 API [1]

In the Heat we have related BP [2], with several patches on review. So if it 
will be implemented on Neutron side, we may add such functionality too.

[1] http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
[2] https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport

--
Regards,
Sergey.



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


--
BR, Eli(Li Yong)Qiao


--
BR, Eli(Li Yong)Qiao

<>__
OpenStack Development Mailing 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] [cross-project] Return request-id to caller - Step 1

[Kekane, Abhishek]

Hi Devs,

As per mentioned in cross-project specs [1] 'Proposed Change' section, I would 
like to proceed with adding 'request-id' attribute to base exception class.

request-id is most needed when api returns anything >= 400 error code. As of 
now python-cinderclient, python-keystoneclient and python-novaclient already 
has a mechanism to return request-id in exception.

So we will make similar changes in remaining clients to return request-id in 
exception and log the same in the response.

Please let me know your suggestions on the same.

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


Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

[Victor Stinner]

Le 16/11/2015 08:33, Kekane, Abhishek a écrit :

Hi,

As apiclient is now removed from oslo-incubator, to proceed with
request-id spec [1] I have two options in mind,

1.Use keystoneauth1 + cliff in all python-clients (add request-id
support in cliff library)

2.apiclient code is available in all python-*clients, modify this code
in individual clients and add support to return request-id.


(1) is the obvious choice for me. Modifying each old copy of apiclient 
would take a lot of time and we don't want to maintain this code anymore.


Victor

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

Re: [openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

[Thierry Carrez]

Everett Toews wrote:
> The following API guidelines are ready for cross project review. They will be 
> merged on Nov. 20 if there's no further feedback.
> [...]

I see you added this topic for the next cross-project meeting. Would you
mind chairing that meeting ? I'm traveling with limited availability and
Mike is on honeymoon.

If you agree, please see the meeting chair guide for details:

https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Meeting_chair_guide

NB: we are still discussing phasing out this meeting, but in the mean
time it sounds fair to hold the meeting if there is an agenda posted.

-- 
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] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Julien Danjou]

On Mon, Nov 16 2015, Dmitry Tantsur wrote:

> Before you ask: using 'sudo pip install -U setuptools pbr' is out of question
> in binary distributions :) so please make sure to remove this line only when
> everyone is updated to whatever version is required for understanding these
> ;python_version=='2.7 bits.

But:
  pip install --user setuptools pbr
might not be out of the question.

-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


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

Re: [openstack-dev] [designate] Records for floating addresses are not removed when an instance is removed

[Jaime Fernández]

Thanks Matt. The link was very useful. However, I couldn't make it work.

The event 'port.delete.end' has the following payload:

> {u'port_id': u'86580146-1772-4e32-8d7b-92bbb9131ae5'}
>
It only provides the port_id. But without the tenant_id, I cannot get the
context associated to the tenant. I've tried with all_tenants:

> context = DesignateContext.get_admin_context(all_tenants=True,
> edit_managed_records=True)
>
but it does not find any record.

Is there any option in get_admin_context that permits me to delete records
without knowing the tenant_id (although the records were created assigned
to that tenant_id)?

On Fri, Nov 13, 2015 at 7:51 PM, Matt Fischer  wrote:

> You can do it like we did for juno Designate as covered in our Vancouver
> talk start about 21 minutes:
>
> https://www.youtube.com/watch?v=N8y51zqtAPA
>
> We've not ported the code to Kilo or Liberty yet but the approach may
> still work.
>
>
> On Fri, Nov 13, 2015 at 9:49 AM, Jaime Fernández 
> wrote:
>
>> When removing an instance (with one floating address assigned) in
>> Horizon, designate-sink only receives an event for instance removal. As a
>> result, only the instance is removed but the floating addresses records are
>> not removed.
>> I'm not sure if it's a bug in openstack (I guess that it should also
>> notify about the unassignment of floating addresses) or it should be
>> considered in the nova notification handler (
>> https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py#L72
>> ).
>> However, it is not possible to add metadata in the floating IP records to
>> save the instance_id and remove them easily when an instance is removed.
>> What's the best approach to remove the floating address records of an
>> instance that is being removed?
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Dmitry Tantsur]

On 11/16/2015 11:35 AM, Julien Danjou wrote:

On Mon, Nov 16 2015, Dmitry Tantsur wrote:


Before you ask: using 'sudo pip install -U setuptools pbr' is out of question
in binary distributions :) so please make sure to remove this line only when
everyone is updated to whatever version is required for understanding these
;python_version=='2.7 bits.


But:
   pip install --user setuptools pbr
might not be out of the question.



Yeah, this (with added -U) fixes the problem. But then we have to add it 
to *all* contribution documentation. I'm pretty sure a lot of people 
won't realize they need it.


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

[openstack-dev] [Nova] notification subteam meeting

[Balázs Gibizer]

Hi, 

The next meeting of the nova notification subteam will happen 2015-11-17 
Tuesday 20:00 UTC [1] on #openstack-meeting-alt on freenode 

Agenda:
 - Status of the outstanding specs and code reviews
 - AOB

See you there.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151117T20 
[2] https://wiki.openstack.org/wiki/Meetings/NovaNotification 



__
OpenStack Development Mailing 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] [networking-ovs-dpdk] ovs-appctl doesn't function correctly

[Hui Xiang]

Hi all,

  I have managed to setup ovs-dpdk on Ubuntu, commands
'ovs-vsctl/ovs-ofctl' all work well excep 'ovs-appctl', could anyone help
me to figure it out? Thanks in advance.


xianghui@xianghui:~$ sudo ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:264fa4e1f24f
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(int-br-eth1): addr:2e:23:93:7f:54:14
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 2(tap7a2317aa-90): addr:0c:52:ff:7f:00:00
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
 12(vhu5392206b-dc): addr:00:00:00:00:00:00
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:26:4f:a4:e1:f2:4f
 config: PORT_DOWN
 state:  LINK_DOWN
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

xianghui@xianghui:~$ sudo ovs-appctl vlog/set dbg
2015-11-16T09:50:28Z|1|daemon_unix|WARN|/var/run/openvswitch/ovs-vswitchd.pid:
open: No such file or directory
ovs-appctl: cannot read pidfile "/var/run/openvswitch/ovs-vswitchd.pid" (No
such file or directory)

Also tried as below, failed as well.

xianghui@xianghui:~$ sudo ovs-appctl -t /opt/stack/logs/ovs-vswitchd.pid
vlog/set dbg
2015-11-16T09:58:15Z|1|unixctl|WARN|failed to connect to
/opt/stack/logs/ovs-vswitchd.pid
ovs-appctl: cannot connect to "/opt/stack/logs/ovs-vswitchd.pid"
(Connection refused)
xianghui@xianghui:~$ sudo ovs-appctl -t /var/run/openvswitch/db.sock
vlog/set dbg
unknown methodovs-appctl: /var/run/openvswitch/db.sock: server returned an
error



-- 
Best Regards.
Hui.

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

[openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Dmitry Tantsur]

Hi all!

I've seen a couple of patches removing "usedevelop = true" from tox.ini. 
This has 2 nasty consequences:
1. It's harder to manually experiment in tox environment, as you have to 
explicitly use 'tox' command every time you change code
2. The most important, it breaks tox invocation for all people who don't 
have very recent pbr and setuptools in their distributions (which I 
suspect might be the majority of people):


ERROR: invocation failed (exit code 1), logfile: 
/home/dtantsur/.gerrty-git/openstack/futurist/.tox/log/tox-0.log

ERROR: actionid=tox
msg=packaging
cmdargs=['/usr/bin/python', 
local('/home/dtantsur/.gerrty-git/openstack/futurist/setup.py'), 
'sdist', '--formats=zip', '--dist-dir', 
local('/home/dtantsur/.gerrty-git/openstack/futurist/.tox/dist')]

env=None

Installed 
/home/dtantsur/.gerrty-git/openstack/futurist/.eggs/pbr-1.8.1-py2.7.egg
error in setup command: 'install_requires' must be a string or list of 
strings containing valid project/version requirement specifiers; 
Expected ',' or end-of-list in futures>=3.0;python_version=='2.7' or 
python_version=='2.6' at ;python_version=='2.7' or python_version=='2.6'


ERROR: FAIL could not package project - v = 
InvocationError('/usr/bin/python 
/home/dtantsur/.gerrty-git/openstack/futurist/setup.py sdist 
--formats=zip --dist-dir 
/home/dtantsur/.gerrty-git/openstack/futurist/.tox/dist (see 
/home/dtantsur/.gerrty-git/openstack/futurist/.tox/log/tox-0.log)', 1)



Before you ask: using 'sudo pip install -U setuptools pbr' is out of 
question in binary distributions :) so please make sure to remove this 
line only when everyone is updated to whatever version is required for 
understanding these ;python_version=='2.7 bits.


Thank you!

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

Re: [openstack-dev] [nova] hackathon day

[Rosa, Andrea (HP Cloud Services)]

Hi, 


> -Original Message-
> From: Wang, Shane [mailto:shane.w...@intel.com]
> Sent: 12 November 2015 16:34
> To: OpenStack Development Mailing List (not for usage questions); Daniel P.
> Berrange; Bhargava, Ruchi
> Subject: Re: [openstack-dev] [nova] hackathon day
> 
> Hey, how about driving a Hackathon on the same dates in 3 geos right before
> release? Who are interested in?


We can say that for the next mid-cycle is not feasible, I think the best option 
at the moment is discuss this proposal at the next summit.
I like the idea to have it in different location not sure if having it before 
the release is a good thing, the core-reviewer efforts are all focused on 
getting the release ready which means on high priority bugs, not necessarily 
the bugs which are tackled during the hackathon.

Regards
--
Andrea Rosa



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

Re: [openstack-dev] [networking-ovs-dpdk]

[Mooney, Sean K]

Hi

Yes sorry for the delay in responding to you and samta.

In your case assuming you are using 2mb hugepages it is easy to hit dpdks 
default max memory segments

This can be changed by setting OVS_DPDK_MEM_SEGMENTS=
In the local.conf and recompiling. To do this simply remove the build complete 
file in /opt/stack/ovs
rm –f /opt/stack/BUILD_COMPLETE

in your case though you are using 1GB hugepages so I don’t think this is 
related to memory fragmentation
or a lack of free hugepages.

to use preallocated 1GB page with ovs you should instead set the following in 
your local.conf

OVS_HUGEPAGE_MOUNT_PAGESIZE=1G
OVS_ALLOCATE_HUGEPAGES=False

Regards
sean

From: Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
Sent: Monday, November 16, 2015 6:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-ovs-dpdk]

Hi all,

I have a similar problem as Samta. Am also stuck at the same place. The 
following command

$sudo ovs-vsctl br-set-external-id br-ex bridge-id br-ex

hangs forever. As Sean said, it might be because of ovs-vswitchd proces.

> The vswitchd process may exit if it  failed to allocate memory (due to memory 
> fragmentation or lack of free hugepages)
> if the ovs-vswitchd.log is not available can you check the the hugepage mount 
> point was created in
> /mnt/huge And that Iis mounted
> Run
> ls -al /mnt/huge
> and
> mount
>
$mount
/dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)
systemd on /sys/fs/cgroup/systemd type cgroup 
(rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse 
(rw,nosuid,nodev,user=ubuntu)
/mnt/huge is my mount point. So no mounting happening.
ovs-vswitchd.log says

2015-11-13T12:48:01Z|1|dpdk|INFO|User-provided -vhost_sock_dir in use: 
/var/run/openvswitch
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Searching for IVSHMEM devices...
EAL: No IVSHMEM configuration found!
EAL: Setting up memory...
EAL: Ask a virtual area of 0x18000 bytes
EAL: Virtual area found at 0x7f1e (size = 0x18000)
EAL: remap_all_hugepages(): mmap failed: Cannot allocate memory
EAL: Failed to remap 1024 MB pages
PANIC in rte_eal_init():
Cannot init memory
7: [/usr/sbin/ovs-vswitchd() [0x40b803]]
6: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f1fb52d3ec5]]
5: [/usr/sbin/ovs-vswitchd() [0x40a822]]
4: [/usr/sbin/ovs-vswitchd() [0x675432]]
3: [/usr/sbin/ovs-vswitchd() [0x442155]]
2: [/usr/sbin/ovs-vswitchd() [0x407c9f]]
1: [/usr/sbin/ovs-vswitchd() [0x447828]]
I have given hugepages in /boot/grub/grub.cfg file. So there are free hugepages.


AnonHugePages:378880 kB
HugePages_Total:   6
HugePages_Free:6
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:1048576 kB
It failed to allocate memory because mounting was not done. Did not understand 
why mounting is not done when there are free hugepages.
And also dpdk binding did happen.

$../DPDK-v2.0.0/tools/dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver

Re: [openstack-dev] [networking-ovs-dpdk] ovs-appctl doesn't function correctly

[Mooney, Sean K]

To use the ovs-appctl application you have to specify the socket path to the 
ovs-vswitchd process.
ovs-appctl -t /var/run/openvswitch/ list-commands
e.g.
ovs-appctl -t /var/run/openvswitch/ovs-vswitchd.10110.ctl list-commands



From: Hui Xiang [mailto:hui.xi...@canonical.com]
Sent: Monday, November 16, 2015 10:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-ovs-dpdk] ovs-appctl doesn't function 
correctly

Hi all,

  I have managed to setup ovs-dpdk on Ubuntu, commands 'ovs-vsctl/ovs-ofctl' 
all work well excep 'ovs-appctl', could anyone help me to figure it out? Thanks 
in advance.


xianghui@xianghui:~$ sudo ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:264fa4e1f24f
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(int-br-eth1): addr:2e:23:93:7f:54:14
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 2(tap7a2317aa-90): addr:0c:52:ff:7f:00:00
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
 12(vhu5392206b-dc): addr:00:00:00:00:00:00
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:26:4f:a4:e1:f2:4f
 config: PORT_DOWN
 state:  LINK_DOWN
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

xianghui@xianghui:~$ sudo ovs-appctl vlog/set dbg
2015-11-16T09:50:28Z|1|daemon_unix|WARN|/var/run/openvswitch/ovs-vswitchd.pid:
 open: No such file or directory
ovs-appctl: cannot read pidfile "/var/run/openvswitch/ovs-vswitchd.pid" (No 
such file or directory)

Also tried as below, failed as well.

xianghui@xianghui:~$ sudo ovs-appctl -t /opt/stack/logs/ovs-vswitchd.pid 
vlog/set dbg
2015-11-16T09:58:15Z|1|unixctl|WARN|failed to connect to 
/opt/stack/logs/ovs-vswitchd.pid
ovs-appctl: cannot connect to "/opt/stack/logs/ovs-vswitchd.pid" (Connection 
refused)
xianghui@xianghui:~$ sudo ovs-appctl -t /var/run/openvswitch/db.sock vlog/set 
dbg
unknown methodovs-appctl: /var/run/openvswitch/db.sock: server returned an error



--
Best Regards.
Hui.

OpenStack Engineer

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

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Davanum Srinivas]

Dmitry,

i was trying to bring sanity to the tox.ini(s). +1 to documenting this
step somewhere prominent.

-- Dims

On Mon, Nov 16, 2015 at 5:37 AM, Dmitry Tantsur  wrote:
> On 11/16/2015 11:35 AM, Julien Danjou wrote:
>>
>> On Mon, Nov 16 2015, Dmitry Tantsur wrote:
>>
>>> Before you ask: using 'sudo pip install -U setuptools pbr' is out of
>>> question
>>> in binary distributions :) so please make sure to remove this line only
>>> when
>>> everyone is updated to whatever version is required for understanding
>>> these
>>> ;python_version=='2.7 bits.
>>
>>
>> But:
>>pip install --user setuptools pbr
>> might not be out of the question.
>>
>
> Yeah, this (with added -U) fixes the problem. But then we have to add it to
> *all* contribution documentation. I'm pretty sure a lot of people won't
> realize they need it.
>
>
> __
> OpenStack Development Mailing 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 Srinivas :: https://twitter.com/dims

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