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

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

[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

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

[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

[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

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

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

[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

[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

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