[openstack-dev] Rescue of volume-backed instances

2014-10-08 Thread Christian Berendt
Right now it is not possible to rescue a volume-backed instance.

nova/compute/api.py: reason = _(Cannot rescue a volume-backed instance)

Are there plans to implement this feature?

Are there well known reasons why this feature is not yet available?

Christian.

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

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

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


[openstack-dev] [devstack] Bug 1339982 (DevStack giving br-ex the IP address of PUBLIC_NETWORK_GATEWAY)

2014-10-08 Thread Mike Spreitzer
I think I am suffering from 
https://bugs.launchpad.net/devstack/+bug/1339982 and am surprised by the 
lack of attention it has gotten --- it seems like a pretty basic thing. Am 
I missing something here?

As revealed at the turning point of a discussion on the openstack mailing 
list (
http://lists.openstack.org/pipermail/openstack/2014-October/009785.html), 
I am trying to use DevStack to install (single node) OpenStack on a lab 
machine rather than my laptop --- and finding that DevStack wedges my 
host's networking if I set PUBLIC_NETWORK_GATEWAY to the address of an 
actual pre-existing external gateway.  Am I and the author of bug 1339982 
the only ones doing this?  Why doesn't our CI checking have this problem?

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


Re: [openstack-dev] Quota management and enforcement across projects

2014-10-08 Thread Salvatore Orlando
On 8 October 2014 04:13, Joe Gordon joe.gord...@gmail.com wrote:


 On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg 
 morgan.fainb...@gmail.com wrote:

 Keeping the enforcement local (same way policy works today) helps limit
 the fragility, big +1 there.

 I also agree with Vish, we need a uniform way to talk about quota
 enforcement similar to how we have a uniform policy language / enforcement
 model (yes I know it's not perfect, but it's far closer to uniform than
 quota management is).


 It sounds like maybe we should have an oslo library for quotas? Somewhere
 where we can share the code,but keep the operations local to each service.


This is what I had in mind as well. A simple library for quota enforcement
which can be used regardless of where and how you do it, which might depend
on the application business logic, the WSGI framework in use, or other
factors.




 If there is still interest of placing quota in keystone, let's talk about
 how that will work and what will be needed from Keystone . The previous
 attempt didn't get much traction and stalled out early in implementation.
 If we want to revisit this lets make sure we have the resources needed and
 spec(s) in progress / info on etherpads (similar to how the multitenancy
 stuff was handled at the last summit) as early as possible.


 Why not centralize quota management via the python-openstackclient, what
 is the benefit of getting keystone involved?


Providing this through the openstack client in my opinion has the
disadvantage that users which either use the REST API direct or write their
own clients won't leverage it. I don't think it's a reasonable assumption
that everybody will use python-openstackclient, is it?

Said that, storing quotas in keystone poses a further challenge to the
scalability of the system, which we shall perhaps address by using
appropriate caching strategies and leveraging keystone notifications. Until
we get that, I think that the openstack client will be the best way of
getting a unified quota management experience.

Salvatore



 Cheers,
 Morgan

 Sent via mobile


 On Friday, October 3, 2014, Salvatore Orlando sorla...@nicira.com
 wrote:

 Thanks Vish,

 this seems a very reasonable first step as well - and since most
 projects would be enforcing quotas in the same way, the shared library
 would be the logical next step.
 After all this is quite the same thing we do with authZ.

 Duncan is expressing valid concerns which in my opinion can be addressed
 with an appropriate design - and a decent implementation.

 Salvatore

 On 3 October 2014 18:25, Vishvananda Ishaya vishvana...@gmail.com
 wrote:

 The proposal in the past was to keep quota enforcement local, but to
 put the resource limits into keystone. This seems like an obvious first
 step to me. Then a shared library for enforcing quotas with decent
 performance should be next. The quota calls in nova are extremely
 inefficient right now and it will only get worse when we try to add
 hierarchical projects and quotas.

 Vish

 On Oct 3, 2014, at 7:53 AM, Duncan Thomas duncan.tho...@gmail.com
 wrote:

  Taking quota out of the service / adding remote calls for quota
  management is going to make things fragile - you've somehow got to
  deal with the cases where your quota manager is slow, goes away,
  hiccups, drops connections etc. You'll also need some way of
  reconciling actual usage against quota usage periodically, to detect
  problems.
 
  On 3 October 2014 15:03, Salvatore Orlando sorla...@nicira.com
 wrote:
  Hi,
 
  Quota management is currently one of those things where every
 openstack
  project does its own thing. While quotas are obviously managed in a
 similar
  way for each project, there are subtle differences which ultimately
 result
  in lack of usability.
 
  I recall that in the past there have been several calls for unifying
 quota
  management. The blueprint [1] for instance, hints at the possibility
 of
  storing quotas in keystone.
  On the other hand, the blazar project [2, 3] seems to aim at solving
 this
  problem for good enabling resource reservation and therefore
 potentially
  freeing openstack projects from managing and enforcing quotas.
 
  While Blazar is definetely a good thing to have, I'm not entirely
 sure we
  want to make it a required component for every deployment. Perhaps
 single
  projects should still be able to enforce quota. On the other hand,
 at least
  on paper, the idea of making Keystone THE endpoint for managing
 quotas,
  and then letting the various project enforce them, sounds promising
 - is
  there any reason for which this blueprint is stalled to the point
 that it
  seems forgotten now?
 
  I'm coming to the mailing list with these random questions about
 quota
  management, for two reasons:
  1) despite developing and using openstack on a daily basis I'm still
  confused by quotas
  2) I've found a race condition in neutron quotas and the fix is not
 trivial.
  So, rather than start coding 

Re: [openstack-dev] [nova] Nova Project Priorities for Kilo

2014-10-08 Thread Nikola Đipanov
On 10/07/2014 01:01 AM, Joe Gordon wrote:
 Hi all,
 
 One of the outcomes of the nova midcyle meetup was to pick several
 things for nova, as a team, to prioritize in Kilo. More background on
 this can be found at [0]
 
 We are now collecting ideas for project priorities on this etherpad [1],
 with the goal of discussing and finalizing the list or priorities for
 Kilo at the summit.
 
 [0] 
 http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#project-priorities
 [1] https://etherpad.openstack.org/p/kilo-nova-priorities
 

Sightly off topic:

Jay and Sylvain, can we maybe move the discussion that started there to
a different etherpad that we can link, so that we don't hijack the pad
completely, but still have that discussion as I think we have very
similar ideas - we should just agree on implementation.

Thanks,
N.

 
 ___
 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] Usage of @author tags in the header of Python files

2014-10-08 Thread Christian Berendt
After proposing a change to Horizon to remove the @author tags from the
header of Python files (https://review.openstack.org/#/c/126656/)
Matthias Runge proposed to discuss this first on the mailing list.

Is it necessary to track the authorship of a file inside the file using
@author tags?

The copyright statement itself is unchanged and intact after the removal
of the @author tags.

The copyright statement is not addicted to the authorship of a file so
it should be safe to remove the @author tags.

The @author tag is not used in other projects. Neutron removed all
@author tags some time ago and there are no @author tags e.g. in Nova,
or Cinder. There are even local hacking checks in Nova, and Neutron to
not use @author tags.

Christian.

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

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

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


Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Dmitriy Shulyak
If there is no checkboxes (read configuration) and plugin is installed -
all deployment tasks will be applied
to every environment, but why do you think that there will be no checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions), classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara, murano,
zabbix)

In 1st case you need to provide shared configuration storage (like cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov nmar...@mirantis.com wrote:

 Hi,

 Frankly speaking, I'm not sure on how 1st approach will even work.
 What if plugin doesn't provide any checkboxes (and in most cases it
 won't)? How should we determine in serializer, which plugins should be
 applied while generating astute.yaml and tasks.yaml? Should we
 autogenerate some stuff for plugins which are not even enabled and do
 needless work?

 This looks too complicated for me from the backend side, and option
 with enabling/disabling plugins in wizard for specific environment (we
 can invent mechanism to disable them on env which is not deployed yet,
 besides, for API it's just one PUT) is MUCH simpler and much more
 obvious, as I see.



 On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Hi,
 
  I would go with the 1st approach. The thing I don't like in the 2nd
 approach
  is that we have to make the user enable plugin twice. For example, we
 have
  to enable Ceph as a plugin and then add Ceph role to nodes and choose
 what
  we want to store in Ceph (images, objects). Why we would need to
 explicitly
  enable Ceph plugin? Let's always show plugin options in wizard and
 settings
  tab, and if the user just doesn't want to enable Ceph, he would just
 leave
  all the checkboxes unchecked. The 2nd approach would also lead to some
 kind
  of inconsistency in case the user enabled Ceph plugin but left all the
  Ceph-related checkboxes unchecked and didn't add Ceph nodes.
 
  2014-10-07 21:17 GMT+07:00 Evgeniy L e...@mirantis.com:
 
  Hi,
 
  We had a meeting today about plugins on UI, as result of the meeting
  we have two approaches and this approaches affect not only UX but
  plugins itself.
 
  1st - disable/enable plugin on settings tab
 
  user installs the plugin
  creates a cluster
  configures and enables/disables plugins on settings tab
 
  For user it will look like Ceph plugin checkboxes on settings tab,
  if he enables checkbox, then we pass the parameter to orchestrator
  as `true`.
 
  Cons:
 
  plugin developer should define a checkbox in each plugin (for plugin
  disabling/enabling)
  on the backend we have to enable all of the plugins for environment,
  because user can define any name for his checkbox and we won't be able
 to
  find it and make appropriate mapping plugin - env
  since all of the plugins are always enabled we have to run tasks for
 all
  of the plugins, and each plugin should parse astute.yaml in order to
 figure
  out if it's required to run task current script
 
  Pros:
 
  it won't require additional setting or step for wizard
  user will be able to disable plugin after environment creation
 
  2nd - enable plugins in wizard
 
  user installs the plugin
  now he can choose specific plugins for his environment in wizard
  after cluster is created, he can configure additional parameters on
  settings tab, if plugin provides any
 
  Cons:
 
  user won't be able to disable plugin after cluster is created
  additional step or configuration subcategory in wizard
 
  Pros:
 
  On backend we always know which plugin is disabled and which is enabled.
 
  it means we don't provide settings for plugins which are disabled
  we don't run tasks on slaves if it's not required
 
  Thanks,
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



 --
 Best regards,
 Nick Markov

 ___
 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

Re: [openstack-dev] [Mistral] Moving docs from wiki to mistral/doc

2014-10-08 Thread Renat Akhmerov
Yes, I already reviewed your commits. Thanks.

Renat Akhmerov
@ Mirantis Inc.



On 07 Oct 2014, at 15:06, Dmitri Zimine dzim...@stackstorm.com wrote:

 Folks, I have moved the DSL and API docs to the project (up on review). Now 
 it contains enough examples to get going, also see doc/README.md for some 
 useful hints. 
 
 Renat, Nikolay, if you find any omissions please add; and once we are happy 
 let’s remove the DSL and API wiki to avoid confusion. Wiki can refer to the 
 readthedocs page (generated with every build).
 
 DZ 

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


Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Nikolay Markov
 Right now we already have like 2 types of plugins (extensions), classified 
 by usage of settings tab:
 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or 
 hypervisor (lvm/qemu/vmware)
 2. Self-contained service that just needs to be installed (sahara, murano, 
 zabbix)

That's not quite right. In 6.0 and after that there will be a lot of
small plugins which only modify some config and/or install some
package. There is nothing to configure here, and I as a plugin
developer don't even want to know anything about checkboxes on UI. I
just want two things: role to execute my command on and command
itself. That's one small YAML.

And autogenerating checkboxes for such plugins on UI is bad, because
explicit is better than implicit (and all our settings are explicitly
defined in openstack.yaml).

On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak dshul...@mirantis.com wrote:
 If there is no checkboxes (read configuration) and plugin is installed - all
 deployment tasks will be applied
 to every environment, but why do you think that there will be no checkboxes
 in most cases?

 Right now we already have like 2 types of plugins (extensions), classified
 by usage of settings tab:
 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
 hypervisor (lvm/qemu/vmware)
 2. Self-contained service that just needs to be installed (sahara, murano,
 zabbix)

 In 1st case you need to provide shared configuration storage (like cluster
 attributes right now), in order for plugin
 to be able to exclude part of core workflow from running (not installing
 swift for example).
 In case if the plugin is self-contained entity, like Sahara, Murano right
 now - checkboxes would be simply required.
 It works this way right now, and it doesnot look like huge overhead.

 So what do you think, will it work or no?

 On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov nmar...@mirantis.com wrote:

 Hi,

 Frankly speaking, I'm not sure on how 1st approach will even work.
 What if plugin doesn't provide any checkboxes (and in most cases it
 won't)? How should we determine in serializer, which plugins should be
 applied while generating astute.yaml and tasks.yaml? Should we
 autogenerate some stuff for plugins which are not even enabled and do
 needless work?

 This looks too complicated for me from the backend side, and option
 with enabling/disabling plugins in wizard for specific environment (we
 can invent mechanism to disable them on env which is not deployed yet,
 besides, for API it's just one PUT) is MUCH simpler and much more
 obvious, as I see.



 On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Hi,
 
  I would go with the 1st approach. The thing I don't like in the 2nd
  approach
  is that we have to make the user enable plugin twice. For example, we
  have
  to enable Ceph as a plugin and then add Ceph role to nodes and choose
  what
  we want to store in Ceph (images, objects). Why we would need to
  explicitly
  enable Ceph plugin? Let's always show plugin options in wizard and
  settings
  tab, and if the user just doesn't want to enable Ceph, he would just
  leave
  all the checkboxes unchecked. The 2nd approach would also lead to some
  kind
  of inconsistency in case the user enabled Ceph plugin but left all the
  Ceph-related checkboxes unchecked and didn't add Ceph nodes.
 
  2014-10-07 21:17 GMT+07:00 Evgeniy L e...@mirantis.com:
 
  Hi,
 
  We had a meeting today about plugins on UI, as result of the meeting
  we have two approaches and this approaches affect not only UX but
  plugins itself.
 
  1st - disable/enable plugin on settings tab
 
  user installs the plugin
  creates a cluster
  configures and enables/disables plugins on settings tab
 
  For user it will look like Ceph plugin checkboxes on settings tab,
  if he enables checkbox, then we pass the parameter to orchestrator
  as `true`.
 
  Cons:
 
  plugin developer should define a checkbox in each plugin (for plugin
  disabling/enabling)
  on the backend we have to enable all of the plugins for environment,
  because user can define any name for his checkbox and we won't be able
  to
  find it and make appropriate mapping plugin - env
  since all of the plugins are always enabled we have to run tasks for
  all
  of the plugins, and each plugin should parse astute.yaml in order to
  figure
  out if it's required to run task current script
 
  Pros:
 
  it won't require additional setting or step for wizard
  user will be able to disable plugin after environment creation
 
  2nd - enable plugins in wizard
 
  user installs the plugin
  now he can choose specific plugins for his environment in wizard
  after cluster is created, he can configure additional parameters on
  settings tab, if plugin provides any
 
  Cons:
 
  user won't be able to disable plugin after cluster is created
  additional step or configuration subcategory in wizard
 
  Pros:
 
  On backend we always know which plugin is 

Re: [openstack-dev] [nova] Nova Project Priorities for Kilo

2014-10-08 Thread Sylvain Bauza


Le 08/10/2014 09:26, Nikola Đipanov a écrit :

On 10/07/2014 01:01 AM, Joe Gordon wrote:

Hi all,

One of the outcomes of the nova midcyle meetup was to pick several
things for nova, as a team, to prioritize in Kilo. More background on
this can be found at [0]

We are now collecting ideas for project priorities on this etherpad [1],
with the goal of discussing and finalizing the list or priorities for
Kilo at the summit.

[0] 
http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#project-priorities
[1] https://etherpad.openstack.org/p/kilo-nova-priorities


Sightly off topic:

Jay and Sylvain, can we maybe move the discussion that started there to
a different etherpad that we can link, so that we don't hijack the pad
completely, but still have that discussion as I think we have very
similar ideas - we should just agree on implementation.


Totally agree with you, I just copy/pasted the discussion into 
https://etherpad.openstack.org/p/nova-scheduler-refactoring and put the 
link into Joe's etherpad.


-Sylvain


Thanks,
N.


___
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] [UX] [Heat] [Mistral] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder

2014-10-08 Thread Renat Akhmerov
Ok, Timur, thanks. Will check it out by the end of this week.

Renat Akhmerov
@ Mirantis Inc.



On 06 Oct 2014, at 20:16, Timur Sufiev tsuf...@mirantis.com wrote:

 Renat,
 
 I've addressed a number of Mistral Workbook builder's issues, including:
 
 * separating workflow-based Tasks from action-based ones, including distinct 
 set of fields for each one;
 * restricting the range of values that can be selected for 'required' field 
 of Task inside reverse-type Workflow to already existing tasks of that 
 Workflow;
 * removing 'Add' button that cluttered UI considerably - now Barricade 
 entities are updated on field's 'change' event;
 * updating the Merlin/Mistral schema with the latest version of Mistral 
 workbook schema
 * and some bugfixing...
 
 Regarding the field validation which is the last goal for Merlin/Mistral PoC 
 I haven't implemented yet, your feedback would be very helpful, namely: 
 * what validation constraints should be added?
 * which fields should be validated?
 
 Any other feedback (not only related to validation issues) is also greatly 
 appreciated. Once we deal with validation and some UI awkwardness, I plan to 
 begin with Horizon integration. 
 
 P.S. As usual, you can find the latest version of Merlin/Mistral Workbook 
 builder at https://github.com/stackforge/merlin
 
 On Tue, Sep 30, 2014 at 11:06 AM, Renat Akhmerov rakhme...@mirantis.com 
 wrote:
 Timur,
 
 For us, undoubtedly, it’s a great news. Visualization of any kind is really 
 important for Mistral for a number of reasons. You can count on any 
 help(including code contribution) from our side.
 
 Thanks
 
 Renat Akhmerov
 @ Mirantis Inc.
 
 
 
 On 26 Sep 2014, at 04:04, Steve Baker sba...@redhat.com wrote:
 
  On 26/09/14 05:36, Timur Sufiev wrote:
  Hello, folks!
 
  Following Drago Rosson's introduction of Barricade.js and our discussion 
  in ML about possibility of using it in Merlin [1], I've decided to change 
  the plans for PoC: now the goal for Merlin's PoC is to implement Mistral 
  Workbook builder on top of Barricade.js. The reasons for that are:
 
  * To better understand Barricade.js potential as data abstraction layer in 
  Merlin, I need to learn much more about its possibilities and limitations 
  than simple examining/reviewing of its source code allows. The best way to 
  do this is by building upon it.
  * It's becoming too crowded in the HOT builder's sandbox - doing the same 
  work as Drago currently does [2] seems like a waste of resources to me 
  (especially in case he'll opensource his HOT builder someday just as he 
  did with Barricade.js).
 
  Drago, it would be to everyone's benefit if your HOT builder efforts were 
  developed on a public git repository, no matter how functional it is 
  currently.
 
  Is there any chance you can publish what you're working on to 
  https://github.com/dragorosson or rackerlabs for a start?
 
  * Why Mistral and not Murano or Solum? Because Mistral's YAML templates 
  have simpler structure than Murano's ones do and is better defined at that 
  moment than the ones in Solum.
 
  There already some commits in https://github.com/stackforge/merlin and 
  since client-side app doesn't talk to the Mistral's server yet, it is 
  pretty easy to run it (just follow the instructions in README.md) and then 
  see it in browser at http://localhost:8080. UI is yet not great, as the 
  current focus is data abstraction layer exploration, i.e. how to exploit 
  Barricade.js capabilities to reflect all relations between Mistral's 
  entities. I hope to finish the minimal set of features in a few weeks - 
  and will certainly announce it in the ML.
 
  [1] 
  http://lists.openstack.org/pipermail/openstack-dev/2014-September/044591.html
  [2] 
  http://lists.openstack.org/pipermail/openstack-dev/2014-August/044186.html
 
 
  ___
  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
 
 
 
 -- 
 Timur Sufiev

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


Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread henry hly
Hi,

Good questions: why not just keeping multiple endpoints, and leaving
orchestration effort in the client side?

From feedback of some large data center operators, they want the cloud
exposed to tenant as a single region with multiple AZs, while each AZ
may be distributed in different/same locations, very similar with AZ
concept of AWS. And the OpenStack API is indispensable for the cloud
for eco-system friendly.

The cascading is mainly doing one thing: map each standalone child
Openstack to AZs in the parent Openstack, hide separated child
endpoints, thus converge them into a single standard OS-API endpoint.

One of the obvious benefit doing so is the networking: we can create a
single Router/LB, with subnet/port member from different child, just
like in a single OpenStack instance. Without the parent OpenStack
working as the aggregation layer, it is not so easy to do so. Explicit
VPN endpoint may be required in each child.

Best Regards
Wu Hongning

On Tue, Oct 7, 2014 at 11:30 PM, Monty Taylor mord...@inaugust.com wrote:
 On 10/07/2014 06:41 AM, Duncan Thomas wrote:
 My data consistency concerts would be around:

 1) Defining global state. You can of course hand wave away a lot of
 your issues by saying they are all local to the sub-unit, but then
 what benefit are you providing .v. just providing a list of endpoints
 and teaching the clients to talk to multiple endpoints, which is far
 easier to make reliable than a new service generally is. State that
 'ought' to be global: quota, usage, floating ips, cinder backups, and
 probably a bunch more

 BTW - since infra regularly talks to multiple clouds, I've been working
 on splitting supporting code for that into a couple of libraries. Next
 pass is to go add support for it to the clients, and it's not really a
 lot of work ... so let's assume that the vs. here is going to be
 accomplished soonish for the purposes of assessing the above question.

 Second BTW - you're certainly right about the first two in the global
 list - we keep track of quota and usage ourselves inside of nodepool.
 Actually - since nodepool already does a bunch of these things - maybe
 we should just slap a REST api on it...

 2) Data locality expectations. You have to be careful about what
 expectations .v. realty you're providing here. If the user experience
 is substantially different using your proxy .v. direct API, then I
 don't think you are providing a useful service - again, just teach the
 clients to be multi-cloud aware. This includes what can be connected
 to what (cinder volumes, snaps, backups, networks, etc), replication
 behaviours and speeds (swift) and probably a bunch more that I haven't
 thought of yet.



 On 7 October 2014 14:24, joehuang joehu...@huawei.com wrote:
 Hello, Joshua,

 Thank you for your concerns on OpenStack cascading. I am afraid that I am 
 not proper person to give comment on cells, but I would like to speak a 
 little about cascading for you mentioned with its own set of consistency 
 warts I'm sure .

 1. For small scale or a cloud within one data centers, one OpenStack 
 instance (including cells) without cascading feature can work just like it 
 work today. OpenStack cascading just introduces Nova-proxy, Cinder-proxy, 
 L2/L3 proxy... like other vendor specific agent/driver( for example, 
 vcenter driver, hyper-v driver, linux-agent.. ovs-agent ), and does not 
 change the current architecture for Nova/Cinder/Neutron..., and does not 
 affect the aleady developed features and deployment capability. The cloud 
 operators can skip the existence of OpenStack cascading if they don't want 
 to use it, just like they don't want to use some kinds of hypervisor / sdn 
 controller 

 2. Could you provide concrete inconsistency issues you are worried about in 
 OpenStack cascading? Although we did not implement inconsistency check in 
 the PoC source code completely, but because logical 
 VM/Volume/Port/Network... objects are stored in the cascading OpenStack, 
 and the physical objects are stored in the cascaded OpenStack, uuid mapping 
 between logical object and physical object had been built,  it's possible 
 and easy to solve the inconsistency issues. Even for flavor, host 
 aggregate, we have method to solve the inconsistency issue.

 Best Regards

 Chaoyi Huang ( joehuang )
 
 From: Joshua Harlow [harlo...@outlook.com]
 Sent: 07 October 2014 12:21
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack cascading

 On Oct 3, 2014, at 2:44 PM, Monty Taylor mord...@inaugust.com wrote:

 On 09/30/2014 12:07 PM, Tim Bell wrote:
 -Original Message-
 From: John Garbutt [mailto:j...@johngarbutt.com]
 Sent: 30 September 2014 15:35
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack
 cascading

 On 30 September 

[openstack-dev] Virtual_machine for devstack

2014-10-08 Thread Angelo Matarazzo

Hi all,
I have prepared a virtual machine with ubuntu installed for devstack
In the /media/nas/nfs_shares/projects/Cloud/Openstack/devstack8_10_14/
There are
devstack8_10_14.ova for virtual box import
local.conf --configuration file for devstack
README_8_10_14 -- instructions

pls, read the instructions and for installing read carefully following 
sections


Prerequisites


Install devstack
==



Other sections:

Run devstack

Shutdown devstack

Install Liclipse
=
Use of Liclipse
=
Reinstall devstack
===
Connect to devstack
=
Git usage
==


Any review or comment is very welcome

cheers,
Angelo



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


[openstack-dev] [Keystone] Juno RC2 available

2014-10-08 Thread Thierry Carrez
Hello everyone,

Due to a number of issues discovered in the published Keystone 2014.2
RC1, we generated a new Juno release candidate. You can find the list of
bugfixes in this RC and a link to a source tarball at:

https://launchpad.net/keystone/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Keystone 2014.2
on October 16. You are therefore strongly encouraged to test and
validate this tarball !

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/keystone/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/keystone/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's
attention.

Regards,

-- 
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] [oslo] Meeting time

2014-10-08 Thread Mehdi Abaakouk


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



- Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
- Thursdays at 1600 UTC [2]: #openstack-meeting-3
- Thursdays at 1700 UTC [3]: #openstack-meeting-3
- Fridays at 1600 UTC (current time, may be ok when DST ends) [4]:
#openstack-meeting-alt, #openstack-meeting-3



I vote for Mondays at 1600 UTC

- ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org

wsFcBAEBCAAQBQJUNPnLCRAYkrQvzqrryAAAYrsP/3YV2hsDPye3LN8msmKh
XuQrVXrWsJtwFezfd0nxZXjEcoWzOS4eRWUh3Khw6FM0AISTDL1yQH9CReEW
ZPY60NPBunhdCYJIsIwVfOyQH6ucc7Z1nqwt30Nrb0eEMYvyrM2EYnFbkmkS
QzyshpCn7wGVjzHm6DCE/orMNkggSNehUySgFoUkdfmEcwkkXyCtCBXRLrOB
x9Of8tSPnwWRUELLQaI8V+xmkpf0cbcwJatz5X4OKa4Enjw/sdlGlnSv12xo
1HkmAXr30gpkI4DjqIbNdVASaKt+C0Y6YQlIALI/R6qzADxCo6IJ84ITAPlE
iNM6uQ837I5yV65sYqYIwSIIlG/AurFOjqmLDfXwHCdE4DrRCF193yBVRlHY
wWKhHSKoQ3KUBCZAQUdR13oxOOIKEgkUTYRhuq51dy4lZsAz69faLVUGWLSh
aoMmGBJCDOWkgwYDTpcTj+bH8aj4SaN6GhMfx8l4ddZmpLPepbzOgAg/HjnY
6+HAx3ZnNUdyDET9HFvgfF7jNf1bCeHzukd6eJ6uId+M6ctkuDPkb2ADAGu3
73CBJphvO1AzeJSykupgXWRln4qoUf4u4PExaqCL6sYWqYLuS7KC+K2fAQSV
/80rvlywoKRPJHVsTYKc96ageKwRtQOML1uZxuuVZUUV33fUPfH3+FBqMgUb
1kyS
=9Ly5
-END PGP SIGNATURE-


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


Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Vitaly Kramskikh
Nikolay,

Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
http://en.wikipedia.org/wiki/Single_Source_of_Truth, and you want to ruin
it for no reason.

Of course it makes no sense to generate anything. Checkboxes on the
settings tab can be added using simple YAML mixin and if you want to check
this checkbox to determine whether to perform some action or not and don't
want to write any python code, try to add to plugin's YAML restrictions
section which we already have for the settings tab, the wizard and roles.

2014-10-08 14:50 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

  Right now we already have like 2 types of plugins (extensions),
 classified by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
 or hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano, zabbix)

 That's not quite right. In 6.0 and after that there will be a lot of
 small plugins which only modify some config and/or install some
 package. There is nothing to configure here, and I as a plugin
 developer don't even want to know anything about checkboxes on UI. I
 just want two things: role to execute my command on and command
 itself. That's one small YAML.

 And autogenerating checkboxes for such plugins on UI is bad, because
 explicit is better than implicit (and all our settings are explicitly
 defined in openstack.yaml).

 On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak dshul...@mirantis.com
 wrote:
  If there is no checkboxes (read configuration) and plugin is installed -
 all
  deployment tasks will be applied
  to every environment, but why do you think that there will be no
 checkboxes
  in most cases?
 
  Right now we already have like 2 types of plugins (extensions),
 classified
  by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
  hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano,
  zabbix)
 
  In 1st case you need to provide shared configuration storage (like
 cluster
  attributes right now), in order for plugin
  to be able to exclude part of core workflow from running (not installing
  swift for example).
  In case if the plugin is self-contained entity, like Sahara, Murano right
  now - checkboxes would be simply required.
  It works this way right now, and it doesnot look like huge overhead.
 
  So what do you think, will it work or no?
 
  On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov nmar...@mirantis.com
 wrote:
 
  Hi,
 
  Frankly speaking, I'm not sure on how 1st approach will even work.
  What if plugin doesn't provide any checkboxes (and in most cases it
  won't)? How should we determine in serializer, which plugins should be
  applied while generating astute.yaml and tasks.yaml? Should we
  autogenerate some stuff for plugins which are not even enabled and do
  needless work?
 
  This looks too complicated for me from the backend side, and option
  with enabling/disabling plugins in wizard for specific environment (we
  can invent mechanism to disable them on env which is not deployed yet,
  besides, for API it's just one PUT) is MUCH simpler and much more
  obvious, as I see.
 
 
 
  On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
   Hi,
  
   I would go with the 1st approach. The thing I don't like in the 2nd
   approach
   is that we have to make the user enable plugin twice. For example, we
   have
   to enable Ceph as a plugin and then add Ceph role to nodes and choose
   what
   we want to store in Ceph (images, objects). Why we would need to
   explicitly
   enable Ceph plugin? Let's always show plugin options in wizard and
   settings
   tab, and if the user just doesn't want to enable Ceph, he would just
   leave
   all the checkboxes unchecked. The 2nd approach would also lead to some
   kind
   of inconsistency in case the user enabled Ceph plugin but left all the
   Ceph-related checkboxes unchecked and didn't add Ceph nodes.
  
   2014-10-07 21:17 GMT+07:00 Evgeniy L e...@mirantis.com:
  
   Hi,
  
   We had a meeting today about plugins on UI, as result of the meeting
   we have two approaches and this approaches affect not only UX but
   plugins itself.
  
   1st - disable/enable plugin on settings tab
  
   user installs the plugin
   creates a cluster
   configures and enables/disables plugins on settings tab
  
   For user it will look like Ceph plugin checkboxes on settings tab,
   if he enables checkbox, then we pass the parameter to orchestrator
   as `true`.
  
   Cons:
  
   plugin developer should define a checkbox in each plugin (for plugin
   disabling/enabling)
   on the backend we have to enable all of the plugins for environment,
   

Re: [openstack-dev] Virtual_machine for devstack

2014-10-08 Thread Angelo Matarazzo

Hi all,
sorry... I made mistake.
wrong mailing list

Cheers,
Angelo

On 08/10/2014 10:27, Angelo Matarazzo wrote:

Hi all,
I have prepared a virtual machine with ubuntu installed for devstack
In the /media/nas/nfs_shares/projects/Cloud/Openstack/devstack8_10_14/
There are
devstack8_10_14.ova for virtual box import
local.conf --configuration file for devstack
README_8_10_14 -- instructions

pls, read the instructions and for installing read carefully following 
sections


Prerequisites


Install devstack
==



Other sections:

Run devstack

Shutdown devstack

Install Liclipse
=
Use of Liclipse
=
Reinstall devstack
===
Connect to devstack
=
Git usage
==


Any review or comment is very welcome

cheers,
Angelo



___
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] [oslo] Meeting time

2014-10-08 Thread Ghe Rivero

I vote for Mondays and Thursdays.

Ghe Rivero

On 08/10/14 10:46, Mehdi Abaakouk wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



- Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
- Thursdays at 1600 UTC [2]: #openstack-meeting-3
- Thursdays at 1700 UTC [3]: #openstack-meeting-3
- Fridays at 1600 UTC (current time, may be ok when DST ends) [4]:
#openstack-meeting-alt, #openstack-meeting-3



I vote for Mondays at 1600 UTC

- ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org

wsFcBAEBCAAQBQJUNPnLCRAYkrQvzqrryAAAYrsP/3YV2hsDPye3LN8msmKh
XuQrVXrWsJtwFezfd0nxZXjEcoWzOS4eRWUh3Khw6FM0AISTDL1yQH9CReEW
ZPY60NPBunhdCYJIsIwVfOyQH6ucc7Z1nqwt30Nrb0eEMYvyrM2EYnFbkmkS
QzyshpCn7wGVjzHm6DCE/orMNkggSNehUySgFoUkdfmEcwkkXyCtCBXRLrOB
x9Of8tSPnwWRUELLQaI8V+xmkpf0cbcwJatz5X4OKa4Enjw/sdlGlnSv12xo
1HkmAXr30gpkI4DjqIbNdVASaKt+C0Y6YQlIALI/R6qzADxCo6IJ84ITAPlE
iNM6uQ837I5yV65sYqYIwSIIlG/AurFOjqmLDfXwHCdE4DrRCF193yBVRlHY
wWKhHSKoQ3KUBCZAQUdR13oxOOIKEgkUTYRhuq51dy4lZsAz69faLVUGWLSh
aoMmGBJCDOWkgwYDTpcTj+bH8aj4SaN6GhMfx8l4ddZmpLPepbzOgAg/HjnY
6+HAx3ZnNUdyDET9HFvgfF7jNf1bCeHzukd6eJ6uId+M6ctkuDPkb2ADAGu3
73CBJphvO1AzeJSykupgXWRln4qoUf4u4PExaqCL6sYWqYLuS7KC+K2fAQSV
/80rvlywoKRPJHVsTYKc96ageKwRtQOML1uZxuuVZUUV33fUPfH3+FBqMgUb
1kyS
=9Ly5
-END PGP SIGNATURE-


___
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] [oslo] Meeting time

2014-10-08 Thread Julien Danjou
On Tue, Oct 07 2014, Roman Podoliaka wrote:

 - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
 - Thursdays at 1600 UTC [2]: #openstack-meeting-3

One of these would be cool.

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


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


Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread joehuang
Hello, Duncan and Monty,

The discussion is more and more concrete, very good.

maybe we should just slap a REST api on it. The challenge of Node-pool REST 
API is What it will look like for these API, totally new API? current OS-API 
?. From cloud operators' feed back, OS-API is preferred. If we developed 
totally new API for Node-pool, it takes long time to grow API-ecosystem or 3rd 
party APP for it.

Best Regards
Chaoyi Huang ( joehuang )

-Original Message-
From: Duncan Thomas [mailto:duncan.tho...@gmail.com] 
Sent: Tuesday, October 07, 2014 11:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack 
cascading

On 7 October 2014 16:30, Monty Taylor mord...@inaugust.com wrote:

 Second BTW - you're certainly right about the first two in the global 
 list - we keep track of quota and usage ourselves inside of nodepool.
 Actually - since nodepool already does a bunch of these things - maybe 
 we should just slap a REST api on it...

Whether or not it does much for this use-case, Nodepool-aaS would definitely be 
useful I think, particularly if it was properly multi-tenant. It isn't /hard/ 
to set up, but it's effort and yet another cog to understand and debug.

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


Re: [openstack-dev] Usage of @author tags in the header of Python files

2014-10-08 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/10/14 09:30, Christian Berendt wrote:
 After proposing a change to Horizon to remove the @author tags from
 the header of Python files
 (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
 to discuss this first on the mailing list.
 
 Is it necessary to track the authorship of a file inside the file
 using @author tags?

Git is a lot better in attributing authorship, so for me, @author tags
are just a waste of precious disk bytes and cpu cycles.

 
 The copyright statement itself is unchanged and intact after the
 removal of the @author tags.
 
 The copyright statement is not addicted to the authorship of a file
 so it should be safe to remove the @author tags.
 
 The @author tag is not used in other projects. Neutron removed all 
 @author tags some time ago and there are no @author tags e.g. in
 Nova, or Cinder. There are even local hacking checks in Nova, and
 Neutron to not use @author tags.
 
 Christian.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUNQZZAAoJEC5aWaUY1u572BEIALXeJDUKp7LLp7Vsw7n3LkhQ
kDjUf/wm0ySNQ8+VLGzaI0BTGhCN4QlrCfdiRXjwI1AYMMcf7DLKGA9pah1hcoEq
xn2uiFce3qGp6KVIbKldVLBfzYTQlDnGBb/uGdrIT3WOyYC6Cj1LNte1AcrNgFLc
x/eDmsQUWp3cvGJReiEW7Gqtmo0DQHswwD70D4NS//nZKSIildeM5ucWpHgtI9k1
PsRNZDHr2Pyg2JRD0eEakW0nt5VICa1vOoCmsOCbVjluwU3XBXgsejHM2fbSeSNp
HnppdogRuZ+30xg9Ij+WbuX5FwMIRc+UTNVektqSkQa582/DcMpMTi/ySLmTH6U=
=33KY
-END PGP SIGNATURE-

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


[openstack-dev] [nova][vmware] VMware CI should vote -1 on test failures

2014-10-08 Thread Matthew Booth
It's just been pointed out to me that the CI formerly known as
Minesweeper doesn't vote -1 if its tests fail. Consequently, I haven't
been noticing its test failures. We no longer show CI comments in gerrit
by default, which is great because in general they're just noise.
However, if I see a -1 vote from CI I am prompted to go look for the
associated test failure. Because MS doesn't vote -1, test failures are
invisible.

Could we please change to having MS vote -1 for test failures? I am
happy for these votes to be purely advisory, but unless they're visible
they're not serving any useful purpose.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

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

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


[openstack-dev] TC Candidacy

2014-10-08 Thread Eoghan Glynn


Folks,

I would like to throw my hat into the ring for the upcoming Technical
Committee election.

I've been involved in the OpenStack community for nearly three years,
starting off by becoming core on glance, before moving my focus mainly
onto the ceilometer project. Along the way I've landed a smattering of
commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
and openstack-manuals, while contributing to the stable-maint effort
over multiple cycles.

More recently, I've served the ceilometer project as PTL over the Juno
cycle, and will be doing so again for Kilo.

I'm employed by Red Hat to work primarily upstream, but I also have
some perspective on the sausage machine that operates downstream in
order to put the technology we produce into the hands of users.

My motivation in running is to bring more perspective from a smaller
project to the deliberations of the TC, which I think already has a
tonne of large-project and cross-project perspective to draw on.
Balance is a good and healthy thing :)

As a community we have a big challenge ahead of us to figure out how
we respond to the growing pains that been felt in our governance
structure and cross-project resources. This has crystallized around
the recent layering and big tent discussions. My own feeling has
always been in favor of a big welcoming tent, but I'm less convinced
that a small blessed core is necessarily a corollary of such
inclusiveness. Before we radically alter the release cycle model
that's served us relatively well thus far, I think a critical eye
should be brought to the proposals; in particular we really need to
clearly identify the core problems that these proposed changes are
intended to solve.

And so, onwards to the stock questions ...

Topic: OpenStack Mission


How do you feel the technical community is doing in meeting the
OpenStack Mission?

In all honesty, I would give us an A+ for effort, but more like a B-
for execution. In our excitement and enthusiasm to add shiny new
features, we sometimes take our eye off the ball in terms of what's
needed to make the lives of our users easier. I'm as guilty of this as
anyone else, perhaps even more so. But I think at this stage, it would
be of much benefit to our user community if we swung the pendulum
somewhat in the other direction, and shifted some focus onto easing
the practical challenges of operating our stuff at scale.

Topic: Technical Committee Mission
==

How do you feel the technical committee is doing in meeting the
technical committee mission?

Well, to be honest, if I thought this couldn't be improved, I wouldn't
be running for election.

On the one hand, I felt the gap analysis for already-integrated
projects was a good and healthy thing, and certainly assisted in
focusing resources over Juno on the areas where the TC saw
deficiencies.

On the other hand, I was quite disheartened by how some of the TC
discussions around project status played out. IMO there was a failure
of due diligence and mentoring. If we continue to have the TC making
important determinations about the future of projects (whether it be
their integrated status or their production readiness), then I think
we need to ensure that the TC keeps itself fully appraised from an
earlier stage about the direction that the project is taking, and
gives fair warning when it feels that a project needs a
course-correction.

Topic: Contributor Motivation
=

How would you characterize the various facets of contributor
motivation?

Most of my prior opensource experience was on various Apache projects
and in contrast it's striking that the OpenStack contributor community
is on the whole more skewed away from pure volunteerism, and towards
corporate contributors. By that, I mean contributors who are employed
by major operators and distributors of OpenStack, where their day-job
is to go forth and make it better. On balance, this is actually a
strength in our community. It certainly aids in the continuity and
sustainability of effort. It also helps ensure that less glamorous,
but ultra-important, efforts such as stable-maint and vulnerability
management get the attention they deserve.

However, despite this skew, I'm well aware that we're building a
broad church here. I think we all benefit from active efforts to
build diversity in our contributor community and harness the energy of
contributors with all kinds of motivations. Not just because it's the
right-on thing to do, but because it's the *smart* thing to do
... ensuring that we get access to all of the talents, especially from
previously under-represented groups. Towards this end, I continue to
support the efforts of programs such as the GNOME OPW and their recent
moves towards extending their reach to a wider set of contributor
backgrounds.

Topic: Rate of Growth
=

There is no argument the OpenStack technical community has a
substantial rate of 

Re: [openstack-dev] Usage of @author tags in the header of Python files

2014-10-08 Thread Daniel P. Berrange
On Wed, Oct 08, 2014 at 09:30:42AM +0200, Christian Berendt wrote:
 After proposing a change to Horizon to remove the @author tags from the
 header of Python files (https://review.openstack.org/#/c/126656/)
 Matthias Runge proposed to discuss this first on the mailing list.
 
 Is it necessary to track the authorship of a file inside the file using
 @author tags?

The only time @author tags are remotely accurate is immediately after
a new file is merged. 6 months down the line when countless different
people have submitted  merged patches against the fie, the @author
tags are just plain wrong and/or misleading.  GIT does a far better
job of tracking authorship per line (eg git blame).  @author tags have
outlived their usefulness by many years.

 The copyright statement itself is unchanged and intact after the removal
 of the @author tags.
 
 The copyright statement is not addicted to the authorship of a file so
 it should be safe to remove the @author tags.

The Copyright lines directly reference the entity asserting copyright
ownership. They aren't conected to / dependant on the @author tags, not
least because the person who authored the code won't be the entity who
actually holds copyright in the case of most corporate contributions.

 The @author tag is not used in other projects. Neutron removed all
 @author tags some time ago and there are no @author tags e.g. in Nova,
 or Cinder. There are even local hacking checks in Nova, and Neutron to
 not use @author tags.

Yep, we removed the few cases where people added @author in Nova and added
the hacking rule to prevent their reintroduction. I see no reason not todo
the same across all openstack projects.

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

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


[openstack-dev] [Ceilometer] Juno RC2 available

2014-10-08 Thread Thierry Carrez
Hello everyone,

Due to a number of issues discovered in the published Ceilometer 2014.2
RC1, we generated a new Juno release candidate. You can find the list of
bugfixes in this RC and a link to a source tarball at:

https://launchpad.net/ceilometer/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Ceilometer
2014.2 on October 16. You are therefore strongly encouraged to test and
validate this tarball !

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/ceilometer/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's
attention.

Regards,

-- 
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] Usage of @author tags in the header of Python files

2014-10-08 Thread Sam Betts (sambetts)
On 08/10/2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/10/14 09:30, Christian Berendt wrote:
 After proposing a change to Horizon to remove the @author tags from
 the header of Python files
 (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
 to discuss this first on the mailing list.
 
 Is it necessary to track the authorship of a file inside the file
 using @author tags?

Git is a lot better in attributing authorship, so for me, @author tags
are just a waste of precious disk bytes and cpu cycles.

+1 


 
 The copyright statement itself is unchanged and intact after the
 removal of the @author tags.
 
 The copyright statement is not addicted to the authorship of a file
 so it should be safe to remove the @author tags.
 
 The @author tag is not used in other projects. Neutron removed all
 @author tags some time ago and there are no @author tags e.g. in
 Nova, or Cinder. There are even local hacking checks in Nova, and
 Neutron to not use @author tags.
 
 Christian.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUNQZZAAoJEC5aWaUY1u572BEIALXeJDUKp7LLp7Vsw7n3LkhQ
kDjUf/wm0ySNQ8+VLGzaI0BTGhCN4QlrCfdiRXjwI1AYMMcf7DLKGA9pah1hcoEq
xn2uiFce3qGp6KVIbKldVLBfzYTQlDnGBb/uGdrIT3WOyYC6Cj1LNte1AcrNgFLc
x/eDmsQUWp3cvGJReiEW7Gqtmo0DQHswwD70D4NS//nZKSIildeM5ucWpHgtI9k1
PsRNZDHr2Pyg2JRD0eEakW0nt5VICa1vOoCmsOCbVjluwU3XBXgsejHM2fbSeSNp
HnppdogRuZ+30xg9Ij+WbuX5FwMIRc+UTNVektqSkQa582/DcMpMTi/ySLmTH6U=
=33KY
-END PGP SIGNATURE-

___
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] Usage of @author tags in the header of Python files

2014-10-08 Thread Duncan Thomas
On 8 October 2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:
 On 08/10/14 09:30, Christian Berendt wrote:
 After proposing a change to Horizon to remove the @author tags from
 the header of Python files
 (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
 to discuss this first on the mailing list.

 Is it necessary to track the authorship of a file inside the file
 using @author tags?

 Git is a lot better in attributing authorship, so for me, @author tags
 are just a waste of precious disk bytes and cpu cycles.

The tags also make people worried about changing 'somebody else's
thing', are difficult to make meaningful over time (how much of a
function do you need to change to claim authorship of it) and
generally give no significant benefit. While I don't currently work on
Horizon, I vote for scrapping them and putting a hacking check in to
keep them out.

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


[openstack-dev] [nova-specs] WARNING: document isn't included in any toctree

2014-10-08 Thread Manickam, Kanagaraj
Hi,

I tried to add a spec under specs/kilo folder and got the following exception:

ERROR: InvocationError: 
'/home/jenkins/workspace/gate-nova-specs-docs/.tox/venv/bin/python setup.py 
build_sphinx'

http://logs.openstack.org/66/126866/1/check/gate-nova-specs-docs/c00edfe/console.html


Can anyone please help here to fix it.

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


Re: [openstack-dev] Quota management and enforcement across projects

2014-10-08 Thread Davanum Srinivas
Salvatore, Joe,

We do have this at the moment:

https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py

-- dims

On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando sorla...@nicira.com wrote:

 On 8 October 2014 04:13, Joe Gordon joe.gord...@gmail.com wrote:


 On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg
 morgan.fainb...@gmail.com wrote:

 Keeping the enforcement local (same way policy works today) helps limit
 the fragility, big +1 there.

 I also agree with Vish, we need a uniform way to talk about quota
 enforcement similar to how we have a uniform policy language / enforcement
 model (yes I know it's not perfect, but it's far closer to uniform than
 quota management is).


 It sounds like maybe we should have an oslo library for quotas? Somewhere
 where we can share the code,but keep the operations local to each service.


 This is what I had in mind as well. A simple library for quota enforcement
 which can be used regardless of where and how you do it, which might depend
 on the application business logic, the WSGI framework in use, or other
 factors.




 If there is still interest of placing quota in keystone, let's talk about
 how that will work and what will be needed from Keystone . The previous
 attempt didn't get much traction and stalled out early in implementation. If
 we want to revisit this lets make sure we have the resources needed and
 spec(s) in progress / info on etherpads (similar to how the multitenancy
 stuff was handled at the last summit) as early as possible.


 Why not centralize quota management via the python-openstackclient, what
 is the benefit of getting keystone involved?


 Providing this through the openstack client in my opinion has the
 disadvantage that users which either use the REST API direct or write their
 own clients won't leverage it. I don't think it's a reasonable assumption
 that everybody will use python-openstackclient, is it?

 Said that, storing quotas in keystone poses a further challenge to the
 scalability of the system, which we shall perhaps address by using
 appropriate caching strategies and leveraging keystone notifications. Until
 we get that, I think that the openstack client will be the best way of
 getting a unified quota management experience.

 Salvatore



 Cheers,
 Morgan

 Sent via mobile


 On Friday, October 3, 2014, Salvatore Orlando sorla...@nicira.com
 wrote:

 Thanks Vish,

 this seems a very reasonable first step as well - and since most
 projects would be enforcing quotas in the same way, the shared library 
 would
 be the logical next step.
 After all this is quite the same thing we do with authZ.

 Duncan is expressing valid concerns which in my opinion can be addressed
 with an appropriate design - and a decent implementation.

 Salvatore

 On 3 October 2014 18:25, Vishvananda Ishaya vishvana...@gmail.com
 wrote:

 The proposal in the past was to keep quota enforcement local, but to
 put the resource limits into keystone. This seems like an obvious first
 step to me. Then a shared library for enforcing quotas with decent
 performance should be next. The quota calls in nova are extremely
 inefficient right now and it will only get worse when we try to add
 hierarchical projects and quotas.

 Vish

 On Oct 3, 2014, at 7:53 AM, Duncan Thomas duncan.tho...@gmail.com
 wrote:

  Taking quota out of the service / adding remote calls for quota
  management is going to make things fragile - you've somehow got to
  deal with the cases where your quota manager is slow, goes away,
  hiccups, drops connections etc. You'll also need some way of
  reconciling actual usage against quota usage periodically, to detect
  problems.
 
  On 3 October 2014 15:03, Salvatore Orlando sorla...@nicira.com
  wrote:
  Hi,
 
  Quota management is currently one of those things where every
  openstack
  project does its own thing. While quotas are obviously managed in a
  similar
  way for each project, there are subtle differences which ultimately
  result
  in lack of usability.
 
  I recall that in the past there have been several calls for unifying
  quota
  management. The blueprint [1] for instance, hints at the possibility
  of
  storing quotas in keystone.
  On the other hand, the blazar project [2, 3] seems to aim at solving
  this
  problem for good enabling resource reservation and therefore
  potentially
  freeing openstack projects from managing and enforcing quotas.
 
  While Blazar is definetely a good thing to have, I'm not entirely
  sure we
  want to make it a required component for every deployment. Perhaps
  single
  projects should still be able to enforce quota. On the other hand,
  at least
  on paper, the idea of making Keystone THE endpoint for managing
  quotas,
  and then letting the various project enforce them, sounds promising
  - is
  there any reason for which this blueprint is stalled to the point
  that it
  seems forgotten now?
 
  I'm coming to the mailing list with these random questions 

Re: [openstack-dev] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets

2014-10-08 Thread Akihiro Motoki
Thanks Henry for moving forward the discussion in Neutron IPv6 meeting
yesterday.
Looking around the related bugs and reviews, I believe it sounds a
good idea to disable PUT for IPv6_ra/address_mode attributes in Juno
release.

Thanks,
Akihiro

On Wed, Oct 8, 2014 at 1:21 AM, Henry Gessau ges...@cisco.com wrote:
 A number of bugs[1][2][3] have been filed which are related to updating the
 IPv6 attributes after a subnet has been created.

 In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
 questions have been raised, which were discussed in today's IPv6 IRC 
 meeting[6].

 Summary:
 In Juno we are not ready for allowing the IPv6 attributes on a subnet to be
 updated after the subnet is created, because:
 - The implementation for supporting updates is incomplete.
 - Perceived lack of usefulness, no good use cases known yet.
 - Allowing updates causes more complexity in the code.
 - Have not tested that radvd, dhcp, etc. behave OK after update.

 Therefore we are proposing to change 'allow_put' to False for the two IPv6
 attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes
 from being updated via the PUT:subnets API.

 We would be interested to hear of any disagreements or questions.


 [1] https://launchpad.net/bugs/1362966
 [2] https://launchpad.net/bugs/1363064
 [3] https://launchpad.net/bugs/1373417
 [4] https://review.openstack.org/125328
 [5] https://review.openstack.org/117799
 [6]
 http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html

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



-- 
Akihiro Motoki amot...@gmail.com

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


Re: [openstack-dev] [nova-specs] WARNING: document isn't included in any toctree

2014-10-08 Thread Davanum Srinivas
Kanagaraj,

Drop it in specs/kilo/approved/ should work fine.

-- dims

On Wed, Oct 8, 2014 at 7:01 AM, Manickam, Kanagaraj
kanagaraj.manic...@hp.com wrote:
 Hi,



 I tried to add a spec under specs/kilo folder and got the following
 exception:



 ERROR: InvocationError:
 '/home/jenkins/workspace/gate-nova-specs-docs/.tox/venv/bin/python setup.py
 build_sphinx'



 http://logs.openstack.org/66/126866/1/check/gate-nova-specs-docs/c00edfe/console.html





 Can anyone please help here to fix it.



 Regards

 Kanagaraj M


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




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

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


Re: [openstack-dev] [Neutron] How to write extension

2014-10-08 Thread Mathieu Rohon
Hi,

please tell us about the extension you want to write, it would really help.
In ML2, you now have the ability to easily add extensions thanks to this work :

https://blueprints.launchpad.net/neutron/+spec/extensions-in-ml2

Mathieu

On Wed, Oct 8, 2014 at 7:52 AM, Damon Wang damon.dev...@gmail.com wrote:
 Hi Kapłoński,

 I recommend you to read these materials:

 Keynotes:
 https://www.openstack.org/assets/presentation-media/insideneutron2.pdf
 Video:
 https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/deep-dive-into-neutron
 Post:
 http://control-that-vm.blogspot.com/2014/05/writing-api-extensions-in-neutron.html

 Regards,
 Wang Wei

 2014-10-08 3:29 GMT+08:00 Sławek Kapłoński sla...@kaplonski.pl:

 Hello,

 Can You send me some examples or link to tutorial how to write extension
 to
 neutron. I'm using ML2 plugin in neutron and I want to add some new
 functionality and API methods to this neutron. So imho I should do it via
 extension but how exactly write it that it will work in existing ML2
 plugin?

 ---
 Best regards
 Sławek Kapłoński
 sla...@kaplonski.pl
 ___
 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] [I18N] compiling translation message catalogs

2014-10-08 Thread James Page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/10/14 18:00, Julie Pichon wrote:
 I'm adding a couple of people on cc: with an interest in Ubuntu and
 SUSE packaging: the Horizon team would love to have your opinion on
 this (it came up during our weekly meeting).
 
 The current consensus is leaning toward removing the mo files for
 Juno RC2 (in a couple of days) rather than wait until Kilo, as this
 has been a pain point for (some/all?) distros for a while.

I'm in agreement that option a) is the best way to go; on the
assumption that compiling the message catalogs won't bring in
requirements for new dependencies, we can deal with that for rc2 in
Ubuntu for Juno.

 
 Thank you,
 
 Julie
 
 On 01/10/14 17:04, Akihiro Motoki wrote:
 Hi,
 
 To display localized strings, we need to compile translated
 message catalogs (PO files) into compiled one (MO files). I would
 like to discuss and get a consensus who and when generate 
 compiled message catalogs. Inputs from packagers are really
 appreciated.
 
 [The current status] * Horizon contains compile message catalogs
 in the git repo. (It is just a history and there seems no strong
 reason to have compiled one in the repo. There is a bug report on
 it.) * Other all projects do not contain compiled message
 catalogs and have only PO files.
 
 [Possible choices] I think there are several options. (there may
 be other options) (a) OpenStack does not distribute compiled
 message catalogs, and only provides a command (setup.py
 integration) to compile message catalogs. Deployers or
 distributors need to compile message catalogs. (b) Similar to
 (a), but compile message catalogs as a part of pip install. (c)
 OpenStack distributes compiled message catalogs as a part of the
 release. (c1) the git repo maintains compiled message catalogs. 
 (c2) only tarball contains compiled message catalogs
 
 Note that the current Horizon is (c1) and others are (a).
 
 [Pros/Cons] (a) It is a simplest way as OpenStack upstream. 
 Packagers need to compile message catalogs and customize there
 scripts. Deployers who install openstack from the source need to
 compile them too. (b) It might be a simple approach from users
 perspective. However to compile message catalogs during
 installation, we need to install required modules (like babel or
 django) before running installation (or require them as the
 first citizen in setup.py require). I don't think it is much
 simpler compared to option (a). (c1) Compiled message catalogs
 are a kind of binary files and they can be generated from PO
 files. There is no need to manage two same data. (c2) OpenStack
 is downloaded in several ways (release tarballs is not the only
 option), so I don't see much merits that the only tarball
 contains compiled message catalogs. A merit is that compiled
 message catalogs are available and there is no additional step
 users need to do.
 
 My preference is (a), but would like to know broader opinions 
 especially from packagers.
 
 Thanks, Akihiro
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 
- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUNTNeAAoJEL/srsug59jD2aoQAKAwvKgL0WLn8ZDqX5KGfX2R
OrTaNcozlNk2OXHgt2nDxOce6yQTbhh4yMJHsymOvgKj4+yOz5L78k9wkRgDmvqX
b6oiUIGjnQTiVQylT9FRuXicb/I5aoHOr2ki7LCHZ0QuABFCSC7noE/e4KnX2a0g
baaEC57UZa3aKepQ0PVQP50F5zGF5ux5jlP3oXtKtNjUL9l5bnTmwVgF8ymOYCZd
Q2fNU3CGUGG9LWwH6WmNJSKEkqGEP8+W7QEcXxT3/JhnVtYIJY/LehfLI8mUGu6o
geFfZqTYM5qOUrdCjFLJE8ayTE0jtM4VIUAX6xxkZNM4sdXdbH15N5UPqUFBRGsj
h/P/L/79qSMCt21eQBeaSDEKUvO6egG31tVpk7xTr6PIwRH8t5R+vXjPGjGqc78m
wdEhO8tMhEangeIbM5fKVKpQ9oqmp7SiI0sFzBS7eKRlB0VMbKCPegaBq8WJDbJq
/URCXYhgtFKTVCDpR5TUUkmhbHkc9NNcXQudJRnTscjy2VNmWI/QuSg7nHnP218H
cASWq1kUHvE7grncvaXyr3jPrKnSP2yVSqLsAOBYP5trb3ci9Sdyw+ajsPeLO8cB
bxEFPETfq5Oz/GEN6ojLr45gbqDuM5MY7pivD/y/4br/cmYtd8R8s/pD0kxn5o6Z
Www0BJtH1h1b2ChPlo+O
=CLi/
-END PGP SIGNATURE-

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


[openstack-dev] [VMware][nova][cinder]an issue about single point of failure

2014-10-08 Thread LiuJeremy

Hi,

I have an issue about single point of failure in OpenStack+VMware scenario.
If one nova-compute or cinder-volume crush. The VCenter which connect to
the nova-compute or cinder-volume will unavailable.

I think we can deploy the nova-compute/cinder-volume to a VM which have the HA
(High Available) capacity.

What do you think about the above solution? And could you provide another 
solution,
especially in physical deployment scenario (deploy the 
nova-compute/cinder-volume
in a physical host)?

Thanks,

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


Re: [openstack-dev] [All] [I18N] compiling translation message catalogs

2014-10-08 Thread Tom Fifield
On 08/10/14 20:51, James Page wrote:
 On 07/10/14 18:00, Julie Pichon wrote:
 I'm adding a couple of people on cc: with an interest in Ubuntu and
 SUSE packaging: the Horizon team would love to have your opinion on
 this (it came up during our weekly meeting).
 
 The current consensus is leaning toward removing the mo files for
 Juno RC2 (in a couple of days) rather than wait until Kilo, as this
 has been a pain point for (some/all?) distros for a while.
 
 I'm in agreement that option a) is the best way to go; on the
 assumption that compiling the message catalogs won't bring in
 requirements for new dependencies, we can deal with that for rc2 in
 Ubuntu for Juno.

I've put some information for you on what it takes to compile messages
over at:
https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1377923

 
 Thank you,
 
 Julie
 
 On 01/10/14 17:04, Akihiro Motoki wrote:
 Hi,

 To display localized strings, we need to compile translated
 message catalogs (PO files) into compiled one (MO files). I would
 like to discuss and get a consensus who and when generate
 compiled message catalogs. Inputs from packagers are really
 appreciated.

 [The current status] * Horizon contains compile message catalogs
 in the git repo. (It is just a history and there seems no strong
 reason to have compiled one in the repo. There is a bug report on
 it.) * Other all projects do not contain compiled message
 catalogs and have only PO files.

 [Possible choices] I think there are several options. (there may
 be other options) (a) OpenStack does not distribute compiled
 message catalogs, and only provides a command (setup.py
 integration) to compile message catalogs. Deployers or
 distributors need to compile message catalogs. (b) Similar to
 (a), but compile message catalogs as a part of pip install. (c)
 OpenStack distributes compiled message catalogs as a part of the
 release. (c1) the git repo maintains compiled message catalogs.
 (c2) only tarball contains compiled message catalogs

 Note that the current Horizon is (c1) and others are (a).

 [Pros/Cons] (a) It is a simplest way as OpenStack upstream.
 Packagers need to compile message catalogs and customize there
 scripts. Deployers who install openstack from the source need to
 compile them too. (b) It might be a simple approach from users
 perspective. However to compile message catalogs during
 installation, we need to install required modules (like babel or
 django) before running installation (or require them as the
 first citizen in setup.py require). I don't think it is much
 simpler compared to option (a). (c1) Compiled message catalogs
 are a kind of binary files and they can be generated from PO
 files. There is no need to manage two same data. (c2) OpenStack
 is downloaded in several ways (release tarballs is not the only
 option), so I don't see much merits that the only tarball
 contains compiled message catalogs. A merit is that compiled
 message catalogs are available and there is no additional step
 users need to do.

 My preference is (a), but would like to know broader opinions
 especially from packagers.

 Thanks, Akihiro

 ___ 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] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Nikolay Markov
Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
they should do is  installing a package and modify a couple of config files
(run a shell command).
These ones have nothing to do with UI or any checkboxes, aren't they?
08 Окт 2014 г. 12:49 пользователь Vitaly Kramskikh 
vkramsk...@mirantis.com написал:

 Nikolay,

 Currently every thing that can be turned into a plugin (Ceph, vCenter,
 Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
 controls) for the settings tab. Why change this approach for plugins? The
 settings tab (cluster attributes) currently is a SSOT
 http://en.wikipedia.org/wiki/Single_Source_of_Truth, and you want to
 ruin it for no reason.

 Of course it makes no sense to generate anything. Checkboxes on the
 settings tab can be added using simple YAML mixin and if you want to check
 this checkbox to determine whether to perform some action or not and don't
 want to write any python code, try to add to plugin's YAML restrictions
 section which we already have for the settings tab, the wizard and roles.

 2014-10-08 14:50 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

  Right now we already have like 2 types of plugins (extensions),
 classified by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
 or hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano, zabbix)

 That's not quite right. In 6.0 and after that there will be a lot of
 small plugins which only modify some config and/or install some
 package. There is nothing to configure here, and I as a plugin
 developer don't even want to know anything about checkboxes on UI. I
 just want two things: role to execute my command on and command
 itself. That's one small YAML.

 And autogenerating checkboxes for such plugins on UI is bad, because
 explicit is better than implicit (and all our settings are explicitly
 defined in openstack.yaml).

 On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak dshul...@mirantis.com
 wrote:
  If there is no checkboxes (read configuration) and plugin is installed
 - all
  deployment tasks will be applied
  to every environment, but why do you think that there will be no
 checkboxes
  in most cases?
 
  Right now we already have like 2 types of plugins (extensions),
 classified
  by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
  hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano,
  zabbix)
 
  In 1st case you need to provide shared configuration storage (like
 cluster
  attributes right now), in order for plugin
  to be able to exclude part of core workflow from running (not installing
  swift for example).
  In case if the plugin is self-contained entity, like Sahara, Murano
 right
  now - checkboxes would be simply required.
  It works this way right now, and it doesnot look like huge overhead.
 
  So what do you think, will it work or no?
 
  On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov nmar...@mirantis.com
 wrote:
 
  Hi,
 
  Frankly speaking, I'm not sure on how 1st approach will even work.
  What if plugin doesn't provide any checkboxes (and in most cases it
  won't)? How should we determine in serializer, which plugins should be
  applied while generating astute.yaml and tasks.yaml? Should we
  autogenerate some stuff for plugins which are not even enabled and do
  needless work?
 
  This looks too complicated for me from the backend side, and option
  with enabling/disabling plugins in wizard for specific environment (we
  can invent mechanism to disable them on env which is not deployed yet,
  besides, for API it's just one PUT) is MUCH simpler and much more
  obvious, as I see.
 
 
 
  On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
   Hi,
  
   I would go with the 1st approach. The thing I don't like in the 2nd
   approach
   is that we have to make the user enable plugin twice. For example, we
   have
   to enable Ceph as a plugin and then add Ceph role to nodes and choose
   what
   we want to store in Ceph (images, objects). Why we would need to
   explicitly
   enable Ceph plugin? Let's always show plugin options in wizard and
   settings
   tab, and if the user just doesn't want to enable Ceph, he would just
   leave
   all the checkboxes unchecked. The 2nd approach would also lead to
 some
   kind
   of inconsistency in case the user enabled Ceph plugin but left all
 the
   Ceph-related checkboxes unchecked and didn't add Ceph nodes.
  
   2014-10-07 21:17 GMT+07:00 Evgeniy L e...@mirantis.com:
  
   Hi,
  
   We had a meeting today about plugins on UI, as result of the meeting
   we have two approaches and this approaches affect not only UX but
   plugins itself.
  
   1st - disable/enable plugin on settings tab
  
   user installs the plugin
   creates a cluster
   configures and enables/disables plugins on settings 

[openstack-dev] [Fuel] Documentation Process changed

2014-10-08 Thread Sergii Golovatiuk
Hi,

On Fuel Summit '2014 we discussed our Documentation process. According to
follow up we aligned it to OpenStack 'DocImpact' process. The new process
has been tested on background by me and Bogdan Dobrelya. Today, I have
updated Fuel Documentation Process
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Documentation so
we are making it official.

Why?
Developer perspective:
It gives more flexibility for the developers to participate in
Documentation Process. Every time when the Reviewer sees that patch
requires Documentation update, it may ask the Commiter to update 'Commit
Message' with DocImpact message. Once patch passes the review Openstack
Infra will trigger a new bug in Launchpad that should be assigned to Fuel
Documentation team.

From Fuel Documentation Team perspective:
When Fuel Documentation Team sees this bug they know who was the commiter
and reviewers and whom they should add for documentation review.

Community:
Community member may ask the developer to put 'DocImpact' message when it's
required.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [QA] Future of Tempest CLI tests

2014-10-08 Thread Matthew Treinish

Hi Everyone,

As we are moving into the kilo cycle and now that DepFreeze has ended the door
has been opened for adding tempest-lib to the requirements list:

https://review.openstack.org/122478

Once that lands we'll be able to start using tempest-lib in projects. The first
use for tempest-lib will be for the CLI testing framework. The patch migrating
tempest to use the version from the library is here:

https://review.openstack.org/117649

So, what does this mean for the future of the cli tests in tempest. By the end
of the cycle my goal is to hopefully have them completely removed from Tempest
and moved into each respective client repo. This is something that has been
discussed many times before and is finally going to be simple migration with
tempest-lib. This provides 2 large advantages, the first being we're starting
the process of slimming down tempest to be more targeted. The 2nd advantage is
that the restrictions on cli testing that have existed in Tempest will no longer
hold for project specific versions of the testing. It will be up to each
individual project to determine how and what they are they are testing, which
should ideally be a much larger set than the simple read-only tests which
existed in tempest.

These tests have always been out of place in the tempest tree, which is all
about consuming and testing via the REST APIs, and we only added them originally
because it was a convenient location to do functional testing against a running
deployment. This is why they've had the restriction of being simple read-only
tests. However, it is no longer nearly as difficult to do this type of
functional testing with infra so there is no need to keep these tests in the
tempest tree.

For the time being I've gone through and blocked any Tempest patches that would
interfere with the patch that migrates to using tempest-lib for the CLI
framework. Once the tempest migration to using tempest-lib for CLI testing lands
I'll unblock any changes. As CLI tests are spun up in python-*client repos we
will remove the corresponding tests from tempest and add them to the functional
tests. New cli test proposals to Tempest will not be blocked until there is a
corresponding functional test suite is in the client being tested. But, I think
working on adding functional testing to the clients should be considered a
priority over expanding the tests in tempest.


Thanks,

Matt Treinish


pgpNLA6Jnc9lM.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [QA] Meeting Thursday October 9th at 17:00 UTC

2014-10-08 Thread Matthew Treinish
Hi Everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
this Thursday, October 9th at 17:00 UTC in the #openstack-meeting channel.

The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

It's also worth noting that a few weeks ago we started having a regular
dedicated Devstack topic during the meetings. So if anyone is interested in
Devstack development please join the meetings to be a part of the discussion.

To help people figure out what time 17:00 UTC is in other timezones tomorrow's
meeting will be at:

13:00 EDT
02:00 JST
02:30 ACST
19:00 CEST
12:00 CDT
10:00 PDT

-Matt Treinish


pgpvis6ncq5kl.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] adding James Carey to oslo-i18n-core

2014-10-08 Thread Doug Hellmann

On Sep 23, 2014, at 5:03 PM, Doug Hellmann d...@doughellmann.com wrote:

 James Carey (jecarey) from IBM has done the 3rd most reviews of oslo.i18n 
 this cycle [1]. His feedback has been useful, and I think he would be a good 
 addition to the team for maintaining oslo.i18n.
 
 Let me know what you think, please.
 
 Doug
 
 [1] http://stackalytics.com/?module=oslo.i18n

Welcome to the team, James!

Sorry for the delay in circling back to take care of this.

Doug


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


Re: [openstack-dev] [VMware][nova][cinder]an issue about single point of failure

2014-10-08 Thread Duncan Thomas
Work is underway in cinder to allow active/active HA (or
active/active/active/... for the truly paranoid) volume managers for a
single backend, for remote backends that can support it. This is
likely to take most of the Kilo cycle to finish.

You can use pacemaker or other H/A technology (I suspect some sort of
monitored VM is the VMWare equivalent) to improve the availability of
cinder-volume in the current release.



On 8 October 2014 13:58, LiuJeremy jeremy-...@outlook.com wrote:

 Hi,

 I have an issue about single point of failure in OpenStack+VMware 
 scenario.
 If one nova-compute or cinder-volume crush. The VCenter which connect to
 the nova-compute or cinder-volume will unavailable.

 I think we can deploy the nova-compute/cinder-volume to a VM which have the HA
 (High Available) capacity.

 What do you think about the above solution? And could you provide another 
 solution,
 especially in physical deployment scenario (deploy the 
 nova-compute/cinder-volume
 in a physical host)?

 Thanks,

 Jeremy Liu

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



-- 
Duncan Thomas

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


Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Evgeniy L
Hi,

Vitaly, I understand your concerns about UX.
But there are technical problems and statements which affect
plugin developer and makes his live more complicated.

My opinion is we definitely should know, if plugin is disabled
or if it's enabled for specific environment.

1. plugin developer defines tasks, like I want the script to be
executed on nodes with controller role and I don't think that
he expects this task to be run on all of the nodes, also
I don't think that we want ask plugin developer to parse
yaml with bash in order to understand if his plugin is enabled,
it's a bad design
2. there will be no way to uninstall the plugin, because all of the
plugins are enabled on the environments, even if user doesn't
use them

Also I don't think that it's a good interface, to ask plugin developr
to include checkbox in each plugin.

The second solution is discussed because it's the most explicit
way to solve described problem.

Let's try to figure out the solution which will work well for user
and for plugin developer.

For example, for each plugin generate section on UI with checkbox
Like:

GlusterFS [ ] - disable all of the fields for the section
Here is some description of the section, which we can take from
description field.

IP address [127.0.0.1] - this field provides plugin developer

If plugin is set, we add env - plugin relation, if it's unset, we
delete it.
Also when user checks the checkbox, UI will be able to retrieve
attributes which plugin provides. But it's not so easy todo, I'm not
sure if we can do it with hooks, but it's possible with some separate
model and handlers.

Thanks,

On Wed, Oct 8, 2014 at 12:48 PM, Vitaly Kramskikh vkramsk...@mirantis.com
wrote:

 Nikolay,

 Currently every thing that can be turned into a plugin (Ceph, vCenter,
 Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
 controls) for the settings tab. Why change this approach for plugins? The
 settings tab (cluster attributes) currently is a SSOT
 http://en.wikipedia.org/wiki/Single_Source_of_Truth, and you want to
 ruin it for no reason.

 Of course it makes no sense to generate anything. Checkboxes on the
 settings tab can be added using simple YAML mixin and if you want to check
 this checkbox to determine whether to perform some action or not and don't
 want to write any python code, try to add to plugin's YAML restrictions
 section which we already have for the settings tab, the wizard and roles.

 2014-10-08 14:50 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

  Right now we already have like 2 types of plugins (extensions),
 classified by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
 or hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano, zabbix)

 That's not quite right. In 6.0 and after that there will be a lot of
 small plugins which only modify some config and/or install some
 package. There is nothing to configure here, and I as a plugin
 developer don't even want to know anything about checkboxes on UI. I
 just want two things: role to execute my command on and command
 itself. That's one small YAML.

 And autogenerating checkboxes for such plugins on UI is bad, because
 explicit is better than implicit (and all our settings are explicitly
 defined in openstack.yaml).

 On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak dshul...@mirantis.com
 wrote:
  If there is no checkboxes (read configuration) and plugin is installed
 - all
  deployment tasks will be applied
  to every environment, but why do you think that there will be no
 checkboxes
  in most cases?
 
  Right now we already have like 2 types of plugins (extensions),
 classified
  by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
  hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano,
  zabbix)
 
  In 1st case you need to provide shared configuration storage (like
 cluster
  attributes right now), in order for plugin
  to be able to exclude part of core workflow from running (not installing
  swift for example).
  In case if the plugin is self-contained entity, like Sahara, Murano
 right
  now - checkboxes would be simply required.
  It works this way right now, and it doesnot look like huge overhead.
 
  So what do you think, will it work or no?
 
  On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov nmar...@mirantis.com
 wrote:
 
  Hi,
 
  Frankly speaking, I'm not sure on how 1st approach will even work.
  What if plugin doesn't provide any checkboxes (and in most cases it
  won't)? How should we determine in serializer, which plugins should be
  applied while generating astute.yaml and tasks.yaml? Should we
  autogenerate some stuff for plugins which are not even enabled and do
  needless work?
 
  This looks too complicated for me from the backend side, and option
  with enabling/disabling plugins in 

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

2014-10-08 Thread Doug Hellmann

On Oct 8, 2014, at 1:22 AM, Robert Collins robe...@robertcollins.net wrote:

 On 8 October 2014 11:10, Mike Bayer mba...@redhat.com wrote:
 Hi folks -
 
 So just to update on the status here, for the transactional testing and all 
 that, I’ve had a blueprint in the queue for quite awhile:
 
 ...
 
 I'll probably time it out upstream if I can't get a review and just
 drop it straight into testtools. That said, I'm still AWL from
 everything dealing with this personal matter. Once thats resolved I'll
 be full steam on unblocking things for this patch set of yours.
 
 If you want to move forward without me - backporting the fixes to
 testtools would be a good start, jml or thomi or jelmer (amongst
 others) can review and land and do a release - I'm not critical path.

I know you put together a PoC (maybe more) showing how to make this work for 
namespace packages. I wonder if this is just another example of a reason to 
stop using them, though?

Does it make sense to move ahead with separate test suite instances and come 
back to unify that when we resolve the package issue?

Doug


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


Re: [openstack-dev] [oslo] Meeting time

2014-10-08 Thread Doug Hellmann

On Oct 8, 2014, at 5:20 AM, Julien Danjou jul...@danjou.info wrote:

 On Tue, Oct 07 2014, Roman Podoliaka wrote:
 
 - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
 - Thursdays at 1600 UTC [2]: #openstack-meeting-3
 
 One of these would be cool.
 
 -- 
 Julien Danjou
 -- Free Software hacker
 -- http://julien.danjou.info
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think we’re converging, but let’s do this with doodle instead of spamming the 
dev list.

Please vote here: http://doodle.com/zv8izg7ymxcank34

Doug


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


[openstack-dev] Info on XenAPI data format for 'host_data' call

2014-10-08 Thread Daniel P. Berrange
I'm doing some work on the get_available_resource method and need
to understand what data format XenAPI returns for the following
RPC call:

   data = call_xenhost(self._session, host_data, {})

I don't have any suitable XenServer hosts to test on myself, so if
anyone can provide a raw/json dump of the complete dataset returned
for this call on a real XenServer host, that would be very helpful


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

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


Re: [openstack-dev] TC Candidacy

2014-10-08 Thread Tristan Cacqueray
confirmed

On 08/10/14 05:51 AM, Eoghan Glynn wrote:
 
 
 Folks,
 
 I would like to throw my hat into the ring for the upcoming Technical
 Committee election.
 
 I've been involved in the OpenStack community for nearly three years,
 starting off by becoming core on glance, before moving my focus mainly
 onto the ceilometer project. Along the way I've landed a smattering of
 commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
 and openstack-manuals, while contributing to the stable-maint effort
 over multiple cycles.
 
 More recently, I've served the ceilometer project as PTL over the Juno
 cycle, and will be doing so again for Kilo.
 
 I'm employed by Red Hat to work primarily upstream, but I also have
 some perspective on the sausage machine that operates downstream in
 order to put the technology we produce into the hands of users.
 
 My motivation in running is to bring more perspective from a smaller
 project to the deliberations of the TC, which I think already has a
 tonne of large-project and cross-project perspective to draw on.
 Balance is a good and healthy thing :)
 
 As a community we have a big challenge ahead of us to figure out how
 we respond to the growing pains that been felt in our governance
 structure and cross-project resources. This has crystallized around
 the recent layering and big tent discussions. My own feeling has
 always been in favor of a big welcoming tent, but I'm less convinced
 that a small blessed core is necessarily a corollary of such
 inclusiveness. Before we radically alter the release cycle model
 that's served us relatively well thus far, I think a critical eye
 should be brought to the proposals; in particular we really need to
 clearly identify the core problems that these proposed changes are
 intended to solve.
 
 And so, onwards to the stock questions ...
 
 Topic: OpenStack Mission
 
 
 How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 In all honesty, I would give us an A+ for effort, but more like a B-
 for execution. In our excitement and enthusiasm to add shiny new
 features, we sometimes take our eye off the ball in terms of what's
 needed to make the lives of our users easier. I'm as guilty of this as
 anyone else, perhaps even more so. But I think at this stage, it would
 be of much benefit to our user community if we swung the pendulum
 somewhat in the other direction, and shifted some focus onto easing
 the practical challenges of operating our stuff at scale.
 
 Topic: Technical Committee Mission
 ==
 
 How do you feel the technical committee is doing in meeting the
 technical committee mission?
 
 Well, to be honest, if I thought this couldn't be improved, I wouldn't
 be running for election.
 
 On the one hand, I felt the gap analysis for already-integrated
 projects was a good and healthy thing, and certainly assisted in
 focusing resources over Juno on the areas where the TC saw
 deficiencies.
 
 On the other hand, I was quite disheartened by how some of the TC
 discussions around project status played out. IMO there was a failure
 of due diligence and mentoring. If we continue to have the TC making
 important determinations about the future of projects (whether it be
 their integrated status or their production readiness), then I think
 we need to ensure that the TC keeps itself fully appraised from an
 earlier stage about the direction that the project is taking, and
 gives fair warning when it feels that a project needs a
 course-correction.
 
 Topic: Contributor Motivation
 =
 
 How would you characterize the various facets of contributor
 motivation?
 
 Most of my prior opensource experience was on various Apache projects
 and in contrast it's striking that the OpenStack contributor community
 is on the whole more skewed away from pure volunteerism, and towards
 corporate contributors. By that, I mean contributors who are employed
 by major operators and distributors of OpenStack, where their day-job
 is to go forth and make it better. On balance, this is actually a
 strength in our community. It certainly aids in the continuity and
 sustainability of effort. It also helps ensure that less glamorous,
 but ultra-important, efforts such as stable-maint and vulnerability
 management get the attention they deserve.
 
 However, despite this skew, I'm well aware that we're building a
 broad church here. I think we all benefit from active efforts to
 build diversity in our contributor community and harness the energy of
 contributors with all kinds of motivations. Not just because it's the
 right-on thing to do, but because it's the *smart* thing to do
 ... ensuring that we get access to all of the talents, especially from
 previously under-represented groups. Towards this end, I continue to
 support the efforts of programs such as the GNOME OPW and their recent
 moves towards extending their reach to a wider 

Re: [openstack-dev] TC candidacy

2014-10-08 Thread Tristan Cacqueray
confirmed

On 07/10/14 10:06 PM, Adam Lawson wrote:
 Hello everyone!
 
 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step on a limb here
 and enter the circle.
 
 My involvement has been primarily focused on large designs and deployments
 of custom automated Openstack clouds. And while I am more than proficient
 in Python and numerous other languages including .NET/J2EE and others, my
 greatest pleasure has been architecting solutions that are powered by
 Openstack. Focusing on that has really given me a unique perspective. Not
 just on individual components and how they interact with each other, but
 also how they collectively perform within the context of a heterogenous
 hybrid cloud solution while adhering to industry best practices. This
 perspective is one that I hope to bring to the technical committee if the
 Openstack community is so inclined. Not only to shepherd how Openstack is
 put together but to help enable an easier and more seamless adoption cycle
 within the enterprise.
 
 Lastly in the spirit of full disclosure, I am the principal architect for
 an Openstack consulting company I founded which strives for an accelerated
 enterprise adoption of the open cloud through, in part, the successes of
 Openstack. So one could say I am vested in Openstack in a pretty unique way
 compared to most others. So where technical direction is concerned, I
 believe I have a deep well of experience from which to draw via designing
 and developing production Openstack clouds in the real world - day in and
 day out - which I believe would be of immense value to the TC and the
 community supporting the project itself.
 
 I know there are some really smart people who want to also serve on the TC
 with focuses on various areas of Openstack and thankfully the committee was
 designed to accommodate multiple unique perspectives for that very reason.
 My hope is that the community chooses to include my program-agnostic
 architectural influence to the TC while maintaining the same work ethic and
 unyielding commitment to efforts that will deliver excellence to and within
 the Openstack platform.
 
 So without any further adieu, below are my thoughts re the requested
 questions and thanks for your consideration!
 
 *My name is Adam Lawson, running for election to the Openstack Technical
 Committee, and I approve this message.* ; )
 
 *Topic: OpenStack Mission*
 *How do you feel the technical community is doing in meeting the OpenStack
 Mission?*
 
 *“To produce the ubiquitous Open Source Cloud Computing platform that will
 meet the needs of public and private clouds regardless of size, by being
 simple to implement and massively scalable.”*
 
 The whole point of mission statements is merely to identify what we are
 striving to achieve or accomplish within the organization. With that said,
 I feel that technical leadership is the first step to accomplishing a
 technical goal. So to that end, the existence of the TC is a positive first
 step. But it's just one step or many more to come.
  Within this particular TC cycle, I'd like to see the TC demonstrate
 leadership to drive a reduction of lingering technical debt and address API
 and module standardization. Openstack in its current form has a number of
 challenges that are affecting our ability to scale and while some of this
 can be solved organizationally, technical debt and standardization are
 challenges that will not be easy to resolve and might not even be 100
 percent solvable within a single release cycle. But I look forward to how
 the TC *will* shepherd improvements to both process and the product and
 help drive the mission.
  On a side note, easy to implement is still just a goal and the
 engineering requirement to deploy and manage Openstack is still a
 prohibitive hurdle for many organizations. But we have more than one tool
 in front of us that will help us to help others who want to use Openstack
 but .. can't. That's something I'd really like to see change soon.
 
 *Topic: Contributor Motivation*
 *How would you characterize the various facets of contributor motivation?*
  I like what I read earlier today: People want to do work that matters and
 enjoy doing it. This sums up Openstack contributors very well but it sums
 up 

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Vitaly Kramskikh
So they should be implemented like Murano or Sahara and provide a checkbox
in Additional Services section of the settings tab and the wizard

2014-10-08 19:57 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

 Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
 they should do is  installing a package and modify a couple of config files
 (run a shell command).
 These ones have nothing to do with UI or any checkboxes, aren't they?
 08 Окт 2014 г. 12:49 пользователь Vitaly Kramskikh 
 vkramsk...@mirantis.com написал:

 Nikolay,

 Currently every thing that can be turned into a plugin (Ceph, vCenter,
 Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
 controls) for the settings tab. Why change this approach for plugins? The
 settings tab (cluster attributes) currently is a SSOT
 http://en.wikipedia.org/wiki/Single_Source_of_Truth, and you want to
 ruin it for no reason.

 Of course it makes no sense to generate anything. Checkboxes on the
 settings tab can be added using simple YAML mixin and if you want to check
 this checkbox to determine whether to perform some action or not and don't
 want to write any python code, try to add to plugin's YAML restrictions
 section which we already have for the settings tab, the wizard and roles.

 2014-10-08 14:50 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

  Right now we already have like 2 types of plugins (extensions),
 classified by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
 or hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano, zabbix)

 That's not quite right. In 6.0 and after that there will be a lot of
 small plugins which only modify some config and/or install some
 package. There is nothing to configure here, and I as a plugin
 developer don't even want to know anything about checkboxes on UI. I
 just want two things: role to execute my command on and command
 itself. That's one small YAML.

 And autogenerating checkboxes for such plugins on UI is bad, because
 explicit is better than implicit (and all our settings are explicitly
 defined in openstack.yaml).

 On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak dshul...@mirantis.com
 wrote:
  If there is no checkboxes (read configuration) and plugin is installed
 - all
  deployment tasks will be applied
  to every environment, but why do you think that there will be no
 checkboxes
  in most cases?
 
  Right now we already have like 2 types of plugins (extensions),
 classified
  by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
  hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano,
  zabbix)
 
  In 1st case you need to provide shared configuration storage (like
 cluster
  attributes right now), in order for plugin
  to be able to exclude part of core workflow from running (not
 installing
  swift for example).
  In case if the plugin is self-contained entity, like Sahara, Murano
 right
  now - checkboxes would be simply required.
  It works this way right now, and it doesnot look like huge overhead.
 
  So what do you think, will it work or no?
 
  On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov nmar...@mirantis.com
 wrote:
 
  Hi,
 
  Frankly speaking, I'm not sure on how 1st approach will even work.
  What if plugin doesn't provide any checkboxes (and in most cases it
  won't)? How should we determine in serializer, which plugins should be
  applied while generating astute.yaml and tasks.yaml? Should we
  autogenerate some stuff for plugins which are not even enabled and do
  needless work?
 
  This looks too complicated for me from the backend side, and option
  with enabling/disabling plugins in wizard for specific environment (we
  can invent mechanism to disable them on env which is not deployed yet,
  besides, for API it's just one PUT) is MUCH simpler and much more
  obvious, as I see.
 
 
 
  On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
   Hi,
  
   I would go with the 1st approach. The thing I don't like in the 2nd
   approach
   is that we have to make the user enable plugin twice. For example,
 we
   have
   to enable Ceph as a plugin and then add Ceph role to nodes and
 choose
   what
   we want to store in Ceph (images, objects). Why we would need to
   explicitly
   enable Ceph plugin? Let's always show plugin options in wizard and
   settings
   tab, and if the user just doesn't want to enable Ceph, he would just
   leave
   all the checkboxes unchecked. The 2nd approach would also lead to
 some
   kind
   of inconsistency in case the user enabled Ceph plugin but left all
 the
   Ceph-related checkboxes unchecked and didn't add Ceph nodes.
  
   2014-10-07 21:17 GMT+07:00 Evgeniy L e...@mirantis.com:
  
   Hi,
  
   We had a meeting today about plugins on UI, as result of the
 meeting
   we have two approaches and 

[openstack-dev] [Elections] posted TC candidacy eligibility requirements mistake mea culpa

2014-10-08 Thread Anita Kuno
So I have made an error, which hit my radar the other day and has
demonstrated itself to be true this morning (Eastern Daylight Time).

I have been operating with the understanding that a TC candidate needed
to have a commit to one of the OpenStack projects in order to run. (In
other words, they had to come from the electorate.) This is in error. A
fact that I smelled a whiff of in response to a question from Jay Pipes
in irc when I linked to the TC charter, particularly the line: Any
Foundation individual member can propose their candidacy for an
available, directly-elected TC seat.
http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n150
and then was front and centre of my attention this morning when working
with Tristan as new candidates are confirmed.

The information about TC candidacy eligiblity requirements on the TC
elections wikipage currently is wrong and I will change it as soon as I
finish falling on my sword.

I conferred with Thierry this morning and he has been operating under
the same assumption as well. We fixed the broken link to the foundation
by-laws on the governance wikipage and read them again.
http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/ as
well as
http://www.openstack.org/legal/technical-committee-member-policy/ There
is information about the definition of ATC but none about the
requirements of TC candidates. So the governing document in this case is
the TC charter, which states that foundation membership is the sole
requirement for a candidate to be eligible to run.

I apologize for the confusion. In addition to this email and editing the
wikipage, if anyone feels I need to do anything more to address this
please contact me so that I may endeavour to do my best.

Thank you,
Anita.

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


Re: [openstack-dev] Info on XenAPI data format for 'host_data' call

2014-10-08 Thread Bob Ball
Hi Daniel,

The following is an example return value from one of my hosts

{host_name-description: Default install of XenServer, host_hostname: 
ciceronicus, host_memory: {total: 17169604608, overhead: 266592256, 
free: 16132087808, free-computed: 16111337472}, enabled: true, 
host_capabilities: [xen-3.0-x86_64, xen-3.0-x86_32p, hvm-3.0-x86_32, 
hvm-3.0-x86_32p, hvm-3.0-x86_64], host_other-config: {agent_start_time: 
1412774967., iscsi_iqn: iqn.2014-10.com.xensource.hq.eng:587b598c, 
boot_time: 1412774885.}, host_ip_address: 10.219.10.24, 
host_cpu_info: {physical_features: 0098e3fd-bfebfbff-0001-28100800, 
modelname: Intel(R) Xeon(R) CPU   X3430  @ 2.40GHz, vendor: 
GenuineIntel, features: 0098e3fd-bfebfbff-0001-28100800, family: 6, 
maskable: full, cpu_count: 4, socket_count: 1, flags: fpu de tsc 
msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht 
nx constant_tsc nonstop_tsc aperfmperf pni vmx est ssse3 sse4_1 sse4_2 popcnt 
hypervisor ida
  tpr_shadow vnmi flexpriority ept vpid, stepping: 5, model: 30, 
features_after_reboot: 0098e3fd-bfebfbff-0001-28100800, speed: 
2394.086}, host_uuid: ec54eebe-b14b-4b0a-aa89-d2c468771cd3, 
host_name-label: ciceronicus}

Is that enough for what you're looking at?  If there is anything I can help 
with let me know on IRC.

Thanks,

Bob

From: Daniel P. Berrange [berra...@redhat.com]
Sent: 08 October 2014 16:19
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Info on XenAPI data format for 'host_data'  call

I'm doing some work on the get_available_resource method and need
to understand what data format XenAPI returns for the following
RPC call:

   data = call_xenhost(self._session, host_data, {})

I don't have any suitable XenServer hosts to test on myself, so if
anyone can provide a raw/json dump of the complete dataset returned
for this call on a real XenServer host, that would be very helpful


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

___
OpenStack-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] Cinder/Neutron plugins on UI

2014-10-08 Thread Vitaly Kramskikh
Hi, responses inline.

2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com:

 Hi,

 Vitaly, I understand your concerns about UX.
 But there are technical problems and statements which affect
 plugin developer and makes his live more complicated.

 My opinion is we definitely should know, if plugin is disabled
 or if it's enabled for specific environment.

 1. plugin developer defines tasks, like I want the script to be
 executed on nodes with controller role and I don't think that
 he expects this task to be run on all of the nodes, also
 I don't think that we want ask plugin developer to parse
 yaml with bash in order to understand if his plugin is enabled,
 it's a bad design

Bash script shouldn't be even run if the conditions to run it are not met.
I described above how it could be done.

 2. there will be no way to uninstall the plugin, because all of the
 plugins are enabled on the environments, even if user doesn't
 use them

Well, this is the only issue that I see with the first approach and I still
don't know how to solve it.

 Also I don't think that it's a good interface, to ask plugin developr
 to include checkbox in each plugin.

 It should be included only in plugins which affect the installation. For
example, if OSTF was a plugin it wouldn't need such a checkbox. We can also
make kind of plugin bootstrap or a sample plugin whcih will include a
single control.

 The second solution is discussed because it's the most explicit
 way to solve described problem.

 Let's try to figure out the solution which will work well for user
 and for plugin developer.

 For example, for each plugin generate section on UI with checkbox
 Like:

Well, first Nikolay disliked need for a checkbox for any plugin and now you
want to autogenerate a section. Why woudn't we give plugin writers ability
to describe the controls themselves? For example, LBaaS would require a
single checkbox in Additional Services section.


 GlusterFS [ ] - disable all of the fields for the section
 Here is some description of the section, which we can take from
 description field.

 IP address [127.0.0.1] - this field provides plugin developer

 If plugin is set, we add env - plugin relation, if it's unset, we
 delete it.
 Also when user checks the checkbox, UI will be able to retrieve
 attributes which plugin provides. But it's not so easy todo, I'm not
 sure if we can do it with hooks, but it's possible with some separate
 model and handlers.

 Thanks,

 On Wed, Oct 8, 2014 at 12:48 PM, Vitaly Kramskikh vkramsk...@mirantis.com
  wrote:

 Nikolay,

 Currently every thing that can be turned into a plugin (Ceph, vCenter,
 Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
 controls) for the settings tab. Why change this approach for plugins? The
 settings tab (cluster attributes) currently is a SSOT
 http://en.wikipedia.org/wiki/Single_Source_of_Truth, and you want to
 ruin it for no reason.

 Of course it makes no sense to generate anything. Checkboxes on the
 settings tab can be added using simple YAML mixin and if you want to check
 this checkbox to determine whether to perform some action or not and don't
 want to write any python code, try to add to plugin's YAML restrictions
 section which we already have for the settings tab, the wizard and roles.

 2014-10-08 14:50 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

  Right now we already have like 2 types of plugins (extensions),
 classified by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
 or hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano, zabbix)

 That's not quite right. In 6.0 and after that there will be a lot of
 small plugins which only modify some config and/or install some
 package. There is nothing to configure here, and I as a plugin
 developer don't even want to know anything about checkboxes on UI. I
 just want two things: role to execute my command on and command
 itself. That's one small YAML.

 And autogenerating checkboxes for such plugins on UI is bad, because
 explicit is better than implicit (and all our settings are explicitly
 defined in openstack.yaml).

 On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak dshul...@mirantis.com
 wrote:
  If there is no checkboxes (read configuration) and plugin is installed
 - all
  deployment tasks will be applied
  to every environment, but why do you think that there will be no
 checkboxes
  in most cases?
 
  Right now we already have like 2 types of plugins (extensions),
 classified
  by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
  hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano,
  zabbix)
 
  In 1st case you need to provide shared configuration storage (like
 cluster
  attributes right now), in order for plugin
  to be able to exclude part of core workflow from 

Re: [openstack-dev] Info on XenAPI data format for 'host_data' call

2014-10-08 Thread Daniel P. Berrange
On Wed, Oct 08, 2014 at 03:53:25PM +, Bob Ball wrote:
 Hi Daniel,
 
 The following is an example return value from one of my hosts
 
 {host_name-description: Default install of XenServer, host_hostname: 
 ciceronicus, host_memory: {total: 17169604608, overhead: 266592256, 
 free: 16132087808, free-computed: 16111337472}, enabled: true, 
 host_capabilities: [xen-3.0-x86_64, xen-3.0-x86_32p, hvm-3.0-x86_32, 
 hvm-3.0-x86_32p, hvm-3.0-x86_64], host_other-config: 
 {agent_start_time: 1412774967., iscsi_iqn: 
 iqn.2014-10.com.xensource.hq.eng:587b598c, boot_time: 1412774885.}, 
 host_ip_address: 10.219.10.24, host_cpu_info: {physical_features: 
 0098e3fd-bfebfbff-0001-28100800, modelname: Intel(R) Xeon(R) CPU 
   X3430  @ 2.40GHz, vendor: GenuineIntel, features: 
 0098e3fd-bfebfbff-0001-28100800, family: 6, maskable: full, 
 cpu_count: 4, socket_count: 1, flags: fpu de tsc msr pae mce cx8 
 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht nx 
 constant_tsc nonstop_tsc aperfmperf pni vmx est ssse3 sse4_1 sse4_2 popcnt 
 hypervisor i
 da tpr_shadow vnmi flexpriority ept vpid, stepping: 5, model: 30, 
features_after_reboot: 0098e3fd-bfebfbff-0001-28100800, speed: 
2394.086}, host_uuid: ec54eebe-b14b-4b0a-aa89-d2c468771cd3, 
host_name-label: ciceronicus}
 
 Is that enough for what you're looking at?  If there is anything
 I can help with let me know on IRC.

Yes, that is perfect, thank you.

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

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


[openstack-dev] [Fuel] [heads-up] Icehouse has been replaced by Juno in Fuel default mirrors

2014-10-08 Thread Aleksandra Fedorova
Please be aware that Juno has been pushed to Fuel mirrors [1] today.

This means that by running 'make iso' with default settings you get iso
image with Juno OpenStack packages.

To build Fuel iso on top of Icehouse OpenStack release, explicitly set
mirror via MIRROR_BASE parameter:

$ export MIRROR_BASE=http://mirror.fuel-infra.org/fwm/6.0-icehouse
$ make iso


[1]  http://osci-mirror-srt.srt.mirantis.net/fwm/6.0

-- 
Aleksandra Fedorova
bookwar at IRC
Fuel DevOps Engineer
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Nikolay Markov
Vitaly,

Once again, as a plugin developer I don't care about how Sahara or Murano
is implemented. I don't care about checkboxes, either. I just want one
simple command to run on target nodes and I should be provided with the
simplest possible interface to:
1) Write this command in some YAML and don't care about anything else
2) Enable my plugin for particular environment and see if it's really
enabled both on UI and CLI (and through pure API by simple field checking)

If it provides some separate service - this doesn't change anything, I just
need it to be listed somewhere in plugins inside cluster data to know
that it'll be executed.

How will it work with your approach?
08 Окт 2014 г. 20:00 пользователь Vitaly Kramskikh 
vkramsk...@mirantis.com написал:

 Hi, responses inline.

 2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com:

 Hi,

 Vitaly, I understand your concerns about UX.
 But there are technical problems and statements which affect
 plugin developer and makes his live more complicated.

 My opinion is we definitely should know, if plugin is disabled
 or if it's enabled for specific environment.

 1. plugin developer defines tasks, like I want the script to be
 executed on nodes with controller role and I don't think that
 he expects this task to be run on all of the nodes, also
 I don't think that we want ask plugin developer to parse
 yaml with bash in order to understand if his plugin is enabled,
 it's a bad design

 Bash script shouldn't be even run if the conditions to run it are not met.
 I described above how it could be done.

 2. there will be no way to uninstall the plugin, because all of the
 plugins are enabled on the environments, even if user doesn't
 use them

 Well, this is the only issue that I see with the first approach and I
 still don't know how to solve it.

 Also I don't think that it's a good interface, to ask plugin developr
 to include checkbox in each plugin.

 It should be included only in plugins which affect the installation. For
 example, if OSTF was a plugin it wouldn't need such a checkbox. We can also
 make kind of plugin bootstrap or a sample plugin whcih will include a
 single control.

 The second solution is discussed because it's the most explicit
 way to solve described problem.

 Let's try to figure out the solution which will work well for user
 and for plugin developer.

 For example, for each plugin generate section on UI with checkbox
 Like:

 Well, first Nikolay disliked need for a checkbox for any plugin and now
 you want to autogenerate a section. Why woudn't we give plugin writers
 ability to describe the controls themselves? For example, LBaaS would
 require a single checkbox in Additional Services section.


 GlusterFS [ ] - disable all of the fields for the section
 Here is some description of the section, which we can take from
 description field.

 IP address [127.0.0.1] - this field provides plugin developer

 If plugin is set, we add env - plugin relation, if it's unset, we
 delete it.
 Also when user checks the checkbox, UI will be able to retrieve
 attributes which plugin provides. But it's not so easy todo, I'm not
 sure if we can do it with hooks, but it's possible with some separate
 model and handlers.

 Thanks,

 On Wed, Oct 8, 2014 at 12:48 PM, Vitaly Kramskikh 
 vkramsk...@mirantis.com wrote:

 Nikolay,

 Currently every thing that can be turned into a plugin (Ceph, vCenter,
 Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
 controls) for the settings tab. Why change this approach for plugins? The
 settings tab (cluster attributes) currently is a SSOT
 http://en.wikipedia.org/wiki/Single_Source_of_Truth, and you want to
 ruin it for no reason.

 Of course it makes no sense to generate anything. Checkboxes on the
 settings tab can be added using simple YAML mixin and if you want to check
 this checkbox to determine whether to perform some action or not and don't
 want to write any python code, try to add to plugin's YAML restrictions
 section which we already have for the settings tab, the wizard and roles.

 2014-10-08 14:50 GMT+07:00 Nikolay Markov nmar...@mirantis.com:

  Right now we already have like 2 types of plugins (extensions),
 classified by usage of settings tab:
  1. Some kind of backend for service (swift/ceph, lvm/ceph,
 ovs/nsx), or hypervisor (lvm/qemu/vmware)
  2. Self-contained service that just needs to be installed (sahara,
 murano, zabbix)

 That's not quite right. In 6.0 and after that there will be a lot of
 small plugins which only modify some config and/or install some
 package. There is nothing to configure here, and I as a plugin
 developer don't even want to know anything about checkboxes on UI. I
 just want two things: role to execute my command on and command
 itself. That's one small YAML.

 And autogenerating checkboxes for such plugins on UI is bad, because
 explicit is better than implicit (and all our settings are explicitly
 defined in 

[openstack-dev] [Octavia] Octavia Weekly Standup Reminder

2014-10-08 Thread Trevor Vardeman
Hey all!

Friendly reminder to throw a little info in the Standup for this week
before the meeting this afternoon.

-Trevor

PS.  Just tryin to help out Balukoff :P


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


Re: [openstack-dev] [All] [I18N] compiling translation message catalogs

2014-10-08 Thread Akihiro Motoki
Thanks James and Dirk,

First of all, sorry for moving this forward so late in the cycle.
I will remove mo files in Juno when importing the latest translations tomorrow.

On Wed, Oct 8, 2014 at 9:51 PM, James Page james.p...@ubuntu.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 07/10/14 18:00, Julie Pichon wrote:
 I'm adding a couple of people on cc: with an interest in Ubuntu and
 SUSE packaging: the Horizon team would love to have your opinion on
 this (it came up during our weekly meeting).

 The current consensus is leaning toward removing the mo files for
 Juno RC2 (in a couple of days) rather than wait until Kilo, as this
 has been a pain point for (some/all?) distros for a while.

 I'm in agreement that option a) is the best way to go; on the
 assumption that compiling the message catalogs won't bring in
 requirements for new dependencies, we can deal with that for rc2 in
 Ubuntu for Juno.

I believe it does not bring any new dependency requirements.

There are several ways to compile message catalogs:
the way Tom suggested below in the launchpad bug [1] is the simplest.
we need to add python-django to Build-Depends in Ubuntu debian/control.

  cd horizon  django-admin compilemessages  cd ..
  cd openstack_dashboard  django-admin compilemessages  cd ..
  # remove unnecessary .po files
  find . -name django*.po -exec rm -f '{}' \;

Horizon run_tests.sh script also provides more convenient way to
compile message catalogs.
It prepares virtualenv named .venv and compiles message catalogs
using the virtualenv.
The virtualenv is automatically created inside the script, so we don't
need to care Build-Depends,
but run_tests.sh script prompts before creating the virtualenv :-(

  ./run_tests.sh --compilemessages

[1] https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1377923

Thanks,
Akihiro



 Thank you,

 Julie

 On 01/10/14 17:04, Akihiro Motoki wrote:
 Hi,

 To display localized strings, we need to compile translated
 message catalogs (PO files) into compiled one (MO files). I would
 like to discuss and get a consensus who and when generate
 compiled message catalogs. Inputs from packagers are really
 appreciated.

 [The current status] * Horizon contains compile message catalogs
 in the git repo. (It is just a history and there seems no strong
 reason to have compiled one in the repo. There is a bug report on
 it.) * Other all projects do not contain compiled message
 catalogs and have only PO files.

 [Possible choices] I think there are several options. (there may
 be other options) (a) OpenStack does not distribute compiled
 message catalogs, and only provides a command (setup.py
 integration) to compile message catalogs. Deployers or
 distributors need to compile message catalogs. (b) Similar to
 (a), but compile message catalogs as a part of pip install. (c)
 OpenStack distributes compiled message catalogs as a part of the
 release. (c1) the git repo maintains compiled message catalogs.
 (c2) only tarball contains compiled message catalogs

 Note that the current Horizon is (c1) and others are (a).

 [Pros/Cons] (a) It is a simplest way as OpenStack upstream.
 Packagers need to compile message catalogs and customize there
 scripts. Deployers who install openstack from the source need to
 compile them too. (b) It might be a simple approach from users
 perspective. However to compile message catalogs during
 installation, we need to install required modules (like babel or
 django) before running installation (or require them as the
 first citizen in setup.py require). I don't think it is much
 simpler compared to option (a). (c1) Compiled message catalogs
 are a kind of binary files and they can be generated from PO
 files. There is no need to manage two same data. (c2) OpenStack
 is downloaded in several ways (release tarballs is not the only
 option), so I don't see much merits that the only tarball
 contains compiled message catalogs. A merit is that compiled
 message catalogs are available and there is no additional step
 users need to do.

 My preference is (a), but would like to know broader opinions
 especially from packagers.

 Thanks, Akihiro

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



 - --
 James Page
 Ubuntu and Debian Developer
 james.p...@ubuntu.com
 jamesp...@debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJUNTNeAAoJEL/srsug59jD2aoQAKAwvKgL0WLn8ZDqX5KGfX2R
 OrTaNcozlNk2OXHgt2nDxOce6yQTbhh4yMJHsymOvgKj4+yOz5L78k9wkRgDmvqX
 b6oiUIGjnQTiVQylT9FRuXicb/I5aoHOr2ki7LCHZ0QuABFCSC7noE/e4KnX2a0g
 baaEC57UZa3aKepQ0PVQP50F5zGF5ux5jlP3oXtKtNjUL9l5bnTmwVgF8ymOYCZd
 Q2fNU3CGUGG9LWwH6WmNJSKEkqGEP8+W7QEcXxT3/JhnVtYIJY/LehfLI8mUGu6o
 geFfZqTYM5qOUrdCjFLJE8ayTE0jtM4VIUAX6xxkZNM4sdXdbH15N5UPqUFBRGsj
 h/P/L/79qSMCt21eQBeaSDEKUvO6egG31tVpk7xTr6PIwRH8t5R+vXjPGjGqc78m
 

[openstack-dev] [Fuel] Let's remove fuelweb from repo paths

2014-10-08 Thread Igor Kalnitsky
Hi fuelers,

I'm going to propose you remove fuelweb word from repos' paths. What
am I talking about? Let me show you.

Currently we have the following paths to repos:

/var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/
/var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/

Obviously, the word fuelweb is redundant here and doesn't reflect
reality, because our repos contain not only fuel packages, but
openstack.

Moreover, fuel-upgrade script installs repos without that word
(fuelweb, I mean) so we have inconsistent file structure for repos,
which may lead to problems in future.

So I propose to do it now, while we can do it without risks and
safety. I prepared a set of patches

https://review.openstack.org/#/c/126885/
https://review.openstack.org/#/c/126886/
https://review.openstack.org/#/c/126887/

and built an ISO #508 [1] - both master node and centos cluster was
deployed successfully.

Folks, please, take a look over patches above and let's merge it.

Thanks,
Igor


[1]: 
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/

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


Re: [openstack-dev] Usage of @author tags in the header of Python files

2014-10-08 Thread David Lyle
I don't see any need nor benefit from the tags. We should remove them if
convenient.

David
On Oct 8, 2014 3:02 AM, Duncan Thomas duncan.tho...@gmail.com wrote:

 On 8 October 2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:
  On 08/10/14 09:30, Christian Berendt wrote:
  After proposing a change to Horizon to remove the @author tags from
  the header of Python files
  (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
  to discuss this first on the mailing list.
 
  Is it necessary to track the authorship of a file inside the file
  using @author tags?
 
  Git is a lot better in attributing authorship, so for me, @author tags
  are just a waste of precious disk bytes and cpu cycles.

 The tags also make people worried about changing 'somebody else's
 thing', are difficult to make meaningful over time (how much of a
 function do you need to change to claim authorship of it) and
 generally give no significant benefit. While I don't currently work on
 Horizon, I vote for scrapping them and putting a hacking check in to
 keep them out.

 ___
 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] [TripleO] QuintupleO Update

2014-10-08 Thread Ben Nemec
So things have been pretty quiet on the QuintupleO front since the
mid-cycle, but I have finally had a chance to set up an environment to
do some experimentation with it.  I don't have anything ready for
primetime, but I was able to do an Ironic deploy of the undercloud image
from a devtest-built seed image, all in a modified Devstack install.
I've written up the details in a blog post:

http://blog.nemebean.com/content/quintupleo-status-update

It's a bit long, so as a tldr here's the summary of the status from the
end of the post:

With these changes it would theoretically be possible to use QuintupleO
for the TripleO CI environment. The biggest issue I'm aware of would be
the fact that the Ironic code in the images would not be
OpenStack-aware, so we would need to cherry-pick my changes in every
image build. That's something we typically prefer to avoid, so I think a
final version of the Ironic OpenStack driver should be the top priority
right now. The other changes could be applied to a CI OpenStack
installation and largely left alone without affecting any of our
testing. Long-term, of course, we want to get all of this functionality
enabled in the respective projects by default. That will need to happen
before TripleO development in a public OpenStack cloud can happen.

And that's pretty much the state of QuintupleO from my perspective. I
would love to have some more discussions about short and long-term plans
for this either in Paris or before, if possible.

Any comments or questions, you know where I idle in IRC. :-)

-Ben

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


Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

2014-10-08 Thread Pavlo Shchelokovskyy
Hi fellow Heat Cores,

thank you for your support. I am very proud to become part of this
team, and I will do my best to use my new superpowers wisely and
responsibly.

Best regards,
Pavlo.

On Wed, Oct 8, 2014 at 1:22 AM, Angus Salkeld asalk...@mirantis.com wrote:
 Congrats Pavlo, I have added you to core.

 -Angus

 On Wed, Oct 8, 2014 at 1:18 AM, Jeff Peeler jpee...@redhat.com wrote:

 +1

 On 10/06/2014 04:41 PM, Zane Bitter wrote:

 I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core
 team.

 Pavlo has been a consistently active member of the Heat community - he's
 a regular participant in IRC and at meetings, has been making plenty of
 good commits[1] and maintains a very respectable review rate[2] with
 helpful comments. I think he's built up enough experience with the code
 base to be ready for core.

 Heat-cores, please vote by replying to this thread. As a reminder of
 your options[3], +1 votes from 5 cores is sufficient; a -1 is treated as
 a veto.


 Obviously past 5 +1 votes here, but showing full support doesn't hurt.



 cheers,
 Zane.

 [1]

 https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z

 [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
 [3]
 https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members



 ___
 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] [Octavia] Octavia Weekly Standup Reminder

2014-10-08 Thread Stephen Balukoff
Thanks Trevor!

The URL for that is here:
https://etherpad.openstack.org/p/octavia-weekly-standup

Also, the agenda for today's Octavia meeting is here (feel free to add
pertinent topics):
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda

Stephen

On Wed, Oct 8, 2014 at 9:18 AM, Trevor Vardeman 
trevor.varde...@rackspace.com wrote:

 Hey all!

 Friendly reminder to throw a little info in the Standup for this week
 before the meeting this afternoon.

 -Trevor

 PS.  Just tryin to help out Balukoff :P


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




-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of @author tags in the header of Python files

2014-10-08 Thread John Griffith
On Wed, Oct 8, 2014 at 11:15 AM, David Lyle dkly...@gmail.com wrote:

 I don't see any need nor benefit from the tags. We should remove them if
 convenient.

 David
 On Oct 8, 2014 3:02 AM, Duncan Thomas duncan.tho...@gmail.com wrote:

 On 8 October 2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:
  On 08/10/14 09:30, Christian Berendt wrote:
  After proposing a change to Horizon to remove the @author tags from
  the header of Python files
  (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
  to discuss this first on the mailing list.
 
  Is it necessary to track the authorship of a file inside the file
  using @author tags?
 
  Git is a lot better in attributing authorship, so for me, @author tags
  are just a waste of precious disk bytes and cpu cycles.

 The tags also make people worried about changing 'somebody else's
 thing', are difficult to make meaningful over time (how much of a
 function do you need to change to claim authorship of it) and
 generally give no significant benefit. While I don't currently work on
 Horizon, I vote for scrapping them and putting a hacking check in to
 keep them out.

 ___
 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

 I have to echo what others are saying, IMO the @author tags are pretty
meaningless and worse misleading.  I don't have an opinion on removing them
but I certainly think it's ridiculous for people to add them going
forward.  Certainly wouldn't object to them being removed as new
contributors add/amend the files that have them.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] QuintupleO Update

2014-10-08 Thread Robert Collins
On 9 October 2014 06:26, Ben Nemec openst...@nemebean.com wrote:
 So things have been pretty quiet on the QuintupleO front since the
 mid-cycle, but I have finally had a chance to set up an environment to
 do some experimentation with it.  I don't have anything ready for
 primetime, but I was able to do an Ironic deploy of the undercloud image
 from a devtest-built seed image, all in a modified Devstack install.
 I've written up the details in a blog post:

 http://blog.nemebean.com/content/quintupleo-status-update

Cool.

+if ((CONF.libvirt.virt_type == qemu or
+ CONF.libvirt.virt_type == kvm) and
+ flavor.extra_specs.get('libvirt:pxe-first')):
+guest.os_boot_dev = ['network'] + guest.os_boot_dev

Might be better as:
...CONF.libvirt.virt_type in ('qemu', 'kvm') ...
in the short term. Medium term I think we want to be able to control
that on a per instance basis.

Ironic actually polls things till they worked, at least in the IPMI
codepaths, so we should be able to do something there. However,
Devananda was very concerned about having an openstack driver, but was
ok with an IPMI-openstack proxy, which jang volunteered to write.

The neutron one we need to be able to do on a per-port basis. I think
its definitely one of the changes that needs Neutron design input -
e.g. a spec there. Off the top of my head the acl logic will need to
be something like (for dhcp answering)
 - does the network permit tenant nodes to be dhcp servers
 - if yes and this user owns the network permit them to control this setting

For spoofing something similar:
 - does the network permit ports to be enabled for spoofing
 - if yes and this user owns the network permit them to control this setting

Then we'll want to tunnel that setting via either heat (and specific
port requests in the templates) or nova (and an attribute on the
server request in heat).

At a minimum, to be able to deploy your patches to the tripleo-ci
clouds, I think we'll need the attribute on the network object
specifying whether this is permitted or not: we can then create
dedicated networks per test run with that set, so even if v1 of the
patches just turn it on for every port on such a network, we'd be set.

Overall though, its fantatic you have something working. And I for one
welcome OoOoO.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] Usage of @author tags in the header of Python files

2014-10-08 Thread Monty Taylor
On 10/08/2014 10:45 AM, John Griffith wrote:
 On Wed, Oct 8, 2014 at 11:15 AM, David Lyle dkly...@gmail.com wrote:
 
 I don't see any need nor benefit from the tags. We should remove them if
 convenient.

 David
 On Oct 8, 2014 3:02 AM, Duncan Thomas duncan.tho...@gmail.com wrote:

 On 8 October 2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:
 On 08/10/14 09:30, Christian Berendt wrote:
 After proposing a change to Horizon to remove the @author tags from
 the header of Python files
 (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
 to discuss this first on the mailing list.

 Is it necessary to track the authorship of a file inside the file
 using @author tags?

 Git is a lot better in attributing authorship, so for me, @author tags
 are just a waste of precious disk bytes and cpu cycles.

 The tags also make people worried about changing 'somebody else's
 thing', are difficult to make meaningful over time (how much of a
 function do you need to change to claim authorship of it) and
 generally give no significant benefit. While I don't currently work on
 Horizon, I vote for scrapping them and putting a hacking check in to
 keep them out.

 ___
 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

 I have to echo what others are saying, IMO the @author tags are pretty
 meaningless and worse misleading.  I don't have an opinion on removing them
 but I certainly think it's ridiculous for people to add them going
 forward.  Certainly wouldn't object to them being removed as new
 contributors add/amend the files that have them.

I agree with everything that has been said.


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


Re: [openstack-dev] [Neutron] How to write extension

2014-10-08 Thread Sławek Kapłoński
Hello,

Thanks for link to blueprint Mathieu but I'm using now still Havana version of 
openstack.
I need extension which allow me add to private network something like 
external router that ovs agent will know that should make vxlan or gre 
tunnel to that external device. Maybe there is some solution which allow me to 
do something like that? :)
@Damon: I read those articles before You send me it but something is wrong for 
me (or I don't understand it). I'm trying to do almost exactly what was 
described on 
http://control-that-vm.blogspot.com/2014/05/writing-api-extensions-in-neutron.html
 - I made my file with extension in 
neutron/extensions/my_ext.py and I add name of this extension to ml2 
supported_extension_aliases. When I now do neutron ext-list then I see my 
extension on list but when I send request with curl I have 404 error or error 
500 and in neutron-server logs there is info that ML2 plugin has no method 
xxx. 
So I don't know, should I add methods added by my plugin to ML2 plugin? Or 
should I add by plugin class to classes from which ml2 inherits?

---
Best regards
Sławek Kapłoński
sla...@kaplonski.pl

Dnia środa 08 październik 2014 14:14:56 Mathieu Rohon pisze:
 Hi,
 
 please tell us about the extension you want to write, it would really help.
 In ML2, you now have the ability to easily add extensions thanks to this
 work :
 
 https://blueprints.launchpad.net/neutron/+spec/extensions-in-ml2
 
 Mathieu
 
 On Wed, Oct 8, 2014 at 7:52 AM, Damon Wang damon.dev...@gmail.com wrote:
  Hi Kapłoński,
  
  I recommend you to read these materials:
  
  Keynotes:
  https://www.openstack.org/assets/presentation-media/insideneutron2.pdf
  Video:
  https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-v
  ideos/presentation/deep-dive-into-neutron Post:
  http://control-that-vm.blogspot.com/2014/05/writing-api-extensions-in-neut
  ron.html
  
  Regards,
  Wang Wei
  
  2014-10-08 3:29 GMT+08:00 Sławek Kapłoński sla...@kaplonski.pl:
  Hello,
  
  Can You send me some examples or link to tutorial how to write extension
  to
  neutron. I'm using ML2 plugin in neutron and I want to add some new
  functionality and API methods to this neutron. So imho I should do it via
  extension but how exactly write it that it will work in existing ML2
  plugin?
  
  ---
  Best regards
  Sławek Kapłoński
  sla...@kaplonski.pl
  ___
  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

signature.asc
Description: This is a digitally signed message part.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Documentation Process changed

2014-10-08 Thread Dmitry Borodaenko
At the moment OpenStack infrastructure doesn't allow to customize the
bugs it creates, we should propose a patch at some point to implement
that. When we do, I think we should assign such bugs automatically to
fuel-docs team.

I don't think we should separate user and dev docs bugs, we're working
in the opposite direction towards merging dev docs into fuel-docs:
https://review.openstack.org/124551

Where is your 80% dev vs user docs figure coming from?

I think that whether it's dev or user documentation, a technical
writer should drive the process, collect information from the commit
author, and add it to the right documentation areas. It's commit
author's responsibility to provide an informative commit message in
the first place, to answer technical writer's questions, and to review
docs commits that address the DocImpact bug.

On Oct 8, 2014 10:59 AM, Mike Scherbakov mscherba...@mirantis.com wrote:

 Very good improvement in our documentation process.

 Is there a way to configure it, so bugs would be created with tag docs 
 automatically? It would simplify triaging process I believe.
 From the other hand, as far as I understand, up to 80% of commits with 
 DocImpact will impact development documentation (or it's intended to be 
 affecting only user documentation?). It would be hard for tech writers, who 
 are mostly specialized in Fuel user docs, to work on low-level details of 
 how, let's say, l23network [1] works.
 Do we want to separate docs bugs somehow, user/dev?

 In other words, what would be the flow, who becomes responsible for fixing 
 bugs created automatically by Infra?

 [1] 
 https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network

 On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk sgolovat...@mirantis.com 
 wrote:

 Hi,

 On Fuel Summit '2014 we discussed our Documentation process. According to 
 follow up we aligned it to OpenStack 'DocImpact' process. The new process 
 has been tested on background by me and Bogdan Dobrelya. Today, I have 
 updated Fuel Documentation Process so we are making it official.

 Why?
 Developer perspective:
 It gives more flexibility for the developers to participate in Documentation 
 Process. Every time when the Reviewer sees that patch requires Documentation 
 update, it may ask the Commiter to update 'Commit Message' with DocImpact 
 message. Once patch passes the review Openstack Infra will trigger a new bug 
 in Launchpad that should be assigned to Fuel Documentation team.

 From Fuel Documentation Team perspective:
 When Fuel Documentation Team sees this bug they know who was the commiter 
 and reviewers and whom they should add for documentation review.

 Community:
 Community member may ask the developer to put 'DocImpact' message when it's 
 required.

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


Re: [openstack-dev] [TripleO] QuintupleO Update

2014-10-08 Thread Ben Nemec
On 10/08/2014 12:53 PM, Robert Collins wrote:
 On 9 October 2014 06:26, Ben Nemec openst...@nemebean.com wrote:
 So things have been pretty quiet on the QuintupleO front since the
 mid-cycle, but I have finally had a chance to set up an environment to
 do some experimentation with it.  I don't have anything ready for
 primetime, but I was able to do an Ironic deploy of the undercloud image
 from a devtest-built seed image, all in a modified Devstack install.
 I've written up the details in a blog post:

 http://blog.nemebean.com/content/quintupleo-status-update
 
 Cool.
 
 +if ((CONF.libvirt.virt_type == qemu or
 + CONF.libvirt.virt_type == kvm) and
 + flavor.extra_specs.get('libvirt:pxe-first')):
 +guest.os_boot_dev = ['network'] + guest.os_boot_dev
 
 Might be better as:
 ...CONF.libvirt.virt_type in ('qemu', 'kvm') ...
 in the short term. Medium term I think we want to be able to control
 that on a per instance basis.

Good point.  My excuse is that I copy-pasted that from somewhere else in
the driver. :-)

I'll have to double-check, but I think the general consensus in the Nova
discussions I've seen was that there should be a more generic select
boot device feature added to Nova.  I don't see a spec for it yet
though, so that's something I'll have to follow up on.

 
 Ironic actually polls things till they worked, at least in the IPMI
 codepaths, so we should be able to do something there. However,
 Devananda was very concerned about having an openstack driver, but was
 ok with an IPMI-openstack proxy, which jang volunteered to write.

Yeah, this was just a quick port of my old nova-bm ssh driver to Ironic
so I could prove the concept works.  I included Jan in the To list in
the hopes that he'll chime in on this. :-)

 
 The neutron one we need to be able to do on a per-port basis. I think
 its definitely one of the changes that needs Neutron design input -
 e.g. a spec there. Off the top of my head the acl logic will need to
 be something like (for dhcp answering)
  - does the network permit tenant nodes to be dhcp servers
  - if yes and this user owns the network permit them to control this setting
 
 For spoofing something similar:
  - does the network permit ports to be enabled for spoofing
  - if yes and this user owns the network permit them to control this setting
 
 Then we'll want to tunnel that setting via either heat (and specific
 port requests in the templates) or nova (and an attribute on the
 server request in heat).
 
 At a minimum, to be able to deploy your patches to the tripleo-ci
 clouds, I think we'll need the attribute on the network object
 specifying whether this is permitted or not: we can then create
 dedicated networks per test run with that set, so even if v1 of the
 patches just turn it on for every port on such a network, we'd be set.

Okay, that's good to know.  I haven't looked too closely at what it
would take to make this more granular, but I believe there's similar
(same?) functionality needed for NFV in Neutron so I'm hoping maybe I
can piggy-back on that work.

So yeah, lots of follow-up to do before we can say this is complete, but
I think now I have a much better handle on exactly what we need to
happen to enable this.

 
 Overall though, its fantatic you have something working. And I for one
 welcome OoOoO.
 
 -Rob
 


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


Re: [openstack-dev] [Fuel] Documentation Process changed

2014-10-08 Thread Mike Scherbakov
Thanks Dmitry,
let's try to go this way and correct process if needed when we get first
results.

 Where is your 80% dev vs user docs figure coming from?
it's no more than my guess. We will see real number over time.

On Wed, Oct 8, 2014 at 10:31 PM, Dmitry Borodaenko dborodae...@mirantis.com
 wrote:

 At the moment OpenStack infrastructure doesn't allow to customize the
 bugs it creates, we should propose a patch at some point to implement
 that. When we do, I think we should assign such bugs automatically to
 fuel-docs team.

 I don't think we should separate user and dev docs bugs, we're working
 in the opposite direction towards merging dev docs into fuel-docs:
 https://review.openstack.org/124551

 Where is your 80% dev vs user docs figure coming from?

 I think that whether it's dev or user documentation, a technical
 writer should drive the process, collect information from the commit
 author, and add it to the right documentation areas. It's commit
 author's responsibility to provide an informative commit message in
 the first place, to answer technical writer's questions, and to review
 docs commits that address the DocImpact bug.

 On Oct 8, 2014 10:59 AM, Mike Scherbakov mscherba...@mirantis.com
 wrote:
 
  Very good improvement in our documentation process.
 
  Is there a way to configure it, so bugs would be created with tag docs
 automatically? It would simplify triaging process I believe.
  From the other hand, as far as I understand, up to 80% of commits with
 DocImpact will impact development documentation (or it's intended to be
 affecting only user documentation?). It would be hard for tech writers, who
 are mostly specialized in Fuel user docs, to work on low-level details of
 how, let's say, l23network [1] works.
  Do we want to separate docs bugs somehow, user/dev?
 
  In other words, what would be the flow, who becomes responsible for
 fixing bugs created automatically by Infra?
 
  [1]
 https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network
 
  On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk 
 sgolovat...@mirantis.com wrote:
 
  Hi,
 
  On Fuel Summit '2014 we discussed our Documentation process. According
 to follow up we aligned it to OpenStack 'DocImpact' process. The new
 process has been tested on background by me and Bogdan Dobrelya. Today, I
 have updated Fuel Documentation Process so we are making it official.
 
  Why?
  Developer perspective:
  It gives more flexibility for the developers to participate in
 Documentation Process. Every time when the Reviewer sees that patch
 requires Documentation update, it may ask the Commiter to update 'Commit
 Message' with DocImpact message. Once patch passes the review Openstack
 Infra will trigger a new bug in Launchpad that should be assigned to Fuel
 Documentation team.
 
  From Fuel Documentation Team perspective:
  When Fuel Documentation Team sees this bug they know who was the
 commiter and reviewers and whom they should add for documentation review.
 
  Community:
  Community member may ask the developer to put 'DocImpact' message when
 it's required.

 ___
 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] Usage of @author tags in the header of Python files

2014-10-08 Thread Chris Buccella
Nova has a hacking check for this (N315):
https://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py#n220

Based on the general sentiment around the issue, maybe other projects
should consider enforcing this similarly.


On Wed, Oct 8, 2014 at 1:56 PM, Monty Taylor mord...@inaugust.com wrote:

 On 10/08/2014 10:45 AM, John Griffith wrote:
  On Wed, Oct 8, 2014 at 11:15 AM, David Lyle dkly...@gmail.com wrote:
 
  I don't see any need nor benefit from the tags. We should remove them if
  convenient.
 
  David
  On Oct 8, 2014 3:02 AM, Duncan Thomas duncan.tho...@gmail.com
 wrote:
 
  On 8 October 2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:
  On 08/10/14 09:30, Christian Berendt wrote:
  After proposing a change to Horizon to remove the @author tags from
  the header of Python files
  (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
  to discuss this first on the mailing list.
 
  Is it necessary to track the authorship of a file inside the file
  using @author tags?
 
  Git is a lot better in attributing authorship, so for me, @author tags
  are just a waste of precious disk bytes and cpu cycles.
 
  The tags also make people worried about changing 'somebody else's
  thing', are difficult to make meaningful over time (how much of a
  function do you need to change to claim authorship of it) and
  generally give no significant benefit. While I don't currently work on
  Horizon, I vote for scrapping them and putting a hacking check in to
  keep them out.
 
  ___
  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
 
  I have to echo what others are saying, IMO the @author tags are pretty
  meaningless and worse misleading.  I don't have an opinion on removing
 them
  but I certainly think it's ridiculous for people to add them going
  forward.  Certainly wouldn't object to them being removed as new
  contributors add/amend the files that have them.

 I agree with everything that has been said.


 ___
 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] [TripleO] QuintupleO Update

2014-10-08 Thread Devananda van der Veen
On Wed, Oct 8, 2014 at 12:07 PM, Ben Nemec openst...@nemebean.com wrote:
 On 10/08/2014 12:53 PM, Robert Collins wrote:
 Ironic actually polls things till they worked, at least in the IPMI
 codepaths, so we should be able to do something there. However,
 Devananda was very concerned about having an openstack driver, but was
 ok with an IPMI-openstack proxy, which jang volunteered to write.

 Yeah, this was just a quick port of my old nova-bm ssh driver to Ironic
 so I could prove the concept works.  I included Jan in the To list in
 the hopes that he'll chime in on this. :-)

To recap what Jan and I talked about for a wider audience... An
ipmi-listener that translates to other things (openstack, libvirt, or
what ever) would be very useful for testing the contracts that Ironic
makes with hardware, and also ensuring that our functional tests are
actually testing all of the same code paths we use in production
(which they're not today, because no one should be using the SSH power
driver in production).

Once we have such an ipmi-listener, I think we could (and should)
remove the SSH power driver from Ironic.

-Devananda

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


Re: [openstack-dev] [Fuel] Documentation Process changed

2014-10-08 Thread Sergii Golovatiuk
Hi,

Dima, that's really good approach. 

Mike, technical writer may ask developer and assign bug to him/her if bug 
impacts developer documentation only.

Best Regards,
Sergii Golovatiuk

 On 08 Oct 2014, at 21:08, Mike Scherbakov mscherba...@mirantis.com wrote:
 
 Thanks Dmitry,
 let's try to go this way and correct process if needed when we get first 
 results.
 
  Where is your 80% dev vs user docs figure coming from?
 it's no more than my guess. We will see real number over time.
 
 On Wed, Oct 8, 2014 at 10:31 PM, Dmitry Borodaenko 
 dborodae...@mirantis.com wrote:
 At the moment OpenStack infrastructure doesn't allow to customize the
 bugs it creates, we should propose a patch at some point to implement
 that. When we do, I think we should assign such bugs automatically to
 fuel-docs team.
 
 I don't think we should separate user and dev docs bugs, we're working
 in the opposite direction towards merging dev docs into fuel-docs:
 https://review.openstack.org/124551
 
 Where is your 80% dev vs user docs figure coming from?
 
 I think that whether it's dev or user documentation, a technical
 writer should drive the process, collect information from the commit
 author, and add it to the right documentation areas. It's commit
 author's responsibility to provide an informative commit message in
 the first place, to answer technical writer's questions, and to review
 docs commits that address the DocImpact bug.
 
 On Oct 8, 2014 10:59 AM, Mike Scherbakov mscherba...@mirantis.com wrote:
 
  Very good improvement in our documentation process.
 
  Is there a way to configure it, so bugs would be created with tag docs 
  automatically? It would simplify triaging process I believe.
  From the other hand, as far as I understand, up to 80% of commits with 
  DocImpact will impact development documentation (or it's intended to be 
  affecting only user documentation?). It would be hard for tech writers, 
  who are mostly specialized in Fuel user docs, to work on low-level details 
  of how, let's say, l23network [1] works.
  Do we want to separate docs bugs somehow, user/dev?
 
  In other words, what would be the flow, who becomes responsible for fixing 
  bugs created automatically by Infra?
 
  [1] 
  https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network
 
  On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk 
  sgolovat...@mirantis.com wrote:
 
  Hi,
 
  On Fuel Summit '2014 we discussed our Documentation process. According to 
  follow up we aligned it to OpenStack 'DocImpact' process. The new process 
  has been tested on background by me and Bogdan Dobrelya. Today, I have 
  updated Fuel Documentation Process so we are making it official.
 
  Why?
  Developer perspective:
  It gives more flexibility for the developers to participate in 
  Documentation Process. Every time when the Reviewer sees that patch 
  requires Documentation update, it may ask the Commiter to update 'Commit 
  Message' with DocImpact message. Once patch passes the review Openstack 
  Infra will trigger a new bug in Launchpad that should be assigned to Fuel 
  Documentation team.
 
  From Fuel Documentation Team perspective:
  When Fuel Documentation Team sees this bug they know who was the commiter 
  and reviewers and whom they should add for documentation review.
 
  Community:
  Community member may ask the developer to put 'DocImpact' message when 
  it's required.
 
 ___
 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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Keystone][Oslo] User mapping and X509 for signing

2014-10-08 Thread Adam Young
When gyee posted his X509 server-side auth plugin patch,  the feedback 
we gave was that it should be using the mapping code from Federation to 
transform the environment variables set by the web server to the 
Keystone userid, username, domain name, and so forth.


The PKI token format currently allows for a single signing cert.  I have 
a proposal to allow for multiple signers.  One issue, though, is how to 
map from the certificates signer-info to the Keystone server that signed 
the data.   signer-data is part of the CMS message format, and can be 
used to uniquely identify the certificate that signed the document.  
From the signer-data, we can fetch the certificate.


SO, we could build a system that allowed us to fetch multiple certs for 
checking signatures.  But then the question is, which cert maps to the 
entity authorized to sign for this data.


OpenStack lacks a way to enumerate the systems, endpoints or otherwise.  
I'm going to propose that we create a service domain and that any system 
responsible for signing a document have a user created inside that 
domain.  I think we want to make the endpoint id match the user ID for 
endpoints, and probably something comparable for Nova Compute services.


This means we can use the associated keystone user to determine what 
Compute node signed a message.  It gives us PKI based, asymetric Oslo 
message signing.


This same abstraction should be extended to Kite for symmetric keys.

In order to convert the certificate data to the Keystone User ID, we can 
use the Mapping mechanism from Federation, just like we are planning on 
for the X509 Auth Plugin.


One thing I want to make explicit, and get some validation on from the 
community:  is it acceptable to say that there needs to be a mappable 
link between AL  X509 certificates distributed by a certain CA, for a 
certain Domain and the users in there?  It seems to me to be comparable 
to the LDAP constraints.  Is this a reasonable assumption?  If not, it 
seems like the X509 mechanism is really not much more than a naked 
Public Key.


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


[openstack-dev] [sahara] 2014.1.3 release

2014-10-08 Thread Sergey Lukjanov
Hi,

I'm glad to to announce the 2014.1.3 stable Icehouse release for Sahara.

You could find all the info at:

https://launchpad.net/sahara/icehouse/2014.1.3

The 2014.1.4 is expected after the Kilo-3 release.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Sahara] Juno RC2 available

2014-10-08 Thread Sergey Lukjanov
I've just pushed the tags to sahara-image-elements and sahara-extra:

http://tarballs.openstack.org/sahara-image-elements/sahara-image-elements-2014.2.rc2.tar.gz
http://tarballs.openstack.org/sahara-extra/sahara-extra-2014.2.rc2.tar.gz

Thanks.

P.S. We have no sahara-dashboard release due to the fact that it was merged
to Horizon.

On Tue, Oct 7, 2014 at 1:26 PM, Thierry Carrez thie...@openstack.org
wrote:

 Hello everyone,

 Due to various regressions and documentation issues in the published
 Sahara RC1, we generated a new Juno release candidate for Sahara:

 https://launchpad.net/sahara/juno/juno-rc2

 Unless new release-critical issues are found that warrant a release
 candidate respin, this RC2 will be formally released as Sahara 2014.2 on
 October 16. You are therefore strongly encouraged to test and validate
 this tarball !

 Alternatively, you can directly test the proposed/juno branch at:
 https://github.com/openstack/sahara/tree/proposed/juno

 If you find an issue that could be considered release-critical, please
 file it at:

 https://bugs.launchpad.net/sahara/+filebug

 and tag it *juno-rc-potential* to bring it to the release crew's
 attention.

 Regards,

 --
 Thierry Carrez (ttx)

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




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [all] [oslo] Proposed database connectivity patterns

2014-10-08 Thread Mike Bayer
Hi all -

I’ve drafted up my next brilliant idea for how to get Openstack projects to use 
SQLAlchemy more effectively.   The proposal here establishes significant detail 
on what’s wrong with the current state of things, e.g. the way I see 
EngineFacade, get_session() and get_engine() being used, and proposes a new 
system that provides a true facade around a managed context.   But of course, 
it requires that you all change your code!  (a little bit).  Based on just a 
few tiny conversations on IRC so far, seems like this might be a hard sell.  
But please note, most projects are pretty much broken in how they use the 
database - this proposal is just a first step to making it all non-broken, if 
not as amazing and cool as some people wish it could be.  Unbreaking the code 
and removing boilerplate is the first step - with sane and declarative patterns 
in place, we can then build in more bells and whistles.

Hoping you’re all super curious now, here it is!  Jump in:  
https://review.openstack.org/#/c/125181/

- mike







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


Re: [openstack-dev] TC candidacy

2014-10-08 Thread Adam Lawson
It seems I left out a response. Sorry for the follow-on but here's what was
missing.

*Topic: Technical Committee Mission*
*How do you feel the technical committee is doing in meeting the technical
committee mission?*

*The Technical Committee (TC) is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
Integration, Quality...), decides on issues affecting multiple programs,
forms an ultimate appeals board for technical decisions, and generally has
oversight over all the OpenStack project.*

I believe the TC has thus far done a pretty fair job given the team and its
charter are both rather new. While the TC has been providing leadership for
individual components, I would not characterize the TC today as providing
highly visible leadership (necessary for openness and transparency) which I
would like to see improved. Much of the TC's work today coalesces around
providing a safe harbor for meaningful program integration and ensure
challenges are resolved optimally but the TC needs to get better at
identifying the good/poorly-defined boundaries of this kind of technical
governance model. In other words, the TC needs to get better at being a
good TC. The instantiation of a TC is a perfect first step but the pink
elephant in the room seems to be around cross-project and architectural
guidance; ensuring Openstack as a whole is moving in a direction that
doesn't require accommodating things we shouldn't be doing in the first
place. The lack of API standardization is a great example of moving in a
direction without a big picture context.
 Communications that have gone back and forth and debated about the big
tent model, layers/cascading, scaling documentation, etc have been visible
and the candor of opposing viewpoints have been awesome to follow. But we
could really benefit from some structural adjustments so more decisions
placed before the team are equally visible, a visible and transparent
decision-making process enabling those who use Openstack understand the
architectural perspectives shepherding it. Not just the decision that have
100+ replies on the mailing list
 Oversight over all the projects is an area that I'm anticipating where
we have some easy low-hanging fruit. Where we are today with regard to
focus is understandable given the number of fires affecting individual
programs that cannot be ignored. But we have a big opportunity (there's
that word again) to get some traction on the larger architectural decisions
that may require more work up front but produce some big wins over the long
term. Customers who want to use Openstack have often played the constant
change = unstable card for good reason; Openstack has a long way to go
before it gets to Production-quality for the masses (i.e. without heavy
re-development requirements). I believe the TC can and should influence
that with better solution-level leadership.
 - The deployment challenge is beyond ready for attention.
- A working default 'out-of-the-box' config that can boot an instance
accessible over the network is STILL a challenge. Long past due in my mind.
- Programs like Oslo that address library requirements moves a cloud closer
to Production-capable but really shouldn't be optional. Doing something
well shouldn't be optional. In fact, a Production context shouldn't be one
option of many despite the prevalence of Openstack PoC and pilots; it
should be a consistent design assumption. Gating a feature to the point
that it's 'good enough' is part of the problem. It must be
Production-worthy otherwise it is NOT good enough. That's ready for
attention.
 We might not be able to address all of these and some ideas could use a
lot more cross-talk, but if elected I would like to champion improving how
the TC approaches problems and vets their potential solutions.


*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 Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson alaw...@aqorn.com wrote:

 Hello everyone!

 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step on a 

Re: [openstack-dev] TC candidacy

2014-10-08 Thread Anita Kuno
On 10/08/2014 05:29 PM, Adam Lawson wrote:
 It seems I left out a response. Sorry for the follow-on but here's what was
 missing.
 
 *Topic: Technical Committee Mission*
 *How do you feel the technical committee is doing in meeting the technical
 committee mission?*
 
 *The Technical Committee (TC) is tasked with providing the technical
 leadership for OpenStack as a whole (all official programs, as defined
 below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
 Integration, Quality...), decides on issues affecting multiple programs,
 forms an ultimate appeals board for technical decisions, and generally has
 oversight over all the OpenStack project.*
 
 I believe the TC has thus far done a pretty fair job given the team and its
 charter are both rather new. While the TC has been providing leadership for
 individual components, I would not characterize the TC today as providing
 highly visible leadership (necessary for openness and transparency) which I
 would like to see improved. Much of the TC's work today coalesces around
 providing a safe harbor for meaningful program integration and ensure
 challenges are resolved optimally but the TC needs to get better at
 identifying the good/poorly-defined boundaries of this kind of technical
 governance model. In other words, the TC needs to get better at being a
 good TC. The instantiation of a TC is a perfect first step but the pink
 elephant in the room seems to be around cross-project and architectural
 guidance; ensuring Openstack as a whole is moving in a direction that
 doesn't require accommodating things we shouldn't be doing in the first
 place. The lack of API standardization is a great example of moving in a
 direction without a big picture context.
  Communications that have gone back and forth and debated about the big
 tent model, layers/cascading, scaling documentation, etc have been visible
 and the candor of opposing viewpoints have been awesome to follow. But we
 could really benefit from some structural adjustments so more decisions
 placed before the team are equally visible, a visible and transparent
 decision-making process enabling those who use Openstack understand the
 architectural perspectives shepherding it. Not just the decision that have
 100+ replies on the mailing list
  Oversight over all the projects is an area that I'm anticipating where
 we have some easy low-hanging fruit. Where we are today with regard to
 focus is understandable given the number of fires affecting individual
 programs that cannot be ignored. But we have a big opportunity (there's
 that word again) to get some traction on the larger architectural decisions
 that may require more work up front but produce some big wins over the long
 term. Customers who want to use Openstack have often played the constant
 change = unstable card for good reason; Openstack has a long way to go
 before it gets to Production-quality for the masses (i.e. without heavy
 re-development requirements). I believe the TC can and should influence
 that with better solution-level leadership.
  - The deployment challenge is beyond ready for attention.
 - A working default 'out-of-the-box' config that can boot an instance
 accessible over the network is STILL a challenge. Long past due in my mind.
 - Programs like Oslo that address library requirements moves a cloud closer
 to Production-capable but really shouldn't be optional. Doing something
 well shouldn't be optional. In fact, a Production context shouldn't be one
 option of many despite the prevalence of Openstack PoC and pilots; it
 should be a consistent design assumption. Gating a feature to the point
 that it's 'good enough' is part of the problem. It must be
 Production-worthy otherwise it is NOT good enough. That's ready for
 attention.
  We might not be able to address all of these and some ideas could use a
 lot more cross-talk, but if elected I would like to champion improving how
 the TC approaches problems and vets their potential solutions.
 
 
 *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

Thanks Adam, I will add this to the wikipage.

Thanks,
Anita.
 
 On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson alaw...@aqorn.com wrote:
 
 Hello everyone!

 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I 

Re: [openstack-dev] [neutron] Creation of neutron-drivers team

2014-10-08 Thread Kyle Mestery
Sure, I'll add that section there.

On Tue, Oct 7, 2014 at 2:58 PM, Kevin Benton blak...@gmail.com wrote:
 Can you add a section to the wiki to document how a core can become a member
 of the drivers team?

 On Tue, Oct 7, 2014 at 7:55 AM, Kyle Mestery mest...@mestery.com wrote:

 As discussed in today's meeting [1], I've created a neutron-drivers
 team [2], which was modeled on the same way as the existing
 nova-drivers team. This team will be responsible for approving specs
 for Kilo. Please see the wiki page for the long story, but the short
 story is that as focused team driving spec approval and a consistent
 architectural approach for Neutron in Kilo will be good for the
 long-term health of the project.

 As with all things process related, we'll try this out in Kilo and
 adjust accordingly at the end. I wanted to keep the broader community
 aware of this new team.

 Thanks!
 Kyle

 [1]
 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-07-14.01.html
 [2] https://wiki.openstack.org/wiki/Neutron-drivers

 ___
 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


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


[openstack-dev] [Heat] planning for the midcycle meetup.

2014-10-08 Thread Angus Salkeld
Hi all

I know it may seem early, but it helps with people organising their travel.

In our weekly meeting we created an etherpad to start planning for our
midcycle meetup [1]. Can everyone have a look and add your preferences and
if you have yet another venue add it to the list.

Any help with organisation is welcome.

[1] https://etherpad.openstack.org/p/kilo-heat-midcycle-meetup

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


[openstack-dev] [nova] gerrit based statistics

2014-10-08 Thread Joe Gordon
Recently there has been a lot of discussion around the development growing
pains in nova. Instead of guessing about how bad some of the issues are, I
tried to answer a few questions that may help us better understand the
issues.


Q: How many revisions does it take to merge a patch?

Average: 6.76 revisions
median: 4.0 revisions


Q: How many rechecks/verifies does it take to merge a patch (ignoring
rechecks where the same job failed before and after)?

Average: 0.749 rechecks per patch revision
median: 0.4285  rechecks per patch revision

For comparison here are the same results for tempest, which has a lot more
gating tests:

Average: 1.01591525738
median: 0.6


Q: How long does it take for a patch to get approved?

Average: 28 days
median: 11 days


Q: How long does it take for a patch to get approved that touches
'nova/virt/'?

Average: 34 days
median: 18 days


When looking at these numbers two things stick out out:

* We successfully use recheck an awful lot. More then I expected
* Patches that touch 'nova/virt' take about 20% more time to land or about
6 days. While that is definitely a difference, its smaller then I expected


Dataset: last 800 patches in nova
Code: https://github.com/jogo/gerrit-fun
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] ./run_tests.sh fails to create the .venv environment for neutron

2014-10-08 Thread Vasudevan, Swaminathan (PNB Roseville)
Hi Folks,

./run_tests.sh fails to create the .venv with the latest neutron repo.
It fails at MySQL-python.
Does anyone know what is broken.

Downloading/unpacking oslotest=1.1.0 (from -r 
/home/stack/neutron/test-requirements.txt (line 20))
  Downloading oslotest-1.1.0-py2.py3-none-any.whl
Downloading/unpacking psycopg2 (from -r 
/home/stack/neutron/test-requirements.txt (line 21))
  Downloading psycopg2-2.5.4.tar.gz (682kB): 682kB downloaded
  Running setup.py (path:/home/stack/neutron/.venv/build/psycopg2/setup.py) 
egg_info for package psycopg2

Downloading/unpacking MySQL-python (from -r 
/home/stack/neutron/test-requirements.txt (line 22))
  Downloading MySQL-python-1.2.5.zip (108kB): 108kB downloaded
  Running setup.py (path:/home/stack/neutron/.venv/build/MySQL-python/setup.py) 
egg_info for package MySQL-python
sh: 1: mysql_config: not found
Traceback (most recent call last):
  File string, line 17, in module
  File /home/stack/neutron/.venv/build/MySQL-python/setup.py, line 17, in 
module
metadata, options = get_config()
  File setup_posix.py, line 43, in get_config
libs = mysql_config(libs_r)
  File setup_posix.py, line 25, in mysql_config
raise EnvironmentError(%s not found % (mysql_config.path,))
EnvironmentError: mysql_config not found
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found

Traceback (most recent call last):

  File string, line 17, in module

  File /home/stack/neutron/.venv/build/MySQL-python/setup.py, line 17, in 
module

metadata, options = get_config()

  File setup_posix.py, line 43, in get_config

libs = mysql_config(libs_r)

  File setup_posix.py, line 25, in mysql_config

raise EnvironmentError(%s not found % (mysql_config.path,))

EnvironmentError: mysql_config not found


Cleaning up...
Command python setup.py egg_info failed with error code 1 in 
/home/stack/neutron/.venv/build/MySQL-python
Storing debug log for failure in /home/stack/.pip/pip.log
Command tools/with_venv.sh pip install --upgrade -r 
/home/stack/neutron/test-requirements.txt failed.
None
stack@ubuntu:~/neutron$

Thanks.

Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com


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


Re: [openstack-dev] [nova] gerrit based statistics

2014-10-08 Thread Joe Gordon
On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon joe.gord...@gmail.com wrote:

 Recently there has been a lot of discussion around the development growing
 pains in nova. Instead of guessing about how bad some of the issues are, I
 tried to answer a few questions that may help us better understand the
 issues.


 Q: How many revisions does it take to merge a patch?

 Average: 6.76 revisions
 median: 4.0 revisions


 Q: How many rechecks/verifies does it take to merge a patch (ignoring
 rechecks where the same job failed before and after)?

 Average: 0.749 rechecks per patch revision
 median: 0.4285  rechecks per patch revision

 For comparison here are the same results for tempest, which has a lot more
 gating tests:

 Average: 1.01591525738
 median: 0.6


 Q: How long does it take for a patch to get approved?

 Average: 28 days
 median: 11 days


 Q: How long does it take for a patch to get approved that touches
 'nova/virt/'?

 Average: 34 days
 median: 18 days


To expand on these numbers, same results for last 6 months of commits:

all of nova (1723 patches):
Average: 28.8
median: 11.0

nova/virt (476 patches):
 Average: 34.5




 When looking at these numbers two things stick out out:

 * We successfully use recheck an awful lot. More then I expected
 * Patches that touch 'nova/virt' take about 20% more time to land or about
 6 days. While that is definitely a difference, its smaller then I expected


 Dataset: last 800 patches in nova
 Code: https://github.com/jogo/gerrit-fun

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


Re: [openstack-dev] [nova] gerrit based statistics

2014-10-08 Thread Michael Still
On Thu, Oct 9, 2014 at 11:58 AM, Joe Gordon joe.gord...@gmail.com wrote:
 On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon joe.gord...@gmail.com wrote:

 Recently there has been a lot of discussion around the development growing
 pains in nova. Instead of guessing about how bad some of the issues are, I
 tried to answer a few questions that may help us better understand the
 issues.


 Q: How many revisions does it take to merge a patch?

 Average: 6.76 revisions
 median: 4.0 revisions


 Q: How many rechecks/verifies does it take to merge a patch (ignoring
 rechecks where the same job failed before and after)?

 Average: 0.749 rechecks per patch revision
 median: 0.4285  rechecks per patch revision

 For comparison here are the same results for tempest, which has a lot more
 gating tests:

 Average: 1.01591525738
 median: 0.6


 Q: How long does it take for a patch to get approved?

 Average: 28 days
 median: 11 days


 Q: How long does it take for a patch to get approved that touches
 'nova/virt/'?

 Average: 34 days
 median: 18 days


 To expand on these numbers, same results for last 6 months of commits:

 all of nova (1723 patches):
 Average: 28.8
 median: 11.0

 nova/virt (476 patches):
  Average: 34.5

I think it would be interesting to break this up by driver
directory... Are there drivers which take longer to land code for than
others?

 When looking at these numbers two things stick out out:

 * We successfully use recheck an awful lot. More then I expected
 * Patches that touch 'nova/virt' take about 20% more time to land or about
 6 days. While that is definitely a difference, its smaller then I expected


 Dataset: last 800 patches in nova
 Code: https://github.com/jogo/gerrit-fun



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


Michael

-- 
Rackspace Australia

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


[openstack-dev] 答复: [Heat] Nominating Pavlo Shchelokovskyy for heat-core

2014-10-08 Thread Huangtianhua
congratulations:)

-邮件原件-
发件人: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com] 
发送时间: 2014年10月9日 1:29
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

Hi fellow Heat Cores,

thank you for your support. I am very proud to become part of this team, and I 
will do my best to use my new superpowers wisely and responsibly.

Best regards,
Pavlo.

On Wed, Oct 8, 2014 at 1:22 AM, Angus Salkeld asalk...@mirantis.com wrote:
 Congrats Pavlo, I have added you to core.

 -Angus

 On Wed, Oct 8, 2014 at 1:18 AM, Jeff Peeler jpee...@redhat.com wrote:

 +1

 On 10/06/2014 04:41 PM, Zane Bitter wrote:

 I'd like to propose that we add Pavlo Shchelokovskyy to the 
 heat-core team.

 Pavlo has been a consistently active member of the Heat community - 
 he's a regular participant in IRC and at meetings, has been making 
 plenty of good commits[1] and maintains a very respectable review 
 rate[2] with helpful comments. I think he's built up enough 
 experience with the code base to be ready for core.

 Heat-cores, please vote by replying to this thread. As a reminder of 
 your options[3], +1 votes from 5 cores is sufficient; a -1 is 
 treated as a veto.


 Obviously past 5 +1 votes here, but showing full support doesn't hurt.



 cheers,
 Zane.

 [1]

 https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+st
 atus:merged+project:openstack/heat,n,z

 [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
 [3]
 https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Mem
 bers



 ___
 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] OpenStack Technical Committee Nomination

2014-10-08 Thread Sean Dague
I'd like to announce throwing my hat into the ring for the OpenStack
Technical Committee.

= My Background on the Project =

I've been a contributor to OpenStack since late in the Essex release. I
was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer
on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project
Config repo in infra, and a host of other projects in OpenStack. I was
elected to the TC last fall as part of the first fully directed TC.

You might also know me from the fact that I spend a lot of time on the
OpenStack gate, which really means I spend a lot of time trying to
understand why when all the OpenStack components run together, they
often break horribly, and actually try to debug and address those. I was
part of the team that built Elastic Recheck
(http://status.openstack.org/elastic-recheck/) for that effort.

In any particular release of OpenStack I'm typically one of the largest
reviewers of code. A lot of these are help shepherding in easy fixes
that get lost in our review queues. I built things like Gerrit Dashboard
Creator (https://github.com/stackforge/gerrit-dash-creator) to make it
easier for reviewers to sift patches to make sure that good patches
don't get lost, and make reviewer's lives easier.

And I am a strong believer that the way we grow our community is through
growing our contributors. This is one of the reasons I kicked off the
OpenStack Bootstrapping Hour
(https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and
Dan Smith, to provide one avenue for this growth to happen. I think many
other are required as well, but this is one way to get us started.

= My Views on the Future of OpenStack and the TC =

I feel like OpenStack is at a crossroads. The original definition of the
integrated release, and horizontal teams was built around the concept of
2 projects. It worked at 5. It was strained at 8. And I think we're now
on the very of it being completely broken.

I think that in order for OpenStack to move forward we need to
pragmatically redefine the integrated release as the set of horizontal
components that have to be linked together to be useful. Exactly the
right unit I think is up for debate. It could be as small as Nova,
Glance, Keystone, Neutron. It might include Cinder, Designate, and / or
Oslo (I can see the case for and against any of these). Those should be
the projects that QA, Docs, and Stable Maint, Release Management,
Security Team, and the TC needs to take responsibility for.

I think that we need to have an expansive ecosystem where projects like
Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally,
Ironic, and all the other really interesting projects can flourish. I
think their inclusion in the OpenStack umbrella should be a lightweight
process that is largely a self assessment and an acceptance of certain
principles that are core to OpenStack. I think these projects should be
self responsible for their own QA, Docs, Stable Maint, Security, and
Release Management. And I think mentoring should be made available to
help them with any of these. I believe a structure similar to the User
Committee is probably most appropriate here. However we get this body,
it should have an electorate (directly or indirectly) that represents
ATCs from the broadest expanse of our ecosystem.

I think the TC needs to evolve from a policy body, to a body that's
primarily directly responsible for the integrated release (as I defined
above). Direct responsibility means more than approving and managing gap
analysis plans. It means diving directly into project code across all
the integrated release projects at substantial regularity. It could mean
the TC inheriting +2 on the integrated projects and horizontal efforts
supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we
could only do this with a strong set of expectations and checks and
balances to prevent abuse, but it's an idea that's interesting to think
about).

I would like to think about this as a tight integrated release plus a
large and solid ecosystem.

These are things I'm going to push for going forward, whether or not I'm
on the TC, however I think the idea of having the TC take more ownership
of the integrated release, directly. We need an OpenStack base box set
with more full and cohesive user experience (one that doesn't require
understanding and maintaining multiple db systems), that is deployable
at everything from small colleges and institutions, to giant places like
wall street, telcos, and research institutions. And then we need to have
space to promote great expansions to OpenStack the institutions can
deploy as needed for their needs that a much freer to use exciting new
technology to solve interesting problems.

= Standard TC Questions =

== How do you feel the technical community is doing in meeting the
OpenStack Mission? ==

Our mission statement is: To produce the ubiquitous OpenSource Cloud
Computing platform that will meet the 

[openstack-dev] [Zaqar] How to get the pool list in graceful way.

2014-10-08 Thread Lei Zhang
The question comes from my patch[1]. Kgriffs point that there are two
way to get all the pools. But I don’t know which one is better, event
though I comment that limit=0 is wired. I think there are three ways.

use limit=0( current logical).
pro: 1) may easy to implement
con: 1) not clearly and wired. 2) may some storage driver doesn’t support?
call .list multiple times
pro: 1) directly and compatiblely
con: 1) multiple request must make when the list size is too large.
define a new method named list_all

[1] https://review.openstack.org/#/c/123462/5/zaqar/queues/storage/pooling.py

-- 
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l

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


Re: [openstack-dev] [nova] gerrit based statistics

2014-10-08 Thread Joe Gordon
On Wed, Oct 8, 2014 at 6:12 PM, Michael Still mi...@stillhq.com wrote:

 On Thu, Oct 9, 2014 at 11:58 AM, Joe Gordon joe.gord...@gmail.com wrote:
  On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon joe.gord...@gmail.com
 wrote:
 
  Recently there has been a lot of discussion around the development
 growing
  pains in nova. Instead of guessing about how bad some of the issues
 are, I
  tried to answer a few questions that may help us better understand the
  issues.
 
 
  Q: How many revisions does it take to merge a patch?
 
  Average: 6.76 revisions
  median: 4.0 revisions
 
 
  Q: How many rechecks/verifies does it take to merge a patch (ignoring
  rechecks where the same job failed before and after)?
 
  Average: 0.749 rechecks per patch revision
  median: 0.4285  rechecks per patch revision
 
  For comparison here are the same results for tempest, which has a lot
 more
  gating tests:
 
  Average: 1.01591525738
  median: 0.6
 
 
  Q: How long does it take for a patch to get approved?
 
  Average: 28 days
  median: 11 days
 
 
  Q: How long does it take for a patch to get approved that touches
  'nova/virt/'?
 
  Average: 34 days
  median: 18 days
 
 
  To expand on these numbers, same results for last 6 months of commits:
 
  all of nova (1723 patches):
  Average: 28.8
  median: 11.0
 
  nova/virt (476 patches):
   Average: 34.5

 I think it would be interesting to break this up by driver
 directory... Are there drivers which take longer to land code for than
 others?


Like this?

subtree: None (1724 patches):
Average: 28.7
median: 11.0
subtree: nova/virt/ (476 patches):
Average: 34.5
median: 18.0
subtree: nova/virt/hyperv/ (38 patches):
Average: 46.8
median: 33.0
subtree: nova/virt/libvirt/ (224 patches):
Average: 35.9
median: 18.0
subtree: nova/virt/xenapi/ (72 patches):
Average: 39.5
median: 20.0
subtree: nova/virt/vmwareapi/ (134 patches):
Average: 38.7
median: 26.0



  When looking at these numbers two things stick out out:
 
  * We successfully use recheck an awful lot. More then I expected
  * Patches that touch 'nova/virt' take about 20% more time to land or
 about
  6 days. While that is definitely a difference, its smaller then I
 expected
 
 
  Dataset: last 800 patches in nova
  Code: https://github.com/jogo/gerrit-fun
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 Michael

 --
 Rackspace Australia

 ___
 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] Proposing to disallow updates of IPv6 attributes on subnets

2014-10-08 Thread Martinx - ジェームズ
Hi!

Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN
Provider Network + static IPv6.

I created the subnet(s) like this (one for each tenant):

--
neutron net-create --tenant-id $ID --provider:physical_network=physnet1
--provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200

neutron subnet-create --ip-version 6 --disable-dhcp --tenant-id $ID
physnet1-vlan200 2001:db8:1::/64 --allocation-pool
start=2001:db8:1::8000,end=2001:db8:1:0::::fffe
--

This new BUGs means that, after upgrading to Juno, I'll not be able to
update / convert this static network to SLAAC ?!?!

If yes, how can I force the update without breaking the production
environment? Is there a procedure to follow?

I'm not using Neutron L3 Router and I have no plans to use GRE/VXLAN,
neither a radvd controlled by Neutron. My upstream router already have
radvd ready.

Thanks!
Thiago

On 7 October 2014 13:21, Henry Gessau ges...@cisco.com wrote:

 A number of bugs[1][2][3] have been filed which are related to updating the
 IPv6 attributes after a subnet has been created.

 In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
 questions have been raised, which were discussed in today's IPv6 IRC
 meeting[6].

 Summary:
 In Juno we are not ready for allowing the IPv6 attributes on a subnet to be
 updated after the subnet is created, because:
 - The implementation for supporting updates is incomplete.
 - Perceived lack of usefulness, no good use cases known yet.
 - Allowing updates causes more complexity in the code.
 - Have not tested that radvd, dhcp, etc. behave OK after update.

 Therefore we are proposing to change 'allow_put' to False for the two IPv6
 attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes
 from being updated via the PUT:subnets API.

 We would be interested to hear of any disagreements or questions.


 [1] https://launchpad.net/bugs/1362966
 [2] https://launchpad.net/bugs/1363064
 [3] https://launchpad.net/bugs/1373417
 [4] https://review.openstack.org/125328
 [5] https://review.openstack.org/117799
 [6]

 http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html

 ___
 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] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread joehuang
Hello, Duncan, 

The design goal is to keep the user experience under cascading as what they are 
using one OpenStack instance.


Locality objects: VM ( with availability zone attribute ) ,Volume ( with 
availability zone attribute ), VLAN Network, Port(follow VM vif)

 
Global objects: Quata,Usage, all KeyStone objects, Router, LB, SNAT, FIP, FW, 
VPN, Image ( public image will be available globally, project wide image will 
be global to where the project spreads ) 


Dependency on deployment policy: VxLAN network ( could be global or local ), 
Backup (depends on backup to local swift or global swift), Snapshot of Volume ( 
most deployment will store snapshot in locality, if the snapshot uploaded to 
the glance, it'll be global image, refer to image part ) 


Of course, we have only done the PoC, maybe there are still some unknown 
challenges. Whenever a new issue comes, we are able to find a way to solve it 
by the recursive self-similar mechanism ( please refer to 
https://www.linkedin.com/pulse/article/20140729022031-23841540-openstack-cascading-and-fractal?trk=prof-post
 )


Best Regards
Chaoyi Huang ( Joe Huang )

-Original Message-
From: Duncan Thomas [mailto:duncan.tho...@gmail.com] 
Sent: Tuesday, October 07, 2014 9:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack 
cascading

My data consistency concerts would be around:

1) Defining global state. You can of course hand wave away a lot of your issues 
by saying they are all local to the sub-unit, but then what benefit are you 
providing .v. just providing a list of endpoints and teaching the clients to 
talk to multiple endpoints, which is far easier to make reliable than a new 
service generally is. State that 'ought' to be global: quota, usage, floating 
ips, cinder backups, and probably a bunch more

2) Data locality expectations. You have to be careful about what expectations 
.v. realty you're providing here. If the user experience is substantially 
different using your proxy .v. direct API, then I don't think you are providing 
a useful service - again, just teach the clients to be multi-cloud aware. This 
includes what can be connected to what (cinder volumes, snaps, backups, 
networks, etc), replication behaviours and speeds (swift) and probably a bunch 
more that I haven't thought of yet.



On 7 October 2014 14:24, joehuang joehu...@huawei.com wrote:
 Hello, Joshua,

 Thank you for your concerns on OpenStack cascading. I am afraid that I am not 
 proper person to give comment on cells, but I would like to speak a little 
 about cascading for you mentioned with its own set of consistency warts I'm 
 sure .

 1. For small scale or a cloud within one data centers, one OpenStack instance 
 (including cells) without cascading feature can work just like it work today. 
 OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... 
 like other vendor specific agent/driver( for example, vcenter driver, hyper-v 
 driver, linux-agent.. ovs-agent ), and does not change the current 
 architecture for Nova/Cinder/Neutron..., and does not affect the aleady 
 developed features and deployment capability. The cloud operators can skip 
 the existence of OpenStack cascading if they don't want to use it, just like 
 they don't want to use some kinds of hypervisor / sdn controller 

 2. Could you provide concrete inconsistency issues you are worried about in 
 OpenStack cascading? Although we did not implement inconsistency check in the 
 PoC source code completely, but because logical VM/Volume/Port/Network... 
 objects are stored in the cascading OpenStack, and the physical objects are 
 stored in the cascaded OpenStack, uuid mapping between logical object and 
 physical object had been built,  it's possible and easy to solve the 
 inconsistency issues. Even for flavor, host aggregate, we have method to 
 solve the inconsistency issue.

 Best Regards

 Chaoyi Huang ( joehuang )
 
 From: Joshua Harlow [harlo...@outlook.com]
 Sent: 07 October 2014 12:21
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack cascading

 On Oct 3, 2014, at 2:44 PM, Monty Taylor mord...@inaugust.com wrote:

 On 09/30/2014 12:07 PM, Tim Bell wrote:
 -Original Message-
 From: John Garbutt [mailto:j...@johngarbutt.com]
 Sent: 30 September 2014 15:35
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack cascading

 On 30 September 2014 14:04, joehuang joehu...@huawei.com wrote:
 Hello, Dear TC and all,

 Large cloud operators prefer to deploy multiple OpenStack 
 instances(as
 different zones), rather than a single monolithic OpenStack 
 instance because of these reasons:

 1) Multiple data centers distributed 

Re: [openstack-dev] [nova-specs] WARNING: document isn't included in any toctree

2014-10-08 Thread Manickam, Kanagaraj
Hi Dims,

Thanks. I will move to approved folder.

Regards
Kanagaraj M

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Wednesday, October 08, 2014 5:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova-specs] WARNING: document isn't included in 
any toctree

Kanagaraj,

Drop it in specs/kilo/approved/ should work fine.

-- dims

On Wed, Oct 8, 2014 at 7:01 AM, Manickam, Kanagaraj kanagaraj.manic...@hp.com 
wrote:
 Hi,



 I tried to add a spec under specs/kilo folder and got the following
 exception:



 ERROR: InvocationError:
 '/home/jenkins/workspace/gate-nova-specs-docs/.tox/venv/bin/python 
 setup.py build_sphinx'



 http://logs.openstack.org/66/126866/1/check/gate-nova-specs-docs/c00ed
 fe/console.html





 Can anyone please help here to fix it.



 Regards

 Kanagaraj M


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




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

___
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] [api] Forming the API Working Group

2014-10-08 Thread Everett Toews
https://wiki.openstack.org/wiki/API_Working_Group

This is the start of the API Working Group (API WG). 

To avoid bike shedding over the name of the working group, I decided to title 
the wiki page API Working Group. Simple, to the point, and avoids loaded terms 
like standards, best practices, guidelines, conventions, etc.

The point isn’t what we name it. The point is what action we take about it. I 
propose the deliverables in the API WG wiki page.

Speaking of the wiki page, I wrote it very matter-of-factly. As if this is the 
way things are. They’re not. The wiki page is just a starting point. If 
something was missed, add it. If something can be improved, improve it. Let’s 
try to keep it simple though.

I invite everyone who chimed in on the original thread [1] that kicked this off 
to add themselves as a member committed to making the OpenStack APIs better. 
I’ve Cc’d everyone who asked to be kept in the loop.

I already see some cross project summit topics [2] on APIs. But frankly, with 
the number of people committed to this topic, I’d expect there to be more. I 
encourage everyone to submit more API related sessions with better descriptions 
and goals about what you want to achieve in those sessions.

Regards,
Everett

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046850.html
[2] https://etherpad.openstack.org/p/kilo-crossproject-summit-topics


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


Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Dmitry Borodaenko
I don't like how this discussion is framed. The initial premise that we have
only two controversial options to choose from is lazy. If there is no
consensus, we should look for more options, not for a popular vote.

Secondly, current level of UX is not negotiable. You can't take something that
we already have and that works (and current Fuel UI is the best out there by a
wide margin), and make it worse just to add a new feature. Even something as
important as plugins must be an incremental improvement.

With that premise, lets decompose the problem.

1. There are two levels of settings related to any plugin: a) first you have to
enable enable the plugin itself; b) when the plugin is enabled, it may expose
additional settings.

- How can it be acceptable to have all plugins always enabled in all
  environments? Do you really trust all plugin writers to carefully check for
  plugin-specific options and ensure there is zero impact on an environment if
  none of its options are enabled?

- If all your plugins are enabled everywhere, you can't uninstall any of them
  because all environments you deployed would become unmanageable.

- If you ignore uninstallation, soon you will be stuck with plugins that cannot
  be made removable even when Fuel itself begins to support it.

- To break away from unremovable plugins, you're likely going to have to break
  backwards compatibility (unless you already have a forward-compatible design
  that allows for removable plugins in the future, but then you wouldn't have
  to exclude removing plugins from MVP).

- And if a Fuel upgrade ever requires uninstalling a plugin due to
  irreconcilable incompatibility, and they're enabled in all of your
  environments, you're stuck unable to upgrade.

So, lets not enable any plugins by default. And if we can come up with a way to
make them removable (when they're not enabled in any deployed environments), we
should at least leave room for that in the design.

2. Either level of plugin settings (enable or configure) may be exposed in
setup wizard, settings page, or both.

- Yes, additional plugin settings also may show up in the wizard (e.g. vCenter
  credentials).

- Yes, we should maintain the settings page as the SSoT, and that means
  reflecting as many of setup wizard options in it as possible.

- Yes, for some options (like choice of operating system or network topology),
  our settings page is not dynamic enough to allow user to go back and revert
  them without recreating the environment.

- No, plugin writer shouldn't have to explicitly describe a checkbox to enable
  their plugin. They only should provide name and description of the plugin.
  Plugin engine should be able to produce a catalogue of installed plugins, and
  UI should generate enable checkboxes from that catalogue.

- If a plugin doesn't affect any available environment configuration options
  outside of the settings tab (i.e. setup wizard, network settings, node roles,
  disk  nic configuration), there's no reason to limit it to setup wizard, the
  enable checkbox and whatever other options it has should all be present in
  the settings page.

- Do we have any plugins in 6.0 that have to be present in setup wizard because
  they affect UI outside of settings page? I'm not aware of any.

If so, lets start by representing all plugin settings in the settings page. But
leave the room in the metadata to force some or all of plugin's settings to
show up in the setup wizard (or even to present plugin configuration options
differently in the wizard than in the settings).

Just my $2,
-DmitryB

On Wed, Oct 8, 2014 at 9:18 AM, Nikolay Markov nmar...@mirantis.com wrote:
 Vitaly,

 Once again, as a plugin developer I don't care about how Sahara or Murano is
 implemented. I don't care about checkboxes, either. I just want one simple
 command to run on target nodes and I should be provided with the simplest
 possible interface to:
 1) Write this command in some YAML and don't care about anything else
 2) Enable my plugin for particular environment and see if it's really
 enabled both on UI and CLI (and through pure API by simple field checking)

 If it provides some separate service - this doesn't change anything, I just
 need it to be listed somewhere in plugins inside cluster data to know that
 it'll be executed.

 How will it work with your approach?

 08 Окт 2014 г. 20:00 пользователь Vitaly Kramskikh
 vkramsk...@mirantis.com написал:

 Hi, responses inline.

 2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com:

 Hi,

 Vitaly, I understand your concerns about UX.
 But there are technical problems and statements which affect
 plugin developer and makes his live more complicated.

 My opinion is we definitely should know, if plugin is disabled
 or if it's enabled for specific environment.

 1. plugin developer defines tasks, like I want the script to be
 executed on nodes with controller role and I don't think that
 he expects this task to be run on all of the 

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread Joshua Harlow
On Oct 7, 2014, at 6:24 AM, joehuang joehu...@huawei.com wrote:

 Hello, Joshua, 
 
 Thank you for your concerns on OpenStack cascading. I am afraid that I am not 
 proper person to give comment on cells, but I would like to speak a little 
 about cascading for you mentioned with its own set of consistency warts I'm 
 sure .
 
 1. For small scale or a cloud within one data centers, one OpenStack instance 
 (including cells) without cascading feature can work just like it work today. 
 OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... 
 like other vendor specific agent/driver( for example, vcenter driver, hyper-v 
 driver, linux-agent.. ovs-agent ), and does not change the current 
 architecture for Nova/Cinder/Neutron..., and does not affect the aleady 
 developed features and deployment capability. The cloud operators can skip 
 the existence of OpenStack cascading if they don't want to use it, just like 
 they don't want to use some kinds of hypervisor / sdn controller   

Sure, I understand the niceness that u can just connect clouds into other 
clouds and so-on (the prettyness of the fractal that results from this). That's 
a neat approach and its cool that openstack can do this (so +1 for that). The 
bigger question I have though is around 'should we' do this. This introduces a 
bunch of proxies that from what I can tell are just making it so that nova, 
cinder, neutron can scale by plugging more little cascading components 
together. This kind of connecting them together is very much what I guess could 
be called an 'external' scaling mechanism, one that plugs into the external 
API's of one service from the internal of another (and repeat). The question I 
have is why an 'external' solution in the first place, why not just work on 
scaling the projects internally first and when that ends up not being good 
enough switch to an 'external' scaling solution. Lets take an analogy, your 
queries to mysql are acting slow, do you first, add in X more mysql servers or 
do you instead try to tune your existing mysql server and queries before 
scaling out? I just want to make sure we are not prematurely adding in X more 
layers when we can gain scalability in a more solveable  manageable manner 
first...

 
 2. Could you provide concrete inconsistency issues you are worried about in 
 OpenStack cascading? Although we did not implement inconsistency check in the 
 PoC source code completely, but because logical VM/Volume/Port/Network... 
 objects are stored in the cascading OpenStack, and the physical objects are 
 stored in the cascaded OpenStack, uuid mapping between logical object and 
 physical object had been built,  it's possible and easy to solve the 
 inconsistency issues. Even for flavor, host aggregate, we have method to 
 solve the inconsistency issue.

When you add more levels/layers, by the very nature of adding in those levels 
the number of potential failure points has now increased (there is probably a 
theorem or proof somewhere in literature about this). If you want to see 
inconsistencies that already exists just watch the gate issues and bugs and 
so-on for a while, you will eventually see why it may not be the right time to 
add in more potential failure points instead of fixing the existing failure 
points we already have. I (and I think others) would rather see effort focused 
on those existing failure points vs. adding a set of new ones in (make what 
exists reliable and scalable *first* then move on to scaling things out via 
something like cascading, cells, other...). Overall those same existing 
inconsistencies also make cascading inconsistent (by the very nature of the 
cascading model just being a combination of connected components, aka your 
fractal), since it's typically very hard to create consistent  stable out of 
components that are themselves not consistent and stable...

 
 Best Regards
 
 Chaoyi Huang ( joehuang )
 
 From: Joshua Harlow [harlo...@outlook.com]
 Sent: 07 October 2014 12:21
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack cascading
 
 On Oct 3, 2014, at 2:44 PM, Monty Taylor mord...@inaugust.com wrote:
 
 On 09/30/2014 12:07 PM, Tim Bell wrote:
 -Original Message-
 From: John Garbutt [mailto:j...@johngarbutt.com]
 Sent: 30 September 2014 15:35
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack
 cascading
 
 On 30 September 2014 14:04, joehuang joehu...@huawei.com wrote:
 Hello, Dear TC and all,
 
 Large cloud operators prefer to deploy multiple OpenStack instances(as
 different zones), rather than a single monolithic OpenStack instance 
 because of
 these reasons:
 
 1) Multiple data centers distributed geographically;
 2) Multi-vendor business policy;
 3) Server nodes scale up 

[openstack-dev] [nova] Nova API meeting

2014-10-08 Thread Christopher Yeoh
Hi,

Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC . 

We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.

In other timezones the meeting is at:

EST 20:00 (Thu)
Japan 09:00 (Fri)
China 08:00 (Fri)
ACDT 9:30 (Fri)

The proposed agenda and meeting details are here: 

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda. 

Chris

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