[openstack-dev] [Horizon] ResourceType'ing the Swift UI and a bit of a speed bump

[Richard Jones]

Hi folks,

I've just pushed up an initial patch which implements *some* of the Swift
UI functionality using the ResourceType framework:
https://review.openstack.org/347114

I say *some* because there's an issue in the current code which will
require some refactoring to make it work in a ResourceType world. Funnily
enough, it's related to my other work in de-$scope-ifying the images
actions...

In short, the current containers model service is used for UI state. Kind
of like scope. Either way, it's bad (and I fully own that mistake, and I
apologise for being such a bad person). To make things work properly, the
containers model needs to have its state removed out to the two controllers
(containers and objects). It will retain the interfaces into Swift's object
containers, but those interfaces will require the caller to provide full
context (container and path) rather than relying on the state currently
stored on the model.

The state will be stored on the controllers. Funnily enough I had
implemented things like this in the first iteration of the swift ui, but I
had trouble sharing context between the two controllers. That was before I
used ngRoute. The routing information provides the state information needed
now.

I'm going to look at putting up a new patch to address this and and
hopefully it won't be too horrendous...


 Richard
__
OpenStack Development Mailing 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-translator] [tosca-parser] No weekly IRC meeting this week - July 28th

[Sahdev P Zala]

Hello team,

As we talked in our last meeting, there will be no meeting this Thursday 
July 28th due to no strong agenda and my unavailability this week. Please 
take any discussion on IRC or via emails.

Thanks! 

Regards, 
Sahdev Zala


__
OpenStack Development Mailing 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] Proposing Jakub Libosvar for testing core

[Brian Haley]

+1

On 07/22/2016 04:12 AM, Oleg Bondarev wrote:

+1

On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley > wrote:

+1


On Jul 21, 2016, at 5:13 PM, Kevin Benton > wrote:

+1

On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin > wrote:

+1 from me

On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller > wrote:

As Neutron's so called testing lieutenant I would like to propose
Jakub Libosvar to be a core in the testing area.

Jakub has demonstrated his inherent interest in the testing area 
over
the last few years, his reviews are consistently insightful and his
numbers [1] are in line with others and I know will improve if given
the responsibilities of a core reviewer. Jakub is deeply involved 
with
the project's testing infrastructures and CI systems.

As a reminder the expectation from cores is found here [2], and
specifically for cores interesting in helping out shaping Neutron's
testing story:

* Guide community members to craft a testing strategy for features 
[3]
* Ensure Neutron's testing infrastructures are sufficiently
sophisticated to achieve the above.
* Provide leadership when determining testing Do's & Don'ts [4]. 
What
makes for an effective test?
* Ensure the gate stays consistently green

And more tactically we're looking at finishing the Tempest/Neutron
tests dedup [5] and to provide visual graphing for historical 
control
and data plane performance results similar to [6].

[1] http://stackalytics.com/report/contribution/neutron/90
[2]

http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
[3]

http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
[4] https://assafmuller.com/2015/05/17/testing-lightning-talk/
[5] https://etherpad.openstack.org/p/neutron-tempest-defork
[6]

https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s


__
OpenStack Development Mailing 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 Development Mailing 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] mascot/logo ideas

[Emilien Macchi]

Hi,

So we have until July 27th to take the decision about our mascot.
If you are interested to vote, please add +1 on the proposals on the
etherpad [1].

By Wednesday, we'll take the one with the most of +1

Thanks,

[1] https://etherpad.openstack.org/p/puppet-openstack-mascot-logo

On Tue, Jul 12, 2016 at 11:23 AM, Emilien Macchi  wrote:
> Hey,
>
> During the meeting we decided to use etherpad to submit new ideas for
> our mascot / logo [1]:
> https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
>
> Feel free to use your imagination as long you stay SFW :-)
>
> Thanks,
>
> [1] http://osdir.com/ml/openstack-dev/2016-07/msg00456.html
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [Neutron][oslo.db] Inspecting sqlite db during unit tests

[Mike Bayer]

On 07/25/2016 12:55 PM, Carl Baldwin wrote:

On Fri, Jul 22, 2016 at 8:47 AM, Mike Bayer > wrote:



On 07/22/2016 04:02 AM, Kevin Benton wrote:

Now that we have switched to oslo.db for test provisioning the
responsibility of choosing a location lands
here:

https://github.com/openstack/oslo.db/blob/a79479088029e4fa51def91cb36bc652356462b6/oslo_db/sqlalchemy/provision.py#L505

The problem is that when you specify
OS_TEST_DBAPI_ADMIN_CONNECTION it
does end up creating the file, but then the logic above chooses
a URL
based on the random ident. So you can find an sqlite file in
your tmp
dir, it just won't be the one you asked for.

It seems like a bug in the oslo.db logic, but the commit that
added it
was part of a much larger refactor so I'm not sure if it was
intentional
to ensure that no two tests used the same db.


it is, the testr system runs tests in multiple subprocesses and I
think neutron has it set to four.  if they all shared the same
sqlite database file you'd have failed tests.


A potential improvement might be to replace
OS_TEST_DBAPI_ADMIN_CONNECTION with another environment variable which
could be used to provide a template for generating multiple unique
database names. That would make it a little more intuitive. But, I can
work with this for now.


perhaps we can allow some kind of tokenized syntax within the 
OS_TEST_DBAPI_ADMIN_CONNECTION variable itself.  That env variable is 
already kind of a beast but at least there's just the one.







Car


__
OpenStack Development Mailing 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] [Magnum] Select our project mascot/logo

[Adrian Otto]

How about a shark? Something along these lines:

http://www.logoground.com/logo.php?id=10554



On Jul 25, 2016, at 3:54 PM, Hongbin Lu  wrote:

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world—an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There’s more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

Best regards,
Hongbin
__
OpenStack Development Mailing 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] Live migration IRC meeting on 26th July

[Murray, Paul (HP Cloud)]

The next live migration meeting is on 26th July.

For agenda see: https://wiki.openstack.org/wiki/Meetings/NovaLiveMigration 
(still being updated)

Paul
__
OpenStack Development Mailing 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] [Glare][Heat][Tacker][Murano][App-Catalog] [Glance] How to validate your binary data in OpenStack

[Nikhil Komawar]

Thanks for your nice message Mikhail.


I, however, wanted to address a small correction to avoid any further
presumptions about Glare, Glance and Images API with the tags associated
in the email subject herewith. (also adding Glance tag to the list to
ensure we reach the appropriate Images related audience).


On 7/25/16 2:26 PM, Mikhail Fedosin wrote:
> Hello! Today I want to discuss with community one good feature in
> Glare - artifact validation. In short Glare allows to validate binary
> data before it's uploaded to store. For example, for Tosca we're able
> to check if uploaded yaml is a valid template [1], for vm images we
> can test their integrity. For sure, Glare supports quite sophisticated
> workflows, like sending murano packages to external CI
While this feature looks nothing less than excellent, it is unfortunate
that the Images API is built into Glance -- meaning Glance will remain
the reference implementation of the OpenStack Images API for the near to
long future. So, while it may be possible to test integrity of data
assets, it won't be possible for any operator/user/API-consumer to use
Glare for Images as Glance will remain the whole and sole API for Images
and all future features need to be implemented therein.

The reasons for this have been discussed briefly in the proposal
(review) of the Glare spec and in related conversations. If anyone needs
more info, please reach out.

> or validate Heat templates with given environments. 
>
> So, I want to think out what validation is exactly required from Glare
> and how we can help related projects to succeed, checking and reliably
> storing their binary assets.
>
> Best regards,
> Mikhail Fedosin
>
> [1]
> https://review.openstack.org/#/c/337633/10/contrib/glare/openstack_app_catalog/artifacts.py@159
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing 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,
Nikhil


__
OpenStack Development Mailing 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] [Magnum] Select our project mascot/logo

[Fox, Kevin M]

Some insect related ideas:
https://en.wikipedia.org/wiki/Paraponera_clavata - bullet ant
https://en.wikipedia.org/wiki/Bombardier_beetle

Thanks,
Kevin

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Monday, July 25, 2016 3:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum] Select our project mascot/logo

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world—an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There’s more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

Best regards,
Hongbin
__
OpenStack Development Mailing 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] [Magnum] Select our project mascot/logo

[Grant, Jaycen V]

Stallion(horse) - think something like this: 
http://free-icon-download.com/modules/PDdownloads/singlefile.php?cid=11=44

Snake - http://www.freeiconspng.com/uploads/snake-jungle-22.png

Wave - http://www.123rf.com/photo_11649085_set-of-waves.html

Some ideas that come to mind.

Jaycen

From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Monday, July 25, 2016 3:55 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Magnum] Select our project mascot/logo

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world-an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There's more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

Best regards,
Hongbin
__
OpenStack Development Mailing 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] [Magnum] Select our project mascot/logo

[Hongbin Lu]

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world-an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There's more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

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

Re: [openstack-dev] [tacker] Mascot for Tacker

[Sridhar Ramaswamy]

Based on the inputs so far, we will go ahead with Squid for Tacker!

- Sridhar

On Mon, Jul 18, 2016 at 1:48 PM, Sridhar Ramaswamy  wrote:
> Tackers:
>
> Please provide your inputs to select a Mascot for Tacker in the
> etherpad. This is based on the recent initiative from OpenStack
> marketing team, see http://www.openstack.org/project-mascots for more
> details. There is already an exciting logo proposal in the etherpad
> below :)
>
> https://etherpad.openstack.org/p/tacker-mascot

__
OpenStack Development Mailing 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] Keystone V3 alignment: renaming tenant_id columns to project_id

[Darek Śmigiel]

Hey Neutrinos,

Quick update about Keystone v3 DB migration.

All Stadium projects have necessary changes in review queue. [1] Some of them 
are already merged, others don’t need to have any updates. But we still have 
couple more [2] that need to be merged before Neutron change will land.

We still have “other projects” [1] without applied changes, but it won’t block 
final merge.

If you have spare time, please look at these changes, and try to merge DB 
migration ASAP.

Thanks,
Darek

[1] https://etherpad.openstack.org/p/neutron-stadium-tenant2project 

[2] https://review.openstack.org/#/q/topic:bp/keystone-v3+status:open 


> On Jul 15, 2016, at 12:50 PM, Darek Śmigiel  wrote:
> 
>> 
>> On Jul 15, 2016, at 11:33 AM, Neil Jerram > > wrote:
>> 
>> I've put my name against networking-calico, but I believe it's a no-op for 
>> me at this stage of the tenant->project transition.  The occurrences of 
>> 'tenant' in networking-calico's code are:
>> 
>> ./networking_calico/plugins/calico/plugin.py:45:LOG.info 
>> ("Forcing ML2 tenant_network_types to 'local'")
>> ./networking_calico/plugins/calico/plugin.py:46:
>> cfg.CONF.set_override('tenant_network_types', ['local'], group='ml2')
>> ./networking_calico/agent/dhcp_agent.py:213:  'tenant_id': ? }
>> ./networking_calico/agent/dhcp_agent.py:298: 
>>  "tenant_id": "calico",
>> 
>> So it's just:
>> - the ML2 'tenant_network_types' config setting name
>> - the 'tenant_id' key used in neutron.agent.linux.dhcp.NetModel.
>> 
>> I guess those will be transitioned in due course.  Am I right in thinking 
>> that there's no action for networking-calico right now, or do you think I've 
>> missed something?
>> 
> 
> Hey Neil,
> Thank you for adding calico.
> 
> It seems that you’re right. Probably there is no required work for 
> networking-calico, but good to have all possible projects gathered in one 
> place.
> Couple of other subprojects, which do not write to Neutron DB, also are not 
> changed.
> 
> Darek
> 
>> Thanks,
>>  Neil
>> 
>> 
>> On Thu, Jul 14, 2016 at 9:32 PM Henry Gessau > > wrote:
>> Henry Gessau > wrote:
>> > In accordance with the Blueprint [1] and the spec [2], we are in the 
>> > process
>> > of deprecating the use of the term 'tenant' in favor of 'project'.
>> >
>> > The code change [3] with the biggest impact on Neutron developers is 
>> > currently
>> > out for review and will merge quite soon (shortly after N-2). This change
>> > renames all 'tenant_id' columns in the database to 'project_id'.
>> >
>> > If you have any changes in flight that touch a tenant_id field, you will be
>> > affected. Please familiarize yourself with [3], rebase on it, and comply 
>> > with
>> > the changes.
>> >
>> > One patch known to be affected is [4].
>> >
>> > The column rename change has been designed to have minimal impact on the 
>> > usage
>> > of 'tenant_id' fields. For now 'tenant_id' is still available as a
>> > key/property in resource dicts and objects, and as an attribute in request
>> > contexts.
>> >
>> > In the long run (Ocata or beyond) we want to end up with no usages of the 
>> > term
>> > 'tenant', except in the API for backwards compatibility. Existing usages of
>> > 'tenant' in the codebase will be converted to 'project' on a case-by-case
>> > basis. Although the conversion has not yet commenced, any *new* fields,
>> > arguments, variables, etc. with 'tenant' in the name will no longer be 
>> > accepted.
>> >
>> > [1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3 
>> > 
>> > [2]
>> > http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
>> >  
>> > 
>> > [3] https://review.openstack.org/335786 
>> > 
>> > [4] https://review.openstack.org/244680 
>> > 
>> 
>> This work also affects repos that integrate with neutron and have tables in
>> the Neutron database. We have started to submit patches for the 
>> neutron-fwaas,
>> -lbaas, and -vpnaas repos, and we are keeping track of the progress with an
>> etherpad [5].
>> 
>> I have listed all the Neutron Stadium projects there, as well as all the
>> projects that I could find hosted on git.openstack.org 
>>  that integrate with the
>> Neutron DB. Please help by signing up for a project.
>> 
>> If you encounter any problem or issues, please ask us for help. Either reply
>> to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron 

Re: [openstack-dev] [keystone] project mascot -- turtle!

[Heidi Joy Tretheway]

This is a great list! Right now, I don’t see any conflicts, and I will be able 
to confirm on Wednesday.
Cheers,
Heidi Joy

__
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769  |  skype: heidi.tretheway





> On Jul 18, 2016, at 3:31 PM, Steve Martinelli  wrote:
> 
> We have decided it will be a turtle. (hard shell, security, get it!)
> 
> A poll was created, anyone who had 2 or more commits in a keystone project 
> during the Mitaka or Newton release had a vote. The options were made by 
> active keystone developers during a meeting. Poll results are here [1], in 
> case there is a conflict/copyright issue/etc. we can go with #2 (or #3 or 
> ...) on the list.
> 
> [1] http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_3b96ec71a39af395 
> 

__
OpenStack Development Mailing 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] Equal Chances for all projects (was Plugins for all)

[Hayes, Graham]

Top posting - this is a recap of what has been said, and some
clarifications

I realise that I was not very clear at the beginning of this process, so
here is my effort to clarify things, from the ML thread, and the review.

 >   ... does this also include plugins within projects, like storage
 >   backends in cinder and hypervisor drivers in nova?

No - this was not clear enough. This change is aimed at projects that are
points of significant cross project interaction. While, in the future 
there may
come a point where Nova Compute Drivers are developed out of tree (though
I doubt it), that is not happening today. As a result, there is no 
projects in
the list of projects that would need to integrate with Nova.

 >   Could you please clarify: do you advocate for a generic plugin 
interface for
 >   every project, or that each project should expose a plugin 
interface that
 >   allows plugin to behave as in-tree components? Because the latter 
is what
 >   happens with Tempest, and I see the former a bit complicated.

For every project that has cross project interaction - tempest is a good
example.

For these projects, they should allow all projects in tree (like Nova,
Neutron, Cinder etc are today), or they should have a plugin interface
(like they currently do), but all projects *must* use it, and not use
parts of tempest that are not exposed in that interface.

This would mean that tempest would move the nova, neutron, etc tests to
use the plugin interface.

Now, that plugin could be kept in the tempest repo, and still maintained
by the QA team, but should use the same interface as the other plugins
that are not in that repository.

Of course, it is not just tempest - an incomplete list looks like:

* Tempest
* Devstack
* Grende
* Horizon
* OpenStack Client
* OpenStack SDK
* Searchlight
* Heat
* Mistral
* Celiometer
* Rally
* Documentation

And I am sure I have missed some obvious ones. (if you see a project missing
let me know on the review)


 >   I think I disagree here. The root cause is being addressed: 
external tests can
 >   use the Tempest plugin interface, and use the API, which is being 
stabilized.
 >   The fact that the Tempest API is partially unstable is a temporary 
things, due
 >   to the origin of the project and the way the scope was redefined, 
but again
 >   it's temporary.

This seems to be the core of a lot of the disagreement - this is only 
temporary,
it will all be fixed in the future, and it should stay this way.

Unfortunately the discrepancy between projects is not temporary. The 
specific
problems I have highlighted in the thread for one of the projects is 
temporary,
but I beleive the only long-term solution is to remove the difference 
between
projects.

 >   Before we start making lots of specific rules about how teams
 >   coordinate, I would like to understand the problem those rules are 
meant
 >   to solve, so thank you for providing that example.
 >   ...
 >   It's not clear yet whether there needs to be a new policy to change the
 >   existing intent, or if a discussion just hasn't happened, or if someone
 >   simply needs to edit some code.

Unfortunately there is a big push back on editing code to help plugins from
some of the projects. Again, having the differing access between 
projects will
continue to exacerbate the problem.


 >   "Change the name of the resolution"

That was done in the last patchset. I think the Level Playing Field title
bounced around my head from the other resolution that was titled Level 
Playing
Field. It may have been confusing alright.

I feel like I have been using tempest as an example a little too much, 
as it captures
the current issues perfectly, and a large number of the community have some
knowledge of it, and how it works.

There is other areas across OpenStack where plugins need attention as well:

Horizon
---

Horizon privileged projects have access to much more panels than
plugins (service status, quotas, overviews etc).
Plugins have to rely on tarballs of horizon

OpenStack Client


OpenStack CLI privileged projects have access to more commands, as
plugins cannot hook in to them (e.g. quotas)

Grenade
---

Plugins may or may not have tempest tests ran (I think that patch
merged), they have to use parts of tempest I was told explicitly
plugins should not use to get the tests to run at that point.

Docs


We can now add install guides and hook into the API Reference, and API
guides. This is great - and I am really happy about it. We still have
issues trying to integrate with other areas in docs, and most non docs
privileged projects end up with massive amounts of users docs in
docs.openstack.org/developer/ , which is not ideal.


Thanks,

Graham

On 14/07/2016 20:25, Hayes, Graham wrote:
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross
> project interaction, or allow all projects access to the same internal

[openstack-dev] [searchlight] Rick Aulino core nomination

[Tripp, Travis S]

Hello!

I am nominating Rick Aulino for Searchlight core. Rick has been working on the 
core indexing engine throughout Mitaka and Newton. He has developed a Neutron 
plug-in and has reviewed most of the other plugins in Searchlight.  Since the 
beginning of Mitaka [0] and for the first two Newton milestones [1], Rick is 
consistently in the top 5 for reviews and commits. He has provided thoughtful 
feedback and valuable insights throughout his time on Searchlight.

[0] http://stackalytics.com/report/contribution/searchlight-group/242
[1] http://stackalytics.com/report/contribution/searchlight-group/100

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

Re: [openstack-dev] [Openstack] Filter ComputeCapabilitiesFilter returned 0 hosts

[Turbo Fredriksson]

I'm looking at the documentation at 

  
http://docs.openstack.org/icehouse/config-reference/content/section_compute-scheduler.html#computecapabilitiesfilter

- s n i p -
ComputeCapabilitiesFilter

Matches properties defined in an instance type's extra specs against compute 
capabilities.

If an extra specs key contains a colon ":", anything before the colon is 
treated as a namespace, and anything after the colon is treated as the key to 
be matched. If a namespace is present and is not 'capabilities', it is ignored 
by this filter.
- s n i p -

I've read that section several times now, but I don't understand.
What does it actually mean??

What is "an instance type's extra specs"? And where do I set it?
--
You know, boys, a nuclear reactor is a lot like a woman.
You just have to read the manual and press the right buttons
- Homer Simpson


__
OpenStack Development Mailing 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][stable] status update and call for action

[Ihar Hrachyshka]

Carl Baldwin  wrote:

I appreciate how you're trying to steer this big ship in a new direction  
to improve support for our releases. I know it must be frustrating when  
it doesn't turn as quickly as it should.


On Thu, Jun 30, 2016 at 8:56 AM, Ihar Hrachyshka   
wrote:
For the start, I produced a bunch of topic specific LP dashboards,  
specifically:


- ipv6: https://goo.gl/dyu1d1
- dns: https://goo.gl/9H2BlK
- l3-ipam-dhcp: https://goo.gl/v4XWE4
- l3-dvr-backlog: https://goo.gl/sx0KL5
- l3-ha: https://goo.gl/QIIRa1

Ihar, I've add the above five to the L3 team agenda [1] under our bug  
topic. We will have a discussion about this in our meeting. Our team has  
been putting progressively more emphasis on bugs and this is another  
step. I don't know how this will turn out yet but I think it is worth  
bringing up to the team.


Great, let the team decide. It will be interesting to hear whether the  
process as described makes sense, and whether there are improvements that  
could help to adopt the process in your flow.




- api: https://goo.gl/d66XtB
- db: https://goo.gl/8NNtym
- loadimpact: https://goo.gl/xQuKRc
- ovs: https://goo.gl/Zr70co
- linuxbridge: https://goo.gl/CrcCzU
- sg-fw: https://goo.gl/K9lkdA
- qos: https://goo.gl/9kRCJv

(There are more tags to consider, but let’s start with those.)

Is there will to help with the process?

I'm eager to help but I tend to run a little bit oversubscribed so it can  
be difficult to change my behavior.  :)


I don’t think it should be up to any single person. I believe it’s a  
cultural thing that, as you said above, will obviously require some time to  
deflect. If everyone buys the new world, it shouldn’t be a huge load per  
person. If it’s just a bunch of people on the team taking care, it’s indeed  
prone to oversubscription. We should avoid the latter by spreading the load  
as wide as possible. Hence my call to subteams.


Thanks
Ihar

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

Re: [openstack-dev] [kolla] Monitoring tooling

[Fox, Kevin M]

sigh. I hate to be the bearer of bad news... I seem to be in that role a 
lot recently...

We've fought with the latest version of ceilometer/gnocchi for a few months 
(off and on) to try and get it to work. Currently gnocchi is not fast enough to 
ingest our metering data into ceph. Its possible this is just some undocumented 
(mis)configuration. But we've had issues with ceilometer scaling for multiple 
years now.

Honestly, the longer we've fought with it, the more I wonder why OpenStack is 
writing their own rather then just use a backend store like graphite which is 
already opensource?

Thanks,
Kevin

From: Matthias Runge [mru...@redhat.com]
Sent: Monday, July 25, 2016 11:54 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] Monitoring tooling

On 25/07/16 09:57, Julien Danjou wrote:
> On Sun, Jul 24 2016, Mathias Ewald wrote:
>
>> 5. InfluxDB to store metrics
>> 6. Grafana to dashboard metrics
>
> Would be nice to leverage scalable and open source solution built your
> fellow OpenStack community, i.e. Gnocchi and its Grafana support.
>
Yes, I'd like to repeat the question here: Is there any reason to
introduce another quite complex tool instead of something developed,
supported and used by the OpenStack community?

Matthias

--
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

__
OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Steven Dake (stdake)]

Response inline

On 7/25/16, 11:54 AM, "Matthias Runge"  wrote:

>On 25/07/16 09:57, Julien Danjou wrote:
>> On Sun, Jul 24 2016, Mathias Ewald wrote:
>> 
>>> 5. InfluxDB to store metrics
>>> 6. Grafana to dashboard metrics
>> 
>> Would be nice to leverage scalable and open source solution built your
>> fellow OpenStack community, i.e. Gnocchi and its Grafana support.
>> 
>Yes, I'd like to repeat the question here: Is there any reason to
>introduce another quite complex tool instead of something developed,
>supported and used by the OpenStack community?

I'm not sure how to respond to this question since I don't understand all
of the technical details of all these different solutions and what they
do.  I'd ask someone to draw me a picture but that is probably overkill.
When this thread got kicked off, my general thinking was we might end up
with more then one monitoring solution.

I think digging in deeper, there are 3 layers:
Data acquisition layer (e.g. Collectd)
Data storage layer (e.g. Influxdb)
Data modeling layer (e.g. Grafana)

I'm not a big fan of picking winners although there appears to be little
to no competition at the data modeling layer (unless that is what Sensu
does, still learning), so its the other layers that require the ability to
be mixed and matched.  Nobody has said we would reject such changes.
Operators have told me time and time again, flexibility is why Kolla is
chosen against other operational deployment managers (ODMs).  What google
tells me is that the data acquisition layer has 4 or 5 choices and the
data storage layer has 4 or 5 choices.  We enable and disable each service
individually on intention in Kolla.

I see no reason why this work can't be made to operate in that framework.
Someone needs to show up to do the work and both mewald and daviey have.
Their initial solutions don't include gnocchi (Kolla does not yet have
ansible playbooks for gnocci unfortunately).  I never tell people to go
"work on that" (unless someone asks when ramping up) - people choose to
work on what they want in this project.  I'm likely never changing my
perspective on this last point, fwiw :)

If someone does the work for gnocchi implementation, it will be merged
(unless some other core reviewer -2's the work which is unlikely but
possible - my opinion only counts once:)

Regards
-steve



>
>Matthias
>
>-- 
>Matthias Runge 
>
>Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>Commercial register: Amtsgericht Muenchen, HRB 153243,
>Managing Directors: Charles Cachera, Michael Cunningham,
>Michael O'Neill, Eric Shander
>
>__
>OpenStack Development Mailing 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] [kolla][vote] Applying for stable-follows tag

[Steven Dake (stdake)]

Cool,; a mentorship like relationship would be super helpful :)

I've modified the review.

Regards
-steve


From: Dave Walker >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, July 25, 2016 at 10:23 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

Hi,

I'm not currently kolla-core, but I am a member of stable-maint-core (cross 
project).  I've been pretty involved with Kolla this cycle, some 7 landed 
commits and 34 patchsets pushed up.. So I have a good understanding of both 
sides of the camp.  I'd be happy to throw my head into the ring for 
kolla-stable-maint.

--
Kind Regards,
Dave Walker

On 22 July 2016 at 10:47, Kwasniewska, Alicja 
> wrote:
+1 too

From: Mauricio Lima 
[mailto:mauricioli...@gmail.com]
Sent: Tuesday, July 19, 2016 5:29 PM

To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1

2016-07-19 12:23 GMT-03:00 Vikram Hosakote (vhosakot) 
>:
+1 sure.

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, July 19, 2016 at 9:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 ofc

On 19 July 2016 at 06:02, Ryan Hallisey 
> wrote:
+1

-Ryan

- Original Message -
From: "Jeffrey Zhang" >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Sent: Monday, July 18, 2016 9:16:09 PM
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 to apply
I'd like to be the volunteer.

On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
> wrote:
On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke 
> wrote:
Hi Steve,

+1 to applying. I'll volunteer for the backport team also.

-Paul


On 18/07/16 13:07, Steven Dake (stdake) wrote:

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.
   Full details are here:


http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is
possible that we may not be able to apply for this tag until Liberty
falls into EOL.  Still I personally believe intent matters most, and our
intent has always been for these to be stable low-rate-of-change
no-feature-backport branches.  There are some exceptions I think we
would fit under for the Liberty case, so I think it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for
Kolla reviews specifically.  These folks would be the only folks that
could ACK patches in the stable branch maintenance queue.  Anyone could
continue to submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core
reviewers) or until there is a unanimous vote.  If there is not, then we
won't apply.  The deadline for this vote is July 25th.

Thanks!
-steve




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


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

+1 to apply for stable follows policy.
I would like to volunteer for the backport team.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [kolla] Monitoring tooling

[Matthias Runge]

On 25/07/16 09:57, Julien Danjou wrote:
> On Sun, Jul 24 2016, Mathias Ewald wrote:
> 
>> 5. InfluxDB to store metrics
>> 6. Grafana to dashboard metrics
> 
> Would be nice to leverage scalable and open source solution built your
> fellow OpenStack community, i.e. Gnocchi and its Grafana support.
> 
Yes, I'd like to repeat the question here: Is there any reason to
introduce another quite complex tool instead of something developed,
supported and used by the OpenStack community?

Matthias

-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

__
OpenStack Development Mailing 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] [telemetry] [vitrage] Mascot

[Ildikó Váncsa]

Thanks for the heads up. I checked briefly for logos on Google just to see 
what's around when I had the idea, but it seems I should've done a deeper/wider 
search... :) :(

Cheers,
Ildikó

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: July 25, 2016 14:30
> To: Afek, Ifat (Nokia - IL)
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [telemetry] [vitrage] Mascot
> 
> On Mon, Jul 25 2016, Afek, Ifat (Nokia - IL) wrote:
> 
> > A week ago I published Vitrage mascot alternatives[1] and notified
> > Heidi Joy Tretheway. One of our options was Suricata, which is another
> > name for a Meerkat. We have yet to conduct the official vote, but from
> > what I can tell this is quite a popular option (#2 at the moment).
> >
> > Seems like we have a Meerkat problem... :-)
> 
> Haha, you're right. There's even an open source named Suricata:
>  https://suricata-ids.org/
> 
> We'll probably need to pick something else. There seems to be some kind of 
> pun possible with Vitrage did you explore that btw?
> 
> --
> Julien Danjou
> // Free Software hacker
> // https://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

[openstack-dev] [Glare][Heat][Tacker][Murano][App-Catalog] How to validate your binary data in OpenStack

[Mikhail Fedosin]

Hello! Today I want to discuss with community one good feature in Glare -
artifact validation. In short Glare allows to validate binary data before
it's uploaded to store. For example, for Tosca we're able to check if
uploaded yaml is a valid template [1], for vm images we can test their
integrity. For sure, Glare supports quite sophisticated workflows, like
sending murano packages to external CI or validate Heat templates with
given environments.

So, I want to think out what validation is exactly required from Glare and
how we can help related projects to succeed, checking and reliably storing
their binary assets.

Best regards,
Mikhail Fedosin

[1]
https://review.openstack.org/#/c/337633/10/contrib/glare/openstack_app_catalog/artifacts.py@159
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] weekly subteam status report

[Loo, Ruby]

Hi,

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

Bugs (dtantsur)
===
- Stats (diff with 11 July 2016)
- dtantsur on PTO, no stats from me this week

Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)

* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- may still be able to get the nova patch merged this cycle for multitenance 
without portgroups: https://review.openstack.org/#/c/297895/
- "may" because we're past feature freeze

Node claims API (jroll, lintan)
===
* trello: https://trello.com/c/3ai8OQcA/25-node-claims-api
- this may be superceded by the Placement Engine: 
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html

Multiple compute hosts (jroll, devananda)
=
* trello: https://trello.com/c/OXYBHStp/7-multiple-compute-hosts
- some progress at nova midcycle: 
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099922.html

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Specification updated and is in need of reviews - 
https://review.openstack.org/#/c/294995/
- Cinerama has been kind enough to begin rebasing and correcting the volume 
connection information patch series which is required for boot from volume.
- Patch series starts at https://review.openstack.org/#/c/200983/

OpenStackClient plugin for ironic (thrash, dtantsur, rloo)
==
* trello: https://trello.com/c/ckqtq3kG/16-openstackclient-plugin-for-ironic
- patches for port and chassis commands ready for review: 
https://review.openstack.org/#/q/topic:bug/1526479

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- responded to patch comments, ready for re-review 
https://review.openstack.org/#/c/298461/ 
https://review.openstack.org/#/c/321865/

Keystone policy support (JayF, devananda)
=
* trello: https://trello.com/c/P5q3Es2z/15-keystone-policy-support
- code, unit tests, and docs are done. Split into several patches, starting 
with:
- https://review.openstack.org/#/c/325599/
- next up: integration with Bifrost

Active node creation (TheJulia)
===
* trello: https://trello.com/c/BwA91osf/22-active-node-creation
- Tempest test posted https://review.openstack.org/#/c/344975/
- Required some additional substrate and bug fixes in the tempest api 
client and utilities: https://review.openstack.org/#/c/344974/

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- console_utils: merged
- IPMITool driver interface: needs review (got a few +2s) 
https://review.openstack.org/#/c/293873/

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- https://review.openstack.org/#/c/346068/ helps refactoring some of the 
current root device hints code

Rescue mode (JayF)
==
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- Surprise, surprise: https://review.openstack.org/#/c/171878/ needs reviews

Inspector (dtansur)
===
- grenade for inspector unblocked, thx for escalating ; smoke test for 
inspector in merge conflict now (milan)

Bifrost (TheJulia)
==
- Interest has been expressed in adding ISC-dhcpd and keystone support in to 
bifrost.  TheJulia will be following up with those who have expressed interest 
this week.
- ISC-DHCP initial work started: https://review.openstack.org/#/c/343947 
(WIP: thou reviews are welcomed!)

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

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

[openstack-dev] [Infra] Meeting Tuesday July 26th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

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

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

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

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

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-19-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-19-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-19-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

Re: [openstack-dev] [Neutron] Project mascot - propose your choice/cast your vote

[Armando M.]

On 14 July 2016 at 10:00, Armando M.  wrote:

> Hi Neutrinos,
>
> Based on proposal [1], I prepared an etherpad to allow us to choose
> collaboratively a set of candidates for our mascot. Propose/vote away on
> [2]. You have time until Friday, July 22nd.
>

The deadline has passed, we have now a list of selected candidates to
choose from.

Please cast your vote [1]!

Cheers,
Armando

[1]
https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link


>
> After the deadline the most voted ones (depending on the number) will be
> sent to Heidi Joy @Foundation for the next step in the selection process.
>
> Feel free to reach out if you have any questions/suggestions.
>
> Happy hacking!
> Armando
>
> [1] http://www.openstack.org/project-mascots
> [2] https://etherpad.openstack.org/p/neutron-project-mascot
>

Today was the deadline for
__
OpenStack Development Mailing 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] [trove] weekly meeting canceled this week

[Amrith Kumar]

In view of the mid-cycle, the weekly meeting is canceled for this week.

-amrith

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

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

[Dave Walker]

Hi,

I'm not currently kolla-core, but I am a member of stable-maint-core (cross
project).  I've been pretty involved with Kolla this cycle, some 7 landed
commits and 34 patchsets pushed up.. So I have a good understanding of both
sides of the camp.  I'd be happy to throw my head into the ring for
kolla-stable-maint.

--
Kind Regards,
Dave Walker

On 22 July 2016 at 10:47, Kwasniewska, Alicja 
wrote:

> +1 too
>
>
>
> *From:* Mauricio Lima [mailto:mauricioli...@gmail.com]
> *Sent:* Tuesday, July 19, 2016 5:29 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [kolla][vote] Applying for stable-follows
> tag
>
>
>
> +1
>
>
>
> 2016-07-19 12:23 GMT-03:00 Vikram Hosakote (vhosakot)  >:
>
> +1 sure.
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC:  vhosakot
>
>
>
> *From: *Michał Jastrzębski 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, July 19, 2016 at 9:20 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
> *Subject: *Re: [openstack-dev] [kolla][vote] Applying for stable-follows
> tag
>
>
>
> +1 ofc
>
>
>
> On 19 July 2016 at 06:02, Ryan Hallisey  wrote:
>
> +1
>
>
>
> -Ryan
>
>
>
> - Original Message -
>
> From: "Jeffrey Zhang" 
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
> Sent: Monday, July 18, 2016 9:16:09 PM
>
> Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag
>
>
>
> +1 to apply
>
> I'd like to be the volunteer.
>
>
>
> On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
>
>  wrote:
>
> On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke 
> wrote:
>
> Hi Steve,
>
>
>
> +1 to applying. I'll volunteer for the backport team also.
>
>
>
> -Paul
>
>
>
>
>
> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>
>
>
> Hey Koalians,
>
>
>
> I'd like us to consider applying  for the stable follows policy tag.
>
>Full details are here:
>
>
>
>
>
>
> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>
>
>
> Because of the magic work we did to make liberty functional, it is
>
> possible that we may not be able to apply for this tag until Liberty
>
> falls into EOL.  Still I personally believe intent matters most, and our
>
> intent has always been for these to be stable low-rate-of-change
>
> no-feature-backport branches.  There are some exceptions I think we
>
> would fit under for the Liberty case, so I think it is worth a shot.
>
>
>
> I'd need 2-4 people to commit to joining the stable backport team for
>
> Kolla reviews specifically.  These folks would be the only folks that
>
> could ACK patches in the stable branch maintenance queue.  Anyone could
>
> continue to submit backport patches as they desire.
>
>
>
> I'll leave voting open for 1 week or until there I a majority (6 core
>
> reviewers) or until there is a unanimous vote.  If there is not, then we
>
> won't apply.  The deadline for this vote is July 25th.
>
>
>
> Thanks!
>
> -steve
>
>
>
>
>
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> +1 to apply for stable follows policy.
>
> I would like to volunteer for the backport team.
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
>
>
> __
>
> OpenStack Development Mailing 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
>
> 

Re: [openstack-dev] [kolla] Monitoring tooling

[Mathias Ewald]

Ahh right, I was blind. I just uploaded my latest telegraf ansible role
with pid_mode = host.

cheers
Mathias

2016-07-25 18:32 GMT+02:00 Michał Jastrzębski :

> mewald, we can add pid=host with kolla-docker. Look at nova libvirt
> container deployment
> As for telegraf/influx. Didnt influx require paid license to be
> deployed in cluster mode?
>
> On 25 July 2016 at 11:15, Mathias Ewald  wrote:
> > Hi Steve,
> >
> > I can try collectd, too, no problem. Though, I believe Telegraf is the
> > better match here. Reason: The way collectd talks to influxdb is via UDP
> > which cannot be load balanced with haproxy. Therefore, collectd might be
> a
> > bad choice if we target an influxdb cluster some day. Telegraf uses http
> > rest AND allow to configure multiple influxdb servers as outputs.
> >
> > cheers
> > Mathias
> >
> > 2016-07-25 17:45 GMT+02:00 Steven Dake (stdake) :
> >>
> >> This 218 issue looks like it has a full solution to containerizing
> >> telegraf.  I suspect collectd is VERY similar in nature – so if your up
> for
> >> two challenges instead of one, collectd would be a good second target :)
> >>
> >> Regards
> >> -steve
> >>
> >> From: Mathias Ewald 
> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >> 
> >> Date: Monday, July 25, 2016 at 4:48 AM
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> 
> >> Subject: Re: [openstack-dev] [kolla] Monitoring tooling
> >>
> >> I believe I found a possible (partial) solution:
> >> https://github.com/influxdata/telegraf/issues/218 I will test it and
> report
> >> back.
> >>
> >> 2016-07-25 12:58 GMT+02:00 Mathias Ewald :
> >>>
> >>> Excellent point ... I just checked what happens when running telegraf
> in
> >>> a container: You'll get paths like
> >>>
> >>> /etc/hostname
> >>> /etc/hosts
> >>> /var/log/kolla
> >>>
> >>> and others as available file systems. I guess it makes no sense at all
> >>> then to containerize monitoring agents ... Sensu is going to have the
> same
> >>> problems.
> >>>
> >>> Any suggestions?
> >>>
> >>>
> >>> 2016-07-25 9:39 GMT+02:00 Jeffrey Zhang :
> 
>  I am open to the choice of tools. But i am worried on thing: how to
>  get all the host disk usage when containerized the monitor tool?
> 
> 
> 
>  On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald 
> wrote:
>  > Understood.
>  >
>  > 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>  >>
>  >> On 25/07/16 06:38, Mathias Ewald wrote:
>  >> > Hi, correct me if wrong please: Isn't gnocchi more targeting
> cloud
>  >> > tenants rather than cloud ops? If that's the case I wont find
> info
>  >> > like
>  >> > "controller cpu usage" or "hypervisor memory usage".
>  >> >
>  >> > Cheers
>  >> > Mathias
>  >> >
>  >> Uhm, in this scenario, gnocchi just used as time-series database.
>  >> It's
>  >> up to you, what you feed in. collectd collects whatever you want
> and
>  >> put
>  >> it into your database.
>  >>
>  >> Best,
>  >> Matthias
>  >>
>  >> --
>  >> Matthias Runge 
>  >>
>  >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat:
> Grasbrunn,
>  >> Commercial register: Amtsgericht Muenchen, HRB 153243,
>  >> Managing Directors: Charles Cachera, Michael Cunningham,
>  >> Michael O'Neill, Eric Shander
>  >>
>  >>
>  >>
> __
>  >> OpenStack Development Mailing List (not for usage questions)
>  >> Unsubscribe:
>  >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >
>  >
>  >
>  >
>  > --
>  > Mobil: +49 176 10567592
>  > E-Mail: mew...@evoila.de
>  >
>  > evoila GmbH
>  > Wilhelm-Theodor-Römheld-Str. 34
>  > 55130 Mainz
>  > Germany
>  >
>  > Geschäftsführer: Johannes Hiemer
>  >
>  > Amtsgericht Mainz HRB 42719
>  >
>  > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>  > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>  > E-Mail
>  > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender
>  > und
>  > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die
> unbefugte
>  > Weitergabe dieser Mail ist nicht gestattet.
>  >
>  > This e-mail may contain confidential and/or privileged information.
> If
>  > You
>  > are not the intended recipient (or have received this e-mail in
> error)
>  > please notify the sender immediately and destroy this e-mail. Any
>  > unauthorised 

Re: [openstack-dev] [Neutron][oslo.db] Inspecting sqlite db during unit tests

[Carl Baldwin]

On Fri, Jul 22, 2016 at 8:47 AM, Mike Bayer  wrote:

>
>
> On 07/22/2016 04:02 AM, Kevin Benton wrote:
>
>> Now that we have switched to oslo.db for test provisioning the
>> responsibility of choosing a location lands
>> here:
>> https://github.com/openstack/oslo.db/blob/a79479088029e4fa51def91cb36bc652356462b6/oslo_db/sqlalchemy/provision.py#L505
>>
>> The problem is that when you specify OS_TEST_DBAPI_ADMIN_CONNECTION it
>> does end up creating the file, but then the logic above chooses a URL
>> based on the random ident. So you can find an sqlite file in your tmp
>> dir, it just won't be the one you asked for.
>>
>> It seems like a bug in the oslo.db logic, but the commit that added it
>> was part of a much larger refactor so I'm not sure if it was intentional
>> to ensure that no two tests used the same db.
>>
>
> it is, the testr system runs tests in multiple subprocesses and I think
> neutron has it set to four.  if they all shared the same sqlite database
> file you'd have failed tests.
>

A potential improvement might be to replace OS_TEST_DBAPI_ADMIN_CONNECTION
with another environment variable which could be used to provide a template
for generating multiple unique database names. That would make it a little
more intuitive. But, I can work with this for now.

Car
__
OpenStack Development Mailing 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][oslo.db] Inspecting sqlite db during unit tests

[Carl Baldwin]

On Fri, Jul 22, 2016 at 8:45 AM, Mike Bayer  wrote:

>
> On 07/22/2016 04:02 AM, Kevin Benton wrote:
>
>> Now that we have switched to oslo.db for test provisioning the
>> responsibility of choosing a location lands
>> here:
>> https://github.com/openstack/oslo.db/blob/a79479088029e4fa51def91cb36bc652356462b6/oslo_db/sqlalchemy/provision.py#L505
>>
>> The problem is that when you specify OS_TEST_DBAPI_ADMIN_CONNECTION it
>> does end up creating the file, but then the logic above chooses a URL
>> based on the random ident. So you can find an sqlite file in your tmp
>> dir, it just won't be the one you asked for.
>>
>> It seems like a bug in the oslo.db logic, but the commit that added it
>> was part of a much larger refactor so I'm not sure if it was intentional
>> to ensure that no two tests used the same db.
>>
>
> There is also a very recent commit to Neutron at
> https://review.openstack.org/#/c/332476/ , which I think changes the
> system to actually use the provisioning for the SQLite database as well,
> whereas before it might have been not taking effect.  But in any case, the
> OS_TEST_DBAPI_ADMIN_CONNECTION thing still works in that if you give it a
> file-based URL, provisioning should be putting the database files in /tmp.
> If your approach is "pdb.set_trace(); then look at the file", just do this:
>
> $ OS_TEST_DBAPI_ADMIN_CONNECTION=sqlite:///myfile.db
> .tox/functional/bin/python -m unittest
> neutron.tests.unit.db.test_db_base_plugin_v2.TestBasicGet.test_single_get_admin
>
> >
> /home/classic/dev/redhat/openstack/neutron/neutron/tests/unit/db/test_db_base_plugin_v2.py(790)test_single_get_admin()
> -> plugin = neutron.db.db_base_plugin_v2.NeutronDbPluginV2()
> (Pdb)
> (Pdb) self.engine.url
> sqlite:tmp/hjbckefatl.db
>
> then you can "sqlite3 /tmp/hjbckefatl.db" while the test is pending.
>

Thank you, that helps.
__
OpenStack Development Mailing 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]Nominating Vitalii Kulanov for python-fuelclient-core

[Igor Kalnitsky]

Vitaly's doing a great job. +2, no doubts!

On Mon, Jul 25, 2016 at 6:27 PM, Tatyana Leontovich
 wrote:
> A huge +1
>
> On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko  wrote:
>>
>> +1
>>
>> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko 
>> wrote:
>>>
>>> Hi Fuelers,
>>>
>>> Vitalii has been providing great code reviews and patches for some time.
>>> His recent commitment to help consolidating both old and new fuel clients
>>> and his bug-squashing activities show his willingness to step up and take
>>> responsibilities within the community. He can often be found in #fuel as
>>> vkulanov.
>>>
>>>
>>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
>>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t
>>>
>>>
>>> P. S. Sorry for sending this email twice — I realized I didn’t put a
>>> topic to the subject.
>>>
>>>
>>> - romcheg
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Michał Jastrzębski]

mewald, we can add pid=host with kolla-docker. Look at nova libvirt
container deployment
As for telegraf/influx. Didnt influx require paid license to be
deployed in cluster mode?

On 25 July 2016 at 11:15, Mathias Ewald  wrote:
> Hi Steve,
>
> I can try collectd, too, no problem. Though, I believe Telegraf is the
> better match here. Reason: The way collectd talks to influxdb is via UDP
> which cannot be load balanced with haproxy. Therefore, collectd might be a
> bad choice if we target an influxdb cluster some day. Telegraf uses http
> rest AND allow to configure multiple influxdb servers as outputs.
>
> cheers
> Mathias
>
> 2016-07-25 17:45 GMT+02:00 Steven Dake (stdake) :
>>
>> This 218 issue looks like it has a full solution to containerizing
>> telegraf.  I suspect collectd is VERY similar in nature – so if your up for
>> two challenges instead of one, collectd would be a good second target :)
>>
>> Regards
>> -steve
>>
>> From: Mathias Ewald 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Monday, July 25, 2016 at 4:48 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [kolla] Monitoring tooling
>>
>> I believe I found a possible (partial) solution:
>> https://github.com/influxdata/telegraf/issues/218 I will test it and report
>> back.
>>
>> 2016-07-25 12:58 GMT+02:00 Mathias Ewald :
>>>
>>> Excellent point ... I just checked what happens when running telegraf in
>>> a container: You'll get paths like
>>>
>>> /etc/hostname
>>> /etc/hosts
>>> /var/log/kolla
>>>
>>> and others as available file systems. I guess it makes no sense at all
>>> then to containerize monitoring agents ... Sensu is going to have the same
>>> problems.
>>>
>>> Any suggestions?
>>>
>>>
>>> 2016-07-25 9:39 GMT+02:00 Jeffrey Zhang :

 I am open to the choice of tools. But i am worried on thing: how to
 get all the host disk usage when containerized the monitor tool?



 On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
 > Understood.
 >
 > 2016-07-25 7:34 GMT+02:00 Matthias Runge :
 >>
 >> On 25/07/16 06:38, Mathias Ewald wrote:
 >> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
 >> > tenants rather than cloud ops? If that's the case I wont find info
 >> > like
 >> > "controller cpu usage" or "hypervisor memory usage".
 >> >
 >> > Cheers
 >> > Mathias
 >> >
 >> Uhm, in this scenario, gnocchi just used as time-series database.
 >> It's
 >> up to you, what you feed in. collectd collects whatever you want and
 >> put
 >> it into your database.
 >>
 >> Best,
 >> Matthias
 >>
 >> --
 >> Matthias Runge 
 >>
 >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
 >> Commercial register: Amtsgericht Muenchen, HRB 153243,
 >> Managing Directors: Charles Cachera, Michael Cunningham,
 >> Michael O'Neill, Eric Shander
 >>
 >>
 >> __
 >> OpenStack Development Mailing List (not for usage questions)
 >> Unsubscribe:
 >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >
 >
 >
 >
 > --
 > Mobil: +49 176 10567592
 > E-Mail: mew...@evoila.de
 >
 > evoila GmbH
 > Wilhelm-Theodor-Römheld-Str. 34
 > 55130 Mainz
 > Germany
 >
 > Geschäftsführer: Johannes Hiemer
 >
 > Amtsgericht Mainz HRB 42719
 >
 > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
 > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
 > E-Mail
 > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender
 > und
 > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
 > Weitergabe dieser Mail ist nicht gestattet.
 >
 > This e-mail may contain confidential and/or privileged information. If
 > You
 > are not the intended recipient (or have received this e-mail in error)
 > please notify the sender immediately and destroy this e-mail. Any
 > unauthorised copying, disclosure or distribution of the material in
 > this
 > e-mail is strictly forbidden.
 >
 >
 > __
 > OpenStack Development Mailing 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] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

[Thierry Carrez]

Sean Dague wrote:
> [...]
> After we brought that up in the room, we started going through other
> options. Someone brought up "what about making rootwrap always do this
> for privsep, instead of manually doing this for every project", and I
> volunteered to look at the code to figure out how hard it would be. That
> patch is up at https://review.openstack.org/344450.

I replied (removing my -1) on the review. Just a few answers to the
specific questions:

> I think the path forward here is about the following questions:
> 
> 1) how important are seamless upgrades in our vision?

Very

> 2) are root wrap rules supposed to be config (which is manually audited
> by installers)?

They are code, but were config files in the original design, and that
default persisted over time in some (most?) distros.

> 3) is the software supposed to take into account and adapt to the rules
> not being there (or disabled by an auditor)?

Depends on what you mean by software...

> 4) does always letting rootwrap call privsep regress our near term
> security in any real way (given the flaws in existing rules)?

Only for hypothetical non-OpenStack users, and only slightly.

> 5) what will most quickly allow us to transition into a non rootwrap
> world, with a privsep architecture that will give us a better security
> model?

Probably your patch, since it makes rootwrap a deprecated transitional
library enabling privsep. Which is fine as long as nobody else used
rootwrap (or all those hypothetical users would migrate to privsep).

In summary: I can live with the patch as proposed, as long as Angus is
fine with it.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [tripleo] TripleO Deep Dive session - July 28th

[Emilien Macchi]

Hi,

I propose to lead the next TripleO Deep Dive session and it will be
about Puppet (go figure).

Here's an agenda draft:
1) Introduction about Puppet OpenStack modules.
2) TripleO profiles under the hood
3) Managing data using Hiera and composable services
4) Write your own service step by step.

To join the Meeting:
https://bluejeans.com/275264340

To join via Browser:
https://bluejeans.com/275264340/browser

To join with Lync:
https://bluejeans.com/275264340/lync

To join via Room System:
Video Conferencing System: bjn.vc -or-199.48.152.152
Meeting ID : 275264340

To join via phone :
1)  Dial:
+44 203 574 6870
(see all numbers -
https://www.intercallonline.com/listNumbersByCode.action?confCode=3422501687)
2)  Enter Conference ID : 3422501687

The session will be recorded and I'll present some slides using my
tablet; but I won't share my screen and do terminal things (not needed
in this session), since I'm experiencing CPU consumption issues with
bluejeans on my laptop.

Any feedback is welcome,
-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] Proposing Gabriele Cerami for tripleo-quickstart core

[John Trowbridge]

Since there were no objections to this, I have added Gabriele to the
tripleo-quickstart core group.

This also means that all patches to tripleo-quickstart now require 2x +2
to merge.

On 07/18/2016 11:06 AM, John Trowbridge wrote:
> Howdy,
> 
> I would like to propose Gabriele (panda on IRC), for tripleo-quickstart
> core. He has worked on some pretty major features for the project
> (explicit teardown, devmode), and has a good understanding of the code base.
> 
> This will bring us to three dedicated core reviewers for
> tripleo-quickstart (myself and larsks being the other two), so I would
> also like to implement a 2x +2 policy at this time. Note, that all cores
> of TripleO are also cores on tripleo-quickstart, and should feel free to
> +2 changes as they are comfortable.
> 
> If there are no objections, I will put in a change at the end of the week.
> 
> Thanks,
> 
> - trown
> 
> __
> OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Mathias Ewald]

Hi Steve,

I can try collectd, too, no problem. Though, I believe Telegraf is the
better match here. Reason: The way collectd talks to influxdb is via UDP
which cannot be load balanced with haproxy. Therefore, collectd might be a
bad choice if we target an influxdb cluster some day. Telegraf uses http
rest AND allow to configure multiple influxdb servers as outputs.

cheers
Mathias

2016-07-25 17:45 GMT+02:00 Steven Dake (stdake) :

> This 218 issue looks like it has a full solution to containerizing
> telegraf.  I suspect collectd is VERY similar in nature – so if your up for
> two challenges instead of one, collectd would be a good second target :)
>
> Regards
> -steve
>
> From: Mathias Ewald 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, July 25, 2016 at 4:48 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla] Monitoring tooling
>
> I believe I found a possible (partial) solution:
> https://github.com/influxdata/telegraf/issues/218 I will test it and
> report back.
>
> 2016-07-25 12:58 GMT+02:00 Mathias Ewald :
>
>> Excellent point ... I just checked what happens when running telegraf in
>> a container: You'll get paths like
>>
>> /etc/hostname
>> /etc/hosts
>> /var/log/kolla
>>
>> and others as available file systems. I guess it makes no sense at all
>> then to containerize monitoring agents ... Sensu is going to have the same
>> problems.
>>
>> Any suggestions?
>>
>>
>> 2016-07-25 9:39 GMT+02:00 Jeffrey Zhang :
>>
>>> I am open to the choice of tools. But i am worried on thing: how to
>>> get all the host disk usage when containerized the monitor tool?
>>>
>>>
>>>
>>> On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
>>> > Understood.
>>> >
>>> > 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>>> >>
>>> >> On 25/07/16 06:38, Mathias Ewald wrote:
>>> >> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>>> >> > tenants rather than cloud ops? If that's the case I wont find info
>>> like
>>> >> > "controller cpu usage" or "hypervisor memory usage".
>>> >> >
>>> >> > Cheers
>>> >> > Mathias
>>> >> >
>>> >> Uhm, in this scenario, gnocchi just used as time-series database. It's
>>> >> up to you, what you feed in. collectd collects whatever you want and
>>> put
>>> >> it into your database.
>>> >>
>>> >> Best,
>>> >> Matthias
>>> >>
>>> >> --
>>> >> Matthias Runge 
>>> >>
>>> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>> >> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>> >> Managing Directors: Charles Cachera, Michael Cunningham,
>>> >> Michael O'Neill, Eric Shander
>>> >>
>>> >>
>>> __
>>> >> OpenStack Development Mailing List (not for usage questions)
>>> >> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Mobil: +49 176 10567592
>>> > E-Mail: mew...@evoila.de
>>> >
>>> > evoila GmbH
>>> > Wilhelm-Theodor-Römheld-Str. 34
>>> > 55130 Mainz
>>> > Germany
>>> >
>>> > Geschäftsführer: Johannes Hiemer
>>> >
>>> > Amtsgericht Mainz HRB 42719
>>> >
>>> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>>> > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>>> E-Mail
>>> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender
>>> und
>>> > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>>> > Weitergabe dieser Mail ist nicht gestattet.
>>> >
>>> > This e-mail may contain confidential and/or privileged information. If
>>> You
>>> > are not the intended recipient (or have received this e-mail in error)
>>> > please notify the sender immediately and destroy this e-mail. Any
>>> > unauthorised copying, disclosure or distribution of the material in
>>> this
>>> > e-mail is strictly forbidden.
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Mobil: +49 176 10567592
>> E-Mail: 

Re: [openstack-dev] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

[Jimmy Mcarthur]

If anyone else is out there that isn't sure where to respond, please 
send a ticket into speakersupp...@openstack.org and I'll get you all 
squared away.


THanks,
Jimmy

Ben Nemec wrote:

Sent.  Thanks for looking into this.

-Ben

On 07/25/2016 10:58 AM, Jimmy Mcarthur wrote:

speakersupp...@openstack.org, plus the track chairs, should be cc'd on
any email from the Track Chairs too. Would you mind forwarding me a copy
of the email you received?

Thank you,
Jimmy McArthur
Summit Speaker Support

Ulrich Kleber wrote:

Hi,
it seems the tooling didn't consider that.
I forward this for you to the track chairs, since I am not sure whether you 
will be able to post to the mailing list.
Thanks for letting us know.
Cheers,
Uli

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com]
Sent: Monday, 25 July, 2016 17:32
To: Nikhil Komawar; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][summit] Responding to questions on submitted 
summit talk?

Okay, I sent the question there too.  I figured I would try -dev because 
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:

I think this may be the wrong place to ask such info because all the
process on summit presentation is being handled by folks who are not
necessarily openstack developers.

Please follow:
https://www.openstack.org/summit/barcelona-2016/call-for-presentations
/selection-process and send email to summit [at] openstack [dot] org
  as required.

On 7/25/16 10:55 AM, Ben Nemec wrote:

Hi,

I got a question from one of the track chairs on my presentation, but
the email came from a noreply address and I don't see anywhere on the
submission page that I can respond to feedback.  How are we supposed
to do that?

Thanks.

-Ben

_
_ OpenStack Development Mailing 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-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs




__
OpenStack Development Mailing 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][summit] Responding to questions on submitted summit talk?

[Nick Chase]

Ben --

I'm the one who asked you, I believe; I'll get with you privately. Thanks!

  Nick

On 7/25/2016 11:32 AM, Ben Nemec wrote:

Okay, I sent the question there too.  I figured I would try -dev because
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:

I think this may be the wrong place to ask such info because all the
process on summit presentation is being handled by folks who are not
necessarily openstack developers.

Please follow:
https://www.openstack.org/summit/barcelona-2016/call-for-presentations/selection-process
and send email to summit [at] openstack [dot] org
 as required.

On 7/25/16 10:55 AM, Ben Nemec wrote:

Hi,

I got a question from one of the track chairs on my presentation, but
the email came from a noreply address and I don't see anywhere on the
submission page that I can respond to feedback.  How are we supposed to
do that?

Thanks.

-Ben

__
OpenStack Development Mailing 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



--
Nick Chase, Head of Technical and Marketing Content, Mirantis
Editor in Chief, OpenStack:Unlocked
 

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

Re: [openstack-dev] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

[Ben Nemec]

Sent.  Thanks for looking into this.

-Ben

On 07/25/2016 10:58 AM, Jimmy Mcarthur wrote:
> speakersupp...@openstack.org, plus the track chairs, should be cc'd on
> any email from the Track Chairs too. Would you mind forwarding me a copy
> of the email you received?
> 
> Thank you,
> Jimmy McArthur
> Summit Speaker Support
> 
> Ulrich Kleber wrote:
>> Hi,
>> it seems the tooling didn't consider that. 
>> I forward this for you to the track chairs, since I am not sure whether you 
>> will be able to post to the mailing list.
>> Thanks for letting us know.
>> Cheers,
>> Uli
>>
>> -Original Message-
>> From: Ben Nemec [mailto:openst...@nemebean.com] 
>> Sent: Monday, 25 July, 2016 17:32
>> To: Nikhil Komawar; OpenStack Development Mailing List (not for usage 
>> questions)
>> Subject: Re: [openstack-dev] [all][summit] Responding to questions on 
>> submitted summit talk?
>>
>> Okay, I sent the question there too.  I figured I would try -dev because 
>> somebody here might know and it's of general interest to the community.
>> I'll let everyone know if/when I get a response from the summit folks.
>>
>> On 07/25/2016 10:15 AM, Nikhil Komawar wrote:
>>> I think this may be the wrong place to ask such info because all the 
>>> process on summit presentation is being handled by folks who are not 
>>> necessarily openstack developers.
>>>
>>> Please follow:
>>> https://www.openstack.org/summit/barcelona-2016/call-for-presentations
>>> /selection-process and send email to summit [at] openstack [dot] org 
>>>  as required.
>>>
>>> On 7/25/16 10:55 AM, Ben Nemec wrote:
 Hi,

 I got a question from one of the track chairs on my presentation, but 
 the email came from a noreply address and I don't see anywhere on the 
 submission page that I can respond to feedback.  How are we supposed 
 to do that?

 Thanks.

 -Ben

 _
 _ OpenStack Development Mailing 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-track-chairs mailing list
>> openstack-track-cha...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs
> 


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

Re: [openstack-dev] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

[Jimmy Mcarthur]

speakersupp...@openstack.org, plus the track chairs, should be cc'd on 
any email from the Track Chairs too. Would you mind forwarding me a copy 
of the email you received?


Thank you,
Jimmy McArthur
Summit Speaker Support

Ulrich Kleber wrote:

Hi,
it seems the tooling didn't consider that.
I forward this for you to the track chairs, since I am not sure whether you 
will be able to post to the mailing list.
Thanks for letting us know.
Cheers,
Uli

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com]
Sent: Monday, 25 July, 2016 17:32
To: Nikhil Komawar; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][summit] Responding to questions on submitted 
summit talk?

Okay, I sent the question there too.  I figured I would try -dev because 
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:

I think this may be the wrong place to ask such info because all the
process on summit presentation is being handled by folks who are not
necessarily openstack developers.

Please follow:
https://www.openstack.org/summit/barcelona-2016/call-for-presentations
/selection-process and send email to summit [at] openstack [dot] org
  as required.

On 7/25/16 10:55 AM, Ben Nemec wrote:

Hi,

I got a question from one of the track chairs on my presentation, but
the email came from a noreply address and I don't see anywhere on the
submission page that I can respond to feedback.  How are we supposed
to do that?

Thanks.

-Ben

_
_ OpenStack Development Mailing 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-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs


__
OpenStack Development Mailing 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][summit] Responding to questions on submitted summit talk?

[Ulrich Kleber]

Hi,
it seems the tooling didn't consider that. 
I forward this for you to the track chairs, since I am not sure whether you 
will be able to post to the mailing list.
Thanks for letting us know.
Cheers,
Uli

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com] 
Sent: Monday, 25 July, 2016 17:32
To: Nikhil Komawar; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][summit] Responding to questions on submitted 
summit talk?

Okay, I sent the question there too.  I figured I would try -dev because 
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:
> I think this may be the wrong place to ask such info because all the 
> process on summit presentation is being handled by folks who are not 
> necessarily openstack developers.
> 
> Please follow:
> https://www.openstack.org/summit/barcelona-2016/call-for-presentations
> /selection-process and send email to summit [at] openstack [dot] org 
>  as required.
> 
> On 7/25/16 10:55 AM, Ben Nemec wrote:
>> Hi,
>>
>> I got a question from one of the track chairs on my presentation, but 
>> the email came from a noreply address and I don't see anywhere on the 
>> submission page that I can respond to feedback.  How are we supposed 
>> to do that?
>>
>> Thanks.
>>
>> -Ben
>>
>> _
>> _ OpenStack Development Mailing 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] [cinder][nova] Cancellation of this week's Cinder-Nova meeting

[Ildikó Váncsa]

Hi,

As we had a session about the Cinder-Nova API changes in progress last week 
during the mid-cycles of these two modules we cancel the today's meeting.

You can find meeting logs on this etherpad starting from line 50: 
https://etherpad.openstack.org/p/nova-newton-midcycle

Best Regards,
/Ildikó

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

Re: [openstack-dev] [kolla] Monitoring tooling

[Steven Dake (stdake)]

This 218 issue looks like it has a full solution to containerizing telegraf.  I 
suspect collectd is VERY similar in nature – so if your up for two challenges 
instead of one, collectd would be a good second target :)

Regards
-steve

From: Mathias Ewald >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, July 25, 2016 at 4:48 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] Monitoring tooling

I believe I found a possible (partial) solution: 
https://github.com/influxdata/telegraf/issues/218 I will test it and report 
back.

2016-07-25 12:58 GMT+02:00 Mathias Ewald 
>:
Excellent point ... I just checked what happens when running telegraf in a 
container: You'll get paths like

/etc/hostname
/etc/hosts
/var/log/kolla

and others as available file systems. I guess it makes no sense at all then to 
containerize monitoring agents ... Sensu is going to have the same problems.

Any suggestions?


2016-07-25 9:39 GMT+02:00 Jeffrey Zhang 
>:
I am open to the choice of tools. But i am worried on thing: how to
get all the host disk usage when containerized the monitor tool?



On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald 
> wrote:
> Understood.
>
> 2016-07-25 7:34 GMT+02:00 Matthias Runge 
> >:
>>
>> On 25/07/16 06:38, Mathias Ewald wrote:
>> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>> > tenants rather than cloud ops? If that's the case I wont find info like
>> > "controller cpu usage" or "hypervisor memory usage".
>> >
>> > Cheers
>> > Mathias
>> >
>> Uhm, in this scenario, gnocchi just used as time-series database. It's
>> up to you, what you feed in. collectd collects whatever you want and put
>> it into your database.
>>
>> Best,
>> Matthias
>>
>> --
>> Matthias Runge >
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham,
>> Michael O'Neill, Eric Shander
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Mobil: +49 176 10567592
> E-Mail: mew...@evoila.de
>
> evoila GmbH
> Wilhelm-Theodor-Römheld-Str. 34
> 55130 Mainz
> Germany
>
> Geschäftsführer: Johannes Hiemer
>
> Amtsgericht Mainz HRB 42719
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If You
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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



--
Mobil: +49 176 10567592
E-Mail: mew...@evoila.de

evoila GmbH
Wilhelm-Theodor-Römheld-Str. 34
55130 Mainz
Germany

Geschäftsführer: Johannes Hiemer

Amtsgericht Mainz HRB 42719

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender 

Re: [openstack-dev] [all][summit] Responding to questions on submitted summit talk?

[Ben Nemec]

Okay, I sent the question there too.  I figured I would try -dev because
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:
> I think this may be the wrong place to ask such info because all the
> process on summit presentation is being handled by folks who are not
> necessarily openstack developers.
> 
> Please follow:
> https://www.openstack.org/summit/barcelona-2016/call-for-presentations/selection-process
> and send email to summit [at] openstack [dot] org
>  as required.
> 
> On 7/25/16 10:55 AM, Ben Nemec wrote:
>> Hi,
>>
>> I got a question from one of the track chairs on my presentation, but
>> the email came from a noreply address and I don't see anywhere on the
>> submission page that I can respond to feedback.  How are we supposed to
>> do that?
>>
>> Thanks.
>>
>> -Ben
>>
>> __
>> OpenStack Development Mailing 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] [octavia] ssl re-encryption in octavia

[Michael Johnson]

Brandon,

You are correct, TLS re-encryption has not yet been implemented.  It
is still a feature we would like to have, but no one has done the
coding yet.

Michael


On Fri, Jul 22, 2016 at 8:21 PM, Brandon Logan
 wrote:
> I do not believe it is in it and I don't know if anyone is working on
> it.  I believe it has pushed down the priority stack, but someone might
> correct me if I'm wrong.
>
> Thanks,
> Brandon
> On Fri, 2016-07-22 at 16:00 -0700, Akshay Kumar Sanghai wrote:
>> Hi,
>> I saw in specs of kilo that ssl re-encryption will be introduced in
>> later phase. Is the ssl re-encryption feature available in the mitaka
>> release? I understand ssl offload is available, but I want to try the
>> ssl re-encryption on octavia lbaas.
>> This link refers to v1
>> probably https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL. Please
>> redirect me to any documentation if ssl re-encryption is there.
>>
>>
>> Thanks
>> Akshay Sanghai
>> __
>> OpenStack Development Mailing 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] [Fuel]Nominating Vitalii Kulanov for python-fuelclient-core

[Tatyana Leontovich]

A huge +1

On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko  wrote:

> +1
>
> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko 
> wrote:
>
>> Hi Fuelers,
>>
>> Vitalii has been providing great code reviews and patches for some time.
>> His recent commitment to help consolidating both old and new fuel clients
>> and his bug-squashing activities show his willingness to step up and take
>> responsibilities within the community. He can often be found in #fuel as
>> vkulanov.
>>
>>
>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t
>>
>>
>> P. S. Sorry for sending this email twice — I realized I didn’t put a
>> topic to the subject.
>>
>>
>> - romcheg
>>
>> __
>> OpenStack Development Mailing 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][summit] Responding to questions on submitted summit talk?

[Nikhil Komawar]

I think this may be the wrong place to ask such info because all the
process on summit presentation is being handled by folks who are not
necessarily openstack developers.

Please follow:
https://www.openstack.org/summit/barcelona-2016/call-for-presentations/selection-process
and send email to summit [at] openstack [dot] org
 as required.

On 7/25/16 10:55 AM, Ben Nemec wrote:
> Hi,
>
> I got a question from one of the track chairs on my presentation, but
> the email came from a noreply address and I don't see anywhere on the
> submission page that I can respond to feedback.  How are we supposed to
> do that?
>
> Thanks.
>
> -Ben
>
> __
> OpenStack Development Mailing 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,
Nikhil


__
OpenStack Development Mailing 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][Nova][OVN] Is there anythig we should consider about VM migration in OVN

[Richard Theis]

 wrote on 07/21/2016 10:13:58 PM:

> From: 
> To: "openstack-dev" 
> Date: 07/21/2016 10:16 PM
> Subject: [openstack-dev] [Neutron][Nova][OVN] Is there anythig we 
> should consider about VM migration in OVN
> 
> Hi all 
> 
> There is a patch[1]  add ability to OVN to update port status in 
> Neutron DB when creating VM.

Patch [1] was for the OVN core plugin.  networking-ovn now uses an ML2
driver.  Does the VM live migration problem that you are describing
impact the latest code as well?  If so, please file a bug [3] with
the details.

[3] https://bugs.launchpad.net/networking-ovn/+filebug

Richard

> 
> In this patch,  it will call method in ml2 mech_driver to change 
> port status in Neutron DB,  which invoked by ovsdb monitor. 
> 
> But in vm live migration scenario, it should not update port status 
> at first stage(pre_live_migraion)  in destination host, as there in 
> no binding host in port bind profile now.  And later in the last 
> stage(post_live_migration)[2] it should  update port status to ACTIVE. 
> 
> So if we should consider the vm live migration as described 
> previously, and is there anything else we should  consider about vm 
> migration in OVN?
> 
> Thank
> Jingting
> 
> [1] https://review.openstack.org/#/c/178826/
> [2] http://paste.openstack.org/show/198298/
> 
__
> OpenStack Development Mailing 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] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

[Cammann, Tom]

+1 great addition to the team

From: Hongbin Lu 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, 22 July 2016 at 21:27
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core 
reviewer team

Hi all,

Spyros has consistently contributed to Magnum for a while. In my opinion, what 
differentiate him from others is the significance of his contribution, which 
adds concrete value to the project. For example, the operator-oriented install 
guide he delivered attracts a significant number of users to install Magnum, 
which facilitates the adoption of the project. I would like to emphasize that 
the Magnum team has been working hard but struggling to increase the adoption, 
and Spyros’s contribution means a lot in this regards. He also completed 
several essential and challenging tasks, such as adding support for OverlayFS, 
adding Rally job for Magnum, etc. In overall, I am impressed by the amount of 
high-quality patches he submitted. He is also helpful in code reviews, and his 
comments often help us identify pitfalls that are not easy to identify. He is 
also very active in IRC and ML. Based on his contribution and expertise, I 
think he is qualified to be a Magnum core reviewer.

I am happy to propose Spyros to be a core reviewer of Magnum team. According to 
the OpenStack Governance process [1], we require a minimum of 4 +1 votes from 
Magnum core reviewers within a 1 week voting window (consider this proposal as 
a +1 vote from me). A vote of -1 is a veto. If we cannot get enough votes or 
there is a veto vote prior to the end of the voting window, Spyros is not able 
to join the core team and needs to wait 30 days to reapply.

The voting is open until Thursday July 29st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,
Hongbin
__
OpenStack Development Mailing 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][summit] Responding to questions on submitted summit talk?

[Ben Nemec]

Hi,

I got a question from one of the track chairs on my presentation, but
the email came from a noreply address and I don't see anywhere on the
submission page that I can respond to feedback.  How are we supposed to
do that?

Thanks.

-Ben

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

Re: [openstack-dev] [nova][neutron] neutron port duplication

[John Garbutt]

On 22 July 2016 at 14:54, Andrey Volkov  wrote:
> Hi, nova and neutron teams,
>
> While booting new instance nova requests port for that instance in the
> neutron.
> It's possible to have a situation when neutron doesn't response due timeout
> or connection break and nova retries port creation. It definitely results in
> ports duplication for instance [1].
>
> To solve this issue different methods can be applied:
> - Transactional port creating in neutron (when it's possible to rollback if
> the client doesn't accept the answer).
> - Idempotent port creation (when the client provides some id and server does
> get_or_create on this id).
> - Getting port on the client before next retry attempt (idempotent port
> creation on the client side).
>
> Questions to community:
> - Am I right with my thoughts? Does the problem exist? Maybe there is tool
> already can solve it?
> - Which method is better to apply to solve the problem if it exists?
>
> [1] https://bugs.launchpad.net/nova/+bug/1603909

So I am currently taking a close look at Nova and Neutron interactions
to eliminate these kinds of things.

I hope to work with Neutron to evolve our APIs to try and eliminate
this kind of thing, more systematically. I have promised to work with
Nova and Neutron to get a plan together for the next summit.

I am super happy you have tracked down one of failure modes here.

If we hit a port create timeout, it possible Neutron has created the
port, but Nova never gets the port uuid, so doesn't delete that port
during its cleanup.

I think we probably need to list the ports in neutron when working out
what to delete, to make sure we don't leak ports due to timeouts.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing 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] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

[wkq5325]

+1 from me.  Really good work!



发自我的小米手机在 Ton Ngo ，2016年7月25日 下午10:15写道：+1, it has been a pleasure to work with Spyros.Ton Ngo,Hongbin Lu ---07/22/2016 01:30:26 PM---Hi all, Spyros has consistently contributed to Magnum for a while. In my opinion, what differentiateFrom:Hongbin Lu To:"OpenStack Development Mailing List (not for usage questions)" Date:07/22/2016 01:30 PMSubject:[openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum corereviewer teamHi all, Spyros has consistently contributed to Magnum for a while. In my opinion, what differentiate him from others is the significance of his contribution, which adds concrete value to the project. For example, the operator-oriented install guide he delivered attracts a significant number of users to install Magnum, which facilitates the adoption of the project. I would like to emphasize that the Magnum team has been working hard but struggling to increase the adoption, and Spyros’s contribution means a lot in this regards. He also completed several essential and challenging tasks, such as adding support for OverlayFS, adding Rally job for Magnum, etc. In overall, I am impressed by the amount of high-quality patches he submitted. He is also helpful in code reviews, and his comments often help us identify pitfalls that are not easy to identify. He is also very active in IRC and ML. Based on his contribution and expertise, I think he is qualified to be a Magnum core reviewer. I am happy to propose Spyros to be a core reviewer of Magnum team. According to the OpenStack Governance process [1], we require a minimum of 4 +1 votes from Magnum core reviewers within a 1 week voting window (consider this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get enough votes or there is a veto vote prior to the end of the voting window, Spyros is not able to join the core team and needs to wait 30 days to reapply. The voting is open until Thursday July 29st. [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Best regards,Hongbin__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

Re: [openstack-dev] [neutron] how to create initial db migration script to sub-project

[Henry Gessau]

Moshe Levi  wrote:
> Hi Henry,
> 
> Thank for the reply. 
> 
> I tried to do the following with your commit [2]:

Note I just updated my patch for a minor problem.

> 1. I create models.py in networking_mlnx/db.

Nit: I would recommend creating all model under networking_mlnx/db/models/.

> 2. mysql -e "drop database neutron; create database neutron;"
> 3. neutron-db-manage --subproject=neutron  upgrade heads

You should upgrade all heads here (leave out the --subproject option).

> 4. neutron-db-manage --subproject=networking-mlnx  revision -m "test" --expend

Hopefully you spelled it correctly: --expand. :)

> 
> Now I don't see the errors as before, but the migration script that was 
> generated 
> Looks like [3] and doesn't contain the new table.

Yes, I can reproduce this problem. We need to set up a head.py file that
includes all mlnx models. I need to remember how to correctly set up this
inclusion and I will get back to you.

> 
> Am I doing it wrong?  
> 
> [3] - 
> from alembic import op
> import sqlalchemy as sa
> 
> 
> # revision identifiers, used by Alembic.
> revision = 'cbb661581082'
> down_revision = '65b6db113427b9_initial_contract'
> 
> 
> def upgrade():
> pass
> 
> -Original Message-
> From: Henry Gessau [mailto:hen...@gessau.net] 
> Sent: Sunday, July 24, 2016 9:21 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [neutron] how to create initial db migration 
> script to sub-project
> 
> Hi Moshe,
> 
> It has been a while since a neutron sub-project initialized new alembic 
> migrations, so the devref is out of date, sorry. Let me help you get this 
> sorted out and then I can update the devref with the latest info.
> 
> First you need to create the initial migration for each branch (expand and 
> contract). This is done by submitting a patch -- the contents of which used 
> to be crafted by copying a similar patch from another sub-project. The 
> patches to copy from are now out of date, so I have created a patch [2] for 
> you and we can use this as the new "template patch for initial alembic 
> migrations."
> 
> Some more comments inline ...
> 
> Moshe Levi  wrote:
>> Hi,
>>
>> I am trying to create initial db for the networking-mlnx project. 
>> I am following this neutron alembic documentation [1].
>> I added a entrypoint to networking-mlnx setup.cfg 
>> neutron.db.alembic_migrations =
>> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
>> I added model.py file to networking-mlnx/networking_mlnx/db
>> And I run python setup.py develop to regenerate the entrypoint
>>
>> I am running the following commands:
>> 1. mysql -e "drop database neutron; create database neutron;"
>> 2. neutron-db-manage --subproject=neutron  upgrade heads
> 
> So far so good.
> 
>> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
>> --autogenerate
> 
> Because we now require split (expand and contract) branches, you must now 
> specify --expand or --contract *instead of* --autogenerate. I will update the 
> devref about this.
> 
>> I am getting the following errors:
>> INFO  [alembic.runtime.migration] Context impl MySQLImpl.
>>
>> INFO  [alembic.runtime.migration] Will assume non-transactional DDL. 
>>
>> INFO  [alembic.autogenerate.compare] Detected removed table 
>> u'alembic_version'  
>> INFO  [alembic.autogenerate.compare] Detected removed index 
>> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>>   Generating 
>> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>>  ... done
>>   OK 
>>  
>>
>> Traceback (most recent call last):   
>>  
>>
>>   File "/usr/bin/neutron-db-manage", line 10, in 
>>  
>>
>> sys.exit(main()) 
>>  
>>
>>   File 
>> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>>  line 689, in main
>> return_val |= bool(CONF.command.func(config, CONF.command.name)) 
>>  
>>
>>   File 
>> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>>  line 275, in 

[openstack-dev] [puppet] weekly meeting #88

[Emilien Macchi]

Hi Puppeteers!

We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4.

Here's a first agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160726

Feel free to add topics, and any outstanding bug and patch.

See you tomorrow!
Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven Tests (DDT)

[John Garbutt]

On 25 July 2016 at 13:56, Bhor, Dinesh  wrote:
>
>
> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Monday, July 25, 2016 5:53 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven 
> Tests (DDT)
>
> On 07/25/2016 08:05 AM, Daniel P. Berrange wrote:
>> On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
>>> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
 On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
> On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:
>
> I agree that it's not a bug. I also agree that it helps in some
> specific types of tests which are doing some kind of input
> validation (like the patch you've proposed) or are simply iterating
> over some list of values (status values on a server instance for example).
>
> Using DDT in Nova has come up before and one of the concerns was
> hiding details in how the tests are run with a library, and if
> there would be a learning curve. Depending on the usage, I
> personally don't have a problem with it. When I used it in manila
> it took a little getting used to but I was basically just looking
> at existing tests and figuring out what they were doing when adding new 
> ones.

 I don't think there's significant learning curve there - the way it
 lets you annotate the test methods is pretty easy to understand and
 the ddt docs spell it out clearly for newbies. We've far worse
 things in our code that create a hard learning curve which people
 will hit first :-)

 People have essentially been re-inventing ddt in nova tests already
 by defining one helper method and them having multiple tests methods
 all calling the same helper with a different dataset. So ddt is just
 formalizing what we're already doing in many places, with less code
 and greater clarity.

> I definitely think DDT is easier to use/understand than something
> like testscenarios, which we're already using in Nova.

 Yeah, testscenarios feels little over-engineered for what we want
 most of the time.
>>>
>>> Except, DDT is way less clear (and deterministic) about what's going
>>> on with the test name munging. Which means failures are harder to
>>> track back to individual tests and data load. So debugging the failures is 
>>> harder.
>>
>> I'm not sure what you think is unclear - given an annotated test:
>>
>>@ddt.data({"foo": "test", "availability_zone": "nova1"},
>>   {"name": "  test  ", "availability_zone": "nova1"},
>>   {"name": "", "availability_zone": "nova1"},
>>   {"name": "x" * 256, "availability_zone": "nova1"},
>>   {"name": "test", "availability_zone": "x" * 256},
>>   {"name": "test", "availability_zone": "  nova1  "},
>>   {"name": "test", "availability_zone": ""},
>>   {"name": "test", "availability_zone": "nova1", "foo": "bar"})
>> def test_create_invalid_create_aggregate_data(self, value):
>>
>> It is generated one test for each data item:
>>
>>  test_create_invalid_create_aggregate_data_1
>>  test_create_invalid_create_aggregate_data_2
>>  test_create_invalid_create_aggregate_data_3
>>  test_create_invalid_create_aggregate_data_4
>>  test_create_invalid_create_aggregate_data_5
>>  test_create_invalid_create_aggregate_data_6
>>  test_create_invalid_create_aggregate_data_7
>>  test_create_invalid_create_aggregate_data_8
>>
>> This seems about as obvious as you can possibly get
>
> At least when this was attempted to be introduced into Tempest, the naming 
> was a lot less clear, maybe it got better. But I still think milestone 3 
> isn't the time to start a thing like this.
>
> -Sean
>
> Hi Sean,
>
> IMO it is possible to have a descriptive name to test cases using DDT.
>
> For ex.,
>
> @ddt.data(annotated('missing_name', {"foo": "test", "availability_zone": 
> "nova1"}),
>   annotated('name_greater_than_255_characters', {"name": "x" * 256, 
> "availability_zone": "nova1"}))
> def test_create_invalid_aggregate_data(self, value):
>
>
> it generates following test names:
>
> test_create_invalid_aggregate_data_2_name_greater_than_255_characters
> test_create_invalid_aggregate_data_1_missing_name
>
> I think with this it is easy to identify which test scenario has failed.
>
> Same is implemented in openstack/zaqar.
> https://github.com/openstack/zaqar/blob/master/zaqar/tests/functional/wsgi/v1/test_queues.py#L87

That descriptive name does help with some of my fears (although I wish
it were simpler, maybe just using kwargs in data).

I am +1 sdague's not now. I know we normally allow unit test things,
but we have such a huge backlog, full of really useful changes we
should merge instead, I would rather we all looked at those.

Thanks,

Re: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

[Ton Ngo]

+1, it has been a pleasure to work with Spyros.
Ton Ngo,



From:   Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/22/2016 01:30 PM
Subject:[openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum
corereviewer team



Hi all,

Spyros has consistently contributed to Magnum for a while. In my opinion,
what differentiate him from others is the significance of his contribution,
which adds concrete value to the project. For example, the
operator-oriented install guide he delivered attracts a significant number
of users to install Magnum, which facilitates the adoption of the project.
I would like to emphasize that the Magnum team has been working hard but
struggling to increase the adoption, and Spyros’s contribution means a lot
in this regards. He also completed several essential and challenging tasks,
such as adding support for OverlayFS, adding Rally job for Magnum, etc. In
overall, I am impressed by the amount of high-quality patches he submitted.
He is also helpful in code reviews, and his comments often help us identify
pitfalls that are not easy to identify. He is also very active in IRC and
ML. Based on his contribution and expertise, I think he is qualified to be
a Magnum core reviewer.

I am happy to propose Spyros to be a core reviewer of Magnum team.
According to the OpenStack Governance process [1], we require a minimum of
4 +1 votes from Magnum core reviewers within a 1 week voting window
(consider this proposal as a +1 vote from me). A vote of -1 is a veto. If
we cannot get enough votes or there is a veto vote prior to the end of the
voting window, Spyros is not able to join the core team and needs to wait
30 days to reapply.

The voting is open until Thursday July 29st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,
Hongbin
__
OpenStack Development Mailing 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] [legal-discuss] [keystone][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation

[Monty Taylor]

On 07/25/2016 05:59 AM, Amrith Kumar wrote:
> Bug 1214176 seeks to "Fix copyright headers to be compliant with Foundation 
> policies" and one of the changes being made is to substitute "OpenStack 
> Foundation" in places where the code said "OpenStack LLC".
> 
> Someone just pushed changes to Keystone, Murano and Trove today and I have 
> some concerns about this change.
> 
> Consider the following changes, [2], [3], [4], and [5].
> 
> They assert a copyright in 2011 or 2010 of an entity called "OpenStack 
> Foundation" that was only established in 2012 [6].
> 
> Are these changes legally accurate?

IANAL but IIRC this is correct/valid. When the OpenStack Foundation was
formed, the IP owned by the original LLC was transferred to the Foundation.

https://review.openstack.org/#/c/22684/ for instance did this in Nova
back in February of 2013. You can see the original bug here:

https://bugs.launchpad.net/keystone/+bug/1214176

which references:

http://www.openstack.org/brand/openstack-trademark-policy/

and the patches that go along with it:

https://review.openstack.org/#/q/topic:bug/1214176

> -amrith
> 
> [1] https://bugs.launchpad.net/bugs/1214176
> [2] 
> https://review.openstack.org/#/c/346675/1/keystone/policy/backends/rules.py
> [3] https://review.openstack.org/#/c/346673/1/tools/install_venv.py
> [4] https://review.openstack.org/#/c/346669/1/murano/common/cf_config.py
> [5] https://review.openstack.org/#/c/346669/1/murano/common/config.py
> [6] 
> http://www.businesswire.com/news/home/20120919005997/en/OpenStack-Launches-Independent-Foundation-Begins-Work-Protecting
> 
> 
> ___
> legal-discuss mailing list
> legal-disc...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
> 


__
OpenStack Development Mailing 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][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation

[Amrith Kumar]

Dinesh,

With the required disclaimer that I'm not a lawyer, and I don't play one on TV, 
I believe that the changes proposed to Trove in [1] do not make sense. I am 
not, I do not believe, competent to answer the question of whether or not the 
earlier changes to cinderclient or ironic must be reverted.

-amrith

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


> -Original Message-
> From: Bhor, Dinesh [mailto:dinesh.b...@nttdata.com]
> Sent: Monday, July 25, 2016 8:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [keystone][murano][trove][imm] Changing
> OpenStack LLC to OpenStack Foundation
> 
> Hi amrith,
> 
> I can see the patches got merged against that bug with similar changes:
> 
> [python-cinderclient]
> https://review.openstack.org/#/c/47453/2/cinderclient/base.py
> [ironic]
> https://review.openstack.org/#/c/47451/2/ironic/common/image_service.py
> 
> Do you think these changes needs to be reverted ?
> 
> Thank you,
> Dinesh Bhor
> 
> -Original Message-
> From: Amrith Kumar [mailto:amr...@tesora.com]
> Sent: Monday, July 25, 2016 4:30 PM
> To: legal-disc...@lists.openstack.org
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [keystone][murano][trove][imm] Changing OpenStack
> LLC to OpenStack Foundation
> 
> Bug 1214176 seeks to "Fix copyright headers to be compliant with
> Foundation policies" and one of the changes being made is to substitute
> "OpenStack Foundation" in places where the code said "OpenStack LLC".
> 
> Someone just pushed changes to Keystone, Murano and Trove today and I have
> some concerns about this change.
> 
> Consider the following changes, [2], [3], [4], and [5].
> 
> They assert a copyright in 2011 or 2010 of an entity called "OpenStack
> Foundation" that was only established in 2012 [6].
> 
> Are these changes legally accurate?
> 
> -amrith
> 
> [1] https://bugs.launchpad.net/bugs/1214176
> [2]
> https://review.openstack.org/#/c/346675/1/keystone/policy/backends/rules.p
> y
> [3] https://review.openstack.org/#/c/346673/1/tools/install_venv.py
> [4] https://review.openstack.org/#/c/346669/1/murano/common/cf_config.py
> [5] https://review.openstack.org/#/c/346669/1/murano/common/config.py
> [6] http://www.businesswire.com/news/home/20120919005997/en/OpenStack-
> Launches-Independent-Foundation-Begins-Work-Protecting
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> Disclaimer: This email and any attachments are sent in strictest
> confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then
> delete
> and destroy this email and any attachments without any further use,
> copying
> or forwarding.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] Release Naming polls for P and Q ended, Legal Review under way

[Monty Taylor]

Hey everybody,

I ended the polls for P and Q this morning. Because we had issues
getting working poll links to everyone initially, I kept them open a bit
longer than originally stated to make sure everyone had a chance to vote.

I've submitted the results to the foundation staff who are now putting
the names through legal review. So while you can go look at the results
from CIVS, keep in mind it's possible that we can end up with issues
with one or more of the winners - so don't start naming anything just yet.

We'll report back the final winner as soon as we've got word from legal.

Thanks!
Monty

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

Re: [openstack-dev] [Fuel]Nominating Vitalii Kulanov for python-fuelclient-core

[Yegor Kotko]

+1

On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko  wrote:

> Hi Fuelers,
>
> Vitalii has been providing great code reviews and patches for some time.
> His recent commitment to help consolidating both old and new fuel clients
> and his bug-squashing activities show his willingness to step up and take
> responsibilities within the community. He can often be found in #fuel as
> vkulanov.
>
>
> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t
>
>
> P. S. Sorry for sending this email twice — I realized I didn’t put a topic
> to the subject.
>
>
> - romcheg
>
> __
> OpenStack Development Mailing 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] [Fuel]Nominating Vitalii Kulanov for python-fuelclient-core

[Roman Prykhodchenko]

Hi Fuelers,

Vitalii has been providing great code reviews and patches for some time. His 
recent commitment to help consolidating both old and new fuel clients and his 
bug-squashing activities show his willingness to step up and take 
responsibilities within the community. He can often be found in #fuel as 
vkulanov.

http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t


P. S. Sorry for sending this email twice — I realized I didn’t put a topic to 
the subject.


- romcheg


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

Re: [openstack-dev] [kolla] Monitoring tooling

[Dave Walker]

So, this is one of the areas i'm currently on with the Sensu work.  I've
been experimenting with a privileged container, which is very similar to
our current kolla_toolbox container.

The agent certainly needs to be in it's own container, with access to be
able to run commands in other namespaces / containers.

On 25 July 2016 at 11:58, Mathias Ewald  wrote:

> Excellent point ... I just checked what happens when running telegraf in a
> container: You'll get paths like
>
> /etc/hostname
> /etc/hosts
> /var/log/kolla
>
> and others as available file systems. I guess it makes no sense at all
> then to containerize monitoring agents ... Sensu is going to have the same
> problems.
>
> Any suggestions?
>
>
> 2016-07-25 9:39 GMT+02:00 Jeffrey Zhang :
>
>> I am open to the choice of tools. But i am worried on thing: how to
>> get all the host disk usage when containerized the monitor tool?
>>
>>
>>
>> On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
>> > Understood.
>> >
>> > 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>> >>
>> >> On 25/07/16 06:38, Mathias Ewald wrote:
>> >> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>> >> > tenants rather than cloud ops? If that's the case I wont find info
>> like
>> >> > "controller cpu usage" or "hypervisor memory usage".
>> >> >
>> >> > Cheers
>> >> > Mathias
>> >> >
>> >> Uhm, in this scenario, gnocchi just used as time-series database. It's
>> >> up to you, what you feed in. collectd collects whatever you want and
>> put
>> >> it into your database.
>> >>
>> >> Best,
>> >> Matthias
>> >>
>> >> --
>> >> Matthias Runge 
>> >>
>> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> >> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> >> Managing Directors: Charles Cachera, Michael Cunningham,
>> >> Michael O'Neill, Eric Shander
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Mobil: +49 176 10567592
>> > E-Mail: mew...@evoila.de
>> >
>> > evoila GmbH
>> > Wilhelm-Theodor-Römheld-Str. 34
>> > 55130 Mainz
>> > Germany
>> >
>> > Geschäftsführer: Johannes Hiemer
>> >
>> > Amtsgericht Mainz HRB 42719
>> >
>> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>> > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>> E-Mail
>> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
>> > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>> > Weitergabe dieser Mail ist nicht gestattet.
>> >
>> > This e-mail may contain confidential and/or privileged information. If
>> You
>> > are not the intended recipient (or have received this e-mail in error)
>> > please notify the sender immediately and destroy this e-mail. Any
>> > unauthorised copying, disclosure or distribution of the material in this
>> > e-mail is strictly forbidden.
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Mobil: +49 176 10567592
> E-Mail: mew...@evoila.de
>
> evoila GmbH
> Wilhelm-Theodor-Römheld-Str. 34
> 55130 Mainz
> Germany
>
> Geschäftsführer: Johannes Hiemer
>
> Amtsgericht Mainz HRB 42719
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If You
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

[openstack-dev] Nominating Vitalii Kulanov for python-fuelclient-core

[Roman Prykhodchenko]

Hi Fuelers,

Vitalii has been providing great code reviews and patches for some time. His 
recent commitment to help consolidating both old and new fuel clients and his 
bug-squashing activities show his willingness to step up and take 
responsibilities within the community. He can often be found in #fuel as 
vkulanov.

http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t 



- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] Remove duplicate code using Data Driven Tests (DDT)

[Daniel P. Berrange]

On Mon, Jul 25, 2016 at 08:22:52AM -0400, Sean Dague wrote:
> On 07/25/2016 08:05 AM, Daniel P. Berrange wrote:
> > On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
> >> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
> >>> On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
>  On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:
> 
>  I agree that it's not a bug. I also agree that it helps in some specific
>  types of tests which are doing some kind of input validation (like the 
>  patch
>  you've proposed) or are simply iterating over some list of values (status
>  values on a server instance for example).
> 
>  Using DDT in Nova has come up before and one of the concerns was hiding
>  details in how the tests are run with a library, and if there would be a
>  learning curve. Depending on the usage, I personally don't have a problem
>  with it. When I used it in manila it took a little getting used to but I 
>  was
>  basically just looking at existing tests and figuring out what they were
>  doing when adding new ones.
> >>>
> >>> I don't think there's significant learning curve there - the way it
> >>> lets you annotate the test methods is pretty easy to understand and
> >>> the ddt docs spell it out clearly for newbies. We've far worse things
> >>> in our code that create a hard learning curve which people will hit
> >>> first :-)
> >>>
> >>> People have essentially been re-inventing ddt in nova tests already
> >>> by defining one helper method and them having multiple tests methods
> >>> all calling the same helper with a different dataset. So ddt is just
> >>> formalizing what we're already doing in many places, with less code
> >>> and greater clarity.
> >>>
>  I definitely think DDT is easier to use/understand than something like
>  testscenarios, which we're already using in Nova.
> >>>
> >>> Yeah, testscenarios feels little over-engineered for what we want most
> >>> of the time.
> >>
> >> Except, DDT is way less clear (and deterministic) about what's going on
> >> with the test name munging. Which means failures are harder to track
> >> back to individual tests and data load. So debugging the failures is 
> >> harder.
> > 
> > I'm not sure what you think is unclear - given an annotated test:
> > 
> >@ddt.data({"foo": "test", "availability_zone": "nova1"},
> >   {"name": "  test  ", "availability_zone": "nova1"},
> >   {"name": "", "availability_zone": "nova1"},
> >   {"name": "x" * 256, "availability_zone": "nova1"},
> >   {"name": "test", "availability_zone": "x" * 256},
> >   {"name": "test", "availability_zone": "  nova1  "},
> >   {"name": "test", "availability_zone": ""},
> >   {"name": "test", "availability_zone": "nova1", "foo": "bar"})
> > def test_create_invalid_create_aggregate_data(self, value):
> > 
> > It is generated one test for each data item:
> > 
> >  test_create_invalid_create_aggregate_data_1
> >  test_create_invalid_create_aggregate_data_2
> >  test_create_invalid_create_aggregate_data_3
> >  test_create_invalid_create_aggregate_data_4
> >  test_create_invalid_create_aggregate_data_5
> >  test_create_invalid_create_aggregate_data_6
> >  test_create_invalid_create_aggregate_data_7
> >  test_create_invalid_create_aggregate_data_8
> > 
> > This seems about as obvious as you can possibly get
> 
> At least when this was attempted to be introduced into Tempest, the
> naming was a lot less clear, maybe it got better. But I still think
> milestone 3 isn't the time to start a thing like this.

Historically we've allowed patches that improve / adapt unit tests
to be merged at any time that we're not in final bug-fix only freeze
periods. So on this basis, I'm happy to see this accepted now, especially
since the module is already in global requirements, so not a new thing
from an openstack POV

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] Remove duplicate code using Data Driven Tests (DDT)

[Bhor, Dinesh]

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Monday, July 25, 2016 5:53 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven 
Tests (DDT)

On 07/25/2016 08:05 AM, Daniel P. Berrange wrote:
> On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
>> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
>>> On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
 On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:

 I agree that it's not a bug. I also agree that it helps in some 
 specific types of tests which are doing some kind of input 
 validation (like the patch you've proposed) or are simply iterating 
 over some list of values (status values on a server instance for example).

 Using DDT in Nova has come up before and one of the concerns was 
 hiding details in how the tests are run with a library, and if 
 there would be a learning curve. Depending on the usage, I 
 personally don't have a problem with it. When I used it in manila 
 it took a little getting used to but I was basically just looking 
 at existing tests and figuring out what they were doing when adding new 
 ones.
>>>
>>> I don't think there's significant learning curve there - the way it 
>>> lets you annotate the test methods is pretty easy to understand and 
>>> the ddt docs spell it out clearly for newbies. We've far worse 
>>> things in our code that create a hard learning curve which people 
>>> will hit first :-)
>>>
>>> People have essentially been re-inventing ddt in nova tests already 
>>> by defining one helper method and them having multiple tests methods 
>>> all calling the same helper with a different dataset. So ddt is just 
>>> formalizing what we're already doing in many places, with less code 
>>> and greater clarity.
>>>
 I definitely think DDT is easier to use/understand than something 
 like testscenarios, which we're already using in Nova.
>>>
>>> Yeah, testscenarios feels little over-engineered for what we want 
>>> most of the time.
>>
>> Except, DDT is way less clear (and deterministic) about what's going 
>> on with the test name munging. Which means failures are harder to 
>> track back to individual tests and data load. So debugging the failures is 
>> harder.
> 
> I'm not sure what you think is unclear - given an annotated test:
> 
>@ddt.data({"foo": "test", "availability_zone": "nova1"},
>   {"name": "  test  ", "availability_zone": "nova1"},
>   {"name": "", "availability_zone": "nova1"},
>   {"name": "x" * 256, "availability_zone": "nova1"},
>   {"name": "test", "availability_zone": "x" * 256},
>   {"name": "test", "availability_zone": "  nova1  "},
>   {"name": "test", "availability_zone": ""},
>   {"name": "test", "availability_zone": "nova1", "foo": "bar"})
> def test_create_invalid_create_aggregate_data(self, value):
> 
> It is generated one test for each data item:
> 
>  test_create_invalid_create_aggregate_data_1
>  test_create_invalid_create_aggregate_data_2
>  test_create_invalid_create_aggregate_data_3
>  test_create_invalid_create_aggregate_data_4
>  test_create_invalid_create_aggregate_data_5
>  test_create_invalid_create_aggregate_data_6
>  test_create_invalid_create_aggregate_data_7
>  test_create_invalid_create_aggregate_data_8
> 
> This seems about as obvious as you can possibly get

At least when this was attempted to be introduced into Tempest, the naming was 
a lot less clear, maybe it got better. But I still think milestone 3 isn't the 
time to start a thing like this.

-Sean

Hi Sean,

IMO it is possible to have a descriptive name to test cases using DDT.

For ex.,

@ddt.data(annotated('missing_name', {"foo": "test", "availability_zone": 
"nova1"}),
  annotated('name_greater_than_255_characters', {"name": "x" * 256, 
"availability_zone": "nova1"}))
def test_create_invalid_aggregate_data(self, value):


it generates following test names:

test_create_invalid_aggregate_data_2_name_greater_than_255_characters
test_create_invalid_aggregate_data_1_missing_name

I think with this it is easy to identify which test scenario has failed.

Same is implemented in openstack/zaqar.
https://github.com/openstack/zaqar/blob/master/zaqar/tests/functional/wsgi/v1/test_queues.py#L87

Thank you,
Dinesh Bhor

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the 

Re: [openstack-dev] [keystone][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation

[Bhor, Dinesh]

Hi amrith,

I can see the patches got merged against that bug with similar changes:

[python-cinderclient] 
https://review.openstack.org/#/c/47453/2/cinderclient/base.py
[ironic] https://review.openstack.org/#/c/47451/2/ironic/common/image_service.py

Do you think these changes needs to be reverted ?

Thank you,
Dinesh Bhor

-Original Message-
From: Amrith Kumar [mailto:amr...@tesora.com] 
Sent: Monday, July 25, 2016 4:30 PM
To: legal-disc...@lists.openstack.org
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone][murano][trove][imm] Changing OpenStack LLC 
to OpenStack Foundation

Bug 1214176 seeks to "Fix copyright headers to be compliant with Foundation 
policies" and one of the changes being made is to substitute "OpenStack 
Foundation" in places where the code said "OpenStack LLC".

Someone just pushed changes to Keystone, Murano and Trove today and I have some 
concerns about this change.

Consider the following changes, [2], [3], [4], and [5].

They assert a copyright in 2011 or 2010 of an entity called "OpenStack 
Foundation" that was only established in 2012 [6].

Are these changes legally accurate?

-amrith

[1] https://bugs.launchpad.net/bugs/1214176
[2] https://review.openstack.org/#/c/346675/1/keystone/policy/backends/rules.py
[3] https://review.openstack.org/#/c/346673/1/tools/install_venv.py
[4] https://review.openstack.org/#/c/346669/1/murano/common/cf_config.py
[5] https://review.openstack.org/#/c/346669/1/murano/common/config.py
[6] 
http://www.businesswire.com/news/home/20120919005997/en/OpenStack-Launches-Independent-Foundation-Begins-Work-Protecting


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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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

Re: [openstack-dev] [telemetry] [vitrage] Mascot

[Julien Danjou]

On Mon, Jul 25 2016, Afek, Ifat (Nokia - IL) wrote:

> A week ago I published Vitrage mascot alternatives[1] and notified Heidi Joy
> Tretheway. One of our options was Suricata, which is another name for a
> Meerkat. We have yet to conduct the official vote, but from what I can tell
> this is quite a popular option (#2 at the moment).
>
> Seems like we have a Meerkat problem... :-)

Haha, you're right. There's even an open source named Suricata:
 https://suricata-ids.org/

We'll probably need to pick something else. There seems to be some kind
of pun possible with Vitrage did you explore that btw?

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


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

Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven Tests (DDT)

[Sean Dague]

On 07/25/2016 08:05 AM, Daniel P. Berrange wrote:
> On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
>> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
>>> On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
 On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:

 I agree that it's not a bug. I also agree that it helps in some specific
 types of tests which are doing some kind of input validation (like the 
 patch
 you've proposed) or are simply iterating over some list of values (status
 values on a server instance for example).

 Using DDT in Nova has come up before and one of the concerns was hiding
 details in how the tests are run with a library, and if there would be a
 learning curve. Depending on the usage, I personally don't have a problem
 with it. When I used it in manila it took a little getting used to but I 
 was
 basically just looking at existing tests and figuring out what they were
 doing when adding new ones.
>>>
>>> I don't think there's significant learning curve there - the way it
>>> lets you annotate the test methods is pretty easy to understand and
>>> the ddt docs spell it out clearly for newbies. We've far worse things
>>> in our code that create a hard learning curve which people will hit
>>> first :-)
>>>
>>> People have essentially been re-inventing ddt in nova tests already
>>> by defining one helper method and them having multiple tests methods
>>> all calling the same helper with a different dataset. So ddt is just
>>> formalizing what we're already doing in many places, with less code
>>> and greater clarity.
>>>
 I definitely think DDT is easier to use/understand than something like
 testscenarios, which we're already using in Nova.
>>>
>>> Yeah, testscenarios feels little over-engineered for what we want most
>>> of the time.
>>
>> Except, DDT is way less clear (and deterministic) about what's going on
>> with the test name munging. Which means failures are harder to track
>> back to individual tests and data load. So debugging the failures is harder.
> 
> I'm not sure what you think is unclear - given an annotated test:
> 
>@ddt.data({"foo": "test", "availability_zone": "nova1"},
>   {"name": "  test  ", "availability_zone": "nova1"},
>   {"name": "", "availability_zone": "nova1"},
>   {"name": "x" * 256, "availability_zone": "nova1"},
>   {"name": "test", "availability_zone": "x" * 256},
>   {"name": "test", "availability_zone": "  nova1  "},
>   {"name": "test", "availability_zone": ""},
>   {"name": "test", "availability_zone": "nova1", "foo": "bar"})
> def test_create_invalid_create_aggregate_data(self, value):
> 
> It is generated one test for each data item:
> 
>  test_create_invalid_create_aggregate_data_1
>  test_create_invalid_create_aggregate_data_2
>  test_create_invalid_create_aggregate_data_3
>  test_create_invalid_create_aggregate_data_4
>  test_create_invalid_create_aggregate_data_5
>  test_create_invalid_create_aggregate_data_6
>  test_create_invalid_create_aggregate_data_7
>  test_create_invalid_create_aggregate_data_8
> 
> This seems about as obvious as you can possibly get

At least when this was attempted to be introduced into Tempest, the
naming was a lot less clear, maybe it got better. But I still think
milestone 3 isn't the time to start a thing like this.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

[Sean Dague]

On 07/22/2016 09:20 AM, Angus Lees wrote:
> On Thu, 21 Jul 2016 at 09:27 Sean Dague  > wrote:
> 
> On 07/12/2016 06:25 AM, Matt Riedemann wrote:
> 
> > We probably aren't doing anything while Sean Dague is on vacation.
> He's
> > back next week and we have the nova/cinder meetups, so I'm planning on
> > talking about the grenade issue in person and hopefully we'll have a
> > plan by the end of next week to move forward.
> 
> After some discussions at the Nova midcycle we threw together an
> approach where we just always allow privsep-helper from oslo.rootwrap.
> 
> https://review.openstack.org/344450
> 
> 
> Were these discussions captured anywhere?  I thought we'd discussed
> alternatives on os-dev, reached a conclusion, implemented the
> changes(*), and verified the results all a month ago - and that we were
> just awaiting nova approval.  So I'm surprised to see this sudden change
> in direction...
> 
> (*) Changes:
> https://review.openstack.org/#/c/329769/
> https://review.openstack.org/#/c/332610/
> mriedem's verification: https://review.openstack.org/#/c/331885/

By agreed we said that - https://review.openstack.org/#/c/332610/ was
the option of last resort if no better option could be figured out. But
then we ran into having to do this again for os-vif. And given the roll
out of privsep it looks like we'll basically have this same exception /
manual update another place in base IaaS for multiple cycles here as
this rolls out.

Which is exactly the opposite of our upgrade vision, which upgrades
should be seamless code rolling forward.

If we only had to do this once, maybe we mea culpa and do it. But we
know we at least have to do this twice, and coordinated nova and neutron
coupling the release. This gets exponentially worse.

After we brought that up in the room, we started going through other
options. Someone brought up "what about making rootwrap always do this
for privsep, instead of manually doing this for every project", and I
volunteered to look at the code to figure out how hard it would be. That
patch is up at https://review.openstack.org/344450.

I think the path forward here is about the following questions:

1) how important are seamless upgrades in our vision?
2) are root wrap rules supposed to be config (which is manually audited
by installers)?
3) is the software supposed to take into account and adapt to the rules
not being there (or disabled by an auditor)?
4) does always letting rootwrap call privsep regress our near term
security in any real way (given the flaws in existing rules)?
5) what will most quickly allow us to transition into a non rootwrap
world, with a privsep architecture that will give us a better security
model?

Making oslo.rootwrap trust privsep seems like the least worst option in
front of us, especially to actually get os-vif out there and deployed
this cycle as well.

-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] Remove duplicate code using Data Driven Tests (DDT)

[Daniel P. Berrange]

On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
> > On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
> >> On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:
> >>
> >> I agree that it's not a bug. I also agree that it helps in some specific
> >> types of tests which are doing some kind of input validation (like the 
> >> patch
> >> you've proposed) or are simply iterating over some list of values (status
> >> values on a server instance for example).
> >>
> >> Using DDT in Nova has come up before and one of the concerns was hiding
> >> details in how the tests are run with a library, and if there would be a
> >> learning curve. Depending on the usage, I personally don't have a problem
> >> with it. When I used it in manila it took a little getting used to but I 
> >> was
> >> basically just looking at existing tests and figuring out what they were
> >> doing when adding new ones.
> > 
> > I don't think there's significant learning curve there - the way it
> > lets you annotate the test methods is pretty easy to understand and
> > the ddt docs spell it out clearly for newbies. We've far worse things
> > in our code that create a hard learning curve which people will hit
> > first :-)
> > 
> > People have essentially been re-inventing ddt in nova tests already
> > by defining one helper method and them having multiple tests methods
> > all calling the same helper with a different dataset. So ddt is just
> > formalizing what we're already doing in many places, with less code
> > and greater clarity.
> > 
> >> I definitely think DDT is easier to use/understand than something like
> >> testscenarios, which we're already using in Nova.
> > 
> > Yeah, testscenarios feels little over-engineered for what we want most
> > of the time.
> 
> Except, DDT is way less clear (and deterministic) about what's going on
> with the test name munging. Which means failures are harder to track
> back to individual tests and data load. So debugging the failures is harder.

I'm not sure what you think is unclear - given an annotated test:

   @ddt.data({"foo": "test", "availability_zone": "nova1"},
  {"name": "  test  ", "availability_zone": "nova1"},
  {"name": "", "availability_zone": "nova1"},
  {"name": "x" * 256, "availability_zone": "nova1"},
  {"name": "test", "availability_zone": "x" * 256},
  {"name": "test", "availability_zone": "  nova1  "},
  {"name": "test", "availability_zone": ""},
  {"name": "test", "availability_zone": "nova1", "foo": "bar"})
def test_create_invalid_create_aggregate_data(self, value):

It is generated one test for each data item:

 test_create_invalid_create_aggregate_data_1
 test_create_invalid_create_aggregate_data_2
 test_create_invalid_create_aggregate_data_3
 test_create_invalid_create_aggregate_data_4
 test_create_invalid_create_aggregate_data_5
 test_create_invalid_create_aggregate_data_6
 test_create_invalid_create_aggregate_data_7
 test_create_invalid_create_aggregate_data_8

This seems about as obvious as you can possibly get

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] Remove duplicate code using Data Driven Tests (DDT)

[Jay Pipes]

On 07/25/2016 07:57 AM, Sean Dague wrote:

On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:

On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:

On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:

I agree that it's not a bug. I also agree that it helps in some specific
types of tests which are doing some kind of input validation (like the patch
you've proposed) or are simply iterating over some list of values (status
values on a server instance for example).

Using DDT in Nova has come up before and one of the concerns was hiding
details in how the tests are run with a library, and if there would be a
learning curve. Depending on the usage, I personally don't have a problem
with it. When I used it in manila it took a little getting used to but I was
basically just looking at existing tests and figuring out what they were
doing when adding new ones.


I don't think there's significant learning curve there - the way it
lets you annotate the test methods is pretty easy to understand and
the ddt docs spell it out clearly for newbies. We've far worse things
in our code that create a hard learning curve which people will hit
first :-)

People have essentially been re-inventing ddt in nova tests already
by defining one helper method and them having multiple tests methods
all calling the same helper with a different dataset. So ddt is just
formalizing what we're already doing in many places, with less code
and greater clarity.


I definitely think DDT is easier to use/understand than something like
testscenarios, which we're already using in Nova.


Yeah, testscenarios feels little over-engineered for what we want most
of the time.


Except, DDT is way less clear (and deterministic) about what's going on
with the test name munging. Which means failures are harder to track
back to individual tests and data load. So debugging the failures is harder.

I agree with have a lot of bad patterns in the tests. But I also don't
think that embedding another pattern during milestone 3 is the right
time to do it. At least lets hold until next cycle opens up when there
is more time to actually look at trade offs here.


+1

Also, I actually don't see how testscenarios won't/can't work for 
everything DDT is doing. Sounds a bit like the "why can't we use pytest 
instead of testr?" thing again.


Best,
-jay

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

Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven Tests (DDT)

[Sean Dague]

On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
> On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
>> On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:
>>
>> I agree that it's not a bug. I also agree that it helps in some specific
>> types of tests which are doing some kind of input validation (like the patch
>> you've proposed) or are simply iterating over some list of values (status
>> values on a server instance for example).
>>
>> Using DDT in Nova has come up before and one of the concerns was hiding
>> details in how the tests are run with a library, and if there would be a
>> learning curve. Depending on the usage, I personally don't have a problem
>> with it. When I used it in manila it took a little getting used to but I was
>> basically just looking at existing tests and figuring out what they were
>> doing when adding new ones.
> 
> I don't think there's significant learning curve there - the way it
> lets you annotate the test methods is pretty easy to understand and
> the ddt docs spell it out clearly for newbies. We've far worse things
> in our code that create a hard learning curve which people will hit
> first :-)
> 
> People have essentially been re-inventing ddt in nova tests already
> by defining one helper method and them having multiple tests methods
> all calling the same helper with a different dataset. So ddt is just
> formalizing what we're already doing in many places, with less code
> and greater clarity.
> 
>> I definitely think DDT is easier to use/understand than something like
>> testscenarios, which we're already using in Nova.
> 
> Yeah, testscenarios feels little over-engineered for what we want most
> of the time.

Except, DDT is way less clear (and deterministic) about what's going on
with the test name munging. Which means failures are harder to track
back to individual tests and data load. So debugging the failures is harder.

I agree with have a lot of bad patterns in the tests. But I also don't
think that embedding another pattern during milestone 3 is the right
time to do it. At least lets hold until next cycle opens up when there
is more time to actually look at trade offs here.

-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] [kolla] Monitoring tooling

[Steven Dake (stdake)]

Collectd is how you obtain the host disk usage.  It can be done although
collectd is nearing the complexity of turning nova into a container so it
may need someone experienced with Kolla to execute.

Regards
-steve

On 7/25/16, 12:39 AM, "Jeffrey Zhang"  wrote:

>I am open to the choice of tools. But i am worried on thing: how to
>get all the host disk usage when containerized the monitor tool?
>
>
>
>On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
>> Understood.
>>
>> 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>>>
>>> On 25/07/16 06:38, Mathias Ewald wrote:
>>> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>>> > tenants rather than cloud ops? If that's the case I wont find info
>>>like
>>> > "controller cpu usage" or "hypervisor memory usage".
>>> >
>>> > Cheers
>>> > Mathias
>>> >
>>> Uhm, in this scenario, gnocchi just used as time-series database. It's
>>> up to you, what you feed in. collectd collects whatever you want and
>>>put
>>> it into your database.
>>>
>>> Best,
>>> Matthias
>>>
>>> --
>>> Matthias Runge 
>>>
>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>> Managing Directors: Charles Cachera, Michael Cunningham,
>>> Michael O'Neill, Eric Shander
>>>
>>> 
>>>
>>>__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Mobil: +49 176 10567592
>> E-Mail: mew...@evoila.de
>>
>> evoila GmbH
>> Wilhelm-Theodor-Römheld-Str. 34
>> 55130 Mainz
>> Germany
>>
>> Geschäftsführer: Johannes Hiemer
>>
>> Amtsgericht Mainz HRB 42719
>>
>> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>>E-Mail
>> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
>> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>> Weitergabe dieser Mail ist nicht gestattet.
>>
>> This e-mail may contain confidential and/or privileged information. If
>>You
>> are not the intended recipient (or have received this e-mail in error)
>> please notify the sender immediately and destroy this e-mail. Any
>> unauthorised copying, disclosure or distribution of the material in this
>> e-mail is strictly forbidden.
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>-- 
>Regards,
>Jeffrey Zhang
>Blog: http://xcodest.me
>
>__
>OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Mathias Ewald]

I believe I found a possible (partial) solution:
https://github.com/influxdata/telegraf/issues/218 I will test it and report
back.

2016-07-25 12:58 GMT+02:00 Mathias Ewald :

> Excellent point ... I just checked what happens when running telegraf in a
> container: You'll get paths like
>
> /etc/hostname
> /etc/hosts
> /var/log/kolla
>
> and others as available file systems. I guess it makes no sense at all
> then to containerize monitoring agents ... Sensu is going to have the same
> problems.
>
> Any suggestions?
>
>
> 2016-07-25 9:39 GMT+02:00 Jeffrey Zhang :
>
>> I am open to the choice of tools. But i am worried on thing: how to
>> get all the host disk usage when containerized the monitor tool?
>>
>>
>>
>> On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
>> > Understood.
>> >
>> > 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>> >>
>> >> On 25/07/16 06:38, Mathias Ewald wrote:
>> >> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>> >> > tenants rather than cloud ops? If that's the case I wont find info
>> like
>> >> > "controller cpu usage" or "hypervisor memory usage".
>> >> >
>> >> > Cheers
>> >> > Mathias
>> >> >
>> >> Uhm, in this scenario, gnocchi just used as time-series database. It's
>> >> up to you, what you feed in. collectd collects whatever you want and
>> put
>> >> it into your database.
>> >>
>> >> Best,
>> >> Matthias
>> >>
>> >> --
>> >> Matthias Runge 
>> >>
>> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> >> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> >> Managing Directors: Charles Cachera, Michael Cunningham,
>> >> Michael O'Neill, Eric Shander
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Mobil: +49 176 10567592
>> > E-Mail: mew...@evoila.de
>> >
>> > evoila GmbH
>> > Wilhelm-Theodor-Römheld-Str. 34
>> > 55130 Mainz
>> > Germany
>> >
>> > Geschäftsführer: Johannes Hiemer
>> >
>> > Amtsgericht Mainz HRB 42719
>> >
>> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>> > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>> E-Mail
>> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
>> > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>> > Weitergabe dieser Mail ist nicht gestattet.
>> >
>> > This e-mail may contain confidential and/or privileged information. If
>> You
>> > are not the intended recipient (or have received this e-mail in error)
>> > please notify the sender immediately and destroy this e-mail. Any
>> > unauthorised copying, disclosure or distribution of the material in this
>> > e-mail is strictly forbidden.
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Mobil: +49 176 10567592
> E-Mail: mew...@evoila.de
>
> evoila GmbH
> Wilhelm-Theodor-Römheld-Str. 34
> 55130 Mainz
> Germany
>
> Geschäftsführer: Johannes Hiemer
>
> Amtsgericht Mainz HRB 42719
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If You
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>



-- 
Mobil: +49 176 10567592
E-Mail: mew...@evoila.de

evoila GmbH
Wilhelm-Theodor-Römheld-Str. 34
55130 Mainz
Germany

Geschäftsführer: Johannes Hiemer

Amtsgericht Mainz HRB 42719

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort 

Re: [openstack-dev] [telemetry] [vitrage] Mascot

[Afek, Ifat (Nokia - IL)]

> -Original Message-
> From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> Sent: Thursday, July 21, 2016 9:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [telemetry] Mascot
> 
> I had the Meerkat [1] in mind as Telemetry has a "family" of services
> and meerkat lives in bigger groups too and a few of them stand sentry
> and listen to any event or danger, etc. and "send alarms" to the
> others.
>

Hi,

A week ago I published Vitrage mascot alternatives[1] and notified Heidi Joy 
Tretheway. One of our options was Suricata, which is another name for a 
Meerkat. We have yet to conduct the official vote, but from what I can tell 
this is quite a popular option (#2 at the moment). 

Seems like we have a Meerkat problem... :-)

[1] https://etherpad.openstack.org/p/vitrage-mascot 

Thanks, 
Ifat.


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

[openstack-dev] [neutron][networking-l2gw] Python 3 support

[Gary Kotton]

Hi,
This morning I discovered that the project does not have python 3 support. This 
was due to the fact that it broke the vmware-nsx unit tests.
I have started to kick the wheels with the python 3 support:

1.   Project infra - https://review.openstack.org/346701 (currently 
non-voting)

2.   L2 gw:

a.   https://review.openstack.org/#/c/346638/ - this is currently blocking 
all decomposed plugins invoking l2-gw unit tests

b.   https://review.openstack.org/#/c/346658/

c.   https://review.openstack.org/#/c/346697/
If anyone else would like to jump in and help then please let me know. 
Hopefully we can get this done in a couple of days.
A luta continua
Thanks
Gary
__
OpenStack Development Mailing 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] [Cinder] Midcycle Action item Summary

[Erlon Cruz]

Thanks for the sum up Kendall!

On Fri, Jul 22, 2016 at 1:20 PM, Kendall Nelson 
wrote:

> Hello All,
>
>We came out of the Midcycle with a lot of things on a lot of people’s
> plates. Here is a summary of what everyone signed up for and what things
> need owners.
>
> scottda:
>
>-
>
>Pick a time to meet weekly to discuss and push ahead with
>Active-Active HA (day1)
>-
>
>Find out the process for how swift uses feature branches and teach us
>(day1)
>-
>
>Write a devstack to fix config for tempest multibackend (just pass
>$CINDER_ENABLED_BACKENDS through to tempest.conf; make sure the string
>formats match up between tempest and cinder) (day2)
>
> geguileo:
>
>-
>
>Make a list of minimal risk Active-Active HA patches to focus on first
>(day1)
>
> jgriffith:
>
>-
>
>Work with scottda on getting the logic back into Nova (?) that was
>ripped out for setting up multiple back ends; it used to be there but was
>removed because there were errors coming from LVM (day2)
>-
>
>Work with xyang and e0ne on consolidating a single stable fake driver
>(day3)
>
> smcginnis:
>
>-
>
>Rebase nested quota support patches (day1)
>-
>
>   https://review.openstack.org/#/c/298453/ Functional Tests for
>   nested quotas
>   -
>
>   https://review.openstack.org/#/c/285640/ Cinder test cases for
>   nested quotas
>
> eharney:
>
>-
>
>Figure out what needs to be changed in the client for min vol sizes
>(day1)
>-
>
>Create a wiki or document and schedule for stable branch release plans
>(day2)
>
> diablo_rojo:
>
>-
>
>Write template for email to send to failing CI’s (day1)
>
> bswartz:
>
>-
>
>Push code for your stochastic scheduler spec(day3)
>
> e0ne:
>
>-
>
>Convert functional job in gate to be a stripped down devstack that can
>have the driver be configured
>
>
> ~~~Needs an owner~~~
>
>-
>
>QA Liaison
>-
>
>Request Infra to make driver branches for old releases (day2)
>-
>
>Set up project config for driver branches for old releases (day2)
>-
>
>Spec for the desired result for seamless failback after replication
>failover(day3)
>-
>
>Set provisioning to thick=true in all drivers and then change the
>default provisioning to thin (day3)
>-
>
>Update documentation for tests to explain differences between unit,
>functional, in-tree tempest, and tempest tests- i.e. what services run in
>functional environment versus in-tree tempest tests, what each’s purpose
>is, maybe examples of things that would be tested in each area? (day3)
>-
>
>Set up jobs for fake driver and real drivers for functional tests
>(day3)
>
>
>
> Links to etherpads where notes were taken and todo’s were set up:
>
> Day1: https://etherpad.openstack.org/p/newton-cinder-midcycle-day1
>
> Day2: https://etherpad.openstack.org/p/newton-cinder-midcycle-day2
>
> Day3: https://etherpad.openstack.org/p/newton-cinder-midcycle-day3
>
> Thanks!
>
> Kendall Nelson
>
> (diablo_rojo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Monitoring tooling

[Mathias Ewald]

Excellent point ... I just checked what happens when running telegraf in a
container: You'll get paths like

/etc/hostname
/etc/hosts
/var/log/kolla

and others as available file systems. I guess it makes no sense at all then
to containerize monitoring agents ... Sensu is going to have the same
problems.

Any suggestions?


2016-07-25 9:39 GMT+02:00 Jeffrey Zhang :

> I am open to the choice of tools. But i am worried on thing: how to
> get all the host disk usage when containerized the monitor tool?
>
>
>
> On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
> > Understood.
> >
> > 2016-07-25 7:34 GMT+02:00 Matthias Runge :
> >>
> >> On 25/07/16 06:38, Mathias Ewald wrote:
> >> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
> >> > tenants rather than cloud ops? If that's the case I wont find info
> like
> >> > "controller cpu usage" or "hypervisor memory usage".
> >> >
> >> > Cheers
> >> > Mathias
> >> >
> >> Uhm, in this scenario, gnocchi just used as time-series database. It's
> >> up to you, what you feed in. collectd collects whatever you want and put
> >> it into your database.
> >>
> >> Best,
> >> Matthias
> >>
> >> --
> >> Matthias Runge 
> >>
> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> >> Commercial register: Amtsgericht Muenchen, HRB 153243,
> >> Managing Directors: Charles Cachera, Michael Cunningham,
> >> Michael O'Neill, Eric Shander
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Mobil: +49 176 10567592
> > E-Mail: mew...@evoila.de
> >
> > evoila GmbH
> > Wilhelm-Theodor-Römheld-Str. 34
> > 55130 Mainz
> > Germany
> >
> > Geschäftsführer: Johannes Hiemer
> >
> > Amtsgericht Mainz HRB 42719
> >
> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail
> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> > Weitergabe dieser Mail ist nicht gestattet.
> >
> > This e-mail may contain confidential and/or privileged information. If
> You
> > are not the intended recipient (or have received this e-mail in error)
> > please notify the sender immediately and destroy this e-mail. Any
> > unauthorised copying, disclosure or distribution of the material in this
> > e-mail is strictly forbidden.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Mobil: +49 176 10567592
E-Mail: mew...@evoila.de

evoila GmbH
Wilhelm-Theodor-Römheld-Str. 34
55130 Mainz
Germany

Geschäftsführer: Johannes Hiemer

Amtsgericht Mainz HRB 42719

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If You
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
__
OpenStack Development Mailing 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][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation

[Amrith Kumar]

Bug 1214176 seeks to "Fix copyright headers to be compliant with Foundation 
policies" and one of the changes being made is to substitute "OpenStack 
Foundation" in places where the code said "OpenStack LLC".

Someone just pushed changes to Keystone, Murano and Trove today and I have some 
concerns about this change.

Consider the following changes, [2], [3], [4], and [5].

They assert a copyright in 2011 or 2010 of an entity called "OpenStack 
Foundation" that was only established in 2012 [6].

Are these changes legally accurate?

-amrith

[1] https://bugs.launchpad.net/bugs/1214176
[2] https://review.openstack.org/#/c/346675/1/keystone/policy/backends/rules.py
[3] https://review.openstack.org/#/c/346673/1/tools/install_venv.py
[4] https://review.openstack.org/#/c/346669/1/murano/common/cf_config.py
[5] https://review.openstack.org/#/c/346669/1/murano/common/config.py
[6] 
http://www.businesswire.com/news/home/20120919005997/en/OpenStack-Launches-Independent-Foundation-Begins-Work-Protecting


__
OpenStack Development Mailing 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] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

[Kumari, Madhuri]

+1 for Sypros.

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Saturday, July 23, 2016 1:57 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core 
reviewer team

Hi all,

Spyros has consistently contributed to Magnum for a while. In my opinion, what 
differentiate him from others is the significance of his contribution, which 
adds concrete value to the project. For example, the operator-oriented install 
guide he delivered attracts a significant number of users to install Magnum, 
which facilitates the adoption of the project. I would like to emphasize that 
the Magnum team has been working hard but struggling to increase the adoption, 
and Spyros's contribution means a lot in this regards. He also completed 
several essential and challenging tasks, such as adding support for OverlayFS, 
adding Rally job for Magnum, etc. In overall, I am impressed by the amount of 
high-quality patches he submitted. He is also helpful in code reviews, and his 
comments often help us identify pitfalls that are not easy to identify. He is 
also very active in IRC and ML. Based on his contribution and expertise, I 
think he is qualified to be a Magnum core reviewer.

I am happy to propose Spyros to be a core reviewer of Magnum team. According to 
the OpenStack Governance process [1], we require a minimum of 4 +1 votes from 
Magnum core reviewers within a 1 week voting window (consider this proposal as 
a +1 vote from me). A vote of -1 is a veto. If we cannot get enough votes or 
there is a veto vote prior to the end of the voting window, Spyros is not able 
to join the core team and needs to wait 30 days to reapply.

The voting is open until Thursday July 29st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,
Hongbin
__
OpenStack Development Mailing 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] Proposing Jakub Libosvar for testing core

[Rossella Sblendido]

I find Jakub's reviews always very insightful. He contributed to several 
areas of the code base (OVSFirewallDriver, oslo versioned object and of 
course testing). Big +1 from me!


On 07/22/2016 10:12 AM, Oleg Bondarev wrote:

+1

On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
> wrote:

+1


On Jul 21, 2016, at 5:13 PM, Kevin Benton > wrote:

+1

On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin > wrote:

+1 from me

On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller
> wrote:

As Neutron's so called testing lieutenant I would like to
propose
Jakub Libosvar to be a core in the testing area.

Jakub has demonstrated his inherent interest in the
testing area over
the last few years, his reviews are consistently
insightful and his
numbers [1] are in line with others and I know will
improve if given
the responsibilities of a core reviewer. Jakub is deeply
involved with
the project's testing infrastructures and CI systems.

As a reminder the expectation from cores is found here
[2], and
specifically for cores interesting in helping out shaping
Neutron's
testing story:

* Guide community members to craft a testing strategy for
features [3]
* Ensure Neutron's testing infrastructures are sufficiently
sophisticated to achieve the above.
* Provide leadership when determining testing Do's &
Don'ts [4]. What
makes for an effective test?
* Ensure the gate stays consistently green

And more tactically we're looking at finishing the
Tempest/Neutron
tests dedup [5] and to provide visual graphing for
historical control
and data plane performance results similar to [6].

[1] http://stackalytics.com/report/contribution/neutron/90
[2]

http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
[3]

http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
[4] https://assafmuller.com/2015/05/17/testing-lightning-talk/
[5] https://etherpad.openstack.org/p/neutron-tempest-defork
[6]

https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s


__
OpenStack Development Mailing 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 Development Mailing 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] how to create initial db migration script to sub-project

[Moshe Levi]

Hi Henry,

Thank for the reply. 

I tried to do the following with your commit [2]:
1. I create models.py in networking_mlnx/db.
2. mysql -e "drop database neutron; create database neutron;"
3. neutron-db-manage --subproject=neutron  upgrade heads
4. neutron-db-manage --subproject=networking-mlnx  revision -m "test" --expend

Now I don't see the errors as before, but the migration script that was 
generated 
Looks like [3] and doesn't contain the new table.

Am I doing it wrong?  

[3] - 
from alembic import op
import sqlalchemy as sa


# revision identifiers, used by Alembic.
revision = 'cbb661581082'
down_revision = '65b6db113427b9_initial_contract'


def upgrade():
pass

-Original Message-
From: Henry Gessau [mailto:hen...@gessau.net] 
Sent: Sunday, July 24, 2016 9:21 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] how to create initial db migration 
script to sub-project

Hi Moshe,

It has been a while since a neutron sub-project initialized new alembic 
migrations, so the devref is out of date, sorry. Let me help you get this 
sorted out and then I can update the devref with the latest info.

First you need to create the initial migration for each branch (expand and 
contract). This is done by submitting a patch -- the contents of which used to 
be crafted by copying a similar patch from another sub-project. The patches to 
copy from are now out of date, so I have created a patch [2] for you and we can 
use this as the new "template patch for initial alembic migrations."

Some more comments inline ...

Moshe Levi  wrote:
> Hi,
> 
> I am trying to create initial db for the networking-mlnx project. 
> I am following this neutron alembic documentation [1].
> I added a entrypoint to networking-mlnx setup.cfg 
> neutron.db.alembic_migrations =
> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
> I added model.py file to networking-mlnx/networking_mlnx/db
> And I run python setup.py develop to regenerate the entrypoint
> 
> I am running the following commands:
> 1. mysql -e "drop database neutron; create database neutron;"
> 2. neutron-db-manage --subproject=neutron  upgrade heads

So far so good.

> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
> --autogenerate

Because we now require split (expand and contract) branches, you must now 
specify --expand or --contract *instead of* --autogenerate. I will update the 
devref about this.

> I am getting the following errors:
> INFO  [alembic.runtime.migration] Context impl MySQLImpl. 
>   
> INFO  [alembic.runtime.migration] Will assume non-transactional DDL.  
>   
> INFO  [alembic.autogenerate.compare] Detected removed table 
> u'alembic_version'  
> INFO  [alembic.autogenerate.compare] Detected removed index 
> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>   Generating 
> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>  ... done
>   OK  
>   
>  
> Traceback (most recent call last):
>   
>  
>   File "/usr/bin/neutron-db-manage", line 10, in  
>   
>  
> sys.exit(main())  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 689, in main
> return_val |= bool(CONF.command.func(config, CONF.command.name))  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 275, in do_revision 
> update_head_files(config) 
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 398, in update_head_files   
> f.write(head_map[CONTRACT_BRANCH] + '\n') 
>   
>  
> KeyError: 'contract'
> 
> 
> And the migration script just dropping unrelated tables

This should be 

Re: [openstack-dev] [keystone]keystone v2 bug

[ZZelle]

Hi,

A token issue is done with a POST request not a GET request, so the request
should be:

 curl -X POST ...

and Keystone requires perhaps Accept header.

Cédric/ZZelle

On Mon, Jul 25, 2016 at 3:19 AM, Kenny Ji-work  wrote:

> Hi all,
>
> In the mitaka version, I used v2 RESTful API of keystone as following:
> curl -i   -H "Content-Type: application/json"   -d '
> { "auth": {
> "tenantName": "admin",
> "passwordCredentials": {
> "username": "admin",
> "password": "password"
> }
> }
> }'   http://10.240.227.7:35357/v2.0/tokens ; echo
>
> But the result shows: {"error": {"message": "The request you have made
> requires authentication.", "code": 401, "title": "Unauthorized"}}. But the
> v3 of keystone works normaly.
> Is v2 of keystone not supported in mitaka or something else config I
> config wrong?
>
> Sincerely!
> Kenny Ji
>
> __
> OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Julien Danjou]

On Sun, Jul 24 2016, Mathias Ewald wrote:

> 5. InfluxDB to store metrics
> 6. Grafana to dashboard metrics

Would be nice to leverage scalable and open source solution built your
fellow OpenStack community, i.e. Gnocchi and its Grafana support.

My 2c,
-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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

Re: [openstack-dev] [kolla] Monitoring tooling

[Jeffrey Zhang]

I am open to the choice of tools. But i am worried on thing: how to
get all the host disk usage when containerized the monitor tool?



On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
> Understood.
>
> 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>>
>> On 25/07/16 06:38, Mathias Ewald wrote:
>> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>> > tenants rather than cloud ops? If that's the case I wont find info like
>> > "controller cpu usage" or "hypervisor memory usage".
>> >
>> > Cheers
>> > Mathias
>> >
>> Uhm, in this scenario, gnocchi just used as time-series database. It's
>> up to you, what you feed in. collectd collects whatever you want and put
>> it into your database.
>>
>> Best,
>> Matthias
>>
>> --
>> Matthias Runge 
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham,
>> Michael O'Neill, Eric Shander
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Mobil: +49 176 10567592
> E-Mail: mew...@evoila.de
>
> evoila GmbH
> Wilhelm-Theodor-Römheld-Str. 34
> 55130 Mainz
> Germany
>
> Geschäftsführer: Johannes Hiemer
>
> Amtsgericht Mainz HRB 42719
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If You
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing 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] Priority Spec for Libvirt Storage Pools

[Carlton, Paul (Cloud Services)]

Matt


With help from Maxim Nestratov of Virtuozzo I made some progress with the 
issues relating to my libvirt storage pools spec at the mid cycle last week, 
could you take another look at https://review.openstack.org/#/c/310505/ please, 
I'd like to get this approved so I can land some changes in Newton


Thanks


Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard Enterprise
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Office: +44 (0) 1173 162189
Mobile:+44 (0)7768 994283
Email:paul.carl...@hpe.com
Hewlett-Packard Enterprise Limited registered Office: Cain Road, Bracknell, 
Berks RG12 1HN Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error, you should 
delete it from your system immediately and advise the sender. To any recipient 
of this message within HP, unless otherwise stated you should consider this 
message and attachments as "HP CONFIDENTIAL".


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

Re: [openstack-dev] [kolla] Monitoring tooling

[Mathias Ewald]

Understood.

2016-07-25 7:34 GMT+02:00 Matthias Runge :

> On 25/07/16 06:38, Mathias Ewald wrote:
> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
> > tenants rather than cloud ops? If that's the case I wont find info like
> > "controller cpu usage" or "hypervisor memory usage".
> >
> > Cheers
> > Mathias
> >
> Uhm, in this scenario, gnocchi just used as time-series database. It's
> up to you, what you feed in. collectd collects whatever you want and put
> it into your database.
>
> Best,
> Matthias
>
> --
> Matthias Runge 
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham,
> Michael O'Neill, Eric Shander
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Mobil: +49 176 10567592
E-Mail: mew...@evoila.de

evoila GmbH
Wilhelm-Theodor-Römheld-Str. 34
55130 Mainz
Germany

Geschäftsführer: Johannes Hiemer

Amtsgericht Mainz HRB 42719

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If You
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev