date:20140825

Zane Bitter wrote:
 [...]
 Here are a few of the conclusions:
 
 * Everyone wishes the Design Summit worked like this.
 The meetup seemed a lot more productive than the design summit ever is.
 It's really nice to be in a room small enough that you can talk normally
 and hear everyone, instead of in a room designed for 150 people. It's
 really nice to be able to discuss stuff that isn't related to a
 particular feature - we had a long discussion about how to get through
 the review backlog, for example. It's really nice to not have fixed time
 slots for discussions - because everyone was in the room the whole time,
 we could dip in and out of different topics at will. Often we came back
 to one that we'd previously discussed because we had discovered new
 information. Finally, it's critical to be in a room covered in
 full-sized whiteboards that everyone can see. A single tiny flip chart
 doesn't cut it.

That's good feedback, thanks. The current discussion on design summit
format changes is a bit lost under a Nova thread, so I should revive it
as a separate thread very soon. The idea being to implement whatever
changes we can to the summit to make it more productive (in the limited
remaining time and options we have for that).

 [...]
 * Marc^W Zaqar is critical to pretty much every major non-Convergence
 feature on the roadmap.
 We knew that we wanted to use it for notifications, but we also want to
 make those a replacement for events, and a conduit for warnings and
 debugging information to the user. This is becoming so important that
 we're going to push ahead with an implementation now without waiting to
 see when Zaqar will graduate. Zaqar would also be a good candidate for
 pushing metadata changes to servers, to resolve the performance issues
 currently caused by polling.

Could you expand on that ? Do you need some kind of user-facing queue
service, or is there something in the marc^WZaqar approach that makes it
especially appealing ?

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

2014-08-25 Thread Robert Collins

Fwiw I would like to see such dependencies listed so that we can properly
install trunk via automation.
On 24 Aug 2014 10:43, Maru Newby ma...@redhat.com wrote:


 On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

  Signed PGP part
  FYI: I've uploaded a review for openstack/requirements to add the
  upstream module into the list of potential dependencies [1]. Once it's
  merged, I'm going to introduce this new requirement for Neutron.

 The only reason someone would install ncclient would be because they had a
 brocade or cisco solution that they wanted to integrate with and I don't
 think that justifies making Neutron depend on the library.


 Maru


  [1]: https://review.openstack.org/114213
 
  /Ihar
 
  On 12/08/14 16:27, Ihar Hrachyshka wrote:
   Hey all,
  
   as per [1], Cisco Nexus ML2 plugin requires a patched version of
   ncclient from github. I wonder:
  
   - whether this information is still current; - why don't we depend
   on ncclient thru our requirements.txt file.
  
   [1]: https://wiki.openstack.org/wiki/Neutron/ML2/MechCiscoNexus
  
   Cheers, /Ihar
  
   ___ OpenStack-dev
   mailing list OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Alan Kavanagh

That's a fair point Jay. The Czar does sound like a reasonable approach and 
what would be useful and helpful would be to appoint additional PTL's and not 
have the burden of everything falling on one individual which becomes over 
loading after a period of time. In this case, imho it would be useful to have 2 
or more PTL's assigned per project to adjust the workload and have different 
views and assess the sticky points with different views.
/Alan

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: August-25-14 1:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/23/2014 06:35 PM, Clint Byrum wrote:
  I agree as well. PTL is a servant of the community, as any good 
 leader is. If the PTL feels they have to drop the hammer, or if an 
 impass is reached where they are asked to, it is because they have 
 failed to get everyone communicating effectively, not because that's their 
 job.

The problem isn't really that teams are not communicating effectively, nor is 
the problem to do with some deficit of a PTL in either putting the hammer down 
or failing to figure out common ground.

The issue in my opinion and my experience is that there are multiple valid ways 
of doing something (say, deployment or metering or making
toast) and the TC and our governing structure has decided to pick winners in 
spaces instead of having a big tent and welcoming different solutions and 
projects into the OpenStack fold. We pick winners and by doing so, we are 
exclusionary, and this exclusivity does not benefit our user community, but 
rather just gives it fewer options.

IMHO, the TC should become an advisory team that recommends to interested 
project teams ways in which they can design and architect their projects to 
integrate well with other projects in the OpenStack community, and design their 
projects for the scale, stability and requirements (such as multi-tenancy) that 
an open cloud software ecosystem demands.

Just my two cents,
-jay


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

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

[openstack-dev] [osprofiler] how to report buy for osprofiler

2014-08-25 Thread LeslieWang

Dear all,
I found a bug of osprofiler, but can not find the project at launchpad.net, so 
wonder to know how to report the bug, and contribute my fix.
Best RegardsLeslie___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Anne Gentle wrote:
 Rochelle.RochelleGrober wrote:
/flame-on
 Let's call spades, spades here.  Czar is not only overkill, but the
 wrong metaphor.
 /flame-off
 
 I'm with Rocky on the anti-czar-as-a-word camp. We all like clever names
 to shed the corporate stigma but this word ain't it. Liaison or lead?

Sure! I certainly didn't want to offend anyone with my choice of terms.
Google lists two meanings for the word:

1. an emperor of Russia before 1917 (Tsar Nicholas II)
2. a person appointed by government to advise on and coordinate policy
in a particular area (the former British drugs czar)

I was referring to the latter meaning (like the US presidency has had
cybersecurity czars in the past), but I'm fine with using liaison
instead -- it's just slightly more boring.

 Also wanted to point to https://wiki.openstack.org/wiki/PTLguide as it's
 quite nice.
 
 I think PTLs tend to find help when they absolutely are ready to fall
 over, and I'm all for a plan that helps us not fall over. I've had
 people step up for bug triaging, gate work, tests, and oslo, sometimes
 one person did three or four at once. I certainly can't do it all for
 cross-project. Based on what I've seen, I doubt that we can add this
 much formality to this across 20+ programs. It's the bigger more
 integrated project vs. smaller more focused project difference that
 won't let us do a pattern here. We can certainly document the
 responsibilities and let programs know there are some best practices.

In smaller programs, I would expect the PTL to keep filling most, if not
all, of those roles. As long as the PTL is not overworked, the roles are
well-known and everyone knows who to contact, it works.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [osprofiler] how to report buy for osprofiler

2014-08-25 Thread Boris Pavlovic

Hi Lesile,


Woot! Somebody started using OSprofiler!

I create OSprofiler launchpad page: https://bugs.launchpad.net/osprofiler

Feel free to report bug there.

Best regards,
Boris Pavlovic


On Mon, Aug 25, 2014 at 1:54 PM, LeslieWang wqyu...@hotmail.com wrote:

 Dear all,

 I found a bug of osprofiler, but can not find the project at launchpad.net,
 so wonder to know how to report the bug, and contribute my fix.

 Best Regards
 Leslie

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


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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Zane Bitter wrote:
 On 22/08/14 12:45, Dolph Mathews wrote:
 I'm all for getting a final decision, but a 'final' decision that
 has been
 imposed from outside rather than internalised by the participants is...
 rarely final.
 
 The expectation of a PTL isn't to stomp around and make final
 decisions,
 it's to step in when necessary and help both sides find the best
 solution.
 To moderate.
 
 Oh sure, but that's not just the PTL's job. That's everyone's job. Don't
 you think?
 
 I did that before I was the PTL and will continue to do it after I'm no
 longer the PTL. And if anyone in the (especially) the core or wider Heat
 team sees an opportunity to step in and moderate a disagreement I
 certainly expect them to take it and not wait for me to step in.
 
 I'm not calling for no leadership here - I'm calling for leadership from
 _everyone_, not just from one person who holds a particular role.

I guess the difference between you and me is that I don't see having a
PTL as preventing that moderation and leadership from everyone. I really
see it as a safety valve in case things ever go badly wrong. I prefer
that safety valve to be built into the project leadership, rather than
at the TC level.

Could you explain how having a PTL is preventing that leadership from
everyone ? Did it prevent it in Heat ? Did having the PTL safety valve
hurt you ?

I'm open to the alternative solution (which would be for programs which
are not interested in having a PTL to just not have one). But then if
things go badly wrong, you require the TC to step in with threats of
removal of OpenStack and/or to force an election/vote in the middle of
the crisis. I'm really failing to see how that would result, in those
hypothetical crisis scenarios, in a better outcome.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Tim Bell wrote:
 As part of the user feedback loop, we've found the PTL role extremely useful 
 to channel feedback.  The operator PTL discussions during the Atlanta summit 
 helped to clarify a number of areas where the PTL can then take the points 
 back to the design summit. It is not clear how czars would address the 
 outward facing part of the PTL role which is clearly needed in view of the 
 various discussions around program management and priorities.
 
 If we have lots of czars or major differences in how each project is 
 structured, it is not clear how we channel user feedback to the project 
 teams. Would there be a user czar on each project ?

I agree that this external/user communication role is essential, and is
likely to stay with the PTL, which is why I didn't have a User czar in
my list.

 I have no problem with lots of czars to delegate activities across the 
 projects but having a single accountable and elected PTL who can choose the 
 level of delegation (and be assessed on that) seems to be a very good feature.

Indeed, I see it more as a clear list of the duties that usually fall
onto the PTL lap, but which could be delegated. If some programs want to
keep it the way it is (with the PTL being responsible for all those
duties), it's totally fine.

It's a framework for clear delegation within the current system, not a
whole new system :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc] Procedure for adding official projects

Zane Bitter wrote:
 Over the past couple of release cycles, the TC has put together a fairly
 comprehensive checklist for projects entering into incubation with a
 view to being included in the integrated release. However, I'm not aware
 of anything equivalent for projects that are becoming official (i.e.
 moving to the openstack/ namespace) but that are not targeting eventual
 integration - or, indeed, that _are_ targeting eventual integration but
 have not yet applied for incubation.
 
 The current procedure afaict is to submit a review to the governance
 repo listing the repository under a particular program. It seems like at
 a minimum we should be checking for basic due diligence stuff like Is
 it Apache licensed?, Did everyone sign the CLA? (may it diaf) and
 Are there any trademark issues?. And maybe there are other things the
 TC should be looking at too.

I agree... currently we only check that the program is fine with adding
that new repository (by checking with the PTL :P) and that the project
intent seems to fit in the program mission scope. Extra basic due
diligence can't hurt, and we could turn that into a new requirements list.

Would you be interested in proposing a basic new projects in existing
program requirements list as a governance repo change ? Then we could
iterate on it.

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

2014-08-25 Thread Irena Berezovsky

Hi Andreas,
We can definitely set some time to discuss this. 
I am usually available from 5 to 14:00 UTC.  
Let's follow up on IRC (irenab).

BR,
Irena

-Original Message-
From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] 
Sent: Monday, August 25, 2014 11:00 AM
To: Irena Berezovsky
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non 
promic mode adapters

Hi Irena,
thanks for your reply. Yes sure, collaboration would be great. 
Do you already have a blueprint out there? Maybe wen can synchup this week to 
discuss more details? Cause I would like to understand what exactly you're 
looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 
utc). My irc name is scheuran. Maybe we can get in contact this week!

You also where talking about sriov. I saw some blueprint mentioning sriov  
macvtap. Do you have any insights into this one, too? What we also would like 
to do is to introduce macvtap as network virtualization option. Macvtap also 
registers mac addresses to network adapters...


Thanks,
Andreas


On Sun, 2014-08-24 at 08:51 +, Irena Berezovsky wrote:
 Hi Andreas,
 Thank you for this initiative.
 We were looking on similar problem for mixing OVS and SR-IOV on same network 
 adapter, which also requires mac addresses registration of OVS ports. 
 Please let me know if you would like to collaborate on this effort.
 
 BR,
 Irena
 
 -Original Message-
 From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
 Sent: Friday, August 22, 2014 11:16 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support 
 for non promic mode adapters
 
 Thanks for your feedback. 
 
 No, I do not yet have code for it. Just wanted to get a feeling if such a 
 feature would get acceptance in the community. 
 But if that helps I can sit down and start some prototyping while I'm 
 preparing a blueprint spec in parallel. 
 
 The main part of the implementation I wanted to do on my own to get more 
 familiar with the code base and to get more in touch with the community.
 But of course advice and feedback of experienced neutron developers is 
 essential!
 
 So I will proceed like this
 - Create a blueprint
 - Commit first pieces of code to get early feedback (e.g. ask via the 
 mailing list or irc)
 - Upload a spec (as soon as the repo is available for K)
 
 Does that make sense for you?
 
 Thanks,
 Andreas
 
 
 
 On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
  I think this sounds reasonable. Do you have code for this already, 
  or are you looking for a developer to help implement it?
  
  
  On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring 
  scheu...@linux.vnet.ibm.com wrote:
  Hi,
  last week I started discussing an extension to the existing
  neutron
  openvswitch agent to support network adapters that are not in
  promiscuous mode. Now I would like to enhance the round to get
  feedback
  from a broader audience via the mailing list.
  
  
  The Problem
  When driving vlan or flat networking, openvswitch requires an
  network
  adapter in promiscuous mode.
  
  
  Why not having promiscuous mode in your adapter?
  - Admins like to have full control over their environment and
  which
  network packets enter the system.
  - The network adapter just does not have support for it.
  
  
  What to do?
  Linux net-dev driver offer an interface to manually register
  additional
  mac addresses (also called secondary unicast addresses).
  Exploiting this
  one can register additional mac addresses to the network
  adapter. This
  also works via a well known ip user space tool.
  
  `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`
  
  
  What to do in openstack?
  As neutron is aware of all the mac addresses that are in use
  it's the
  perfect candidate for doing the mac registrations. The idea is
  to modify
  the neutron openvswitch agent that it does the registration on
  port
  add and port remove via the bridge command.
  There would be a new optional configuration parameter,
  something like
  'non-promisc-mode' that is by default set to false. Only when
  set to
  true, macs get manually registered. Otherwise the agent
  behaves like it
  does today. So I guess only very little changes to the agent
  code are
  required. From my current point of view we do not need any
  changes to
  the ml2 plug-in.
  
  
  Blueprint or a bug?
  I guess it's a blueprint.

Re: [openstack-dev] [nova] Server Group API: add 'action' to authorizer?

2014-08-25 Thread Alex Xu


On 2014年08月23日 18:29, Christopher Yeoh wrote:

On Sat, 23 Aug 2014 03:56:27 -0500
Joe Cropper cropper@gmail.com wrote:


Hi Folks,

Would anyone be opposed to adding the 'action' checking to the v2/v3
authorizers?  This would allow administrators more fine-grained
control over  who can read vs. create/update/delete server groups.

Thoughts?

If folks are supportive, I'd be happy to add this... but not sure if
we'd treat this as a 'bug' or whether there is a blueprint under which
this could be done?

Long term we want to have a separate authorizer for every method. Alex
had a nova-spec  proposed for this but it unfortunately did not make
Juno

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

Also since the feature proposal deadline has passed it'll have to wait
till Kilo.


Yes, that spec propose adding policy rule for each API for get more 
fine-grained control. But we have to wait till K release.




Chris

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






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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Flavio Percoco

On 08/25/2014 12:30 PM, Thierry Carrez wrote:
 Zane Bitter wrote:
 On 22/08/14 12:45, Dolph Mathews wrote:
 I'm all for getting a final decision, but a 'final' decision that
 has been
 imposed from outside rather than internalised by the participants is...
 rarely final.

 The expectation of a PTL isn't to stomp around and make final
 decisions,
 it's to step in when necessary and help both sides find the best
 solution.
 To moderate.

 Oh sure, but that's not just the PTL's job. That's everyone's job. Don't
 you think?

 I did that before I was the PTL and will continue to do it after I'm no
 longer the PTL. And if anyone in the (especially) the core or wider Heat
 team sees an opportunity to step in and moderate a disagreement I
 certainly expect them to take it and not wait for me to step in.

 I'm not calling for no leadership here - I'm calling for leadership from
 _everyone_, not just from one person who holds a particular role.
 
 I guess the difference between you and me is that I don't see having a
 PTL as preventing that moderation and leadership from everyone. I really
 see it as a safety valve in case things ever go badly wrong. I prefer
 that safety valve to be built into the project leadership, rather than
 at the TC level.
 
 Could you explain how having a PTL is preventing that leadership from
 everyone ? Did it prevent it in Heat ? Did having the PTL safety valve
 hurt you ?
 

I'd like to see projects leadership as federated as possible. I think
PTLs are actually responsible for spreading leadership throughout the team.

From my point of view, and this is a very personal point of view, PTLs
should worry for making the team grow as a team and as individuals.
Spreading the responsibilities and making everyone part of the decision
making process will help the team to mature and it'll also encourage
members of that team to send their candidacy for future elections.

This is why I think the Czar's (or whatever it'll be called) idea is
important. There may be lots of volunteers or none. However, it's
important to encourage people to participate and I believe this is also
part of the PTLs responsibility.

People could argue saying that we don't need a PTL to do that, everyone
in the community should help with encouraging others and I would
certainly agree with that too.

Probably, the issue here is not about having leaders but about
encouraging people to lead and volunteer as much as they can without
burning out. Thing is, what's the easiest way to get there without
slowing down development or hurting existing projects?

For example: I've heard folks saying: The project is in this state
because the PTL X, Y and Z This is wrong, the project is in that state
because the *whole* team took it there or because no one cares. What I'm
trying to say is that we need to change the way we talk/think about PTLs.

Flavio


 I'm open to the alternative solution (which would be for programs which
 are not interested in having a PTL to just not have one). But then if
 things go badly wrong, you require the TC to step in with threats of
 removal of OpenStack and/or to force an election/vote in the middle of
 the crisis. I'm really failing to see how that would result, in those
 hypothetical crisis scenarios, in a better outcome.


-- 
@flaper87
Flavio Percoco

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

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

2014-08-25 Thread Maru Newby



On Aug 25, 2014, at 11:38 AM, Robert Collins robe...@robertcollins.net wrote:

 Fwiw I would like to see such dependencies listed so that we can properly 
 install trunk via automation.

Do you mean that you want the requirements for all plugins listed somewhere in 
the tree?  Or specifically in Neutron’s requirements.txt?


 On 24 Aug 2014 10:43, Maru Newby ma...@redhat.com wrote:
 
 On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:
 
  Signed PGP part
  FYI: I've uploaded a review for openstack/requirements to add the
  upstream module into the list of potential dependencies [1]. Once it's
  merged, I'm going to introduce this new requirement for Neutron.
 
 The only reason someone would install ncclient would be because they had a 
 brocade or cisco solution that they wanted to integrate with and I don't 
 think that justifies making Neutron depend on the library.
 
 
 Maru
 
 
  [1]: https://review.openstack.org/114213
 
  /Ihar
 
  On 12/08/14 16:27, Ihar Hrachyshka wrote:
   Hey all,
  
   as per [1], Cisco Nexus ML2 plugin requires a patched version of
   ncclient from github. I wonder:
  
   - whether this information is still current; - why don't we depend
   on ncclient thru our requirements.txt file.
  
   [1]: https://wiki.openstack.org/wiki/Neutron/ML2/MechCiscoNexus
  
   Cheers, /Ihar
  
   ___ OpenStack-dev
   mailing list OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

2014-08-25 Thread gordon chung

just an update, i had to re-add PYTHONHASHSEED = 0 to ceilometer. i didn't find 
the exact root cause of why WSME is affecting our doc gate but it appears WSME 
is also affected by new tox and random hashseed as it too suffers from random 
failures in UT.
for now, i've added back HASHSEED so we should be unblocked

cheers,
gord  ___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] The future of the integrated release

2014-08-25 Thread Sean Dague

On 08/20/2014 12:37 PM, Zane Bitter wrote:
 On 11/08/14 05:24, Thierry Carrez wrote:
 So the idea that being (and remaining) in the integrated release should
 also be judged on technical merit is a slightly different effort. It's
 always been a factor in our choices, but like Devananda says, it's more
 difficult than just checking a number of QA/integration checkboxes. In
 some cases, blessing one project in a problem space stifles competition,
 innovation and alternate approaches. In some other cases, we reinvent
 domain-specific solutions rather than standing on the shoulders of
 domain-specific giants in neighboring open source projects.
 
 I totally agree that these are the things we need to be vigilant about.
 
 Stifling competition is a big worry, but it appears to me that a lot of
 the stifling is happening even before incubation. Everyone's time is
 limited, so if you happen to notice a new project on the incubation
 trajectory doing things in what you think is the Wrong Way, you're most
 likely to either leave some drive-by feedback or to just ignore it and
 carry on with your life. What you're most likely *not* to do is to start
 a competing project to prove them wrong, or to jump in full time to the
 existing project and show them the light. It's really hard to argue
 against the domain experts too - when you're acutely aware of how
 shallow your knowledge is in a particular area it's very hard to know
 how hard to push. (Perhaps ironically, since becoming a PTL I feel I
 have to be much more cautious in what I say too, because people are
 inclined to read too much into my opinion - I wonder if TC members feel
 the same pressure.) I speak from first-hand instances of guilt here -
 for example, I gave some feedback to the Mistral folks just before the
 last design summit[1], but I haven't had time to follow it up at all. I
 wouldn't be a bit surprised if they showed up with an incubation
 request, a largely-unchanged user interface and an expectation that I
 would support it.
 
 The result is that projects often don't hear the feedback they need
 until far too late - often when they get to the incubation review (maybe
 not even their first incubation review). In the particularly unfortunate
 case of Marconi, it wasn't until the graduation review. (More about that
 in a second.) My best advice to new projects here is that you must be
 like a ferret up the pant-leg of any negative feedback. Grab hold of any
 criticism and don't let go until you have either converted the person
 giving it into your biggest supporter, been converted by them, or
 provoked them to start a competing project. (Any of those is a win as
 far as the community is concerned.)
 
 Perhaps we could consider a space like a separate mailing list
 (openstack-future?) reserved just for announcements of Related projects,
 their architectural principles, and discussions of the same?  They
 certainly tend to get drowned out amidst the noise of openstack-dev.
 (Project management, meeting announcements, and internal project
 discussion would all be out of scope for this list.)
 
 As for reinventing domain-specific solutions, I'm not sure that happens
 as often as is being made out. IMO the defining feature of IaaS that
 makes the cloud the cloud is on-demand (i.e. real-time) self-service.
 Everything else more or less falls out of that requirement, but the very
 first thing to fall out is multi-tenancy and there just aren't that many
 multi-tenant services floating around out there. There are a couple of
 obvious strategies to deal with that: one is to run existing software
 within a tenant-local resource provisioned by OpenStack (Trove and
 Sahara are examples of this), and the other is to wrap a multi-tenancy
 framework around an existing piece of software (Nova and Cinder are
 examples of this). (BTW the former is usually inherently less
 satisfying, because it scales at a much coarser granularity.) The answer
 to a question of the form:
 
 Why do we need OpenStack project $X, when open source project $Y
 already exists?
 
 is almost always:
 
 Because $Y is not multi-tenant aware; we need to wrap it with a
 multi-tenancy layer with OpenStack-native authentication, metering and
 quota management. That even allows us to set up an abstraction layer so
 that you can substitute $Z as the back end too.
 
 This is completely uncontroversial when you substitute X, Y, Z = Nova,
 libvirt, Xen. However, when you instead substitute X, Y, Z =
 Zaqar/Marconi, Qpid, MongoDB it suddenly becomes *highly* controversial.
 I'm all in favour of a healthy scepticism, but I think we've passed that
 point now. (How would *you* make an AMQP bus multi-tenant?)
 
 To be clear, Marconi did made a mistake. The Marconi API presented
 semantics to the user that excluded many otherwise-obvious choices of
 back-end plugin (i.e. Qpid/RabbitMQ). It seems to be a common thing (see
 also: Mistral) to want to design for every feature an existing
 Enterprisey

[openstack-dev] [mistral] Team meeting reminder - 08/25/2014

2014-08-25 Thread Renat Akhmerov

Hi Mistral folks,

Don’t forget that we’ll have a team meeting today at 16.00 UTC at 
#openstack-meeting.

Agenda:
* Review action items
* Current status (progress, issues, roadblocks, further plans)
* API V2 Discussion (integration with Glance, versioned client etc.)
* New action design discussion (storing actions in DB etc.)
* Open discussion

(See http://wiki.openstack.org/wiki/Meetings/MistralAgenda for meeting archive)

Renat Akhmerov
@ Mirantis Inc.



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

[openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

2014-08-25 Thread Timur Nurlygayanov

Hi team,

Today I started to build Fuel ISO from the master branch and with packages
with code from the master branches, and have found strange errors:
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/77/console

Looks like we have hardcoded versions of all required packages in specs:
https://github.com/stackforge/fuel-main/blob/master/packages/rpm/specs/nailgun.spec#L17-L44

and this is the root of problems. In the result we can't build ISO from
master branch, because we have another versions of requirements for code
from master branches.
Looks like it is common issue for several components.

Could we discuss how we can organize specs to avoid problems with
dependencies?


Thank you!


-- 

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc

[image: http://www.openstacksv.com/] http://www.openstacksv.com/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Swift] 2.1.0-rc tagged

2014-08-25 Thread John Dickinson

Swift 2.1.0.rc1 has been tagged as our release candidate for 2.1.0. The plan is 
to let this RC soak for a week and then do the final release on Sept 1.

Please check it out and report any issues that you find.


Tag applied:
http://git.openstack.org/cgit/openstack/swift/commit/?id=8d02147d04a41477383de8e13bea6ac3fd2cade0

Tarball built:
http://tarballs.openstack.org/swift/swift-2.1.0.rc1.tar.gz

Bugfixes marked released at:
https://launchpad.net/swift/+milestone/2.1.0



--John






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [osprofiler] how to report buy for osprofiler

2014-08-25 Thread LeslieWang

Hi Boris,
Thanks for the reply. 
I'm trying TripleO, and want to enable Horizon UI in this environment, and the 
bug causes horizon can not start correctly. I feel my found probably is helpful 
for people who have needs, so wanna report back to community. 
I've created bug https://bugs.launchpad.net/osprofiler/+bug/1361235, and 
describe the problems and root cause as well as one possible solution.
Best RegardsLeslie___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

2014-08-25 Thread Igor Shishkin

Hi all,
along with building your own ISO following instructions [1], you can always 
download nightly build [2] and run it, by using virtualbox scripts [3], for 
example.

For your conveniency, you can see a build status table on CI [4]. First tab now 
refers to pre-5.1 builds, and second - to master builds.
BVT columns stands for Build Verification Test, which is essentially full HA 
deploy deployment test.

Currently pre-5.1 and master builds are actually built from same master branch. 
As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to 
use stable/5.1 branch.

Thanks,

[1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
[2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds
[3] https://github.com/stackforge/fuel-main/tree/master/virtualbox
[4] https://fuel-jenkins.mirantis.com/view/ISO/
-- 
Igor Shishkin
DevOps




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

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-08-25 Thread Pradeep Kilambi (pkilambi)



On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote:


On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:

 On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com
wrote:
 On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 20/08/14 18:28, Salvatore Orlando wrote:
 Some comments inline.
 
 Salvatore
 
 On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com
 mailto:ihrac...@redhat.com wrote:
 
 Hi all,
 
 I've read the proposal for incubator as described at [1], and I
 have several comments/concerns/suggestions to this.
 
 Overall, the idea of giving some space for experimentation that
 does not alienate parts of community from Neutron is good. In that
 way, we may relax review rules and quicken turnaround for preview
 features without loosing control on those features too much.
 
 Though the way it's to be implemented leaves several concerns, as
 follows:
 
 1. From packaging perspective, having a separate repository and
 tarballs seems not optimal. As a packager, I would better deal with
 a single tarball instead of two. Meaning, it would be better to
 keep the code in the same tree.
 
 I know that we're afraid of shipping the code for which some users
 may expect the usual level of support and stability and
 compatibility. This can be solved by making it explicit that the
 incubated code is unsupported and used on your user's risk. 1) The
 experimental code wouldn't probably be installed unless explicitly
 requested, and 2) it would be put in a separate namespace (like
 'preview', 'experimental', or 'staging', as the call it in Linux
 kernel world [2]).
 
 This would facilitate keeping commit history instead of loosing it
 during graduation.
 
 Yes, I know that people don't like to be called experimental or
 preview or incubator... And maybe neutron-labs repo sounds more
 appealing than an 'experimental' subtree in the core project.
 Well, there are lots of EXPERIMENTAL features in Linux kernel that
 we actively use (for example, btrfs is still considered
 experimental by Linux kernel devs, while being exposed as a
 supported option to RHEL7 users), so I don't see how that naming
 concern is significant.
 
 
 I think this is the whole point of the discussion around the
 incubator and the reason for which, to the best of my knowledge,
 no proposal has been accepted yet.
 
 
 I wonder where discussion around the proposal is running. Is it
public?
 
 The discussion started out privately as the incubation proposal was
 put together, but it's now on the mailing list, in person, and in IRC
 meetings. Lets keep the discussion going on list now.
 
 
 In the spirit of keeping the discussion going, I think we probably
 need to iterate in practice on this idea a little bit before we can
 crystallize on the policy and process for this new repo. Here are few
 ideas on how we can start this iteration:
 
 * Namespace for the new repo:
 Should this be in the neutron namespace, or a completely different
 namespace like neutron labs? Perhaps creating a separate namespace
 will help the packagers to avoid issues of conflicting package owners
 of the namespace.

I don¹t think there is a technical requirement to choose a new namespace.
 Python supports sharing a namespace, and packaging can support this
feature (see: oslo.*).


From what I understand there can be overlapping code between neutron and
incubator to override/modify existing python/config files. In which case,
packaging(for Eg: rpm) will raise a path conflict. So we probably will
need to worry about namespaces?



 
 * Dependency on Neutron (core) repository:
 We would need to sort this out so that we can get UTs to run and pass
 in the new repo. Can we set the dependency on Neutron milestone
 releases? We already publish tar balls for the milestone releases, but
 I am not sure we publish these as packages to pypi. If not could we
 start doing that? With this in place, the incubator would always lag
 the Neutron core by at the most one milestone release.

Given that it is possible to specify a dependency as a branch/hash/tag in
a git repo [1], I¹m not sure it¹s worth figuring out how to target
tarballs.  Master branch of the incubation repo could then target the
master branch of the Neutron repo and always be assured of being current,
and then released versions could target milestone tags or released
versions.

1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git


 
 * Modules overlapping with the Neutron (core) repository:
 We could initially start with the features that required very little
 or no changes to the Neutron core, to avoid getting into the issue of
 blocking on changes to the Neutron (core) repository before progress
 can be made in the incubator.

+1

I agree that it would be in an incubated effort¹s best interest to put
off doing invasive changes to the Neutron tree as long as possible to
ensure

Re: [openstack-dev] [TripleO][Nova] Specs and approvals

2014-08-25 Thread Jay Dobies

I was on vacation last week and am late to the discussion, but I'm +1 
for the idea.


On 08/19/2014 02:08 PM, Joe Gordon wrote:




On Tue, Aug 19, 2014 at 8:23 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:

On 08/19/2014 05:31 AM, Robert Collins wrote:
  Hey everybody - https://wiki.openstack.org/wiki/TripleO/SpecReviews
  seems pretty sane as we discussed at the last TripleO IRC meeting.
 
  I'd like to propose that we adopt it with the following tweak:
 
  19:46:34 lifeless so I propose that +2 on a spec is a commitment to
  review it over-and-above the core review responsibilities
  19:47:05 lifeless if its not important enough for a reviewer to do
  that thats a pretty strong signal
  19:47:06 dprince lifeless: +1, I thought we already agreed to that
  at the meetup
  19:47:17 slagle yea, sounds fine to me
  19:47:20 bnemec +1
  19:47:30 lifeless dprince: it wasn't clear whether it was
  part-of-responsibility, or additive, I'm proposing we make it clearly
  additive
  19:47:52 lifeless and separately I think we need to make surfacing
  reviews-for-themes a lot better
 
  That is - +1 on a spec review is 'sure, I like it', +2 is
specifically
  I will review this *over and above* my core commitment - the goal
  here is to have some very gentle choke on concurrent WIP without
  needing the transition to a managed pull workflow that Nova are
  discussing - which we didn't have much support for during the
meeting.
 
  Obviously, any core can -2 for any of the usual reasons - this motion
  is about opening up +A to the whole Tripleo core team on specs.
 
  Reviewers, and other interested kibbitzers, please +1 / -1 as you
feel fit :)

+1

I really like this.  In fact, I like it a lot more than the current
proposal for Nova.  I think the Nova team should consider this, as well.


Nova and tripleo are at different points in there lifecycle just look at
tripleo-specs [0] vs nova-specs [1]. TripleO has 11 specs and nova has
80+, TripleO has 22 cores and nova has 21 cores.  AFAIK none of the
tripleo specs are vendor specific, while a good chunk of nova ones are.
I don't think there is a one size fits all solution here.


[0] http://specs.openstack.org/openstack/tripleo-specs/
[1] http://specs.openstack.org/openstack/nova-specs/


It still rate limits code reviews by making core reviewers explicitly
commit to reviewing things.  This is like our previous attempt at
sponsoring blueprints, but the use of gerrit I think would make it more
successful.

It also addresses my primary concerns with the tensions between group
will and small groups no longer being able to self organize and push
things to completion without having to haggle through yet another
process.

--
Russell Bryant

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




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



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

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone


On 24/08/14 23:17, Adam Young wrote:

On 08/23/2014 02:01 AM, Clint Byrum wrote:

I don't know how Zaqar does its magic, but I'd love to see simple signed
URLs rather than users/passwords. This would work for Heat as well. That
way we only have to pass in a single predictably formatted string.

Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700:

Here's an interesting fact about Zaqar (the project formerly known as
Marconi) that I hadn't thought about before this week: it's probably the
first OpenStack project where a major part of the API primarily faces




Nah, this is the direction we are headed.  Service users (out of LDAP!)
are going to be the norm with a recent feature add to Keytone:


http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/


Ah, excellent, thanks Adam. (BTW markup fail: The naming of this file 
is essential: keystone..conf [sic] is the expected form.)


So this will solve the Authentication half of the problem. What is the 
recommended solution for Authorisation?


In particular, even if a service like Zaqar or Heat implements their own 
authorisation (e.g. the user creating a Zaqar queue supplies lists of 
the accounts that are allowed to read or write to it, respectively), how 
does the user ensure that the service accounts they create will not have 
access to other OpenStack APIs? IIRC the default policy.json files 
supplied by the various projects allow non-admin operations from any 
account with a role in the project.


thanks,
Zane.

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

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

2014-08-25 Thread Ryan Brown



On 08/22/2014 05:35 PM, Zane Bitter wrote:

 On AWS the very first thing a user does is create a bunch of IAM
 accounts so that they virtually never have to use the credentials
 associated with their natural person ever again. There are both user
 accounts and service accounts - the latter IIUC have
 automatically-rotating keys. Is there anything like this planned in
 Keystone? Zaqar is likely only the first (I guess second, if you count
 Heat) of many services that will need it.
 

The only auto-rotation in AWS is through roles[1], which are separate
from users.

User:
* Is a real person or a service account
* Can generate temporary tokens with a subset of their perms
* Has a static credentials (access keys, username/password, MFA)

Role:
* Has no static credentials
* Is granted to an instance on launch
* Temporary tokens are provided to instance by instance metadata service

I'm actually quite partial to roles because, in my experience, service
accounts rarely have their credentials rotated more than once per eon.
Having the ability to let instances grab tokens would certainly help
Heat, especially if we start using Zaqar (the artist formerly known as
marconi).


[1]:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

2014-08-25 Thread Kyle Mestery

Dane, thanks for all the great work you're doing in the third-party CI
area. It's great to see you working to share this knowledge with
others as well!

Did Kevin's idea work for you to move past this issue? If not, I
suggest you put an item on the neutron meeting agenda today and we
cover this there. You could put the item on the third-party meeting
agenda as well.

Thanks!
Kyle

On Sun, Aug 24, 2014 at 9:43 AM, Dane Leblanc (leblancd)
lebla...@cisco.com wrote:
 Hi Kevin:



 Thanks, this is a great idea! I may try just a slight variation of this
 concept. Maybe your idea could be the recommended way to create a 3rd party
 CI for plugins that are just being introduced and need to limit the scope of
 testing to a small set of plugin-related commits (or plugins blocked on a
 certain fix).



 Thanks,
 Dane



 From: Kevin Benton [mailto:blak...@gmail.com]
 Sent: Saturday, August 23, 2014 5:47 AM


 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required
 to be run



 Can you disable posting of results directly from your Jenkins/Zuul setup and
 have a script that just checks the log file for special markers to determine
 if the vote should be FAILED/PASSED/SKIPPED? Another advantage of this
 approach is that it gives you an opportunity to detect when a job just
 failed to setup due to infrastructure reasons and trigger a recheck without
 ever first posting a failure to gerrit.



 On Fri, Aug 22, 2014 at 3:06 PM, Dane Leblanc (leblancd)
 lebla...@cisco.com wrote:

 Thanks Edgar for updating the APIC status!!!

 Edgar and Kyle: *PLEASE NOTE**  I need your understanding and
 advice on the following:

 We are still stuck with a problem stemming from a design limitation of
 Jenkins that prevents us from being compliant with Neutron 3rd Party CI
 requirements for our DFA CI.

 The issue is that Jenkins only allows our scripts to (programmatically)
 return either Success or Fail. There is no option to return Aborted, Not
 Tested, or Skipped.

 Why does this matter? The DFA plugin is just being introduced, and initial
 DFA-enabling change sets have not yet been merged. Therefore, all other
 change sets will fail our Tempest tests, since they are not DFA-enabled.

 Similarly, we were recently blocked in our APIC CI with a critical bug,
 causing all change sets without this fix to fail on our APIC testbed.

 In these cases, we would like to enter a throttled or partially blocked
 mode, where we would skip testing on change sets we know will fail, and (in
 an ideal world) signal this shortcoming to Gerrit e.g. by returning a
 Skipped status. Unfortunately, this option is not available in Jenkins
 scripts, as Jenkins is currently designed. The only options we have
 available is Success or all Fail, which are both misleading. We would
 also incorrectly report success or fail on one of the following test
 commits:
 https://review.openstack.org/#/c/114393/
 https://review.openstack.org/#/c/40296/

 I've brought this issue up on the openstack-infra IRC, and jeblair confirmed
 the Jenkins limitation, but asked me to get consensus from the Neutron
 community as to this being a problem/requirement. I've also sent out an
 e-mail on the Neutron ML trying to start a discussion on this problem (no
 traction). I plan on bringing this up in the 3rd Party CI IRC on Monday,
 assuming there is time permitted in the open discussion.

 I'm also investigating

 For the short term, I would like to propose the following:
 * We bring this up on the 3rd Party CI IRC on Monday to get a solution or
 workaround, if available. If a solution is available, let's consider
 including that as a hint when we come up with CI requirements for handling
 CIs bocked by some critical fix.
 * I'm also looking into using a REST API to cancel a Jenkins job
 programmatically.
 * If no solution or workaround is available, we work with infra team or with
 Jenkins team to create a solution.
 * Until a solution is available, for plugins which are blocked by a critical
 bug, we post a status/notes indicating the plugin's situation on our 3rd
 party CI status wiki, e.g.:

 Vendor  Plugin/Driver Name  Contact Name
 Status  Notes
 My Vendor Name  My Plugin CIMy Contact Person   T
 Throttled / Partially blocked / Awaiting Intial Commits

 The status/notes should be clear and understood by the Neutron team.  The
 console logs for change sets where the tests were skipped should also
 contain a message that all testing is being skipped for that commit.

 Note that when the DFA initial commits are merged, then this issue would go
 away for the DFA CI. However, this problem will reappear every time a
 blocking critical bug shows up for a 3rd party CI setup, or a new plugin is
 introduced and the hardware-enabling commits are not yet merged.  (That is,
 until we have a solution for the Jenkins limitation).

 Let me know what you think.

[openstack-dev] [nova] Server Groups - remove VM from group?

Hello,

Is our long-term vision to allow a VMs to be dynamically added/removed
from a group?  That is, unless I'm overlooking something, it appears
that you can only add a VM to a server group at VM boot time and
effectively remove it by deleting the VM?

Just curious if this was a design point, or merely an approach at a
staged implementation [that might welcome some additions]?  :)

Thanks,
Joe

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

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

2014-08-25 Thread Kyle Mestery

On Sun, Aug 24, 2014 at 2:18 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Hi,

The amount of tests that we are having to add skips to for the One
Convergence plugin has grown quite a bit lately.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

This is the only plugin that inherits from the NeutronDbPluginV2 class and
has completely disabled creating Subnets that have an ip_version of 6.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

I hate to single out this plugin. Before this development cycle, open source
plugins would allow the creation of Subnets with ip_version set to 6, and
then have lots of bugs which would prevent any instances from actually
obtaining IPv6 addresses and routing. But we didn't have to explicitly skip
tests every time someone wanted to fix bugs - like the following patch.

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

Also, I want to highlight some meeting minutes, where it was discussed that
in the K release, all plugins will be required to support IPv6. I hope we
can discuss this, build consensus, and ensure that the K release requirement
is reasonable.

http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

Sean, this is a very valid point. Can you please add an item on the
neutron meeting agenda today so we can discuss this? I'd like to talk
this through with the team to understand how we as a community want to
move forward here. Since we will have closed the IPV6 gap in Juno once
the stateful/stateless patches merge, we should be requiring all
plugins to support IPV6 and not skip these tests.

Thanks,
Kyle

Sean M. Collins

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

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

2014-08-25 Thread Jay Pipes


On 08/25/2014 11:10 AM, Joe Cropper wrote:

Hello,

Is our long-term vision to allow a VMs to be dynamically added/removed
from a group?  That is, unless I'm overlooking something, it appears
that you can only add a VM to a server group at VM boot time and
effectively remove it by deleting the VM?

Just curious if this was a design point, or merely an approach at a
staged implementation [that might welcome some additions]?  :)


See here:

http://lists.openstack.org/pipermail/openstack-dev/2014-April/033746.html

If I had my druthers, I would revert the whole extension.

-jay

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

Re: [openstack-dev] [congress] policy summit

2014-08-25 Thread Kyle Mestery

On Sun, Aug 24, 2014 at 7:01 PM, Sean Roberts seanrobert...@gmail.com wrote:
 I am looking for policy overview/impact covering heat, neutron, nova, olso,
 mistral, and rubric. Are there any others that want to join us and discuss
 how policy impacts their project? I would welcome some discussion around
 Opendaylight policy as well.

 We have 21 people signed up to join us so far here
 https://www.eventbrite.com/e/openstack-policy-summit-tickets-12642081807. It
 will be much better to join us in person, but I will setup a remote, so Kyle
 and others that can join in. Go ahead and add yourself as remote to the
 event.

 Those people that have signed up, update the etherpad
 https://etherpad.openstack.org/p/juno-midcycle-policy-summit. The proposed
 agenda is Thursday covers various project policy overview and/or impacts.
 Friday covers various cross-project policy use cases including security.
 More information on the etherpad sooner, will allow us to pre-debate content
 and we will get a lot more out of the two days.

Thanks for setting up the remote access Sean, I know myself as well as
a few others won't be able to make it in person, so attending via some
remote method is a good fallback.

Kyle

 ~ sean


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


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

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report


On 25/08/14 05:21, Thierry Carrez wrote:

Zane Bitter wrote:

[...]
Here are a few of the conclusions:

* Everyone wishes the Design Summit worked like this.
The meetup seemed a lot more productive than the design summit ever is.
It's really nice to be in a room small enough that you can talk normally
and hear everyone, instead of in a room designed for 150 people. It's
really nice to be able to discuss stuff that isn't related to a
particular feature - we had a long discussion about how to get through
the review backlog, for example. It's really nice to not have fixed time
slots for discussions - because everyone was in the room the whole time,
we could dip in and out of different topics at will. Often we came back
to one that we'd previously discussed because we had discovered new
information. Finally, it's critical to be in a room covered in
full-sized whiteboards that everyone can see. A single tiny flip chart
doesn't cut it.


That's good feedback, thanks. The current discussion on design summit
format changes is a bit lost under a Nova thread, so I should revive it
as a separate thread very soon. The idea being to implement whatever
changes we can to the summit to make it more productive (in the limited
remaining time and options we have for that).


Yeah, I have been following that thread too. It's a hard problem, 
because obviously the ability to talk to developers from other projects 
and users at the design summit is _also_ valuable... we need to find a 
way to somehow make both happen, preferably without making everyone 
travel 4 times a year or for more than a week at a time.



[...]
* Marc^W Zaqar is critical to pretty much every major non-Convergence
feature on the roadmap.
We knew that we wanted to use it for notifications, but we also want to
make those a replacement for events, and a conduit for warnings and
debugging information to the user. This is becoming so important that
we're going to push ahead with an implementation now without waiting to
see when Zaqar will graduate. Zaqar would also be a good candidate for
pushing metadata changes to servers, to resolve the performance issues
currently caused by polling.


Could you expand on that ? Do you need some kind of user-facing queue
service, or is there something in the marc^WZaqar approach that makes it
especially appealing ?


Basically we just need a user-facing queue service. The key drivers are 
the need for:

1) an asynchronous way of talking back to the user
2) a central service optimised for polling by the user, so that other 
services (like Heat) can move to a push model
3) a way of passing notifications between OpenStack services that the 
user can intercept and process if they choose (e.g. we already use 
user-defined webhooks to communicate from Ceilometer to autoscaling in 
Heat so that users can interpose their own alarm conditioning, but this 
has authentication issues and the potential to turn Ceilometer into a 
DOS engine)


Zaqar is a more-than-adequate-seeming implementation of those 
requirements that is already incubated.


Ideally it will also support SNS-style push notifications to the user, 
but that's more the user's problem than Heat's ;) We just want people to 
stop polling us, because it's killing our performance.


cheers,
Zane.

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

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

Thanks Jay.  Those are the same types of questions I was pondering as
well when debating how someone might use this.  I think what we have
is fine for a first pass, but that's what I was poking at... whether
some of the abilities to add/remove members dynamically could exist
(e.g., I no longer want this VM to have an anti-affinity policy
relative to the others, etc.).

- Joe

On Mon, Aug 25, 2014 at 10:16 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/25/2014 11:10 AM, Joe Cropper wrote:

 Hello,

 Is our long-term vision to allow a VMs to be dynamically added/removed
 from a group?  That is, unless I'm overlooking something, it appears
 that you can only add a VM to a server group at VM boot time and
 effectively remove it by deleting the VM?

 Just curious if this was a design point, or merely an approach at a
 staged implementation [that might welcome some additions]?  :)


 See here:

 http://lists.openstack.org/pipermail/openstack-dev/2014-April/033746.html

 If I had my druthers, I would revert the whole extension.

 -jay

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

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

Re: [openstack-dev] [designate] [neutron] designate and neutron integration

2014-08-25 Thread Hayes, Graham

We don't actually envisage a bind9 views solution in the near future.

I would imagine (this has not yet been discussed) that we would have
service VMs (one per network / tenant) connected to the neutron network,
and a control network (like how Trove are doing the neutron
integration).

Designate would then manage that server as if it is in its own pool.

We would need to find a way for neutrons dnsmasq to pass certain queries
to the designate controlled server, but that should not be an issue
(AFAIK it can be done with a few lines in the dnsmasq config).


On Mon, 2014-08-25 at 08:59 +, Zang MingJie wrote:
 I don't like the idea that uses bind9 views to split networks, due to
 follow reasons:
 
 the designate may not or hard to know the router's public address
 non-router may exist for some isolate networks
 there is no routes in our dhcp namespace currently
 
 I suggest run one bind9 instance for each network which has domain
 support, and introduce a designate-bind9-agent to control the bind9
 instances.
 
 +--+--+- network
 |  |  |
 +-++-++-+
 |instance || dnsmasq ||  bind9  |
 +-++-++-+ 
 
|  |
+--+   +-+
|dhcp agent|   |dns agent|
+--+   +-+
 
 On Tue, Aug 12, 2014 at 1:41 AM, Hayes, Graham graham.ha...@hp.com
 wrote:
 
  kazuhiro MIYASHITA,
 
  As designate progresses with server pools, we aim to have support
 for a
  'private' dns server, that could run within a neutron network - is
 that
  the level of integration you were referring to?
 
  That is, for the time being, a long term goal, and not covered by
 Carl's
  Kilo blueprint.
 
  We talked with both people from both Neutron and Nova in Atlanta,
 and
  worked out the first steps for designate / neutron integration (auto
  provisioning of records)
 
  For that level of integration, we are assuming that a neutron router
  will be involved in DNS queries within a network.
 
  Long term I would prefer to see a 'private pool' connecting directly
 to
  the Network2 (like any other service VM (LBaaS etc)) and have
 dnsmasq
  pass on only records hosted by that 'private pool' to designate.
 
  This is all yet to be fleshed out, so I am open to suggestions. It
  requires that we complete server pools, and that work is only just
  starting (it was the main focus of our mid-cycle 2 weeks ago).
 
  Graham
 
  On Mon, 2014-08-11 at 11:02 -0600, Carl Baldwin wrote:
   kazuhiro MIYASHITA,
  
   I have done a lot of thinking about this.  I have a blueprint on
 hold
   until Kilo for Neutron/Designate integration [1].
  
   However, my blueprint doesn't quite address what you are going
 after
   here.  An assumption that I have made is that Designate is an
 external
   or internet facing service so a Neutron router needs to be in the
   datapath to carry requests from dnsmasq to an external network.
  The
   advantage of this is that it is how Neutron works today so there
 is no
   new development needed.
  
   Could you elaborate on the advantages of connecting dnsmasq
 directly
   to the external network where Designate will be available?
  
   Carl
  
   [1] https://review.openstack.org/#/c/88624/
  
   On Mon, Aug 11, 2014 at 7:51 AM, Miyashita, Kazuhiro
   miy...@jp.fujitsu.com wrote:
Hi,
   
I want to ask about neutron and designate integration.
I think dnsmasq fowards DNS request from instance to designate
 is better.
   
   ++
   |DNS server(designate)   |
   ++
|
-+--+-- Network1
 |
  ++
  |dnsmasq |
  ++
|
-+--+-- Network2
 |
+-+
|instance |
+-+
   
Because it's simpler than virtual router connects Network1 and
 Network2.
If router connects network, instance should know where DNS
 server is. it is complicated.
dnsmasq returns its ip address as dns server in DHCP replay by
 ordinary, so,
I think good dnsmasq becomes like a gateway to designate.
   
But, I can't connect dnsmasq to Network1. because of today's
 neutron design.
   
Question:
  Does designate design team have a plan such as above
 integration?
  or other integration design?
   
*1: Network1 and Network2 are deployed by neutron.
*2: neutron deploys dnsmasq as a dhcp server.
dnsmasq can forward DNS request.
   
Thanks,
   
kazuhiro MIYASHITA
   
   
   
   
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs


On 22/08/14 21:02, Anne Gentle wrote:

I'm with Rocky on the anti-czar-as-a-word camp. We all like clever names to
shed the corporate stigma but this word ain't it. Liaison or lead?


+1. The only time you hear the word 'czar' in regular life (outside of 
references to pre-revolutionary Russia) it means that the government is 
looking for a cheap PR win that doesn't require actually doing/changing 
anything.


Liaison or Contact would be fine choices IMHO.

cheers,
Zane.

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

Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

2014-08-25 Thread Vladimir Kuklin

I would also like to add that you can use our library called devops along
with system tests we use for QA and CI. These tests use libvirt and kvm so
that you can easily fire up an environment with specific configuration
(Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation
how to use this library is here:
http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps
in documentation, please feel free to file bugs to
https://launchpad.net/fuel.


On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com
wrote:

 Hi all,
 along with building your own ISO following instructions [1], you can
 always download nightly build [2] and run it, by using virtualbox scripts
 [3], for example.

 For your conveniency, you can see a build status table on CI [4]. First
 tab now refers to pre-5.1 builds, and second - to master builds.
 BVT columns stands for Build Verification Test, which is essentially full
 HA deploy deployment test.

 Currently pre-5.1 and master builds are actually built from same master
 branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be
 reconfigured to use stable/5.1 branch.

 Thanks,

 [1]
 http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
 [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds
 [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox
 [4] https://fuel-jenkins.mirantis.com/view/ISO/
 --
 Igor Shishkin
 DevOps




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 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
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com http://www.mirantis.ru/
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

2014-08-25 Thread Timur Nurlygayanov

When I started the build of ISO from master branch, I can see the following
errors:
https://bugs.launchpad.net/fuel/+bug/1361279

I want to submit the patch set and remove all hardcoded requirements and
change all '==' to '=', but I want to discuss how we can organize specs to
avoid problems with dependencies before this.

Thank you.


On Mon, Aug 25, 2014 at 6:21 PM, Timur Nurlygayanov 
tnurlygaya...@mirantis.com wrote:

 Hi team,

 Today I started to build Fuel ISO from the master branch and with packages
 with code from the master branches, and have found strange errors:

 http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/77/console

 Looks like we have hardcoded versions of all required packages in specs:

 https://github.com/stackforge/fuel-main/blob/master/packages/rpm/specs/nailgun.spec#L17-L44

 and this is the root of problems. In the result we can't build ISO from
 master branch, because we have another versions of requirements for code
 from master branches.
 Looks like it is common issue for several components.

 Could we discuss how we can organize specs to avoid problems with
 dependencies?


 Thank you!


 --

 Timur,
 QA Engineer
 OpenStack Projects
 Mirantis Inc

 [image: http://www.openstacksv.com/] http://www.openstacksv.com/




-- 

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc

[image: http://www.openstacksv.com/] http://www.openstacksv.com/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

2014-08-25 Thread Jay Pipes


On 08/25/2014 11:31 AM, Joe Cropper wrote:

Thanks Jay.  Those are the same types of questions I was pondering as
well when debating how someone might use this.  I think what we have
is fine for a first pass, but that's what I was poking at... whether
some of the abilities to add/remove members dynamically could exist
(e.g., I no longer want this VM to have an anti-affinity policy
relative to the others, etc.).


I guess what I was getting at is that I think the whole interface is 
flawed and it's not worth putting in the effort to make it slightly less 
flawed.


Best,
-jay


- Joe

On Mon, Aug 25, 2014 at 10:16 AM, Jay Pipes jaypi...@gmail.com wrote:

On 08/25/2014 11:10 AM, Joe Cropper wrote:


Hello,

Is our long-term vision to allow a VMs to be dynamically added/removed
from a group?  That is, unless I'm overlooking something, it appears
that you can only add a VM to a server group at VM boot time and
effectively remove it by deleting the VM?

Just curious if this was a design point, or merely an approach at a
staged implementation [that might welcome some additions]?  :)



See here:

http://lists.openstack.org/pipermail/openstack-dev/2014-April/033746.html

If I had my druthers, I would revert the whole extension.

-jay

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


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




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

[openstack-dev] What does NASA not using OpenStack mean to OS's future

http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] removing single mode

2014-08-25 Thread Andrew Woodward

Started a new thread so that we don't hijack the older thread.
 as


 Andrew, will you work on it in 6.0? What are remaining items there? Also,
 it might affect our tests - simple mode runs faster so we use it for smoke
 ISO test. Anastasia, please confirm that we can switch smoke to
 one-ha-controller model, or even drop smoke at all and use BVT only
 (running CentOS 3 HA controllers and same with Ubuntu).


The primary reason that we haven't disabled single yet is was due to [0]
where we where having problems adding additional controllers. With the
changes to galera and rabbit clustering it appears that we ended up fixing
it already.

The remaining issues are:
1) Ensuring we have good test coverage for the cases we expect to support
[1]
2) Removing simple mode from the ui and tests
3) Removing simple mode support from nailgun (maybe we leave it) and cli
4) Updating documentation

[0] https://bugs.launchpad.net/fuel/+bug/1350266
[1] https://bugs.launchpad.net/fuel/+bug/1350266/comments/7

-- 
Andrew
Mirantis
Ceph community
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Enable SSL between client and API exposed via public URL with HAProxy

2014-08-25 Thread Andrew Woodward

Mike,

I've started a separate thread titled 'removing single mode' so that we
don't thread jack the ssl conversation.



On Thu, Aug 21, 2014 at 12:27 PM, David Easter deas...@mirantis.com wrote:

 Hi Adam,

  Just to clarify the subtlety of this change - you can still install a
 single controller, but that controller will be “HA-ready” by deploying all
 the projects needed for HA onto that controller.  In other words, Fuel will
 still be able to support smaller deployments along side larger ones for
 those who only need one controller and a few compute nodes.

   This also enables an environment to grow overtime without redeployment.
  Since everything is in place for HA, adding another controller just
 extends that HA (and removes the single-controller single-point-of-failure).

 - David J. Easter
   Director of Product Management,   Mirantis, Inc.

 http://openstacksv.com/

 From: Adam Lawson alaw...@aqorn.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Thursday, August 21, 2014 at 12:11 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Fuel] Enable SSL between client and API
 exposed via public URL with HAProxy

 IMHO, removing non-HA mode in Fuel would be a mistake as Fuel is also used
 for smaller deployments. HA is required for Production sure but removing
 support for smaller deployments would drive consumers of smaller clouds
 elsewhere for orchestration. Maintaining support for smaller clouds
 probably isn't a priority for Mirantis but I think it should be a priority
 for the general community consumer base. This also goes for all of the
 orchestrators out there whether it's SUSE, Juju, Piston, Nebulous, etc etc.

 Just my two cents.


 *Adam Lawson*
 AQORN, Inc.
 427 North Tatnall Street
 Ste. 58461
 Wilmington, Delaware 19801-2230
 Toll-free: (844) 4-AQORN-NOW ext. 101
 International: +1 302-387-4660
 Direct: +1 916-246-2072



 On Thu, Aug 21, 2014 at 7:24 AM, Guillaume Thouvenin thouv...@gmail.com
 wrote:


 On Thu, Aug 21, 2014 at 5:02 PM, Mike Scherbakov 
 mscherba...@mirantis.com wrote:



 Guillaume, do I understand right that without implementation of
 https://blueprints.launchpad.net/fuel/+spec/ca-deployment, SSL support
 will not be fully automated? And, consequently, we can not call it as
 complete production ready feature for Fuel users?


 Yes you are right.  Without the implementation of the CA deployment  we
 can not consider it as ready to use.
 To test my deployment I manually copy a self-signed certificate on all
 controllers on a predefined location according to what I have in the puppet
 manifest. So it's really just for testing. I also write a small puppet
 manifest to generate a self signed certificate to deploy it automatically
 but it works only for one controller so this solution is also only for
 testing.

 So to have the feature ready for production we need to manage certificate
 maybe as a new option into the fuel dashboard.

 Best Regards,
 Guillaume

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


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

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




-- 
Andrew
Mirantis
Ceph community
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Steve Martinelli

This is hardly a development related question.


Regards,

Steve Martinelli
Software Developer - OpenStack
Keystone Core Member





Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com

8200 Warden Ave
Markham, ON L6G 1C7
Canada


Aryeh Friedman aryeh.fried...@gmail.com wrote
on 08/25/2014 12:08:50 PM:

 From: Aryeh Friedman aryeh.fried...@gmail.com
 To: OpenStack Development Mailing List
(not for usage questions) 
 openstack-dev@lists.openstack.org, 
 Date: 08/25/2014 12:12 PM
 Subject: [openstack-dev] What does NASA not using
OpenStack mean to 
 OS's future
 
 http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-
 leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead
 
 -- 
 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [Fuel] removing single mode

2014-08-25 Thread Mike Scherbakov

Thanks, Andrew.

I think it's worth to track as a normal feature with formal fuel-specs, as
it touches too many things (docs and a number of tests). Should be short
spec though.


On Mon, Aug 25, 2014 at 8:19 PM, Andrew Woodward xar...@gmail.com wrote:

 Started a new thread so that we don't hijack the older thread.
  as


 Andrew, will you work on it in 6.0? What are remaining items there? Also,
 it might affect our tests - simple mode runs faster so we use it for smoke
 ISO test. Anastasia, please confirm that we can switch smoke to
 one-ha-controller model, or even drop smoke at all and use BVT only
 (running CentOS 3 HA controllers and same with Ubuntu).


 The primary reason that we haven't disabled single yet is was due to [0]
 where we where having problems adding additional controllers. With the
 changes to galera and rabbit clustering it appears that we ended up fixing
 it already.

 The remaining issues are:
 1) Ensuring we have good test coverage for the cases we expect to support
 [1]
 2) Removing simple mode from the ui and tests
 3) Removing simple mode support from nailgun (maybe we leave it) and cli
 4) Updating documentation

 [0] https://bugs.launchpad.net/fuel/+bug/1350266
 [1] https://bugs.launchpad.net/fuel/+bug/1350266/comments/7

 --
 Andrew
 Mirantis
 Ceph community

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




-- 
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

2014-08-25 Thread Timur Nurlygayanov

Commit with fast fix was submitted: https://review.openstack.org/#/c/116667/
Need review :)

I will try to build image with this commit and will send my comments with
my results.


On Mon, Aug 25, 2014 at 7:55 PM, Timur Nurlygayanov 
tnurlygaya...@mirantis.com wrote:

 When I started the build of ISO from master branch, I can see the
 following errors:
 https://bugs.launchpad.net/fuel/+bug/1361279

 I want to submit the patch set and remove all hardcoded requirements and
 change all '==' to '=', but I want to discuss how we can organize specs to
 avoid problems with dependencies before this.

 Thank you.


 On Mon, Aug 25, 2014 at 6:21 PM, Timur Nurlygayanov 
 tnurlygaya...@mirantis.com wrote:

 Hi team,

 Today I started to build Fuel ISO from the master branch and with
 packages with code from the master branches, and have found strange errors:

 http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/77/console

 Looks like we have hardcoded versions of all required packages in specs:

 https://github.com/stackforge/fuel-main/blob/master/packages/rpm/specs/nailgun.spec#L17-L44

 and this is the root of problems. In the result we can't build ISO from
 master branch, because we have another versions of requirements for code
 from master branches.
 Looks like it is common issue for several components.

 Could we discuss how we can organize specs to avoid problems with
 dependencies?


 Thank you!


 --

 Timur,
 QA Engineer
 OpenStack Projects
 Mirantis Inc

 [image: http://www.openstacksv.com/] http://www.openstacksv.com/




 --

 Timur,
 QA Engineer
 OpenStack Projects
 Mirantis Inc

 [image: http://www.openstacksv.com/] http://www.openstacksv.com/




-- 

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc

[image: http://www.openstacksv.com/] http://www.openstacksv.com/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Jay Pipes


On 08/25/2014 12:08 PM, Aryeh Friedman wrote:

http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead


Would you mind please not posting to the developer's mailing list 
inflammatory random web pages?


Thanks,
-jay


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

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Anita Kuno

On 08/25/2014 12:29 PM, Jay Pipes wrote:
 On 08/25/2014 12:08 PM, Aryeh Friedman wrote:
 http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead

 
 Would you mind please not posting to the developer's mailing list
 inflammatory random web pages?
 
 Thanks,
 -jay
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
As well, please keep in mind that OS means operating system. It is not
an acronym for OpenStack.

Readers who don't know the difference will believe your usage is correct
and follow your incorrect example.

Thank you,
Anita.

http://lists.openstack.org/pipermail/openstack-dev/2014-August/043159.html

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

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

2014-08-25 Thread Edgar Magana

Dane,

I will second Kyle's idea. Let's discuss this during today IRC meeting if
Kevin's suggestion does not work for you.

Thanks,

Edgar

On 8/25/14, 10:08 AM, Kyle Mestery mest...@mestery.com wrote:

Dane, thanks for all the great work you're doing in the third-party CI
area. It's great to see you working to share this knowledge with
others as well!

Did Kevin's idea work for you to move past this issue? If not, I
suggest you put an item on the neutron meeting agenda today and we
cover this there. You could put the item on the third-party meeting
agenda as well.

Thanks!
Kyle

On Sun, Aug 24, 2014 at 9:43 AM, Dane Leblanc (leblancd)
lebla...@cisco.com wrote:
 Hi Kevin:



 Thanks, this is a great idea! I may try just a slight variation of this
 concept. Maybe your idea could be the recommended way to create a 3rd
party
 CI for plugins that are just being introduced and need to limit the
scope of
 testing to a small set of plugin-related commits (or plugins blocked on
a
 certain fix).



 Thanks,
 Dane



 From: Kevin Benton [mailto:blak...@gmail.com]
 Sent: Saturday, August 23, 2014 5:47 AM


 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
required
 to be run



 Can you disable posting of results directly from your Jenkins/Zuul
setup and
 have a script that just checks the log file for special markers to
determine
 if the vote should be FAILED/PASSED/SKIPPED? Another advantage of this
 approach is that it gives you an opportunity to detect when a job just
 failed to setup due to infrastructure reasons and trigger a recheck
without
 ever first posting a failure to gerrit.



 On Fri, Aug 22, 2014 at 3:06 PM, Dane Leblanc (leblancd)
 lebla...@cisco.com wrote:

 Thanks Edgar for updating the APIC status!!!

 Edgar and Kyle: *PLEASE NOTE**  I need your understanding
and
 advice on the following:

 We are still stuck with a problem stemming from a design limitation of
 Jenkins that prevents us from being compliant with Neutron 3rd Party CI
 requirements for our DFA CI.

 The issue is that Jenkins only allows our scripts to (programmatically)
 return either Success or Fail. There is no option to return Aborted,
Not
 Tested, or Skipped.

 Why does this matter? The DFA plugin is just being introduced, and
initial
 DFA-enabling change sets have not yet been merged. Therefore, all other
 change sets will fail our Tempest tests, since they are not DFA-enabled.

 Similarly, we were recently blocked in our APIC CI with a critical bug,
 causing all change sets without this fix to fail on our APIC testbed.

 In these cases, we would like to enter a throttled or partially
blocked
 mode, where we would skip testing on change sets we know will fail, and
(in
 an ideal world) signal this shortcoming to Gerrit e.g. by returning a
 Skipped status. Unfortunately, this option is not available in Jenkins
 scripts, as Jenkins is currently designed. The only options we have
 available is Success or all Fail, which are both misleading. We
would
 also incorrectly report success or fail on one of the following test
 commits:
 https://review.openstack.org/#/c/114393/
 https://review.openstack.org/#/c/40296/

 I've brought this issue up on the openstack-infra IRC, and jeblair
confirmed
 the Jenkins limitation, but asked me to get consensus from the Neutron
 community as to this being a problem/requirement. I've also sent out an
 e-mail on the Neutron ML trying to start a discussion on this problem
(no
 traction). I plan on bringing this up in the 3rd Party CI IRC on Monday,
 assuming there is time permitted in the open discussion.

 I'm also investigating

 For the short term, I would like to propose the following:
 * We bring this up on the 3rd Party CI IRC on Monday to get a solution
or
 workaround, if available. If a solution is available, let's consider
 including that as a hint when we come up with CI requirements for
handling
 CIs bocked by some critical fix.
 * I'm also looking into using a REST API to cancel a Jenkins job
 programmatically.
 * If no solution or workaround is available, we work with infra team or
with
 Jenkins team to create a solution.
 * Until a solution is available, for plugins which are blocked by a
critical
 bug, we post a status/notes indicating the plugin's situation on our 3rd
 party CI status wiki, e.g.:

 Vendor  Plugin/Driver Name  Contact Name
 Status  Notes
 My Vendor Name  My Plugin CIMy Contact Person   T
 Throttled / Partially blocked / Awaiting Intial Commits

 The status/notes should be clear and understood by the Neutron team.
The
 console logs for change sets where the tests were skipped should also
 contain a message that all testing is being skipped for that commit.

 Note that when the DFA initial commits are merged, then this issue
would go
 away for the DFA CI. However, this problem will reappear every time a
 blocking critical bug shows up for a 3rd

Re: [openstack-dev] [Fuel] removing single mode

2014-08-25 Thread Evgeniy L

Hi Andrew,

I have some comments regarding to you action items

 2) Removing simple mode from the ui and tests
 3) Removing simple mode support from nailgun (maybe we leave it) and cli

We shouldn't do it, because nailgun should handle both versions of cluster.
What we have to do here is to use openstack.yaml to keep all possible modes.
For new release there will be only ha, to manage previous releases we have
to create data migrations in nailgun to create the filed with modes i.e.
multinode
and ha.

Also fixes for ui are required too, I think it mostly related to wizard,
'mode' tab
where use can chose ha or non ha cluster in case of new release there should
be only ha, and in case of old releases there should be ha and multinode.

Thanks,



On Mon, Aug 25, 2014 at 8:19 PM, Andrew Woodward xar...@gmail.com wrote:

 Started a new thread so that we don't hijack the older thread.
  as


 Andrew, will you work on it in 6.0? What are remaining items there? Also,
 it might affect our tests - simple mode runs faster so we use it for smoke
 ISO test. Anastasia, please confirm that we can switch smoke to
 one-ha-controller model, or even drop smoke at all and use BVT only
 (running CentOS 3 HA controllers and same with Ubuntu).


 The primary reason that we haven't disabled single yet is was due to [0]
 where we where having problems adding additional controllers. With the
 changes to galera and rabbit clustering it appears that we ended up fixing
 it already.

 The remaining issues are:
 1) Ensuring we have good test coverage for the cases we expect to support
 [1]
 2) Removing simple mode from the ui and tests
 3) Removing simple mode support from nailgun (maybe we leave it) and cli
 4) Updating documentation

 [0] https://bugs.launchpad.net/fuel/+bug/1350266
 [1] https://bugs.launchpad.net/fuel/+bug/1350266/comments/7

 --
 Andrew
 Mirantis
 Ceph community

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


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

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

1. Sorry wrong list
2. Your answers just confirm NASA was right


On Mon, Aug 25, 2014 at 12:22 PM, Steve Martinelli steve...@ca.ibm.com
wrote:

 This is hardly a development related question.


 Regards,

 *Steve Martinelli*
 Software Developer - OpenStack
 Keystone Core Member
 --
  *Phone:* 1-905-413-2851
 * E-mail:* *steve...@ca.ibm.com* steve...@ca.ibm.com
 8200 Warden Ave
 Markham, ON L6G 1C7
 Canada



 Aryeh Friedman aryeh.fried...@gmail.com wrote on 08/25/2014 12:08:50 PM:

  From: Aryeh Friedman aryeh.fried...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 08/25/2014 12:12 PM
  Subject: [openstack-dev] What does NASA not using OpenStack mean to
  OS's future
 
  http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-

  leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead
 
  --
  Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
 http://www.petitecloud.org/

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

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




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

That was indeed a rather long (and insightful) thread on the topic.
It sounds like there are still some healthy discussions worth having
on the subject -- either exploring your [potentially superseding]
proposal, or minimally rounding out the existing server group API to
support add existing VM [1] and remove VM -- I think these would
make it a lot more usable (I'm thinking of the poor cloud
administrator that makes a mistake when they boot an instance and
either forgets to put it in a group or puts it in the wrong group --
it's square 1 for them)?

Is this queued up as a discussion point for Paris?  If so, count me in!

Thanks,
Joe

On Mon, Aug 25, 2014 at 11:08 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/25/2014 11:31 AM, Joe Cropper wrote:

 Thanks Jay.  Those are the same types of questions I was pondering as
 well when debating how someone might use this.  I think what we have
 is fine for a first pass, but that's what I was poking at... whether
 some of the abilities to add/remove members dynamically could exist
 (e.g., I no longer want this VM to have an anti-affinity policy
 relative to the others, etc.).


 I guess what I was getting at is that I think the whole interface is flawed
 and it's not worth putting in the effort to make it slightly less flawed.

 Best,
 -jay


 - Joe

 On Mon, Aug 25, 2014 at 10:16 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/25/2014 11:10 AM, Joe Cropper wrote:


 Hello,

 Is our long-term vision to allow a VMs to be dynamically added/removed
 from a group?  That is, unless I'm overlooking something, it appears
 that you can only add a VM to a server group at VM boot time and
 effectively remove it by deleting the VM?

 Just curious if this was a design point, or merely an approach at a
 staged implementation [that might welcome some additions]?  :)



 See here:

 http://lists.openstack.org/pipermail/openstack-dev/2014-April/033746.html

 If I had my druthers, I would revert the whole extension.

 -jay

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


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



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

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

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

2014-08-25 Thread Dane Leblanc (leblancd)

Edgar, Kyle:

Kevin's suggestion should work for me (still hashing out the implementation).  
I've added an item to the 3rd Party IRC agenda anyway to discuss this corner 
case.

Thanks!
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com] 
Sent: Monday, August 25, 2014 12:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Dane,

I will second Kyle's idea. Let's discuss this during today IRC meeting if 
Kevin's suggestion does not work for you.

Thanks,

Edgar

On 8/25/14, 10:08 AM, Kyle Mestery mest...@mestery.com wrote:

Dane, thanks for all the great work you're doing in the third-party CI 
area. It's great to see you working to share this knowledge with others 
as well!

Did Kevin's idea work for you to move past this issue? If not, I 
suggest you put an item on the neutron meeting agenda today and we 
cover this there. You could put the item on the third-party meeting 
agenda as well.

Thanks!
Kyle

On Sun, Aug 24, 2014 at 9:43 AM, Dane Leblanc (leblancd) 
lebla...@cisco.com wrote:
 Hi Kevin:



 Thanks, this is a great idea! I may try just a slight variation of 
this  concept. Maybe your idea could be the recommended way to create 
a 3rd party  CI for plugins that are just being introduced and need to 
limit the scope of  testing to a small set of plugin-related commits 
(or plugins blocked on a  certain fix).



 Thanks,
 Dane



 From: Kevin Benton [mailto:blak...@gmail.com]
 Sent: Saturday, August 23, 2014 5:47 AM


 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron] [third-party] What tests are 
required  to be run



 Can you disable posting of results directly from your Jenkins/Zuul 
setup and  have a script that just checks the log file for special 
markers to determine  if the vote should be FAILED/PASSED/SKIPPED? 
Another advantage of this  approach is that it gives you an 
opportunity to detect when a job just  failed to setup due to 
infrastructure reasons and trigger a recheck without  ever first 
posting a failure to gerrit.



 On Fri, Aug 22, 2014 at 3:06 PM, Dane Leblanc (leblancd) 
 lebla...@cisco.com wrote:

 Thanks Edgar for updating the APIC status!!!

 Edgar and Kyle: *PLEASE NOTE**  I need your understanding 
and  advice on the following:

 We are still stuck with a problem stemming from a design limitation 
 of Jenkins that prevents us from being compliant with Neutron 3rd 
 Party CI requirements for our DFA CI.

 The issue is that Jenkins only allows our scripts to 
(programmatically)  return either Success or Fail. There is no option 
to return Aborted, Not  Tested, or Skipped.

 Why does this matter? The DFA plugin is just being introduced, and 
initial  DFA-enabling change sets have not yet been merged. Therefore, 
all other  change sets will fail our Tempest tests, since they are not 
DFA-enabled.

 Similarly, we were recently blocked in our APIC CI with a critical 
 bug, causing all change sets without this fix to fail on our APIC testbed.

 In these cases, we would like to enter a throttled or partially 
blocked
 mode, where we would skip testing on change sets we know will fail, 
and (in  an ideal world) signal this shortcoming to Gerrit e.g. by 
returning a  Skipped status. Unfortunately, this option is not 
available in Jenkins  scripts, as Jenkins is currently designed. The 
only options we have  available is Success or all Fail, which are 
both misleading. We would  also incorrectly report success or fail on 
one of the following test
 commits:
 https://review.openstack.org/#/c/114393/
 https://review.openstack.org/#/c/40296/

 I've brought this issue up on the openstack-infra IRC, and jeblair 
confirmed  the Jenkins limitation, but asked me to get consensus from 
the Neutron  community as to this being a problem/requirement. I've 
also sent out an  e-mail on the Neutron ML trying to start a 
discussion on this problem (no  traction). I plan on bringing this up 
in the 3rd Party CI IRC on Monday,  assuming there is time permitted 
in the open discussion.

 I'm also investigating

 For the short term, I would like to propose the following:
 * We bring this up on the 3rd Party CI IRC on Monday to get a 
solution or  workaround, if available. If a solution is available, 
let's consider  including that as a hint when we come up with CI 
requirements for handling  CIs bocked by some critical fix.
 * I'm also looking into using a REST API to cancel a Jenkins job  
programmatically.
 * If no solution or workaround is available, we work with infra team 
or with  Jenkins team to create a solution.
 * Until a solution is available, for plugins which are blocked by a 
critical  bug, we post a status/notes indicating the plugin's 
situation on our 3rd  party CI status wiki, e.g.:

 Vendor  Plugin/Driver Name  Contact Name
 Status  Notes
 My Vendor Name

[openstack-dev] [mistral] Team meeting minutes/log - 08/25/2014

2014-08-25 Thread Renat Akhmerov

Thanks for joining our community meeting today!

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-08-25-16.00.html
Meeting log: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-08-25-16.00.log.html

The next meeting will be on Sept 1st at the same time.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

2014-08-25 Thread Russell Bryant

On 08/25/2014 12:56 PM, Joe Cropper wrote:
 That was indeed a rather long (and insightful) thread on the topic.
 It sounds like there are still some healthy discussions worth having
 on the subject -- either exploring your [potentially superseding]
 proposal, or minimally rounding out the existing server group API to
 support add existing VM [1] and remove VM -- I think these would
 make it a lot more usable (I'm thinking of the poor cloud
 administrator that makes a mistake when they boot an instance and
 either forgets to put it in a group or puts it in the wrong group --
 it's square 1 for them)?
 
 Is this queued up as a discussion point for Paris?  If so, count me in!

Adding a VM is far from trivial and is why we ripped it out before
merging.  That implies a potential reshuffling of a bunch of existing
VMs.  Consider an affinity group of instances A and B and then you add
running instance C to that group.  What do you expect to happen?  Live
migrate C to the host running A and B?  What if there isn't room?
Reschedule all 3 to find a host and live migrate all of them?  This kind
of orchestration is a good bit outside of the scope of what's done
inside of Nova today.

-- 
Russell Bryant

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

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

I was thinking something simple such as only allowing the add operation to 
succeed IFF no policies are found to be in violation... and then nova wouldn't 
need to get into all the complexities you mention?

And remove would be fairly straightforward as well since no constraints would 
need to be checked. 

Thoughts?

Thanks,
Joe

 On Aug 25, 2014, at 12:10 PM, Russell Bryant rbry...@redhat.com wrote:
 
 On 08/25/2014 12:56 PM, Joe Cropper wrote:
 That was indeed a rather long (and insightful) thread on the topic.
 It sounds like there are still some healthy discussions worth having
 on the subject -- either exploring your [potentially superseding]
 proposal, or minimally rounding out the existing server group API to
 support add existing VM [1] and remove VM -- I think these would
 make it a lot more usable (I'm thinking of the poor cloud
 administrator that makes a mistake when they boot an instance and
 either forgets to put it in a group or puts it in the wrong group --
 it's square 1 for them)?
 
 Is this queued up as a discussion point for Paris?  If so, count me in!
 
 Adding a VM is far from trivial and is why we ripped it out before
 merging.  That implies a potential reshuffling of a bunch of existing
 VMs.  Consider an affinity group of instances A and B and then you add
 running instance C to that group.  What do you expect to happen?  Live
 migrate C to the host running A and B?  What if there isn't room?
 Reschedule all 3 to find a host and live migrate all of them?  This kind
 of orchestration is a good bit outside of the scope of what's done
 inside of Nova today.
 
 -- 
 Russell Bryant
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Endre Karlson

1. If you're wanting to start a fire you need to somewhere else then a
development mailing list.
2. Get your facts together, much of what you're writing on Quota as many
has pointed out is totally wrong.

Also what Anita noted earlier about OS != OpenStack in that sense.

Please keep topics like this off the ML.

Regards
Endre



2014-08-25 18:48 GMT+02:00 Aryeh Friedman aryeh.fried...@gmail.com:

 1. Sorry wrong list
 2. Your answers just confirm NASA was right


 On Mon, Aug 25, 2014 at 12:22 PM, Steve Martinelli steve...@ca.ibm.com
 wrote:

 This is hardly a development related question.


 Regards,

 *Steve Martinelli*
 Software Developer - OpenStack
 Keystone Core Member
 --
  *Phone:* 1-905-413-2851
 * E-mail:* *steve...@ca.ibm.com* steve...@ca.ibm.com
 8200 Warden Ave
 Markham, ON L6G 1C7
 Canada



 Aryeh Friedman aryeh.fried...@gmail.com wrote on 08/25/2014 12:08:50
 PM:

  From: Aryeh Friedman aryeh.fried...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 08/25/2014 12:12 PM
  Subject: [openstack-dev] What does NASA not using OpenStack mean to
  OS's future
 
  http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-

  leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead
 
  --
  Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
 http://www.petitecloud.org/

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

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




 --
 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

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


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

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

Do you call Martin Meckos having no clue... he is the one that leveled the
second worse criticism after mine... or is Euclapytus not one the founding
members of OpenStack (after all many of the glance commands still use it's
name)


On Mon, Aug 25, 2014 at 1:30 PM, Endre Karlson endre.karl...@gmail.com
wrote:

 1. If you're wanting to start a fire you need to somewhere else then a
 development mailing list.
 2. Get your facts together, much of what you're writing on Quota as many
 has pointed out is totally wrong.

 Also what Anita noted earlier about OS != OpenStack in that sense.

 Please keep topics like this off the ML.

 Regards
 Endre



 2014-08-25 18:48 GMT+02:00 Aryeh Friedman aryeh.fried...@gmail.com:

 1. Sorry wrong list
 2. Your answers just confirm NASA was right


 On Mon, Aug 25, 2014 at 12:22 PM, Steve Martinelli steve...@ca.ibm.com
 wrote:

 This is hardly a development related question.


 Regards,

 *Steve Martinelli*
 Software Developer - OpenStack
 Keystone Core Member
 --
  *Phone:* 1-905-413-2851
 * E-mail:* *steve...@ca.ibm.com* steve...@ca.ibm.com
 8200 Warden Ave
 Markham, ON L6G 1C7
 Canada



 Aryeh Friedman aryeh.fried...@gmail.com wrote on 08/25/2014 12:08:50
 PM:

  From: Aryeh Friedman aryeh.fried...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 08/25/2014 12:12 PM
  Subject: [openstack-dev] What does NASA not using OpenStack mean to
  OS's future
 
  http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-

 
 leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead
 
  --
  Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
 http://www.petitecloud.org/

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

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




 --
 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

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



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




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

2014-08-25 Thread Subrahmanyam Ongole

Hi Sean

I will join the Neutron IRC, get the inputs and address them at the
earliest.

I like to know the requirements for J K release cycles and what other
open source reference plugins have done towards this. We need to ramp up
our resources on ipv6 support.

On Sun, Aug 24, 2014 at 12:18 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:

Hi,

The amount of tests that we are having to add skips to for the One
Convergence plugin has grown quite a bit lately.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

This is the only plugin that inherits from the NeutronDbPluginV2 class and
has completely disabled creating Subnets that have an ip_version of 6.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

I hate to single out this plugin. Before this development cycle, open
source plugins would allow the creation of Subnets with ip_version set to
6, and then have lots of bugs which would prevent any instances from
actually obtaining IPv6 addresses and routing. But we didn't have to
explicitly skip tests every time someone wanted to fix bugs - like the
following patch.

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

Also, I want to highlight some meeting minutes, where it was discussed
that in the K release, all plugins will be required to support IPv6. I hope
we can discuss this, build consensus, and ensure that the K release
requirement is reasonable.

http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

Sean M. Collins

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

Thanks
OSM
(Subrahmanyam Ongole)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

2014-08-25 Thread Russell Bryant

On 08/25/2014 01:25 PM, Joe Cropper wrote:
 I was thinking something simple such as only allowing the add operation to 
 succeed IFF no policies are found to be in violation... and then nova 
 wouldn't need to get into all the complexities you mention?

Even something like this is a lot more complicated than it sounds due to
the fact that several operations can be happening in parallel.  I think
we just need to draw a line for Nova that just doesn't include this
functionality.

 And remove would be fairly straightforward as well since no constraints would 
 need to be checked. 

Right, remove is straight forward, but seems a bit odd to have without
add.  I'm not sure there's much value to it.

-- 
Russell Bryant

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

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Ian Wells

On 25 August 2014 10:34, Aryeh Friedman aryeh.fried...@gmail.com wrote:

 Do you call Martin Meckos having no clue... he is the one that leveled the
 second worse criticism after mine... or is Euclapytus not one the founding
 members of OpenStack (after all many of the glance commands still use it's
 name)


You appear to be trolling, and throwing around amazingly easy-to-disprove
'factoids', in an inappropriate forum, in order to drum up support for your
own competing open source cloud platform.  Please stop.

Your time would be much better spent improving your platform rather than
coming up with frankly bizarre criticism of the competitors.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

If I was doing that then I would be promoting the platform by name (which I
am not). I was just pointing out in our own internal ananylis OS came
in dead last among all the open source IaaS/PaaS's (the current version of
mine is not #1 btw)


On Mon, Aug 25, 2014 at 2:03 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:

 On 25 August 2014 10:34, Aryeh Friedman aryeh.fried...@gmail.com wrote:

 Do you call Martin Meckos having no clue... he is the one that leveled
 the second worse criticism after mine... or is Euclapytus not one the
 founding members of OpenStack (after all many of the glance commands still
 use it's name)


 You appear to be trolling, and throwing around amazingly easy-to-disprove
 'factoids', in an inappropriate forum, in order to drum up support for your
 own competing open source cloud platform.  Please stop.

 Your time would be much better spent improving your platform rather than
 coming up with frankly bizarre criticism of the competitors.
 --
 Ian.

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




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Launchpad tracking of oslo projects


On Aug 22, 2014, at 5:59 AM, Thierry Carrez thie...@openstack.org wrote:

 TL;DR:
 Let's create an Oslo projectgroup in Launchpad to track work across all
 Oslo libraries. In library projects, let's use milestones connected to
 published versions rather than the common milestones.
 
 Long version:
 As we graduate more Oslo libraries (which is awesome), tracking Oslo
 work in Launchpad (bugs, milestones...) has become more difficult.
 
 There used to be only one Launchpad project (oslo, which covered the
 oslo incubator). It would loosely follow the integrated milestones
 (juno-1, juno-2...), get blueprints and bugs targeted to those, get tags
 pushed around those development milestones: same as the integrated
 projects, just with no source code tarball uploads.
 
 When oslo.messaging graduated, a specific Launchpad project was created
 to track work around it. It still had integrated development milestones
 -- only at the end it would publish a 1.4.0 release instead of a 2014.2
 one. That approach creates two problems. First, it's difficult to keep
 track of oslo work since it now spans two projects. Second, the
 release management logic of marking bugs Fix released at development
 milestones doesn't really apply (bugs should rather be marked released
 when a published version of the lib carries the fix). Git tags and
 Launchpad milestones no longer align, which creates a lot of confusion.
 
 Then as more libraries appeared, some of them piggybacked on the general
 oslo Launchpad project (generally adding tags to point to the specific
 library), and some others created their own project. More confusion ensues.
 
 Here is a proposal that we could use to solve that, until StoryBoard
 gets proper milestone support and Oslo is just migrated to it:
 
 1. Ask for an oslo project group in Launchpad
 
 This would solve the first issue, by allowing to see all oslo work on
 single pages (see examples at [1] or [2]). The trade-off here is that
 Launchpad projects can't be part of multiple project groups (and project
 groups can't belong to project groups). That means that Oslo projects
 will no longer be in the openstack Launchpad projectgroup. I think the
 benefits outweigh the drawbacks here: the openstack projectgroup is not
 very strict anyway so I don't think it's used in people workflows that much.
 
 2. Create one project per library, adopt tag-based milestones
 
 Each graduated library should get its own project (part of the oslo
 projectgroup). It should use the same series/cycles as everyone else
 (juno), but it should have milestones that match the alpha release
 tags, so that you can target work to it and mark them fix released
 when that means the fix is released. That would solve the issue of
 misaligned tags/milestones. The trade-off here is that you lose the
 common milestone rhythm (although I guess you can still align some
 alphas to the common development milestones). That sounds a small price
 to pay to better communicate which version has which fix.

We don’t necessarily decide the version numbers for all of the libraries in 
advance. I think we talked about this on IRC, and your suggestion was to use a 
“next” milestone and then rename it at the point of release. Am I remembering 
correctly?

 
 3. Rename oslo project to oslo-incubator
 
 Keep the Launchpad oslo project as-is, part of the same projectgroup,
 to cover oslo-incubator work. This can keep the common development
 milestones, since the incubator doesn't do releases anyway. However,
 it has to be renamed to oslo-incubator so that it doesn't conflict
 with the projectgroup namespace. Once it no longer contains graduated
 libs, that name makes much more sense anyway.
 
 
 This plan requires Launchpad admin assistance to create a projectgroup
 and rename a project, so I'd like to get approval on it before moving to
 ask them for help.
 
 Comments, thoughts ?
 
 [1] https://blueprints.launchpad.net/openstack
 [2] https://bugs.launchpad.net/openstack
 
 -- 
 Thierry Carrez (ttx)

This makes sense to me, so let’s move ahead with your plan.

It would be good if we had a script to automate some of the release processes 
now, and it seems like this change is going to make it easier to implement 
parts like marking all of the tickets as released and updating their milestone.

We do have launchpad projects for some of the other oslo libraries, we just 
haven’t been using them for release tracking:

https://launchpad.net/python-stevedore
https://launchpad.net/python-cliff
https://launchpad.net/taskflow
https://launchpad.net/pbr
https://launchpad.net/oslo.vmware

Doug

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


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

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective


On Aug 23, 2014, at 5:36 PM, Maru Newby ma...@redhat.com wrote:

 
 On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:
 
 On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote:
 On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com 
 wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 20/08/14 18:28, Salvatore Orlando wrote:
 Some comments inline.
 
 Salvatore
 
 On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com
 mailto:ihrac...@redhat.com wrote:
 
 Hi all,
 
 I've read the proposal for incubator as described at [1], and I
 have several comments/concerns/suggestions to this.
 
 Overall, the idea of giving some space for experimentation that
 does not alienate parts of community from Neutron is good. In that
 way, we may relax review rules and quicken turnaround for preview
 features without loosing control on those features too much.
 
 Though the way it's to be implemented leaves several concerns, as
 follows:
 
 1. From packaging perspective, having a separate repository and
 tarballs seems not optimal. As a packager, I would better deal with
 a single tarball instead of two. Meaning, it would be better to
 keep the code in the same tree.
 
 I know that we're afraid of shipping the code for which some users
 may expect the usual level of support and stability and
 compatibility. This can be solved by making it explicit that the
 incubated code is unsupported and used on your user's risk. 1) The
 experimental code wouldn't probably be installed unless explicitly
 requested, and 2) it would be put in a separate namespace (like
 'preview', 'experimental', or 'staging', as the call it in Linux
 kernel world [2]).
 
 This would facilitate keeping commit history instead of loosing it
 during graduation.
 
 Yes, I know that people don't like to be called experimental or
 preview or incubator... And maybe neutron-labs repo sounds more
 appealing than an 'experimental' subtree in the core project.
 Well, there are lots of EXPERIMENTAL features in Linux kernel that
 we actively use (for example, btrfs is still considered
 experimental by Linux kernel devs, while being exposed as a
 supported option to RHEL7 users), so I don't see how that naming
 concern is significant.
 
 
 I think this is the whole point of the discussion around the
 incubator and the reason for which, to the best of my knowledge,
 no proposal has been accepted yet.
 
 
 I wonder where discussion around the proposal is running. Is it public?
 
 The discussion started out privately as the incubation proposal was
 put together, but it's now on the mailing list, in person, and in IRC
 meetings. Lets keep the discussion going on list now.
 
 
 In the spirit of keeping the discussion going, I think we probably
 need to iterate in practice on this idea a little bit before we can
 crystallize on the policy and process for this new repo. Here are few
 ideas on how we can start this iteration:
 
 * Namespace for the new repo:
 Should this be in the neutron namespace, or a completely different
 namespace like neutron labs? Perhaps creating a separate namespace
 will help the packagers to avoid issues of conflicting package owners
 of the namespace.
 
 I don’t think there is a technical requirement to choose a new namespace.  
 Python supports sharing a namespace, and packaging can support this feature 
 (see: oslo.*).

If the point of the incubator is to signal to deployers that the code isn’t 
fully supported, you may want to use a different namespace for the 
python/system packages as well.

Doug

 
 
 * Dependency on Neutron (core) repository:
 We would need to sort this out so that we can get UTs to run and pass
 in the new repo. Can we set the dependency on Neutron milestone
 releases? We already publish tar balls for the milestone releases, but
 I am not sure we publish these as packages to pypi. If not could we
 start doing that? With this in place, the incubator would always lag
 the Neutron core by at the most one milestone release.
 
 Given that it is possible to specify a dependency as a branch/hash/tag in a 
 git repo [1], I’m not sure it’s worth figuring out how to target tarballs.  
 Master branch of the incubation repo could then target the master branch of 
 the Neutron repo and always be assured of being current, and then released 
 versions could target milestone tags or released versions.
 
 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git
 
 
 * Modules overlapping with the Neutron (core) repository:
 We could initially start with the features that required very little
 or no changes to the Neutron core, to avoid getting into the issue of
 blocking on changes to the Neutron (core) repository before progress
 can be made in the incubator.
 
 +1
 
 I agree that it would be in an incubated effort’s best interest to put off 
 doing invasive changes to the Neutron tree as long as possible to ensure 
 sufficient time to hash out the best

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

 Even something like this is a lot more complicated than it sounds due to
the fact that several operations can be happening in parallel.

That's fair, but I was thinking that the 'add existing' VM is fairly
close in behavior to 'add new' VM to the group, less of course any
parallel operations happening on the VM itself.

 I think we just need to draw a line for Nova that just doesn't include this
functionality.

If that's our general direction, no problem.  I'm just thinking about
this from a user's perspective; this would be very difficult for any
administrator to use in its current form because you essentially can't
make a mistake in the group management--any mistake results in you
having to essentially delete the VM and start over, which is a pretty
major usability issue IMO, at least in terms of most production
environments.

Don't get me wrong, I think server groups have a lot of interesting
use cases (I actually would really like to use them) in their current
form and I think as a starting point, this is great.  But I think
without some of these added flexibilities, I think it would be very
challenging for any IT administrator to use them--hence why I'm
exploring adding some additional functionality; I'm even happy to help
implement this, if we can get any type of concurrence on the subject.
:-)

- Joe

On Mon, Aug 25, 2014 at 12:58 PM, Russell Bryant rbry...@redhat.com wrote:
 On 08/25/2014 01:25 PM, Joe Cropper wrote:
 I was thinking something simple such as only allowing the add operation to 
 succeed IFF no policies are found to be in violation... and then nova 
 wouldn't need to get into all the complexities you mention?

 Even something like this is a lot more complicated than it sounds due to
 the fact that several operations can be happening in parallel.  I think
 we just need to draw a line for Nova that just doesn't include this
 functionality.

 And remove would be fairly straightforward as well since no constraints 
 would need to be checked.

 Right, remove is straight forward, but seems a bit odd to have without
 add.  I'm not sure there's much value to it.

 --
 Russell Bryant

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

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

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

2014-08-25 Thread Elizabeth K. Joseph

Hi everyone,

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

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs


On Aug 23, 2014, at 6:35 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Dolph Mathews's message of 2014-08-22 09:45:37 -0700:
 On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter zbit...@redhat.com wrote:
 
 On 22/08/14 11:19, Thierry Carrez wrote:
 
 Zane Bitter wrote:
 
 On 22/08/14 08:33, Thierry Carrez wrote:
 
 We also
 still need someone to have the final say in case of deadlocked issues.
 
 
 -1 we really don't.
 
 
 I know we disagree on that :)
 
 
 No problem, you and I work in different programs so we can both get our
 way ;)
 
 
 People say we don't have that many deadlocks in OpenStack for which the
 PTL ultimate power is needed, so we could get rid of them. I'd argue
 that the main reason we don't have that many deadlocks in OpenStack is
 precisely *because* we have a system to break them if they arise.
 
 
 s/that many/any/ IME and I think that threatening to break a deadlock by
 fiat is just as bad as actually doing it. And by 'bad' I mean
 community-poisoningly, trust-destroyingly bad.
 
 
 I guess I've been active in too many dysfunctional free and open source
 software projects -- I put a very high value on the ability to make a
 final decision. Not being able to make a decision is about as
 community-poisoning, and also results in inability to make any
 significant change or decision.
 
 
 I'm all for getting a final decision, but a 'final' decision that has been
 imposed from outside rather than internalised by the participants is...
 rarely final.
 
 
 The expectation of a PTL isn't to stomp around and make final decisions,
 it's to step in when necessary and help both sides find the best solution.
 To moderate.
 
 
 Have we had many instances where a project's community divided into
 two camps and dug in to the point where they actually needed active
 moderation? And in those cases, was the PTL not already on one side of
 said argument? I'd prefer specific examples here.
 
 
 I have yet to see a deadlock in Heat that wasn't resolved by better
 communication.
 
 
 Moderation == bettering communication. I'm under the impression that you
 and Thierry are agreeing here, just from opposite ends of the same spectrum.
 
 
 I agree as well. PTL is a servant of the community, as any good leader
 is. If the PTL feels they have to drop the hammer, or if an impass is
 reached where they are asked to, it is because they have failed to get
 everyone communicating effectively, not because that's their job.”

That’s certainly how I approach it. I consider myself responsible for helping 
the team coordinate and making sure we have everything covered. Sometimes that 
means asking for volunteers for a new task, and sometimes it means a gentle 
reminder of an previous commitment.

That said, some responsibilities of the PTL role are outward-facing. 
Potentially anyone on the team could pick up those duties, just as any of the 
inward-facing duties, but having a single initial point of contact is 
especially useful when the priorities of two teams need to be aligned for a 
period of time to work on a joint task.

Doug

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


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

Re: [openstack-dev] [heat] heat.conf.sample is not up to date


On Aug 24, 2014, at 12:30 PM, Ruslan Kamaldinov rkamaldi...@mirantis.com 
wrote:

 On Sun, Aug 24, 2014 at 11:10 AM, Mike Spreitzer mspre...@us.ibm.com wrote:
 What I really need to know is what to do when committing a change that
 really does require a change in the sample configuration file.  Of course I
 tried running generate_sample.sh, but `tox -epep8` still complains.  What is
 the right procedure to get a correct sample committed?  BTW, I am doing the
 following admittedly risky thing: I run DevStack, and make my changes in
 /opt/stack/heat/.
 
 Mike,
 
 It seems that you have oslo.messaging installed from master (default
 behavior of Devstack), while heat.sample.config is built for
 oslo.messaging v 1.3.1. As a quick workaround I'd suggest to downgrade
 oslo.messaging to 1.3.1 in pep8 virtual environment:
 $ cd /opt/stack/heat
 $ source .tox/pep8/bin/activate
 $ pip install oslo.messaging==1.3.1
 $ deactivate
 $ tox -e pep8 # should pass now
 
 I'd also like to know what would be the procedure to update sample
 config when new version of oslo.messaging is released? Maybe we should
 pin requirements to specific version of oslo library and update that
 requirement along with the sample config once new version is released?

Please do not pin Oslo library versions in your project. That will cause issues 
updating requirements across the project and make back-ports more difficult in 
the future. 

We have API compatibility requirements for Oslo libraries, but do not usually 
consider the configuration options to be part of the API. We do follow the 
normal configuration deprecation policy for options, but under that policy 
changes (additions, renames, and moves) are still allowed. We don’t add or 
change options lightly, but since those allowed changes will break the 
diff-based tests for sample files in projects using the libraries, the best 
solution is to generate the sample config file during packaging or a 
documentation build and *not* use it as part of gate testing.

Doug

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


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

Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes

2014-08-25 Thread Brandon Logan

Hi John,
Comments in-line

On Sun, 2014-08-24 at 16:37 +0300, John Schwarz wrote:
Hi,

With the ongoing development of LBaaS v2, support for v2 of LBaaS in
neutronclient is also being developed, as can be seen in [1].
The current implementation adds a new syntax for v2; Whereas the v1
syntax is 'neutron lb-object-command', the new v2 syntax is 'neutron
lbaas-object-command'.

We fear that this can lead to some level of confusion on the users'
side. Currently, nothing prevents a user from trying to create a v1 pool
and then trying to add v2 members. Of course the second command will
fail, but the error message will be a non-intuitive one.

This was discussed at the last weekly IRC meeting ([2]). Some bulletins:

1. As was discussed in the hackathon, there shouldn't be more than one
version active at any given time - either v1 or v2. Also, using the same
syntax for both v1 and v2 is not a good idea (db migration will be
difficult when both version share syntax). We believe this should also
be enforced in the server side.

I actually don't think a real decision was made at the hackathon for
this. I know we were originally going to do a shim layer to translate
v1 calls into v2 and v2 object model to v1 for v1 driver consumption. I
am, however, fine with that rule and it will make things much simpler.
There will definitely need to be code in the intiialization of both v1
and v2 plugins that check whether the other version has been
initialized, since we cannot guarantee an order in which
extensions/service plugins are loaded. This should be trivial to do
though.

2. Therefor, there should be some configuration to specifically enable
either version (not both) in case LBaaS is needed. In this case, the
other version is disabled (ie. a REST query for non-active version
should return a not activated error). Additionally, adding a
'lb-version' command to return the version currently active seems like a
good user-facing idea. We should see how this doesn't negatively effect
the db migration process (for example, allowing read-only commands for
both versions?)

A /version endpoint can be added for both v1 and v2 extensions and
service plugins. If it doesn't already exist, it would be nice if
neutron had an endpoint that would return the list of loaded extensions
and their versions.

3. Another decision that's needed to be made is the syntax for v2. As
mentioned, the current new syntax is 'neutron lbaas-object-command'
(against the old 'lb-object-action'), keeping in mind that once v1
is deprecated, a syntax like 'lbv2-object-action' would be probably
unwanted. Is 'lbaas-object-command' okay with everyone?

That is the reason we with with lbaas because lbv2 looks ugly and we'd
be stuck with it for the lifetime of v2, unless we did another migration
back to lb for it. Which seemed wrong to do, since then we'd have to
accept both lbv2 and lb commands, and then deprecate lbv2.

I assume this also means you are fine with the prefix in the API
resource of /lbaas as well then?

4. If we are going for different API between versions, appropriate
patches also need to be written for lbaas-related scripts and also
Tempest, and their maintainers should probably be notified.

Could you elaborate on this? I don't understand what you mean by
different API between version.

Are there any issues with one of the points raised above? Does anyone
see any other problems which we forgot to write down?

Thanks a lot,

John Schwarz, Yair Fried,
Redhat.

[1]: https://review.openstack.org/#/c/111475
[2]:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html

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

Re: [openstack-dev] [heat] heat.conf.sample is not up to date

2014-08-25 Thread Joe Gordon

On Aug 24, 2014 9:04 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:



 On Sunday, August 24, 2014, Anne Gentle a...@openstack.org wrote:

 I'm following this as well since I have the exact same problem in a
docstring patch for heat.


 Keystone saw an oddity with the new sample config generator (changing how
options are sorted and therefore changing the way the sample config is
rendered). This could be a similar / related issue.

 Most of the projects stopped gating on up-to-date sample config a few
reasons, the first is that with external library dependencies you never
know when / if something upstream will break the test run (e.g. New
Oslo.config or new keystonemiddleware).

 Now imagine that issue occurred and was blocking a gate-fixing bug
(happened at least a couple times).

 In short, making sample config being up-to-date to merge code causes a
lot if headaches.

 Different projects handle this differently. Nova doesn't have a sample
config in tree, keystone updates on a semi-regular basis (sometimes as part
of a patch, sometimes as a separate patch). Keystone team is looking at
adding a simple non-voting gate job (if infra doesn't mind) that will tell
us the config is out of date.

Nova dropped the file, in part because we didn't see the point of including
auto generated files in tree.


 While it is nice to always have an updated sample config, I think it is
not worth the breakage / issues it adds to the gate.

 It might make sense to standardize how we handle sample config files
across the projects or at least standardize on removing the gate block if
the config is out of date. I know it was floated earlier that there would
be a proposal bot job (like translations) for sample config files, but I
don't remember the specifics of why it wasn't well liked.

 --Morgan

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

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

Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes

2014-08-25 Thread Brandon Logan

Hi Clark,
From my understanding the keystone catalog will not contain endpoints
for neutron extensions. I could see it being allowed but since Neutron
can enable/disable extensions on a whim, there would need to be some
cross project communication between keystone and neutron. I'm sure
there are other issues that would arise from this too. Then again, I
could be wrong and this is already both solved for and allowed in
Keystone.

Regarding having two separate commands for each version; Since neutron
extensions don't have any kind of versioning built it, it would be tough
to do through the API at least. The client can make smart decisions
though and make it easier for a user. However, if lb-object-action
worked for both v1 and v2, and the user has no idea what Neutron has
loaded, I don't see that being a better user experience when they try to
do a v1 command when v2 has been loaded.

Thanks,
Brandon
On Sun, 2014-08-24 at 11:50 -0700, Clark Boylan wrote:
On Sun, Aug 24, 2014, at 06:37 AM, John Schwarz wrote:
Hi,

This was discussed at the last weekly IRC meeting ([2]). Some bulletins:

4. If we are going for different API between versions, appropriate
patches also need to be written for lbaas-related scripts and also
Tempest, and their maintainers should probably be notified.

Are there any issues with one of the points raised above? Does anyone
see any other problems which we forgot to write down?

Thanks a lot,

John Schwarz, Yair Fried,
Redhat.

[1]: https://review.openstack.org/#/c/111475
[2]:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html

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

As a user of both the neutron API and python-neutronclient it would be
much better to have the client use a common set of commands for both v1
and v2 where the specific version used is determined by the keystone
catalog or other overriding information. I don't want to have to
remember two different sets of commands with potentially two different
outputs. Client libraries exist so that users don't have to think about
this stuff.

This should prevent confusion as users will use a common version unless
they specifically provide an override of some sort.

Clark

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

Re: [openstack-dev] [all] Acceptable methods for establishing per-test-suite behaviors


On Aug 22, 2014, at 4:09 PM, James E. Blair cor...@inaugust.com wrote:

 Hi,
 
 One of the things we've wanted for a while in some projects is a
 completely separate database environment for each test when using MySQL.
 To that end, I wrote a MySQL schema fixture that is in use in nodepool:
 
 http://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/tests/__init__.py#n75
 
 While a per-test schema is more overhead than what you're asking about,
 it's sometimes very desirable and quite simple.

Yes, that would be a useful addition to oslo.db, too.

Doug

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


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

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Joshua Harlow

So to see if we can get something useful from this thread.

What was your internal analysis, can it be published? Even negative analysis is 
useful to make openstack better...

It'd be nice to have some details on what you found, what u didn't find, so 
that we can all improve...

After all that is what it's all about.

-Josh

On Aug 25, 2014, at 11:13 AM, Aryeh Friedman aryeh.fried...@gmail.com wrote:

 If I was doing that then I would be promoting the platform by name (which I 
 am not). I was just pointing out in our own internal ananylis OS came in 
 dead last among all the open source IaaS/PaaS's (the current version of mine 
 is not #1 btw)
 
 
 On Mon, Aug 25, 2014 at 2:03 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:
 On 25 August 2014 10:34, Aryeh Friedman aryeh.fried...@gmail.com wrote:
 Do you call Martin Meckos having no clue... he is the one that leveled the 
 second worse criticism after mine... or is Euclapytus not one the founding 
 members of OpenStack (after all many of the glance commands still use it's 
 name)
 
 You appear to be trolling, and throwing around amazingly easy-to-disprove 
 'factoids', in an inappropriate forum, in order to drum up support for your 
 own competing open source cloud platform.  Please stop.
 
 Your time would be much better spent improving your platform rather than 
 coming up with frankly bizarre criticism of the competitors.
 -- 
 Ian.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Rochelle.RochelleGrober



Zane Bitter wrote:
 On 22/08/14 21:02, Anne Gentle wrote:
  I'm with Rocky on the anti-czar-as-a-word camp. We all like clever
 names to
  shed the corporate stigma but this word ain't it. Liaison or lead?
 
 +1. The only time you hear the word 'czar' in regular life (outside of
 references to pre-revolutionary Russia) it means that the government is
 looking for a cheap PR win that doesn't require actually doing/changing
 anything.
 
 Liaison or Contact would be fine choices IMHO.

Or, how about Secretary?  Such as part of a cabinet?  Secretary of bugs is 
kinda cool in that they collect info and report, troubleshoot, etc., but final 
decisions are directed by PTL.

--Rocky

 
 cheers,
 Zane.



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

[openstack-dev] [requirements] writing down global requirements lore

2014-08-25 Thread Sean Dague

A few of us that have +2 on the global requirements repository happened
to be in Chicago last week for LinuxCon, and something that came up over
drinks was the fact that it seems clear that the overall +2 group on the
repo doesn't have all the background on why the repository got created,
or some guidelines that we expect out of new proposed reviews.

I volunteered to take a stab at writing down what I interpret as the
background and the standards we should have from my interactions. That
review is here - https://review.openstack.org/#/c/116708

I'd suggest for this review folks -1 for things that they feel are wrong
(or missing to the point that this isn't useful if it lands without it).
Additional enhancements can come as follow ons. But having a basic
upgrade of this readme should help a lot on clarity.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Jeremy Stanley

On 2014-08-25 19:39:30 + (+), Rochelle.RochelleGrober wrote:
 Or, how about Secretary?
[...]

While we're painting this particular bike shed, I have a preference
for janitor, drudge, mule, valet, slogger or similar terms
which make it apparent that there is nothing at all glamorous nor
powerful about the appointment.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

2014-08-25 Thread Kevin Benton

Hi Sean,

Until the IPv6 support requirement is determined, this patch prevent
reviewers from having to add the skip test as long as they mention 'v6' in
the name. [1]

1. https://review.openstack.org/116712

On Sun, Aug 24, 2014 at 12:18 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:

Hi,

The amount of tests that we are having to add skips to for the One
Convergence plugin has grown quite a bit lately.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

This is the only plugin that inherits from the NeutronDbPluginV2 class and
has completely disabled creating Subnets that have an ip_version of 6.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

I hate to single out this plugin. Before this development cycle, open
source plugins would allow the creation of Subnets with ip_version set to
6, and then have lots of bugs which would prevent any instances from
actually obtaining IPv6 addresses and routing. But we didn't have to
explicitly skip tests every time someone wanted to fix bugs - like the
following patch.

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

Also, I want to highlight some meeting minutes, where it was discussed
that in the K release, all plugins will be required to support IPv6. I hope
we can discuss this, build consensus, and ensure that the K release
requirement is reasonable.

http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

Sean M. Collins

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

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

Re: [openstack-dev] [all] The future of the integrated release

2014-08-25 Thread Adam Lawson

I recognize I'm joining the discussion late but I've been following the
dialog fairly closely and want to offer my perspective FWIW. I have a lot
going through my head, not sure how to get it all out there so I'll do a
brain dump, get some feedback and apologize in advance.

One the things I like most about Openstack is its incredible flexibility -
a modular architecture where certain programs/capabilities can be leveraged
for a specific install - or not, and ideally the rest of the feature suite
remains functional irrespective of a program status. When it comes to a
program being approved as part of Openstack Proper (pardon my stepping over
that discussion), I think a LOT of what is being discussed here touches on
what Openstack will ultimately be about and what it won't.

With products like Cloudstack floating around consuming market share, all I
see is Citrix. A product billed as open source but so closely aligned with
one vendor that it almost doesn't matter. They have matured decision
structure, UI polish and organized support but they don't have community.
Not like us anyway. With Openstack the moral authority to call ourselves
the champions of open cloud and with that, we have competing interests that
make our products better. We don't have a single vendor (yet) that dictates
whether something will happen or not. The maturity of the Openstack
products themselves are driven by a community of consumers where the needs
are accommodated rather than sold.

A positive than comes with such a transparent design pipeline is the
increased capability for design agility and accommodating changes when a
change is needed. But I'm becoming increasingly disappointed at the mount
of attention being given to whether one product is blessed by Openstack or
not. In a modular design, these programs should be interchangeable with
only a couple exceptions. Does being blessed really matter? The consensus
I've garnered in this thread is the desperate need for the consuming
community's continued involvement. What I *haven't* heard much about is how
Openstack can standardize how these programs - blessed or not - can
interact with the rest of the suite to the extent they adhere to the
correct inputs/outputs which makes them functional. Program status is
irrelevant.

I guess when it comes right down to it, I love what Openstack is and where
we're going and I especially appreciate these discussions. But I'm
disappointed at the number of concerns I've been reading about things that
ultimately don't matter (like being blessed, about who has the power, etc)
and I have concerns we lose sight what this is all about to the point that
the vision for Openstack gets clouded.

We have a good thing and no project can accommodate every request so a
decision must be made as to what is 'included' and what is 'supported'. But
with modularity, it really doesn't matter one iota if a program is blessed
in the Openstack integrated release cycle or not.

But my goodness we have some brilliant minds on our team don't we!

Mahalo,
Adam


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Mon, Aug 25, 2014 at 6:36 AM, Sean Dague s...@dague.net wrote:

 On 08/20/2014 12:37 PM, Zane Bitter wrote:
  On 11/08/14 05:24, Thierry Carrez wrote:
  So the idea that being (and remaining) in the integrated release should
  also be judged on technical merit is a slightly different effort. It's
  always been a factor in our choices, but like Devananda says, it's more
  difficult than just checking a number of QA/integration checkboxes. In
  some cases, blessing one project in a problem space stifles competition,
  innovation and alternate approaches. In some other cases, we reinvent
  domain-specific solutions rather than standing on the shoulders of
  domain-specific giants in neighboring open source projects.
 
  I totally agree that these are the things we need to be vigilant about.
 
  Stifling competition is a big worry, but it appears to me that a lot of
  the stifling is happening even before incubation. Everyone's time is
  limited, so if you happen to notice a new project on the incubation
  trajectory doing things in what you think is the Wrong Way, you're most
  likely to either leave some drive-by feedback or to just ignore it and
  carry on with your life. What you're most likely *not* to do is to start
  a competing project to prove them wrong, or to jump in full time to the
  existing project and show them the light. It's really hard to argue
  against the domain experts too - when you're acutely aware of how
  shallow your knowledge is in a particular area it's very hard to know
  how hard to push. (Perhaps ironically, since becoming a PTL I feel I
  have to be much more cautious in what I say too, because people are
  inclined to read too much into my opinion - I wonder if TC members feel
  the same

[openstack-dev] [Heat][Docker] How to Dockerize your applications with OpenStack Heat in simple steps

2014-08-25 Thread Marouen Mechtri

Hi all,

I want to present you our guide for Docker containers deployment with
OpenStack Heat.
In this guide we dockerize and deploy a lamp application on two containers.

https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/Docker-containers-deployment-with-OpenStack-Heat.rst
https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst


Hope it will be helpful for many people. Please let us know your opinion
about it.

Regards,
Marouen Mechtri
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Stefano Maffulli

On 08/25/2014 02:36 PM, Joshua Harlow wrote:
 So to see if we can get something useful from this thread.

not on this mailing list. Move it somewhere else: this thread is off
topic here.

/stef

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

[openstack-dev] [trove] single trove config file and run check_uptodate?

2014-08-25 Thread Matt Riedemann

I was reviewing some install script recently where someone was trying to 
configure trove and I was asking about some config option they were 
setting which wasn't in the trove.conf.sample.  I was too lazy at the 
time to see if it was a valid option in the code, but did make me wonder 
if there has been discussion about consolidating the various trove 
config files into a single config file with sections (heat used to have 
the same issue, now they have a single config file).  I'm assuming this 
has come up before but didn't see anything in the mailing list.


Building on that, if there was a single trove config file we could have 
a job that gates on making sure it's up to date by using the 
check_uptodate script used in other projects, e.g. cinder.  That should 
be a relatively easy drop-in, the work will be in cleaning up the config 
file (unless you just replace with what generate_sample provides).


I think the docs team is also interested in seeing this happen...

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [qa] In-tree functional test vision

2014-08-25 Thread Joe Gordon

On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent chd...@redhat.com wrote:


 In the Thoughts on the patch test failure rate and moving forward
 thread[1] there's discussion of moving some of the burden for
 functional testing to the individual projects. This seems like a good
 idea to me, but also seems like it could be a source of confusion so I
 thought I'd start another thread to focus on the details of just this
 topic, separate from the gate-oriented discussion in the other.

 In a couple of messages[2] Sean mentions the vision. Is there a wiki
 page or spec or other kind of document where this nascent vision is
 starting to form? Even if we can't quite get started just yet, it
 would be good to have an opporunity to think about the constraints and
 goals that we'll be working with.


There is no single document on this that I know of. But two good places to
start are the functional testing systems we have for swift and neutron:

http://logs.openstack.org/70/116570/3/check/check-swift-dsvm-functional/4894055/console.html


http://logs.openstack.org/70/116570/3/check/check-neutron-dsvm-functional/bf68c61/console.html
http://git.openstack.org/cgit/openstack/neutron/tree/tox.ini#n29




 Not just the goal of moving tests around, but what, for example, makes
 a good functional test?


Here is a non-exhaustive list of some differences between what belongs in
tempest and functional tests

* functional tests should ideally not need external services (external
services makes it closer to an integration test)
* functional tests can be whitebox tests
* a functional test environment should be easier to set up then devstack




 For constraints: Will tempest be available as a stable library? Is using
 tempest (or other same library across all projects) a good or bad thing?
 Seems there's some disagreement on both of these.


Yes, there is a separate thread on spinning out a tempest-lib (not sure on
what final name will be yet) that functional tests can use. Although I
think there is a lot  to be done before  needing the tempest-lib.



 Personally I'm quite eager to to vastly increase the amount of testing
 I can do on my own machine(s) before letting the gate touch my code.


Why can't you run devstack locally? Maybe there are some changes we can
make so its easier to run devstack locally first.



 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-
 July/thread.html#41057
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-July/041188.html
 http://lists.openstack.org/pipermail/openstack-dev/2014-July/041252.html

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

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

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

Re: [openstack-dev] [tc] Procedure for adding official projects


On 25/08/14 06:48, Thierry Carrez wrote:

Zane Bitter wrote:

Over the past couple of release cycles, the TC has put together a fairly
comprehensive checklist for projects entering into incubation with a
view to being included in the integrated release. However, I'm not aware
of anything equivalent for projects that are becoming official (i.e.
moving to the openstack/ namespace) but that are not targeting eventual
integration - or, indeed, that _are_ targeting eventual integration but
have not yet applied for incubation.

The current procedure afaict is to submit a review to the governance
repo listing the repository under a particular program. It seems like at
a minimum we should be checking for basic due diligence stuff like Is
it Apache licensed?, Did everyone sign the CLA? (may it diaf) and
Are there any trademark issues?. And maybe there are other things the
TC should be looking at too.


I agree... currently we only check that the program is fine with adding
that new repository (by checking with the PTL :P) and that the project
intent seems to fit in the program mission scope. Extra basic due
diligence can't hurt, and we could turn that into a new requirements list.

Would you be interested in proposing a basic new projects in existing
program requirements list as a governance repo change ? Then we could
iterate on it.


Sure :)

https://review.openstack.org/116727


- ZB

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Stefano Maffulli

On Mon 25 Aug 2014 03:38:18 PM CDT, Zane Bitter wrote:
 I'd say we've done fairly well, but I would attribute that at least in
 part to the fact that we've treated the PTL as effectively the
 temporary release management contact more than the guy who will
 resolve disputes for us. In other words, despite rather than because
 of the requirement to have a PTL.

I found this (despite rather than because) a non sequitur.

Let's put this conversation to rest since it seems there is no 
disagreement on the fact that the PTL role is working and stop 
investigating why it's working.

 Imagine a scenario where the community is more or less evenly
 split and neither side is willing to back down even after seeking
 guidance from the TC, the PTL breaks the deadlock by fiat in lieu of
 consensus, followed by [...]

You highlight an interesting scenario: let's file it in the 'risks' 
bucket. I think  we have already ways to mitigate the risk of this 
unlikely event to happen, with Foundation intervening, Board and other 
mediation coming from *outside* of the dev community.

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Rochelle.RochelleGrober

Zane Bitter [August 25, 2014 1:38 PM] wrote:

. . .

snip


 
 I'd say we've done fairly well, but I would attribute that at least in
 part to the fact that we've treated the PTL as effectively the
 temporary
 release management contact more than the guy who will resolve
 disputes for us. In other words, despite rather than because of the
 requirement to have a PTL.
 
 I do think that having a PTL with no actual responsibilities runs the
 risk of having it be seen as a trophy rather than a service to the
 community. The good PTLs - which so far is all of them - are likely to
 respond by volunteering for just as many things as they were doing
 before, so that will tend to counteract the goal of preventing burnout.

I don't think anyone is saying or even really believes that distributing the 
workload would result in a PTL no actual responsibilities.  There is just so 
much to do as a PTL for the larger projects that even having a team focused on 
ensuring the tactical activities happen will still leave the PTL with a 
superhuman workload: planning, coordinating, correcting, driving, regrouping, 
focusing, liaising, etc.  

As I said in my previous mail (got lost in the conversation about what to call 
these team members), To keep growing quality, communications, contributions and 
the health of the projects and OpenStack as an ecosystem, the PTLs must not 
only be strategic thinkers, but strategic actors.  And it's pretty darn hard to 
be strategic when you're down in the tactical, day-to-day weeds.  All of it is 
important, but the only way to keep OpenStack growing *and* healthy is to start 
to specialize in organizational areas, not just code areas.

Look at the organic growth of technical projects in general.  When you start 
with just a few people, communication is easy.  Everyone knows the whole 
project and it's easy to stay on the same page.  New people come on board and 
now you need to document design, operation and organizational lore.  More 
people come on board and you need to track bugs, maybe features, and maybe 
split into groups, which means a leader needs to arise in each group such that 
the multiple groups can stay in sync and integrate their components.  And it 
continues to grow.  Some OpenStack projects have reached the state where each 
of them are really multiple projects, each with a lead.  Neutron and TripleO 
both address this situation, empowering the internal projects and project 
leads, with the PTLs becoming more strategic and more focused on the ecosystem 
of the subprojects.

I bet Kyle Mestery, Jay Pipes and Robert Collins would be happy to dissuade you 
of the idea that they don't have any responsibilities ;-)

--Rocky


  I'm open to the alternative solution (which would be for programs
 which
  are not interested in having a PTL to just not have one). But then if
  things go badly wrong, you require the TC to step in with threats of
  removal of OpenStack and/or to force an election/vote in the middle
 of
  the crisis. I'm really failing to see how that would result, in those
  hypothetical crisis scenarios, in a better outcome.
 
 I don't think there are any good scenarios if you get to that crisis
 point. Imagine a scenario where the community is more or less evenly
 split and neither side is willing to back down even after seeking
 guidance from the TC, the PTL breaks the deadlock by fiat in lieu of
 consensus, followed by an unusually high number of spelling mistakes
 corrections in the source code, a single-issue election, potentially a
 reversal of the decision and possibly a fork that will force the TC to
 step in and choose a side. (Note: not choosing is also a choice.)
 That's
 pretty much an unmitigated disaster too.
 
 Our goal must be to avoid reaching the crisis point, and it seems to me
 that it is actually helpful to make clear to projects that their
 choices
 are:
 Option A: reach consensus
 Option B: there is no Option B
 
 cheers,
 Zane.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds

2014-08-25 Thread Michael Still

On Thu, Aug 21, 2014 at 1:17 AM, Tim Bell tim.b...@cern.ch wrote:

  Michael has been posting very informative blogs on the summary of the
 mid-cycle meetups for Nova. The one on the Nova Network to Neutron
 migration was of particular interest to me as it raises a number of
 potential impacts for the CERN production cloud. The blog itself is at
 http://www.stillhq.com/openstack/juno/14.html



 I would welcome suggestions from the community on the approach to take and
 areas that the nova/neutron team could review to limit the impact on the
 cloud users.



 For some background, CERN has been running nova-network in flat DHCP mode
 since our first Diablo deployment. We moved to production for our users in
 July last year and are currently supporting around 70,000 cores, 6 cells,
 100s of projects and thousands of VMs. Upgrades generally involve disabling
 the API layer while allowing running VMs to carry on without disruption.
 Within the time scale of the migration to Neutron (M release at the
 latest), these numbers are expected to double.



 For us, the concerns we have with the ‘cold’ approach would be on the user
 impact and operational risk of such a change. Specifically,



 1.  A big bang approach of shutting down the cloud, upgrade and the
 resuming the cloud would cause significant user disruption

 2.  The risks involved with a cloud of this size and the open source
 network drivers would be difficult to mitigate through testing and could
 lead to site wide downtime

 3.  Rebooting VMs may be possible to schedule in batches but would
 need to be staggered to keep availability levels



 Note, we are not looking to use Neutron features initially, just to find a
 functional equivalent of the flat DHCP network.



 We would appreciate suggestions on how we could achieve a smooth migration
 for the simple flat DHCP models.


Thanks for sending this Tim. Sorry for my slow reply, a day long meeting
and some international travel got in the way. When we originally talked, I
said I needed to understand more of the background to your need for a zero
downtime upgrade. That said...

Mark McClain and I discussed a possible plan for nova-network to neutron
upgrades at the Ops Meetup today, and it seemed generally acceptable. It
defines a cold migration as freezing the ability to create or destroy
instances during the upgrade, and then requiring a short network outage for
each instance in the cell.

This is why I'm trying to understand the no downtime use case better. Is
it literally no downtime, ever? Or is it a more simple no simultaneous
downtime for instances?

Michael

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Stefano Maffulli

On 08/22/2014 08:19 PM, John Dickinson wrote:
 I think Anne makes some excellent points about the pattern being
 proposed being unlikely to be commonly implemented across all the
 programs (or, at best, very difficult). Let's not try to formalize
 another best practice that works many times and force it to work
 every time. 

I kinda agree with John here. I think the most important effect of this
proposal is that it will add *transparency* to the development effort.
One of the most common questions I have to answer is 'Who should I talk
to to address this issue? and I can't blame them. Just to give you an
example, the list of core reviewers of many project is not immediately
available, sometimes even the name of the PTL is missing from their wiki
pages (since the wiki pages don't follow a common template).

Since we've been growing so much I'm not surprised nor afraid of
becoming more of a bureaucratic organization (in Taylor/Weber's sense of
an organizational structure, we're simply growing up --poor wikipedia
page on this topic
http://en.wikipedia.org/wiki/Organizational_structure#Bureaucratic_structures)
and introduce more rules.

I like the idea of having a template of roles that support PTLs in their
job and I think we should let PTLs pick which of the roles to fill in,
but not divert too much from the common list of roles. And we need to
make sure that these roles and people are communicated properly.

I think we outgrew the phase where any PTL could experiment and
self-organize in full autonomy because snowflakes are too hard to manage
and produce only entropy at our size. We have too many projects,
programs and teams and if all of them operate very differently it
becomes next to impossible for newcomers to join. It gets too hard even
for community  managers to advice newcomers. We're too big for that.
Some level of standardization is inevitable :)

 And let's get the PTLs
 together for one or two days every cycle to discuss project issues.
 Just PTLs, and let's focus on the project management stuff and some
 cross-project issues.

This is orthogonal to the PTLs supporting roles: we can sure do
something to help in this aspect.

On another note, bike shed 'czar' gets -1 from me. Liaison or any of
fungi's suggestions sound better :)

/stef

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

Re: [openstack-dev] [qa] In-tree functional test vision

2014-08-25 Thread Chris Dent


On Mon, 25 Aug 2014, Joe Gordon wrote:

[Other stuff snipped, thanks for that, good to have some pointers.]


Why can't you run devstack locally? Maybe there are some changes we can
make so its easier to run devstack locally first.


I do run a local devstack, and throw in some tempest and grenade every
now and again too.

But in terms of automated local testing in the project tree there are
places it is difficult for clean unit tests to reach. Sure we can make
really hairy mocks, but that results in tests which a) make no sense
b) it is hard to have any confidence in.

Thus in tree functional tests:

* to reach places unit tests won't go
* to not have the noise of all that mock and OO mess
* to have some faith in the end to end

The sorts of things that require provisioning of temporary datastores,
interception of wsgi apps, in process message queues...

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

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

Re: [openstack-dev] [Heat][Docker] How to Dockerize your applications with OpenStack Heat in simple steps

2014-08-25 Thread Angus Salkeld

This seems misleading as there is no description on setting up nova-docker
or using the heat docker container.

-Angus



On Tue, Aug 26, 2014 at 5:56 AM, Marouen Mechtri mechtri.mar...@gmail.com
wrote:

 Hi all,

 I want to present you our guide for Docker containers deployment with
 OpenStack Heat.
 In this guide we dockerize and deploy a lamp application on two containers.


 https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/Docker-containers-deployment-with-OpenStack-Heat.rst
 https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst


 Hope it will be helpful for many people. Please let us know your opinion
 about it.

 Regards,
 Marouen Mechtri

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


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

Re: [openstack-dev] [qa] In-tree functional test vision

2014-08-25 Thread Joe Gordon

On Mon, Aug 25, 2014 at 2:50 PM, Chris Dent chd...@redhat.com wrote:

 On Mon, 25 Aug 2014, Joe Gordon wrote:

 [Other stuff snipped, thanks for that, good to have some pointers.]


  Why can't you run devstack locally? Maybe there are some changes we can
 make so its easier to run devstack locally first.


 I do run a local devstack, and throw in some tempest and grenade every
 now and again too.

 But in terms of automated local testing in the project tree there are
 places it is difficult for clean unit tests to reach. Sure we can make
 really hairy mocks, but that results in tests which a) make no sense
 b) it is hard to have any confidence in.

 Thus in tree functional tests:

 * to reach places unit tests won't go
 * to not have the noise of all that mock and OO mess
 * to have some faith in the end to end

 The sorts of things that require provisioning of temporary datastores,
 interception of wsgi apps, in process message queues...



agreed




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

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

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

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-08-25 Thread Mandeep Dhami

+1

I agree with Pradeep and Doug that a new namespace makes for a better
structure for packaging and usage.

Regards,
Mandeep
-



On Mon, Aug 25, 2014 at 11:30 AM, Doug Hellmann d...@doughellmann.com
wrote:


 On Aug 23, 2014, at 5:36 PM, Maru Newby ma...@redhat.com wrote:

 
  On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com
 wrote:
 
  On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com
 wrote:
  On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
 
  On 20/08/14 18:28, Salvatore Orlando wrote:
  Some comments inline.
 
  Salvatore
 
  On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com
  mailto:ihrac...@redhat.com wrote:
 
  Hi all,
 
  I've read the proposal for incubator as described at [1], and I
  have several comments/concerns/suggestions to this.
 
  Overall, the idea of giving some space for experimentation that
  does not alienate parts of community from Neutron is good. In that
  way, we may relax review rules and quicken turnaround for preview
  features without loosing control on those features too much.
 
  Though the way it's to be implemented leaves several concerns, as
  follows:
 
  1. From packaging perspective, having a separate repository and
  tarballs seems not optimal. As a packager, I would better deal with
  a single tarball instead of two. Meaning, it would be better to
  keep the code in the same tree.
 
  I know that we're afraid of shipping the code for which some users
  may expect the usual level of support and stability and
  compatibility. This can be solved by making it explicit that the
  incubated code is unsupported and used on your user's risk. 1) The
  experimental code wouldn't probably be installed unless explicitly
  requested, and 2) it would be put in a separate namespace (like
  'preview', 'experimental', or 'staging', as the call it in Linux
  kernel world [2]).
 
  This would facilitate keeping commit history instead of loosing it
  during graduation.
 
  Yes, I know that people don't like to be called experimental or
  preview or incubator... And maybe neutron-labs repo sounds more
  appealing than an 'experimental' subtree in the core project.
  Well, there are lots of EXPERIMENTAL features in Linux kernel that
  we actively use (for example, btrfs is still considered
  experimental by Linux kernel devs, while being exposed as a
  supported option to RHEL7 users), so I don't see how that naming
  concern is significant.
 
 
  I think this is the whole point of the discussion around the
  incubator and the reason for which, to the best of my knowledge,
  no proposal has been accepted yet.
 
 
  I wonder where discussion around the proposal is running. Is it
 public?
 
  The discussion started out privately as the incubation proposal was
  put together, but it's now on the mailing list, in person, and in IRC
  meetings. Lets keep the discussion going on list now.
 
 
  In the spirit of keeping the discussion going, I think we probably
  need to iterate in practice on this idea a little bit before we can
  crystallize on the policy and process for this new repo. Here are few
  ideas on how we can start this iteration:
 
  * Namespace for the new repo:
  Should this be in the neutron namespace, or a completely different
  namespace like neutron labs? Perhaps creating a separate namespace
  will help the packagers to avoid issues of conflicting package owners
  of the namespace.
 
  I don’t think there is a technical requirement to choose a new
 namespace.  Python supports sharing a namespace, and packaging can support
 this feature (see: oslo.*).

 If the point of the incubator is to signal to deployers that the code
 isn’t fully supported, you may want to use a different namespace for the
 python/system packages as well.

 Doug

 
 
  * Dependency on Neutron (core) repository:
  We would need to sort this out so that we can get UTs to run and pass
  in the new repo. Can we set the dependency on Neutron milestone
  releases? We already publish tar balls for the milestone releases, but
  I am not sure we publish these as packages to pypi. If not could we
  start doing that? With this in place, the incubator would always lag
  the Neutron core by at the most one milestone release.
 
  Given that it is possible to specify a dependency as a branch/hash/tag
 in a git repo [1], I’m not sure it’s worth figuring out how to target
 tarballs.  Master branch of the incubation repo could then target the
 master branch of the Neutron repo and always be assured of being current,
 and then released versions could target milestone tags or released versions.
 
  1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git
 
 
  * Modules overlapping with the Neutron (core) repository:
  We could initially start with the features that required very little
  or no changes to the Neutron core, to avoid getting into the issue of
  blocking on

[openstack-dev] [cinder]pylint errors with hashlib

2014-08-25 Thread Murali Balcha

Pylint on my patch is failing with the following error:

Module 'hashlib' has no 'sha256'

Cinder pylint already has following exceptions,


pylint_exceptions:[Instance of 'sha1' has no 'update' member, ]

pylint_exceptions:[Module 'hashlib' has no 'sha224' member, ]


So I think hashlib has no 'sha256' should be added to the exception list as 
well. How can I update the exception list?


Thanks,

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

[openstack-dev] [nova] Suggestion that Fix to logic of diskfilter

2014-08-25 Thread Jae Sang Lee

Hi, all.

Diskfilter based on host disk usage, it check between usable host disk size
and requested vm disk size.
But when create a VM with boot volume, Diskfilter has filtered a host
although a VM doesn't use host disk.
(Usually ISCSI volume could be attached)

So I have filed following defect to fix the logic that doesn't check when a
VM created with boot volume.
https://bugs.launchpad.net/nova/+bug/1358566

Could anyone please let me know whether I can fix this for Juno?

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

Re: [openstack-dev] [cinder]pylint errors with hashlib

2014-08-25 Thread Clark Boylan

On Mon, Aug 25, 2014, at 06:45 PM, Murali Balcha wrote:
 Pylint on my patch is failing with the following error:
 
 Module 'hashlib' has no 'sha256'
 
 Cinder pylint already has following exceptions,
 
 
 pylint_exceptions:[Instance of 'sha1' has no 'update' member, ]
 
 pylint_exceptions:[Module 'hashlib' has no 'sha224' member, ]
 
 
 So I think hashlib has no 'sha256' should be added to the exception
 list as well. How can I update the exception list?
 
 
 Thanks,
 
 Murali Balcha
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think this may be related to your install of python. Mine does not
have this problem.

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type help, copyright, credits or license for more information.
 import hashlib
 hashlib.sha256
built-in function openssl_sha256
 hashlib.sha224
built-in function openssl_sha224
 s = hashlib.sha1()
 s.update('somestring')
 

You should not need to treat these as acceptable failures.

Clark

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

Re: [openstack-dev] [nova] Suggestion that Fix to logic of diskfilter