Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[James Bottomley]

On Thu, 2016-07-07 at 21:28 -0500, Edward Leafe wrote:
> On Jul 7, 2016, at 8:33 PM, Joshua Harlow 
> wrote:
> > 
> > That's sad, how can we fix the fact that users/deployments have
> > gone off into their own silos and may be running their own forks;
> > what went wrong (besides some of the obvious stuff that I think I
> > know about, that others probably don't) that resulted in this
> > happening?
> > 
> > Seems like something we can learn from by reflecting on this and
> > trying to find a path forward (or maybe we just accept there isn't
> > one, idk).
> 
> I think admitting that it was a conceptual mis-match from the start
> would be the first step. Containers are not VMs.

That's not a correct statement: they certainly can be orchestrated like
VMs if constructed like them: that's actually what operating system
containers are.  However, container systems are also amenable to being
constructed very differently from VMs because of the granular nature of
the virtualisations.

>  Attempts to treat them as such are always going to be poor
> compromises.

I think this reflects the persistent failure OpenStack has had in
trying to encompass the entire container space.  The problem is that
they're not monolithic, like VMs for which, whether it's ESX, KVM, Xen
or HyperV, one VM looks very like another.  The homogeneous nature of
VMs makes it natural to think containers can be pidgeonholed in the
same way ... the problem is that really, they can't.  Some container
systems absolutely can be orchestrated by nova and some can't.

Currently there is no one OpenStack system that can orchestrate the
full power of containers as presented by the raw Linux API.  I don't
think this is a particular problem because there's no industrial
consumer begging for that full power.  Right at the moment, containers
are consumed as a collection of disparate use cases and, reflecting
this, OpenStack has a variety of systems corresponding somewhat to the
consumption models.  However, being use case specific, none of them can
orchestrate an arbitrary "container" system, and, of course, any new
use case that arises likely doesn't fit with any of the current models.
 Reality is being messy again, I'm afraid.

> Containers have an important place in OpenStack; it's just not in
> Nova.

Following this theory, the next move would be trying to remove the lxc
and vz container drivers from nova?  I really don't think that's a good
idea because the fit is quite useful for a significant set of use
cases.

James


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


signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing 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] What's Up, Doc? 8 July

[Lana Brindley]

Hi everyone,

This week I'm pleased to report that the index page for the new Install 
Tutorials is up and running! We also had some lengthy discussions about the use 
of conditionalised formatting (with ``only``), so there were a few meaty topics 
to go through in the meeting this week. It's also been way too long since we 
last did a core team review, so that happened this week. I'd also like to 
remind you that the CFP for Barcelona is only open until mid next week, so get 
your proposals in soon!  

== Progress towards Newton ==

89 days to go!

Bugs closed so far: 256

I think 50 bugs in two weeks is something of a record! Thanks to all the bug 
smashers working hard this week :)

Newton deliverables: 
https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
Feel free to add more detail and cross things off as they are achieved 
throughout the release.

The CFP for Barcelona is open now, until 13 July. If you want to brainstorm 
some documentation-related ideas, please get in touch!

== Speciality Team Reports ==

'''HA Guide: Bogdan Dobrelya'''
No report this week.

'''Install Guide: Lana Brindley'''
Index page is now up, needs some iteration to improve. Decided against using 
``only`` for now (review after Newton), Manila patch to be updated. Next 
meeting: 19 July 0600 UTC

'''Networking Guide: Edgar Magana'''
No meeting this week. Keep trying to move documentation from other dispersed 
places to the networking guide.

'''Security Guide: Nathaniel Dillon'''
No report this week.

'''User Guides: Joseph Robinson'''
Adding the consistency notes to the work items wiki page. Team emails.

'''Ops Guide: Shilla Saebi'''
No report this week.

'''API Guide: Anne Gentle'''
Sign up on the etherpad to participate in a keystone Identity API sprint: 
https://etherpad.openstack.org/p/keystone-api-sprint 
New patch this week to migrate the ceilometer Telemetry API docs, please 
review:  https://review.openstack.org/334028 Thank you Khushbu!
Need another +2 from the swift team for their migration patch: 
https://review.openstack.org/#/c/312315/
Updated patch in the governance repo projects.yaml file to indicate both 
contributor docs URLs and API docs URLs: 
https://review.openstack.org/#/c/316396/ Consider a work in progress for URL 
completeness and accuracy, but please review for format.
Responding to input about API versions and release versions. See 
http://lists.openstack.org/pipermail/openstack-docs/2016-July/008818.html 

'''Config/CLI Ref: Tomoyuki Kato'''
Closed many bugs.
Implementing common configuration sections for shared services and libraries.
Updated a few clients reference, and added solum client.

'''Training labs: Pranav Salunke, Roger Luethi'''
No report this week.

'''Training Guides: Matjaz Pancur'''
No report this week.

'''Hypervisor Tuning Guide: Blair Bethwaite
No report this week.

'''UX/UI Guidelines: Michael Tullis, Rodrigo Caballero'''
Three out of the five personas have been created and are being reviewed.
https://review.openstack.org/#/c/326662/
The last two personas will be added to the change within the week.
It was suggested to add a checklist for developers to be able to identify the 
appropriate persona for their work.

== Core Team Review ==

The core team have completed their review for July, and we would like to 
welcome Joseph Robinson to the openstack-doc-core team.

Joseph has been leading the User Guides speciality team for some time now, and 
has been a docs-specs-core as part of that role. Welcome to the larger core 
team, Joseph, we're really pleased to have you aboard :)

== Site Stats ==

25% of our hits are coming from new (rather than returning) users.

== Doc team meeting ==

Next meetings:

The US meeting was held this week, you can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-07-06

Next meetings:
APAC: Wednesday 13 July, 00:30 UTC
US: Wednesday 20 July, 19:00 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#8_July_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Joshua Harlow]

Edward Leafe wrote:

On Jul 7, 2016, at 8:33 PM, Joshua Harlow  wrote:

That's sad, how can we fix the fact that users/deployments have gone off into 
their own silos and may be running their own forks; what went wrong (besides 
some of the obvious stuff that I think I know about, that others probably 
don't) that resulted in this happening?

Seems like something we can learn from by reflecting on this and trying to find 
a path forward (or maybe we just accept there isn't one, idk).


I think admitting that it was a conceptual mis-match from the start would be 
the first step. Containers are not VMs. Attempts to treat them as such are 
always going to be poor compromises.

Containers have an important place in OpenStack; it's just not in Nova.



Then can we get 
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n2514 
finally adjusted to be what it really is... instead of what it really 
isn't...




-- Ed Leafe






__
OpenStack Development Mailing 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] Liberty: (path|segment)_mtu values

[Nicolas Bock]

On 07/07/2016 09:26 PM, Matt Kassawara wrote:
> The effect of these options depends on your version of Liberty. Some
> patches fixing MTU implementation in Mitaka+ were backported to Liberty [1].
> 
> [1] https://review.openstack.org/#/c/305782/
> 
Thanks for the pointer Matt. I have started reading the source code,
which already made a few things much clearer.

Nick

> On Mon, Jul 4, 2016 at 2:18 AM, Nicolas Bock  > wrote:
> 
> Hi,
> 
> I am trying to understand the effect of the variables `path_mtu` and
> `segment_mtu` of `ml2_conf.ini`.
> 
> - Is it necessary to set values for those two variables?
> - What does neutron do with the values for those variables?
> - According to the documentation, a value of <= 0 means that the
> (path|segment)_mtu values are indeterminate. What does neutron do in
> this case?
> 
> Thanks,
> 
> Nick
> 
> 
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> 
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Bilean][CloudKitty][Telemetry] Opendiscussionaround Bilean and existing OpenStack components

[吕冬兵]

Hi Stéphane, 
 


 
I got what you mean, I’m sure that CloudKitty can rating by event, but I have 
some other puzzles. Let me generally describe the arch of Bilean first
 
[events] <—> [rating] <—> [billing]
 
When event coming from notification, bilean engine will rating the resource 
according policy and rule. A rule reference to a kind of resource(instance, 
volumes e.g), and a policy consists of several rules, different user can use 
different billing policy). After that engine will update user’s rate. Bilean 
doesn’t have period task to do billing work, but triggered by events and period 
task to do health check for users (daily task now). When user’s balance is 
almost used up, bilean engine will notify user. 
 
So you see, Bilean is a closed-loop billing solution, what I mean trigger-based 
billing is not just rating by events, the main thing is billing. Does 
CloudKitty do billing too? And how? If not or has different solution about 
that, force to combine them will make it neither fish nor fowl.
 


 
Best regards,
 
lvdongbing

 
 
-- Original --
From:  "Stéphan Albert";
Date:  Fri, Jul 8, 2016 05:44 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [Bilean][CloudKitty][Telemetry] 
Opendiscussionaround Bilean and existing OpenStack components

 
On Thu, Jul 07, 2016 at 09:50:02AM +0800, 吕冬兵 wrote:
> Hi,
> 
> I'm sorry to see this discussion so late:). Thanks for attention.
> 
> I don't oppose to contribute to add trigger-based solution to
> CloudKitty, I just want to know if it's possible to support
> trigger-based for CloudKitty based on now arch, pls generally describe
> how. And another thing I want to make sure is that if it's good to mix
> two different solution in one component.
Hi,

At the moment we have an arch that looks like this

[collector] <-> [orchestrator] <-> [rating, storage, etc]

The orchestrator is responsible of polling data from different backends
using collectors.
We are currently working on a refactor of the internal architecture, we
plan on having rating engines as drivers to ease transitions and
possibility to fully integrate with other engines. And we'll add the "on
demand collect" which is basically a smarter rating engine.
We can easily do something like this:

   [events]
  ^
  |
  v
[collector] <-> [orchestrator] <-> [rating, storage, etc]

Which is just adding notification handling to the orchestrator. Events
will then be processed by the rating engine.

Everything can be enabled/disabled easily using configuration so that
users can choose what type they need (poll/event). I don't see what can
be the blocking point here.

The new rating engine is on the agenda of next Monday meeting, we can
add a point to talk about collaboration on event based rating.

I'm available if you need any information.

Cheers,
Stéphane

__
OpenStack Development Mailing 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] [nova][nova-docker] Retiring nova-docker project

[Edward Leafe]

On Jul 7, 2016, at 8:33 PM, Joshua Harlow  wrote:
> 
> That's sad, how can we fix the fact that users/deployments have gone off into 
> their own silos and may be running their own forks; what went wrong (besides 
> some of the obvious stuff that I think I know about, that others probably 
> don't) that resulted in this happening?
> 
> Seems like something we can learn from by reflecting on this and trying to 
> find a path forward (or maybe we just accept there isn't one, idk).

I think admitting that it was a conceptual mis-match from the start would be 
the first step. Containers are not VMs. Attempts to treat them as such are 
always going to be poor compromises.

Containers have an important place in OpenStack; it's just not in Nova.


-- Ed Leafe







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

[Openstack-operators] ACTION Needed - All WGs Chairs

[Edgar Magana]

Dear Working Groups Chairs,

As you know WGs present an opportunity to consolidate and increase the 
Community around OpenStack from the User and Operator perspective. One of the 
goals of the User Committee is to help WGs to have the resources needed to 
achieve their specific goals and exactly as the TC validates and accepts 
development projects the UC needs to validate and accept WGs before they be 
granted with resources and support from UC and the OpenStack Foundation. 
(https://wiki.openstack.org/wiki/Procedure_for_Creating_a_New_Working_Group)

In order to validate the current work and progress of the existing WGs under: 
https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups
The UC would like to have all chairs to reply to this thread with the status of 
the WG and their plans for the Barcelona summit. This is also an opportunity to 
have a space allocated to get together and discuss about work and activities. 
This is only for existing WGs not for new ones. If we do not hear from WG 
Chairs, we will assume that those WGs are no longer active and therefore they 
will be removed from UC documentation.

Please, reach out to us with a short report of the activities (wikis, 
etherpads, repos, etc).

Thanks,

Edgar, Shilla and Jon
UC Members.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Joshua Harlow]

That's sad, how can we fix the fact that users/deployments have gone off 
into their own silos and may be running their own forks; what went wrong 
(besides some of the obvious stuff that I think I know about, that 
others probably don't) that resulted in this happening?


Seems like something we can learn from by reflecting on this and trying 
to find a path forward (or maybe we just accept there isn't one, idk).


Matt Riedemann wrote:

On 7/7/2016 3:12 PM, Davanum Srinivas wrote:

Folks,

The nova-docker project[1] is barely alive[2]. So i'll kick off the
process of retiring the project [3]

Thanks,
Dims

[1] http://git.openstack.org/cgit/openstack/nova-docker/
[2] http://stackalytics.com/report/contribution/nova-docker/30
[3]
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project



+1

Expand the numbers to 6 months and you'll see only 13 commits.

It's surprisingly high in the user survey (page 39):

https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

So I suspect most users/deployments are just running their own forks.



__
OpenStack Development Mailing 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][linux bridge]

[Bhatia, Manjeet S]

Hi,

There is work in progress for pure python driven linux network configuration. I 
think most
of work will be done with this patch https://review.openstack.org/#/c/155631/ . 
The only
thing left after this will be linux bridge configuration, Which I would like to 
discuss with
community. There are two ways at the moment I can think to do that 
implementation,
First, use pybrctl which may need some changes in library itself in order for 
full support.
It will clean up the code from neutron. But looking pybrctl code which is just 
executing
Shell commands, another solution which Brandon Logan discussed is move the 
existing
Code for executing those commands to neutron-lib, which I think is better 
solution. I would
like to have views of community, especially people working neutron-lib about 
moving
python code for executing brctl commands to neutron-lib.


Thanks and Regards !
Manjeet Singh Bhatia
__
OpenStack Development Mailing 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-Infra] Barcelona summit talk ideas

[Elizabeth K. Joseph]

On Tue, Jun 14, 2016 at 7:07 AM, Paul Belanger  wrote:
> Greetings,
>
> I wanted to start another etherpad[1] for collaboration on summit talk ideas
> related to openstack-infra. I think it worked well for Austin and see no 
> reason
> not to do it again.
>
> I've already outlined a few ideas of what interests me (and hopefully others),
> please take a moment to review and add your own ideas.
>
> We have until July 13 to submit talks[2]:
>
>  JULY 13, 2016 AT 11:59PM PDT (JULY 14 6:59 UTC) IS THE DEADLINE TO SUBMIT A
>  TALK.
>
> [1] https://etherpad.openstack.org/p/barcelona-upstream-openstack-infa
> [2] https://www.openstack.org/summit-login/login

Talks seem to be coming together, which is good since the deadline is
less than a week away :)

We have a lightning talks section of the Etherpad. In case anyone
missed it, thingee mentioned at our meeting this week and has sent an
email about how to participate in the upstream lightning talks he's
hosting again 
(http://lists.openstack.org/pipermail/openstack-dev/2016-July/098945.html)
so we probably want to firm up our talk plans for that too.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [TripleO][os-net-config] add support for NFV virtual switch

[Xin Wu]

Hi,

This is Xin from Big Switch. I'm proposing to make os_net_config support
DPDK switch for NFV workloads.
 Current os_net_config supports ovs_bridge, linux_bridge, ivs_bridge
and different types of interfaces. The os_net_config's abstraction is
perfect to support DPDK switches for NFV workloads as well.
 If this proposal makes sense, I would love to start with adding the
support for Big Switch's DPDK switch first, which is called nfv-switch. The
code change will be very similar to https://review.openstack.org/#/c/274492/

Thanks a lot

Xin
__
OpenStack Development Mailing 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] [Bilean][CloudKitty][Telemetry] Open discussionaround Bilean and existing OpenStack components

[Stéphane Albert]

On Thu, Jul 07, 2016 at 09:50:02AM +0800, 吕冬兵 wrote:
> Hi,
> 
> I'm sorry to see this discussion so late:). Thanks for attention.
> 
> I don't oppose to contribute to add trigger-based solution to
> CloudKitty, I just want to know if it's possible to support
> trigger-based for CloudKitty based on now arch, pls generally describe
> how. And another thing I want to make sure is that if it's good to mix
> two different solution in one component.
Hi,

At the moment we have an arch that looks like this

[collector] <-> [orchestrator] <-> [rating, storage, etc]

The orchestrator is responsible of polling data from different backends
using collectors.
We are currently working on a refactor of the internal architecture, we
plan on having rating engines as drivers to ease transitions and
possibility to fully integrate with other engines. And we'll add the "on
demand collect" which is basically a smarter rating engine.
We can easily do something like this:

   [events]
  ^
  |
  v
[collector] <-> [orchestrator] <-> [rating, storage, etc]

Which is just adding notification handling to the orchestrator. Events
will then be processed by the rating engine.

Everything can be enabled/disabled easily using configuration so that
users can choose what type they need (poll/event). I don't see what can
be the blocking point here.

The new rating engine is on the agenda of next Monday meeting, we can
add a point to talk about collaboration on event based rating.

I'm available if you need any information.

Cheers,
Stéphane

__
OpenStack Development Mailing 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] Lightning Talks For Barcelona

[Mike Perez]

Hi all,

Just like in Austin we will have Lightning Talks for the Upstream Development
track.

Presentation should be:

* 5 minutes

* Not a sales pitch of your product, company, etc.

* Being related to upstream development. Examples of ideas but not limited to:
  - A cool oslo library you want to show off.
  - Neat editor trick/scripts/non-OpenStack project that makes development in
OpenStack easy.
  - Encouraging good practices such as style, API's, etc.

Please email me directly with your little abstract. Last time lightning talks
happened on the first day on the last time slot. I don't know when they will
be this time, but I will update you all. Thanks!

-- 
Mike Perez

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

[openstack-dev] [release] Release countdown for week R-12, July 11-15 (Newton Milestone 2)

[Doug Hellmann]

Focus
-

Major feature work should be well under way as we approach the
second milestone.

General Notes
-

Keep in mind that we freeze releases of all libraries between the
third milestone and the final release to give downstream packagers
time to vet the libraries. Only emergency bug fix updates are allowed
during that period. Prioritize any feature work that includes work
in libraries to ensure that it can be completed and the library
released before the freeze.

Release Actions
---

Official projects following any of the cycle-based release models
should propose beta 2 tags for their deliverables by 14 July.

This is also a good time to review stable/liberty and stable/mitaka
branches for needed releases.

Important Dates
---

Newton 2 milestone, July 14.

Library release freeze date starting R-6, Aug 25.

Newton 3 milestone, Sept 1

Newton release schedule: http://releases.openstack.org/newton/schedule.html

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

Re: [openstack-dev] [puppet] Request to add puppet-dpdk module

[Russell Bryant]

On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:

> Hello,
>
> We are working on blueprint [1] to integrate DPDK with tripleo. In the
> process, we are planning to add a new puppet module "puppet-dpdk" for the
> required puppet changes.
>
> The initial version of the repository is at github [2]. Note that the
> changes are
> ​not ​
> complete yet. It is in progress.
>
> Please let us know your views on including this new module.
>
> Regards,
> Saravanan KR
> ​
>
> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
> [2] https://github.com/krsacme/puppet-dpdk
>

​I took a quick look at Emilien's request.  In general, including this
functionality in the puppet openstack project makes sense to me.

It looks like this is installing and configuring openvswitch-dpdk.  Have
you considered integrating DPDK awareness into the existing puppet-vswitch
that configures openvswitch?  Why is a separate puppet-dpdk needed?

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

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Matt Riedemann]

On 7/7/2016 3:12 PM, Davanum Srinivas wrote:

Folks,

The nova-docker project[1] is barely alive[2]. So i'll kick off the
process of retiring the project [3]

Thanks,
Dims

[1] http://git.openstack.org/cgit/openstack/nova-docker/
[2] http://stackalytics.com/report/contribution/nova-docker/30
[3] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project



+1

Expand the numbers to 6 months and you'll see only 13 commits.

It's surprisingly high in the user survey (page 39):

https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

So I suspect most users/deployments are just running their own forks.

--

Thanks,

Matt Riedemann


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

Re: [Openstack-operators] Please review: OpenStack Personas Document

[Silence Dogood]

Vish the virtual machine barista?

On Thu, Jul 7, 2016 at 4:23 PM, Kruithof Jr, Pieter <
pieter.kruithof...@intel.com> wrote:

> Operators,
>
> If you have a few moments, please review the following:
>
> https://review.openstack.org/#/c/326662/14
>
> The intent of the document is to generate a group of personas
> that represent the different users of OpenStack.  We’re currently working
> on Alan the App Developer, Carlos Cloud Operator and Doug the Domain
> Operator.
>
> The intent is to help build consistency across the projects by landing on
> a standard definition of our users.  It would be really helpful to get you
> feedback for all of you.
>
> Thanks,
>
> Piet
>
> --
> Piet Kruithof
> Sr User Experience Architect, Intel OTC
> PTL, OpenStack UX Project
>
> Mobile: 512 576-2844
> IRC: piet
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Please review: OpenStack Personas Document

[Kruithof Jr, Pieter]

Operators,

If you have a few moments, please review the following:

https://review.openstack.org/#/c/326662/14

The intent of the document is to generate a group of personas that represent 
the different users of OpenStack.  We’re currently working on Alan the App 
Developer, Carlos Cloud Operator and Doug the Domain Operator.

The intent is to help build consistency across the projects by landing on a 
standard definition of our users.  It would be really helpful to get you 
feedback for all of you.

Thanks,

Piet

--
Piet Kruithof
Sr User Experience Architect, Intel OTC
PTL, OpenStack UX Project

Mobile: 512 576-2844
IRC: piet
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Davanum Srinivas]

Folks,

The nova-docker project[1] is barely alive[2]. So i'll kick off the
process of retiring the project [3]

Thanks,
Dims

[1] http://git.openstack.org/cgit/openstack/nova-docker/
[2] http://stackalytics.com/report/contribution/nova-docker/30
[3] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

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

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

Re: [Openstack] Liberty: (path|segment)_mtu values

[Matt Kassawara]

The effect of these options depends on your version of Liberty. Some
patches fixing MTU implementation in Mitaka+ were backported to Liberty [1].

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

On Mon, Jul 4, 2016 at 2:18 AM, Nicolas Bock  wrote:

> Hi,
>
> I am trying to understand the effect of the variables `path_mtu` and
> `segment_mtu` of `ml2_conf.ini`.
>
> - Is it necessary to set values for those two variables?
> - What does neutron do with the values for those variables?
> - According to the documentation, a value of <= 0 means that the
> (path|segment)_mtu values are indeterminate. What does neutron do in
> this case?
>
> Thanks,
>
> Nick
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Internal integration (best?) practices

[Joshua Harlow]

Cool, so we aren't alone here (I knew it!)

Has the DNS generation ever been a problem for you, as its out of band 
and can have problems like if it ever stops working, the DNS name may be 
reported in the instance, but that hostname may not actually be in DNS 
and thus this equals a confused user?


Same goes with cleanup as well, when it's out of band it's hard to 
handle the failure of DNS to actually perform the delete and therefore 
it makes it hard/impossible to stop the instance from being deleted if 
this happens (and if a DNS deletion failure occurs and the user tries to 
reuse the same hostname in a short period of time before that problem is 
fixed then you get a doubly confused user).


It almost makes me desire for a more customizable boot/delete-workflow 
where these kinds of additional actions can be tied into the larger 
workflow for those that want to do them (in a way there would be a 
standard workflow that would be the accepted openstack way, but it would 
be relatively easy to add a new  in that to call out to DNS or to 
do ...).


Ben Morrice wrote:

Hello,

We do something similar. Our requirements are:

* VM is registered in CMDB (foreman as we are a puppet shop)
* VM is registered in DNS
* Cleanup of the above is performed on VM termination

Our Horizon is customised, so that when a VM is spawned the user can
associate it to a foreman hostgroup and environment. If the user doesn't
select a hostgroup/environment the record is still created in foreman as
'unmanaged'.
If the record is not able to be created in Foreman, Horizon will fail at
this point and the VM will not be spawned.

We also have a bit of python that listens and reacts to
compute.instance.create.end and compute.instance.delete.end messages in
the notification queue.

For creations we do a bit of sanity checking and create A records based
off the VM name
For deletions we remove the DNS A records, remove from Foreman as well
as checking/removing from other systems that the VM may have been a be a
member of (example: GPFS cluster member invoked through puppet).

We decided to react on compute.instance.create.end messages for DNS
creations as we wanted to be able to use HEAT and automatically
generated hostnames.

I'm not sure what the 'best practices' are, however this setup has been
working nicely for us for the past 2 years.

Kind regards,

Ben Morrice

__
Ben Morrice | e: ben.morr...@epfl.ch | t: +41-21-693-9670
EPFL ENT CBS BBP
Biotech Campus
Chemin des Mines 9
1202 Geneva
Switzerland

On 06/07/16 20:13, Joshua Harlow wrote:

Hi folks (operators and devs),

I was digging into some of godaddy code yesterday/everyday and it got
me thinking about how other operators are handling customized internal
integrations and what some of the common patterns are for how these
integrations are typically performed (overall it doesn't feel like
there are that many patterns that people can be doing in that many
different ways). It got me thinking that there really isn't a best
practices document that I know for these types of common integrations
(perhaps this can be the start of one?) that operators and developers
can provide feedback on (because perhaps there is a new or to-be new
API that replaces an older style of integration).

This hopefully falls into the pattern (and/or is similar to) that is
described in:

https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html#alternatives-for-extension-owners


'''
Please bring forward the conversation to the wider community anyway.
There are a lot of OpenStack deploys, and issues that you think are
specific to your environment may not be. And in conversation with the
upstream operator and developer communities we could probably come up
with a generic facility that supports your use.
'''

So let me describe some of the internal integrations we've had to do
and see if these sound familiar to what others have had to do and it'd
be nice to share how those integrations were performed (or even if the
integration that was done is similar or done in a different manner,
that's cool to):

(1) Requirement we have is to register virtual machines booted with a
in-house dns solution and to also delete dns names registered on
deletion being triggered.

The steps this will do is on reception of a
'compute.instance.create.end' event being received (the program that
does this listens on the notifications queue of nova) logic will
proceed that will (direct comment from routine here):

'Creates A and PTR records based off of the instance's hostname and
fixed ip.'

This goes about and has further logic to realize this statement (its
error robustness is a different discussion, but I digress) and the
'compute.instance.delete.end' event does the reverse:

'Removes instance's DNS entries. Will remove A and PTR records.'

Now sidestepping the choice of using the notifications queue (and
having a consumer 

Re: [openstack-dev] Manila TripleO Mitaka

[Charles Short]

Hi Marios,

Many thanks for the update, that does help clarify 

Regards

Charles

Sent from my iPhone

> On 7 Jul 2016, at 17:14, Marios Andreou  wrote:
> 
>> On 07/07/16 14:25, Charles Short wrote:
>> Hi,
> Hi Charles,
> 
>> 
>> I am deploying TripleO Mitaka stable and want to include the NetApp
>> Manila driver referenced here -
>> 
>> http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/deploy_manila.html
> 
> thanks for pointing those docs out - to be honest I don't know why we
> landed those since the manila integration itself is still in progress. I
> went looking for the gerrit review but gave up - found the commit at
> https://github.com/openstack/tripleo-docs/commit/01ee4f59356b7d7df572d021931a4c7fa1e07cd9
> ... in any case I think we need to mark these WIP and I'm doing that at
> https://review.openstack.org/339109
> 
> 
>> I cannot see either templates available in the Undercloud.
>> 
>> Digging a bit it looks like there are some hurdles to overcome -
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/096126.html
>> 
>> Does anyone have an update on progress, especially for the NetApp driver?
> 
> 
> Currently I am aware of three reviews related to Manila. One is the
> 'main' patch to land manila-generic backend and the other two are for
> netap and gluster integration respectively.
> 
>https://review.openstack.org/#/c/188137/ “Enable Manila integration
> - as a composable controller service”
> 
>https://review.openstack.org/#/c/188138/ “Add integration with
> NetApp Manila driver”
> 
>https://review.openstack.org/#/c/230936/ “Add Gluster integration to
> Manila”
> 
> 
> The Manila integration as a composable service needs to land first. The
> Netapp and Gluster reviews I've not had any involvement in at all; they
> will also need to tlc to get landed, but they both depend on the 'main'
> manila integration patch.
> 
> 
> Hope that helps clarify the situation somewhat,
> 
> thanks, marios
> 
> 
> 
>> 
>> Many thanks
>> 
>> Charles
> 
> 
> __
> OpenStack Development Mailing 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] Opportunity to contribute in OpenStack

[Jainesh Patel]

Hello,

We are a group of students that are currently pursuing our undergraduate
degree in Computer Science from Pune Institute of Computer
Technology(PICT), Maharashtra, India. We will be graduating in June 2017
and are currently in our final year. For our B.E project, we have selected
the domain as Cloud Computing and would be very interesting to work on
OpenStack.

It will be a great learning opportunity for us to work with OpenStack and
in turn work with you. We would appreciate if you could steer us towards
the direction of choosing the right topic and working towards culminating a
project in the same, which would be helpful for the community.

Following are the few details which include information about us, which
would help you in making an informed decision:

1) Group Name- TheAtom

2) Group Members:
Shubham Mulay ( shubhammu...@gmail.com )
Faizaan Shaikh ( faizaanshai...@gmail.com )
Jainesh Patel ( jainesh...@gmail.com )

3) We have two mentors working with us, who will be guiding throughout the
process,
Dhruvesh Rathore ( dhruves...@hotmail.com )
Prerit Auti ( prerita...@gmail.com )

4) Development time : 6 to 7 months from Aug '16 to Feb '17.

We would love to hear from you about any ideas that you see fit for us to
pursue and which are feasible in the specified time frame. Hoping to hear
from you soon, and thanking you in anticipation.

Regards,
TheAtom
__
OpenStack Development Mailing 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-Infra] JJB V2.0 planning

[Darragh Bailey]

Took a bit of doing, but worked out what was needed to use #openstack-sprint

Created an entry on the Virtual Sprint wiki page:
https://wiki.openstack.org/wiki/VirtualSprints#JJB_V2.0_API_Sprint

Chat to you all tomorrow.


On 6 July 2016 at 21:01, Darragh Bailey  wrote:

> Hi,
>
> On 6 Jul 2016 20:26, "Paul Belanger"  wrote:
> >
>
> Snipped
>
> > > Also thinking that spinning up a temporary public dedicated IRC chat
> room
> > > would be helpful here, probably look to avoid using one of the existing
> > > meeting rooms because I'm assuming that would conflict with other
> teams,
> > > unless someone tells me there is a simple solution to this. Only
> negative I
> > > can see is that the chats wouldn't be logged.
> > >
> > You may want to check if the #openstack-sprint channel is available on
> freenode.
> > We have logging enabled on it and seems like a natural fit for your
> agenda.
> >
>
> Fantastic, thanks for that suggestion. Even if it's not those time,
> hopefully it will be for the next ones.
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool" - unknown
>



-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack-operators] Kilo ->-> Mitaka anyone have notes :)

[Jesse Keating]

That's strange, this very command has worked for every environment we've tried, Kilo -> Mitaka. No errors, successful appearing migration, continued Nova operation after the fact.
 
Maybe I'm missing something. I realize it's untested, but the sync command does not fail.
-jlk
 
 
- Original message -From: Andrew Laski To: openstack-operators@lists.openstack.orgCc:Subject: Re: [Openstack-operators] Kilo ->-> Mitaka anyone have notes :)Date: Mon, Jun 27, 2016 5:35 AM 
On Sun, Jun 26, 2016, at 07:58 PM, Sam Morrison wrote:> I’ve done kilo -> mitaka with Keystone and all worked fine. Nothing> special I needed to do.>> If you’re wanting to do live upgrades with nova you can’t skip a version> from my understanding.Correct. Not without doing the work yourself to make it possible, andrealizing that it's untested/unsupported and likely will bring outgremlins.In order to make db migrations less painful, i.e. faster, Nova moved toa system where only schema changes occur in the sqlalchemy-migratemigrations and all data is migrated by another nova-manage command whichcan be run while the system is in use. But the side effect of this isthat the data migration needs to take place for each release, and thereare checks in place to ensure this happens. Unless you have an emptydatabase "nova-manage db sync" won't even complete successfully forkilo->mitaka since there's a check in place to ensure the liberty datamigration took place.>> Sam>>> > On 25 Jun 2016, at 4:16 AM, Jonathan Proulx  wrote:> >> > Hi All,> >> > I about to start testing for our Kilo->Mitaka migration.> >> > I seem to recall many (well a few at least) people who were looking to> > do a direct Kilo to Mitaka upgrade (skipping Liberty).> >> > Blue Box apparently just did and I read Stefano's blog[1] about it,> > and while it gives me hope my plan is possible it's not realy a> > technical piece.> >> > I'm on my 7th version of OpenStack for this cloud now so not my first> > redeo as they say, but other than read Liberty and Mitaka release> > notes carefully and test like crazy wonder if anyone has seen specific> > issues or has specific advice for skiping a step here?> >> > Thanks,> > -Jon> >> > --> > [1] https://www.dreamhost.com/blog/2016/06/21/dreamcompute-goes-m-for-mitaka-without-unleashing-the-dragons/> >> > ___> > OpenStack-operators mailing list> > OpenStack-operators@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>>> ___> OpenStack-operators mailing list> OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators___OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Matt Fischer]

That's my comment I spoke to Mark V about it this morning and he's working
on it already, so you may want to coordinate with him.

On Thu, Jul 7, 2016 at 11:20 AM, Amrith Kumar  wrote:

> I see a comment in https://etherpad.openstack.org/p/NYC-ops-meetup about
> “OpenStack East Discount?”.
>
>
>
> If someone wants to pursue this, please let me know; I’ll get you in touch
> with folks who are doing the registration for OpenStack East and you’ll be
> able to get (maybe) a joint registration thing going to get the discount.
>
>
>
> -amrith
>
>
>
> *From:* Chris Morgan [mailto:mihali...@gmail.com]
> *Sent:* Wednesday, July 06, 2016 4:08 PM
> *To:* Saverio Proto 
> *Cc:* openstack-operators@lists.openstack.org
> *Subject:* Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26
>
>
>
> For the purposes of the mid-cycle meeting this august, I can be the point
> of contact:
>
>
>
> If anyone needs my full contact info, just email me here and I will reply
> with full details. Sorry for the delay with this.
>
>
>
> Chris
>
>
>
> On Fri, Jun 24, 2016 at 10:42 PM, Chris Morgan 
> wrote:
>
> Hi there
>   Sorry for the delay. I am hoping to see our organizer asap Monday when
> she's back from a trip and to get an answer for this. I don't know who the
> official organizer is but I would think we could do this to just be a
> credible org that can confirm details like you mention.
>
> Chris (Bloomberg)
>
> Sent from my iPhone
>
>
> > On Jun  23, 2016, at 4:14 PM, Saverio Proto  wrote:
> >
> > Hello there :)
> >
> > is anyone from the openstack foundation or from bloomberg that can
> > help out with this ?
> >
> > I share this for anyone that needs visa.
> >
> > for Austin we had something like this:
> > https://www.openstack.org/summit/austin-2016/austin-and-travel/
> > https://openstackfoundation.formstack.com/forms/visa_form_austin_summit
> >
> > anyone that needs to apply for Visa will need a 'US point of contact
> > information'.
> >
> > Basically, if the organizer of the Ops Midcycle is officially the
> > openstack foundation or bloomberg, I need to enter in my visa
> > application the following info:
> >
> > Organization name
> > Address in the US
> > Phone number
> > Email
> >
> > It must be a phone number and a email where in case there is a check,
> > somebody can tell "yes of course, this guy exist and is coming to the
> > conference" :)
> >
> > How we sort this out ?
> >
> > thank you
> >
> > Saverio
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>
> --
>
> Chris Morgan 
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Amrith Kumar]

I see a comment in https://etherpad.openstack.org/p/NYC-ops-meetup about 
“OpenStack East Discount?”.

If someone wants to pursue this, please let me know; I’ll get you in touch with 
folks who are doing the registration for OpenStack East and you’ll be able to 
get (maybe) a joint registration thing going to get the discount.

-amrith

From: Chris Morgan [mailto:mihali...@gmail.com]
Sent: Wednesday, July 06, 2016 4:08 PM
To: Saverio Proto 
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

For the purposes of the mid-cycle meeting this august, I can be the point of 
contact:

If anyone needs my full contact info, just email me here and I will reply with 
full details. Sorry for the delay with this.

Chris

On Fri, Jun 24, 2016 at 10:42 PM, Chris Morgan 
> wrote:
Hi there
  Sorry for the delay. I am hoping to see our organizer asap Monday when she's 
back from a trip and to get an answer for this. I don't know who the official 
organizer is but I would think we could do this to just be a credible org that 
can confirm details like you mention.

Chris (Bloomberg)

Sent from my iPhone

> On Jun  23, 2016, at 4:14 PM, Saverio Proto 
> > wrote:
>
> Hello there :)
>
> is anyone from the openstack foundation or from bloomberg that can
> help out with this ?
>
> I share this for anyone that needs visa.
>
> for Austin we had something like this:
> https://www.openstack.org/summit/austin-2016/austin-and-travel/
> https://openstackfoundation.formstack.com/forms/visa_form_austin_summit
>
> anyone that needs to apply for Visa will need a 'US point of contact
> information'.
>
> Basically, if the organizer of the Ops Midcycle is officially the
> openstack foundation or bloomberg, I need to enter in my visa
> application the following info:
>
> Organization name
> Address in the US
> Phone number
> Email
>
> It must be a phone number and a email where in case there is a check,
> somebody can tell "yes of course, this guy exist and is coming to the
> conference" :)
>
> How we sort this out ?
>
> thank you
>
> Saverio
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Chris Morgan >
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Anita Kuno]

On 07/07/2016 12:43 PM, Shilla Saebi wrote:
> I don't think it's setup yet for the ops mid cycle.

Is there any sense of urgency on this? If not, could there be, please?

This is a significant event in terms of expense (New York accommodations
are very expensive) and logistics (New York accommodations are very hard
to get at any price).

Letting folks register will really help everyone concerned with the
travel logistics involved. Figuring out travel on limited time scales
(less that 2 months now) is challenging anywhere in the world, New York
much more so.

My thanks,
Anita.

> On Thu, Jul 7, 2016 at 12:25 PM, Edgar Magana 
> wrote:
> 
>> Folks,
>> Do we have an eventbrite already set up?
>>
>> Thanks,
>>
>> Edgar
>>
>> On 6/23/16, 1:14 PM, "Saverio Proto"  wrote:
>>
>> Hello there :)
>>
>> is anyone from the openstack foundation or from bloomberg that can
>> help out with this ?
>>
>> I share this for anyone that needs visa.
>>
>> for Austin we had something like this:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_summit_austin-2D2016_austin-2Dand-2Dtravel_=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=wf9aH1oLv0jEU-Xw0tQijtKexSOVHWxi6gfy8iZn36g=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_visa-5Fform-5Faustin-5Fsummit=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=n4Mtj1sOz0froNvkbC4f-w7qd-lF26MJ1aFZWtSi_f8=
>>
>> anyone that needs to apply for Visa will need a 'US point of contact
>> information'.
>>
>> Basically, if the organizer of the Ops Midcycle is officially the
>> openstack foundation or bloomberg, I need to enter in my visa
>> application the following info:
>>
>> Organization name
>> Address in the US
>> Phone number
>> Email
>>
>> It must be a phone number and a email where in case there is a check,
>> somebody can tell "yes of course, this guy exist and is coming to the
>> conference" :)
>>
>> How we sort this out ?
>>
>> thank you
>>
>> Saverio
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=hJ_UMzKTYvPT5NCIcRrq6bc1D7JZx9FZl9nzLqla8SM=
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Edgar Magana]

Thank you Allison.

Erin,

Basically, the meet-up is very close and we should speed up the Eventbrite 
creation. I hope you can help us and start the registration ASAP. A huge 
disclaimer,  I did not attend the team meeting last time so, they may have 
started this process and I am just messing things around.

Edgar

On 7/7/16, 9:40 AM, "Allison Price"  wrote:

Hi Edvar and Saverio, 

I wanted to bring my colleague, Erin Disney, into this thread as she will be 
one of the points of contact from the Foundation for the Ops Midcycle in New 
York. She will be able to help answer the questions around the Eventbrite 
registration and visas. 

Cheers,
Allison


Allison Price
OpenStack Marketing
alli...@openstack.org


> On Jul 7, 2016, at 11:25 AM, Edgar Magana  wrote:
> 
> Folks,
> Do we have an eventbrite already set up?
> 
> Thanks,
> 
> Edgar
> 
> On 6/23/16, 1:14 PM, "Saverio Proto"  wrote:
> 
> Hello there :)
> 
> is anyone from the openstack foundation or from bloomberg that can
> help out with this ?
> 
> I share this for anyone that needs visa.
> 
> for Austin we had something like this:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_summit_austin-2D2016_austin-2Dand-2Dtravel_=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=wf9aH1oLv0jEU-Xw0tQijtKexSOVHWxi6gfy8iZn36g=
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_visa-5Fform-5Faustin-5Fsummit=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=n4Mtj1sOz0froNvkbC4f-w7qd-lF26MJ1aFZWtSi_f8=
>  
> 
> anyone that needs to apply for Visa will need a 'US point of contact
> information'.
> 
> Basically, if the organizer of the Ops Midcycle is officially the
> openstack foundation or bloomberg, I need to enter in my visa
> application the following info:
> 
> Organization name
> Address in the US
> Phone number
> Email
> 
> It must be a phone number and a email where in case there is a check,
> somebody can tell "yes of course, this guy exist and is coming to the
> conference" :)
> 
> How we sort this out ?
> 
> thank you
> 
> Saverio
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=hJ_UMzKTYvPT5NCIcRrq6bc1D7JZx9FZl9nzLqla8SM=
>  
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwIFAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=lNuCpnzMaT-05LKn_FFNp0L8JET-rRkt-GlmvCwBXSs=YaNpLJXLTb5T6v9IAsbzYQuNa9iN9bJ4_eeRT5ZbVjk=
>  



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

No new guidelines have been merged or proposed for freeze this week, but 
we have cleaned up some of the language in the guideline pages and have 
had some productive discussions initiated by the Glance team about 
changes they are working towards.


# Recently merged guidelines

No new guidelines in the last two weeks but the following fixes were merged:

* Get rid of the DRAFT warning at the top of guidelines
  https://review.openstack.org/#/c/330687/
* Remove "Conveying error/fault information" section
  https://review.openstack.org/#/c/330876/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties. If you're the author of one of these older 
reviews, please come back to it or we'll have to mark it abandoned.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/



__
OpenStack Development Mailing 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-operators] Next Ops Midcycle NYC August 25-26

[Shilla Saebi]

I don't think it's setup yet for the ops mid cycle.

On Thu, Jul 7, 2016 at 12:25 PM, Edgar Magana 
wrote:

> Folks,
> Do we have an eventbrite already set up?
>
> Thanks,
>
> Edgar
>
> On 6/23/16, 1:14 PM, "Saverio Proto"  wrote:
>
> Hello there :)
>
> is anyone from the openstack foundation or from bloomberg that can
> help out with this ?
>
> I share this for anyone that needs visa.
>
> for Austin we had something like this:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_summit_austin-2D2016_austin-2Dand-2Dtravel_=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=wf9aH1oLv0jEU-Xw0tQijtKexSOVHWxi6gfy8iZn36g=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_visa-5Fform-5Faustin-5Fsummit=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=n4Mtj1sOz0froNvkbC4f-w7qd-lF26MJ1aFZWtSi_f8=
>
> anyone that needs to apply for Visa will need a 'US point of contact
> information'.
>
> Basically, if the organizer of the Ops Midcycle is officially the
> openstack foundation or bloomberg, I need to enter in my visa
> application the following info:
>
> Organization name
> Address in the US
> Phone number
> Email
>
> It must be a phone number and a email where in case there is a check,
> somebody can tell "yes of course, this guy exist and is coming to the
> conference" :)
>
> How we sort this out ?
>
> thank you
>
> Saverio
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=hJ_UMzKTYvPT5NCIcRrq6bc1D7JZx9FZl9nzLqla8SM=
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [nova] [ironic] Input types for scheduler filters

[Miles Gould]

Hi everyone,

tl;dr: the tests for the  operator in 
nova.scheduler.filters.extra_specs_ops do not test what it looks like 
they're meant to test. This is confusing us, and holding up work in 
Ironic. Does it match its arguments against a list of strings, or 
against a single string?


--

Over in Ironic, we need a more flexible language for specifying 
root-device hints, and we thought it would be a Good Thing to adopt the 
scheduler filter language used in Nova. There's already a review in 
progress to move that code into oslo.utils 
(https://review.openstack.org/#/c/308398) and another to clean it up 
with a well-defined formal grammar 
(https://review.openstack.org/#/c/313699/), so this ought to be an easy 
win. But! We're not sure that we've correctly understood the semantics 
of the language, which in turn means we can't tell if it's suitable for 
our use.


Here are two representative tests for the  operator:

def test_extra_specs_matches_one_with_op_allin(self):
values = ['aes', 'mmx', 'aux']
self._do_extra_specs_ops_test(
value=str(values),
req=' aes mmx',
matches=True)

def test_extra_specs_fails_with_op_allin(self):
values = ['aes', 'mmx', 'aux']
self._do_extra_specs_ops_test(
value=str(values),
req='  txt',
matches=False)

So it looks like  takes a list of strings, and matches against a 
`value` which is also a list of strings, and returns True iff every 
argument is in `value`. But look closer. Those tests actually check 
matching against str(values), which is the literal string "['aes', 
'mmx', 'aux']". This is also a valid Python collection, to which the 
Python `in` operator applies just fine, so what these tests actually 
check is if every argument string is a *substring* of str(values). This 
means that the following test passes:


def test_extra_specs_matches_all_with_op_allin(self):
values = ['aes', 'mmx', 'aux']
self._do_extra_specs_ops_test(
value=str(values),
req=' e',
matches=True)

[Don't believe me? See https://review.openstack.org/#/c/336094]

Is this the intended behaviour? When this is called as part of a real 
scheduler filter, is the list of values stringified before matching like 
this?


Further evidence that this isn't the intended behaviour: if you remove 
all the calls to str(), then the original tests still pass, but the 
' e' (substring matching) one doesn't.


So, is  meant to be doing substring matching? Or are the tests 
in error?


Thanks!
Miles

__
OpenStack Development Mailing 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-operators] Next Ops Midcycle NYC August 25-26

[Allison Price]

Hi Edvar and Saverio, 

I wanted to bring my colleague, Erin Disney, into this thread as she will be 
one of the points of contact from the Foundation for the Ops Midcycle in New 
York. She will be able to help answer the questions around the Eventbrite 
registration and visas. 

Cheers,
Allison


Allison Price
OpenStack Marketing
alli...@openstack.org


> On Jul 7, 2016, at 11:25 AM, Edgar Magana  wrote:
> 
> Folks,
> Do we have an eventbrite already set up?
> 
> Thanks,
> 
> Edgar
> 
> On 6/23/16, 1:14 PM, "Saverio Proto"  wrote:
> 
> Hello there :)
> 
> is anyone from the openstack foundation or from bloomberg that can
> help out with this ?
> 
> I share this for anyone that needs visa.
> 
> for Austin we had something like this:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_summit_austin-2D2016_austin-2Dand-2Dtravel_=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=wf9aH1oLv0jEU-Xw0tQijtKexSOVHWxi6gfy8iZn36g=
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_visa-5Fform-5Faustin-5Fsummit=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=n4Mtj1sOz0froNvkbC4f-w7qd-lF26MJ1aFZWtSi_f8=
>  
> 
> anyone that needs to apply for Visa will need a 'US point of contact
> information'.
> 
> Basically, if the organizer of the Ops Midcycle is officially the
> openstack foundation or bloomberg, I need to enter in my visa
> application the following info:
> 
> Organization name
> Address in the US
> Phone number
> Email
> 
> It must be a phone number and a email where in case there is a check,
> somebody can tell "yes of course, this guy exist and is coming to the
> conference" :)
> 
> How we sort this out ?
> 
> thank you
> 
> Saverio
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=hJ_UMzKTYvPT5NCIcRrq6bc1D7JZx9FZl9nzLqla8SM=
>  
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-announce] [new][telemetry] ceilometer 5.0.4 release (liberty)

[no-reply]

We are stoked to announce the release of:

ceilometer 5.0.4: OpenStack Telemetry

This release is part of the liberty stable release series.

For more details, please see below.

Changes in ceilometer 5.0.3..5.0.4
--

3ce27ce Updated from global requirements
7cdc7aa Remove oslo_utils.timeutils.total_seconds() usage + catch 
DriverLoadFailure for get_transport optional + fix CI failure due to 
oslo.messaging 5.0.0 + correct concurrency of gabbi
fe66169 Fix concurrency issue with snmp pollsters
7dbaf4c do not configure worker specific items in init


Diffstat (except docs and test files)
-

.testr.conf|  2 +-
ceilometer/alarm/evaluator/__init__.py |  2 +-
ceilometer/hardware/inspector/snmp.py  | 18 +++
ceilometer/messaging.py|  5 +--
ceilometer/notification.py | 19 +--
requirements.txt   |  2 +-
test-requirements.txt  |  2 +-
9 files changed, 58 insertions(+), 60 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 18f6449..09dc9ee 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -34 +34 @@ python-glanceclient>=0.18.0
-python-keystoneclient!=1.8.0,>=1.6.0
+python-keystoneclient!=1.8.0,<3.0.0,>=1.6.0
diff --git a/test-requirements.txt b/test-requirements.txt
index a34286f..b2e84ad 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +7 @@ hacking<0.11,>=0.10.0
-Babel>=1.3
+Babel!=2.3.0,!=2.3.1,!=2.3.2,!=2.3.3,>=1.3 # BSD



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-dev] [new][oslo] oslo.utils 3.15.0 release (newton)

[no-reply]

We are delighted to announce the release of:

oslo.utils 3.15.0: Oslo Utility library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.utils

With package available at:

https://pypi.python.org/pypi/oslo.utils

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.utils

For more details, please see below.

Changes in oslo.utils 3.14.0..3.15.0


53e70e8 Add basic docstrings to stopwatch has_started/stopped methods
893ac87 Make mask_dict_password consistent with mask_password
5b8de1c Updated from global requirements
e1ec546 improve tests for mask_password and mask_dict_password
17c2e2c Simplify boolean expression in executils.py


Diffstat (except docs and test files)
-

oslo_utils/excutils.py|  1 -
oslo_utils/strutils.py| 21 ++
oslo_utils/timeutils.py   |  2 +
test-requirements.txt |  2 +-
5 files changed, 62 insertions(+), 51 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index b9e4d03..6562796 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -21 +21 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
OpenStack Development Mailing 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-operators] Next Ops Midcycle NYC August 25-26

[Edgar Magana]

Folks,
Do we have an eventbrite already set up?

Thanks,

Edgar

On 6/23/16, 1:14 PM, "Saverio Proto"  wrote:

Hello there :)

is anyone from the openstack foundation or from bloomberg that can
help out with this ?

I share this for anyone that needs visa.

for Austin we had something like this:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_summit_austin-2D2016_austin-2Dand-2Dtravel_=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=wf9aH1oLv0jEU-Xw0tQijtKexSOVHWxi6gfy8iZn36g=
 
https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_visa-5Fform-5Faustin-5Fsummit=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=n4Mtj1sOz0froNvkbC4f-w7qd-lF26MJ1aFZWtSi_f8=
 

anyone that needs to apply for Visa will need a 'US point of contact
information'.

Basically, if the organizer of the Ops Midcycle is officially the
openstack foundation or bloomberg, I need to enter in my visa
application the following info:

Organization name
Address in the US
Phone number
Email

It must be a phone number and a email where in case there is a check,
somebody can tell "yes of course, this guy exist and is coming to the
conference" :)

How we sort this out ?

thank you

Saverio

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=hJ_UMzKTYvPT5NCIcRrq6bc1D7JZx9FZl9nzLqla8SM=
 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [User-committee] Seeking feedback: Active User Contributor (AUC) eligibility requirements

[Edgar Magana]

Good to have this question clarified.

Thanks,

Edgar

On 7/6/16, 3:18 PM, "Shamail"  wrote:



> On Jul 6, 2016, at 5:44 PM, Lauren Sell  wrote:
> 
> Hi Rocky,
> 
> Agreed! I think that’s the intent of the first bullet — official user group 
> organizers.

Completely agree, they are a vital part of the community and often are the 
first aspect of community that newcomers experience.  The first bullet is 
intended to ensure they are included in AUC.
> 
> Cheers,
> Lauren
> 
> 
>> On Jul 6, 2016, at 4:42 PM, Rochelle Grober  
>> wrote:
>> 
>> Umm, I see a major contribution area not included here:
>> 
>> OpenStack community meetup organizers.  I know some sink a large amount of 
>> time scheduling and organizing at least one a month, some two or more.  
>> These organizers are critical for getting info out on OpenStack and 
>> familiarizing their local tech communities with the OpenStack project.  I 
>> hope they are included somewhere for their contributions.
>> 
>> --Rocky
>> 
>> -Original Message-
>> From: Jonathan D. Proulx [mailto:j...@csail.mit.edu] 
>> Sent: Thursday, June 30, 2016 12:00 PM
>> To: Shamail Tahir
>> Cc: openstack-operators; user-committee
>> Subject: Re: [User-committee] Seeking feedback: Active User Contributor 
>> (AUC) eligibility requirements
>> 
>> 
>> I'm surprised this hasn't generated more feed back, though I'd
>> generally take that as positive.
>> 
>> List seems good to me.
>> 
>> The self nomintaion + confirm by UC is a good catch all especially in
>> the beginning where we're unlikely to have though of everything.  We
>> can always expand criterial later if the 'misc' of UC confirmantion
>> gets too big and we idnetify patterns.
>> 
>> Thanks all!
>> -Jon
>> 
>> On Wed, Jun 29, 2016 at 04:52:00PM -0400, Shamail Tahir wrote:
>> :Hi everyone,
>> :
>> :The AUC Recognition WG has been hard at work on milestone-4 of our plan
>> :which is to identify the eligibility criteria for each community
>> :contributor role that is covered by AUC.  We had a great mix of community
>> :people involved in defining these thresholds but we wanted to also open
>> :this up for broader community feedback before we propose them to the user
>> :committee.  AUC is a new concept and we hope to make iterative improvements
>> :going forward... you can consider the guidelines below as "version 1" and I
>> :am certain they will evolve as lessons are learned.  Thank you in advance
>> :for your feedback!
>> :
>> :*  Official User Group organizers
>> :
>> :o   Listed as an organizer or coordinator for an official OpenStack user
>> :group
>> :
>> :*  Active members of official UC Working Groups
>> :
>> :o   Attend 25% of the IRC meetings and have spoken more than 25 times OR
>> :have spoken more than 100 times regardless of attendance count over the
>> :last six months
>> :
>> :o   WG that do not use IRC for their meetings will depend on the meeting
>> :chair(s) to identify active participation from attendees
>> :
>> :*  Ops meetup moderators
>> :
>> :o   Moderate a session at the operators meetup over the last six
>> :months AND/OR
>> :
>> :o   Host the operators meetup (limit 2 people from the hosting
>> :organization) over the last six months
>> :
>> :*  Contributions to any repository under UC governance (ops
>> :repositories, user stories repository, etc.)
>> :
>> :o   Submitted two or more patches to a UC governed repository over the last
>> :six months
>> :
>> :*  Track chairs for OpenStack Summits
>> :
>> :o   Identified track chair for the upcoming OpenStack Summit (based on when
>> :data is gathered) [this is a forward-facing metric]
>> :
>> :*  Contributors to Superuser (articles, interviews, user stories, etc.)
>> :
>> :o   Listed as author in at least one publication at superuser.openstack.org
>> :over the last six months
>> :
>> :*  Submission for eligibility to AUC review panel
>> :
>> :o   No formal criteria, anyone can self-nominate, and nominations will be
>> :reviewed per guidance established in milestone-5
>> :
>> :*  Active moderators on ask.openstack
>> :
>> :o   Listed as moderator on Ask OpenStack and have over 500 karma
>> :
>> :There is additional information available in the etherpad[1] the AUC
>> :recognition WG has been using for this task which includes Q (question
>> :and answers) between team members.
>> :
>> :[1] 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_uc-2Drecog-2Dmetrics=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=ZbPal3xjxf0I-b_QC_8XFdbxXZUh_zhIsLLYtzKCXwo=pqinxE_krEV6hmTIfhRgij1cbObysnydk1yrx5A10Ig=
>>  
>> :
>> :-- 
>> :Thanks,
>> :Shamail Tahir
>> :t: @ShamailXD
>> :tz: Eastern Time
>> 
>> :___
>> :User-committee mailing list
>> :user-commit...@lists.openstack.org
>> 

Re: [openstack-dev] Manila TripleO Mitaka

[Marios Andreou]

On 07/07/16 14:25, Charles Short wrote:
> Hi,
Hi Charles,

> 
> I am deploying TripleO Mitaka stable and want to include the NetApp
> Manila driver referenced here -
> 
> http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/deploy_manila.html
> 
>

thanks for pointing those docs out - to be honest I don't know why we
landed those since the manila integration itself is still in progress. I
went looking for the gerrit review but gave up - found the commit at
https://github.com/openstack/tripleo-docs/commit/01ee4f59356b7d7df572d021931a4c7fa1e07cd9
... in any case I think we need to mark these WIP and I'm doing that at
https://review.openstack.org/339109


> I cannot see either templates available in the Undercloud.
> 
> Digging a bit it looks like there are some hurdles to overcome -
> 
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/096126.html
> 
> Does anyone have an update on progress, especially for the NetApp driver?


Currently I am aware of three reviews related to Manila. One is the
'main' patch to land manila-generic backend and the other two are for
netap and gluster integration respectively.

https://review.openstack.org/#/c/188137/ “Enable Manila integration
- as a composable controller service”

https://review.openstack.org/#/c/188138/ “Add integration with
NetApp Manila driver”

https://review.openstack.org/#/c/230936/ “Add Gluster integration to
Manila”


The Manila integration as a composable service needs to land first. The
Netapp and Gluster reviews I've not had any involvement in at all; they
will also need to tlc to get landed, but they both depend on the 'main'
manila integration patch.


Hope that helps clarify the situation somewhat,

thanks, marios



> 
> Many thanks
> 
> Charles
> 


__
OpenStack Development Mailing 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] [security] [horizon] Security implications of exposing a keystone token to a JS client

[Fox, Kevin M]

Ok. Thanks for taking a look.

Kevin

From: David Stanek [dsta...@dstanek.com]
Sent: Wednesday, July 06, 2016 5:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [security] [horizon] Security implications of 
exposing a keystone token to a JS client

On 07/01 at 19:41, Fox, Kevin M wrote:
> Hi David,
>
> How do you feel about the approach here:
> https://review.openstack.org/#/c/311189/
>
> Its lets the existing angular js module:
> horizon.app.core.openstack-service-api.keystone
>
> access the current token via getCurrentUserSession().token
>

Hey Kevin,

It's hard to tell without a lot of the context. From what I can tell the
token is pulled down as part of the data of an API request. As long as
that's not cached I think you are OK.

--
David Stanek
web: http://dstanek.com
blog: http://traceback.org

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

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

Re: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

[Tripp, Travis S]

By caching, do you mean not persisting it in local storage or a cookie?  Would 
it be okay to store in a variable in browser memory for the duration of the 
session to be used with subsequent API requests?

Thanks,
Travis

On 7/6/16, 6:36 PM, "David Stanek"  wrote:

On 07/01 at 19:41, Fox, Kevin M wrote:
> Hi David,
> 
> How do you feel about the approach here:
> https://review.openstack.org/#/c/311189/
> 
> Its lets the existing angular js module:
> horizon.app.core.openstack-service-api.keystone
> 
> access the current token via getCurrentUserSession().token
> 

Hey Kevin,

It's hard to tell without a lot of the context. From what I can tell the
token is pulled down as part of the data of an API request. As long as
that's not cached I think you are OK.

-- 
David Stanek
web: http://dstanek.com
blog: http://traceback.org

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


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

Re: [Openstack-operators] How to create floating ip pool use nova network? thanks

[Joe Topjian]

In Kilo (I haven't verified Liberty or Mitaka), you can manage nova-network
floating IP pools with:

nova-manage floating --help
nova-manage floating create --help

Hope that helps!
Joe


On Wed, Jul 6, 2016 at 8:23 PM, 云淡风轻 <821696...@qq.com> wrote:

> hi everyone,
>
> How to create floating ip pool use nova network? thanks
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Enable IPv6 for exsisting Kilo environment

[suresh kumar]

Hi All,

I want to enable IPv6 for existing kilo environment I have neutron
configured with provider network (neutron with tunneling segmentation).

1) Please let me know what configuration changes need to be done on neutron
and compute nodes.
2) Is it possible to create ipv6 vxlan on ipv4 tunnel?
3) how to modify images to support ipv4/ipv6 dual stack


Thanks,
Suresh
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [designate] Mid Cycle Dates - 22-26th August in Dublin, Ireland

[Hayes, Graham]

At the IRC meeting yesterday we (finally) got some dates
in place for the Mid Cycle.

22-26th August in Dublin, Ireland.

Final location to be confirmed - this mid cycle is not being sponsored
by anyone, so I need rough numbers before I go beg, borrow and / or
steal a room, but it will be the city centre (Dublin 1 or 2).

Can everyone let me know if this is OK, and if they would be interested
in attending?

If no one shouts at me by Monday, I will start booking a room, for 8
to 10 people, which should give us a little room for expansion, but not
too much, so if you are interested, please let me know.

Thanks!

Graham

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

Re: [openstack-dev] [tc] Leadership training recap & steps forward

[Amrith Kumar]

There is a new OpenStack channel, #openstack-swg (SWG stands for Stewardship 
Working Group). For more details, please see the draft resolution for the 
TC[1]. A proposal has also been made for group meeting time[2]. Please provide 
input there if you wish to participate.

Thanks,

-amrith

[1] https://review.openstack.org/#/c/337895/
[2] https://review.openstack.org/#/c/338134/

> -Original Message-
> From: Alexis Monville [mailto:amonv...@redhat.com]
> Sent: Thursday, July 07, 2016 7:20 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [tc] Leadership training recap & steps
> forward
> 
> That's great news!
> Congrats to Colette for the organization and to the people who dare to
> join the training!
> 
> On Wed, Jul 6, 2016 at 6:45 PM, Amrith Kumar  wrote:
> > A huge "THANK YOU" to Colette for all the time and effort that went into
> making this a reality. What she doesn't mention is that this training
> (which lasted just a couple of days) was a year in the making!
> >
> > In addition to the great sandwiches and BBQ (and beer), I think it was
> great to have so many of us in a room at once. There is something about
> meeting in person, breaking bread (and jokes) that is totally lost in a
> virtual environment.
> >
> > I think the training and the discussions were well worth it and I
> encourage anyone who is serious about leadership in OpenStack to consider
> attending the next session. And while you are there, make it a point to go
> to Maker Works and meet Tom Root. It is truly inspiring to see what he's
> doing there.
> >
> > -amrith
> >
> >> -Original Message-
> >> From: Colette Alexander [mailto:colettealexan...@gmail.com]
> >> Sent: Wednesday, July 06, 2016 12:05 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: [openstack-dev] [tc] Leadership training recap & steps forward
> >>
> >> Hello Stackers!
> >>
> >> I wanted to send an update about what happened last week at the
> >> leadership training session in Ann Arbor, Michigan and some of the
> >> things moving out of the training that we're hoping help improve the
> >> community as a whole.
> >>
> >> 17 people from the community (including 8 from the TC) and 2 trainers
> >> from ZingTrain spent 2 days covering a range of materials and
> >> subjects: servant leadership! Visioning! Stages of learning! Good
> >> practices for leading organizational change! Also there were delicious
> >> sandwiches and BBQ.
> >>
> >> Reviews and reflections from the training have been overwhelmingly
> >> positive, and some blog posts about it are starting to pop up.[0]
> >>
> >> On the day after training, a slightly smaller group than the full 17
> >> met to discuss how some of the ideas presented might help the
> >> OpenStack community, and identified some areas of work that are now
> >> being initiated by the TC. Some of the work identified involves the TC
> >> examining and where necessary, altering the ways it works, and some of
> >> it involves a general support for and development of leadership in all
> >> areas of the OpenStack community. To more clearly define and
> >> accomplish that work, a Stewardship Working Group has been
> >> proposed.[1]
> >>
> >> Because of the success of the training, and the fact that 5 TC members
> >> weren't able to attend this past instance, I'm working to arrange a
> >> repeated offering. It's still very much in the planning stages, but
> >> I'm hoping it will be in September, and follow the same 2-day
> >> training/1 day reflection/planning structure as before. The training
> >> will be enrolled similarly to the last one - with TC and Board members
> >> having first crack at the sign up list, and then opening remaining
> >> seats to the rest of the community. I will post to the -dev list as
> >> dates and details are finalized for that.
> >>
> >> Ideally there will be some discussion and work on this (including a
> >> potential panel discussion) at the Ocata Summit in Barcelona as well -
> >> stay tuned for information on that as it becomes available!
> >>
> >> A huge thanks to all who attended, and to the Foundation who sponsored
> >> the training for everyone - I'm incredibly excited to work on all of
> >> this in such a great environment, with such great people.
> >>
> >> Sincerely,
> >>
> >> -colette/gothicmindfood
> >>
> >> [0] http://www.tesora.com/openstack-tc-will-not-opening-deli/
> >> [1] https://review.openstack.org/#/c/337895/
> >>
> >>
> __
> >> OpenStack Development Mailing 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-operators] PCI Passthrough issues

[Jonathan Proulx]

On Thu, Jul 07, 2016 at 11:13:29AM +1000, Blair Bethwaite wrote:
:Jon,
:
:Awesome, thanks for sharing. We've just run into an issue with SRIOV
:VF passthrough that sounds like it might be the same problem (device
:disappearing after a reboot), but haven't yet investigated deeply -
:this will help with somewhere to start!

:By the way, the nouveau mention was because we had missed it on some
:K80 hypervisors recently and seen passthrough apparently work, but
:then the NVIDIA drivers would not build in the guest as they claimed
:they could not find a supported device (despite the GPU being visible
:on the PCI bus). 

Definitely sage advice! 

:I have also heard passing mention of requiring qemu
:2.3+ but don't have any specific details of the related issue.

I didn't do a bisection but with qemu 2.2 (from ubuntu cloudarchive
kilo) I was sad and with 2.5 (from ubuntu cloudarchive mitaka but
installed on a kilo hypervisor) I am working.

Thanks,
-Jon


:Cheers,
:
:On 7 July 2016 at 08:13, Jonathan Proulx  wrote:
:> On Wed, Jul 06, 2016 at 12:32:26PM -0400, Jonathan D. Proulx wrote:
:> :
:> :I do have an odd remaining issue where I can run cuda jobs in the vm
:> :but snapshots fail and after pause (for snapshotting) the pci device
:> :can't be reattached (which is where i think it deletes the snapshot
:> :it took).  Got same issue with 3.16 and 4.4 kernels.
:> :
:> :Not very well categorized yet, but I'm hoping it's because the VM I
:> :was hacking on had it's libvirt.xml written out with the older qemu
:> :maybe?  It had been through a couple reboots of the physical system
:> :though.
:> :
:> :Currently building a fresh instance and bashing more keys...
:>
:> After an ugly bout of bashing I've solve my failing snapshot issue
:> which I'll post here in hopes of saving someonelse
:>
:> Short version:
:>
:> add "/dev/vfio/vfio rw," to  /etc/apparmor.d/abstractions/libvirt-qemu
:> add "ulimit -l unlimited" to /etc/init/libvirt-bin.conf
:>
:> Longer version:
:>
:> What was happening.
:>
:> * send snapshot request
:> * instance pauses while snapshot is pending
:> * instance attempt to resume
:> * fails to reattach pci device
:>   * nova-compute.log
:> Exception during message handling: internal error: unable to execute 
QEMU command 'device_add': Device initialization failedcompute.log
:>
:>   * qemu/.log
:> vfio: failed to open /dev/vfio/vfio: Permission denied
:> vfio: failed to setup container for group 48
:> vfio: failed to get group 48
:> * snapshot disappears
:> * instance resumes but without passed through device (hard reboot
:> reattaches)
:>
:> seeing permsission denied I though would be an easy fix but:
:>
:> # ls -l /dev/vfio/vfio
:> crw-rw-rw- 1 root root 10, 196 Jul  6 14:05 /dev/vfio/vfio
:>
:> so I'm guessing I'm in apparmor hell, I try adding "/dev/vfio/vfio
:> rw," to  /etc/apparmor.d/abstractions/libvirt-qemu rebooting the
:> hypervisor and trying again which gets me a different libvirt error
:> set:
:>
:> VFIO_MAP_DMA: -12
:> vfio_dma_map(0x5633a5fa69b0, 0x0, 0xa, 0x7f4e7be0) = -12 (Cannot 
allocate memory)
:>
:> kern.log (and thus dmesg) showing:
:> vfio_pin_pages: RLIMIT_MEMLOCK (65536) exceeded
:>
:> Getting rid of this one required inserting 'ulimit -l unlimited' into
:> /etc/init/libvirt-bin.conf in the 'script' section:
:>
:> 
:> script
:> [ -r /etc/default/libvirt-bin ] && . /etc/default/libvirt-bin
:> ulimit -l unlimited
:> exec /usr/sbin/libvirtd $libvirtd_opts
:> end script
:>
:>
:> -Jon
:>
:> ___
:> OpenStack-operators mailing list
:> OpenStack-operators@lists.openstack.org
:> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
:
:
:
:-- 
:Cheers,
:~Blairo

-- 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [telecom-nfv] New IRC channel - #opnfv-openstack

[Curtis]

On Thu, Jul 7, 2016 at 2:13 AM, Ulrich Kleber  wrote:
> Hi,
> we have setup an own IRC channel to discuss collaboration with OpenStack from 
> OPNFV side. Please join.

Thanks Uli, I will try to hang out in that channel. :)

Thanks,
Curtis.

> Cheers,
> Uli
>
>
> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org 
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Dave Neary
> Sent: Wednesday, 06 July, 2016 15:57
> To: opnfv-tech-disc...@lists.opnfv.org; Csatari, Gergely (Nokia - HU/Budapest)
> Subject: [opnfv-tech-discuss] New IRC channel - #opnfv-openstack
>
> Hi,
>
> Gergely Csatari (who plays for OPNFV ;-) ) just started a new IRC channel on 
> Freenode called #opnfv-openstack, with the goal of having a place for OPNFV 
> people who are engaged in OpenStack (and OpenStack people interested in NFV) 
> can meet, and perhaps help out other people who are navigating the minefield.
>
> It's new, so currently not much is happening there, but it's intended to be a 
> place where you can get feedback on blueprints, hgand-holding through getting 
> signed up for various infra, working through community processes, getting 
> help on how to identify and find key people in the OpenStack projects you 
> care about, etc.
>
> Come along and join! One more channel for the auto-join list.
>
> Thanks,
> Dave.
>
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338 
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-disc...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Blog: serverascode.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Getting help with Python API

[Jared Wilkinson]

Thanks. I finally figured it out with the help of someone with a bit more 
Python knowledge than I have. I wasn’t able to figure out that the list was a 
list of arrays on my own. I would try to get the type for each one of the items 
in the list (which was the list of tenants, ids, etc), but it would return that 
it was  ‘’ and I didn’t know what 
to do with that since I expected something like  since that’s what 
it looked like when I just printed the line. After he pointed me to the fact it 
was an array (still not sure how to determine that other than just recognizing 
the output), I was able to pull the id just as you referenced.

Now on to figure out the new python-openstackclient API so I can use that 
instead!

Jared Wilkinson | Senior Infrastructure Engineer – Team Lead
jwilkin...@ebsco.com | (W) 205/981-4018 | (M) 205/259-9802
5724 US Highway 280 East, Birmingham, AL 35242, USA

From:  on behalf of Matt Fischer 
Date: Wednesday, July 6, 2016 at 9:04 PM
To: Jared Wilkinson 
Cc: "openstack-operators@lists.openstack.org" 

Subject: Re: [Openstack-operators] Getting help with Python API

When you make the API calls you're going to get back a list python objects 
which you need to iterate. I believe some APIs will let you ask for specific 
fields only, but this is simple enough:

keystone = client.Client(username=Username, password=Password, 
tenant_name=Tenant,
auth_url='http://%s:5000/v2.0' % (Ip))
tenants = keystone.tenants.list()
tenant_ids = []
for tenant in tenants:
tenant_ids.append(tenant.id)

Then you can process the tenant_ids list, of course once you done that you've 
lost the context of the object (like the name of the tenant).

For stuff like this the docs are your best bet along with introspecting the 
objects using the interactive python shell:

http://docs.openstack.org/developer/python-keystoneclient/

On Wed, Jul 6, 2016 at 12:53 PM, Jared Wilkinson 
> wrote:
Hey folks,

I am in the process of teaching myself Python and I have done a couple of free 
online courses but still have a fairly rudimentary understanding of Python, 
especially when it comes to using the OpenStack SDK. I was hoping you guys 
could point me to a mailing list for getting help with using the Python API 
calls in custom scripts. Specifically, something as simple as, return a list of 
all the tenant IDs (only) and push that send that to nova quota show and return 
just the CPU, memory, and storage metrics.

I can get the list of tenants from Keystone, but I can’t get it to just send me 
the list of IDs (we are using v2 of identity). I have read the documentation, 
but nothing there seems to help (or I am not quite strong enough in my Python 
skills to understand it) for this specific instance.

Any direction would be appreciated.

Thanks,
Jared

Jared Wilkinson | Senior Infrastructure Engineer – Team Lead
jwilkin...@ebsco.com | (W) 
205/981-4018 | (M) 205/259-9802
5724 US Highway 280 East, Birmingham, AL 35242, USA

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [fuel] Weekly meeting for July 7

[Andrew Woodward]

There is no agenda on the meeting again this week so I am calling it
canceled.

Thanks
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing 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] Juju Charm Usability/Functionality Enhancements

[James Page]

Hi James

On Wed, 6 Jul 2016 at 18:52 James Beedy  wrote:

> I've a few things I want to bring up concerning usability/functionality in
> nova-cloud-controller and openstack-dashboard.
>
> 1. Request-timeout configurability for openstack-dashboard.
> - Everyone who accesses horizon asks me for this. I think it would be
> smart to set the timeout to the keystone token session timeout value.
> - I've filed a feature request/bug, and proposed a merge for this in
> the past, to no avail. This is a must for usability, and so simple to add.
> What gives?
>

visibility of merges across a large number of charms in launchpad was never
good so things did get missed; I've had a dig but can't find either a bug
or a merge against the old launchpad bzr branches; this sounds like a
useful feature - it would be helpful if you could raise a bug and then we
can workout how that fits into the next 3 months of charm delivery.


> 2. 'cross_az_attach=True'
> - Without "cross_az_attach=True" under the cinder context in
> nova.conf, live migration across availability_zones, alongside a handful of
> other critical ops fail.
> - This is a critical config param, the absence of which has blocked me
> on multiple levels for a long time now.
> - I've previously filed a bug/feature request for this, and also have
> proposed a merge that adds this functionality.
> - This is critical. ATTN HERE ASAP, PLEASE!
>

Already on my list to review this bug:


https://bugs.launchpad.net/charms/+source/nova-cloud-controller/+bug/1599289

again I can't find a merge on Launchpad (see [1]) but we'll see if we can
fit this into the next 7 days of dev prior to the feature freeze for the
16.07 charm release at the end of the month.

Cheers

James

[1]
https://code.launchpad.net/~openstack-charmers-archive/charms/trusty/nova-cloud-controller/next/+merges
__
OpenStack Development Mailing 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] [freezer] Freezer Midcycle Meetup

[Mathieu, Pierre-Arthur]

Hi,

The Freezer team is excited to announce that we're hosting our Newton midcycle
meetup on 15th of July, 2016.
The event is free and will happen in Galway, Ireland and be hosted by Hewlett 
Packard Enterprise.
We are planning for some virtual attendance as well.

Logistic is being managed here: [1]

Feel free to ask any question in this thread or in #openstack-freezer.

We hope to see you there,
Best Wishes,
- Pierre

[1] https://etherpad.openstack.org/p/freezer_midcycle_meetup_newton

__
OpenStack Development Mailing 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] Failed to install fuel master

[Stanislaw Bogatkin]

I believe it is a problem root. We put kickstart file as a kernel parameter
and custom usb creators sometimes do not take it to consideration. Use
plain diskdump for copy ISO onto usb stick and all should work properly in
this case. You can find more details in official documentation for Fuel 8.0
[0].

[0]
https://docs.mirantis.com/openstack/fuel/fuel-8.0/fuel-install-guide.html#install-prepare-install-media

On Thu, Jul 7, 2016 at 12:53 PM, Alioune  wrote:

> Hi guys,
> I'm using Fuel-8.0  iso, I used "Lili USB Creator" to write ISO to the
> USB.
> (I tried this process for ubuntu-server.iso and it worked correctly).
>
> Regards,
>
> On 7 July 2016 at 09:54, Stanislaw Bogatkin 
> wrote:
>
>> Hi guys,
>>
>> could you tell which way you used to write ISO to the USB stick?
>>
>> On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan 
>> wrote:
>>
>>> I'm pretty sure this is a USB stick install as I've seen the same
>>> failure on Fuel-8.0. Basically, the installer is not able to find the
>>> mounted drive to run the kickstart file. Duel layer DVD media or a virtual
>>> Fuel master are the only ways I've gotten Fuel-8.0 to install.
>>>
>>> On 07/05/2016 05:22 AM, Vladimir Kuklin wrote:
>>>
>>> Hi, Alioune
>>>
>>> Let's start with the most basic steps. Which Fuel are you using?
>>> And how do you install the node? Do you use USB stick or DVD or some
>>> IPMI virtual media? From what I see here it pretty much looks like, that
>>> this media is not inserted into the host.
>>>
>>> On Tue, Jul 5, 2016 at 3:11 PM, Alioune  wrote:
>>>
 Hi all,

 I'm trying to install fuel master using [1] on phycal server but the
 installation process fails and switches to a dracut console with the
 following error:

 dracut-initqueue[595] floppy0: no floppy controllers found
 dracut-initqueue[595] Warning: failed to fetck kickstart from
 hd:sr0:/ks.cfg
 dracut-initqueue[595] mount: no medium found on /dev/sr0
 dracut-initqueue[595] Warning: Cloud not boot
 dracut-initqueue[595] Warning: /dev/root does not exist


 Starting Dracut Emergency Shell
 Warning: /dev/root does not exist
 Generating "/run/initramfs/rdsosreport.txt"
 dracut:/#

 Any suggestion for solving that error ?

 Regards,

 [1]
 http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html


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


>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> --
>>> Jack Morgan
>>> OPNFV Pharos Intel Lab
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> with best regards,
>> Stan.
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Stability and reliability of gate jobs

[Steven Dake (stdake)]

On 7/6/16, 5:50 PM, "Paul Belanger"  wrote:

>On Thu, Jun 16, 2016 at 12:20:06PM +, Steven Dake (stdake) wrote:
>> David,
>> 
>> The gates are unreliable for a variety of reasons - some we can fix -
>>some
>> we can't directly.
>> 
>> RDO rabbitmq introduced IPv6 support to erlang, which caused our gate
>> reliably to drop dramatically.  Prior to this change, our gate was
>>running
>> 95% reliability or better - assuming the code wasn¹t busted.
>> The gate gear is different - meaning different setup.  We have been
>> working on debugging all these various gate provider issues with infra
>> team and I think that is mostly concluded.
>> The gate changed to something called bindeps which has been less
>>reliable
>> for us.
>
>I would be curious to hear your issues with bindep. A quick look at kolla
>show
>you are not using other-requirements.txt yet, so you are using our default
>fallback.txt file. I am unsure how that could be impacting you.
>
>> We do not have mirrors of CentOS repos - although it is in the works.
>> Mirrors will ensure that images always get built.  At the moment many of
>> the gate failures are triggered by build failures (the mirrors are too
>> busy).
>
>This is no longer the case, openstack-infra is now mirroring both
>centos-7[1]
>and epel-7[2]. And just this week we brought Ubuntu Cloud Archive[3]
>online. It
>would be pretty trivial to update kolla to start using them.
>
>[1] http://mirror.dfw.rax.openstack.org/centos/7/
>[2] http://mirror.dfw.rax.openstack.org/epel/7/
>[3] http://mirror.dfw.rax.openstack.org/ubuntu-cloud-archive/

Thanks I was aware that infra made mirrors available; I have not had a
chance to personally modify the gate to make use of these mirrors.

I am not sure if there is an issue with bindep or not.  A whole lot of
things changed at once and our gate went from pretty stable to super
unstable.  One of those things was bindeps but there were a bunch of other
changes.  I wouldn't pin it all on binddep.
 
>
>> We do not have mirrors of the other 5-10 repos and files we use.  This
>> causes more build failures.
>> 
>We do have the infrastructure in AFS to do this, it would require you to
>write
>the patch and submit it to openstack-infra so we can bring it online.  In
>fact,
>the OpenStack Ansible team was responsible for UCA mirror above, I simply
>did
>the last 5% to bring it into production.

Wow that’s huge!  I was not aware of this.  Do you have an example patch
which brings a mirror into service??

Thanks
-steve

>
>> Complicating matters, any of theses 5 things above can crater one gate
>>job
>> of which we run about 15 jobs, which causes the entire gate to fail (if
>> they were voting).  I really want a voting gate for kolla's jobs.  I
>>super
>> want it.  The reason we can't make the gates voting at this time is
>> because of the sheer unreliability of the gate.
>> 
>> If anyone is up for a thorough analysis of *why* the gates are failing,
>> that would help us fix them.
>> 
>> Regards
>> -steve
>> 
>> On 6/15/16, 3:27 AM, "Paul Bourke"  wrote:
>> 
>> >Hi David,
>> >
>> >I agree with this completely. Gates continue to be a problem for Kolla,
>> >reasons why have been discussed in the past but at least for me it's
>>not
>> >clear what the key issues are.
>> >
>> >I've added this item to agenda for todays IRC meeting (16:00 UTC -
>> >https://wiki.openstack.org/wiki/Meetings/Kolla). It may help if before
>> >hand we can brainstorm a list of the most common problems here
>>beforehand.
>> >
>> >To kick things off, rabbitmq seems to cause a disproportionate amount
>>of
>> >issues, and the problems are difficult to diagnose, particularly when
>> >the only way to debug is to summit "DO NOT MERGE" patch sets over and
>> >over. Here's an example of a failed centos binary gate from a simple
>> >patch set I was reviewing this morning:
>> 
>>>http://logs.openstack.org/06/329506/1/check/gate-kolla-dsvm-deploy-cento
>>>s-
>> >binary/3486d03/console.html#_2016-06-14_15_36_19_425413
>> >
>> >Cheers,
>> >-Paul
>> >
>> >On 15/06/16 04:26, David Moreau Simard wrote:
>> >> Hi Kolla o/
>> >>
>> >> I'm writing to you because I'm concerned.
>> >>
>> >> In case you didn't already know, the RDO community collaborates with
>> >> upstream deployment and installation projects to test it's packaging.
>> >>
>> >> This relationship is beneficial in a lot of ways for both parties, in
>> >>summary:
>> >> - RDO has improved test coverage (because it's otherwise hard to test
>> >> different ways of installing, configuring and deploying OpenStack by
>> >> ourselves)
>> >> - The RDO community works with upstream projects (deployment or core
>> >> projects) to fix issues that we find
>> >> - In return, the collaborating deployment project can feel more
>> >> confident that the RDO packages it consumes have already been tested
>> >> using it's platform and should work
>> >>
>> >> To make a long story short, we do this with a project called 

Re: [openstack-dev] [stable][liberty] [cinder] is stable liberty broken?

[Eric Harney]

On 07/07/2016 02:41 AM, Chen CH Ji wrote:
> Hi,
>I am backporting https://review.openstack.org/#/c/333749/ 
> 
>to stable/liberty and failed in gating job, then I submitted 
> another 
> doc change https://review.openstack.org/#/c/338699/  to verify and seems 
> failed 
> with same reason and I have no idea what's wrong in test... can someone help 
> to 
> take a look or give some hint?
> error is :
> 
>  
> ft17.1: 
> cinder.tests.unit.api.contrib.test_quotas.QuotaSetsControllerTest.test_delete_StringException:
>  Empty attachments:
>pythonlogging:''
>stderr
>stdout
> 
> Traceback (most recent call last):
>File "cinder/tests/unit/api/contrib/test_quotas.py", line 100, in setUp
>  self.fixture = self.useFixture(config_fixture.Config(auth_token.CONF))
> AttributeError: 'module' object has no attribute 'CONF'
> 
> 
> 

Yes, it looks like it.

I filed bug https://bugs.launchpad.net/cinder/+bug/1599855 for this.

It looks like the way we are setting keystonemiddleware options breaks
with newer keystonemiddleware releases.

keystonemiddleware 2.6.0 works here, 4.6.0 does not.

Thanks for the report.


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

Re: [openstack-dev] [openstack-ansible] existing centralized syslog server

[Jesse Pretorius]

On 7/6/16, 3:24 PM, "fabrice grelaud"  wrote:

>
>I would like to know what is the best approach to customize our 
>openstack-ansible deployment if we want to use our existing solution of ELK 
>and centralized rsyslog server.
>
>We deploy openstack-ansible (mitaka 13.1.2 release) on our infrastructure with 
>for convenient and no risk a vm for syslog server role. That is ok. But now if 
>i want to use our centralized syslog server ?
>
>What i need is to set ip address of our existing server to the rsyslog client 
>(containers + metal) and of course configure our rsyslog.conf to manage 
>openstack template.
>So:
>- no need to create on the log server a lxc container (setup-hosts.yml: 
>lxc-hosts-setup, lxc-containers-create)
>- no need to install syslog server (setup-infrastructure.yml: 
>rsyslog-install.yml)

To add more rsyslog targets for logs you can see in 
https://github.com/openstack/openstack-ansible-rsyslog_client/blob/stable/mitaka/defaults/main.yml#L56-L73
 that there is an example of the changes you need to make to 
/etc/openstack_deploy/user_variables.yml to include additional targets.

You may be able to do away with the log host altogether as you desire by simply 
leaving the ‘log_hosts’ group out of the 
/etc/openstack_deploy/openstack_user_config.yml and 
/etc/openstack_deploy/conf.d/*.yml files. This is an untested code path so you 
may find that we make assumptions about the presence of the log_host so please 
register bugs for any issues you find so that we can eradicate those 
assumptions. To my mind the log host is not required for a deployment if the 
deployer so chooses (and especially if the deployer has alternative syslog 
targets in-place).

>How can i modify my openstack-ansible environment (/etc/openstack_deploy, 
>env.d, conf.d, openstack_user_config.yml, user_variables.yml, playbook ?) the 
>most transparent manner and that permits minor release update simply ?

As long as you’re only editing things in user space (i.e. In 
/etc/openstack_deploy/) and not in-tree (i.e. In /opt/openstack-ansible/) then 
the minor upgrade process is documented here: 
http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/app-minorupgrade.html

I hope that this answers your questions!


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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-operators] [puppet] - controller with mysql and rabbitmq have problem with puppet dependencies

[Emilien Macchi]

Good feedback!
However I'm afraid this is not the right channel for Puppetlabs
modules (rabbitmq, apache, mysql, etc) discussions. Please use
puppet-dev [1] if you want to get more attraction from Puppet
community.
If you need support about Puppet OpenStack [2], this place is the good
one though!

Thanks,

[1] https://groups.google.com/forum/#!forum/puppet-dev
[2] docs.openstack.org/developer/puppet-openstack-guide/

On Thu, Jul 7, 2016 at 7:49 AM, Saverio Proto  wrote:
> So it is puppetlabs-rabbitmq 5.4.0 that created this problem.
> I rolled back to 5.3.1
>
> Here is the commit that introduces the problem:
> https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/df71b47413fa2e941850a42e82ba83d7f680529d
>
> Saverio
>
> 2016-07-07 13:18 GMT+02:00 Saverio Proto :
>> Hello,
>>
>> I have a pet server hosting both mysql and rabbitmq for openstack.
>> I guess this is common for many people running a Openstack Controller pet.
>>
>> I just figured out I have a strange problem with my puppet modules 
>> dependencies:
>>
>> puppetlabs-rabbitmq requires:
>> puppet-staging
>>
>> puppetlab-mysql requires:
>> nanliu-staging
>>
>> these 'staging' modules have a name collision, r10k will install them
>> into modules/staging/
>> so the latest one that is the Puppetfile wins.
>>
>> I know nanliu a old fork... but... which one of the two should I stick to ?
>>
>> Saverio
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Emilien Macchi

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [puppet] - controller with mysql and rabbitmq have problem with puppet dependencies

[Saverio Proto]

So it is puppetlabs-rabbitmq 5.4.0 that created this problem.
I rolled back to 5.3.1

Here is the commit that introduces the problem:
https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/df71b47413fa2e941850a42e82ba83d7f680529d

Saverio

2016-07-07 13:18 GMT+02:00 Saverio Proto :
> Hello,
>
> I have a pet server hosting both mysql and rabbitmq for openstack.
> I guess this is common for many people running a Openstack Controller pet.
>
> I just figured out I have a strange problem with my puppet modules 
> dependencies:
>
> puppetlabs-rabbitmq requires:
> puppet-staging
>
> puppetlab-mysql requires:
> nanliu-staging
>
> these 'staging' modules have a name collision, r10k will install them
> into modules/staging/
> so the latest one that is the Puppetfile wins.
>
> I know nanliu a old fork... but... which one of the two should I stick to ?
>
> Saverio

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Manila TripleO Mitaka

[Charles Short]

Hi,

I am deploying TripleO Mitaka stable and want to include the NetApp 
Manila driver referenced here -


http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/deploy_manila.html

I cannot see either templates available in the Undercloud.

Digging a bit it looks like there are some hurdles to overcome -

http://lists.openstack.org/pipermail/openstack-dev/2016-May/096126.html

Does anyone have an update on progress, especially for the NetApp driver?

Many thanks

Charles

--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205


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

[Openstack-operators] [puppet] - controller with mysql and rabbitmq have problem with puppet dependencies

[Saverio Proto]

Hello,

I have a pet server hosting both mysql and rabbitmq for openstack.
I guess this is common for many people running a Openstack Controller pet.

I just figured out I have a strange problem with my puppet modules dependencies:

puppetlabs-rabbitmq requires:
puppet-staging

puppetlab-mysql requires:
nanliu-staging

these 'staging' modules have a name collision, r10k will install them
into modules/staging/
so the latest one that is the Puppetfile wins.

I know nanliu a old fork... but... which one of the two should I stick to ?

Saverio

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Fuel] Failed to install fuel master

[Alioune]

Hi guys,
I'm using Fuel-8.0  iso, I used "Lili USB Creator" to write ISO to the USB.
(I tried this process for ubuntu-server.iso and it worked correctly).

Regards,

On 7 July 2016 at 09:54, Stanislaw Bogatkin  wrote:

> Hi guys,
>
> could you tell which way you used to write ISO to the USB stick?
>
> On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan  wrote:
>
>> I'm pretty sure this is a USB stick install as I've seen the same failure
>> on Fuel-8.0. Basically, the installer is not able to find the mounted drive
>> to run the kickstart file. Duel layer DVD media or a virtual Fuel master
>> are the only ways I've gotten Fuel-8.0 to install.
>>
>> On 07/05/2016 05:22 AM, Vladimir Kuklin wrote:
>>
>> Hi, Alioune
>>
>> Let's start with the most basic steps. Which Fuel are you using?
>> And how do you install the node? Do you use USB stick or DVD or some IPMI
>> virtual media? From what I see here it pretty much looks like, that this
>> media is not inserted into the host.
>>
>> On Tue, Jul 5, 2016 at 3:11 PM, Alioune  wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to install fuel master using [1] on phycal server but the
>>> installation process fails and switches to a dracut console with the
>>> following error:
>>>
>>> dracut-initqueue[595] floppy0: no floppy controllers found
>>> dracut-initqueue[595] Warning: failed to fetck kickstart from
>>> hd:sr0:/ks.cfg
>>> dracut-initqueue[595] mount: no medium found on /dev/sr0
>>> dracut-initqueue[595] Warning: Cloud not boot
>>> dracut-initqueue[595] Warning: /dev/root does not exist
>>>
>>>
>>> Starting Dracut Emergency Shell
>>> Warning: /dev/root does not exist
>>> Generating "/run/initramfs/rdsosreport.txt"
>>> dracut:/#
>>>
>>> Any suggestion for solving that error ?
>>>
>>> Regards,
>>>
>>> [1]
>>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>> Jack Morgan
>> OPNFV Pharos Intel Lab
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> with best regards,
> Stan.
>
> __
> OpenStack Development Mailing 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-operators] It is qcow2 or vmdk format ? to create openstack image and then auto create cluster on VMware station with windows?

[????????]

hi ,
It is qcow2 or vmdk format ? to create openstack image and then auto create 
cluster on VMware station with windows?


thanks a lot!___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [puppet] Request to add puppet-dpdk module

[Saravanan KR]

Hello,

We are working on blueprint [1] to integrate DPDK with tripleo. In the
process, we are planning to add a new puppet module "puppet-dpdk" for the
required puppet changes.

The initial version of the repository is at github [2]. Note that the
changes are
​not ​
complete yet. It is in progress.

Please let us know your views on including this new module.

Regards,
Saravanan KR
​

[1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
[2] https://github.com/krsacme/puppet-dpdk
__
OpenStack Development Mailing 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] It is impossible to queue UpdateDnsmasqTask

[Georgy Kibardin]

Continuing speaking to myself :)

Option 4 implies that we generate puppet manifest with a set of admin
networks instead of writing it into hiera. So, we get a two step task
which, first, generates manifest with unique name and, second, calls puppet
to apply it.
However, theres still a problem with this approach. When we almost
simultaneously delete environments A and B (and A goes a bit earlier)
astute acknowledges two UpdateDnsmasqTask tasks for execution, however, it
cannot guarantee that puppet for UpdateDnsmasqTask for env A will be
executed earlier than for env B. This would lead to incorrect list of admin
networks by the end of environment deletion.

So the option 4 just doesn't work.

On Wed, Jul 6, 2016 at 11:41 AM, Georgy Kibardin 
wrote:

> Bulat is suggesting to move with 4. He suggest to merge all actions of
> UpdateDnsmasqTask into one puppet task. There are three actions: syncing
> admin network list to heira, dhcp ranges update and cobbler sync. The
> problem I see with this approach is that current implementation does not
> suppose passing any additional data to "puppet apply". Cobbler sync seems
> to be a reasonable part of updating dhcp ranges config.
>
> Best,
> Georgy
>
> On Thu, Jun 16, 2016 at 7:25 PM, Georgy Kibardin 
> wrote:
>
>> Hi All,
>>
>> Currently we can only run one instance of subj. at time. An attempt to
>> run second one causes an exception. This behaviour at least may cause a
>> cluster to stuck forever in "removing" state (reproduces here
>> https://bugs.launchpad.net/fuel/+bug/1544493) or just produce
>> incomprehensible "task already running" message. So we need to address the
>> problem somehow. I see the following ways to fix it:
>>
>> 1. Just put the cluster into "error" state which would allow user to
>> remove it later.
>>   pros: simple and fixes the problem at hand (#1544493)
>>   cons: it would be hard to detect "come againg later" situation; quite a
>> lame behavior: why don't you "come again later" yourself.
>>
>> 2. Implement generic queueing in nailgun.
>> pros: quite simple
>> cons: it doesn't look like nailgun responsibility
>>
>> 3. Implement generic queueing in astute.
>>pros: this behaviour makes sense for astute.
>>cons: the implementation would be quite complex, we need to
>> synchronize execution between separate worker processes.
>>
>> 4. Split the task so that each part would work with particular cluster.
>>pros: we don't extend our execution model
>>cons: untrivial implementation; no guarantee that we are always able
>> to split master node tasks on per cluster basis.
>>
>> Best,
>> Georgy
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] UFCG OneView CI comments missing recheck command

[Sam Betts (sambetts)]

On the official OpenStack Third Party CI Documentation, it is a
requirement for third party Cis to respond to comments in the following
formats: 

recheck

 recheck
 
(Where  is replaced with the name of your third party CI.)

http://docs.openstack.org/infra/system-config/third_party.html#requirements

I don¹t think we should be creating a third party recheck comment style
specific to Ironic, this will just lead to inconstancies across different
OpenStack projects.

Sam

On 07/07/2016 08:04, "Watanabe, Isao"  wrote:

>Hello jlvillal, thiagop
>Hello krtaylor
>
>In Cinder, 3rd party CIs are asked to set their recheck keyword to "run
>XXX CI" (also Note it in the CI's Wiki), so that the infra CI will not
>get kicked.
>Maybe we can decide one for our Ironic, too, on the next Wednesday.
>
>Best regards,
>Watanabe.isao
>
>
>> -Original Message-
>> From: Villalovos, John L [mailto:john.l.villalo...@intel.com]
>> Sent: Wednesday, June 29, 2016 9:24 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
>>recheck
>> command
>> 
>> 
>> 
>> > -Original Message-
>> > From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
>> > Sent: Tuesday, June 28, 2016 17:00
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> > Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
>> > recheck command
>> >
>> > Hi Jay,
>> >
>> > Sorry about that. The comment should be "recheck oneview" to test
>>again.
>> > I'll patch the failure message with instructions, thanks for the
>>warning.
>> 
>> I'm not sure "recheck oneview" is a good command because it will kick
>>off the
>> master recheck. I would suggest something that will not trigger the
>>normal jobs
>> to recheck.
>> 
>> "retest oneview"??  Hopefully there is some standard for 3rd Party CI
>>to use.
>> 
>> And yes, please do put in the message the command to do a job recheck.
>> 
>> John
>> 
>>_
>>_
>> OpenStack Development Mailing 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] Failed to install fuel master

[Stanislaw Bogatkin]

Hi guys,

could you tell which way you used to write ISO to the USB stick?

On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan  wrote:

> I'm pretty sure this is a USB stick install as I've seen the same failure
> on Fuel-8.0. Basically, the installer is not able to find the mounted drive
> to run the kickstart file. Duel layer DVD media or a virtual Fuel master
> are the only ways I've gotten Fuel-8.0 to install.
>
> On 07/05/2016 05:22 AM, Vladimir Kuklin wrote:
>
> Hi, Alioune
>
> Let's start with the most basic steps. Which Fuel are you using?
> And how do you install the node? Do you use USB stick or DVD or some IPMI
> virtual media? From what I see here it pretty much looks like, that this
> media is not inserted into the host.
>
> On Tue, Jul 5, 2016 at 3:11 PM, Alioune  wrote:
>
>> Hi all,
>>
>> I'm trying to install fuel master using [1] on phycal server but the
>> installation process fails and switches to a dracut console with the
>> following error:
>>
>> dracut-initqueue[595] floppy0: no floppy controllers found
>> dracut-initqueue[595] Warning: failed to fetck kickstart from
>> hd:sr0:/ks.cfg
>> dracut-initqueue[595] mount: no medium found on /dev/sr0
>> dracut-initqueue[595] Warning: Cloud not boot
>> dracut-initqueue[595] Warning: /dev/root does not exist
>>
>>
>> Starting Dracut Emergency Shell
>> Warning: /dev/root does not exist
>> Generating "/run/initramfs/rdsosreport.txt"
>> dracut:/#
>>
>> Any suggestion for solving that error ?
>>
>> Regards,
>>
>> [1]
>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Jack Morgan
> OPNFV Pharos Intel Lab
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Use Keystone trusts in Magnum?

[Johannes Grassler]

Hello,

On 07/06/2016 09:52 PM, Hongbin Lu wrote:

Magnum generates Keystone trust for each bay: 
https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay 
. Possibly, you can reuse the trust stored in the bay for this purpose.


Oh...good to know that, thanks! That would make it a lot easier. I'll give it a 
try...

Cheers,

Johannes



Best regards,
Hongbin


-Original Message-
From: Johannes Grassler [mailto:jgrass...@suse.de]
Sent: July-06-16 9:40 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [magnum] Use Keystone trusts in Magnum?

Hello,

I submitted https://review.openstack.org/#/c/326428 a while ago to get
around having to configure Heat's policy.json in a very permissive
manner[0]. I naively only tested it as one user, but gating caught that
omission and dutifully failed (a user cannot stack-get another user's
Heat stack, even if it's the Magnum service user). Ordinarily, that is.

Beyond the ordinary, Heat uses[1] Keystone trusts[2] to handle what is
basically the same problem (acting on a user's behalf way past the time
of the stack-create when the token used for the stack-create may have
expired already).

I propose doing the same thing in Magnum to get the Magnum service user
the ability to perform a stack-get on all of its bays' stacks. That way
the hairy problems with the wide-open permissions neccessary for a
global stack-list can be avoided entirely.

I'd be willing to implement this, either as part of the existing change
referenced above or with a blueprint and all the bells and whistles.

So I have two questions:

1) Is this an acceptable way to handle the issue?

2) If so, is it blueprint material or can I get away with adding the
code
 required for Keystone trusts to the existing change?

Cheers,

Johannes


Footnotes:

[0] See Steven Hardy's excellent dissection of the problem at the root
of it:

  http://lists.openstack.org/pipermail/openstack-dev/2016-
July/098742.html

[1] http://hardysteven.blogspot.de/2014/04/heat-auth-model-updates-
part-1-trusts.html

[2] https://wiki.openstack.org/wiki/Keystone/Trusts

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton Maxfeldstr. 5,
90409 Nürnberg, Germany

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




--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

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

Re: [openstack-dev] [ironic] UFCG OneView CI comments missing recheck command

[Watanabe, Isao]

Hello jlvillal, thiagop
Hello krtaylor

In Cinder, 3rd party CIs are asked to set their recheck keyword to "run XXX CI" 
(also Note it in the CI's Wiki), so that the infra CI will not get kicked.
Maybe we can decide one for our Ironic, too, on the next Wednesday.

Best regards,
Watanabe.isao


> -Original Message-
> From: Villalovos, John L [mailto:john.l.villalo...@intel.com]
> Sent: Wednesday, June 29, 2016 9:24 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: ufcg-oneview...@lsd.ufcg.edu.br
> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing recheck
> command
> 
> 
> 
> > -Original Message-
> > From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
> > Sent: Tuesday, June 28, 2016 17:00
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: ufcg-oneview...@lsd.ufcg.edu.br
> > Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
> > recheck command
> >
> > Hi Jay,
> >
> > Sorry about that. The comment should be "recheck oneview" to test again.
> > I'll patch the failure message with instructions, thanks for the warning.
> 
> I'm not sure "recheck oneview" is a good command because it will kick off the
> master recheck. I would suggest something that will not trigger the normal 
> jobs
> to recheck.
> 
> "retest oneview"??  Hopefully there is some standard for 3rd Party CI to use.
> 
> And yes, please do put in the message the command to do a job recheck.
> 
> John
> __
> OpenStack Development Mailing 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] [stable][liberty] [cinder] is stable liberty broken?

[Chen CH Ji]

Hi,
  I am backporting https://review.openstack.org/#/c/333749/ 
  to stable/liberty and failed in gating job, then I submitted another doc change https://review.openstack.org/#/c/338699/  to verify and seems failed with same reason and I have no idea what's wrong in test... can someone help to take a look or give some hint?
 
error is :

ft17.1: cinder.tests.unit.api.contrib.test_quotas.QuotaSetsControllerTest.test_delete_StringException: Empty attachments:
  pythonlogging:''
  stderr
  stdout

Traceback (most recent call last):
  File "cinder/tests/unit/api/contrib/test_quotas.py", line 100, in setUp
self.fixture = self.useFixture(config_fixture.Config(auth_token.CONF))
AttributeError: 'module' object has no attribute 'CONF'


__
OpenStack Development Mailing 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] Failed to install fuel master

[Jack Morgan]

I'm pretty sure this is a USB stick install as I've seen the same
failure on Fuel-8.0. Basically, the installer is not able to find the
mounted drive to run the kickstart file. Duel layer DVD media or a
virtual Fuel master are the only ways I've gotten Fuel-8.0 to install.


On 07/05/2016 05:22 AM, Vladimir Kuklin wrote:
> Hi, Alioune
>
> Let's start with the most basic steps. Which Fuel are you using?
> And how do you install the node? Do you use USB stick or DVD or some
> IPMI virtual media? From what I see here it pretty much looks like,
> that this media is not inserted into the host.
>
> On Tue, Jul 5, 2016 at 3:11 PM, Alioune  > wrote:
>
> Hi all,
>
> I'm trying to install fuel master using [1] on phycal server but
> the installation process fails and switches to a dracut console
> with the following error:
>
> dracut-initqueue[595] floppy0: no floppy controllers found
> dracut-initqueue[595] Warning: failed to fetck kickstart from
> hd:sr0:/ks.cfg
> dracut-initqueue[595] mount: no medium found on /dev/sr0
> dracut-initqueue[595] Warning: Cloud not boot
> dracut-initqueue[595] Warning: /dev/root does not exist
>
>
> Starting Dracut Emergency Shell
> Warning: /dev/root does not exist
> Generating "/run/initramfs/rdsosreport.txt"
> dracut:/#
>
> Any suggestion for solving that error ?
>
> Regards,
>
> [1] 
> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru 
> vkuk...@mirantis.com 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Jack Morgan
OPNFV Pharos Intel Lab

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