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

[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

[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

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

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

[Renat Akhmerov]

Yes, I already reviewed your commits. Thanks.

Renat Akhmerov
@ Mirantis Inc.



On 07 Oct 2014, at 15:06, Dmitri Zimine  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

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

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

[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

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

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

[openstack-dev] Virtual_machine for devstack

[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

[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

[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

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

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

Re: [openstack-dev] Virtual_machine for devstack

[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

[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

[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

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

[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

[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

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

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

[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

[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

[Sam Betts (sambetts)]

On 08/10/2014 10:39, "Ihar Hrachyshka"  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

[Duncan Thomas]

On 8 October 2014 10:39, Ihar Hrachyshka  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

[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

[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  wrote:
>
> On 8 October 2014 04:13, Joe Gordon  wrote:
>>
>>
>> On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg
>>  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 
>>> 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 
 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 
> 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 
> > 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 t

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

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

___
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

[Davanum Srinivas]

Kanagaraj,

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

-- dims

On Wed, Oct 8, 2014 at 7:01 AM, Manickam, Kanagaraj
 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

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

[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

[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

[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

[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
> , 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 :
>
>> >>> 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 
>> 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 
>> 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
>> >>  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 :
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> We had a meeting today about plugins on UI, as resul

[openstack-dev] [Fuel] Documentation Process changed

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

[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

[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

[Doug Hellmann]

On Sep 23, 2014, at 5:03 PM, Doug Hellmann  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

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

[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 
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
> , 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 :
>
>> >>> 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 
>> 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 
>> 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?
>

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

[Doug Hellmann]

On Oct 8, 2014, at 1:22 AM, Robert Collins  wrote:

> On 8 October 2014 11:10, Mike Bayer  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

[Doug Hellmann]

On Oct 8, 2014, at 5:20 AM, Julien Danjou  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

[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

[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

Re: [openstack-dev] TC candidacy

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

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

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

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

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

[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

[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

[Vitaly Kramskikh]

Hi, responses inline.

2014-10-08 21:09 GMT+07:00 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
>
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  > 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
>> , 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 :
>>
>>> >>> 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 
>>> 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 pro

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

[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

[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

[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 :
>
>> 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
>>> , 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 :
>>>
 >>> 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 comm

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

[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] Quota management and enforcement across projects

[Doug Hellmann]

On Oct 8, 2014, at 7:03 AM, Davanum Srinivas  wrote:

> Salvatore, Joe,
> 
> We do have this at the moment:
> 
> https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py
> 
> — dims

If someone wants to drive creating a useful library during kilo, please 
consider adding the topic to the etherpad we’re using to plan summit sessions 
and then come participate in the Oslo meeting this Friday 16:00 UTC.

https://etherpad.openstack.org/p/kilo-oslo-summit-topics

Doug

> 
> On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando  wrote:
>> 
>> On 8 October 2014 04:13, Joe Gordon  wrote:
>>> 
>>> 
>>> On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg
>>>  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 
 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 
> 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 
>> 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 
>>> 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 o

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

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

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

[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

[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"  wrote:

> On 8 October 2014 10:39, Ihar Hrachyshka  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

[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

[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  wrote:
> Congrats Pavlo, I have added you to core.
>
> -Angus
>
> On Wed, Oct 8, 2014 at 1:18 AM, Jeff Peeler  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

[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

[John Griffith]

On Wed, Oct 8, 2014 at 11:15 AM, David Lyle  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"  wrote:
>
>> On 8 October 2014 10:39, Ihar Hrachyshka  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] [Fuel] Documentation Process changed

[Mike Scherbakov]

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


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

[Robert Collins]

On 9 October 2014 06:26, Ben Nemec  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 
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

[Monty Taylor]

On 10/08/2014 10:45 AM, John Griffith wrote:
> On Wed, Oct 8, 2014 at 11:15 AM, David Lyle  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"  wrote:
>>
>>> On 8 October 2014 10:39, Ihar Hrachyshka  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] [sahara] team meeting Oct 9 1800 UTC

[Sergey Lukjanov]

Hi folks,

We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20141009T18

P.S. I'd like to continue discussing design summit sessions.

-- 
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] [Neutron] How to write extension

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

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

[Ben Nemec]

On 10/08/2014 12:53 PM, Robert Collins wrote:
> On 9 October 2014 06:26, Ben Nemec  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

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

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

> On 10/08/2014 10:45 AM, John Griffith wrote:
> > On Wed, Oct 8, 2014 at 11:15 AM, David Lyle  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" 
> wrote:
> >>
> >>> On 8 October 2014 10:39, Ihar Hrachyshka  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

[Devananda van der Veen]

On Wed, Oct 8, 2014 at 12:07 PM, Ben Nemec  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

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

[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

[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

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

[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

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

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

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

[Kyle Mestery]

Sure, I'll add that section there.

On Tue, Oct 7, 2014 at 2:58 PM, Kevin Benton  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  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.

[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

[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

[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 "", line 17, in 
  File "/home/stack/neutron/.venv/build/MySQL-python/setup.py", line 17, in 

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 "", line 17, in 

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


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

[Joe Gordon]

On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon  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

[Michael Still]

On Thu, Oct 9, 2014 at 11:58 AM, Joe Gordon  wrote:
> On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon  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

[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  wrote:
> Congrats Pavlo, I have added you to core.
>
> -Angus
>
> On Wed, Oct 8, 2014 at 1:18 AM, Jeff Peeler  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

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

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

[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

[Joe Gordon]

On Wed, Oct 8, 2014 at 6:12 PM, Michael Still  wrote:

> On Thu, Oct 9, 2014 at 11:58 AM, Joe Gordon  wrote:
> > On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon 
> 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

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

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

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

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

[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

[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  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"
>  написал:
>
>> Hi, responses inline.
>>
>> 2014-10-08 21:09 GMT+07:00 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

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

[Joshua Harlow]

On Oct 7, 2014, at 6:24 AM, joehuang  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  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  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) M

[openstack-dev] [nova] Nova API meeting

[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

[openstack-dev] [keystone] Using 'admin_token' option as token to create keystone client.

[Nader Lahouti]

Hi,

Is it acceptable to use 'admin_token' option from keystone.conf,  when
creating a keystone client? something like this:

kc = client.Client(token=cfg.CONF.admin_token,

   endpoint='http://localhost:35357/v2.0/')




Thanks,

Nader.
___
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

[henry hly]

Hi Joshua,

Absolutely internally improvement of single openstack is the first
important thing, and there are already much effort in the community.
For example, without optimization of security group, 200 nodes cluster
would have serve performance problem, now with several patchs in Juno
it's very easy to scale the number up to 500 or more.

The Cascading has no conflicts with that, in fact hierarchical scale
depends on square of single child scale. If a single child can deal
with 00's to 000's, cascading on it would then deal with 00,000's. And
besides ultra high scalability, the Cascading also care about
geo-location distribution, zone fault isolation, modularization plug
and play, and software maintenance isolation.

Conceptually the Cascading would not introduce extra consistence
problem because of its tree-like topology, but not peer mesh topology.
The parent openstack is the central processing point of all
user-facing request driven events, just as what happens in a single
openstack. From the top level view, each child openstack is just a
agent running on a "big host", while currently agent side state is
natural asynchronous with controller side db, so there would not be
extra consistence problem for cascading compared with single layer
openstack today.

Best Regads
Wu Hongning


On Thu, Oct 9, 2014 at 12:27 PM, Joshua Harlow  wrote:
> On Oct 7, 2014, at 6:24 AM, joehuang  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 somethin

Re: [openstack-dev] [keystone] Using 'admin_token' option as token to create keystone client.

[Lei Zhang]

it should works but it is not safe to use admin_token. Because
* It is a admin token which has the full privilege for the keystone service
* The token will be always valid till the admin_token in the conf file
is changed.
  It is dangerous when the token leak.

Suggest that the admin_token is only used for the initial of admin account.

On Thu, Oct 9, 2014 at 2:29 PM, Nader Lahouti  wrote:
> Hi,
>
> Is it acceptable to use 'admin_token' option from keystone.conf,  when
> creating a keystone client? something like this:
>
> kc = client.Client(token=cfg.CONF.admin_token,
>
>endpoint='http://localhost:35357/v2.0/')
>
>
>
>
> Thanks,
>
> Nader.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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