Re: [openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

[Lajos Katona]

Hi Matthew,

Thanks for the help, this helped a lot a start the work.

regards
Lajos

On 09/10/2015 04:13 PM, Matthew Treinish wrote:

On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote:

Hi,

I just noticed that from tag 6, the test plugin interface considered ready,
and I am eager to start to use it.
I have some questions:

If I understand well in the future the plugin interface will be moved to
tempest-lib, but now I have to import module(s) from tempest to start to use
the interface.
Is there a plan for this, I mean when the whole interface will be moved to
tempest-lib?

The only thing which will eventually move to tempest-lib is the abstract class
that defines the expected methods of a plugin class [1] The other pieces will
remain in tempest. Honestly this won't likely happen until sometime during
Mitaka. Also when it does move to tempest-lib we'll deprecate the tempest
version and keep it around to allow for a graceful switchover.

The rationale behind this is we really don't provide any stability guarantees
on tempest internals (except for a couple of places which are documented, like
this plugin class) and we want any code from tempest that's useful to external
consumers to really live in tempest-lib.


If I start to create a test plugin now (from tag 6), what should be the best
solution to do this?
I thought to create a repo for my plugin and add that as a subrepo to my
local tempest repo, and than I can easily import stuff from tempest, but I
can keep my test code separated from other parts of tempest.
Is there a better way of doing this?

To start I'd take a look at the documentation for tempest plugins:

http://docs.openstack.org/developer/tempest/plugin.html

 From tempest's point of view a plugin is really just an entry point that points
to a class that exposes certain methods. So the Tempest plugin can live anywhere
as long as it's installed as an entry point in the proper namespace. Personally
I feel like including it as a subrepo in a local tempest tree is a bit strange,
but I don't think it'll cause any issues if you do that.


If there would be an example plugin somewhere, that would be the most
preferable maybe.

There is a cookiecutter repo in progress. [2] Once that's ready it'll let you
create a blank plugin dir that'll be ready for you to populate. (similar to the
devstack plugin cookiecutter that already exists)

For current examples the only project I know of that's using a plugin interface
is manila [3] so maybe take a look at what they're doing.

-Matt Treinish

[1] 
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/test_discover/plugins.py#n26
[2] https://review.openstack.org/208389
[3] https://review.openstack.org/#/c/201955


__
OpenStack Development Mailing 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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

Hi,

Today in the #openstack-puppet channel a discussion about the pro and
cons of using domain parameter for Keystone V3 has been left opened.

The context

Domain names are needed in Openstack Keystone V3 for identifying users
or groups (of users) within different projects (tenant).
Users and groups are uniquely identified within a domain (or a realm as
opposed to project domains).
Then projects have their own domain so users or groups can be assigned
to them through roles.

In Kilo, Keystone V3 have been introduced as an experimental feature.
Puppet providers such as keystone_tenant, keystone_user,
keystone_role_user have been adapted to support it.
Also new ones have appeared (keystone_domain) or are their way
(keystone_group, keystone_trust).
And to be backward compatible with V2, the default domain is used when
no domain is provided.

In existing providers such as keystone_tenant, the domain can be either
part of the name or provided as a parameter:

A. The 'composite namevar' approach:

   keystone_tenant {'projectX::domainY': ... }
 B. The 'meaningless name' approach:

  keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}

Notes:
 - Actually using both combined should work too with the domain
supposedly overriding the name part of the domain.
 - Please look at [1] this for some background between the two approaches:

The question
-
Decide between the two approaches, the one we would like to retain for
puppet-keystone.

Why it matters?
---
1. Domain names are mandatory in every user, group or project. Besides
the backward compatibility period mentioned earlier, where no domain
means using the default one.
2. Long term impact
3. Both approaches are not completely equivalent which different
consequences on the future usage.
4. Being consistent
5. Therefore the community to decide

The two approaches are not technically equivalent and it also depends
what a user might expect from a resource title.
See some of the examples below.

Because OpenStack DB tables have IDs to uniquely identify objects, it
can have several objects of a same family with the same name.
This has made things difficult for Puppet resources to guarantee
idem-potency of having unique resources.
In the context of Keystone V3 domain, hopefully this is not the case for
the users, groups or projects but unfortunately this is still the case
for trusts.

Pros/Cons
--
A.
  Pros
- Easier names
  Cons
- Titles have no meaning!
- Cases where 2 or more resources could exists
- More difficult to debug
- Titles mismatch when listing the resources (self.instances)

B.
  Pros
- Unique titles guaranteed
- No ambiguity between resource found and their title
  Cons
- More complicated titles

Examples
--
= Meaningless name example 1=
Puppet run:
  keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}

Second run:
  keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}

Result/Listing:

  keystone_tenant { 'project_A::domain_1':
ensure  => 'present',
domain  => 'domain_1',
enabled => 'true',
id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
  }
   keystone_tenant { 'project_A::domain_2':
ensure  => 'present',
domain  => 'domain_2',
enabled => 'true',
id  => '4b8255591949484781da5d86f2c47be7',
  }

= Composite name example 1  =
Puppet run:
  keystone_tenant {'project_A::domain_1', ...}

Second run:
  keystone_tenant {'project_A::domain_2', ...}

# Result/Listing
  keystone_tenant { 'project_A::domain_1':
ensure  => 'present',
domain  => 'domain_1',
enabled => 'true',
id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
   }
  keystone_tenant { 'project_A::domain_2':
ensure  => 'present',
domain  => 'domain_2',
enabled => 'true',
id  => '4b8255591949484781da5d86f2c47be7',
   }

= Meaningless name example 2  =
Puppet run:
  keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}
  keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',
description=>'blah'...}

Result: project_A in domain_1 has a description

= Composite name example 2  =
Puppet run:
  keystone_tenant {'project_A::domain_1', ...}
  keystone_tenant {'project_A::domain_1', description => 'blah', ...}

Result: Error because the resource must be unique within a catalog

My vote

I would love to have the approach A for easier name.
But I've seen the challenge of maintaining the providers behind the
curtains and the confusion it creates with name/titles and when not sure
about the domain we're dealing with.
Also I believe that supporting self.instances consistently with
meaningful name is saner.
Therefore I vote B

Finally
--
Thanks for reading that far!
To choose, please provide feedback with more pros/cons, examples and
your vote.

Thanks,
Gilles


PS:
[1] https://groups.google.com/forum/#!topic/puppet-dev/CVYwvHnPSMc

Re: [openstack-dev] [nova] [api] Nova currently handles list with limit=0 quite different for different objects.

[Kevin L. Mitchell]

On Fri, 2015-09-11 at 15:41 +0800, Zhenyu Zheng wrote:
> Hi, I found out that nova currently handles list with limit=0 quite
> different for different objects.
> 
> Especially when list servers:
> 
> According to the code:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/common.py#n206
> 
> when limit = 0, it should apply as max_limit, but currently, in:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n1930
> 
> we directly return [], this is quite different with comment in the api
> code.
> 
> 
> I checked other objects:
> 
> when list security groups and server groups, it will return as no
> limit has been set. And for flavors it returns []. I will continue to
> try out other APIs if needed.
> 
> I think maybe we should make a rule for all objects, at least fix the
> servers to make it same in api and db code.
> 
> I have reported a bug in launchpad:
> 
> https://bugs.launchpad.net/nova/+bug/1494617
> 
> 
> Any suggestions?

After seeing the test failures that showed up on your proposed fix, I'm
thinking that the proposed change reads like an API change, requiring a
microversion bump.  That said, I approve of increased consistency across
the API, and perhaps the behavior on limit=0 is something the API group
needs to discuss a guideline for?
-- 
Kevin L. Mitchell 
Rackspace


__
OpenStack Development Mailing 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]Let's take care of our integration tests

[David Lyle]

Of course, your question confused me. As you switched to selenium tests.

To run integration tests,
./run_tests.sh --integration

which is also documented in ./run_tests.sh --help

David

On Fri, Sep 11, 2015 at 10:25 AM, David Lyle  wrote:
> Oops!
>
> ./run_tests.sh --only-selenium   only skips the non-selenium tests. It
> works as intended.  ./run_tests.sh --with-selenium will run all tests.
> Both of which are documented in the help of run_tests.sh
>
> David
>
> On Fri, Sep 11, 2015 at 10:23 AM, David Lyle  wrote:
>> raj
>>
>> On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig  wrote:
>>> Is there any documentation to run the tests locally?
>>> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
>>> recommended way?
>>>
>>> -Rajat
>>>
>>> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle  wrote:

 I completely agree about monitoring for integration test failures and
 blocking until the failure is corrected.

 The hope is to make sure we've stabilized the integration testing
 framework a bit before reenabling to vote.

 Thanks Timur, I know this has been a considerable undertaking.

 David

 On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:
 > It looks like we've reached the point where our Horizon integration
 > tests
 > are functional again.  Thanks for your work on this Timur! (Offer for
 > beer/hug at the next summit still stands)
 >
 > I'd like to have these tests voting again ASAP, but I understand that
 > might
 > be a bit risky at this point. We haven't yet proven that these tests
 > will be
 > stable over the long term.
 >
 > I encourage all of the reviewers to keep the integration tests in mind
 > as we
 > are reviewing code. Keep an eye on the status of the
 > gate-horizon-dsvm-integration test. It's failure would be great reason
 > to
 > hand out a -1!
 >
 > Doug
 >
 >
 >
 > __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >

 __
 OpenStack Development Mailing 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] [Glance] glance core rotation part 1

[Alex Meade]

+1

On Fri, Sep 11, 2015 at 2:33 PM, Ian Cordasco 
wrote:

>
>
> -Original Message-
> From: Nikhil Komawar 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: September 11, 2015 at 09:30:23
> To: openstack-dev@lists.openstack.org 
> Subject:  [openstack-dev] [Glance] glance core rotation part 1
>
> > Hi,
> >
> > I would like to propose the following removals from glance-core based on
> > the simple criterion of inactivity/limited activity for a long period (2
> > cycles or more) of time:
> >
> > Alex Meade
> > Arnaud Legendre
> > Mark Washenberger
> > Iccha Sethi
>
> I think these are overdue
>
> > Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)
>
> Sad to see Zhi Yan Liu's activity drop off.
>
> > Please vote +1 or -1 and we will decide by Monday EOD PT.
>
> +1
>
> --
> Ian Cordasco
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Suggestion to split install guide

[Devananda van der Veen]

I agree that it's far too long right now and should be split up.

I would suggest splitting the section on standalone usage into its own
guide, since many of the advanced topics can apply to using Ironic
with and without other services. So perhaps more like this:

- Basic Install Guide with OpenStack
- Basic Install Gude for stand-alone usage
- Advanced topics
-- working with UEFI
-- using configdrive instead of cloud-init
-- hardware inspection
-- trusted and secure boot
- Driver references
-- one section for each driver's specific guide



On Fri, Sep 11, 2015 at 7:57 AM, Bruno Cornec  wrote:
> Hello,
>
> Dmitry Tantsur said on Fri, Sep 11, 2015 at 10:56:07AM +0200:
>>
>> Our install guide is huge, and I've just approved even more text for it.
>> WDYT about splitting it into "Basic Install Guide", which will contain bare
>> minimum for running ironic and deploying instances, and "Advanced Install
>> Guide", which will the following things:
>> 1. Using Bare Metal service as a standalone service
>> 2. Enabling the configuration drive (configdrive)
>> 3. Inspection
>> 4. Trusted boot
>> 5. UEFI
>
>
> As a recent reader, I'd like to keep the UEFI part in the main doc as
> more and more server will be UEFI by default. The rest seems good to go
> in a separate one.
>
> Bruno.
> --
> Open Source Profession, Linux Community Lead WW  http://opensource.hp.com
> HP EMEA EG Open Source Technology Strategist http://hpintelco.net
> FLOSS projects: http://mondorescue.org http://project-builder.org
> Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Nova] Design Summit Topics for Nova

[John Garbutt]

Hi,

Its time to start thinking about what things you want to get discussed
at the Design Summit, this is specifically the Nova developer design
summit track. We have about 14 fishbowl sessions.

To make it easier to know who submitted what, we are going to try out
google forms for the submissions:
http://goo.gl/forms/D2Qk8XGhZ6

If that does not work for you, let me know, and I can see what can be done.

Note: the form does encourage linking to a spec, as that can be useful
for setting the context of the idea you want to discuss. There will
likely be more news on nova-spec reviews, and setting priorities on
specs, once we have RC1 out the door.

Thanks,
johnthetubaguy

PS
We can sort out links to etherpads for the Friday meet up and
unconference slots (if we do those) nearer the time.

__
OpenStack Development Mailing 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] [Heat] Scattered thoughts on the PTL election

[Zane Bitter]

The Heat project pioneered the concept of rotating the PTL for every 
development cycle, and so far all of the early (before 2013) developers 
who are still involved have served as PTL. I think this has been a 
*tremendous* success for the project, and a testament to the sheer depth 
of leadership talent that we are fortunate to have (as well as, it must 
be said, to Thierry and the release management team and their ability to 
quickly bring new people up to speed every cycle). We're already seeing 
a lot of other projects moving toward the PTL role having a shorter time 
horizon, and I suspect the main reason they're not moving more rapidly 
in that direction is that it takes time to build up the expectation of 
rotating succession and make sure that the leaders within each project 
are preparing to take their turn. So I like to think that we've been a 
good influence on the whole OpenStack community in this respect :)


(I'd also note that this expectation is very helpful in terms of 
spreading the workload around and reducing the amount of work that falls 
on a single person. To the extent that it is possible to be the PTL of 
the Heat project and still get some real work done, not just clicking on 
things in Launchpad - though, be warned, there is still quite a bit of 
that involved.)


However, there is one area in which we have not yet been as successful: 
so far all of the PTLs have been folks that were early developers of the 
project. IMHO it's time for that to change: we have built an amazing 
team of folks since then who are great leaders in the community and who 
now have the experience to step up. I can think of at least 4 excellent 
potential candidates just off the top of my head.


Obviously there is a time commitment involved - in fact Flavio's entire 
blog post[1] is great and you should definitely read that first - but if 
you are already devoting a majority of your time to the upstream Heat 
project and you think this is likely to be sustainable for the next 6 
months, then please run for PTL!


(You may safely infer from this that I won't be running this time.)

cheers,
Zane.

[1] http://blog.flaper87.com/post/something-about-being-a-ptl/

__
OpenStack Development Mailing 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] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Chris Dent]

On Fri, 11 Sep 2015, Luo Gangyi wrote:


I am using master branch and newest code for testing.

For the purpose for learning the structure of gnocchi, I changed the
default UUID type of mysql from binary to char, so I can easily link
the resource-id(I mean in database), metric id and directory name of
storing measures.

When I did that, I found all the metrics where their resource id is
combined(here, I mean in Ceilometer, such as instance-xxx-tap)
have no measures stored.


In addition to the things that Julien has said, one thing that is
non-obvious about how gnocchi stores resources is that if the
incoming ID is _not_ a UUID then a uuid5 hash is created based on the id
provided. So if your resource has an ceilometer-side id of 'instance-xxx-
tap' it will be saved in the database in a form like 
5B0A4989-44C3-46D1-A1ED-
4705062F51A2. The code review for that change is here:
https://review.openstack.org/#/c/216390/

With that change in place you can still use the 'instance-xxx-tap' ID
in the  part of /v1/metric/resource// URLs and in
search queries.

But as pointed out elsewhere in the thread at least some of your
resources are missing because of the 'display_name' attribute being
dropped.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing 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]Let's take care of our integration tests

[Rajat Vig]

Is there any documentation to run the tests locally?
Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
recommended way?

-Rajat

On Thu, Sep 10, 2015 at 3:54 PM, David Lyle  wrote:

> I completely agree about monitoring for integration test failures and
> blocking until the failure is corrected.
>
> The hope is to make sure we've stabilized the integration testing
> framework a bit before reenabling to vote.
>
> Thanks Timur, I know this has been a considerable undertaking.
>
> David
>
> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:
> > It looks like we've reached the point where our Horizon integration tests
> > are functional again.  Thanks for your work on this Timur! (Offer for
> > beer/hug at the next summit still stands)
> >
> > I'd like to have these tests voting again ASAP, but I understand that
> might
> > be a bit risky at this point. We haven't yet proven that these tests
> will be
> > stable over the long term.
> >
> > I encourage all of the reviewers to keep the integration tests in mind
> as we
> > are reviewing code. Keep an eye on the status of the
> > gate-horizon-dsvm-integration test. It's failure would be great reason to
> > hand out a -1!
> >
> > Doug
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon]Let's take care of our integrationtests

[Douglas Fish]

Also some info available at
 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/integration_tests/README.rst
 
to point out needed config
Doug
 
 
- Original message -From: David Lyle To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [Horizon]Let's take care of our integration testsDate: Fri, Sep 11, 2015 11:39 AM 
Of course, your question confused me. As you switched to selenium tests.To run integration tests,./run_tests.sh --integrationwhich is also documented in ./run_tests.sh --helpDavidOn Fri, Sep 11, 2015 at 10:25 AM, David Lyle  wrote:> Oops!>> ./run_tests.sh --only-selenium   only skips the non-selenium tests. It> works as intended.  ./run_tests.sh --with-selenium will run all tests.> Both of which are documented in the help of run_tests.sh>> David>> On Fri, Sep 11, 2015 at 10:23 AM, David Lyle  wrote:>> raj On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig  wrote:>>> Is there any documentation to run the tests locally?>>> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the>>> recommended way?>> -Rajat>> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle  wrote: I completely agree about monitoring for integration test failures and blocking until the failure is corrected. The hope is to make sure we've stabilized the integration testing framework a bit before reenabling to vote. Thanks Timur, I know this has been a considerable undertaking. David On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote: > It looks like we've reached the point where our Horizon integration > tests > are functional again.  Thanks for your work on this Timur! (Offer for > beer/hug at the next summit still stands) > > I'd like to have these tests voting again ASAP, but I understand that > might > be a bit risky at this point. We haven't yet proven that these tests > will be > stable over the long term. > > I encourage all of the reviewers to keep the integration tests in mind > as we > are reviewing code. Keep an eye on the status of the > gate-horizon-dsvm-integration test. It's failure would be great reason > to > hand out a -1! > > Doug > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing 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:unsubscribehttp://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] [Fuel] Nominate Olga Gusarenko for fuel-docs core

[Irina Povolotskaya]

Fuelers,

I'd like to nominate Olga Gusarenko for the fuel-docs-core.

She has been doing great work and made a great contribution
into Fuel documentation:

http://stackalytics.com/?user_id=ogusarenko=all_type=all=fuel-docs

It's high time to grant her core reviewer's rights in fuel-docs.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

-- 
Best regards,

Irina
__
OpenStack Development Mailing 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] Nominate Olga Gusarenko for fuel-docs core

[Dmitry Borodaenko]

+1

Great work Olga!

On Fri, Sep 11, 2015, 11:09 Irina Povolotskaya 
wrote:

> Fuelers,
>
> I'd like to nominate Olga Gusarenko for the fuel-docs-core.
>
> She has been doing great work and made a great contribution
> into Fuel documentation:
>
>
> http://stackalytics.com/?user_id=ogusarenko=all_type=all=fuel-docs
>
> It's high time to grant her core reviewer's rights in fuel-docs.
>
> Core reviewer approval process definition:
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> --
> Best regards,
>
> Irina
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon]Let's take care of our integration tests

[David Lyle]

raj

On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig  wrote:
> Is there any documentation to run the tests locally?
> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
> recommended way?
>
> -Rajat
>
> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle  wrote:
>>
>> I completely agree about monitoring for integration test failures and
>> blocking until the failure is corrected.
>>
>> The hope is to make sure we've stabilized the integration testing
>> framework a bit before reenabling to vote.
>>
>> Thanks Timur, I know this has been a considerable undertaking.
>>
>> David
>>
>> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:
>> > It looks like we've reached the point where our Horizon integration
>> > tests
>> > are functional again.  Thanks for your work on this Timur! (Offer for
>> > beer/hug at the next summit still stands)
>> >
>> > I'd like to have these tests voting again ASAP, but I understand that
>> > might
>> > be a bit risky at this point. We haven't yet proven that these tests
>> > will be
>> > stable over the long term.
>> >
>> > I encourage all of the reviewers to keep the integration tests in mind
>> > as we
>> > are reviewing code. Keep an eye on the status of the
>> > gate-horizon-dsvm-integration test. It's failure would be great reason
>> > to
>> > hand out a -1!
>> >
>> > Doug
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] ?????? [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Luo Gangyi]

Thanks Julien :)
  
 >  But I don't think Ceilometer has this metric posted to Gnocchi yet, the
>  code is a bit young and not finished on the Ceilometer side. If you
>  check gnocchi_resources.yaml, it's still marked "ignored" for now.
  
 I checked it again, no "ignored" is marked, seems the bug of devstack ;(
  
 And it's OK that gnocchi is not perfect now, but I still have some worries 
about how gnocchi deal with or going to deal with instance--tapxxx 
condition.
 I see 'network.incoming.bytes' belongs to resouce type 'instance'. But no 
attributes of instance can save the infomation of tap name. Although I can 
search
 all metric ids from resouce id(instance uuid), how do I distinguish them from 
different taps of an instance?
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com



  
  

 

 --  --
  ??: "Julien Danjou";;
 : 2015??9??12??(??) 0:01
 ??: "Luo Gangyi"; 
 : "OpenStack Development Mailing L"; 
 : Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with 
combined resource-id ?

 

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Gangyi,

>  I am using master branch and newest code for testing.

Cool.

>  For the purpose for learning the structure of gnocchi, I changed the
>  default UUID type of mysql from binary to char, so I can easily link
>  the resource-id(I mean in database), metric id and directory name of
>  storing measures.

Bah, don't do that ?C and rather use PostgreSQL, it's the recommended
backend. :)

>  When I did that, I found all the metrics where their resource id is
>  combined(here, I mean in Ceilometer, such as instance-xxx-tap)
>  have no measures stored.


>  Log in Ceilometer collector records this:
>  "
>  2015-09-11 07:55:55.097 10636 ERROR ceilometer.dispatcher.gnocchi [-] 
> Resource 
> instance-0001-4641f59e-994c-4255-b0ec-43a276d1c19c-tap8aadb7ad-d7 
> creation failed with status: 400: 
>  
>   400 Bad Request
>  
>  
>   400 Bad Request
>   The server could not comply with the request since it is either malformed 
> or otherwise incorrect.
> Invalid input: required key not provided @ data['display_name']
>   
> 
>
>  "
>  So I wander whether gnocchi cannot deal with such combined resource-id 
> metrics or whether it is because I change the UUID type or whatever.

Yes, it can, but the problem is more likely in the Ceilometer collector
dispatcher code that is sending the data. From the error you have, it
seems it tries to create an instance but it has no value for
display_name, so it is denied by Gnocchi. If this is from a standard
devstack installation, I'd suggest to open a bug on Ceilometer.

>  And another question is how to query measures for those metrics whose
>  resource id is combined.

They are resource on their own so if you know their id you can just
access the metrics at /v1/resources///metric//measures.

>  For example, I want to query the network traffic of an vm, I know the
>  instance uuid -, I know metric name
>  'network.incoming.byte.rate' but I do not know the exact resouce_id
>  and metric id. What procedure should I do ?

You need to know the ID of the resource and then ask for its metric on
the REST interface. If you don't know the ID of the resource, you can
search for it by instance id.

But I don't think Ceilometer has this metric posted to Gnocchi yet, the
code is a bit young and not finished on the Ceilometer side. If you
check gnocchi_resources.yaml, it's still marked "ignored" for now.

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info__
OpenStack Development Mailing 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] [devstack][keystone][ironic] Use only Keystone v3 API in DevStack

[Devananda van der Veen]

We (the Ironic team) have talked a couple times about keystone /v3
support and about improving the granularity of policy support within
Ironic. No one stepped up to work on these specifically, and they
weren't prioritized during Liberty ... but I think everyone agreed
that we should get on with the keystone v3 relatively soon.

If Ironic is the only integrated project that doesn't support v3 yet,
then yea, we should get on that as soon as M opens.

-Devananda

On Fri, Sep 11, 2015 at 9:45 AM, Davanum Srinivas  wrote:
> Hi,
>
> Short story/question:
> Is keystone /v3 support important to the ironic team? For Mitaka i guess?
>
> Long story:
> The previous discussion - guidance from keystone team on magnum
> (http://markmail.org/message/jchf2vj752jdzfet) motivated me to dig into the
> experimental job we have in devstack for full keystone v3 api and ended up
> with this review.
>
> https://review.openstack.org/#/c/221300/
>
> So essentially that rips out v2 keystone pipeline *except* for ironic jobs.
> as ironic has some hard-coded dependencies to keystone /v2 api. I've logged
> a bug here:
> https://bugs.launchpad.net/ironic/+bug/1494776
>
> Note that review above depends on Jamie's tempest patch which had some hard
> coded /v2 dependency as well (https://review.openstack.org/#/c/214987/)
>
> follow up question:
> Does anyone know of anything else that does not work with /v3?
>
> Thanks,
> Dims
>
> --
> 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] [Glance] glance core rotation part 1

[Ian Cordasco]

 

-Original Message-
From: Nikhil Komawar 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: September 11, 2015 at 09:30:23
To: openstack-dev@lists.openstack.org 
Subject:  [openstack-dev] [Glance] glance core rotation part 1

> Hi,
>  
> I would like to propose the following removals from glance-core based on
> the simple criterion of inactivity/limited activity for a long period (2
> cycles or more) of time:
>  
> Alex Meade
> Arnaud Legendre
> Mark Washenberger
> Iccha Sethi

I think these are overdue

> Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)

Sad to see Zhi Yan Liu's activity drop off.

> Please vote +1 or -1 and we will decide by Monday EOD PT.

+1

--  
Ian Cordasco
__
OpenStack Development Mailing 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]Let's take care of our integration tests

[David Lyle]

Oops!

./run_tests.sh --only-selenium   only skips the non-selenium tests. It
works as intended.  ./run_tests.sh --with-selenium will run all tests.
Both of which are documented in the help of run_tests.sh

David

On Fri, Sep 11, 2015 at 10:23 AM, David Lyle  wrote:
> raj
>
> On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig  wrote:
>> Is there any documentation to run the tests locally?
>> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
>> recommended way?
>>
>> -Rajat
>>
>> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle  wrote:
>>>
>>> I completely agree about monitoring for integration test failures and
>>> blocking until the failure is corrected.
>>>
>>> The hope is to make sure we've stabilized the integration testing
>>> framework a bit before reenabling to vote.
>>>
>>> Thanks Timur, I know this has been a considerable undertaking.
>>>
>>> David
>>>
>>> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:
>>> > It looks like we've reached the point where our Horizon integration
>>> > tests
>>> > are functional again.  Thanks for your work on this Timur! (Offer for
>>> > beer/hug at the next summit still stands)
>>> >
>>> > I'd like to have these tests voting again ASAP, but I understand that
>>> > might
>>> > be a bit risky at this point. We haven't yet proven that these tests
>>> > will be
>>> > stable over the long term.
>>> >
>>> > I encourage all of the reviewers to keep the integration tests in mind
>>> > as we
>>> > are reviewing code. Keep an eye on the status of the
>>> > gate-horizon-dsvm-integration test. It's failure would be great reason
>>> > to
>>> > hand out a -1!
>>> >
>>> > Doug
>>> >
>>> >
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

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

[openstack-dev] [devstack][keystone][ironic] Use only Keystone v3 API in DevStack

[Davanum Srinivas]

Hi,

Short story/question:
Is keystone /v3 support important to the ironic team? For Mitaka i guess?

Long story:
The previous discussion - guidance from keystone team on magnum (
http://markmail.org/message/jchf2vj752jdzfet) motivated me to dig into the
experimental job we have in devstack for full keystone v3 api and ended up
with this review.

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

So essentially that rips out v2 keystone pipeline *except* for ironic jobs.
as ironic has some hard-coded dependencies to keystone /v2 api. I've logged
a bug here:
https://bugs.launchpad.net/ironic/+bug/1494776

Note that review above depends on Jamie's tempest patch which had some hard
coded /v2 dependency as well (https://review.openstack.org/#/c/214987/)

follow up question:
Does anyone know of anything else that does not work with /v3?

Thanks,
Dims

-- 
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-dev] [fuel][swift] Separate roles for Swift nodes

[Daniel Depaoli]

Hi all!
I'm starting to investigate some improvements for swift installation in
fuel, in paticular a way to dedicate a node for it. I found this blueprint
https://blueprints.launchpad.net/fuel/+spec/swift-separate-role that seems
to be what i'm looking for.
The blueprint was accepted but not yet started. So, can someone tell me
more about this blueprint? I'm interested in working for it.

Best regards,

-- 

Daniel Depaoli
CREATE-NET Research Center
Smart Infrastructures Area
Junior Research 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] [neutron][tempest] iptables-based security groups / accepting ingress ICMP

[Tikkanen, Viktor (Nokia - FI/Espoo)]

Hi!

We have a scenario tempest test case (test_cross_tenant_traffic) which
assumes that an instance should be able to receive icmp echo responses
even when no ingress security rules are defined for that instance.

I don't take a stand on iptables-based security group implementation
details (this was discussed e.g. here:
http://lists.openstack.org/pipermail/openstack-dev/2015-April/060989.html
) but rather on tempest logic.

Do we have some requirement(s) that incoming packets with ESTABLISHED
state should be accepted regardless of security rules? If so, does it
really concern also ICMP packets?

And if there are no such requirements, should we e.g. parameterize the
test case so that it will be skipped when no iptables-based firewall
drivers are used?

-Viktor

__
OpenStack Development Mailing 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] [Devstack][Sahara][Cinder] BlockDeviceDriver support in Devstack

[Vitaly Gridnev]

Hello folks!

Cinder supports BlockDeviceDriver [1] for a while, but driver cannot be
selected as a backend during devstack installation. This driver solves
several possible issues with I/O performance, which is really important for
Sahara clusters. Also, support of this driver is required for CI of this
driver in Cinder.

I uploaded the change [0] to review with support of this backend at
devstack, but this change really missed for reviewers. This change got a
bunch of +1's and I would like to request for extra reviews for that.

Thanks!

[0] Change on review: https://review.openstack.org/#/c/214194/
[1] https://wiki.openstack.org/wiki/BlockDeviceDriver

Best Regards,
Vitaly Gridnev
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] [keystone] PTL non-candidacy

[Henry Nash]

Gotta add my thanks as well…as I’m sure Dolph will attest, it’s a tough job - 
and we’ve been lucky to have people who have been prepared to put in the really 
significant effort  that is required to make both the role and the project 
successful!

To infinity and beyond….

Henry
> On 11 Sep 2015, at 05:08, Brad Topol  wrote:
> 
> Thank you Morgan for your outstanding leadership, tremendous effort, and your 
> dedication to OpenStack and Keystone in particular. It has been an absolute 
> pleasure getting to work with you these past few years. And I am looking 
> forward to working with you in your new role!!!
> 
> --Brad
> 
> 
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
> 
> Morgan Fainberg ---09/10/2015 05:44:52 PM---As I outlined 
> (briefly) in my recent announcement of changes ( 
> https://www.morganfainberg.com/blog/2 
> 
> From: Morgan Fainberg 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 09/10/2015 05:44 PM
> Subject: [openstack-dev] [keystone] PTL non-candidacy
> 
> 
> 
> 
> As I outlined (briefly) in my recent announcement of changes ( 
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
>  
> 
>  ) I will not be running for PTL of Keystone this next cycle (Mitaka). The 
> role of PTL is a difficult but extremely rewarding job. It has been amazing 
> to see both Keystone and OpenStack grow.
> 
> I am very pleased with the accomplishments of the Keystone development team 
> over the last year. We have seen improvements with Federation, 
> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing, 
> releasing a dedicated authentication library, cross-project initiatives 
> around improving the Service Catalog, and much, much more. I want to thank 
> each and every contributor for the hard work that was put into Keystone and 
> its associated projects.
> 
> While I will be changing my focus to spend more time on the general needs of 
> OpenStack and working on the Public Cloud story, I am confident in those who 
> can, and will, step up to the challenges of leading development of Keystone 
> and the associated projects. I may be working across more projects, but you 
> can be assured I will be continuing to work hard to see the initiatives I 
> helped start through. I wish the best of luck to the next PTL.
> 
> I guess this is where I get to write a lot more code soon!
> 
> See you all (in person) in Tokyo!
> --Morgan__
> OpenStack Development Mailing 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][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

[Thierry Carrez]

Tony Breeds wrote:
> Nominations for OpenStack PTLs (Program Technical Leads) are now open and will
> remain open until September 17, 05:59 UTC.

Programs are called Project Teams (since the Big Tent reform), and we
recognize that the PTL leading duties are not just technical, so PTL is
now actually an acronym for "Project Team Leads".

Cheers,

-- 
Thierry Carrez (ttx)



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

[openstack-dev] [nova] Nova currently handles list with limit=0 quite different for different objects.

[Zhenyu Zheng]

Hi, I found out that nova currently handles list with limit=0 quite
different for different objects.

Especially when list servers:

According to the code:
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/common.py#n206

when limit = 0, it should apply as max_limit, but currently, in:
http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n1930

we directly return [], this is quite different with comment in the api code.


I checked other objects:

when list security groups and server groups, it will return as no limit has
been set. And for flavors it returns []. I will continue to try out other
APIs if needed.

I think maybe we should make a rule for all objects, at least fix the
servers to make it same in api and db code.

I have reported a bug in launchpad:

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

Any suggestions?

Best Regards,

Zheng
__
OpenStack Development Mailing 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] [Glance] python-glanceclient 1.0.x back compat for v2 proposal.

[Flavio Percoco]

On 11/09/15 08:08 +1200, Robert Collins wrote:

On 11 September 2015 at 07:48, Nikhil Komawar  wrote:

Hi all,


...

3. python-glanceclient upgrades need to be done in staged manner and by
cross-checking the rel-notes or preferably commit messages if your
deployment is fragile to upgrades. A CI/CD pipeline shouldn't need such
back compat changes for long period of time.


I wanted to ask more about this one. This is AIUI opposite to the
advice we've previously given well, everyone. My understanding was
that for all clients, all versions of the client work with all
versions of OpenStack that are currently upstream supported, always.

That suggests that installing the current version is always safe! Has
that changed? What should users that use many different clouds do now?


I believe the above keeps being true. At least, that's what I hope,
for the sake of interoperability and compatibility.

However, let me expand a bit what Nikhil said in his emails on this
thread:

1) The CLI and the library are still compatible with the V1 of the
API. Unfortunately, these 2 APIs are not 100% compatible between them
and that's what is causing the issues mentioned in the previous email.

2) While I think this incompatibilities are unfortunate, I also
think this changes are required to clean up the CLI from old
properties. This is the first time that Glance's does this - not going
to get in the details of why this is the case - but I believe it's
good for the project at this point.

Now, the real reason why I think we're having this conversation now
and we didn't have it before is because glanceclient keeps depending
on an explicit/default API version being passed through the CLI rather
than using the information returned by the identity service.

In addition to the above, glanceclient - and I think many other
clients too - keeps mapping the CLI 1:1 to the server's API. I think
this makes maintaining the CLI more difficult and it's also
not-user-friendly. Many things that are exposed through the CLI
- and especially the way they are exposed: json, I'm looking at you -
are simply not required or not important for the user that just wants
to "use the cloud".

To conclude, this release doesn't mean the team is dead set on the
current CLI. It just means that the CLI has been cleaned up and
Liberty's stable branch for glanceclient will be cut from the latest
version. If there are things users want to have, they'll be
reconsidered and added back if necessary. These things would be
released in a minor version during Mitaka and users will be able to
consume them anyway. In other words, I'd love to see more interaction
between the glance community and the broader users community. The lack
of communication between these two has caused most of the problems
we've seen lately. I hope enough feedback will come back and thorough
tests of this new version will also be done, which is not to say that
these breaking changes are meant to increase the communication, just
to be clear :)

Cheers,
Flavio

P.S: Also, in this specific case, I'd rather make v1's CLI v2
compatible than the other way around, TBH. That'd help people migrate
their scripts and still be able to use them to talk to v1 servers
without any changes. Can we talk about this?



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


--
@flaper87
Flavio Percoco


pgp3ESBDnVL2f.pgp
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] [glance] [nova] Verification of glance images before boot

[Flavio Percoco]

On 10/09/15 15:36 -0400, Nikhil Komawar wrote:

The solution to this problem is to improve the scrubber to clean up the
garbage data left behind in the backend store during such failed uploads.

Currently, scrubber cleans up images in pending_delete and extending
that to images in killed status would avoid such a situation.


While the above would certainly help, I think it's not the right
solution. Images in status "killed" should not have data to begin
with.

I'd rather find a way to clean that data as soon as the image is
moved to a "killed" state instead of extending the scrubber.

Cheers,
Flavio


On 9/10/15 3:28 PM, Poulos, Brianna L. wrote:

Malini,

Thank you for bringing up the ³killed² state as it relates to quota.  We
opted to move the image to a killed state since that is what occurs when
an upload fails, and the signature verification failure would occur during
an upload.  But we should keep in mind the potential to take up space and
yet not take up quota when signature verification fails.

Regarding the MD5 hash, there is currently a glance spec [1] to allow the
hash method used for the checksum to be configurable‹currently it is
hardcoded in glance.  After making it configurable, the default would
transition from MD5 to something more secure (like SHA-256).

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

Thanks,
~Brianna




On 9/10/15, 5:10 , "Bhandaru, Malini K" 
wrote:


Brianna, I can imagine a denial of service attack by uploading images
whose signature is invalid if we allow them to reside in Glance
In a "killed" state. This would be less of an issue "killed" images still
consume storage quota until actually deleted.
Also given MD-5 less secure, why not have the default hash be SHA-1 or 2?
Regards
Malini

-Original Message-
From: Poulos, Brianna L. [mailto:brianna.pou...@jhuapl.edu]
Sent: Wednesday, September 09, 2015 9:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: stuart.mcla...@hp.com
Subject: Re: [openstack-dev] [glance] [nova] Verification of glance
images before boot

Stuart is right about what will currently happen in Nova when an image is
downloaded, which protects against unintentional modifications to the
image data.

What is currently being worked on is adding the ability to verify a
signature of the checksum.  The flow of this is as follows:
1. The user creates a signature of the "checksum hash" (currently MD5) of
the image data offline.
2. The user uploads a public key certificate, which can be used to verify
the signature to a key manager (currently Barbican).
3. The user creates an image in glance, with signature metadata
properties.
4. The user uploads the image data to glance.
5. If the signature metadata properties exist, glance verifies the
signature of the "checksum hash", including retrieving the certificate

>from the key manager.

6. If the signature verification fails, glance moves the image to a
killed state, and returns an error message to the user.
7. If the signature verification succeeds, a log message indicates that
it succeeded, and the image upload finishes successfully.

8. Nova requests the image from glance, along with the image properties,
in order to boot it.
9. Nova uses the signature metadata properties to verify the signature
(if a configuration option is set).
10. If the signature verification fails, nova does not boot the image,
but errors out.
11. If the signature verification succeeds, nova boots the image, and a
log message notes that the verification succeeded.

Regarding what is currently in Liberty, the blueprint mentioned [1] has
merged, and code [2] has also been merged in glance, which handles steps
1-7 of the flow above.

For steps 7-11, there is currently a nova blueprint [3], along with code
[4], which are proposed for Mitaka.

Note that we are in the process of adding official documentation, with
examples of creating the signature as well as the properties that need to
be added for the image before upload.  In the meantime, there's an
etherpad that describes how to test the signature verification
functionality in Glance [5].

Also note that this is the initial approach, and there are some
limitations.  For example, ideally the signature would be based on a
cryptographically secure (i.e. not MD5) hash of the image.  There is a
spec in glance to allow this hash to be configurable [6].

[1]
https://blueprints.launchpad.net/glance/+spec/image-signing-and-verificati
o
n-support
[2]
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107dd
b
4b04ff6e
[3] https://review.openstack.org/#/c/188874/
[4] https://review.openstack.org/#/c/189843/
[5]
https://etherpad.openstack.org/p/liberty-glance-image-signing-instructions
[6] https://review.openstack.org/#/c/191542/


Thanks,
~Brianna




On 9/9/15, 12:16 , "Nikhil Komawar"  wrote:


That's correct.

The size and the checksum are to be verified outside of Glance, in this
case Nova. 

[openstack-dev] [Ironic] Suggestion to split install guide

[Dmitry Tantsur]

Hi all!

Our install guide is huge, and I've just approved even more text for it. 
WDYT about splitting it into "Basic Install Guide", which will contain 
bare minimum for running ironic and deploying instances, and "Advanced 
Install Guide", which will the following things:

1. Using Bare Metal service as a standalone service
2. Enabling the configuration drive (configdrive)
3. Inspection
4. Trusted boot
5. UEFI

Opinions?

__
OpenStack Development Mailing 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] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Luo Gangyi]

Hi devs,


I am trying Ceilometer with gnocchi. 


I find that gnocchi cannot deal with combined resource-id such as 
instance-xx-tapxx or instance--vda. I'm not sure whether it is my 
configuration problem or just bug.


And if such combined resource-id can be processed correctly, what about its 
metadata(or called attributes)? In current design, gnocchi seems treat 
instance-aaa, instance-aaa-tap111,   instance-aaa-tap222 as equal although they 
have parent-child relationship and share many attributes.


Is anyone else have the same problem and concern?



--
Luo gangyiluogan...@chinamobile.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] [neutron][tempest] iptables-based security groups / accepting ingress ICMP

[Kevin Benton]

Neutron security groups are stateful. A response should be able to come
back without ingress rules regardless of the use of iptables.

On Fri, Sep 11, 2015 at 12:25 AM, Tikkanen, Viktor (Nokia - FI/Espoo) <
viktor.tikka...@nokia.com> wrote:

> Hi!
>
> We have a scenario tempest test case (test_cross_tenant_traffic) which
> assumes that an instance should be able to receive icmp echo responses
> even when no ingress security rules are defined for that instance.
>
> I don't take a stand on iptables-based security group implementation
> details (this was discussed e.g. here:
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/060989.html
> ) but rather on tempest logic.
>
> Do we have some requirement(s) that incoming packets with ESTABLISHED
> state should be accepted regardless of security rules? If so, does it
> really concern also ICMP packets?
>
> And if there are no such requirements, should we e.g. parameterize the
> test case so that it will be skipped when no iptables-based firewall
> drivers are used?
>
> -Viktor
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
__
OpenStack Development Mailing 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] Fine-grained error reporting via the external API

[Matthew Booth]

I've recently been writing a tool which uses Nova's external API. This
is my first time consuming this API, so it has involved a certain amount
of discovery. The tool is here for the curious:

  https://gist.github.com/mdbooth/163f5fdf47ab45d7addd

I have felt hamstrung by the general inability to distinguish between
different types of error. For example, if a live migration failed is it
because:

1. The compute driver doesn't support support it.

2. This instance requires block storage migration.

3. Something ephemeral.

These 3 errors all require different responses:

1. Quit and don't try again.

2. Try again immediately with the block migration argument.[1]

3. Try again in a bit.

However, all I have is that I made a BadRequest. I could potentially
grep the human readable error message, but the text of that message
doesn't form part of the API, and it may be translated in any case. As
an API consumer, it seems I can't really tell anything other than 'it
didn't work'. More than that requires guesswork, heuristics and inference.

I don't think I've missed some source of additional wisdom, but it would
obviously be great if I have. Has there ever been any effort to define
some contract around more fine-grained error reporting?

Thanks,

Matt

[1] Incidentally, this suggests to me that live migrate should just do
this anyway.
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
OpenStack Development Mailing 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] [CI] [zuul] Can not vote +/-1 verified into gerrit server

[Watanabe, Isao]

Hello, Ramy

Thank you for your help.
Could you do me another favor, please.
I need to move our CI from sandbox to cinder later.
Do I need to register the CI to anywhere, so that the CI could test new patch 
set in cinder project, please?

Best regards,
Watanabe.isao



> -Original Message-
> From: Asselin, Ramy [mailto:ramy.asse...@hp.com]
> Sent: Friday, September 11, 2015 12:07 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into
> gerrit server
> 
> Done. Thank you for adding your CI system to the wiki.
> 
> Ramy
> 
> -Original Message-
> From: Watanabe, Isao [mailto:watanabe_i...@jp.fujitsu.com]
> Sent: Thursday, September 10, 2015 8:00 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into
> gerrit server
> 
> Hello, Ramy
> 
> Could you please add the following CI to the third-party ci group, too.
> 
> Fujitsu ETERNUS CI
> 
> We are preparing this CI test system, and going to use this CI system to test
> Cinder.
> The wiki of this CI:
> 
> 
> Thank you very much.
> 
> Best regards,
> Watanabe.isao
> 
> 
> 
> > -Original Message-
> > From: Asselin, Ramy [mailto:ramy.asse...@hp.com]
> > Sent: Thursday, September 10, 2015 8:00 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified
> > into gerrit server
> >
> > I added Fnst OpenStackTest CI
> >  > us :open,n,z>  to the third-party ci group.
> >
> > Ramy
> >
> >
> >
> > From: Evgeny Antyshev [mailto:eantys...@virtuozzo.com]
> > Sent: Thursday, September 10, 2015 3:51 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified
> > into gerrit server
> >
> >
> >
> >
> >
> > On 10.09.2015 11:30, Xie, Xianshan wrote:
> >
> > Hi, all,
> >
> >In my CI environment, after submitting a patch into
> > openstack-dev/sandbox,
> >
> > the Jenkins Job can be launched automatically, and the result message
> > of the job also can be posted into the gerrit server successfully.
> >
> > Everything seems fine.
> >
> >
> >
> > But in the "Verified" column, there is no verified vote, such as +1
> > or -1.
> >
> > You will be able when your CI account is added to "Third-Party CI"
> > group on review.openstack.org
> > https://review.openstack.org/#/admin/groups/270,members
> > I advice you to ask for such a permission in an IRC meeting for
> > third-party CI maintainers:
> > https://wiki.openstack.org/wiki/Meetings/ThirdParty
> > But you still won't be able to vote on other projects, except the sandbox.
> >
> >
> >
> >
> > (patch url: https://review.openstack.org/#/c/222049/
> >  ,
> >
> > CI name:  Fnst OpenStackTest CI)
> >
> >
> >
> > Although I have already added the "verified" label into the
> > layout.yaml , under the check pipeline, it does not work yet.
> >
> >
> >
> > And my configuration info is setted as follows:
> >
> > Layout.yaml
> >
> > ---
> >
> > pipelines:
> >
> >   - name: check
> >
> >trigger:
> >
> >  gerrit:
> >
> >   - event: patchset-created
> >
> >   - event: change-restored
> >
> >   - event: comment-added
> >
> > ...
> >
> >success:
> >
> > gerrit:
> >
> >   verified: 1
> >
> >failure:
> >
> > gerrit:
> >
> >   verified: -1
> >
> >
> >
> > jobs:
> >
> >- name: noop-check-communication
> >
> >   parameter-function: reusable_node
> >
> > projects:
> >
> > - name: openstack-dev/sandbox
> >
> >- noop-check-communication
> >
> > ---
> >
> >
> >
> >
> >
> > And the projects.yaml of Jenkins job:
> >
> > ---
> >
> > - project:
> >
> > name: sandbox
> >
> > jobs:
> >
> >   - noop-check-communication:
> >
> >  node: 'devstack_slave || devstack-precise-check || d-p-c'
> >
> > ...
> >
> > ---
> >
> >
> >
> > Could anyone help me? Thanks in advance.
> >
> >
> >
> > Xiexs
> >
> >
> >
> >
> >
> >
> >
> >
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de
> > v
> >
> >
> 
> 
> 
> __
> 

Re: [openstack-dev] [Ironic] There is a function to display the VGA emulation screen of BMC in the baremetal node on the Horizon?

[Lucas Alvares Gomes]

Hi,

> We are investigating how to display on the Horizon a VGA
> emulation screen of BMC in the bare metal node that has been
> deployed by Ironic.
> If it was already implemented, I thought that the connection
> information of a VNC or SPICE server (converted if necessary)
> for a VGA emulation screen of BMC is returned as the stdout of
> the "nova get-*-console".
> However, we were investigating how to configure Ironic and so
> on, but we could not find a way to do so.
> I tried to search roughly the implementation of such a process
> in the source code of Ironic, but it was not found.
>
> The current Ironic, I think such features are not implemented.
> However, is this correct?
>

A couple of drivers in Ironic supports web console (shellinabox), you
can take a look docs to see how to enable and use it:
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#configure-node-web-console

Hope that helps,
Lucas

__
OpenStack Development Mailing 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][lbaas] Is SSL offload config possible using non "admin" tenant?

[Vijay Venkatachalam]

Hi,
  Has anyone tried configuring SSL Offload as a tenant?
  During listener creation there is an error thrown saying 'could 
not locate/find container'.
  The lbaas plugin is not able to fetch the tenant's certificate.

  From the code it looks like the lbaas plugin is tyring to connect 
to barbican with keystone details provided in neutron.conf
  Which is by default username = "admin" and tenant_name ="admin".
  This means lbaas plugin is looking for tenant's ceritifcate in 
"admin" tenant, which it will never be able to find.

  What is the procedure for the lbaas plugin to get hold of the 
tenant's certificate?

  Assuming "admin" user has access to all tenant's certificates. 
Should the lbaas plugin connect to barbican with username='admin' and 
tenant_name =  listener's tenant_name?

Is this, the way forward ? *OR* Am I missing something?


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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[David Chadwick]

On 11/09/2015 14:32, Rich Megginson wrote:
> On 09/11/2015 04:17 AM, David Chadwick wrote:
>> Whichever approach is adopted you need to consider the future and the
>> longer term objective of moving to fully hierarchical names. I believe
>> the current Keystone approach is only an interim one, as it only
>> supports partial hierarchies. Fully hierarchical names has been
>> discussed in the Keystone group, but I believe that this has been
>> shelved until later in order to get a quick fix released now.
> 
> Can you explain more about "fully hierarchical names"?  What is the
> string representation?

sorry no because there was no agreement on it
david

> 
>>
>> regards
>>
>> David
>>
>> On 11/09/2015 08:03, Gilles Dubreuil wrote:
>>> Hi,
>>>
>>> Today in the #openstack-puppet channel a discussion about the pro and
>>> cons of using domain parameter for Keystone V3 has been left opened.
>>>
>>> The context
>>> 
>>> Domain names are needed in Openstack Keystone V3 for identifying users
>>> or groups (of users) within different projects (tenant).
>>> Users and groups are uniquely identified within a domain (or a realm as
>>> opposed to project domains).
>>> Then projects have their own domain so users or groups can be assigned
>>> to them through roles.
>>>
>>> In Kilo, Keystone V3 have been introduced as an experimental feature.
>>> Puppet providers such as keystone_tenant, keystone_user,
>>> keystone_role_user have been adapted to support it.
>>> Also new ones have appeared (keystone_domain) or are their way
>>> (keystone_group, keystone_trust).
>>> And to be backward compatible with V2, the default domain is used when
>>> no domain is provided.
>>>
>>> In existing providers such as keystone_tenant, the domain can be either
>>> part of the name or provided as a parameter:
>>>
>>> A. The 'composite namevar' approach:
>>>
>>> keystone_tenant {'projectX::domainY': ... }
>>>   B. The 'meaningless name' approach:
>>>
>>>keystone_tenant {'myproject': name='projectX', domain=>'domainY',
>>> ...}
>>>
>>> Notes:
>>>   - Actually using both combined should work too with the domain
>>> supposedly overriding the name part of the domain.
>>>   - Please look at [1] this for some background between the two
>>> approaches:
>>>
>>> The question
>>> -
>>> Decide between the two approaches, the one we would like to retain for
>>> puppet-keystone.
>>>
>>> Why it matters?
>>> ---
>>> 1. Domain names are mandatory in every user, group or project. Besides
>>> the backward compatibility period mentioned earlier, where no domain
>>> means using the default one.
>>> 2. Long term impact
>>> 3. Both approaches are not completely equivalent which different
>>> consequences on the future usage.
>>> 4. Being consistent
>>> 5. Therefore the community to decide
>>>
>>> The two approaches are not technically equivalent and it also depends
>>> what a user might expect from a resource title.
>>> See some of the examples below.
>>>
>>> Because OpenStack DB tables have IDs to uniquely identify objects, it
>>> can have several objects of a same family with the same name.
>>> This has made things difficult for Puppet resources to guarantee
>>> idem-potency of having unique resources.
>>> In the context of Keystone V3 domain, hopefully this is not the case for
>>> the users, groups or projects but unfortunately this is still the case
>>> for trusts.
>>>
>>> Pros/Cons
>>> --
>>> A.
>>>Pros
>>>  - Easier names
>>>Cons
>>>  - Titles have no meaning!
>>>  - Cases where 2 or more resources could exists
>>>  - More difficult to debug
>>>  - Titles mismatch when listing the resources (self.instances)
>>>
>>> B.
>>>Pros
>>>  - Unique titles guaranteed
>>>  - No ambiguity between resource found and their title
>>>Cons
>>>  - More complicated titles
>>>
>>> Examples
>>> --
>>> = Meaningless name example 1=
>>> Puppet run:
>>>keystone_tenant {'myproject': name='project_A',
>>> domain=>'domain_1', ...}
>>>
>>> Second run:
>>>keystone_tenant {'myproject': name='project_A',
>>> domain=>'domain_2', ...}
>>>
>>> Result/Listing:
>>>
>>>keystone_tenant { 'project_A::domain_1':
>>>  ensure  => 'present',
>>>  domain  => 'domain_1',
>>>  enabled => 'true',
>>>  id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
>>>}
>>> keystone_tenant { 'project_A::domain_2':
>>>  ensure  => 'present',
>>>  domain  => 'domain_2',
>>>  enabled => 'true',
>>>  id  => '4b8255591949484781da5d86f2c47be7',
>>>}
>>>
>>> = Composite name example 1  =
>>> Puppet run:
>>>keystone_tenant {'project_A::domain_1', ...}
>>>
>>> Second run:
>>>keystone_tenant {'project_A::domain_2', ...}
>>>
>>> # Result/Listing
>>>keystone_tenant { 'project_A::domain_1':
>>>  ensure  => 'present',
>>>  domain  => 'domain_1',
>>>  enabled => 'true',
>>>  id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
>>> }
>>>

Re: [openstack-dev] [devstack][keystone][ironic] Use only Keystone v3 API in DevStack

[Dolph Mathews]

On Fri, Sep 11, 2015 at 2:55 PM, Yee, Guang  wrote:

> Can you please elaborate on "granularity of policy support within
> Ironic."? Is there a blueprint/etherpad we can take a look?
>

See the lack of granularity expressed by Ironic's current policy file:


https://github.com/openstack/ironic/blob/5671e7c2df455f97ef996c47c9c4f461a82e1c38/etc/ironic/policy.json


>
>
> Guang
>
>
> -Original Message-
> From: Devananda van der Veen [mailto:devananda@gmail.com]
> Sent: Friday, September 11, 2015 10:25 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [devstack][keystone][ironic] Use only
> Keystone v3 API in DevStack
>
> We (the Ironic team) have talked a couple times about keystone /v3 support
> and about improving the granularity of policy support within Ironic. No one
> stepped up to work on these specifically, and they weren't prioritized
> during Liberty ... but I think everyone agreed that we should get on with
> the keystone v3 relatively soon.
>
> If Ironic is the only integrated project that doesn't support v3 yet, then
> yea, we should get on that as soon as M opens.
>
> -Devananda
>
> On Fri, Sep 11, 2015 at 9:45 AM, Davanum Srinivas 
> wrote:
> > Hi,
> >
> > Short story/question:
> > Is keystone /v3 support important to the ironic team? For Mitaka i guess?
> >
> > Long story:
> > The previous discussion - guidance from keystone team on magnum
> > (http://markmail.org/message/jchf2vj752jdzfet) motivated me to dig
> > into the experimental job we have in devstack for full keystone v3 api
> > and ended up with this review.
> >
> > https://review.openstack.org/#/c/221300/
> >
> > So essentially that rips out v2 keystone pipeline *except* for ironic
> jobs.
> > as ironic has some hard-coded dependencies to keystone /v2 api. I've
> > logged a bug here:
> > https://bugs.launchpad.net/ironic/+bug/1494776
> >
> > Note that review above depends on Jamie's tempest patch which had some
> > hard coded /v2 dependency as well
> > (https://review.openstack.org/#/c/214987/)
> >
> > follow up question:
> > Does anyone know of anything else that does not work with /v3?
> >
> > Thanks,
> > Dims
> >
> > --
> > 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
>
> __
> OpenStack Development Mailing 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] [UX] Creating acount at Invision

[Hossein Zabolzadeh]

Hi,
I want to have an account at Invision.
Thanks to someone with right priviledge to create a new account for me
there.
I sent a request to Horizon IRC channel, but it yields no result.
__
OpenStack Development Mailing 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][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Rich Megginson]

On 09/11/2015 01:03 AM, Gilles Dubreuil wrote:

Hi,

Today in the #openstack-puppet channel a discussion about the pro and
cons of using domain parameter for Keystone V3 has been left opened.

The context

Domain names are needed in Openstack Keystone V3 for identifying users
or groups (of users) within different projects (tenant).
Users and groups are uniquely identified within a domain (or a realm as
opposed to project domains).
Then projects have their own domain so users or groups can be assigned
to them through roles.

In Kilo, Keystone V3 have been introduced as an experimental feature.
Puppet providers such as keystone_tenant, keystone_user,
keystone_role_user have been adapted to support it.
Also new ones have appeared (keystone_domain) or are their way
(keystone_group, keystone_trust).
And to be backward compatible with V2, the default domain is used when
no domain is provided.

In existing providers such as keystone_tenant, the domain can be either
part of the name or provided as a parameter:

A. The 'composite namevar' approach:

keystone_tenant {'projectX::domainY': ... }
  B. The 'meaningless name' approach:

   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}

Notes:
  - Actually using both combined should work too with the domain
supposedly overriding the name part of the domain.
  - Please look at [1] this for some background between the two approaches:

The question
-
Decide between the two approaches, the one we would like to retain for
puppet-keystone.

Why it matters?
---
1. Domain names are mandatory in every user, group or project. Besides
the backward compatibility period mentioned earlier, where no domain
means using the default one.
2. Long term impact
3. Both approaches are not completely equivalent which different
consequences on the future usage.
4. Being consistent
5. Therefore the community to decide

The two approaches are not technically equivalent and it also depends
what a user might expect from a resource title.
See some of the examples below.

Because OpenStack DB tables have IDs to uniquely identify objects, it
can have several objects of a same family with the same name.
This has made things difficult for Puppet resources to guarantee
idem-potency of having unique resources.
In the context of Keystone V3 domain, hopefully this is not the case for
the users, groups or projects but unfortunately this is still the case
for trusts.

Pros/Cons
--
A.
   Pros
 - Easier names
   Cons
 - Titles have no meaning!
 - Cases where 2 or more resources could exists
 - More difficult to debug
 - Titles mismatch when listing the resources (self.instances)

B.
   Pros
 - Unique titles guaranteed
 - No ambiguity between resource found and their title
   Cons
 - More complicated titles

Examples
--
= Meaningless name example 1=
Puppet run:
   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}

Second run:
   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}

Result/Listing:

   keystone_tenant { 'project_A::domain_1':
 ensure  => 'present',
 domain  => 'domain_1',
 enabled => 'true',
 id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
   }
keystone_tenant { 'project_A::domain_2':
 ensure  => 'present',
 domain  => 'domain_2',
 enabled => 'true',
 id  => '4b8255591949484781da5d86f2c47be7',
   }

= Composite name example 1  =
Puppet run:
   keystone_tenant {'project_A::domain_1', ...}

Second run:
   keystone_tenant {'project_A::domain_2', ...}

# Result/Listing
   keystone_tenant { 'project_A::domain_1':
 ensure  => 'present',
 domain  => 'domain_1',
 enabled => 'true',
 id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
}
   keystone_tenant { 'project_A::domain_2':
 ensure  => 'present',
 domain  => 'domain_2',
 enabled => 'true',
 id  => '4b8255591949484781da5d86f2c47be7',
}

= Meaningless name example 2  =
Puppet run:
   keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}
   keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',
description=>'blah'...}

Result: project_A in domain_1 has a description

= Composite name example 2  =
Puppet run:
   keystone_tenant {'project_A::domain_1', ...}
   keystone_tenant {'project_A::domain_1', description => 'blah', ...}

Result: Error because the resource must be unique within a catalog

My vote

I would love to have the approach A for easier name.
But I've seen the challenge of maintaining the providers behind the
curtains and the confusion it creates with name/titles and when not sure
about the domain we're dealing with.
Also I believe that supporting self.instances consistently with
meaningful name is saner.
Therefore I vote B


+1

Although, in my limited testing, I have not been able to get this to 
work with Puppet 3.8.  I've been following the link below to create a 

Re: [openstack-dev] [devstack][keystone][ironic] Use only Keystone v3 API in DevStack

[Yee, Guang]

Can you please elaborate on "granularity of policy support within Ironic."? Is 
there a blueprint/etherpad we can take a look?


Guang


-Original Message-
From: Devananda van der Veen [mailto:devananda@gmail.com] 
Sent: Friday, September 11, 2015 10:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack][keystone][ironic] Use only Keystone v3 
API in DevStack

We (the Ironic team) have talked a couple times about keystone /v3 support and 
about improving the granularity of policy support within Ironic. No one stepped 
up to work on these specifically, and they weren't prioritized during Liberty 
... but I think everyone agreed that we should get on with the keystone v3 
relatively soon.

If Ironic is the only integrated project that doesn't support v3 yet, then yea, 
we should get on that as soon as M opens.

-Devananda

On Fri, Sep 11, 2015 at 9:45 AM, Davanum Srinivas  wrote:
> Hi,
>
> Short story/question:
> Is keystone /v3 support important to the ironic team? For Mitaka i guess?
>
> Long story:
> The previous discussion - guidance from keystone team on magnum
> (http://markmail.org/message/jchf2vj752jdzfet) motivated me to dig 
> into the experimental job we have in devstack for full keystone v3 api 
> and ended up with this review.
>
> https://review.openstack.org/#/c/221300/
>
> So essentially that rips out v2 keystone pipeline *except* for ironic jobs.
> as ironic has some hard-coded dependencies to keystone /v2 api. I've 
> logged a bug here:
> https://bugs.launchpad.net/ironic/+bug/1494776
>
> Note that review above depends on Jamie's tempest patch which had some 
> hard coded /v2 dependency as well 
> (https://review.openstack.org/#/c/214987/)
>
> follow up question:
> Does anyone know of anything else that does not work with /v3?
>
> Thanks,
> Dims
>
> --
> 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

__
OpenStack Development Mailing 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] [app-catalog] PTL Candidacy

[Christopher Aedo]

It's time for the Community App Catalog to go through an official
election cycle, and I'm putting my name in for PTL.  I've been filling
that role provisionally since before the App Catalog was launched at
the Vancouver summit, and I would like to continue service as PTL
officially.  Now that we've joined the Big Tent[1], having a committed
leader is more important than ever :) .

I believe the App Catalog has tremendous potential for helping the
end-users of OpenStack clouds find and share things they can deploy on
those clouds.  To that end, I've been working with folks on extending
the types of assets that can live in the catalog and also trying to
make finding and consuming those assets easier.

Since we announced the Community App Catalog I've done everything I
could to deliver on the "community" part.  With the help of the
OpenStack Infra team, we moved the site to OpenStack infrastructure as
quickly as possible.  All planning and coordination efforts have
happened on IRC (#openstack-app-catalog), the dev and operators
mailing list, and during the weekly IRC meetings[2].  I've also been
working to get more people engaged and involved with the Community App
Catalog project while attempting to raise the profile and exposure
whenever possible.

Speaking of community, I know being part of the OpenStack community at
a broad level is one of the most important things for a PTL.  On that
front I'm active and always available on IRC (docaedo), and do my best
to stay on top of all the traffic on the dev mailing list.  I also
work with Richard Raseley to organize the OpenStack meetup in Portland
in order to reach, educate (and entertain) people who want to learn
more about OpenStack.

The next big thing we will do for the Community App Catalog is to
build out the backend so it becomes a more engaging experience for the
users, as well as makes it easier for other projects to contribute and
consume the assets.  In addition to the Horizon plugin[3][4] (check it
out with devstack, it's pretty cool!) we are thinking through the API
side of this and will eventually contribute the code to search, fetch
and push from the OpenStack Client.

All of this is to say that I'm eager and proud to serve as the
Community App Catalog PTL for the next six months if you'll have me!

[1] https://review.openstack.org/#/c/217957/
[2] https://wiki.openstack.org/wiki/Meetings/app-catalog
[3] https://github.com/stackforge/apps-catalog-ui
[4] https://github.com/openstack/app-catalog-ui

__
OpenStack Development Mailing 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][TC] 'team:danger-not-diverse tag' and my concerns

[Joshua Harlow]

Hi all,

I was reading over the TC IRC logs for this week (my weekly reading) and 
I just wanted to let my thoughts and comments be known on:


http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309

I feel it's very important to send a positive note for new/upcoming 
projects and libraries... (and for everyone to remember that most 
projects do start off with a small set of backers). So I just wanted to 
try to ensure that we send a positive note with any tag like this that 
gets created and applied and that we all (especially the TC) really 
really considers the negative connotations of applying that tag to a 
project (it may effectively ~kill~ that project).


I would really appreciate that instead of just applying this tag (or 
other similarly named tag to projects) that instead the TC try to 
actually help out projects with those potential tags in the first place 
(say perhaps by actively listing projects that may need more 
contributors from a variety of companies on the openstack blog under say 
a 'HELP WANTED' page or something). I'd much rather have that vs. any 
said tags, because the latter actually tries to help projects, vs just 
stamping them with a 'you are bad, figure out how to fix yourself, 
because you are not diverse' tag.


I believe it is the TC job (in part) to help make the community better, 
and not via tags like this that IMHO actually make it worse; I really 
hope that folks on the TC can look back at their own projects they may 
have created and ask how would their own project have turned out if they 
were stamped with a similar tag...


- 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] [Neutron] Allow for per-subnet dhcp options

[Kyle Mestery]

On Fri, Sep 11, 2015 at 2:04 PM, Jonathan Proulx  wrote:

> I'm hurt that this blue print has seen no love in 18 months:
> https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet
>
>
This BP has no RFE bug or spec filed for it, so it's hard to be on anyone's
radar when it's not following the submission guidelines Neutron has for new
work [1]. I'm sorry this has flown under the radar so far, hopefully it can
rise up with an RFE bug.

[1] http://docs.openstack.org/developer/neutron/policies/blueprints.html


> I need different MTUs and different domians on different subnets.  It
> appears there is still no way to do this other than running a network
> node (or two if I want HA) for each subnet.
>
> Please someone tell me I'm a fool and there's an easy way to do this
> that I failed to find (again)...
>
> -Jon
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] PTL non-candidacy

[Yee, Guang]

Morgan, thanks for all your hard work. It’s been an honor to have you as our 
PTL.

"All the world's a stage,”

Now set back, relax, grab a drink, and enjoy the show. ☺


Guang


From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Sent: Thursday, September 10, 2015 2:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] PTL non-candidacy

As I outlined (briefly) in my recent announcement of changes ( 
https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/ 
) I will not be running for PTL of Keystone this next cycle (Mitaka). The role 
of PTL is a difficult but extremely rewarding job. It has been amazing to see 
both Keystone and OpenStack grow.

I am very pleased with the accomplishments of the Keystone development team 
over the last year. We have seen improvements with Federation, 
Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing, 
releasing a dedicated authentication library, cross-project initiatives around 
improving the Service Catalog, and much, much more. I want to thank each and 
every contributor for the hard work that was put into Keystone and its 
associated projects.

While I will be changing my focus to spend more time on the general needs of 
OpenStack and working on the Public Cloud story, I am confident in those who 
can, and will, step up to the challenges of leading development of Keystone and 
the associated projects. I may be working across more projects, but you can be 
assured I will be continuing to work hard to see the initiatives I helped start 
through. I wish the best of luck to the next PTL.

I guess this is where I get to write a lot more code soon!

See you all (in person) in Tokyo!
--Morgan
__
OpenStack Development Mailing 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] [cinder] Design Summit Topics

[Mike Perez]

Propose your topics:

https://etherpad.openstack.org/p/cinder-mitaka-summit-topics

Next Cinder meeting, we'll discuss them:

https://wiki.openstack.org/wiki/CinderMeetings

--
Mike Perez

__
OpenStack Development Mailing 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] [devstack][keystone][ironic] Use only Keystone v3 API in DevStack

[Devananda van der Veen]

This has been informal discussions at various times around how differently
privileged users might use Ironic for different things. It would be great
if our API supported policy settings that corresponded to, let's say, a
junior support engineer's read-only access, or a DC technician's need to
perform maintenance on a server without granting them admin access to the
whole cloud. Things like that... but nothing formal has been written yet.

On Fri, Sep 11, 2015 at 1:01 PM, Dolph Mathews 
wrote:

>
> On Fri, Sep 11, 2015 at 2:55 PM, Yee, Guang  wrote:
>
>> Can you please elaborate on "granularity of policy support within
>> Ironic."? Is there a blueprint/etherpad we can take a look?
>>
>
> See the lack of granularity expressed by Ironic's current policy file:
>
>
> https://github.com/openstack/ironic/blob/5671e7c2df455f97ef996c47c9c4f461a82e1c38/etc/ironic/policy.json
>
>
>>
>>
>> Guang
>>
>>
>> -Original Message-
>> From: Devananda van der Veen [mailto:devananda@gmail.com]
>> Sent: Friday, September 11, 2015 10:25 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [devstack][keystone][ironic] Use only
>> Keystone v3 API in DevStack
>>
>> We (the Ironic team) have talked a couple times about keystone /v3
>> support and about improving the granularity of policy support within
>> Ironic. No one stepped up to work on these specifically, and they weren't
>> prioritized during Liberty ... but I think everyone agreed that we should
>> get on with the keystone v3 relatively soon.
>>
>> If Ironic is the only integrated project that doesn't support v3 yet,
>> then yea, we should get on that as soon as M opens.
>>
>> -Devananda
>>
>> On Fri, Sep 11, 2015 at 9:45 AM, Davanum Srinivas 
>> wrote:
>> > Hi,
>> >
>> > Short story/question:
>> > Is keystone /v3 support important to the ironic team? For Mitaka i
>> guess?
>> >
>> > Long story:
>> > The previous discussion - guidance from keystone team on magnum
>> > (http://markmail.org/message/jchf2vj752jdzfet) motivated me to dig
>> > into the experimental job we have in devstack for full keystone v3 api
>> > and ended up with this review.
>> >
>> > https://review.openstack.org/#/c/221300/
>> >
>> > So essentially that rips out v2 keystone pipeline *except* for ironic
>> jobs.
>> > as ironic has some hard-coded dependencies to keystone /v2 api. I've
>> > logged a bug here:
>> > https://bugs.launchpad.net/ironic/+bug/1494776
>> >
>> > Note that review above depends on Jamie's tempest patch which had some
>> > hard coded /v2 dependency as well
>> > (https://review.openstack.org/#/c/214987/)
>> >
>> > follow up question:
>> > Does anyone know of anything else that does not work with /v3?
>> >
>> > Thanks,
>> > Dims
>> >
>> > --
>> > 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
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Allow for per-subnet dhcp options

[Jonathan Proulx]

I'm hurt that this blue print has seen no love in 18 months:
https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet

I need different MTUs and different domians on different subnets.  It
appears there is still no way to do this other than running a network
node (or two if I want HA) for each subnet.

Please someone tell me I'm a fool and there's an easy way to do this
that I failed to find (again)...

-Jon

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

[openstack-dev] [nova] How to get notification for new compute node?

[Sarbajit Chatterjee]

Hi,

I wanted to know how I can get a notification event for compute node
addition in OpenStack. I can see a new hypervisor entry gets added after
every compute node is added but, can't find the exchange where I can get
this notification (I can get notifications for VM creation, deletion etc.).
I tried listening to nova exchange but, did not receive this event.

Please help.

Thanks,
Sarbajit
__
OpenStack Development Mailing 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][TC] 'team:danger-not-diverse tag' and my concerns

[Shamail Tahir]

On Fri, Sep 11, 2015 at 3:26 PM, Joshua Harlow  wrote:

> Hi all,
>
> I was reading over the TC IRC logs for this week (my weekly reading) and I
> just wanted to let my thoughts and comments be known on:
>
>
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309
>
> I feel it's very important to send a positive note for new/upcoming
> projects and libraries... (and for everyone to remember that most projects
> do start off with a small set of backers). So I just wanted to try to
> ensure that we send a positive note with any tag like this that gets
> created and applied and that we all (especially the TC) really really
> considers the negative connotations of applying that tag to a project (it
> may effectively ~kill~ that project).
>
> I would really appreciate that instead of just applying this tag (or other
> similarly named tag to projects) that instead the TC try to actually help
> out projects with those potential tags in the first place (say perhaps by
> actively listing projects that may need more contributors from a variety of
> companies on the openstack blog under say a 'HELP WANTED' page or
> something). I'd much rather have that vs. any said tags, because the latter
> actually tries to help projects, vs just stamping them with a 'you are bad,
> figure out how to fix yourself, because you are not diverse' tag.
>
> I believe it is the TC job (in part) to help make the community better,
> and not via tags like this that IMHO actually make it worse; I really hope
> that folks on the TC can look back at their own projects they may have
> created and ask how would their own project have turned out if they were
> stamped with a similar tag...
>

I agree with Josh and, furthermore, maybe a similar "warning" could be
implicitly made by helping the community understand why the
"diverse-affiliation" tag matters.  If we (through education on tags in
general) stated that the reason diverse-affiliation matters, amongst other
things, is because it shows that the project can potentially survive a
single contributor changing their involvement then wouldn't that achieve
the same purpose of showing stability/mindshare/collaboration for projects
with diverse-affiliation tag (versus those that don't have it) and make
them more "preferred" in a sense?

Thanks,
Shamail


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



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing 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][TC] 'team:danger-not-diverse tag' and my concerns

[Vipul Sabhaya]

Thanks for starting this thread Josh.

On Fri, Sep 11, 2015 at 12:26 PM, Joshua Harlow 
wrote:

> Hi all,
>
> I was reading over the TC IRC logs for this week (my weekly reading) and I
> just wanted to let my thoughts and comments be known on:
>
>
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309
>
> I feel it's very important to send a positive note for new/upcoming
> projects and libraries... (and for everyone to remember that most projects
> do start off with a small set of backers). So I just wanted to try to
> ensure that we send a positive note with any tag like this that gets
> created and applied and that we all (especially the TC) really really
> considers the negative connotations of applying that tag to a project (it
> may effectively ~kill~ that project).
>
> Completely agree. Projects that don’t automatically fit into the
‘stater-kit’ type of tag (e.g. Cue) are going to take longer to really
build a community.  It doesn’t mean that the project isn’t active, or that
the team is not willing to fix bugs, or that operators should be afraid to
run it.


> I would really appreciate that instead of just applying this tag (or other
> similarly named tag to projects) that instead the TC try to actually help
> out projects with those potential tags in the first place (say perhaps by
> actively listing projects that may need more contributors from a variety of
> companies on the openstack blog under say a 'HELP WANTED' page or
> something). I'd much rather have that vs. any said tags, because the latter
> actually tries to help projects, vs just stamping them with a 'you are bad,
> figure out how to fix yourself, because you are not diverse' tag.
>
>
+1.  If the TC can play a role in helping projects build their community, a
lot more of the smaller projects would be much more successful.


> I believe it is the TC job (in part) to help make the community better,
> and not via tags like this that IMHO actually make it worse; I really hope
> that folks on the TC can look back at their own projects they may have
> created and ask how would their own project have turned out if they were
> stamped with a similar tag...
>
> - 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
>
__
OpenStack Development Mailing 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] Install fuel-libraryX.Y as a package on slave nodes

[Andrey Danin]

I support this proposal but I just wanted to mention that we'll lose an
easy way to develop manifests. I agree that manifests in this case have no
difference with Neutron code, for instance. But anyway I +1 this,
especially with Vova Kuklin's additions.

On Thu, Sep 10, 2015 at 12:25 PM, Vladimir Kuklin 
wrote:

> Folks
>
> I have a strong +1 for the proposal to decouple master node and slave
> nodes.
> Here are the stregnths of this approach
> 1) We can always decide which particular node runs which particular set of
> manifests. This will allow us to do be able to apply/roll back changes
> node-by-node. This is very important from operations perspective.
> 2) We can decouple master and slave nodes manifests and not drag new
> library version onto the master node when it is not needed. This allows us
> to decrease probability of regressions
> 3) This makes life easier for the user - you just run 'apt-get/yum
> install' instead of some difficult to digest `mco` command.
>
> The only weakness that I see here is on mentioned by Andrey. I think we
> can fix it by providing developers with clean and simple way of building
> library package on the fly. This will make developers life easier enough to
> work with proposed approach.
>
> Also, we need to provide ways for better UX, like provide one button/api
> call for:
>
> 1) update all manifests on particular nodes (e.g. all or only a part of
> nodes of the cluster) to particular version
> 2)  revert all manifests back to the version which is provided by the
> particular GA release
> 3) 
>
> So far I would mark need for simple package-building system for developer
> as a dependency for the proposed change, but I do not see any other way
> than proceeding with it.
>
>
>
> On Thu, Sep 10, 2015 at 11:50 AM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Oleg,
>>
>> Alex gave a perfect example regarding support folks when they need to fix
>> something really quick. It's client's choice what to patch or not. You may
>> like it or not, but it's client's choice.
>>
>> On 10 Sep 2015, at 09:33, Oleg Gelbukh  wrote:
>>
>> Alex,
>>
>> I absolutely understand the point you are making about need for
>> deployment engineers to modify things 'on the fly' in customer environment.
>> It's makes things really flexible and lowers the entry barrier for sure.
>>
>> However, I would like to note that in my opinion this kind on 'monkey
>> patching' is actually a bad practice for any environments other than dev
>> ones. It immediately leads to emergence of unsupportable frankenclouds. I
>> would greet any modification to the workflow that will discourage people
>> from doing that.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Wed, Sep 9, 2015 at 5:56 PM, Alex Schultz 
>> wrote:
>>
>>> Hey Vladimir,
>>>
>>>
>>>
 Regarding plugins: plugins are welcome to install specific additional
 DEB/RPM repos on the master node, or just configure cluster to use
 additional onl?ne repos, where all necessary packages (including plugin
 specific puppet manifests) are to be available. Current granular deployment
 approach makes it easy to append specific pre-deployment tasks
 (master/slave does not matter). Correct me if I am wrong.


>>> Don't get me wrong, I think it would be good to move to a fuel-library
>>> distributed via package only.  I'm bringing these points up to indicate
>>> that there is many other things that live in the fuel library puppet path
>>> than just the fuel-library package.  The plugin example is just one place
>>> that we will need to invest in further design and work to move to the
>>> package only distribution.  What I don't want is some partially executed
>>> work that only works for one type of deployment and creates headaches for
>>> the people actually having to use fuel.  The deployment engineers and
>>> customers who actually perform these actions should be asked about
>>> packaging and their comfort level with this type of requirements.  I don't
>>> have a complete understanding of the all the things supported today by the
>>> fuel plugin system so it would be nice to get someone who is more familiar
>>> to weigh in on this idea. Currently plugins are only rpms (no debs) and I
>>> don't think we are building fuel-library debs at this time either.  So
>>> without some work on both sides, we cannot move to just packages.
>>>
>>>
 Regarding flexibility: having several versioned directories with puppet
 modules on the master node, having several fuel-libraryX.Y packages
 installed on the master node makes things "exquisitely convoluted" rather
 than flexible. Like I said, it is flexible enough to use mcollective, plain
 rsync, etc. if you really need to do things manually. But we have
 convenient service (Perestroika) which builds packages in minutes if you
 need. Moreover, In the nearest future (by 8.0) Perestroika will be
 

[openstack-dev] [keystone][ptl] PTL Candidacy

[Steve Martinelli]

Hey everyone,

After contributing consistently to Keystone since the Grizzly release, I'd
like to run for the Keystone PTL position for the Mikata release cycle.

I've been a core contributor to Keystone since Icehouse and have largely
been focused on improving Keystone’s ability to integrate with enterprise
environments. I was a significant contributor to Keystone’s federation
support, adding capabilities such as SAML and OpenID Connect enablement,
Keystone to Keystone federation support hybrid clouds, and I have had the
pleasure of collaborating with folks from CERN, RackSpace, HP, Red Hat, and
U. Kent on all these initiatives. In addition I have added cloud auditing
support to Keystone. In my spare time, I have served as a core contributor
to OpenStack Client, Oslo Policy, Oslo Cache and pyCADF. I’ve also
contributed small patches to various other OpenStack projects, such as
Docs, Horizon, Oslo, Infra, DevStack and whatever else was needed.

All of this would be for not if it wasn’t without the exceptional Keystone
core team and its extended team. They are truly fantastic folks, and I’ve
been honored to serve under Morgan and Dolph for the last two and a half
years. Thanks to their mentoring I feel this is the right time for me to
serve as PTL. I am fortunate enough to work for an employer that would
allow me to focus 100% of my time on the role of PTL.

I've also helped many new developers contribute to OpenStack and Keystone,
and have always tried to be available to other OpenStack teams to ensure
the other projects have the support from Keystone they need in order to
succeed.

Some of my goals for the Mikata cycle are:
  - Continue our track record of striving to be an extremely stable project
  - Stride to make v3 the go-to API and finally deprecate v2.0!
  - Improvements on the federated identity use-cases
  - Continue the work being done in Hierarchical multi-tenancy and Reseller
  - Release a version of keystoneclient that no longer includes the
session/auth/CLI code
  - General cleanup and paying down technical debt:
- Deprecate PKI tokens in favor of Fernet tokens
- Remove the concept of extensions, and instead mark features as
experimental or stable
- Create a functional test suite for more advanced Keystone
configurations

Finally, I think it’s important that as PTL time is spent on non-technical
duties such as improving the growth and vitality of the OpenStack community
in the following ways:
  - Actively seek out the input and feedback from operators and deployers
  - Mentoring others to become future core contributor and project team
leads
  - Ensuring I act as a point of contact for other OpenStack projects
  - Continue to foster the healthy environment we have created in the
Keystone team and OpenStack as a whole

Thanks,

Steve Martinelli
OpenStack Keystone Core
__
OpenStack Development Mailing 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] PTL Non-Candidacy

[Paul Michali]

You've done (are doing) a great job as PTL Kyle! Many thanks for all your
hard work in leaving the camp-site in better shape than when you got there
:)



On Fri, Sep 11, 2015 at 6:12 PM Eichberger, German <
german.eichber...@hpe.com> wrote:

> I am with Kevin — we will just write you into the ballot!
>
> Kyle, you rock! Thanks for all the support and help — and hit me up if you
> are short on gin :-)
>
> German
>
>
> From: Kevin Benton >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Date: Friday, September 11, 2015 at 2:35 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Subject: Re: [openstack-dev] [neutron] PTL Non-Candidacy
>
> This has the works "PTL" and "Candidacy" in the subject. I think that's
> enough to make it on the ballot!
>
> On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery > wrote:
> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.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
>
>
>
>
> --
> Kevin Benton
>
> __
> OpenStack Development Mailing 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][TC] 'team:danger-not-diverse tag' and my concerns

[Jim Meyer]

On Sep 11, 2015, at 12:45 PM, Shamail Tahir  wrote:
> On Fri, Sep 11, 2015 at 3:26 PM, Joshua Harlow  > wrote:
> Hi all,
> 
> I was reading over the TC IRC logs for this week (my weekly reading) and I 
> just wanted to let my thoughts and comments be known on:
> 
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309
>  
> 
> 
> I feel it's very important to send a positive note for new/upcoming projects 
> and libraries... (and for everyone to remember that most projects do start 
> off with a small set of backers). So I just wanted to try to ensure that we 
> send a positive note with any tag like this that gets created and applied and 
> that we all (especially the TC) really really considers the negative 
> connotations of applying that tag to a project (it may effectively ~kill~ 
> that project).
> 
> I would really appreciate that instead of just applying this tag (or other 
> similarly named tag to projects) that instead the TC try to actually help out 
> projects with those potential tags in the first place (say perhaps by 
> actively listing projects that may need more contributors from a variety of 
> companies on the openstack blog under say a 'HELP WANTED' page or something). 
> I'd much rather have that vs. any said tags, because the latter actually 
> tries to help projects, vs just stamping them with a 'you are bad, figure out 
> how to fix yourself, because you are not diverse' tag.
> 
> I believe it is the TC job (in part) to help make the community better, and 
> not via tags like this that IMHO actually make it worse; I really hope that 
> folks on the TC can look back at their own projects they may have created and 
> ask how would their own project have turned out if they were stamped with a 
> similar tag…

First, strongly agree:

Tags should be positive attributes or encouragement, not negative or 
discouraging. I think they should also be as objectively true as possible. 
Which Monty Taylor said later[1] in the discussion and Jay Pipes reiterated[2].

> I agree with Josh and, furthermore, maybe a similar "warning" could be 
> implicitly made by helping the community understand why the 
> "diverse-affiliation" tag matters.  If we (through education on tags in 
> general) stated that the reason diverse-affiliation matters, amongst other 
> things, is because it shows that the project can potentially survive a single 
> contributor changing their involvement then wouldn't that achieve the same 
> purpose of showing stability/mindshare/collaboration for projects with 
> diverse-affiliation tag (versus those that don't have it) and make them more 
> "preferred" in a sense?

I think I agree with others, most notably Doug Hellman[3] in the TC discussion; 
we need a marker of the other end of the spectrum. The absence of information 
is only significant if you know what’s missing and it’s importance.

Separately, I agree that more education around tags and their importance is 
needed.

I understand the concern is that we want to highlight the need for diversity, 
and I believe that instead of “danger-not-diverse” we’d be better served by 
“increase-diversity” or “needs-diversity” as the other end of the spectrum from 
“diverse-affiliation.” And I’ll go rant on the review now[4]. =]

—j

[1] 
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-378
 

[2] 
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-422
 

[3] 
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-330
 

[4] https://review.openstack.org/#/c/218725/ 



__
OpenStack Development Mailing 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][TC] 'team:danger-not-diverse tag' and my concerns

[gord chung]

On 11/09/2015 3:26 PM, Joshua Harlow wrote:

Hi all,

I was reading over the TC IRC logs for this week (my weekly reading) 
and I just wanted to let my thoughts and comments be known on:


http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309 



I feel it's very important to send a positive note for new/upcoming 
projects and libraries... (and for everyone to remember that most 
projects do start off with a small set of backers). So I just wanted 
to try to ensure that we send a positive note with any tag like this 
that gets created and applied and that we all (especially the TC) 
really really considers the negative connotations of applying that tag 
to a project (it may effectively ~kill~ that project).


I would really appreciate that instead of just applying this tag (or 
other similarly named tag to projects) that instead the TC try to 
actually help out projects with those potential tags in the first 
place (say perhaps by actively listing projects that may need more 
contributors from a variety of companies on the openstack blog under 
say a 'HELP WANTED' page or something). I'd much rather have that vs. 
any said tags, because the latter actually tries to help projects, vs 
just stamping them with a 'you are bad, figure out how to fix 
yourself, because you are not diverse' tag.


I believe it is the TC job (in part) to help make the community 
better, and not via tags like this that IMHO actually make it worse; I 
really hope that folks on the TC can look back at their own projects 
they may have created and ask how would their own project have turned 
out if they were stamped with a similar tag...


completely agree with everything here... i made a comment on the 
patch[1] regarding this and was told the idea was that the purpose of 
the tag was to note the potential fragility of a project if the leading 
company were to decide to pull out. this seems like a valid item to 
track but with that said, the existing wording of the proposal is not that.


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

cheers,

--
gord


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

Re: [openstack-dev] [neutron] PTL Non-Candidacy

[Kevin Benton]

This has the works "PTL" and "Candidacy" in the subject. I think that's
enough to make it on the ballot!

On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery  wrote:

> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.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
>
>


-- 
Kevin Benton
__
OpenStack Development Mailing 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] [UX] Creating acount at Invision

[David Lyle]

Invite sent.

On Fri, Sep 11, 2015 at 2:25 PM, Hossein Zabolzadeh
 wrote:
> Hi,
> I want to have an account at Invision.
> Thanks to someone with right priviledge to create a new account for me
> there.
> I sent a request to Horizon IRC channel, but it yields no result.
>
> __
> OpenStack Development Mailing 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] [puppet] PTL Candidacy

[Emilien Macchi]

( Also posted on https://review.openstack.org/222767 )

Moving Puppet OpenStack modules under the big tent was an amazing
opportunity for us to make sure our project remains Open [1].
Liberty was our first cycle where we were part of OpenStack and we can
be proud of what we achieved together [2].

We've built a community coming from two different worlds: developers and
operators. We need to keep that, because I think that's what is making
the difference today when you're deploying OpenStack: you need a short
loop feedback between both worlds.

Being OpenStack is not easy, and we have great challenges
in front of us.

* Documentation
I would like to put emphasis on having more documentation
so we can more easily welcome new contributors and hopefuly get more
adoption.
I truly believe more documentation will help our contributors
to get quickly involved and eventually give a chance to scale-up our team.
Our users deserve more guidance to understand best practices when using
our modules, that should also be part of this effort.

* Continuous Integration
We did a lot of work on CI, on both beaker & integration jobs. I would
like to continue integration work and test more OpenStack modules.
I would like to continue collaboration with Tempest team and keep using
it for testing. I'm also interested by multi-node and upgrade testing,
that would make stronger how we develop the modules.

* Release management
I would like to reach a better release velocity by trying to stay close
to OpenStack releases (especially from packaging).
As soon as major distributions release stable packaging, I think we
should provide a release.

* Community
I would like to continue the collaboration with other projects, mostly
OpenStack Infrastructure (for Continuous Integration work), TripleO,
Fuel, Kolla (container integration), Documentation, Tempest (for
puppet-openstack-integration work) and packagers (Ubuntu Cloud Archive
and RDO teams).
This collaboration is making OpenStack better and is the reason for our
success today. We need to continue that way by coordinating groups and
maintaining good communications.


I had the immense pleasure to lead our team during the last few months
and I would like to continue my role of PTL for the next cycle.
Thank you for your time and consideration,


[1] https://wiki.openstack.org/wiki/Open
[2] http://my1.fr/blog/liberty-cycle-retrospective-in-puppet-openstack/

-- 
Emilien Macchi
https://wiki.openstack.org/wiki/User:Emilienm



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

[openstack-dev] [Keystone] PTL Candidacy: Adam Young

[Adam Young]

My name is Adam Young and I am running for Keystone Project Technical Lead.


Why I am running:  I've been part of this project since it was in 
incubation.  During that time, I've received the benefit of several 
dedicated PTLs.  It is time for me to offer to do the hard work 
necessary to make Keystone successful.


The Keystone project gets its name from the block on an arch that is put 
into position to make the whole structure self supporting. Remove any 
piece of the arch and the whole thing collapses.  What is notable about 
a Keystone is that it has the highest degree of pressure of any block in 
the arch.


The Keystone project fills that same role in OpenStack.  It provides the 
means to make OpenStack capable of architectural feats not previously 
possible.  But it also is the highest risk piece from a security 
perspective, and it is here that, as PTL, I will focus my attentions.


My goals for Keystone:

1.  Removing the bearer aspects of tokens
2.  Better delegation mechanisms to scale the management of OpenStack.
3.  Improving stability, scale, and performance.
4.  Simplify integration with external identity sources

As a member of the team, I have been frustrated by our inability to make 
progress on some of these key aspects due to workflow constraints.  As 
PTL, I will look to restructuring the code approval process to increase 
development throughput while increasing the emphasis on quality.


I've been blogging since before I started on Keystone.  It has been one 
of the key ways that I have communicated the design, criticism, and 
techniques essential for Keystone's continued success.  As PTL, I will 
continue to communicate, and to aid the other team members to 
communicate.  Keystone needs to work with the rest of the OpenStack 
project teams.


Here's the most important part;  I'm, going to do this all anyway. It 
does not matter if I am PTL or not, this is how I will work.


I'm hoping by running that I inspire other Keystone Developers to run as 
well.  We've got a great crew, and I am looking forward to being part of 
it in this upcoming release.


__
OpenStack Development Mailing 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] PTL Non-Candidacy

[Eichberger, German]

I am with Kevin — we will just write you into the ballot!

Kyle, you rock! Thanks for all the support and help — and hit me up if you are 
short on gin :-)

German


From: Kevin Benton >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron] PTL Non-Candidacy

This has the works "PTL" and "Candidacy" in the subject. I think that's enough 
to make it on the ballot!

On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery 
> wrote:
I'm writing to let everyone know that I do not plan to run for Neutron PTL for 
a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan 
recently put it in his non-candidacy email [1]. But it goes further than that 
for me. As Flavio put it in his post about "Being a PTL" [2], it's a full time 
job. In the case of Neutron, it's more than a full time job, it's literally an 
always on job.

I've tried really hard over my three cycles as PTL to build a stronger web of 
trust so the project can grow, and I feel that's been accomplished. We have a 
strong bench of future PTLs and leaders ready to go, I'm excited to watch them 
lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered the 
concept of rotating PTL duties with each cycle, I'd like to highly encourage 
Neutron and other projects to do the same. Having a deep bench of leaders 
supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.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




--
Kevin Benton

__
OpenStack Development Mailing 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] PTL Non-Candidacy

[Kyle Mestery]

I'm writing to let everyone know that I do not plan to run for Neutron PTL
for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
recently put it in his non-candidacy email [1]. But it goes further than
that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
full time job. In the case of Neutron, it's more than a full time job, it's
literally an always on job.

I've tried really hard over my three cycles as PTL to build a stronger web
of trust so the project can grow, and I feel that's been accomplished. We
have a strong bench of future PTLs and leaders ready to go, I'm excited to
watch them lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered
the concept of rotating PTL duties with each cycle, I'd like to highly
encourage Neutron and other projects to do the same. Having a deep bench of
leaders supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] PTL non-candidacy

[Rodrigo Duarte]

Thanks Morgan, it was a pleasure to have you contributing as PTL while
working with Keystone.

On Fri, Sep 11, 2015 at 4:52 PM, Yee, Guang  wrote:

> Morgan, thanks for all your hard work. It’s been an honor to have you as
> our PTL.
>
>
>
> "All the world's a stage,”
>
>
>
> Now set back, relax, grab a drink, and enjoy the show. J
>
>
>
>
>
> Guang
>
>
>
>
>
> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
> *Sent:* Thursday, September 10, 2015 2:41 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [keystone] PTL non-candidacy
>
>
>
> As I outlined (briefly) in my recent announcement of changes (
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
> ) I will not be running for PTL of Keystone this next cycle (Mitaka). The
> role of PTL is a difficult but extremely rewarding job. It has been amazing
> to see both Keystone and OpenStack grow.
>
>
>
> I am very pleased with the accomplishments of the Keystone development
> team over the last year. We have seen improvements with Federation,
> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
> releasing a dedicated authentication library, cross-project initiatives
> around improving the Service Catalog, and much, much more. I want to thank
> each and every contributor for the hard work that was put into Keystone and
> its associated projects.
>
>
>
> While I will be changing my focus to spend more time on the general needs
> of OpenStack and working on the Public Cloud story, I am confident in those
> who can, and will, step up to the challenges of leading development of
> Keystone and the associated projects. I may be working across more
> projects, but you can be assured I will be continuing to work hard to see
> the initiatives I helped start through. I wish the best of luck to the next
> PTL.
>
>
>
> I guess this is where I get to write a lot more code soon!
>
>
>
> See you all (in person) in Tokyo!
>
> --Morgan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
MSc in Computer Science
http://rodrigods.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] [neutron] PTL Non-Candidacy

[Brandon Logan]

Kyle,
This news saddens me, but I completely understand.  You've been a great
PTL and I appreciate everything you have done for Neutron.  Enjoy your
new found free time after this.

Thanks,
Brandon
On Fri, 2015-09-11 at 16:12 -0500, Kyle Mestery wrote:
> I'm writing to let everyone know that I do not plan to run for Neutron
> PTL for a fourth cycle. Being a PTL is a rewarding but difficult job,
> as Morgan recently put it in his non-candidacy email [1]. But it goes
> further than that for me. As Flavio put it in his post about "Being a
> PTL" [2], it's a full time job. In the case of Neutron, it's more than
> a full time job, it's literally an always on job.
> 
> I've tried really hard over my three cycles as PTL to build a stronger
> web of trust so the project can grow, and I feel that's been
> accomplished. We have a strong bench of future PTLs and leaders ready
> to go, I'm excited to watch them lead and help them in anyway I can.
> 
> 
> As was said by Zane in a recent email [3], while Heat may have
> pioneered the concept of rotating PTL duties with each cycle, I'd like
> to highly encourage Neutron and other projects to do the same. Having
> a deep bench of leaders supporting each other is important for the
> future of all projects.
> 
> 
> See you all in Tokyo!
> 
> Kyle
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

[Sean Dague]

On 09/10/2015 03:45 PM, Robert Collins wrote:
> On 11 September 2015 at 07:23, Robert Collins  
> wrote:
>> Note that master is pinned:
>>
>> commit aca1a74909d7a2841cd9805b7f57c867a1f74b73
>> Author: Tushar Gohad 
>> Date:   Tue Aug 18 07:55:18 2015 +
>>
>> Restrict PyECLib version to 1.0.7
>>
>> v1.0.9 rev of PyECLib replaces Jerasure with a native EC
>> implementation (liberasurecode_rs_vand) as the default
>> EC scheme.  Going forward, Jerasure will not be bundled
>> with PyPI version of PyECLib as it used to be, until
>> v1.0.7.
>>
>> This is an interim change to Global/Swift requirements
>> until we get v1.0.9 PyECLib released and included in
>> global-requirements and ready patches that change Swift
>> default ec_type (for doc, config samples and unit tests)
>> from "jerasure_rs_vand" to "liberasurecode_rs_vand."
>>
>> Without this change, Swift unit tests will break at gate
>> as soon as PyECLib v1.0.9 lands on PyPI
>>
>> * Swift is the only user of PyECLib at the moment
>>
>> Change-Id: I52180355b95679cbcddd497bbdd9be8e7167a3c7
>>
>>
>> But it appears a matching change was not done to j/k - and the pin
>> hasn't been removed from master.
> 
> I'm going to propose another manual review rule I think: we should not
> permit lower releases to use higher versions of libraries -
> approximately noone tests downgrades of their thing [and while it only
> matters for packages with weird installs / state management things,
> its a glaring hole in our reliability story].

I feel like that's a bad thing to assume of people's systems. What is
the expected behavior of an installer if it discovers installing
OpenStack requires downgrading a library? Halt and catch fire?

It also means we're back to having to pin requirements in stable
branches because that's the only way we can guaruntee this for people.
And that's a thing we specifically wanted to get out of the business of
doing because it let to all kinds of problems.

-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] Fine-grained error reporting via the external API

[Matthew Booth]

On 11/09/15 12:19, Sean Dague wrote:
> On 09/11/2015 05:41 AM, Matthew Booth wrote:
>> I've recently been writing a tool which uses Nova's external API. This
>> is my first time consuming this API, so it has involved a certain amount
>> of discovery. The tool is here for the curious:
>>
>>   https://gist.github.com/mdbooth/163f5fdf47ab45d7addd
>>
>> I have felt hamstrung by the general inability to distinguish between
>> different types of error. For example, if a live migration failed is it
>> because:
>>
>> 1. The compute driver doesn't support support it.
>>
>> 2. This instance requires block storage migration.
>>
>> 3. Something ephemeral.
>>
>> These 3 errors all require different responses:
>>
>> 1. Quit and don't try again.
>>
>> 2. Try again immediately with the block migration argument.[1]
>>
>> 3. Try again in a bit.
>>
>> However, all I have is that I made a BadRequest. I could potentially
>> grep the human readable error message, but the text of that message
>> doesn't form part of the API, and it may be translated in any case. As
>> an API consumer, it seems I can't really tell anything other than 'it
>> didn't work'. More than that requires guesswork, heuristics and inference.
>>
>> I don't think I've missed some source of additional wisdom, but it would
>> obviously be great if I have. Has there ever been any effort to define
>> some contract around more fine-grained error reporting?
>>
>> Thanks,
>>
>> Matt
>>
>> [1] Incidentally, this suggests to me that live migrate should just do
>> this anyway.
> 
> This is an API working group recommendation evolving here. The crux of
> which is going to be a structured json error return document that will
> contain more info. https://review.openstack.org/#/c/167793/

Thanks, Sean, that's exactly what I was looking for. I'll continue this
discussion in that review.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

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

Re: [openstack-dev] [keystone] creating new users with invalid mail addresses possible

[Lance Bragstad]

On Fri, Sep 11, 2015 at 8:04 AM, David Stanek  wrote:

> On Fri, Sep 11, 2015 at 8:26 AM, Christian Berendt 
> wrote:
>
>> At the moment it is possible to create new users with invalid mail
>> addresses. I pasted the output of my test at
>> http://paste.openstack.org/show/456642/. (the listing of invalid mail
>> addresses is available at
>> http://codefool.tumblr.com/post/15288874550/list-of-valid-and-invalid-email-addresses
>> ).
>>
>> Is it intended that addresses are not be validated?
>>
>> Does it makes sense to validate addresses (e.g. with
>> https://github.com/mailgun/flanker)?
>>
>
> I don't know the complete history of this (I'm sure others can chime in
> later), but since Keystone doesn't use the email address for anything it
> was never really considered a first class attribute. It is just something
> we accept and return through the API. It doesn't even have its own column
> in the database.
>

Correct, I believe this is the reason why we don't actually tie the email
address attribute validation into jsonschema [0]. The email address
attribute is just something that is grouped into the 'extra' attributes of
a create user request, so it's treated similarly with jsonschema [1]. I
remember having a few discussions around this with various people, probably
in code review somewhere [2].

I think jsonschema has built-in support that would allow us to validate
email addresses [3]. I think that would plug in pretty naturally to what's
already in keystone.

[0]
https://github.com/openstack/keystone/blob/aa8dc5c9c529c2678933c9b211b4640600e55e3a/keystone/identity/schema.py#L24-L33
[1]
https://github.com/openstack/keystone/blob/aa8dc5c9c529c2678933c9b211b4640600e55e3a/keystone/identity/schema.py#L39

[2] https://review.openstack.org/#/c/132122/6/keystone/identity/schema.py
[3]
http://python-jsonschema.readthedocs.org/en/latest/validate/#validating-formats



> I don't like this for a variety of reasons and we do have a bug[1] for
> fixing this. Last Thursday several of us were discussing making a database
> column for the email address as part of the fix for that bug.
>
> 1. https://bugs.launchpad.net/keystone/+bug/1218682
>
> --
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
> www: http://dstanek.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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Rich Megginson]

On 09/11/2015 04:17 AM, David Chadwick wrote:

Whichever approach is adopted you need to consider the future and the
longer term objective of moving to fully hierarchical names. I believe
the current Keystone approach is only an interim one, as it only
supports partial hierarchies. Fully hierarchical names has been
discussed in the Keystone group, but I believe that this has been
shelved until later in order to get a quick fix released now.


Can you explain more about "fully hierarchical names"?  What is the 
string representation?




regards

David

On 11/09/2015 08:03, Gilles Dubreuil wrote:

Hi,

Today in the #openstack-puppet channel a discussion about the pro and
cons of using domain parameter for Keystone V3 has been left opened.

The context

Domain names are needed in Openstack Keystone V3 for identifying users
or groups (of users) within different projects (tenant).
Users and groups are uniquely identified within a domain (or a realm as
opposed to project domains).
Then projects have their own domain so users or groups can be assigned
to them through roles.

In Kilo, Keystone V3 have been introduced as an experimental feature.
Puppet providers such as keystone_tenant, keystone_user,
keystone_role_user have been adapted to support it.
Also new ones have appeared (keystone_domain) or are their way
(keystone_group, keystone_trust).
And to be backward compatible with V2, the default domain is used when
no domain is provided.

In existing providers such as keystone_tenant, the domain can be either
part of the name or provided as a parameter:

A. The 'composite namevar' approach:

keystone_tenant {'projectX::domainY': ... }
  B. The 'meaningless name' approach:

   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}

Notes:
  - Actually using both combined should work too with the domain
supposedly overriding the name part of the domain.
  - Please look at [1] this for some background between the two approaches:

The question
-
Decide between the two approaches, the one we would like to retain for
puppet-keystone.

Why it matters?
---
1. Domain names are mandatory in every user, group or project. Besides
the backward compatibility period mentioned earlier, where no domain
means using the default one.
2. Long term impact
3. Both approaches are not completely equivalent which different
consequences on the future usage.
4. Being consistent
5. Therefore the community to decide

The two approaches are not technically equivalent and it also depends
what a user might expect from a resource title.
See some of the examples below.

Because OpenStack DB tables have IDs to uniquely identify objects, it
can have several objects of a same family with the same name.
This has made things difficult for Puppet resources to guarantee
idem-potency of having unique resources.
In the context of Keystone V3 domain, hopefully this is not the case for
the users, groups or projects but unfortunately this is still the case
for trusts.

Pros/Cons
--
A.
   Pros
 - Easier names
   Cons
 - Titles have no meaning!
 - Cases where 2 or more resources could exists
 - More difficult to debug
 - Titles mismatch when listing the resources (self.instances)

B.
   Pros
 - Unique titles guaranteed
 - No ambiguity between resource found and their title
   Cons
 - More complicated titles

Examples
--
= Meaningless name example 1=
Puppet run:
   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}

Second run:
   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}

Result/Listing:

   keystone_tenant { 'project_A::domain_1':
 ensure  => 'present',
 domain  => 'domain_1',
 enabled => 'true',
 id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
   }
keystone_tenant { 'project_A::domain_2':
 ensure  => 'present',
 domain  => 'domain_2',
 enabled => 'true',
 id  => '4b8255591949484781da5d86f2c47be7',
   }

= Composite name example 1  =
Puppet run:
   keystone_tenant {'project_A::domain_1', ...}

Second run:
   keystone_tenant {'project_A::domain_2', ...}

# Result/Listing
   keystone_tenant { 'project_A::domain_1':
 ensure  => 'present',
 domain  => 'domain_1',
 enabled => 'true',
 id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
}
   keystone_tenant { 'project_A::domain_2':
 ensure  => 'present',
 domain  => 'domain_2',
 enabled => 'true',
 id  => '4b8255591949484781da5d86f2c47be7',
}

= Meaningless name example 2  =
Puppet run:
   keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}
   keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',
description=>'blah'...}

Result: project_A in domain_1 has a description

= Composite name example 2  =
Puppet run:
   keystone_tenant {'project_A::domain_1', ...}
   keystone_tenant {'project_A::domain_1', description => 'blah', ...}

Result: Error 

Re: [openstack-dev] [keystone] PTL non-candidacy

[David Stanek]

On Thu, Sep 10, 2015 at 5:40 PM, Morgan Fainberg 
wrote:

> While I will be changing my focus to spend more time on the general needs
> of OpenStack and working on the Public Cloud story, I am confident in those
> who can, and will, step up to the challenges of leading development of
> Keystone and the associated projects. I may be working across more
> projects, but you can be assured I will be continuing to work hard to see
> the initiatives I helped start through. I wish the best of luck to the next
> PTL.


It's been an honor and a privilege to work with you. You've done a great
job and I'm sorry to see you go. Fortunately you're not going too far! Good
luck with your future OpenStack adventures!


-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.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] [Ironic] Suggestion to split install guide

[Jim Rollenhagen]

On Fri, Sep 11, 2015 at 10:56:07AM +0200, Dmitry Tantsur wrote:
> Hi all!
> 
> Our install guide is huge, and I've just approved even more text for it.
> WDYT about splitting it into "Basic Install Guide", which will contain bare
> minimum for running ironic and deploying instances, and "Advanced Install
> Guide", which will the following things:
> 1. Using Bare Metal service as a standalone service
> 2. Enabling the configuration drive (configdrive)
> 3. Inspection
> 4. Trusted boot
> 5. UEFI
> 
> Opinions?

+1, our guide is impossibly long. I like the idea of splitting out the
optional bits so folks don't think that it's all required.

// 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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[David Chadwick]

Whichever approach is adopted you need to consider the future and the
longer term objective of moving to fully hierarchical names. I believe
the current Keystone approach is only an interim one, as it only
supports partial hierarchies. Fully hierarchical names has been
discussed in the Keystone group, but I believe that this has been
shelved until later in order to get a quick fix released now.

regards

David

On 11/09/2015 08:03, Gilles Dubreuil wrote:
> Hi,
> 
> Today in the #openstack-puppet channel a discussion about the pro and
> cons of using domain parameter for Keystone V3 has been left opened.
> 
> The context
> 
> Domain names are needed in Openstack Keystone V3 for identifying users
> or groups (of users) within different projects (tenant).
> Users and groups are uniquely identified within a domain (or a realm as
> opposed to project domains).
> Then projects have their own domain so users or groups can be assigned
> to them through roles.
> 
> In Kilo, Keystone V3 have been introduced as an experimental feature.
> Puppet providers such as keystone_tenant, keystone_user,
> keystone_role_user have been adapted to support it.
> Also new ones have appeared (keystone_domain) or are their way
> (keystone_group, keystone_trust).
> And to be backward compatible with V2, the default domain is used when
> no domain is provided.
> 
> In existing providers such as keystone_tenant, the domain can be either
> part of the name or provided as a parameter:
> 
> A. The 'composite namevar' approach:
> 
>keystone_tenant {'projectX::domainY': ... }
>  B. The 'meaningless name' approach:
> 
>   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}
> 
> Notes:
>  - Actually using both combined should work too with the domain
> supposedly overriding the name part of the domain.
>  - Please look at [1] this for some background between the two approaches:
> 
> The question
> -
> Decide between the two approaches, the one we would like to retain for
> puppet-keystone.
> 
> Why it matters?
> ---
> 1. Domain names are mandatory in every user, group or project. Besides
> the backward compatibility period mentioned earlier, where no domain
> means using the default one.
> 2. Long term impact
> 3. Both approaches are not completely equivalent which different
> consequences on the future usage.
> 4. Being consistent
> 5. Therefore the community to decide
> 
> The two approaches are not technically equivalent and it also depends
> what a user might expect from a resource title.
> See some of the examples below.
> 
> Because OpenStack DB tables have IDs to uniquely identify objects, it
> can have several objects of a same family with the same name.
> This has made things difficult for Puppet resources to guarantee
> idem-potency of having unique resources.
> In the context of Keystone V3 domain, hopefully this is not the case for
> the users, groups or projects but unfortunately this is still the case
> for trusts.
> 
> Pros/Cons
> --
> A.
>   Pros
> - Easier names
>   Cons
> - Titles have no meaning!
> - Cases where 2 or more resources could exists
> - More difficult to debug
> - Titles mismatch when listing the resources (self.instances)
> 
> B.
>   Pros
> - Unique titles guaranteed
> - No ambiguity between resource found and their title
>   Cons
> - More complicated titles
> 
> Examples
> --
> = Meaningless name example 1=
> Puppet run:
>   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}
> 
> Second run:
>   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}
> 
> Result/Listing:
> 
>   keystone_tenant { 'project_A::domain_1':
> ensure  => 'present',
> domain  => 'domain_1',
> enabled => 'true',
> id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
>   }
>keystone_tenant { 'project_A::domain_2':
> ensure  => 'present',
> domain  => 'domain_2',
> enabled => 'true',
> id  => '4b8255591949484781da5d86f2c47be7',
>   }
> 
> = Composite name example 1  =
> Puppet run:
>   keystone_tenant {'project_A::domain_1', ...}
> 
> Second run:
>   keystone_tenant {'project_A::domain_2', ...}
> 
> # Result/Listing
>   keystone_tenant { 'project_A::domain_1':
> ensure  => 'present',
> domain  => 'domain_1',
> enabled => 'true',
> id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
>}
>   keystone_tenant { 'project_A::domain_2':
> ensure  => 'present',
> domain  => 'domain_2',
> enabled => 'true',
> id  => '4b8255591949484781da5d86f2c47be7',
>}
> 
> = Meaningless name example 2  =
> Puppet run:
>   keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}
>   keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',
> description=>'blah'...}
> 
> Result: project_A in domain_1 has a description
> 
> = Composite name example 2  =
> Puppet run:
>   keystone_tenant {'project_A::domain_1', ...}
>   

[openstack-dev] [ceilometer] using entry_points for configuration considered harmful

[Chris Dent]

Several weeks ago I made a little tool call pollman[1] that demonstrates
pollsters plugins that are outside the ceilometer python namespace. I
was going to use it in my portion of a summit talk to show just how
incredibly easy it is to create custom pollsters. After getting the
basics working and testing it out I forgot all about it until reminded
about it in a way that I think demonstrates a fairly significant problem
in the way that ceilometer (and perhaps other OpenStack projects) manage
extensions.

Ceilometer is now frozen for Liberty so I've been doing a lot of
devstack runs to find and fix bugs. And what do I spy with my little
cli but:

$ ceilometer meter-list
[...]
| weather.temperature  | gauge  | C  | 2172797  | pollman | pollman |

$ ceilometer sample-list -q resource_id=2172797 --limit 1
[...]
| 0b667812-586a-11e5-9568-3417ebd4f75d | 2172797 | weather.temperature 
| gauge | 18.62  | C| 2015-09-11T09:46:58.571000 |

It's 18.62 C in Newquay today. Good to know.

I have not configured Ceilometer to do this. Pollman set
entry_points on ceilometer months ago and they are being used today.

This is really weird to me. I know why it is happening; it is the
designed in behavior that ceilometer pollsters will activate and run all
available pollster plugins (even when there are not resources available)
but goodness me that's not very explicit.

If I want this to stop the most direct thing to do is uninstall pollman.

Sure, I can disable the meters associated with pollman in
pipeline.yaml but to do I've got to go find out what they are. One
way to do that is to go look at the entry_points, but if I've got
multiple external plugins those entry_points are all over the place.
Not very friendly.

I like entry_points, especially in the way that they allow external
extensions (let's have more of them please!), but we shouldn't be
using them as service configuration[2].

What ideas do people have for being more explicit?

Now that the pollsters are only using the first half of the
pipeline.yaml file it probably makes sense to explore (in Mitaka) a more
explicit polling configuration file, separate from the transformations
described by the pipeline.

[1] https://github.com/cdent/pollman
It gets the temperature for configured locations and saves it as a
sample. Its unfinished because I promptly forgot about it until
reminded as described above.

[2] Yes, I'm conscious of the fact that this problem goes away if I
always use clean installs or virtualenvs but is that something we
always want to require? It would be handy to be able to have a
generic vm image which is "the ceilometer polling machine" and has
all the pollsters installed but not all started by default.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing 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] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Julien Danjou]

On Fri, Sep 11 2015, Julien Danjou wrote:

> Which version are you testing? The master branch has no support for

s/no/now/

-- 
Julien Danjou
-- Free Software hacker
-- http://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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 11/09/15 20:17, David Chadwick wrote:
> Whichever approach is adopted you need to consider the future and the
> longer term objective of moving to fully hierarchical names. I believe
> the current Keystone approach is only an interim one, as it only
> supports partial hierarchies. Fully hierarchical names has been
> discussed in the Keystone group, but I believe that this has been
> shelved until later in order to get a quick fix released now.
> 
> regards
> 
> David
> 

Thanks David,

That's interesting.
So sub projects are pushing the issue further down.
And maybe one day sub domains and sub users?

keystone_role_user {
'user.subuser::domain1@project.subproject.subsubproject::domain2':
roles => [...]
}

or

keystone_role_user {'user.subuser':
  user_domain => 'domain1',
  tenant => 'project.subproject',
  tenant_domain => 'domain2',
  roles => [...]
}

I tend to think the domain must stick with the name it's associated
with, otherwise we have to say 'here the domain for this and that, etc'.



> On 11/09/2015 08:03, Gilles Dubreuil wrote:
>> Hi,
>>
>> Today in the #openstack-puppet channel a discussion about the pro and
>> cons of using domain parameter for Keystone V3 has been left opened.
>>
>> The context
>> 
>> Domain names are needed in Openstack Keystone V3 for identifying users
>> or groups (of users) within different projects (tenant).
>> Users and groups are uniquely identified within a domain (or a realm as
>> opposed to project domains).
>> Then projects have their own domain so users or groups can be assigned
>> to them through roles.
>>
>> In Kilo, Keystone V3 have been introduced as an experimental feature.
>> Puppet providers such as keystone_tenant, keystone_user,
>> keystone_role_user have been adapted to support it.
>> Also new ones have appeared (keystone_domain) or are their way
>> (keystone_group, keystone_trust).
>> And to be backward compatible with V2, the default domain is used when
>> no domain is provided.
>>
>> In existing providers such as keystone_tenant, the domain can be either
>> part of the name or provided as a parameter:
>>
>> A. The 'composite namevar' approach:
>>
>>keystone_tenant {'projectX::domainY': ... }
>>  B. The 'meaningless name' approach:
>>
>>   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}
>>
>> Notes:
>>  - Actually using both combined should work too with the domain
>> supposedly overriding the name part of the domain.
>>  - Please look at [1] this for some background between the two approaches:
>>
>> The question
>> -
>> Decide between the two approaches, the one we would like to retain for
>> puppet-keystone.
>>
>> Why it matters?
>> ---
>> 1. Domain names are mandatory in every user, group or project. Besides
>> the backward compatibility period mentioned earlier, where no domain
>> means using the default one.
>> 2. Long term impact
>> 3. Both approaches are not completely equivalent which different
>> consequences on the future usage.
>> 4. Being consistent
>> 5. Therefore the community to decide
>>
>> The two approaches are not technically equivalent and it also depends
>> what a user might expect from a resource title.
>> See some of the examples below.
>>
>> Because OpenStack DB tables have IDs to uniquely identify objects, it
>> can have several objects of a same family with the same name.
>> This has made things difficult for Puppet resources to guarantee
>> idem-potency of having unique resources.
>> In the context of Keystone V3 domain, hopefully this is not the case for
>> the users, groups or projects but unfortunately this is still the case
>> for trusts.
>>
>> Pros/Cons
>> --
>> A.
>>   Pros
>> - Easier names
>>   Cons
>> - Titles have no meaning!
>> - Cases where 2 or more resources could exists
>> - More difficult to debug
>> - Titles mismatch when listing the resources (self.instances)
>>
>> B.
>>   Pros
>> - Unique titles guaranteed
>> - No ambiguity between resource found and their title
>>   Cons
>> - More complicated titles
>>
>> Examples
>> --
>> = Meaningless name example 1=
>> Puppet run:
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}
>>
>> Second run:
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}
>>
>> Result/Listing:
>>
>>   keystone_tenant { 'project_A::domain_1':
>> ensure  => 'present',
>> domain  => 'domain_1',
>> enabled => 'true',
>> id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
>>   }
>>keystone_tenant { 'project_A::domain_2':
>> ensure  => 'present',
>> domain  => 'domain_2',
>> enabled => 'true',
>> id  => '4b8255591949484781da5d86f2c47be7',
>>   }
>>
>> = Composite name example 1  =
>> Puppet run:
>>   keystone_tenant {'project_A::domain_1', ...}
>>
>> Second run:
>>   keystone_tenant {'project_A::domain_2', ...}
>>
>> # Result/Listing
>>   keystone_tenant { 'project_A::domain_1':
>> ensure  

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

[Asselin, Ramy]

Follow these instructions to get permission from cinder: [1]
Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#permissions-on-your-third-party-system

-Original Message-
From: Watanabe, Isao [mailto:watanabe_i...@jp.fujitsu.com] 
Sent: Friday, September 11, 2015 2:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit 
server

Hello, Ramy

Thank you for your help.
Could you do me another favor, please.
I need to move our CI from sandbox to cinder later.
Do I need to register the CI to anywhere, so that the CI could test new patch 
set in cinder project, please?

Best regards,
Watanabe.isao



> -Original Message-
> From: Asselin, Ramy [mailto:ramy.asse...@hp.com]
> Sent: Friday, September 11, 2015 12:07 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified 
> into gerrit server
> 
> Done. Thank you for adding your CI system to the wiki.
> 
> Ramy
> 
> -Original Message-
> From: Watanabe, Isao [mailto:watanabe_i...@jp.fujitsu.com]
> Sent: Thursday, September 10, 2015 8:00 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified 
> into gerrit server
> 
> Hello, Ramy
> 
> Could you please add the following CI to the third-party ci group, too.
> 
> Fujitsu ETERNUS CI
> 
> We are preparing this CI test system, and going to use this CI system 
> to test Cinder.
> The wiki of this CI:
> 
> 
> Thank you very much.
> 
> Best regards,
> Watanabe.isao
> 
> 
> 
> > -Original Message-
> > From: Asselin, Ramy [mailto:ramy.asse...@hp.com]
> > Sent: Thursday, September 10, 2015 8:00 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified 
> > into gerrit server
> >
> > I added Fnst OpenStackTest CI
> >  > at us :open,n,z>  to the third-party ci group.
> >
> > Ramy
> >
> >
> >
> > From: Evgeny Antyshev [mailto:eantys...@virtuozzo.com]
> > Sent: Thursday, September 10, 2015 3:51 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified 
> > into gerrit server
> >
> >
> >
> >
> >
> > On 10.09.2015 11:30, Xie, Xianshan wrote:
> >
> > Hi, all,
> >
> >In my CI environment, after submitting a patch into 
> > openstack-dev/sandbox,
> >
> > the Jenkins Job can be launched automatically, and the result 
> > message of the job also can be posted into the gerrit server successfully.
> >
> > Everything seems fine.
> >
> >
> >
> > But in the "Verified" column, there is no verified vote, such as +1 
> > or -1.
> >
> > You will be able when your CI account is added to "Third-Party CI"
> > group on review.openstack.org
> > https://review.openstack.org/#/admin/groups/270,members
> > I advice you to ask for such a permission in an IRC meeting for 
> > third-party CI maintainers:
> > https://wiki.openstack.org/wiki/Meetings/ThirdParty
> > But you still won't be able to vote on other projects, except the sandbox.
> >
> >
> >
> >
> > (patch url: https://review.openstack.org/#/c/222049/
> >  ,
> >
> > CI name:  Fnst OpenStackTest CI)
> >
> >
> >
> > Although I have already added the "verified" label into the 
> > layout.yaml , under the check pipeline, it does not work yet.
> >
> >
> >
> > And my configuration info is setted as follows:
> >
> > Layout.yaml
> >
> > ---
> >
> > pipelines:
> >
> >   - name: check
> >
> >trigger:
> >
> >  gerrit:
> >
> >   - event: patchset-created
> >
> >   - event: change-restored
> >
> >   - event: comment-added
> >
> > ...
> >
> >success:
> >
> > gerrit:
> >
> >   verified: 1
> >
> >failure:
> >
> > gerrit:
> >
> >   verified: -1
> >
> >
> >
> > jobs:
> >
> >- name: noop-check-communication
> >
> >   parameter-function: reusable_node
> >
> > projects:
> >
> > - name: openstack-dev/sandbox
> >
> >- noop-check-communication
> >
> > ---
> >
> >
> >
> >
> >
> > And the projects.yaml of Jenkins job:
> >
> > ---
> >
> > - project:
> >
> > name: sandbox
> >
> > jobs:
> >
> >   - noop-check-communication:
> >
> >  node: 'devstack_slave || devstack-precise-check || d-p-c'
> >
> > ...
> >
> > ---
> >
> >
> >
> > Could anyone help me? Thanks in advance.
> >
> >
> 

Re: [openstack-dev] [keystone] PTL non-candidacy

[David Chadwick]

Hi Morgan

I think you have been an excellent PTL, and I wish you all the best in
your future roles with OpenStack

regards

David


On 10/09/2015 22:40, Morgan Fainberg wrote:
> As I outlined (briefly) in my recent announcement of changes (
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
> ) I will not be running for PTL of Keystone this next cycle (Mitaka).
> The role of PTL is a difficult but extremely rewarding job. It has been
> amazing to see both Keystone and OpenStack grow.
> 
> I am very pleased with the accomplishments of the Keystone development
> team over the last year. We have seen improvements with Federation,
> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
> releasing a dedicated authentication library, cross-project initiatives
> around improving the Service Catalog, and much, much more. I want to
> thank each and every contributor for the hard work that was put into
> Keystone and its associated projects.
> 
> While I will be changing my focus to spend more time on the general
> needs of OpenStack and working on the Public Cloud story, I am confident
> in those who can, and will, step up to the challenges of leading
> development of Keystone and the associated projects. I may be working
> across more projects, but you can be assured I will be continuing to
> work hard to see the initiatives I helped start through. I wish the best
> of luck to the next PTL.
> 
> I guess this is where I get to write a lot more code soon!
> 
> See you all (in person) in Tokyo!
> --Morgan
> 
> 
> __
> OpenStack Development Mailing 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] [glance] [nova] Verification of glance images before boot

[Nikhil Komawar]

You are right in the sense that's the ideal scenario.

(Impl-wise) However, even today we do not guarantee that behavior. If
someone were to propose a new driver or a change driver capability or
any thing of such order, images in status killed won't be guaranteed to
have removed the garbage data. The driver may not choose to be resilient
enough or would not take the responsibility of data removal
synchronously on failures.

Taking that fact in account, I have thought of Brianna's patch to be okay.

On 9/11/15 4:42 AM, Flavio Percoco wrote:
> On 10/09/15 15:36 -0400, Nikhil Komawar wrote:
>> The solution to this problem is to improve the scrubber to clean up the
>> garbage data left behind in the backend store during such failed
>> uploads.
>>
>> Currently, scrubber cleans up images in pending_delete and extending
>> that to images in killed status would avoid such a situation.
>
> While the above would certainly help, I think it's not the right
> solution. Images in status "killed" should not have data to begin
> with.
>
> I'd rather find a way to clean that data as soon as the image is
> moved to a "killed" state instead of extending the scrubber.
>
> Cheers,
> Flavio
>
>> On 9/10/15 3:28 PM, Poulos, Brianna L. wrote:
>>> Malini,
>>>
>>> Thank you for bringing up the ³killed² state as it relates to
>>> quota.  We
>>> opted to move the image to a killed state since that is what occurs
>>> when
>>> an upload fails, and the signature verification failure would occur
>>> during
>>> an upload.  But we should keep in mind the potential to take up
>>> space and
>>> yet not take up quota when signature verification fails.
>>>
>>> Regarding the MD5 hash, there is currently a glance spec [1] to
>>> allow the
>>> hash method used for the checksum to be configurable‹currently it is
>>> hardcoded in glance.  After making it configurable, the default would
>>> transition from MD5 to something more secure (like SHA-256).
>>>
>>> [1] https://review.openstack.org/#/c/191542/
>>>
>>> Thanks,
>>> ~Brianna
>>>
>>>
>>>
>>>
>>> On 9/10/15, 5:10 , "Bhandaru, Malini K" 
>>> wrote:
>>>
 Brianna, I can imagine a denial of service attack by uploading images
 whose signature is invalid if we allow them to reside in Glance
 In a "killed" state. This would be less of an issue "killed" images
 still
 consume storage quota until actually deleted.
 Also given MD-5 less secure, why not have the default hash be SHA-1
 or 2?
 Regards
 Malini

 -Original Message-
 From: Poulos, Brianna L. [mailto:brianna.pou...@jhuapl.edu]
 Sent: Wednesday, September 09, 2015 9:54 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: stuart.mcla...@hp.com
 Subject: Re: [openstack-dev] [glance] [nova] Verification of glance
 images before boot

 Stuart is right about what will currently happen in Nova when an
 image is
 downloaded, which protects against unintentional modifications to the
 image data.

 What is currently being worked on is adding the ability to verify a
 signature of the checksum.  The flow of this is as follows:
 1. The user creates a signature of the "checksum hash" (currently
 MD5) of
 the image data offline.
 2. The user uploads a public key certificate, which can be used to
 verify
 the signature to a key manager (currently Barbican).
 3. The user creates an image in glance, with signature metadata
 properties.
 4. The user uploads the image data to glance.
 5. If the signature metadata properties exist, glance verifies the
 signature of the "checksum hash", including retrieving the certificate
>>> >from the key manager.
 6. If the signature verification fails, glance moves the image to a
 killed state, and returns an error message to the user.
 7. If the signature verification succeeds, a log message indicates
 that
 it succeeded, and the image upload finishes successfully.

 8. Nova requests the image from glance, along with the image
 properties,
 in order to boot it.
 9. Nova uses the signature metadata properties to verify the signature
 (if a configuration option is set).
 10. If the signature verification fails, nova does not boot the image,
 but errors out.
 11. If the signature verification succeeds, nova boots the image,
 and a
 log message notes that the verification succeeded.

 Regarding what is currently in Liberty, the blueprint mentioned [1]
 has
 merged, and code [2] has also been merged in glance, which handles
 steps
 1-7 of the flow above.

 For steps 7-11, there is currently a nova blueprint [3], along with
 code
 [4], which are proposed for Mitaka.

 Note that we are in the process of adding official documentation, with
 examples of creating the signature as well as the properties that
 need to
 

[openstack-dev] [nova] changes in our tempest/devstack scenarios

[Sean Dague]

This is mostly an FYI for folks about how the test jobs have changed a
bit going into the Liberty release because people might not have kept on
top of it.

On a Liberty devstack the service catalogue now looks as follows:

compute => /v2.1/
compute_legacy => /v2

This means that all dsvm jobs are now using /v2.1/ as their base
testing. This change was supposed to be seamless. It mostly was. There
were a few compat issues exposed during this flip which we've got fixed.

The /v2 provided by devstack is v2.0 on v2.1 (as that's the Nova
defaults), which means it's the "relaxed validation" version of v2.1
code stack which should actually unnoticable from v2.0.

In order to make sure that the /v2 bits of Nova don't regress, there are
now 2 compat jobs up and running:

gate-tempest-dsvm-nova-v20-api - this is running Tempest Nova API tests
against the v2.0 on v2.1 stack. This is going to be around for a long time.

gate-tempest-dsvm-nova-v20-api-legacy - this is running Tempest Nova API
tests against v2.0 on the old v2.0 code base. This will go away once we
remove the v2.0 code stack.

Their success rates are looking pretty reasonable compared to a baseline:

http://tinyurl.com/oergv7q

And as such I've proposed making them voting in the Nova check queue -
https://review.openstack.org/222573


-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] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Julien Danjou]

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Luo,

> I find that gnocchi cannot deal with combined resource-id such as
> instance-xx-tapxx or instance--vda. I'm not sure whether it is my
> configuration problem or just bug.

Which version are you testing? The master branch has no support for
resource ID that are not UUID.

> And if such combined resource-id can be processed correctly, what about its
> metadata(or called attributes)? In current design, gnocchi seems treat
> instance-aaa, instance-aaa-tap111, instance-aaa-tap222 as equal although they
> have parent-child relationship and share many attributes.

We just merged support for those resources. We do not store any
attribute other than the name and parent instance AFAICS. What do you
miss as an attribute exactly?

-- 
Julien Danjou
# Free Software hacker
# http://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] [nova] Fine-grained error reporting via the external API

[Sean Dague]

On 09/11/2015 05:41 AM, Matthew Booth wrote:
> I've recently been writing a tool which uses Nova's external API. This
> is my first time consuming this API, so it has involved a certain amount
> of discovery. The tool is here for the curious:
> 
>   https://gist.github.com/mdbooth/163f5fdf47ab45d7addd
> 
> I have felt hamstrung by the general inability to distinguish between
> different types of error. For example, if a live migration failed is it
> because:
> 
> 1. The compute driver doesn't support support it.
> 
> 2. This instance requires block storage migration.
> 
> 3. Something ephemeral.
> 
> These 3 errors all require different responses:
> 
> 1. Quit and don't try again.
> 
> 2. Try again immediately with the block migration argument.[1]
> 
> 3. Try again in a bit.
> 
> However, all I have is that I made a BadRequest. I could potentially
> grep the human readable error message, but the text of that message
> doesn't form part of the API, and it may be translated in any case. As
> an API consumer, it seems I can't really tell anything other than 'it
> didn't work'. More than that requires guesswork, heuristics and inference.
> 
> I don't think I've missed some source of additional wisdom, but it would
> obviously be great if I have. Has there ever been any effort to define
> some contract around more fine-grained error reporting?
> 
> Thanks,
> 
> Matt
> 
> [1] Incidentally, this suggests to me that live migrate should just do
> this anyway.

This is an API working group recommendation evolving here. The crux of
which is going to be a structured json error return document that will
contain more info. https://review.openstack.org/#/c/167793/

-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] Fine-grained error reporting via the external API

[Feodor Tersin]

> From: mbo...@redhat.com
> To: openstack-dev@lists.openstack.org
> Date: Fri, 11 Sep 2015 10:41:47 +0100
> Subject: [openstack-dev] [nova] Fine-grained error reporting via the  
> external API
> 
> However, all I have is that I made a BadRequest. I could potentially
> grep the human readable error message, but the text of that message
> doesn't form part of the API, and it may be translated in any case. As
> an API consumer, it seems I can't really tell anything other than 'it
> didn't work'. More than that requires guesswork, heuristics and inference.
> 
> I don't think I've missed some source of additional wisdom, but it would
> obviously be great if I have. Has there ever been any effort to define
> some contract around more fine-grained error reporting?

Matt, iiuc this has been discussed early [1]. There is a review [2] mentioned 
at the end of that thread.

[1] http://markmail.org/message/6l6szrm6ox7w2cxk
[2] https://review.openstack.org/#/c/167793/
  __
OpenStack Development Mailing 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] [murano] [dashboard] Remove the owner filter from "Package Definitions" page

[Kirill Zaitsev]

I believe, that pagination is not broken there, since it works the same way 
pagination works on glance images page in horizon (the place the filter comes 
from)
Nevertheless +1 from me on the idea of replacing the filter with text-based 
filter, that would search by name. AFAIK it should be able to paginate based on 
filtered api calls.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 4 Sep 2015 at 14:49:26, Ekaterina Chernova (efedor...@mirantis.com) wrote:

Agreed.

Currently, pagination is broken on "Package definitions" page now, so removing 
that filter
will fix it back. Also, 'Other' tab looks unhelpful, admin should indicate to 
witch tenant this package belongs to.
This improvement will be added later.

Regards,
Kate.

On Fri, Sep 4, 2015 at 1:06 PM, Alexander Tivelkov  
wrote:
​+1 on this.

Filtering by ownership makes sense only on Catalog view (i.e. on the page of 
usable apps) ​but not on the admin-like console like the list of package 
definitions. 

--
Regards,
Alexander Tivelkov

On Fri, Sep 4, 2015 at 12:36 PM, Dmitro Dovbii  wrote:
Hi folks!

I want suggest you to delete owner filter (3 tabs) from Package Definition 
page. Previously this filter was available for all users and we agreed that it 
is useless. Now it is available only for admin but I think this fact still 
doesn't improve the UX. Moreover, this filter prevents the implementation of 
the search by name, because the work of the two filters can be inconsistent.
So, please express your opinion on this issue. If you agree, I will remove this 
filter ASAP.

Best regards,
Dmytro Dovbii

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



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


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

[openstack-dev] [zaqar][all] PTL No-Candidacy

[Flavio Percoco]

Greetings,

I'm sending this email to announce that I wont be running for Zaqar's
PTL position this cycle.

I've been Zaqar's PTL for two cycles and I believe it is time for me
to move on. More importantly, I believe it's time for this great,
still small, project to be led by someone else. The reasons behind
this belief have nothing to do with neither the previous state of the
project or even its current success story. If anything, my current
decision of not running has everything to do with the project's
current growth.

As many of you know, Zaqar (formerly known as Marconi) went through
many ups and downs. From great discussions and growth attempts to
almost being shutdown[0]. This has taugh me a lot but more
importantly, it's made the team stronger and it's cleared the team's
goals and path. And to prove that, let me share some of the success
stories the team has had since Vancouver:

3 great milestones
==

Let me start by sharing the progress the project has made code-wise.
While it may not be the most important for many people, I believe it's
extremly valuable for the project. The reason for this being that
every single member of this team is not a full-time Zaqar developer.
That means, every single member of this team has a different full-time
responsibility and every contribution made to the project has been
made in their spare working (or free) time. From amazing Outreachy
mentees (we've mentored participants of the Outrechy program since
cycle 1) to great contributors from other projects in OpenStack.

In milestone #1[1], we closed several bugs while we discussed the
features that we wanted to work on during Liberty. In milestone #2[1],
some of the features we wanted to have in Liberty started to land and
several bugs were fixed as well. In milestone #3, many bugs were fixed
due to a heavy testing session. But it doesn't end there. In RC1[4], 3
FFE were granted - not carelessly, FWIW - to complete all the work
we've planned for Liberty and, of course, more bug fixes.

We now even have a websocket example in the code base... ZOMG!

In addition to the above, the client library has kept moving forward
and it's being aligned with the current, maintained, API. This
progress just makes me happy and happier. Keep reading and you'll know
why.

Adoption by other projects
==

If you read the call for adoption thread[0], you probably know how
important that was for the project to move forward. After many
discussions in Vancouver, on IRC, conferences, mailing lists, pigeons,
telegrams, etc. projects started to see[5] the different use-cases for
Zaqar and we started talking about implementations and steps forward.
One good example of this is Heat's use of Zaqar for
software-config[6], which was worked on and implemented.

Things didn't stop there on this front. Other projects, like Sahara,
are also considering using Zaqar to communicate with guests agents.
While this is under discussion on Sahara's side, the required features
for it to happen and be more secure have been implemented in Zaqar[7].
Other interesting discussions are also on-going that might help with
Zaqar's adoption[8].

That said, I believe one of the works I'm most excited about right now
is the puppet-zaqar project, which will make it simpler for
deployments based on puppet to, well, deploy zaqar[9].

Community Growth


None of the above would have been possible without a great community
and especially without growing it. I'm not talking about the core
reviewers team growth - although we did have an addition[10] - but the
growth of the community accross OpenStack. Folks from other teams -
OpenStack Puppet, Sahara, Heat, Trove, cross-project efforts - have
joined the efforts of pushing Zaqar forward in different ways (like
the ones I've mentioned before).

Therefore, I owe a huge THANK YOU to each and one of these people that
helped making this progress possible.

Oh God, please, stop talking


Sure, fine! But before I do that, let me share why I've said all the
above.

The above is not to show off what the team has accomplished. It's
definitely not to take any credits whatsoever. It's to show exactly
why the team needs a new PTL.

I believe PTLs should rotate every 2 cycles (if not every cycle). I've
been the PTL for 2 cycles (or probably even more) and it's time for
the vision and efforts of other folks to jump in. It's time for folks
with more OPs knowledge than me to help making Zaqar more
"maintainable". It's time for new technical issues to come up and for
us as a community to work together on achieving those. More
cross-project collaboration, more APIs improvement, more user stories
is what Zaqar needs right now and I believe there are very capable
folks in Zaqar's team that would be perfect for this task.

One thing I'd like the whole team to put some efforts on, regardless
what technical decisions will be taken, is on increasing the diversity
of the 

[openstack-dev] [horizon] Patterns for Angular Panels

[Tripp, Travis S]

"A pattern, apart from the term's use to mean Template is a discernible 
regularity in the world or in a manmade design. As such, the elements of a   
pattern repeat in a predictable manner." -https://en.wikipedia.org/wiki/Pattern


Hello horizon-eers,

We have made some progress towards angular development in horizon, but much of 
it is still invisible. During Kilo, enough effort was put forth on angular work 
to help us recognize the deficiencies of the existing horizon angular code 
structure, style, localization, and even directory layout. 

A lot of effort went into Liberty to improve all of those areas, which has now 
enabled a much more serious discussion on producing angular based panels for 
horizon. And we actually have quite a few panels pretty far along in the patch 
process, but pretty much stuck in a holding pattern. Why? Primarily because 
there isn’t agreement on the coding pattern to be used for the panels.

Everybody seems to agree that we want a good enough pattern to base all the 
panels on. And most people would like a pattern that provides enough reusable 
widgets / services / etc that replicating the pattern requires a minimal amount 
of code with a maximum amount of flexibility.

However, one problem is that no single panel on its own constitutes a pattern. 
And within any line of patches for a particular panel, the attempts to extract 
out reusable pieces into separate patches often get blocked because they are 
only used in a single panel. This creates an impasse where the ability to 
effectively work on panels stagnates.

So, right now, the most recognizable pattern for angular panels is release 
after release of horizon having zero angular panels implemented.

That is a pattern that I believe must be broken.

So what can we do about it? Here are a few options:

1) Formalize a status of "experimental" and allow a limited number of disabled 
panels to merge with refactoring allowed
2) Immediately create a relatively short lived "Angular Panel" feature branch 
for some cross panel work.
3) Establish a new angular repo with additional cores for angular based 
features with a separate release mechanism


One argument says that merging in code that is initially disabled (panel 
disabled, workflow disabled) at least provides some real examples to draw from 
and actually can better enable external plugin developers, such as the app 
catalog work being done. It also can help to identify bugs and usability 
problems that may not otherwise be discovered (such as hard coded static urls 
and webroots) because deployers will have access to the feature. If a 
particular deployer wants to use it, they can enable it, potentially at their 
own risk. If another deployer does not want to use it until the feature has 
more time to bake, they do not have to use it and don’t have to block other 
deployers that do want to use it.

A counter argument is that allowing the merge of disabled code allows 
undesirable patterns to replicate quickly, causing way too much time to be 
wasted with having to refactor everything.

The idea of a feature branch has been brought up before, but I think it was not 
accepted for a number of reasons. A few being that the scope and goal of such a 
feature branch was not clear (too narrow or too broad) and with a lack of 
belief that there would be a reasonable timeline for acceptance back to master. 

We could also just create a separate repo for the angular based work 
(framework, dashboards, panels) and perhaps provide that as its own xstatic 
package (synced up to the main horizon release). A deployer desiring the 
angular work would deploy that package along with the base horizon release and 
still be able to selectively enable / disable the angular features they want. 
The argument against this is that it is more complicated to manage and even 
more likely that we could break things.


In my opinion the most effective route forward is something like this:

 1) Immediately create a feature branch for Angular Panel Pattern Establishment
 2) Allow 3 - 5 panels and their patches to be eagerly merged
 3) Use the panels to establish cross panel patterns and to find ways to 
simplify code re-use
 4) Extract out patches to be proposed to master as we see fit
 5) Set a goal of Mitaka M1 for at least a few panels to be merged back to 
master

While on the feature branch, the goal is to promote co-existence and pattern 
development allowing for easier collaboration between developers. This means 
allowing incomplete features on the branch. When merged back to master, the 
reviews would enforce the more stringent standards for merge guidelines, but 
could still allow for panels to be merged and still initially be disabled if 
desired.

I believe that this would create a pattern of visible progress.

Remember, perfection is the enemy of... http://pasteboard.co/zq44Y8f.png

-Travis
__
OpenStack Development 

Re: [openstack-dev] Gerrit downtime on Friday 2015-09-11 at 23:00 UTC

[James E. Blair]

cor...@inaugust.com (James E. Blair) writes:

> On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for
> about 30 minutes while we rename some projects.
>
> Existing reviews, project watches, etc, should all be carried
> over.

This has been completed without incident.

>  Currently, we plan on renaming the following projects:
>
>   stackforge/os-ansible-deployment -> openstack/openstack-ansible
>   stackforge/os-ansible-specs -> openstack/openstack-ansible-specs
>
>   stackforge/solum -> openstack/solum
>   stackforge/python-solumclient -> openstack/python-solumclient
>   stackforge/solum-specs -> openstack/solum-specs
>   stackforge/solum-dashboard -> openstack/solum-dashboard
>   stackforge/solum-infra-guestagent -> openstack/solum-infra-guestagent
>
>   stackforge/magnetodb -> openstack/magnetodb
>   stackforge/python-magnetodbclient -> openstack/python-magnetodbclient
>   stackforge/magnetodb-specs -> openstack/magnetodb-specs
>
>   stackforge/kolla -> openstack/kolla
>   stackforge/neutron-powervm -> openstack/networking-powervm

And we also moved these:

stackforge/os-ansible-deployment -> openstack/openstack-ansible
stackforge/os-ansible-deployment-specs -> openstack/openstack-ansible-specs

stackforge/refstack -> openstack/refstack
stackforge/refstack-client -> openstack/refstack-client

Thanks to everyone that pitched in to help the move go smoothly.

As a reminder, we expect this to be the last move of projects from
stackforge into openstack before we retire the stackforge/ namespace as
previously announced [1].

-Jim

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html

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

Re: [openstack-dev] [neutron] PTL Non-Candidacy

[Ichihara Hirofumi]

I'm stunned by the news. Neutron team doesn't lose great PTL but I know
your hard work. Your devotion made Neutron grow more. Enjoy your new found
free time

Hirofumi

2015-09-12 6:12 GMT+09:00 Kyle Mestery :

> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] PTL Candidacy

[Jim Rollenhagen]

Hi friends,

I'd like to throw in my hats (yes, all of them, I'll get to that shortly) for
the Ironic PTL election. In case you don't immediately recognize me,
I'm 'jroll' on IRC, where you can always find me.

I've been working on the Ironic project for a year and a half now, as one of
an architect of the first public cloud deployment of Ironic. It's
amazing to see how far we've come. When I joined the project, it could boot a
server. Now we have a laundry list of hardware drivers, support for cleaning
a node after teardown, ironic-python-agent, Bifrost, UEFI support, and so on
and so on, with plenty more on the way.

Over the last cycle or so, I've helped lead the charge on moving the project
even faster. It took much debate, but we now have fine-grained API versioning
that helps us advance our API faster and signal changes to users. We're also
beginning to embark on our new release model, which I have great hopes for:
we shipped 23 bug fixes in the 16 days between 4.0 and 4.1. I'd like to
continue serving our users by releasing frequently.

Back to the hats: I've worn many while working on Ironic, so I think I have
a unique perspective on the different aspects of the project.

With my deployer/operator hat on:

* Let's make deployments easier. Deploying Ironic with the rest of OpenStack
  is complex, and we need to improve the docs and tools around that. We should
  also point people at Bifrost more often, where they just need the Cobbler use
  case of spinning up a bunch of metal.

* Let's make operator's lives better. Ironic has cases where things can get
  into bad states. Let's document those (or better yet, fix them!). We should
  also make it easier for operators to get an insight into their environment.
  Some of our logs are vague or hard to find; we need to improve that. We
  should also work on the metrics spec to give ops insight into Ironic's
  performance.

With my developer hat on:

* Let's build a good devref, similar to Nova's. It's difficult for new or
  casual contributors to find their way around the project, because we don't
  have docs on how we develop code and the conventions around doing so. For
  example, when does a patch need to bump the API version? Cores know this;
  is it documented?

* I'd also love to see us grow our core reviewer team. We mostly do a good
  job at keeping reviews timely. However, our reviewers are also fantastic
  developers, and it would be great if they had more time to write code. I
  think we should evaluate giving more people +2 power, and trusting them
  not to land code if they aren't familiar with that part of the system.

With my leader hat on:

* Let's collaborate better with Nova. In the past, we haven't done a good
  job of this, and there was even some animosity between the projects. We now
  have two Nova liasions that help out by bring patches to nova-core's
  attention. It's a good start, but I think we need people working on Ironic
  that follow development in Nova that could impact us; truly collaborating
  to make sure Nova doesn't break us, and vice-versa. These folks should be
  actively reviewing Nova specs and code to ensure it doesn't break our model,
  and working to bring our model back in line with what Nova expects.

* Let's also start paying better attention to cross-project initiatives in
  OpenStack; collaborating with the API working group, cross-project specs,
  etc. I've started doing this, but the community needs more people doing it.
  We should be reviewing specs from these teams and making sure we implement
  those initiatives in a timely fashion. Most recent example: Keystone v3.
  We're way behind on getting that work done.

There's other things I'd like to accomplish as well, but those are the main
pieces. As for my downstream hat, it won't be getting as much use if I'm
elected. You can look at my history as one of the most active Ironic
developers on IRC, helping people solve problems, reviewing code, and helping
design large features. I've confirmed with my employer that if I'm elected
PTL, nearly 100% of my focus will be upstream, and you'll be seeing more of
me, for better or worse. :)

Regardless of the outcome, I'm looking forward to serving the Ironic community
during Mitaka.

Thanks for reading,

// 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] [neutron] PTL Non-Candidacy

[Vikram Choudhary]

I was little upset hearing this. You are a true leader Kyle. Nice working
with you.
On Sep 12, 2015 5:33 AM, "Assaf Muller"  wrote:

> Kyle, you've really done a fantastic job during your time. The community
> is now much more welcoming, and I think that working on Neutron is now much
> easier. We've grown to be a very positive and constructive community and
> that's not always been the case. I distinctly remember many conversations
> with a wide range of people about this exact topic over the last year and a
> half, all praising the changes you've been leading. Kudos.
>
> On 11 בספט׳ 2015, at 17:13, Kyle Mestery  wrote:
>
> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] PTL Non-Candidacy

[Sukhdev Kapur]

Hi Kyle,

You have done wonders for the Neutron project. I hate to see you go, but,
fully understand your posiiton. We will miss you.

Best of luck
-Sukhdev


On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery  wrote:

> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL Non-Candidacy

[Assaf Muller]

Kyle, you've really done a fantastic job during your time. The community is
now much more welcoming, and I think that working on Neutron is now much
easier. We've grown to be a very positive and constructive community and
that's not always been the case. I distinctly remember many conversations
with a wide range of people about this exact topic over the last year and a
half, all praising the changes you've been leading. Kudos.

On 11 בספט׳ 2015, at 17:13, Kyle Mestery  wrote:

I'm writing to let everyone know that I do not plan to run for Neutron PTL
for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
recently put it in his non-candidacy email [1]. But it goes further than
that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
full time job. In the case of Neutron, it's more than a full time job, it's
literally an always on job.

I've tried really hard over my three cycles as PTL to build a stronger web
of trust so the project can grow, and I feel that's been accomplished. We
have a strong bench of future PTLs and leaders ready to go, I'm excited to
watch them lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered
the concept of rotating PTL duties with each cycle, I'd like to highly
encourage Neutron and other projects to do the same. Having a deep bench of
leaders supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html

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

Re: [openstack-dev] [all][TC] 'team:danger-not-diverse tag' and my concerns

[Joe Gordon]

On Fri, Sep 11, 2015 at 2:30 PM, Jim Meyer  wrote:

> On Sep 11, 2015, at 12:45 PM, Shamail Tahir  wrote:
>
> On Fri, Sep 11, 2015 at 3:26 PM, Joshua Harlow 
> wrote:
>
>> Hi all,
>>
>> I was reading over the TC IRC logs for this week (my weekly reading) and
>> I just wanted to let my thoughts and comments be known on:
>>
>>
>> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309
>>
>> I feel it's very important to send a positive note for new/upcoming
>> projects and libraries... (and for everyone to remember that most projects
>> do start off with a small set of backers). So I just wanted to try to
>> ensure that we send a positive note with any tag like this that gets
>> created and applied and that we all (especially the TC) really really
>> considers the negative connotations of applying that tag to a project (it
>> may effectively ~kill~ that project).
>>
>> I would really appreciate that instead of just applying this tag (or
>> other similarly named tag to projects) that instead the TC try to actually
>> help out projects with those potential tags in the first place (say perhaps
>> by actively listing projects that may need more contributors from a variety
>> of companies on the openstack blog under say a 'HELP WANTED' page or
>> something). I'd much rather have that vs. any said tags, because the latter
>> actually tries to help projects, vs just stamping them with a 'you are bad,
>> figure out how to fix yourself, because you are not diverse' tag.
>>
>> I believe it is the TC job (in part) to help make the community better,
>> and not via tags like this that IMHO actually make it worse; I really hope
>> that folks on the TC can look back at their own projects they may have
>> created and ask how would their own project have turned out if they were
>> stamped with a similar tag…
>
>
> First, strongly agree:
>
> *Tags should be positive attributes or encouragement, not negative or
> discouraging. *I think they should also be as objectively true as
> possible. Which Monty Taylor said later[1] in the discussion and Jay Pipes
> reiterated[2].
>
> I agree with Josh and, furthermore, maybe a similar "warning" could be
> implicitly made by helping the community understand why the
> "diverse-affiliation" tag matters.  If we (through education on tags in
> general) stated that the reason diverse-affiliation matters, amongst other
> things, is because it shows that the project can potentially survive a
> single contributor changing their involvement then wouldn't that achieve
> the same purpose of showing stability/mindshare/collaboration for projects
> with diverse-affiliation tag (versus those that don't have it) and make
> them more "preferred" in a sense?
>
>
> I think I agree with others, most notably Doug Hellman[3] in the TC
> discussion; we need a marker of the other end of the spectrum. The absence
> of information is only significant if you know what’s missing and it’s
> importance.
>
> Separately, I agree that more education around tags and their importance
> is needed.
>
> I understand the concern is that we want to highlight the need for
> diversity, and I believe that instead of “danger-not-diverse” we’d be
> better served by “increase-diversity” or “needs-diversity” as the other end
> of the spectrum from “diverse-affiliation.” And I’ll go rant on the review
> now[4]. =]
>

Thank you for actually providing a review of the patch. I will respond to
the feedback in gerrit.



>
> —j
>
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-378
> [2]
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-422
> [3]
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-330
> [4] https://review.openstack.org/#/c/218725/
>
>
>
> __
> OpenStack Development Mailing 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] [Keystone] PTL Candidacy: Adam Young

[Shinobu Kinjo]

I'm not sure if I should reply to you or not since I am not developer of this 
project but another.

But I would like to let you know what I am really really thinking how the 
Keystone should work is:

Just HUB

I know that this description would be confusing you and developers subscribing 
this list.
Anyhow here is my thoughts.

>1.  Removing the bearer aspects of tokens

  Yes, that is what I am thinking of.

>2.  Better delegation mechanisms to scale the management of OpenStack.

  Yes, that is what I am thinking of.

>3.  Improving stability, scale, and performance.

  Plus security and isolation, if it would work as security hub for the 
OpenStack.

>4.  Simplify integration with external identity sources

Yes, that is what I am thinking of.

Shinobu

__
OpenStack Development Mailing 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] [ceilometer] using entry_points for configuration considered harmful

[Doug Hellmann]

Excerpts from Chris Dent's message of 2015-09-11 11:31:07 +0100:
> 
> Several weeks ago I made a little tool call pollman[1] that demonstrates
> pollsters plugins that are outside the ceilometer python namespace. I
> was going to use it in my portion of a summit talk to show just how
> incredibly easy it is to create custom pollsters. After getting the
> basics working and testing it out I forgot all about it until reminded
> about it in a way that I think demonstrates a fairly significant problem
> in the way that ceilometer (and perhaps other OpenStack projects) manage
> extensions.
> 
> Ceilometer is now frozen for Liberty so I've been doing a lot of
> devstack runs to find and fix bugs. And what do I spy with my little
> cli but:
> 
>  $ ceilometer meter-list
>  [...]
>  | weather.temperature  | gauge  | C  | 2172797  | pollman | pollman |
> 
>  $ ceilometer sample-list -q resource_id=2172797 --limit 1
>  [...]
>  | 0b667812-586a-11e5-9568-3417ebd4f75d | 2172797 | 
> weather.temperature | gauge | 18.62  | C| 2015-09-11T09:46:58.571000 |
> 
> It's 18.62 C in Newquay today. Good to know.
> 
> I have not configured Ceilometer to do this. Pollman set
> entry_points on ceilometer months ago and they are being used today.
> 
> This is really weird to me. I know why it is happening; it is the
> designed in behavior that ceilometer pollsters will activate and run all
> available pollster plugins (even when there are not resources available)
> but goodness me that's not very explicit.
> 
> If I want this to stop the most direct thing to do is uninstall pollman.
> 
> Sure, I can disable the meters associated with pollman in
> pipeline.yaml but to do I've got to go find out what they are. One
> way to do that is to go look at the entry_points, but if I've got
> multiple external plugins those entry_points are all over the place.
> Not very friendly.

How about making a tool to discover them? Something like
https://pypi.python.org/pypi/entry_point_inspector but more specific to
ceilometer plugins.

> 
> I like entry_points, especially in the way that they allow external
> extensions (let's have more of them please!), but we shouldn't be
> using them as service configuration[2].
> 
> What ideas do people have for being more explicit?

Are the plugins grouped in any way or named to allow wildcards for
partial names? For example, is it easy to say "I want all of the
compute pollsters, but I don't know their names" by using putting
something like 'compute:*' in the configuration file?

> 
> Now that the pollsters are only using the first half of the
> pipeline.yaml file it probably makes sense to explore (in Mitaka) a more
> explicit polling configuration file, separate from the transformations
> described by the pipeline.

That may make sense.

> 
> [1] https://github.com/cdent/pollman
> It gets the temperature for configured locations and saves it as a
> sample. Its unfinished because I promptly forgot about it until
> reminded as described above.
> 
> [2] Yes, I'm conscious of the fact that this problem goes away if I
> always use clean installs or virtualenvs but is that something we
> always want to require? It would be handy to be able to have a
> generic vm image which is "the ceilometer polling machine" and has
> all the pollsters installed but not all started by default.

I think the decision was based on the idea that we didn't expect real
deployments to install packages they weren't using. A dev environment is
obviously a different case.

Doug

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

[openstack-dev] [keystone] creating new users with invalid mail addresses possible

[Christian Berendt]

At the moment it is possible to create new users with invalid mail 
addresses. I pasted the output of my test at 
http://paste.openstack.org/show/456642/. (the listing of invalid mail 
addresses is available at 
http://codefool.tumblr.com/post/15288874550/list-of-valid-and-invalid-email-addresses).


Is it intended that addresses are not be validated?

Does it makes sense to validate addresses (e.g. with 
https://github.com/mailgun/flanker)?


Christian.

--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
OpenStack Development Mailing 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] [ceilometerclient] Updating global-requirements caps.

[gord chung]

On 10/09/2015 7:26 PM, Tony Breeds wrote:

Hi all,
 In trying to fix a few stable/juno issues we need to release a new version
of ceilometerclient for stable/juno.  This email is to try and raise awareness
so that if the proposal is bonkers [1] we can come up with something better.

This isn't currently possible due to the current caps in juno and kilo.

The proposed fix is to:

. update g-r in master (liberty): python-ceilometerclient>=1.2
   https://review.openstack.org/#/c/222386/
. update g-r in stable/kilo: python-ceilometerclient>=1.1.1,<1.2
. release a sync of stable/kilo g-r to stable/kilo python-ceilometerclient as 
1.1.1
. update g-r in stable/juno: python-ceilometerclient<1.1.0,!=1.0.13,!=1.0.14
. release 1.0.15 with a sync of stable/juno g-r

The point is, leave 1.0.x for juno, 1.1.x for kilo and >=1.2 for liberty

This is being tracked as: 
https://bugs.launchpad.net/python-ceilometerclient/+bug/1494516

There is a secondary issue if getting the (juno) gate in a shape where we can
actually do all of that.

Yours Tony.
[1] Bonkers is a recognized technical term right?


i commented on patch already but to reiterate, this sounds sane to me. 
we tagged stuff improperly during juno/kilo timespan so our versioning 
became an issue[1] and it looks like it caught up to us.


as it stands, version 1.1.0 is the rough equivalent to 1.0.14 (but with 
a requirement updates).  this seems to solve all the requirements issues 
so i'm content with the solution. thanks to both of you for figuring out 
the requirements logistics.


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-ceilometer/%23openstack-ceilometer.2015-04-14.log.html#t2015-04-14T21:50:49


cheers,

--
gord


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

Re: [openstack-dev] [keystone] creating new users with invalid mail addresses possible

[David Stanek]

On Fri, Sep 11, 2015 at 8:26 AM, Christian Berendt 
wrote:

> At the moment it is possible to create new users with invalid mail
> addresses. I pasted the output of my test at
> http://paste.openstack.org/show/456642/. (the listing of invalid mail
> addresses is available at
> http://codefool.tumblr.com/post/15288874550/list-of-valid-and-invalid-email-addresses
> ).
>
> Is it intended that addresses are not be validated?
>
> Does it makes sense to validate addresses (e.g. with
> https://github.com/mailgun/flanker)?
>

I don't know the complete history of this (I'm sure others can chime in
later), but since Keystone doesn't use the email address for anything it
was never really considered a first class attribute. It is just something
we accept and return through the API. It doesn't even have its own column
in the database.

I don't like this for a variety of reasons and we do have a bug[1] for
fixing this. Last Thursday several of us were discussing making a database
column for the email address as part of the fix for that bug.

1. https://bugs.launchpad.net/keystone/+bug/1218682

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.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] [fuel][swift] Separate roles for Swift nodes

[Alex Schultz]

Hey Daniel,

So as part of the 7.0 work we added support in plugins to be able to create
roles and being able to separate roles from the existing system. I think
swift would be a good candidate for this.  I know we also added in some
support for an external swift configuration that will be helpful if you
choose to go down the plugin route.  As an example of a plugin where we've
separated roles from the controller (I believe swift currently lives as
part of the controller role), you can take a look at our keystone, database
and rabbitmq plugins:

https://github.com/stackforge/fuel-plugin-detach-keystone
https://github.com/stackforge/fuel-plugin-detach-database
https://github.com/stackforge/fuel-plugin-detach-rabbitmq

-Alex

On Fri, Sep 11, 2015 at 2:24 AM, Daniel Depaoli <
daniel.depa...@create-net.org> wrote:

> Hi all!
> I'm starting to investigate some improvements for swift installation in
> fuel, in paticular a way to dedicate a node for it. I found this blueprint
> https://blueprints.launchpad.net/fuel/+spec/swift-separate-role that
> seems to be what i'm looking for.
> The blueprint was accepted but not yet started. So, can someone tell me
> more about this blueprint? I'm interested in working for it.
>
> Best regards,
>
> --
> 
> Daniel Depaoli
> CREATE-NET Research Center
> Smart Infrastructures Area
> Junior Research 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 Development Mailing 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] Suggestion to split install guide

[Bruno Cornec]

Hello,

Dmitry Tantsur said on Fri, Sep 11, 2015 at 10:56:07AM +0200:
Our install guide is huge, and I've just approved even more text for 
it. WDYT about splitting it into "Basic Install Guide", which will 
contain bare minimum for running ironic and deploying instances, and 
"Advanced Install Guide", which will the following things:

1. Using Bare Metal service as a standalone service
2. Enabling the configuration drive (configdrive)
3. Inspection
4. Trusted boot
5. UEFI


As a recent reader, I'd like to keep the UEFI part in the main doc as
more and more server will be UEFI by default. The rest seems good to go
in a separate one.

Bruno.
--
Open Source Profession, Linux Community Lead WW  http://opensource.hp.com
HP EMEA EG Open Source Technology Strategist http://hpintelco.net
FLOSS projects: http://mondorescue.org http://project-builder.org 
Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org


__
OpenStack Development Mailing 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] [Glance] glance core rotation part 1

[Flavio Percoco]

On 11/09/15 10:23 -0400, Nikhil Komawar wrote:

Hi,

I would like to propose the following removals from glance-core based on
the simple criterion of inactivity/limited activity for a long period (2
cycles or more) of time:

Alex Meade
Arnaud Legendre
Mark Washenberger
Iccha Sethi
Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)


+1 from me. Glad we're finally doing this.

I'd like to thank them all for having contributed so much to Glance
and I hope to see them back someday.

Flavio

--
@flaper87
Flavio Percoco


pgphHiQTiOibJ.pgp
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] [glance] [nova] Verification of glance images before boot

[Flavio Percoco]

On 11/09/15 07:58 -0400, Nikhil Komawar wrote:

You are right in the sense that's the ideal scenario.

(Impl-wise) However, even today we do not guarantee that behavior. If someone
were to propose a new driver or a change driver capability or any thing of such
order, images in status killed won't be guaranteed to have removed the garbage
data. The driver may not choose to be resilient enough or would not take the
responsibility of data removal synchronously on failures.


I think it's glance's responsibility to make sure the driver deletes
the image data. If the API is not strong enough to guarantee this,
then we should change that.


Taking that fact in account, I have thought of Brianna's patch to be okay.


Oh sure, I'm not trying to say it was a wrong choice. Sorry if it
sounded like that. I was replying to the thought of extending scrubber
(unless there's a patch that does this that I might have missed).

Cheers,
Flavio



On 9/11/15 4:42 AM, Flavio Percoco wrote:

   On 10/09/15 15:36 -0400, Nikhil Komawar wrote:

   The solution to this problem is to improve the scrubber to clean up the
   garbage data left behind in the backend store during such failed
   uploads.

   Currently, scrubber cleans up images in pending_delete and extending
   that to images in killed status would avoid such a situation.


   While the above would certainly help, I think it's not the right
   solution. Images in status "killed" should not have data to begin
   with.

   I'd rather find a way to clean that data as soon as the image is
   moved to a "killed" state instead of extending the scrubber.

   Cheers,
   Flavio


   On 9/10/15 3:28 PM, Poulos, Brianna L. wrote:

   Malini,

   Thank you for bringing up the ³killed² state as it relates to
   quota.  We
   opted to move the image to a killed state since that is what occurs
   when
   an upload fails, and the signature verification failure would occur
   during
   an upload.  But we should keep in mind the potential to take up
   space and
   yet not take up quota when signature verification fails.

   Regarding the MD5 hash, there is currently a glance spec [1] to
   allow the
   hash method used for the checksum to be configurable‹currently it
   is
   hardcoded in glance.  After making it configurable, the default
   would
   transition from MD5 to something more secure (like SHA-256).

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

   Thanks,
   ~Brianna




   On 9/10/15, 5:10 , "Bhandaru, Malini K"
   
   wrote:


   Brianna, I can imagine a denial of service attack by uploading
   images
   whose signature is invalid if we allow them to reside in Glance
   In a "killed" state. This would be less of an issue "killed"
   images still
   consume storage quota until actually deleted.
   Also given MD-5 less secure, why not have the default hash be
   SHA-1 or 2?
   Regards
   Malini

   -Original Message-
   From: Poulos, Brianna L. [mailto:brianna.pou...@jhuapl.edu]
   Sent: Wednesday, September 09, 2015 9:54 AM
   To: OpenStack Development Mailing List (not for usage
   questions)
   Cc: stuart.mcla...@hp.com
   Subject: Re: [openstack-dev] [glance] [nova] Verification of
   glance
   images before boot

   Stuart is right about what will currently happen in Nova when
   an image is
   downloaded, which protects against unintentional modifications
   to the
   image data.

   What is currently being worked on is adding the ability to
   verify a
   signature of the checksum.  The flow of this is as follows:
   1. The user creates a signature of the "checksum hash"
   (currently MD5) of
   the image data offline.
   2. The user uploads a public key certificate, which can be used
   to verify
   the signature to a key manager (currently Barbican).
   3. The user creates an image in glance, with signature metadata
   properties.
   4. The user uploads the image data to glance.
   5. If the signature metadata properties exist, glance verifies
   the
   signature of the "checksum hash", including retrieving the
   certificate

   >from the key manager.

   6. If the signature verification fails, glance moves the image
   to a
   killed state, and returns an error message to the user.
   7. If 

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Morgan Fainberg]

On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil  wrote:

>
>
> On 11/09/15 20:17, David Chadwick wrote:
> > Whichever approach is adopted you need to consider the future and the
> > longer term objective of moving to fully hierarchical names. I believe
> > the current Keystone approach is only an interim one, as it only
> > supports partial hierarchies. Fully hierarchical names has been
> > discussed in the Keystone group, but I believe that this has been
> > shelved until later in order to get a quick fix released now.
> >
> > regards
> >
> > David
> >
>
> Thanks David,
>
> That's interesting.
> So sub projects are pushing the issue further down.
> And maybe one day sub domains and sub users?
>
> keystone_role_user {
> 'user.subuser::domain1@project.subproject.subsubproject::domain2':
> roles => [...]
> }
>
> or
>
> keystone_role_user {'user.subuser':
>   user_domain => 'domain1',
>   tenant => 'project.subproject',
>   tenant_domain => 'domain2',
>   roles => [...]
> }
>
> I tend to think the domain must stick with the name it's associated
> with, otherwise we have to say 'here the domain for this and that, etc'.
>
>
>
> > On 11/09/2015 08:03, Gilles Dubreuil wrote:
> >> Hi,
> >>
> >> Today in the #openstack-puppet channel a discussion about the pro and
> >> cons of using domain parameter for Keystone V3 has been left opened.
> >>
> >> The context
> >> 
> >> Domain names are needed in Openstack Keystone V3 for identifying users
> >> or groups (of users) within different projects (tenant).
> >> Users and groups are uniquely identified within a domain (or a realm as
> >> opposed to project domains).
> >> Then projects have their own domain so users or groups can be assigned
> >> to them through roles.
> >>
> >> In Kilo, Keystone V3 have been introduced as an experimental feature.
> >> Puppet providers such as keystone_tenant, keystone_user,
> >> keystone_role_user have been adapted to support it.
> >> Also new ones have appeared (keystone_domain) or are their way
> >> (keystone_group, keystone_trust).
> >> And to be backward compatible with V2, the default domain is used when
> >> no domain is provided.
> >>
> >> In existing providers such as keystone_tenant, the domain can be either
> >> part of the name or provided as a parameter:
> >>
> >> A. The 'composite namevar' approach:
> >>
> >>keystone_tenant {'projectX::domainY': ... }
> >>  B. The 'meaningless name' approach:
> >>
> >>   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}
> >>
> >> Notes:
> >>  - Actually using both combined should work too with the domain
> >> supposedly overriding the name part of the domain.
> >>  - Please look at [1] this for some background between the two
> approaches:
> >>
> >> The question
> >> -
> >> Decide between the two approaches, the one we would like to retain for
> >> puppet-keystone.
> >>
> >> Why it matters?
> >> ---
> >> 1. Domain names are mandatory in every user, group or project. Besides
> >> the backward compatibility period mentioned earlier, where no domain
> >> means using the default one.
> >> 2. Long term impact
> >> 3. Both approaches are not completely equivalent which different
> >> consequences on the future usage.
> >> 4. Being consistent
> >> 5. Therefore the community to decide
> >>
> >> The two approaches are not technically equivalent and it also depends
> >> what a user might expect from a resource title.
> >> See some of the examples below.
> >>
> >> Because OpenStack DB tables have IDs to uniquely identify objects, it
> >> can have several objects of a same family with the same name.
> >> This has made things difficult for Puppet resources to guarantee
> >> idem-potency of having unique resources.
> >> In the context of Keystone V3 domain, hopefully this is not the case for
> >> the users, groups or projects but unfortunately this is still the case
> >> for trusts.
> >>
> >> Pros/Cons
> >> --
> >> A.
> >>   Pros
> >> - Easier names
> >>   Cons
> >> - Titles have no meaning!
> >> - Cases where 2 or more resources could exists
> >> - More difficult to debug
> >> - Titles mismatch when listing the resources (self.instances)
> >>
> >> B.
> >>   Pros
> >> - Unique titles guaranteed
> >> - No ambiguity between resource found and their title
> >>   Cons
> >> - More complicated titles
> >>
> >> Examples
> >> --
> >> = Meaningless name example 1=
> >> Puppet run:
> >>   keystone_tenant {'myproject': name='project_A', domain=>'domain_1',
> ...}
> >>
> >> Second run:
> >>   keystone_tenant {'myproject': name='project_A', domain=>'domain_2',
> ...}
> >>
> >> Result/Listing:
> >>
> >>   keystone_tenant { 'project_A::domain_1':
> >> ensure  => 'present',
> >> domain  => 'domain_1',
> >> enabled => 'true',
> >> id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
> >>   }
> >>keystone_tenant { 'project_A::domain_2':
> >> ensure  => 'present',
> >> domain  

[openstack-dev] [Glance] PTL Candidacy

[Flavio Percoco]

Greetings,

I'd like to raise my hand and send my candidacy for Glance's PTL
position. If you've heard my name, it's entirely possible that you
hear it either for my Zaqar's PTL position or my current TC position.

Before I go forward with my candidacy, allow me to say that I won't be
running for Zaqar's PTL position and that it's my intention to be
entirely focused on Glance[0]. I take being a PTL seriously[1] and I
strongly believe in the importance of focus when it comes to making
progress, which is what I'd like to base my candidacy on.

Glance may seem a simple service but it's not as simple as many folks
think. It's small compared to many other projects but it's still
exciting to work on. Perhaps, even more important than how exciting it
is, we should all remember the impact this project has on the rest of
the community and how it impacts all the OpenStack deployments out
there. In addition to this, Glance remains one of the projects that
are considered part of the starting kit and it serves a very important
task in a cloud deployment.

The reason I'm bringing the above up is because I believe we've
derailed a bit from that and that we should bring focus back on what's
the most important task for Glance, which is to serve cloud images in
a resilent, consistent and reliable way. This is not to say that
innovation should be stopped but it certainly shouldn't affect this
mission.

I believe these are some of the most important topics that our team
should focus on (non exhaustive list):

- Collaboration with other projects to migrate OpenStack to use
 Glance's V2 API

- Collaborate with the defcore team to define a clear view and support
 of what Glance provides and is.

- Increase V2 stability and awareness.

- Improve Glance's gate story to make sure we cover enough scenarios
 that are representative of existing deployments and use cases.

By reading the above four points, it's clear that I think that lot of
our work should go on cross-project collaboration. However, I'd like
to extend that to cross-team collaboration. One of the things that I
believe has affected Glance a lot is the lack of interaction with
other teams, especially with OPs, when it came down to working on new
features that had an impact on users. Therefore, I'd like to help
increasing cross-team collaboration in Glance's team.

As far as my involvement in Glance goes, I've been part of the team
since I started working on OpenStack. For the upcoming cycle, I'm
ready to dedicate my PTL duties entirely on the project and completely
focused on what's important to bring back focus and keep the project
growing but stable.

As some of you know already, I'm also part of the Technical Committee
and I'll be up for election next April, which means I'll be part of
the TC for, at least, 6 more months. Being part of the TC takes time
and this is something you should keep in mind (as much as I do).
However, if I were to be elected as Glance's PTL, I'll dedicate all my
efforts and time - consider that my current job allows me to be full
time upstream -  to just these to roles.

It'd be a great honor for me to work together with the Glance team and
to keep sharing knowledge, experiences and work as I've been doing so
far but this time as a PTL.

Thanks for reading thus far and for considering this candidacy,
Sincerely,
Flavio

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074212.html
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html

--
@flaper87
Flavio Percoco


pgpWYPRRzJNp0.pgp
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