Re: [openstack-dev] [swift] Go! Swift!

[Clint Byrum]

Excerpts from Clay Gerrard's message of 2015-05-07 18:35:23 -0700:
> On Thu, May 7, 2015 at 3:48 PM, Clint Byrum  wrote:
> 
> > I'm still very curious to hear if anybody has been willing to try to
> > make Swift work on pypy.
> 
> 
> yeah, Alex Gaynor was helping out with it for awhile.  It worked.  And it
> helped.  A little bit.
> 
> Probably still worth looking at if you're curious, but I'm not aware of
> anyone who's currently working aggressively to productionize swift running
> on pypy.

So if I take your phrase "A little bit" to mean "Not enough to matter"
then I can imagine there isn't much more that can be done.

It sounds like there are really deep architectural issues in Swift that
need addressing, not just "make code run faster", but "get closer to
the metal" type efficiencies that are being sought.

This should be interesting indeed.

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

[openstack-dev] [Nova] Liberty mid-cycle meetup

[Michael Still]

As discussed at the Nova meeting this morning, we'd like to gauge
interest in a mid-cycle meetup for the Liberty release.

To that end, I've created the following eventbrite event like we have
had for previous meetups. If you sign up, you're expressing interest
in the event and if we decide there's enough interest to go ahead we
will email you and let you know its safe to book travel and that
you're ticket is now a real thing.

To save you a few clicks, the proposed details are 21 July to 23 July,
at IBM in Rochester, MN.

So, I'd appreciate it if people could take a look at:


https://www.eventbrite.com.au/e/openstack-nova-liberty-mid-cycle-developer-meetup-tickets-16908756546

Thanks,
Michael

PS: I haven't added this to the wiki list of sprints because it might
not happen. When the decision is final, I'll add it to the wiki if we
decide to go ahead.

-- 
Rackspace Australia

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

Re: [openstack-dev] [cinder] Taskflow 0.10.0 incompatible with NetApp NFS drivers

[Joshua Harlow]

Alright, it was as I had a hunch for, a small bug found in the new 
algorithm to make the storage layer 
copy-original,mutate-copy,save-copy,update-original (vs 
update-original,save-original) more reliable.


https://bugs.launchpad.net/taskflow/+bug/1452978 opened and a one line 
fix made @ https://review.openstack.org/#/c/181288/ to stop trying to 
copy task results (which was activating logic that must of caused the 
reference to drop out of existence and therefore the issue noted below).


Will get that released in 0.10.1 once it flushes through the pipeline.

Thanks alex for helping double check, if others want to check to that'd 
be nice, can make sure that's the root cause (overzealous usage of 
copy.copy, ha).


Overall I'd still *highly* recommend that the following still happen:

>> One way to get around whatever the issue is would be to change the
>> drivers to not update the object directly as it is not needed. But
>> this should not fail. Perhaps a more proper fix is for the volume
>> manager to not pass around sqlalchemy objects.

But that can be a later tweak that cinder does; using any taskflow 
engine that isn't the greenthreaded/threaded/serial engine will require 
results to be serializable, and therefore copyable, so that those 
results can go across IPC or MQ/other boundaries. Sqlalchemy objects 
won't fit either of these cases (obviously).


-Josh

Joshua Harlow wrote:

Are we sure this is taskflow? I'm wondering since those errors are more
from task code (which is in cinder) and the following seems to be a
general garbage collection issue (not connected to taskflow?):

'Exception during message handling: Can't emit change event for
attribute 'Volume.provider_location' - parent object of type 
has been garbage collected.'''

Or:

'''2015-05-07 22:42:51.142 17040 TRACE oslo_messaging.rpc.dispatcher
ObjectDereferencedError: Can't emit change event for attribute
'Volume.provider_location' - parent object of type  has been
garbage collected.'''

Alex Meade wrote:

So it seems that this will break a number of drivers, I see that
glusterfs does the same thing.

On Thu, May 7, 2015 at 10:29 PM, Alex Meade mailto:mr.alex.me...@gmail.com>> wrote:

It appears that the release of taskflow 0.10.0 exposed an issue in
the NetApp NFS drivers. Something changed that caused the sqlalchemy
Volume object to be garbage collected even though it is passed into
create_volume()

An example error can be found in the c-vol logs here:

http://dcf901611175aa43f968-c54047c910227e27e1d6f03bb1796fd7.r95.cf5.rackcdn.com/57/181157/1/check/cinder-cDOT-NFS/0473c54/


One way to get around whatever the issue is would be to change the
drivers to not update the object directly as it is not needed. But
this should not fail. Perhaps a more proper fix is for the volume
manager to not pass around sqlalchemy objects.


+1



Something changed in taskflow, however, and we should just
understand if that has other impact.


I'd like to understand that also: the only one commit that touched this
stuff is https://github.com/openstack/taskflow/commit/227cf52 (which
basically ensured that a storage object copy is modified, then saved,
then the local object is updated vs updating the local object, and then
saving, which has problems/inconsistencies if the save fails).



-Alex


__

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


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


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

Re: [openstack-dev] [Cinder] Static Ceph mon connection info prevents VM restart

[David Medberry]

Josh,

Certainly in our case the the monitor hosts (in addition to IPs) would have
made a difference.

On Thu, May 7, 2015 at 3:21 PM, Josh Durgin  wrote:

> Hey folks, thanks for filing a bug for this:
>
> https://bugs.launchpad.net/cinder/+bug/1452641
>
> Nova stores the volume connection info in its db, so updating that
> would be a workaround to allow restart/migration of vms to work.
> Otherwise running vms shouldn't be affected, since they'll notice any
> new or deleted monitors through their existing connection to the
> monitor cluster.
>
> Perhaps the most general way to fix this would be for cinder to return
> any monitor hosts listed in ceph.conf (as they are listed, so they may
> be hostnames or ips) in addition to the ips from the current monmap
> (the current behavior).
>
> That way an out of date ceph.conf is less likely to cause problems,
> and multiple clusters could still be used with the same nova node.
>
> Josh
>
> On 05/06/2015 12:46 PM, David Medberry wrote:
>
>> Hi Arne,
>>
>> We've had this EXACT same issue.
>>
>> I don't know of a way to force an update as you are basically pulling
>> the rug out from under a running instance. I don't know if it is
>> possible/feasible to update the virsh xml in place and then migrate to
>> get it to actually use that data. (I think we tried that to no avail.)
>> dumpxml=>massage cephmons=>import xml
>>
>> If you find a way, let me know, and that's part of the reason I'm
>> replying so that I stay on this thread. NOTE: We did this on icehouse.
>> Haven't tried since upgrading to Juno but I don't note any change
>> therein that would mitigate this. So I'm guessing Liberty/post-Liberty
>> for a real fix.
>>
>>
>>
>> On Wed, May 6, 2015 at 12:57 PM, Arne Wiebalck > > wrote:
>>
>> Hi,
>>
>> As we swapped a fraction of our Ceph mon servers between the
>> pre-production and production cluster
>> -- something we considered to be transparent as the Ceph config
>> points to the mon alias--, we ended
>> up in a situation where VMs with volumes attached were not able to
>> boot (with a probability that matched
>> the fraction of the servers moved between the Ceph instances).
>>
>> We found that the reason for this is the connection_info in
>> block_device_mapping which contains the
>> IP adresses of the mon servers as extracted by the rbd driver in
>> initialize_connection() at the moment
>> when the connection is established. From what we see, however, this
>> information is not updated as long
>> as the connection exists, and will hence be re-applied without
>> checking even when the XML is recreated.
>>
>> The idea to extract the mon servers by IP from the mon map was
>> probably to get all mon servers (rather
>> than only one from a load-balancer or an alias), but while our
>> current scenario may be special, we will face
>> a similar problem the day the Ceph mons need to be replaced. And
>> that makes it a more general issue.
>>
>> For our current problem:
>> Is there a user-transparent way to force an update of that
>> connection information? (Apart from fiddling
>> with the database entries, of course.)
>>
>> For the general issue:
>> Would it be possible to simply use the information from the
>> ceph.conf file directly (an alias in our case)
>> throughout the whole stack to avoid hard-coding IPs that will be
>> obsolete one day?
>>
>> Thanks!
>>   Arne
>>
>> --
>> Arne Wiebalck
>> CERN IT
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] upgrade_levels in nova upgrade

[Rui Chen]

Assuming my understanding is correct, 2 things make you sad in the upgrade
process.

1. must reconfig the 'upgrade_levels' in the config file during
post-upgrade.
2. must restart the service in order to make the option 'upgrade_level'
work.

I think the configuration management tools (e.g. chef, pupput) can solve
the #1.
We can change the 'upgrade_level' option in config file after upgrading and
sync it to all the hosts conveniently.

#2 is more complex, fortunately there are some works to try to solve it,
[1] [2].
If all the OpenStack services can support SIGHUP, I think we just need to
trigger a SIGHUP to make the services reload the config file.

Correct me If I'm wrong, thanks.


[1]: https://blueprints.launchpad.net/glance/+spec/sighup-conf-reload
[2]: https://bugs.launchpad.net/oslo-incubator/+bug/1276694



2015-05-07 16:09 GMT+08:00 Guo, Ruijing :

>  Hi, All,
>
>
>
> In existing design, we need to reconfig nova.conf and restart nova
> service during post-upgrade cleanup
>
> As https://www.rdoproject.org/Upgrading_RDO_To_Icehouse:
>
>
>
> I propose to send RPC message to remove RPC API version pin.
>
>
>
>
>
> 1.   Stop services  (same with existing)
>
> 2.   Upgrade packages (same with existing)
>
> 3.   Upgrade DB schema (same with existint)
>
> 4.   Start service with upgrade  (add upgrade parameter so that nova
> will use old version of RPC API. We may add more parameter for other
> purpose including query upgrade progress)
>
> 5.   Send RPC message to remove RPC API version pin. (we don’t need
> to reconfig nova.conf and restart nova service)
>
>
>
> What do you think?
>
>
>
> Thanks,
>
> -Ruijing
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Taskflow 0.10.0 incompatible with NetApp NFS drivers

[Joshua Harlow]

Are we sure this is taskflow? I'm wondering since those errors are more 
from task code (which is in cinder) and the following seems to be a 
general garbage collection issue (not connected to taskflow?):


'Exception during message handling: Can't emit change event for 
attribute 'Volume.provider_location' - parent object of type  
has been garbage collected.'''


Or:

'''2015-05-07 22:42:51.142 17040 TRACE oslo_messaging.rpc.dispatcher 
ObjectDereferencedError: Can't emit change event for attribute 
'Volume.provider_location' - parent object of type  has been 
garbage collected.'''


Alex Meade wrote:

So it seems that this will break a number of drivers, I see that
glusterfs does the same thing.

On Thu, May 7, 2015 at 10:29 PM, Alex Meade mailto:mr.alex.me...@gmail.com>> wrote:

It appears that the release of taskflow 0.10.0 exposed an issue in
the NetApp NFS drivers. Something changed that caused the sqlalchemy
Volume object to be garbage collected even though it is passed into
create_volume()

An example error can be found in the c-vol logs here:


http://dcf901611175aa43f968-c54047c910227e27e1d6f03bb1796fd7.r95.cf5.rackcdn.com/57/181157/1/check/cinder-cDOT-NFS/0473c54/

One way to get around whatever the issue is would be to change the
drivers to not update the object directly as it is not needed. But
this should not fail. Perhaps a more proper fix is for the volume
manager to not pass around sqlalchemy objects.


+1



Something changed in taskflow, however, and we should just
understand if that has other impact.


I'd like to understand that also: the only one commit that touched this 
stuff is https://github.com/openstack/taskflow/commit/227cf52 (which 
basically ensured that a storage object copy is modified, then saved, 
then the local object is updated vs updating the local object, and then 
saving, which has problems/inconsistencies if the save fails).




-Alex


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


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

Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering

[Andrew Beekhof]

> On 5 May 2015, at 7:52 pm, Bogdan Dobrelya  wrote:
> 
> On 05.05.2015 04:32, Andrew Beekhof wrote:
>> 
>> 
>> [snip]
>> 
>> 
>> Technically it calculates an ordered graph of actions that need to be 
>> performed for a set of related resources.
>> You can see an example of the kinds of graphs it produces at:
>> 
>>   
>> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/s-config-testing-changes.html
>> 
>> There is a more complex one which includes promotion and demotion on the 
>> next page.
>> 
>> The number of actions that can run at any one time is therefor limited by
>> - the value of batch-limit (the total number of in-flight actions)
>> - the number of resources that do not have ordering constraints between them 
>> (eg. rsc{1,2,3} in the above example)  
>> 
>> So in the above example, if batch-limit >= 3, the monitor_0 actions will 
>> still all execute in parallel.
>> If batch-limit == 2, one of them will be deferred until the others complete.
>> 
>> Processing of the graph stops the moment any action returns a value that was 
>> not expected.
>> If that happens, we wait for currently in-flight actions to complete, 
>> re-calculate a new graph based on the new information and start again.
>> 
>> 
>> First we do a non-recurring monitor (*_monitor_0) to check what state the 
>> resource is in.
>> We can’t assume its off because a) we might have crashed, b) the admin might 
>> have accidentally configured it to start at boot or c) the admin may have 
>> asked us to re-check everything.
>> 
>> 
>> Also important to know, the order of actions is:

I should clarify something here:

   s/actions is/actions for each resource is/

>> 
>> 1. any necessary demotions
>> 2. any necessary stops
>> 3. any necessary starts
>> 4. any necessary promotions
>> 
>> 
> 
> Thank you for explaining this, Andrew!
> 
> So, in the context of the given two example DB(MySQL) and
> messaging(RabbitMQ) resources:
> 
> "The problem is that pacemaker can only promote a resource after it
> detects the resource is started. During a full reassemble, in the first
> transition batch, pacemaker starts all the resources including MySQL and
> RabbitMQ. Pacemaker issues resource agent "start" invocation in parallel
> and reaps the results.
> For a multi-state resource agent like RabbitMQ, pacemaker needs the
> start result reported in the first batch, then transition engine and
> policy engine decide if it has to retry starting or promote, and put
> this new transition job into a new batch."
> 
> So, for given example, it looks like we currently have:
> _batch start_
> ...
> 3. DB, messaging resources start in a one batch

Since there is no dependancy between them, yes.

> 4. messaging resource promote blocked by the step 3 completion
> _batch end_

Not quite, I wasn’t as clear as I could have been in my previous email.

We wont promote Rabbit instances until all they have all been started.
However we don’t need to wait for all the DBs to finish starting (again, 
because there is no dependancy between them) before we begin promoting Rabbit.

So a single transition that did this is totally possible:

t0.  Begin transition
t1.  Rabbit start node1(begin)
t2.  DB start node 3   (begin)
t3.  DB start node 2   (begin)
t4.  Rabbit start node2(begin)
t5.  Rabbit start node3(begin)
t6.  DB start node 1   (begin)
t7.  Rabbit start node2(complete)
t8.  Rabbit start node1(complete)
t9.  DB start node 3   (complete)
t10. Rabbit start node3(complete)
t11. Rabbit promote node 1 (begin)
t12. Rabbit promote node 3 (begin)
t13. Rabbit promote node 2 (begin)
... etc etc ...

For something like cinder however, these are some of the dependancies we define:

pcs constraint order start keystone-clone then cinder-api-clone
pcs constraint order start cinder-api-clone then cinder-scheduler-clone
pcs constraint order start galera-master then keystone-clone

So first all the galera instances must be started. Then we can begin to promote 
some.
Once all the promotions complete, then we can start the keystone instances.
Once all the keystone instances are up, then we can bring up the cinder API 
instances, which allows us to start the scheduler, etc etc.

And assuming nothing fails, this can all happen in one transition.

Bottom line: Pacemaker will do as much as it can as soon as it can.  
The only restrictions are ordering constraints you specify, the batch-limit, 
and each master/slave (or clone) resource’s _internal_ 
demote->stop->start->promote ordering.

Am I making it better or worse?

> 
> Does this mean what an artificial constraints ordering between DB and
> messaging could help them to get into the separate transition batches, like:
> 
> ...
> 3. messaging multistate clone resource start
> 4. messaging multistate clone resource promote
> _batch end_
> 
> _next batch start_
> ...
> 3. DB simple clone resource start
> 
> ?
> 
> -- 
> Best regards,
> Bogdan Dobrelya,
> Skype #bog

Re: [openstack-dev] [all] who is the ptl of trove?

[Nikhil Manchanda]

Hi Li:

Thanks for contacting me about Trove. I'm still the PTL for Trove for
the Liberty cycle.

Looking at my inbox. I see that I have an email from you from late May
5th. Because of the volume of emails I get in my inbox, please
understand that it might sometimes take me 2-3 days to respond to all
non-urgent questions about trove. In fact, I'd recommend that you send
any Trove related questions out to the OpenStack development mailing
list (this one). There are more Trove related folks on this list, and
there is a better chance of getting a quicker reply for queries
sent out to the mailing list.

Hope this helps,

Thanks,
Nikhil


On Thu, May 7, 2015 at 7:47 PM, Li Tianqing  wrote:

> Thanks a lot
>
>
> --
> Best
> Li Tianqing
>
> At 2015-05-08 10:33:52, "Steve Martinelli"  wrote:
>
> That information can be found here:
> http://governance.openstack.org/reference/projects/trove.html
> And a full list here:
> http://governance.openstack.org/reference/projects/index.html
>
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
>
>
> From:"Li Tianqing" 
> To:"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> Date:05/07/2015 10:31 PM
> Subject:[openstack-dev] [all] who is the ptl of trove?
> --
>
>
>
> Hello,
>  Who is the ptl of trove?
>
>
>
>
> --
> Best
> Li Tianqing
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

On Thu, May 7, 2015 at 7:47 PM, Li Tianqing  wrote:

> Thanks a lot
>
>
> --
> Best
> Li Tianqing
>
> At 2015-05-08 10:33:52, "Steve Martinelli"  wrote:
>
> That information can be found here:
> http://governance.openstack.org/reference/projects/trove.html
> And a full list here:
> http://governance.openstack.org/reference/projects/index.html
>
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
>
>
> From:"Li Tianqing" 
> To:"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> Date:05/07/2015 10:31 PM
> Subject:[openstack-dev] [all] who is the ptl of trove?
> --
>
>
>
> Hello,
>  Who is the ptl of trove?
>
>
>
>
> --
> Best
> Li Tianqing
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] who is the ptl of trove?

[Li Tianqing]

sorry, I thought he was not.
i can not connect on him though those three emails. PTL can be long time be not 
connected?
Email: slick...@gmail.com 
 nikhil.mancha...@hp.com 
 nik...@manchanda.me





 



--

Best
Li Tianqing

At 2015-05-08 10:34:36, "James Polley"  wrote:

A quick google for "Openstack projects" pointed me at 
https://wiki.openstack.org/wiki/Project_Teams, which has a link to the 
complete, up-to-date list of projects at 
http://governance.openstack.org/reference/projects/index.html, which pointed me 
to http://governance.openstack.org/reference/projects/trove.html, which tells 
me that the PTL is Nikhil Manchanda (SlickNik)


On Fri, May 8, 2015 at 12:26 PM, Li Tianqing  wrote:

Hello,
 Who is the ptl of trove? 





--

Best
Li Tianqing



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



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

Re: [openstack-dev] [cinder] Taskflow 0.10.0 incompatible with NetApp NFS drivers

[Alex Meade]

So it seems that this will break a number of drivers, I see that glusterfs
does the same thing.

On Thu, May 7, 2015 at 10:29 PM, Alex Meade  wrote:

> It appears that the release of taskflow 0.10.0 exposed an issue in the
> NetApp NFS drivers. Something changed that caused the sqlalchemy Volume
> object to be garbage collected even though it is passed into create_volume()
>
> An example error can be found in the c-vol logs here:
>
>
> http://dcf901611175aa43f968-c54047c910227e27e1d6f03bb1796fd7.r95.cf5.rackcdn.com/57/181157/1/check/cinder-cDOT-NFS/0473c54/
>
> One way to get around whatever the issue is would be to change the drivers
> to not update the object directly as it is not needed. But this should not
> fail. Perhaps a more proper fix is for the volume manager to not pass
> around sqlalchemy objects.
>
> Something changed in taskflow, however, and we should just understand if
> that has other impact.
>
> -Alex
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Taskflow 0.10.0 incompatible with NetApp NFS drivers

[Alex Meade]

It appears that the release of taskflow 0.10.0 exposed an issue in the
NetApp NFS drivers. Something changed that caused the sqlalchemy Volume
object to be garbage collected even though it is passed into create_volume()

An example error can be found in the c-vol logs here:

http://dcf901611175aa43f968-c54047c910227e27e1d6f03bb1796fd7.r95.cf5.rackcdn.com/57/181157/1/check/cinder-cDOT-NFS/0473c54/

One way to get around whatever the issue is would be to change the drivers
to not update the object directly as it is not needed. But this should not
fail. Perhaps a more proper fix is for the volume manager to not pass
around sqlalchemy objects.

Something changed in taskflow, however, and we should just understand if
that has other impact.

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

[openstack-dev] [all] who is the ptl of trove?

[Li Tianqing]

Hello,
 Who is the ptl of trove? 





--

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

Re: [openstack-dev] [swift] Go! Swift!

[Huang Zhiteng]

Well put, Clay.  Totally Agree.

On Fri, May 8, 2015 at 10:19 AM, Clay Gerrard  wrote:
>
>
> On Thu, May 7, 2015 at 5:05 PM, Adam Lawson  wrote:
>>
>> what sort of limitations have you discovered that had to do specifically
>> with the fact we're using Python?
>
>
> Python is great.  Conscious decision to optimize for developer wall time
> over cpu cycles has made it a great language for 20 years - and probably
> will for another 20 at *least* (IMHO).
>
> I don't think you would pick out anything to point at as a "limitation" of
> python that you couldn't point at any dynamic interpreted language, but my
> list is something like this:
>
> Dynamic Interpreted Runtime overhead
> Eventlet non-blocking hub is NOT OK for blocking operations (cpu, disk)
> OTOH, dispatch to threads has overhead AND GIL
> non-byte-aligned buffers restricts access to O_DIRECT and asyncio
>
> *So often* this kinda stuff just doesn't matter.  Or even lots of times even
> when it *does* matter - it doesn't matter that much in the grand scheme of
> things.  Or maybe it matters a non-trivial amount, *but* there's still other
> things that just mater more *right now*.  I think Swift has been in that
> last case for a long time, maybe we still are - great thing about
> open-source is redbo can publish an experiment on a feature branch in gerrit
> and in-between the hard work of testing it - we can pontificate about it on
> the mailing list!  ;)
>
> FWIW, I don't think anyone should find it particularly surprising that a
> mature data-path project would naturally gravitate closer to the metal in
> the critical paths - it shouldn't be a big deal - unless it all works out -
> and it's $%^&! tons faster - then BOOYAH! ;)
>
> But I'd suggest you be very careful not to draw any assumptions in general
> about a great language like python even if this one time this one project
> thought maybe they should find out if some part of the distributed system
> might be better by some measure in something not-python.  ;)
>
> Cheers,
>
> -Clay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards
Huang Zhiteng

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

Re: [openstack-dev] [swift] Go! Swift!

[Clay Gerrard]

On Thu, May 7, 2015 at 5:05 PM, Adam Lawson  wrote:

> what sort of limitations have you discovered that had to do specifically
> with the fact we're using Python?
>

Python is great.  Conscious decision to optimize for developer wall time
over cpu cycles has made it a great language for 20 years - and probably
will for another 20 at *least* (IMHO).

I don't think you would pick out anything to point at as a "limitation" of
python that you couldn't point at any dynamic interpreted language, but my
list is something like this:

   - Dynamic Interpreted Runtime overhead
   - Eventlet non-blocking hub is NOT OK for blocking operations (cpu, disk)
   - OTOH, dispatch to threads has overhead AND GIL
   - non-byte-aligned buffers restricts access to O_DIRECT and asyncio

*So often* this kinda stuff just doesn't matter.  Or even lots of times
even when it *does* matter - it doesn't matter that much in the grand
scheme of things.  Or maybe it matters a non-trivial amount, *but* there's
still other things that just mater more *right now*.  I think Swift has
been in that last case for a long time, maybe we still are - great thing
about open-source is redbo can publish an experiment on a feature branch in
gerrit and in-between the hard work of testing it - we can pontificate
about it on the mailing list!  ;)

FWIW, I don't think anyone should find it particularly surprising that a
mature data-path project would naturally gravitate closer to the metal in
the critical paths - it shouldn't be a big deal - unless it all works out -
and it's $%^&! tons faster - then BOOYAH! ;)

But I'd suggest you be very careful not to draw any assumptions in general
about a great language like python even if this one time this one project
thought maybe they should find out if some part of the distributed system
might be better by some measure in something not-python.  ;)

Cheers,

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

Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc.

[Dolph Mathews]

On Thursday, May 7, 2015, Adam Young  wrote:

>  On 05/06/2015 06:54 PM, Hu, David J (Converged Cloud) wrote:
>
> david8hu> One of the first thing we have to do is get all of our glossary
> straight J  I am starting to hear about “capability”.  Are we talking
> about “rule” in oslo policy terms? Or “action” in nova policy terms? Or
> this is something new.  For example, “compute:create_instance” is a “rule”
> in oslo.policy enforce(…) definition,  “compute:create_instance” is an
> “action” in nova.policy enforce(…) definition.
>
>
> By capability, I ( think I ) mean  Action in Nova terms, as I am trying to
> exclude the internal rules that policy lets you define.  However, to
> further muddy the water, you can actually enforce on one of these rules./
> For example, the Keystone server enforces on "admin_required"  for the V2
> API.
>
> The term capability has been thrown around a few times and I picked it
> up.  Really what I want to delineate is the point in the code at which
> policy gets enforced.
>

I completely agree with Adam. Capabilities are the "actions" a user is
allowed to perform. But I'd rather talk in terms of authorized HTTP API
calls.

I've tossed around the idea of something like GET /capabilities where the
response included something analogous to a list of APIs where the user
(i.e. current token / authorization context) match the relevant policy
rules -- but implementing that concept in more than one service would be a
huge challenge.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Upstream QA test plans

[Adam Young]

Yes, we have Tempest and unit tests and Functional tests.  But still we 
need test plans


Keystone often plays a role deep in others work flows. Often we have 
complicated features that span multiple services;  WebSSO, Trusts and 
HEAT,  EC2 Credentials...


Before we can automate the tests, we need to know what to test.  And 
that is a conversation best started by the developers implementing the 
feature, and then handed off to the engineer that needs to make sure the 
feature actually works, positive, negative, and edge.


I'm sure that we have many organizations with internal QA that can 
benefit from test plans that show how to exercise and test these 
features.  As part of getting comfortable working up stream, my team has 
written the start of a few test plans.  I'd like to share them with the 
larger Keystone consuming community;



https://etherpad.openstack.org/p/ldap-backend-non-default-domain
https://etherpad.openstack.org/p/hierarchical-projects
https://etherpad.openstack.org/p/keystone-token-scoping

As you can guess, my goal is not purely altruistic:  I'd like to get 
other people to both input into these test cases and to write some for 
other aspects of Keystone.  Other ones we've identified:


CADF Notifications Everywhere
Allow Redelegation via Trusts
mapping to existing user in federated workflow

I think Etherpad is the right medium for this.  I was originally 
thinking the Spec process, but approving test plans seems to 
centralized:  we want multiple engineers contributing to the test 
plans.  They should be collaborative documents as people add suggestions 
of what to test.


Eventually, these should be automated, but before we can automate, we 
need to identify what to test.  Getting just that down is incredibly 
valuable. We can be more rigorous on the review process when we automate.


I am actively seeking suggestions.  How should we best organize this effort?

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

Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc.

[Adam Young]

On 05/06/2015 06:54 PM, Hu, David J (Converged Cloud) wrote:
david8hu> One of the first thing we have to do is get all of our 
glossary straight J  I am starting to hear about “capability”.  Are we 
talking about “rule” in oslo policy terms? Or “action” in nova policy 
terms? Or this is something new.  For example, 
“compute:create_instance” is a “rule” in oslo.policy enforce(…) 
definition,  “compute:create_instance” is an “action” in nova.policy 
enforce(…) definition.


By capability, I ( think I ) mean  Action in Nova terms, as I am trying 
to exclude the internal rules that policy lets you define. However, to 
further muddy the water, you can actually enforce on one of these 
rules./  For example, the Keystone server enforces on "admin_required"  
for the V2 API.


The term capability has been thrown around a few times and I picked it 
up.  Really what I want to delineate is the point in the code at which  
policy gets enforced.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [swift] Go! Swift!

[Michael Barton]

On Thu, May 7, 2015 at 7:05 PM, Adam Lawson  wrote:

> Chuck (and/or others who understand tor have experienced the limits of
> Python)
>
> I found this comment of yours incredibly intriguing: "we are running out
> of incremental improvements that can be made with Python".
>
> Given your work with Swift thus far, what sort of limitations have you
> discovered that had to do specifically with the fact we're using Python? I
> haven't run into real-life limitations specific to a particular language
> before (I usually run into issues with my approach rather than limitations
> with the language itself) so i find this to be a fascinating (and perhaps
> accidental) consideration.
>


Well, Swift is sort of different from provisioning services like most
Openstack projects.  We handle hundreds of times as many requests as big
Nova installations, and the backend servers like this one handle some
multiplier on top of that.  Our users care a lot about performance because
it affects things like their page load times.

Then Python turns out to be kind of a bad choice for writing a
high-performance file server.  It's slow.  Its concurrency model really
punishes you for having workloads that mix disk and network i/o and CPU.
Swift's mix of worker processes, eventlet, and thread pools mostly works
but it's complicated and inefficient.  Blocking disk operations and
CPU-heavy tasks are still prone to either locking up event loops or
thrashing the GIL.

Python 3 and pypy would both make some aspects of that better, but not fix
it (yet).

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

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

[Mike Bayer]

On 5/7/15 5:32 PM, Thomas Goirand wrote:

If there are really fixes and features we

need in Py2K then of course we have to either convince MySQLdb to merge
them or switch to mysqlclient.


Given the "no reply in 6 months" I think that's enough to say it: 
mysql-python is a dangerous package with a non-responsive upstream. 
That's always bad, and IMO, enough to try to get rid of it. If you 
think switching to PyMYSQL is effortless, and the best way forward, 
then let's do that ASAP!


haha - id rather have drop eventlet + mysqlclient :)

as far as this thread, where this has been heading is that django has 
already been recommending mysqlclient and it's become apparent just what 
a barrage of emails and messages have been sent Andy Dustman's way, with 
no response.I agree this is troubling behavior, and I've alerted 
people at RH internal that we need to start thinking about this package 
switch.My original issue was that for Fedora etc., changing it in 
this way is challenging, and from my discussions with packaging people, 
this is actually correct - this isn't an easy way to do it for them and 
there have been many emails as a result.  My other issue is the 
SQLAlchemy testing issue - I'd essentially have to just stop testing 
mysql-python and switch to mysqlclient entirely, which means i need to 
revise all my docs and get all my users to switch also when the 
SQLAlchemy MySQLdb dialect eventually diverges from mysql-python 1.2.5, 
hence the whole thing is in a not-minor-enough way my problem as 
well.A simple module name change for mysqlclient, then there's no 
problem.   But there you go - assuming continued crickets from AD, and 
seeing that people continue find it important to appease projects like 
Trac that IMO quite amateurishly hardcode "import MySQLdb", I don't see 
much other option.


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

Re: [openstack-dev] [swift] Go! Swift!

[Clay Gerrard]

On Thu, May 7, 2015 at 3:48 PM, Clint Byrum  wrote:

> I'm still very curious to hear if anybody has been willing to try to
> make Swift work on pypy.


yeah, Alex Gaynor was helping out with it for awhile.  It worked.  And it
helped.  A little bit.

Probably still worth looking at if you're curious, but I'm not aware of
anyone who's currently working aggressively to productionize swift running
on pypy.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [chef] Feedback to move IRC Monday meeting and time.

[zhiwei]

Sorry for late response, 1600 GMT is a little late in China, will
check the meeting minutes if not attend.

On Fri, May 8, 2015 at 12:19 AM, JJ Asghar  wrote:
>
> On May 6, 2015, at 11:33 PM, Samuel Cassiba  wrote:
>>
>>
>> This has actually caused a situation that I’d like to make public. In the
>> documentation the times for the meetings are suggested at the top of the
>> hour, we have ours that start at :30 past. This allows for our friends and
>> community members on the west coast of the United States able to join at a
>> pseudo-reasonable time.  The challenge is, if we move it forward to the top
>> of the hour, we may lose the west coast, but if we move it back to the top
>> of the next hour we may lose our friends in Germany and earlier time zones.
>>
> Moving it to the top of the hour would still fall in the realm of
> pseudo-reasonable, as reasonable as meetings in that timeframe can be. 0800
> is more reasonable than 0730. ;-)
>
> By doing that, it would allow the group to remain as inclusive as possible,
> while still allowing time for commutes for us west coasters.
>
>
> Awesome! Yeah so it looks like we’ve gotten some positive feedback about
> moving the meeting to 1600GMT. We’ll discuss it and ideally make it official
> on Monday, and it’s already added to the agenda[1].
>
>
> -JJ
>
> [1]: https://etherpad.openstack.org/p/openstack-chef-meeting-20150511
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering

[Andrew Beekhof]

> On 5 May 2015, at 9:30 pm, Zhou Zheng Sheng / 周征晟  
> wrote:
> 
> Thank you Andrew. Sorry for misspell your name in the previous email.
> 
> on 2015/05/05 14:25, Andrew Beekhof wrote:
>>> On 5 May 2015, at 2:31 pm, Zhou Zheng Sheng / 周征晟  
>>> wrote:
>>> 
>>> Thank you Bogdan for clearing the pacemaker promotion process for me.
>>> 
>>> on 2015/05/05 10:32, Andrew Beekhof wrote:
> On 29 Apr 2015, at 5:38 pm, Zhou Zheng Sheng / 周征晟 
>  wrote:
 [snip]
 
> Batch is a pacemaker concept I found when I was reading its
> documentation and code. There is a "batch-limit: 30" in the output of
> "pcs property list --all". The pacemaker official documentation
> explanation is that it's "The number of jobs that the TE is allowed to
> execute in parallel." From my understanding, pacemaker maintains cluster
> states, and when we start/stop/promote/demote a resource, it triggers a
> state transition. Pacemaker puts as many as possible transition jobs
> into a batch, and process them in parallel.
 Technically it calculates an ordered graph of actions that need to be 
 performed for a set of related resources.
 You can see an example of the kinds of graphs it produces at:
 
  
 http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/s-config-testing-changes.html
 
 There is a more complex one which includes promotion and demotion on the 
 next page.
 
 The number of actions that can run at any one time is therefor limited by
 - the value of batch-limit (the total number of in-flight actions)
 - the number of resources that do not have ordering constraints between 
 them (eg. rsc{1,2,3} in the above example)  
 
 So in the above example, if batch-limit >= 3, the monitor_0 actions will 
 still all execute in parallel.
 If batch-limit == 2, one of them will be deferred until the others 
 complete.
 
 Processing of the graph stops the moment any action returns a value that 
 was not expected.
 If that happens, we wait for currently in-flight actions to complete, 
 re-calculate a new graph based on the new information and start again.
>>> So can I infer the following statement? In a big cluster with many
>>> resources, chances are some resource agent actions return unexpected
>>> values,
>> The size of the cluster shouldn’t increase the chance of this happening 
>> unless you’ve set the timeouts too aggressively.
> 
> If there are many types of resource agents, and anyone of them is not
> well written, it might cause trouble, right?

Yes, but really only for the things that depend on it.

For example if resources B, C, D, E all depend (in some way) on A, then their 
startup is going to be delayed.
But F, G, H and J will be able to start while we wait around for B to time out.

> 
>>> and if any of the in-flight action timeout is long, it would
>>> block pacemaker from re-calculating a new transition graph?
>> Yes, but its actually an argument for making the timeouts longer, not 
>> shorter.
>> Setting the timeouts too aggressively actually increases downtime because of 
>> all the extra delays and recovery it induces.
>> So set them to be long enough that there is unquestionably a problem if you 
>> hit them.
>> 
>> But we absolutely recognise that starting/stopping a database can take a 
>> very long time comparatively and that it shouldn’t block recovery of other 
>> unrelated services.
>> I would expect to see this land in Pacemaker 1.1.14
> 
> It will be great to see this in Pacemaker 1.1.14. From my experience
> using Pacemaker, I think customized resource agents are possibly the
> weakest part.

This is why we encourage people wanting new agents to get involved with the 
upstream resource-agents project :-)

> This feature should improve the handling for resource
> action timeouts.
> 
>>> I see the
>>> current batch-limit is 30 and I tried to increase it to 100, but did not
>>> help.
>> Correct.  It only puts an upper limit on the number of in-flight actions, 
>> actions still need to wait for all their dependants to complete before 
>> executing.
>> 
>>> I'm sure that the cloned MySQL Galera resource is not related to
>>> master-slave RabbitMQ resource. I don't find any dependency, order or
>>> rule connecting them in the cluster deployed by Fuel [1].
>> In general it should not have needed to wait, but if you send me a 
>> crm_report covering the period you’re talking about I’ll be able to comment 
>> specifically about the behaviour you saw.
> 
> You are very nice, thank you. I uploaded the file generated by
> crm_report to google drive.
> 
> https://drive.google.com/file/d/0B_vDkYRYHPSIZ29NdzV3NXotYU0/view?usp=sharing

Hmmm... there’s no logs included here for some reason.
I suspect it a bug on my part, can you apply this patch to report.collector on 
the machine you’re running crm_report from and retry?

   https://github.com/ClusterLabs/pacemaker/commit

Re: [openstack-dev] [nova][oslo] RPC Asynchronous Communication

[Joe Gordon]

On May 7, 2015 2:37 AM, "Sahid Orentino Ferdjaoui" <
sahid.ferdja...@redhat.com> wrote:
>
> Hi,
>
> The primary point of this expected discussion around asynchronous
> communication is to optimize performance by reducing latency.
>
> For instance the design used in Nova and probably other projects let
> able to operate ascynchronous operations from two way.
>
> 1. When communicate between inter-services
> 2. When communicate to the database
>
> 1 and 2 are close since they use the same API but I prefer to keep a
> difference here since the high level layer is not the same.
>
> From Oslo Messaging point of view we currently have two methods to
> invoke an RPC:
>
>   Cast and Call: The first one is not bloking and will invoke a RPC
> without to wait any response while the second will block the
> process and wait for the response.
>
> The aim is to add new method which will return without to block the
> process an object let's call it "Future" which will provide some basic
> methods to wait and get a response at any time.
>
> The benefice from Nova will comes on a higher level:
>
> 1. When communicate between services it will be not necessary to block
>the process and use this free time to execute some other
>computations.

Isn't this what the use of green threads (and eventlet) is supposed to
solve. Assuming my understanding is correct, and we can fix any issues
without adding async oslo.messaging, then adding yet another async pattern
seems like a bad thing.

>
>   future = rpcapi.invoke_long_process()
>  ... do something else here ...
>   result = future.get_response()
>
> 2. We can use the benefice of all of the work previously done with the
>Conductor and so by updating the framework Objects and Indirection
>Api we should take advantage of async operations to the database.
>
>MyObject = MyClassObject.get_async()
>  ... do something else here ...
>MyObject.wait()
>
>MyObject.foo = "bar"
>MyObject.save_async()
>  ... do something else here ...
>MyObject.wait()
>
> All of this is to illustrate and have to be discussed.
>
> I guess the first job needs to come from Oslo Messaging so the
> question is to know the feeling here and then from Nova since it will
> be the primary consumer of this feature.
>
> https://blueprints.launchpad.net/nova/+spec/asynchronous-communication
>
> Thanks,
> s.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate

[Dolph Mathews]

On Monday, May 4, 2015, Flavio Percoco  wrote:

> On 02/05/15 12:02 -0700, Morgan Fainberg wrote:
>
>>
>>
>>  On May 2, 2015, at 10:28, Monty Taylor  wrote:
>>>
>>>  On 05/01/2015 09:16 PM, Jamie Lennox wrote:
 Hi all,

 At around the time Barbican was applying for incubation there was a
 discussion about "supported" WSGI frameworks. From memory the decision
 at the time was that Pecan was to be the only supported framework and
 that for incubation Barbican had to convert to Pecan (from Falcon).

 Keystone is looking to ditch our crusty old, home-grown wsgi layer for
 an external framework and both Pecan and Falcon are in global
 requirements.

 In the experimenting I've done Pecan provides a lot of stuff we don't
 need and some that just gets in the way. To call out a few:
 * the rendering engine really doesn't make sense for us, for APIs, and
 where we are often returning different data (not just different views or
 data) based on Content-Type.
 * The security enforcement within Pecan does not really mesh with how
 we enforce policy, nor does the way we build controller objects per
 resource. It seems we will have to build this for ourselves on top of
 pecan

 and there are just various other niggles.

 THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK.

 Everything I've found can be dealt with and pecan will be a vast
 improvement over what we use now. I have also not written a POC with
 Falcon to know that it will suit any better.

 My question is: Does the ruling that Pecan is the only WSGI framework
 for OpenStack stand? I don't want to have 100s of frameworks in the
 global requirements, but given falcon is already there iff a POC
 determines that Falcon is a better fit for keystone can we use it?

>>>
>>> a) Just to be clear - I don't actually care
>>>
>>
> Just to be super clear, I don't care either. :)
>
>
>>> That said:
>>>
>>> falcon is a wsgi framework written by kgriffs who was PTL of marconi who
>>> has since being involved with OpenStack. My main perception of it has
>>> always been as a set of people annoyed by openstack doing their own
>>> thing. That's fine - but I don't have much of a use for that myself.
>>>
>>
> ok, I'll bite.
>
> We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's
> maintainer. The main reason it was picked was related to performance
> first[0] and time (We didn't/don't have enough resources to even think
> of porting the API) and at this point, I believe it's not even going
> to be considered anymore in the short future.


I'm just going to pipe up and say that's a terribly shallow reason for
choosing a web framework, and I think it's silly and embarrassing that
there's not a stronger community preference for more mature frameworks. I
take that as a sign that most of our developer community is coming from
non-Python backgrounds, which is fine, but this whole conversation has
always felt like a plague of Not-Invented-Here, which baffles me.


>
> There were lots of discussions around this, there were POCs and team
> work. I think it's fair to say that the team didn't blindly *ignored*
> what was recommended as the community framework but it picked what
> worked best for the service.
>
> [0] https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation
>
>
>>> pecan is a wsgi framework written by Dreamhost that eventually moved
>>> itself into stackforge to better enable collaboration with our community
>>> after we settled on it as the API for things moving forward.
>>>
>>> Since the decision that new REST apis should be written in Pecan, the
>>> following projects have adopted it:
>>>
>>> openstack:
>>> barbican
>>> ceilometer
>>> designate
>>> gnocchi
>>> ironic
>>> ironic-python-agent
>>> kite
>>> magnum
>>> storyboard
>>> tuskar
>>>
>>> stackforge:
>>> anchor
>>> blazar
>>> cerberus
>>> cloudkitty
>>> cue
>>> fuel-ostf
>>> fuel-provision
>>> graffiti
>>> libra
>>> magnetodb
>>> monasca-api
>>> mistral
>>> octavia
>>> poppy
>>> radar
>>> refstack
>>> solum
>>> storyboard
>>> surveil
>>> terracotta
>>>
>>> On the other hand, the following use falcon:
>>>
>>> stachtach-quincy
>>> zaqar
>>>
>>>
>> To me this is a strong indicator that pecan will see more eyes and
>> possibly be more open to improvement to meet the general need.
>>
>
> +1
>
>  That means that for all of the moaning and complaining, there is
>>> essentially one thing that uses it - the project that was started by the
>>> person who wrote it and has since quit.
>>>
>>> I'm sure it's not perfect - but the code is in stackforge - I'm sure we
>>> can improve it if there is something missing. OTOH - if we're going to
>>> go back down this road, I'd think it would be more useful to maybe look
>>> at flask or something else that has a large following in the python
>>> community at large to try to reduce the amount of special we are.
>>>
>>>
>> +1

Re: [openstack-dev] [swift] Go! Swift!

[Adam Lawson]

Chuck (and/or others who understand tor have experienced the limits of
Python)

I found this comment of yours incredibly intriguing: "we are running out of
incremental improvements that can be made with Python".

Given your work with Swift thus far, what sort of limitations have you
discovered that had to do specifically with the fact we're using Python? I
haven't run into real-life limitations specific to a particular language
before (I usually run into issues with my approach rather than limitations
with the language itself) so i find this to be a fascinating (and perhaps
accidental) consideration.



*Adam Lawson*

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


On Thu, May 7, 2015 at 3:48 PM, Clint Byrum  wrote:

> Excerpts from Chuck Thier's message of 2015-05-07 13:10:13 -0700:
> > I think most are missing the point a bit.  The question that should
> really
> > be asked is, what is right for Swift to continue to scale.  Since the
> > inception of Openstack, Swift has had to solve for problems of scale that
> > generally are not shared with the rest of Openstack.
> >
> > When we first set out to write Swift, we had set, what we thought at the
> > time were pretty lofty goals for ourselves:
> >
> > * 100 Billion objects
> > * 100 Petabytes of data
> > * 100 K requests/second
> > * 100 Gb/s throughput
> >
> > We started with Python figuring that when we hit major bottlenecks, we
> > would look at other options.  We have been surprised at how far we have
> > been able to push Python and have met most if not all of the goals above.
> >
> > As we look toward the future, we realize that we are now looking for how
> we
> > will support trillions of objects, 100's of petabytes to exabytes of
> data,
> > etc.  We feel that we have finally hit that point that we need more than
> > incremental improvements, and that we are running out of incremental
> > improvements that can be made with Python.
> >
> > What started as a simple experiment by Mike Barton, has turned into
> quite a
> > significant improvement in performance and builds a base that can be
> built
> > off of for future improvements.  This wasn't built because of it being
> > "shiny" but out of direct need, and is currently being tested with great
> > results on production workloads.
> >
> > I applaud the team that has worked on this at Rackspace, and hope the
> > community can look at the current needs of Swift, and the merits of the
> > work that has been accomplished, rather than the politics of "shiny".
> >
>
> Chuck, much respect to you and the team for everything accomplished.
>
> I'm still very curious to hear if anybody has been willing to try to
> make Swift work on pypy. This is pretty much why pypy exists, and making
> pypy work for Swift could mean some really nice residual benefits to the
> other projects that haven't gone as far as to experiment with a compiled
> language like Go yet. There's also the other benefit that pypy would
> gain some eyeballs and improvements that we could feed back into it.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings

[Tony Breeds]

On Thu, May 07, 2015 at 01:31:07PM +0300, Mikhail Dubov wrote:
> We have decided to stay in *#openstack-meeting* but have our meetings *on
> Mondays at 1400 UTC*. Hope that this time there will be no conflicts.
> 
> We will also have the internal release meeting in *#openstack-rally* one
> hour before that, on Mondays at 1300 UTC.

Okay thanks.  iCal updated.

Tony.


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

Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering

[Andrew Beekhof]

> On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / 周征晟  
> wrote:
> 
> Thank you Andrew.
> 
> on 2015/05/05 08:03, Andrew Beekhof wrote:
>>> On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya  wrote:
>>> 
 Hello,
>>> Hello, Zhou
>>> 
 I using Fuel 6.0.1 and find that RabbitMQ recover time is long after
 power failure. I have a running HA environment, then I reset power of
 all the machines at the same time. I observe that after reboot it
 usually takes 10 minutes for RabittMQ cluster to appear running
 master-slave mode in pacemaker. If I power off all the 3 controllers and
 only start 2 of them, the downtime sometimes can be as long as 20 minutes.
>>> Yes, this is a known issue [0]. Note, there were many bugfixes, like
>>> [1],[2],[3], merged for MQ OCF script, so you may want to try to
>>> backport them as well by the following guide [4]
>>> 
>>> [0] https://bugs.launchpad.net/fuel/+bug/1432603
>>> [1] https://review.openstack.org/#/c/175460/
>>> [2] https://review.openstack.org/#/c/175457/
>>> [3] https://review.openstack.org/#/c/175371/
>>> [4] https://review.openstack.org/#/c/170476/
>> Is there a reason you’re using a custom OCF script instead of the 
>> upstream[a] one?
>> Please have a chat with David (the maintainer, in CC) if there is something 
>> you believe is wrong with it.
>> 
>> [a] 
>> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster
> 
> I'm using the OCF script from the Fuel project, specifically from the
> "6.0" stable branch [alpha].

Ah, I’m still learning who is who... i thought you were part of that project 
:-) 

> 
> Comparing with upstream OCF code, the main difference is that Fuel
> RabbitMQ OCF is a master-slave resource. Fuel RabbitMQ OCF does more
> bookkeeping, for example, blocking client access when RabbitMQ cluster
> is not ready. I beleive the upstream OCF should be OK to use as well
> after I read the code, but it might not fit into the Fuel project. As
> far as I test, the Fuel OCF script is good except sometimes the full
> reassemble time is long, and as I find out, it is mostly because the
> Fuel MySQL Galera OCF script keeps pacemaker from promoting RabbitMQ
> resource, as I mentioned in the previous emails.
> 
> Maybe Vladimir and Sergey can give us more insight on why Fuel needs a
> master-slave RabbitMQ.

That would be good to know.
Browsing the agent, promote seems to be a no-op if rabbit is already running.

> I see Vladimir and Sergey works on the original
> Fuel blueprint "RabbitMQ cluster" [beta].
> 
> [alpha]
> https://github.com/stackforge/fuel-library/blob/stable/6.0/deployment/puppet/nova/files/ocf/rabbitmq
> [beta]
> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-cluster-controlled-by-pacemaker
> 
 I have a little investigation and find out there are some possible causes.
 
 1. MySQL Recovery Takes Too Long [1] and Blocking RabbitMQ Clustering in
 Pacemaker
 
 The pacemaker resource p_mysql start timeout is set to 475s. Sometimes
 MySQL-wss fails to start after power failure, and pacemaker would wait
 475s before retry starting it. The problem is that pacemaker divides
 resource state transitions into batches. Since RabbitMQ is master-slave
 resource, I assume that starting all the slaves and promoting master are
 put into two different batches. If unfortunately starting all RabbitMQ
 slaves are put in the same batch as MySQL starting, even if RabbitMQ
 slaves and all other resources are ready, pacemaker will not continue
 but just wait for MySQL timeout.
>>> Could you please elaborate the what is the same/different batches for MQ
>>> and DB? Note, there is a MQ clustering logic flow charts available here
>>> [5] and we're planning to release a dedicated technical bulletin for this.
>>> 
>>> [5] http://goo.gl/PPNrw7
>>> 
 I can re-produce this by hard powering off all the controllers and start
 them again. It's more likely to trigger MySQL failure in this way. Then
 I observe that if there is one cloned mysql instance not starting, the
 whole pacemaker cluster gets stuck and does not emit any log. On the
 host of the failed instance, I can see a mysql resource agent process
 calling the sleep command. If I kill that process, the pacemaker comes
 back alive and RabbitMQ master gets promoted. In fact this long timeout
 is blocking every resource from state transition in pacemaker.
 
 This maybe a known problem of pacemaker and there are some discussions
 in Linux-HA mailing list [2]. It might not be fixed in the near future.
 It seems in generally it's bad to have long timeout in state transition
 actions (start/stop/promote/demote). There maybe another way to
 implement MySQL-wss resource agent to use a short start timeout and
 monitor the wss cluster state using monitor action.
>>> This is very interesting, thank you! I believe all commands for MySQL RA
>>> OCF script should be

[openstack-dev] [nova] libvirt.remove_unused_kernels config option - default to true now?

[Matt Riedemann]

I came across this today:

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagecache.py#L50

That was added back in grizzly:

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

With a note in the code that we should default it to true at some point. 
 Is 2+ years long enough for this to change to true?


This change predates my involvement in the project so ML it is.

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Joe Gordon]

As a heads up, here is a patch to remove Sahara from the default
configuration as well. This is part of the effort to further decouple the
'integrated gate' so we don't have to gate every project on the tests for
every project.

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

On Thu, May 7, 2015 at 11:58 AM, Boris Pavlovic  wrote:

> So... test jobs should be extremely explicit about what they setup and
>> what they expect.
>
>
> +2
>
> Best regards,
> Boris Pavlovic
>
> On Thu, May 7, 2015 at 9:44 PM, Sean Dague  wrote:
>
>> On 05/07/2015 02:29 PM, Joshua Harlow wrote:
>> > Boris Pavlovic wrote:
>> >> Sean,
>> >>
>> >> Nobody is able to track and know *everything*.
>> >>
>> >> Friendly reminder that Heat is going to be removed and not installed by
>> >> default would help to avoid such situations.
>> >
>> > Doesn't keystone have a service listing? Use that in rally (and
>> > elsewhere?), if keystone had a service and each service had a API
>> > discovery ability, there u go, profit! ;)
>>
>> Service listing for test jobs is actually quite dangerous, because then
>> something can change something about which services are registered, and
>> you automatically start skipping 30% of your tests because you react
>> correctly to this change. However, that means the job stopped doing what
>> you think it should do.
>>
>> *This has happened multiple times in the past*. And typically days,
>> weeks, or months go by before someone notices in investigating an
>> unrelated failure. And then it's days, weeks, or months to dig out of
>> the regressions introduced.
>>
>> So... test jobs should be extremely explicit about what they setup and
>> what they expect.
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] Cross-project coordination

[Brent Eagles]

Hi,

On Thu, May 07, 2015 at 10:03:30PM +, Sean M. Collins wrote:
> On Wed, Apr 22, 2015 at 06:41:58PM EDT, Jay Pipes wrote:
> > Agreed. I'm hoping that someone in the Nova community -- note, this does 
> > not need to be a Nova core contributor -- can step up to the plate and 
> > serve in this critical role.
> 
> Hi,
> 
> I've put together a section on the wiki,
> 
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
> 
> We still need a Nova liaison to sign up, to help me with the Nova/Neutron
> cross project effort. If you are interested, please reply and replace
> the "Volunteer Needed" sections in the table!

I volunteer! I've modified the wiki accordingly.

Cheers,

Brent


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

Re: [openstack-dev] [ceilometer] removing Angus Salkeld and Nick Barcet from ceilometer-core‏

[Angus Salkeld]

On Fri, May 8, 2015 at 3:56 AM, gordon chung  wrote:

> hi folks,
>
> as both have moved on to other endeavours, today we will be removing two
> founding contributors of Ceilometer from the core team. thanks to both of
> you for guiding the project in it's early days!
>

+1 from me, it's somewhat overdue, I appreciate having been core - thank
you all..

-Angus


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

Re: [openstack-dev] Heat-engine fails to start

[Angus Salkeld]

On Thu, May 7, 2015 at 5:47 PM, Murali B  wrote:

> Hi
>
> I installed heat on juno version.
>
> When I start heat-engine it fails and I am seeing the below error
>
> cal/lib/python2.7/dist-packages/stevedore/extension.py:156
> 2015-05-07 13:06:36.076 10670 DEBUG stevedore.extension [-] found
> extension EntryPoint.parse('routing =
> oslo.messaging.notify._impl_routing:RoutingDriver') _load_plugins
> /usr/local/lib/python2.7/dist-packages/stevedore/extension.py:156
> 2015-05-07 13:06:36.077 10670 DEBUG stevedore.extension [-] found
> extension EntryPoint.parse('test =
> oslo.messaging.notify._impl_test:TestDriver') _load_plugins
> /usr/local/lib/python2.7/dist-packages/stevedore/extension.py:156
> 2015-05-07 13:06:36.077 10670 DEBUG stevedore.extension [-] found
> extension EntryPoint.parse('messaging =
> oslo.messaging.notify._impl_messaging:MessagingDriver') _load_plugins
> /usr/local/lib/python2.7/dist-packages/stevedore/extension.py:156
> 2015-05-07 13:06:36.077 10670 DEBUG stevedore.extension [-] found
> extension EntryPoint.parse('AWSTemplateFormatVersion.2010-09-09 =
> heat.engine.cfn.template:CfnTemplate') _load_plugins
> /usr/local/lib/python2.7/dist-packages/stevedore/extension.py:156
> 2015-05-07 13:06:36.084 10670 CRITICAL heat.engine [-] Could not load
> AWSTemplateFormatVersion.2010-09-09: (sqlalchemy-migrate 0.9.6
> (/usr/local/lib/python2.7/dist-packages),
> Requirement.parse('sqlalchemy-migrate==0.9.1'))
>
>
Hi

Heat templates are stevedore plugins. you have
"AWSTemplateFormatVersion.2010-09-09" that was installed (with pip install)
that needs 'sqlalchemy-migrate==0.9.1', but your system has
'sqlalchemy-migrate 0.9.6' (so it refuses to run)

I'd suggest reinstalling heat either with a proper package manager or "pip
install".

-Angus



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

Re: [openstack-dev] [swift] Go! Swift!

[Clint Byrum]

Excerpts from Chuck Thier's message of 2015-05-07 13:10:13 -0700:
> I think most are missing the point a bit.  The question that should really
> be asked is, what is right for Swift to continue to scale.  Since the
> inception of Openstack, Swift has had to solve for problems of scale that
> generally are not shared with the rest of Openstack.
> 
> When we first set out to write Swift, we had set, what we thought at the
> time were pretty lofty goals for ourselves:
> 
> * 100 Billion objects
> * 100 Petabytes of data
> * 100 K requests/second
> * 100 Gb/s throughput
> 
> We started with Python figuring that when we hit major bottlenecks, we
> would look at other options.  We have been surprised at how far we have
> been able to push Python and have met most if not all of the goals above.
> 
> As we look toward the future, we realize that we are now looking for how we
> will support trillions of objects, 100's of petabytes to exabytes of data,
> etc.  We feel that we have finally hit that point that we need more than
> incremental improvements, and that we are running out of incremental
> improvements that can be made with Python.
> 
> What started as a simple experiment by Mike Barton, has turned into quite a
> significant improvement in performance and builds a base that can be built
> off of for future improvements.  This wasn't built because of it being
> "shiny" but out of direct need, and is currently being tested with great
> results on production workloads.
> 
> I applaud the team that has worked on this at Rackspace, and hope the
> community can look at the current needs of Swift, and the merits of the
> work that has been accomplished, rather than the politics of "shiny".
> 

Chuck, much respect to you and the team for everything accomplished.

I'm still very curious to hear if anybody has been willing to try to
make Swift work on pypy. This is pretty much why pypy exists, and making
pypy work for Swift could mean some really nice residual benefits to the
other projects that haven't gone as far as to experiment with a compiled
language like Go yet. There's also the other benefit that pypy would
gain some eyeballs and improvements that we could feed back into it.

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

[openstack-dev] [release] taskflow release 0.10.0 (liberty)

[Joshua Harlow]

We are jubilant to announce the release of:

taskflow 0.10.0: Taskflow structured state management library.

With source available at:

http://git.openstack.org/cgit/openstack/taskflow

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/0.10.0

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

Changes in taskflow 0.9.0..0.10.0
-

51a82bb Remove validation of state on state read property access
32ccdf1 Make the default path a constant and tweak class docstring
5efcbf0 Add speed-test tools script
a0cc12d Speed up memory backend via a path -> node reverse mapping
a37a881 Updated from global requirements
21f4985 Fix a typo in taskflow docs
b8f1447 Fix post coverage job option not recognized
46d30ee Move implementations into there own sub-sections
f5a276d Remove run_cross_tests.sh
3097e52 Move zookeeper jobboard constants to class level
1764e3e Retain chain of missing dependencies
da61f15 Expose fake filesystem 'join' and 'normpath'
c1127ef Add + use diagram explaining retry controller area of influence
5186341 Add openclipart.org conductor image to conductor docs
d80ee56 Use oslo_utils eventletutils to warn about eventlet patching
43194f5 Test more engine types in argument passing unit test
3bbbcc6 Add a conductor running example
4616670 Replace more instance(s) of exception chaining with helper
4b0091a Avoid attribute error by checking executor for being non-none
227cf52 Make the storage layer more resilent to failures

Diffstat (except docs and test files)
-

taskflow/engines/__init__.py |  10 +-
taskflow/engines/action_engine/engine.py |  30 ++-
taskflow/examples/tox_conductor.py   | 243 
+++

taskflow/jobs/backends/__init__.py   |  12 +-
taskflow/jobs/backends/impl_zookeeper.py | 122 +++-
taskflow/persistence/backends/__init__.py|  10 +-
taskflow/persistence/backends/impl_memory.py | 106 ++
taskflow/persistence/backends/impl_sqlalchemy.py |   2 -
taskflow/storage.py  | 227 +++--
test-requirements.txt|   2 +-
tools/speed_test.py  |  61 ++
tox.ini  |   2 +-
27 files changed, 767 insertions(+), 331 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 939b2ff..a6a7a19 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ testscenarios>=0.4
-kombu>=2.5.0
+kombu>=3.0.7



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

Re: [openstack-dev] [nova] Port Nova to Python 3

[Thomas Goirand]

On 04/24/2015 10:20 PM, Kevin L. Mitchell wrote:

On Fri, 2015-04-24 at 16:07 -0400, Sean Toner wrote:

What I meant by the worst of both worlds is that you don't get the nice
new features of python3, while simultaneously dealing with the headaches
of making code run under both python versions.  You'll have to do weird
things with imports (for example urllib) and deal with the
inconsistencies between some functions that return strings and some that
return unicode, and some that return bytes.

It's not impossible, but you have to add that extra work while also
depriving yourself of the goodness of python3 only features :)


This is why the 'six' library is such a godsend; this stuff is still not
easy, but the hardest parts, like the imports problem, are already taken
care of by six…and maintaining the bytes/strings/unicode distinction is
actually just as useful in Python 2, it just doesn't have the machinery
to really detect the mixing :)


Oh, this makes me think: how would one fix something like this?

def unicode_convert(self, item):
try:
>   return unicode(item, "utf-8")
E   NameError: name 'unicode' is not defined

and something like this?

def make(self, idp, sp, args):
md5 = hashlib.md5()
for arg in args:
md5.update(arg.encode("utf-8"))
>   md5.update(sp)
E   TypeError: Unicode-objects must be encoded before hashing

and one last one:

def harvest_element_tree(self, tree):
# Fill in the instance members from the contents of the
# XML tree.
for child in tree:
self._convert_element_tree_to_member(child)
>   for attribute, value in tree.attrib.iteritems():
self._convert_element_attribute_to_member(attribute, value)
E   AttributeError: 'dict' object has no attribute 'iteritems'

I once found a document on the net about how to fix the iteritems 
thingy, but I can't find it again... :(


BTW, I did this:
-from Cookie import SimpleCookie
+try:
+from Cookie import SimpleCookie
+except:
+from http.cookies import SimpleCookie

Is there anything smarter to do with six? What's the rule with 
six.moves? Should I always just use the new location?


Also, is this a correct fix for the basestring issue in Py3?

+try:
+basestring
+except NameError:
+basestring = (str,bytes)

(FYI: I am trying to port pysaml2 to Python 3, and I already have a 
nearly 5k lines patch...)


Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [Nova][Neutron] Cross-project coordination

[Sean M. Collins]

On Wed, Apr 22, 2015 at 06:41:58PM EDT, Jay Pipes wrote:
> Agreed. I'm hoping that someone in the Nova community -- note, this does 
> not need to be a Nova core contributor -- can step up to the plate and 
> serve in this critical role.

Hi,

I've put together a section on the wiki,

https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons

We still need a Nova liaison to sign up, to help me with the Nova/Neutron
cross project effort. If you are interested, please reply and replace
the "Volunteer Needed" sections in the table!

-- 
Sean M. Collins

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

[openstack-dev] [nova] Service group foundations and features

[Joshua Harlow]

Hi all,

In seeing the following:

- https://review.openstack.org/#/c/169836/
- https://review.openstack.org/#/c/163274/
- https://review.openstack.org/#/c/138607/

Vilobh and I are starting to come to the conclusion that the service 
group layers in nova really need to be cleaned up (without adding more 
features that only work in one driver), or removed or other... Spec[0] 
has interesting findings on this:


A summary/highlights:

* The zookeeper service driver in nova has probably been broken for 1 or 
more releases, due to eventlet attributes that are gone that it via 
evzookeeper[1] library was using. Evzookeeper only works for eventlet < 
0.17.1. Please refer to [0] for details.
* The memcache service driver really only uses memcache for a tiny piece 
of the service liveness information (and does a database service table 
scan to get the list of services). Please refer to [0] for details.
* Nova-manage service disable (CLI admin api) does interact with the 
service group layer for the 'is_up'[3] API (but it also does a database 
service table scan[4] to get the list of services, so this is 
inconsistent with the service group driver API 'get_all'[2] view on what 
is enabled/disabled). Please refer to [9][10] for nova manage service 
enable disable for details.
  * Nova service delete (REST api) seems to follow a similar broken 
pattern (it also avoids calling into the service group layer to delete a 
service, which means it only works with the database layer[5], and 
therefore is inconsistent with the service group 'get_all'[2] API).


^^ Doing the above makes both disable/delete agnostic about other 
backends available that may/might manage service group data for example 
zookeeper, memcache, redis etc... Please refer [6][7] for details. 
Ideally the API should follow the model used in [8] so that the 
extension, admin interface as well as the API interface use the same 
servicegroup interface which should be *fully* responsible for managing 
services. Doing so we will have a consistent view of services data, 
liveness, disabled/enabled and so-on...


So with no disrespect to the authors of 169836 and 163274 (or anyone 
else involved), I am wondering if we can put a request in to figure out 
how to get the foundation of the service group concepts stabilized (or 
other...) before adding more features (that only work with the DB layer).


What is the path to request some kind of larger coordination effort by 
the nova folks to fix the service group layers (and the concepts that 
are not disjoint/don't work across them) before continuing to add 
features on-top of a 'shakey' foundation?


If I could propose something it would probably work out like the following:

Step 0: Figure out if the service group API + layer(s) should be 
maintained/tweaked at all (nova-core decides?)


If maintain it:

 - Have an agreement that nova service extension, admin 
interface(nova-manage) and API go through a common path for 
update/delete/read.
  * This common path should likely be the servicegroup API so as to 
have a consistent view of data and that also helps nova to add different 
data-stores (keeping the services data in a DB and getting numerous 
updates about liveliness every few seconds of N number of compute where 
N is pretty high can be detrimental to Nova's performance)
 - At the same time allow 163274 to be worked on (since it fixes a 
edge-case that was asked about in the initial addition of the delete API 
in its initial code commit @ https://review.openstack.org/#/c/39998/)
 - Delay 169836 until the above two/three are fixed (and stabilized); 
it's down concept (and all other usages of services that are hitting a 
database mentioned above) will need to go through the same service group 
foundation that is currently being skipped.


Else:
  - Discard 138607 and start removing the service group code (and just 
use the DB for all the things).
  - Allow 163274 and 138607 (since those would be additions on-top of 
the DB layer that will be preserved).


Thoughts?

- Josh (and Vilobh, who is spending the most time on this recently)

[0] Replace service group with tooz : 
https://review.openstack.org/#/c/138607/

[1] https://pypi.python.org/pypi/evzookeeper/
[2] 
https://github.com/openstack/nova/blob/stable/kilo/nova/servicegroup/api.py#L93
[3] 
https://github.com/openstack/nova/blob/stable/kilo/nova/servicegroup/api.py#L87

[4] https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L711
[5] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/services.py#L106
[6] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/services.py#L107

[7] https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3436
[8] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/services.py#L61
[9] Nova manage enable : 
https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L742
[10] Nova manage disable : 
https://g

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

[Giulio Fidente]

On 05/07/2015 07:35 PM, Dan Prince wrote:

On Thu, 2015-05-07 at 17:36 +0200, Giulio Fidente wrote:

On 05/07/2015 03:31 PM, Dan Prince wrote:

On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:


[...]


on the other hand, we can very well get rid of the ifs today by
deploying *with* pacemaker in single node scenario as well! we already
have EnablePacemaker always set to true for dev purposes, even on single
node


EnablePacemaker is set to 'false' by default. IMO it should be opt-in:

http://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=1f7426a014f0f83ace4d2b3531014e22f7778b4d


sure that param is false by default, but one can enable it and deploy 
with pacemaker on single node, and in fact many people do this for dev 
purposes


before that change, we were even running CI on single node with 
pacemaker so as a matter of fact, one could get rid of the conditionals 
in the manifest today by just assuming there will be pacemaker


this said, I prefer myself to leave some "air" for a (future?) 
non-pacemaker scenario, but I still wanted to point out the reason why 
the conditionals are there in the first place

--
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

[Jay Reslock]

Thanks very much to both of you for your help!

I was able to get to another error now about EndpointNotFound.  I will
troubleshoot more and review the bugs mentioned by Sergey.

-Jason

On Thu, May 7, 2015 at 5:34 PM Sergey Kraynev  wrote:

> Hi Jay.
>
> AFAIK, it works, but we can have some minor issues. There several atches
> on review to improve it:
>
>
> https://review.openstack.org/#/q/status:open+project:openstack/python-heatclient+branch:master+topic:improve-sessionclient,n,z
>
> Also as I remember we really had bug mentioned by you, but fix was merged.
> Please look:
> https://review.openstack.org/#/c/160431/1
> https://bugs.launchpad.net/python-heatclient/+bug/1427310
>
> Which version of client do you use? Try to use code from master, it should
> works.
> Also one note: the best place for such questions is
> openst...@lists.openstack.org or http://ask.openstack.org/. And of course
> channel #heat in IRC.
>
> Regards,
> Sergey.
>
> On 7 May 2015 at 23:43, Jay Reslock  wrote:
>
>> Hi,
>> This is my first mail to the group.  I hope I set the subject correctly
>> and that this hasn't been asked already.  I searched archives and did not
>> see this question asked or answered previously.
>>
>> I am working on a client thing that uses the python-keystoneclient and
>> python-heatclient api bindings to set up an authenticated session and then
>> use that session to talk to the heat service.  This doesn't work for heat
>> but does work for other services such as nova and sahara.  Is this because
>> sessions aren't supported in the heatclient api yet?
>>
>> sample code:
>>
>> https://gist.github.com/jreslock/a525abdcce53ca0492a7
>>
>> I'm using fabric to define tasks so I can call them via another tool.
>> When I run the task I get:
>>
>> TypeError: Client() takes at least 1 argument (0 given)
>>
>> The documentation does not say anything about being able to pass session
>> to the heatclient but the others seem to work.  I just want to know if this
>> is intended/expected behavior or not.
>>
>> -Jason
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Add config option for real deletes instead of soft-deletes

[Jay Pipes]

Not sure about a configuration option, but here's yet another 
spec/blueprint that you might be interested in reading:


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

Best,
-jay

On 04/21/2015 05:42 PM, Artom Lifshitz wrote:

Hello,

I'd like to gauge acceptance of introducing a feature that would give operators
a config option to perform real database deletes instead of soft deletes.

There's definitely a need for *something* that cleans up the database. There
have been a few attempts at a DB purge engine [1][2][3][4][5], and archiving to
shadow tables has been merged [6] (though that currently has some issues [7]).

DB archiving notwithstanding, the general response to operators when they
mention the database becoming too big seems to be "DIY cleanup."

I would like to propose a different approach: add a config option that turns
soft-deletes into real deletes, and start telling operators "if you turn this
on, it's DIY backups."

Would something like that be acceptable and feasible? I'm ready to put in the
work to implement this, however searching the mailing list indicates that it
would be somewhere between non trivial and impossible [8]. Before I start, I
would like some confidence that it's closer to the former than the latter :)

Cheers!

[1] https://blueprints.launchpad.net/nova/+spec/db-purge-engine
[2] https://blueprints.launchpad.net/nova/+spec/db-purge2
[3] https://blueprints.launchpad.net/nova/+spec/remove-db-archiving
[4] https://blueprints.launchpad.net/nova/+spec/database-purge
[5] https://blueprints.launchpad.net/nova/+spec/db-archiving
[6] https://review.openstack.org/#/c/18493/
[7] https://review.openstack.org/#/c/109201/
[8] 
http://lists.openstack.org/pipermail/openstack-operators/2014-November/005591.html

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



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

Re: [openstack-dev] OpenStack Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

On Thu, May 7, 2015 at 4:26 PM Martinx - ジェームズ 
wrote:

> Guys,
>
>  I just upgraded my Trusty servers, that I'm running OpenStack Juno, to
> Linux 3.19, which is already available at Proposed repository.
>
>  OpenStack is dead here, no connectivity for the tenants.
>
>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452868
>
>  I appreciate any help!
>
>  It works okay with Linux 3.19.
>
> Best,
> Thiago
>

First things first.

I'm so sorry about this crossposting, I'll not do it again. I'm tired and
I'm not feeling well today, huge headache... I'll only crosspost again, my
apologies now.

Secondly, only after a complete power cycle, Juno with Trusty + Linux 3.19
is working. Tenants have connectivity again.

 So far, the only error that I'm still seeing, is the following:

---
==> /var/log/neutron/ovs-cleanup.log <==
2015-05-07 13:30:57.384 881 TRACE neutron Command: ['sudo',
'/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'link',
'delete', 'tap3da8f4fe-55']
2015-05-07 13:30:57.384 881 TRACE neutron Exit code: 2
2015-05-07 13:30:57.384 881 TRACE neutron Stdout: ''
2015-05-07 13:30:57.384 881 TRACE neutron Stderr: 'RTNETLINK answers:
Operation not supported\n'
---

 I'll clean up everything, bridges and Namespaces, to see if the problem
persists. I saw this problem in a lab as well, I'll reset the databases and
tenants to start over again, with Linux 3.19 from the beginning.

 Again, forgive-me about the crossposting and about the buzz.

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

Re: [openstack-dev] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

[Sergey Kraynev]

Hi Jay.

AFAIK, it works, but we can have some minor issues. There several atches on
review to improve it:

https://review.openstack.org/#/q/status:open+project:openstack/python-heatclient+branch:master+topic:improve-sessionclient,n,z

Also as I remember we really had bug mentioned by you, but fix was merged.
Please look:
https://review.openstack.org/#/c/160431/1
https://bugs.launchpad.net/python-heatclient/+bug/1427310

Which version of client do you use? Try to use code from master, it should
works.
Also one note: the best place for such questions is
openst...@lists.openstack.org or http://ask.openstack.org/. And of course
channel #heat in IRC.

Regards,
Sergey.

On 7 May 2015 at 23:43, Jay Reslock  wrote:

> Hi,
> This is my first mail to the group.  I hope I set the subject correctly
> and that this hasn't been asked already.  I searched archives and did not
> see this question asked or answered previously.
>
> I am working on a client thing that uses the python-keystoneclient and
> python-heatclient api bindings to set up an authenticated session and then
> use that session to talk to the heat service.  This doesn't work for heat
> but does work for other services such as nova and sahara.  Is this because
> sessions aren't supported in the heatclient api yet?
>
> sample code:
>
> https://gist.github.com/jreslock/a525abdcce53ca0492a7
>
> I'm using fabric to define tasks so I can call them via another tool.
> When I run the task I get:
>
> TypeError: Client() takes at least 1 argument (0 given)
>
> The documentation does not say anything about being able to pass session
> to the heatclient but the others seem to work.  I just want to know if this
> is intended/expected behavior or not.
>
> -Jason
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

[Thomas Goirand]

On 05/05/2015 08:41 PM, Mike Bayer wrote:



On 5/4/15 6:48 PM, Thomas Goirand wrote:

I don't see what it would break. If I do:

Package: python-mysqlclient
Breaks: python-mysqldb
Replaces: python-mysqldb
Provides: python-mysqldb

everything is fine, and python-mysqlclient becomes another
implementation of the same thing. Then I believe it'd be a good idea
to simply remove python-mysqldb from Debian, since it's not maintained
upstream anymore.


It is also imprudent to switch
production openstack applications to a driver that is new and untested
(even though it is a port), nor is it necessary.


Supporting Python 3 is necessary, as we are going to remove Python 2
from Debian from Buster.

I don't know debian but the approach would be that something like the
"mysqlclient-py3k" package applies to Python 3 only.






There should be no
reason Openstack applications are hardcoded to one database driver.


If they share the same "import mysqldb", and if they are API
compatible, how is this a problem?

how do you know they are API compatible?


According to Victor, that's what the author of the fork says. That's 
also what he wants, as per the issue 44 which you raised (the 
mysqlclient upstream wants it to be a drop-in replacement for mysqldb, 
to help distributions to better switch to Python 3).



This is in fact exactly where
this approach can become a huge problem.   No MySQL drivers I've ever
used are fully API compatible with any of the other ones. *all* of them
have subtle and not-so-subtle differences in behavior.  That mysqlclient
is now a fork means it will begin to diverge, and as issues come up to
which their resolution requires even more subtle or not-so-subtle
changes in behavior, these differences will only continue to grow.


I agree. Which is exactly why we don't want one package for Py2, and the 
other one for Py3.



From a SQLAlchemy perspective this would be much easier to maintain as
a new sub-dialect.


Best for SQLA and everyone else would be a re-merge as a single project. 
Either that, or just mysqlclient takes over completely mysql-python in 
PyPi, just like you suggested in the github issue 44. I'd love to see 
one or the other happen. The later could be decided by a PyPi 
administrator, given the fact that the mysql-python maintainer is 
unresponsive. Have you tried to approach someone with such rights at PyPi?


Though if it doesn't happen, as you wrote it's going to be hell for you 
to test against both implementation. Maybe then the only choice you have 
is to decide to use only one of them (and mysqlclient seems the best of 
both).


I by the way found methane very reasonable in his replies


The
approach should be simply that in Python 3, the mysqlclient library is
installed instead of mysql-python.


So, in Python 3, we'd have some bugfixes, and not in Python 2? This
seems a very weird approach to me, which *will* lead to lots of issues.

I've asked three times now to please show the bugfixes that are
needed.


Yourself, you wrote that there was some bugfixes and subtle differences, 
didn't you?



Show me the issues that aren't being fixed, and then I will
be convinced and begin the process of pushing here at Red Hat to make
the same packaging changes such that our customers will no longer be
able to use the original MySQLdb. We're talking about an instant,
systemwide replacement of one MySQLdb implementation for another and I
just think that is high risk.


IMO, since that's a fork, the risk isn't greater than just upgrading 
from one version to next for any given package.



Switching to mysqlclient is basically almost "free" (by that, I mean
effortless), if I understand what Victor wrote. The same thing can't
be said of removing Eventlet or switching to pymysql, even though if
both may be needed. So why add the later as a blocker for the former?

Well, switching to pymysql *is* just as effortless IMHO, and in fact
*more* effortless because it can be done impacting only individual
applications at a time, rather than forcing it on everything at once.
SQLAlchemy has a dialect for PyMySQL already which is well maintained
and well tested.  We change the database URL in projects to include
"mysql+pymysql", update requirements.txt, distros add their packages
like they have to anyway, and we're done.


Really? If it's that simple, then please start doing this, and let's 
happily switch to PyMYSQL for Liberty.



But again, I really want to see what the critical issues in MySQLdb are
that are holding us back.


The main motivation is the lack of support for Python 3.


If there are really fixes and features we
need in Py2K then of course we have to either convince MySQLdb to merge
them or switch to mysqlclient.


Given the "no reply in 6 months" I think that's enough to say it: 
mysql-python is a dangerous package with a non-responsive upstream. 
That's always bad, and IMO, enough to try to get rid of it. If you think 
switching to PyMYSQL is effortless, and the best way forwa

Re: [openstack-dev] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

[Ian Cordasco]

On 5/7/15, 14:43, "Jay Reslock"  wrote:

>Hi,
>This is my first mail to the group.  I hope I set the subject correctly
>and that this hasn't been asked already.  I searched archives and did not
>see this question asked or answered previously.
>
>
>I am working on a client thing that uses the python-keystoneclient and
>python-heatclient api bindings to set up an authenticated session and
>then use that session to talk to the heat service.  This doesn't work for
>heat but does work for other services
> such as nova and sahara.  Is this because sessions aren't supported in
>the heatclient api yet?
>
>
>sample code:
>
>
>https://gist.github.com/jreslock/a525abdcce53ca0492a7
>
>
>
>I'm using fabric to define tasks so I can call them via another tool.
>When I run the task I get:
>
>
>TypeError: Client() takes at least 1 argument (0 given)
>
>
>
>The documentation does not say anything about being able to pass session
>to the heatclient but the others seem to work.  I just want to know if
>this is intended/expected behavior or not.
>
>
>-Jason
>


Hey Jason,

Welcome to the list. There's a critical difference in the different
Client's that you import. In the rest of the examples you import from
foo.v2.client. In this case, you're importing heatclient.client. Since
heat's API is versioned, heatclient.client.Client is expecting a string
like 'v1' to be passed like

Client(version='v1', session=sess)

Alternatively, you can just do

from heatclient.v1 import client as heat_v1
heat = heat_v1.Client(session=sess)

Note, there is no v2 in heatclient.

Cheers,
Ian

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

Re: [openstack-dev] [Cinder] Static Ceph mon connection info prevents VM restart

[Josh Durgin]

Hey folks, thanks for filing a bug for this:

https://bugs.launchpad.net/cinder/+bug/1452641

Nova stores the volume connection info in its db, so updating that
would be a workaround to allow restart/migration of vms to work.
Otherwise running vms shouldn't be affected, since they'll notice any
new or deleted monitors through their existing connection to the
monitor cluster.

Perhaps the most general way to fix this would be for cinder to return
any monitor hosts listed in ceph.conf (as they are listed, so they may
be hostnames or ips) in addition to the ips from the current monmap
(the current behavior).

That way an out of date ceph.conf is less likely to cause problems,
and multiple clusters could still be used with the same nova node.

Josh

On 05/06/2015 12:46 PM, David Medberry wrote:

Hi Arne,

We've had this EXACT same issue.

I don't know of a way to force an update as you are basically pulling
the rug out from under a running instance. I don't know if it is
possible/feasible to update the virsh xml in place and then migrate to
get it to actually use that data. (I think we tried that to no avail.)
dumpxml=>massage cephmons=>import xml

If you find a way, let me know, and that's part of the reason I'm
replying so that I stay on this thread. NOTE: We did this on icehouse.
Haven't tried since upgrading to Juno but I don't note any change
therein that would mitigate this. So I'm guessing Liberty/post-Liberty
for a real fix.



On Wed, May 6, 2015 at 12:57 PM, Arne Wiebalck mailto:arne.wieba...@cern.ch>> wrote:

Hi,

As we swapped a fraction of our Ceph mon servers between the
pre-production and production cluster
— something we considered to be transparent as the Ceph config
points to the mon alias—, we ended
up in a situation where VMs with volumes attached were not able to
boot (with a probability that matched
the fraction of the servers moved between the Ceph instances).

We found that the reason for this is the connection_info in
block_device_mapping which contains the
IP adresses of the mon servers as extracted by the rbd driver in
initialize_connection() at the moment
when the connection is established. From what we see, however, this
information is not updated as long
as the connection exists, and will hence be re-applied without
checking even when the XML is recreated.

The idea to extract the mon servers by IP from the mon map was
probably to get all mon servers (rather
than only one from a load-balancer or an alias), but while our
current scenario may be special, we will face
a similar problem the day the Ceph mons need to be replaced. And
that makes it a more general issue.

For our current problem:
Is there a user-transparent way to force an update of that
connection information? (Apart from fiddling
with the database entries, of course.)

For the general issue:
Would it be possible to simply use the information from the
ceph.conf file directly (an alias in our case)
throughout the whole stack to avoid hard-coding IPs that will be
obsolete one day?

Thanks!
  Arne

—
Arne Wiebalck
CERN IT
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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




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

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

[Thomas Goirand]

On 05/05/2015 09:56 PM, Mike Bayer wrote:

Having two packages that both install into the same name is the least
ideal arrangement


From your point of view, and for testing against both, certainly. But 
for a distribution, avoiding dot have 2 packages clashing each other and 
deciding on only a single implementation of the same API is so much 
better in many ways. This avoid the duplication of work, security 
support, and above all: this makes it possible for all reverse 
dependency to just use the new implementation without doing anything.



and I don't see why we have to settle for a mediocre
outcome like that.  What we want is MySQL-Python to be maintained, we
have a maintainer, we have the code, we have everything we need, except
a password. We should at least make an attempt at that outcome.


A fork is often the worst thing that can happen to a project. See the 
examples of libav vs ffmpeg, libreoffice vs openoffice, or mysql vs 
mariadb. At the end, end users and developers all suffer. The only thing 
we can do is pickup the implementation which we believe is best for us. 
And in this case, it looks like mysqlclient has python3 support, which 
we want as a feature.


If you believe you can make it so that either:
#1 mysql-python can get Python 3 support.
#2 both forks are re-merged, and maintained as one.

then that's the best possible outcome (especially #2).

Whatever happens, talking to both upstream seems a very good idea to me.

However, it may not be possible to revert what has (or is about to) 
happen in Debian, as this is the decision of the package maintainer. I 
don't think it would be a good idea to go up to the Debian technical 
committee if the maintainer of the python-mysqldb package doesn't do 
something we like. The only other option we'd have would be to 
re-introduce mysql-python as a separate package, but the Debian FTP 
masters may oppose to it and reject it, unless we have a very good 
reason to do so (and at this point, I don't know if we do...).


Hoping the above helps with Debian insights,
Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [puppet] Proposal to configure Oslo libraries

[Ben Nemec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I don't know much about the puppet project organization so I won't
comment on whether 1 or 2 is better, but a big +1 to having a common
way to configure Oslo opts.  Consistency of those options across all
services is one of the big reasons we pushed so hard for the libraries
to own their option definitions, so this would align well with the way
the projects are consumed.

- -Ben

On 05/07/2015 03:19 PM, Emilien Macchi wrote:
> Hi,
> 
> I think one of the biggest challenges working on Puppet OpenStack 
> modules is to keep code consistency across all our modules (~20). 
> If you've read the code, you'll see there is some differences
> between RabbitMQ configuration/parameters in some modules and this
> is because we did not have the right tools to make it properly. A
> lot of the duplicated code we have comes from Oslo libraries 
> configuration.
> 
> Now, I come up with an idea and two proposals.
> 
> Idea 
> 
> We could have some defined types to configure oslo sections in
> OpenStack configuration files.
> 
> Something like: define oslo::messaging::rabbitmq( $user, $password 
> ) { ensure_resource($name, 'oslo_messaging_rabbit/rabbit_userid',
> {'value' => $user}) ... }
> 
> Usage in puppet-nova: ::oslo::messaging::rabbitmq{'nova_config': 
> user => 'nova', password => 'secrete', }
> 
> And patch all our modules to consume these defines and finally
> have consistency at the way we configure Oslo projects (messaging,
> logging, etc).
> 
> Proposals =
> 
> #1 Creating puppet-oslo ... and having oslo::messaging::rabbitmq,
> oslo::messaging::qpid, ..., oslo::logging, etc. This module will be
> used only to configure actual Oslo libraries when we deploy
> OpenStack. To me, this solution is really consistent with how 
> OpenStack works today and is scalable as soon we contribute Oslo 
> configuration changes in this module.
> 
> #2 Using puppet-openstacklib ... and having
> openstacklib::oslo::messaging::(...) A good thing is our modules
> already use openstacklib. But openstacklib does not configure
> OpenStack now, it creates some common defines & classes that are
> consumed in other modules.
> 
> 
> I personally prefer #1 because: * it's consistent with OpenStack. *
> I don't want openstacklib the repo where we put everything common.
> We have to differentiate *common-in-OpenStack* and
> *common-in-our-modules*. I think openstacklib should continue to be
> used for common things in our modules, like providers, wrappers,
> database management, etc. But to configure common OpenStack bits
> (aka Oslo©), we might want to create puppet-oslo.
> 
> As usual, any thoughts are welcome,
> 
> Best,
> 
> 
> 
> __

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVS9HMAAoJEDehGd0Fy7uq24sH/j/ctaGaNbGdxyRCfBatIPbU
Vk810yyMYzNH67s4Ku8LsEKvqMAoToEtnq/84ZXiUGUH65PtwGm9e6Nb54tkIHTE
tPVjQSePC7omn97M5A4tb94b6h0TaLxWT+0oZjnto1Lk+/Q1tCYgCySClyF/CsmM
2CZvHRqRKWG1ytWhJuYrjymury4Xfgpcwt7MA69Nqun/7fwjSgFvvVdfVlln6VI+
2Nx4AIFDyXVafvN7ZBIGkyqrWRsmyht3elvJg5JtxSu8gQbf3LVgbkTLREUccHDA
07/edo00ouAHMhKyYdvFimmjqr6gom5OqmpQqiw8TsFqFUDEXunTVil/v5W1dL8=
=B85A
-END PGP SIGNATURE-

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

Re: [openstack-dev] [cinder][nova] Question on Cinder client exception handling

[Matt Riedemann]

On 5/7/2015 3:21 PM, Chen CH Ji wrote:

no, I only want to confirm whether cinder folks is doing this or there
are already tricks can be used that before submit the change ... thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC

Inactive hide details for Matt Riedemann ---05/07/2015 10:12:21 PM---On
5/6/2015 7:02 AM, Chen CH Ji wrote: > HiMatt Riedemann ---05/07/2015
10:12:21 PM---On 5/6/2015 7:02 AM, Chen CH Ji wrote: > Hi

From: Matt Riedemann 
To: openstack-dev@lists.openstack.org
Date: 05/07/2015 10:12 PM
Subject: Re: [openstack-dev] [cinder][nova] Question on Cinder client
exception handling







On 5/6/2015 7:02 AM, Chen CH Ji wrote:
 > Hi
 > In order to work on [1] , nova need to know what kind of
 > exception are raised when using cinderclient so that it can handle like
 > [2] did?
 > In this case, we don't need to distinguish the error
 > case based on string compare , it's more accurate and less error leading
 > Anyone is doing it or any other methods I can use to
 > catch cinder specified  exception in nova? Thanks
 >
 >
 > [1] https://bugs.launchpad.net/nova/+bug/1450658
 > [2]
 >
https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L64
 >
 > Best Regards!
 >
 > Kevin (Chen) Ji 纪 晨
 >
 > Engineer, zVM Development, CSTL
 > Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 > Phone: +86-10-82454158
 > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 > District, Beijing 100193, PRC
 >
 >
 >
__
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >

Is there anything preventing us from adding a more specific exception to
cinderclient and then once that's in and released, we can pin the
minimum version of cinderclient in global-requirements so nova can
safely use it?

--

Thanks,

Matt Riedemann


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



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



I added some notes to the bug after looking into the cinder code.  I 
think this would actually be a series of changes if you want something 
more specific than the 500 you're getting back from the cinder API 
today, and that's going to be several changes (cinder to raise a more 
specific error, cinderclient to translate that to a specific exception, 
and then nova to handle that).


I'd probably just go with a change to nova to handle the 500 from cinder 
and not completely puke and orphan the instance.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [cinder][nova] Question on Cinder client exception handling

[Duncan Thomas]

On 7 May 2015 at 23:10, Matt Riedemann  wrote:

>
> Is there anything preventing us from adding a more specific exception to
> cinderclient and then once that's in and released, we can pin the minimum
> version of cinderclient in global-requirements so nova can safely use it?
>

Seems like the right approach to me. In some cases, the cinder API will
need to return more info first. I suggest raising bugs for any situations
that are hard to detect, and we can work from there...

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

Re: [openstack-dev] [swift] Go! Swift!

[David Medberry]

On Thu, May 7, 2015 at 2:10 PM, Chuck Thier  wrote:

> What started as a simple experiment by Mike Barton, has turned into quite
> a significant improvement in performance and builds a base that can be
> built off of for future improvements.  This wasn't built because of it
> being "shiny" but out of direct need, and is currently being tested with
> great results on production workloads.
>

Excellent and congrats to the team. Also very happy that it has been posted
and not made "secret sauce." Much appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] Question on Cinder client exception handling

[Chen CH Ji]

no, I only want to confirm whether cinder folks is doing this or there are
already tricks can be used that before submit the change ... thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann 
To: openstack-dev@lists.openstack.org
Date:   05/07/2015 10:12 PM
Subject:Re: [openstack-dev] [cinder][nova] Question on Cinder client
exception handling





On 5/6/2015 7:02 AM, Chen CH Ji wrote:
> Hi
> In order to work on [1] , nova need to know what kind of
> exception are raised when using cinderclient so that it can handle like
> [2] did?
> In this case, we don't need to distinguish the error
> case based on string compare , it's more accurate and less error leading
> Anyone is doing it or any other methods I can use to
> catch cinder specified  exception in nova? Thanks
>
>
> [1] https://bugs.launchpad.net/nova/+bug/1450658
> [2]
>
https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L64

>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Is there anything preventing us from adding a more specific exception to
cinderclient and then once that's in and released, we can pin the
minimum version of cinderclient in global-requirements so nova can
safely use it?

--

Thanks,

Matt Riedemann


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

[openstack-dev] [puppet] Proposal to configure Oslo libraries

[Emilien Macchi]

Hi,

I think one of the biggest challenges working on Puppet OpenStack
modules is to keep code consistency across all our modules (~20).
If you've read the code, you'll see there is some differences between
RabbitMQ configuration/parameters in some modules and this is because we
did not have the right tools to make it properly.
A lot of the duplicated code we have comes from Oslo libraries
configuration.

Now, I come up with an idea and two proposals.

Idea


We could have some defined types to configure oslo sections in OpenStack
configuration files.

Something like:
define oslo::messaging::rabbitmq(
  $user,
  $password
) {
  ensure_resource($name, 'oslo_messaging_rabbit/rabbit_userid', {'value'
=> $user})
  ...
}

Usage in puppet-nova:
::oslo::messaging::rabbitmq{'nova_config':
  user => 'nova',
  password => 'secrete',
}

And patch all our modules to consume these defines and finally have
consistency at the way we configure Oslo projects (messaging, logging, etc).

Proposals
=

#1 Creating puppet-oslo
... and having oslo::messaging::rabbitmq, oslo::messaging::qpid, ...,
oslo::logging, etc.
This module will be used only to configure actual Oslo libraries when we
deploy OpenStack. To me, this solution is really consistent with how
OpenStack works today and is scalable as soon we contribute Oslo
configuration changes in this module.

#2 Using puppet-openstacklib
... and having openstacklib::oslo::messaging::(...)
A good thing is our modules already use openstacklib.
But openstacklib does not configure OpenStack now, it creates some
common defines & classes that are consumed in other modules.


I personally prefer #1 because:
* it's consistent with OpenStack.
* I don't want openstacklib the repo where we put everything common. We
have to differentiate *common-in-OpenStack* and *common-in-our-modules*.
I think openstacklib should continue to be used for common things in our
modules, like providers, wrappers, database management, etc. But to
configure common OpenStack bits (aka Oslo©), we might want to create
puppet-oslo.

As usual, any thoughts are welcome,

Best,
-- 
Emilien Macchi



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

Re: [openstack-dev] [cinder][nova] Question on Cinder client exception handling

[Matt Riedemann]

On 5/6/2015 7:02 AM, Chen CH Ji wrote:

Hi
In order to work on [1] , nova need to know what kind of
exception are raised when using cinderclient so that it can handle like
[2] did?
In this case, we don't need to distinguish the error
case based on string compare , it's more accurate and less error leading
Anyone is doing it or any other methods I can use to
catch cinder specified  exception in nova? Thanks


[1] https://bugs.launchpad.net/nova/+bug/1450658
[2]
https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L64

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC


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



Is there anything preventing us from adding a more specific exception to 
cinderclient and then once that's in and released, we can pin the 
minimum version of cinderclient in global-requirements so nova can 
safely use it?


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [swift] Go! Swift!

[Chuck Thier]

I think most are missing the point a bit.  The question that should really
be asked is, what is right for Swift to continue to scale.  Since the
inception of Openstack, Swift has had to solve for problems of scale that
generally are not shared with the rest of Openstack.

When we first set out to write Swift, we had set, what we thought at the
time were pretty lofty goals for ourselves:

* 100 Billion objects
* 100 Petabytes of data
* 100 K requests/second
* 100 Gb/s throughput

We started with Python figuring that when we hit major bottlenecks, we
would look at other options.  We have been surprised at how far we have
been able to push Python and have met most if not all of the goals above.

As we look toward the future, we realize that we are now looking for how we
will support trillions of objects, 100's of petabytes to exabytes of data,
etc.  We feel that we have finally hit that point that we need more than
incremental improvements, and that we are running out of incremental
improvements that can be made with Python.

What started as a simple experiment by Mike Barton, has turned into quite a
significant improvement in performance and builds a base that can be built
off of for future improvements.  This wasn't built because of it being
"shiny" but out of direct need, and is currently being tested with great
results on production workloads.

I applaud the team that has worked on this at Rackspace, and hope the
community can look at the current needs of Swift, and the merits of the
work that has been accomplished, rather than the politics of "shiny".

Thanks,

--
Chuck


On Thu, Apr 30, 2015 at 11:45 AM John Dickinson  wrote:

> Swift is a scalable and durable storage engine for storing unstructured
> data. It's been proven time and time again in production in clusters all
> over the world.
>
> We in the Swift developer community are constantly looking for ways to
> improve the codebase and deliver a better quality codebase to users
> everywhere. During the past year, the Rackspace Cloud Files team has been
> exploring the idea of reimplementing parts of Swift in Go. Yesterday, they
> released some of this code, called "hummingbird", for the first time. It's
> been proposed to a "feature/hummingbird" branch in Swift's source repo.
>
> https://review.openstack.org/#/c/178851
>
> I am very excited about this work being in the greater OpenStack Swift
> developer community. If you look at the patch above, you'll see that there
> are various parts of Swift reimplemented in Go. During the next six months
> (i.e. before Tokyo), I would like us to answer this question:
>
> What advantages does a compiled-language object server bring, and do they
> outweigh the costs of using a different language?
>
> Of course, there are a ton of things we need to explore on this topic, but
> I'm happy that we'll be doing it in the context of the open community
> instead of behind closed doors. We will have a fishbowl session in
> Vancouver on this topic. I'm looking forward to the discussion.
>
>
> --John
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

[Jay Reslock]

Hi,
This is my first mail to the group.  I hope I set the subject correctly and
that this hasn't been asked already.  I searched archives and did not see
this question asked or answered previously.

I am working on a client thing that uses the python-keystoneclient and
python-heatclient api bindings to set up an authenticated session and then
use that session to talk to the heat service.  This doesn't work for heat
but does work for other services such as nova and sahara.  Is this because
sessions aren't supported in the heatclient api yet?

sample code:

https://gist.github.com/jreslock/a525abdcce53ca0492a7

I'm using fabric to define tasks so I can call them via another tool.  When
I run the task I get:

TypeError: Client() takes at least 1 argument (0 given)

The documentation does not say anything about being able to pass session to
the heatclient but the others seem to work.  I just want to know if this is
intended/expected behavior or not.

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

Re: [openstack-dev] Question about multi-host mode while using nova-network

[Christopher Aedo]

The openstack-dev list is primarily intended to be used for OpenStack
development discussions and planning, rather than dealing with
operational/usage questions.  Your best place to start is
http://ask.openstack.org if you can't find the answer in our excellent
docs (http://docs.openstack.org/).

-Christopher

On Thu, May 7, 2015 at 12:08 AM, BYEONG-GI KIM  wrote:
> Hello.
>
> It seems that this question would be quite outdated question, because this
> is a question about nova-network instead of neutron.
>
> I wonder whether VMs located in a Compute Node, e.g., Compute A, are
> accessible while its nova-network service is down if the other nova-network
> is running on the other Compute Nodes, such as Compute B, Compute C, etc.
>
> Or, does the multi-host just provide continuity of the networking service
> via avoiding single point failure?
>
> Thanks in advance!
>
> Regards,
> Byeong-gi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] Question about multi-host mode while using nova-network

[Christopher Aedo]

The openstack-dev list is primarily intended to be used for OpenStack
development discussions and planning, rather than dealing with
operational/usage questions.  Your best place to start is
http://ask.openstack.org if you can't find the answer in our excellent
docs (http://docs.openstack.org/).

-Christopher


On Thu, May 7, 2015 at 12:08 AM, BYEONG-GI KIM  wrote:
> Hello.
>
> It seems that this question would be quite outdated question, because this
> is a question about nova-network instead of neutron.
>
> I wonder whether VMs located in a Compute Node, e.g., Compute A, are
> accessible while its nova-network service is down if the other nova-network
> is running on the other Compute Nodes, such as Compute B, Compute C, etc.
>
> Or, does the multi-host just provide continuity of the networking service
> via avoiding single point failure?
>
> Thanks in advance!
>
> Regards,
> Byeong-gi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Sean M. Collins]

On Thu, May 07, 2015 at 01:40:53PM EDT, Sean Dague wrote:
> On 05/07/2015 01:37 PM, Boris Pavlovic wrote:
> > Sean,
> > 
> > Nobody is able to track and know *everything*.
> > 
> > Friendly reminder that Heat is going to be removed and not installed by
> > default would help to avoid such situations. 
> 
> Sure, but that misses the first point, that gate jobs should really be
> explicit about the services they run.
> 
> It's a vast surprise that anything running in our gate just runs with
> "defaults".
> 
> So I would suggest now is an excellent time to make the rally jobs work
> like the grenade and tempest jobs and be explicit about such things.
> 
>   -Sean


I'd like to +1 this - that gate jobs should be also explicit about their
configuration. For example, on the network side I've been listening to
my own advice and making the Ironic job explicitly set the OVS agent for
Neutron.

-- 
Sean M. Collins

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

Re: [openstack-dev] OpenStack Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

I meatn, it works okay with Linux 3.16, not 3.19. Sorry...

On Thu, May 7, 2015 at 4:26 PM Martinx - ジェームズ 
wrote:

> Guys,
>
>  I just upgraded my Trusty servers, that I'm running OpenStack Juno, to
> Linux 3.19, which is already available at Proposed repository.
>
>  OpenStack is dead here, no connectivity for the tenants.
>
>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452868
>
>  I appreciate any help!
>
>  It works okay with Linux 3.19.
>
> Best,
> Thiago
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

Guys,

 I just upgraded my Trusty servers, that I'm running OpenStack Juno, to
Linux 3.19, which is already available at Proposed repository.

 OpenStack is dead here, no connectivity for the tenants.

 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452868

 I appreciate any help!

 It works okay with Linux 3.19.

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

Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

[Georgy Okrokvertskhov]

Yes, Rabbit MQ is kind of shared. Each VM gets its own Queue which is
dynamically created in MQ when application is being deployed. Technically
we can create separate MQ users and virtual hosts for each VM, but this is
an overkill for now. So by default it is just separate Queue with random
generated name.

If you want more protection you wiull have to change Murano default
behaviour by adding a new vhost for each tenant.

Thanks
Gosha

On Thu, May 7, 2015 at 10:26 AM, Fox, Kevin M  wrote:

>  So... rabbit is not multitenant I think. You share a rabbit across
> multiple tenants's vms? How do you protect one tenant's vm's from getting
> commands sent to it by another tenant?
>
> Thanks,
> Kevin
>  --
> *From:* Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com]
> *Sent:* Thursday, May 07, 2015 9:18 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
>
> Hi,
>
>  When we use Murano in production there is a MQ service which is running
> on OpenStack controllers but it listens on public interface. It means that
> both Murano which is running on OpenStack controllers and Agent on VMs have
> an access to this MQ via external (public) network.
>  When Murano creates a new deployment it actually deploys a private
> network and attach it to the router which acts as a gateway to external
> networking. So it is specific application deployment topology which allows
> VMs to communicate with MA via external network.
>
>  Thanks
>  Gosha
>
> On Thu, May 7, 2015 at 1:28 AM, Filip Blaha  wrote:
>
>>  yes. I agree that direction is important from only networking piont of
>> view. Usually is more probable that VM on neutron network will be able to
>> access O~S service ( VM --> rabbit) then opposite direction from O~S
>> service to VM running on neutron network (mistral --> VM).
>>
>> Filip
>>
>>
>>
>> On 05/06/2015 06:39 PM, Georgy Okrokvertskhov wrote:
>>
>>   Connection direction here is important only in the frame of networking
>> connectivity problem solving. The networking in OpenStack in general works
>> in such a way so that connections from VM are allowed to almost anywhere.
>> In Murano production deployment we use separate MQ instance so that VMs
>> have no access to OpenStack MQ.
>>
>>  In the sense who initiates task execution it always a Murano service
>> which publishes tasks (shell script + necessary files) in the MQ so that
>> agent can pull them and execute.
>>
>>  Thanks
>>  Gosha
>>
>>
>>
>> On Wed, May 6, 2015 at 9:31 AM, Filip Blaha  wrote:
>>
>>> Hello
>>>
>>> one more note on that. There is difference in direction who initiates
>>> connection. In case of murano agent --> rabbit MQ is connection initiated
>>> from VM to openstack service(rabbit). In case of std.ssh mistral action is
>>> direction opposite from openstack service (mistral) to ssh server on VM.
>>>
>>> Filip
>>>
>>>
>>> On 05/06/2015 06:00 PM, Pospisil, Radek wrote:
>>>
 Hello,

 I think that the generic question is - can be O~S services also
 accessible on Neutron networks, so VM (created by Nova) can access it? We
 (I and Filip) were discussing this today and we were not make a final
 decision.
 Another example is Murano agent running on VMs - it connects to
 RabbitMQ which is also accessed by Murano engine

Regards,

 Radek

 -Original Message-
 From: Blaha, Filip
 Sent: Wednesday, May 06, 2015 5:43 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action

 Hello

 We are considering implementing  actions on services of a murano
 environment via mistral workflows. We are considering whether mistral
 std.ssh action could be used to run some command on an instance. Example of
 such action in murano could be restart action on Mysql DB service.
 Mistral workflow would ssh to that instance running Mysql and run
 "service mysql restart". From my point of view trying to use SSH to access
 instances from mistral workflow is not good idea but I would like to
 confirm it.

 The biggest problem I see there is openstack networking. Mistral
 service running on some openstack node would not be able to access instance
 via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh
 from namespace of its gateway router e.g. "ip netns exec qrouter-... ssh
 cirros@10.0.0.5" but I think it is not good to rely on implementation
 detail of  neutron and use it. In multinode openstack deployment it could
 be even more complicated.

 In other words I am asking whether we can use std.ssh mistral action to
 access instances via ssh on theirs fixed IPs? I think no but I would like
 to confirm it.

 Thanks
 Filip


 

Re: [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI

[Samuel Bartel]

Vitaly, Simon, thanks for your answers.
In fact for the cinder multi backend use case, it is more complicated and
closer from simon's case. For each filer, we have several parameters
(hostname/ip, username, password, volume, storage protocoleand so on). So I
thing that we are going to use Simon's approach a little bit modified :
having  a pick list corresponding to the number of filers to declare and
then display the corresponding number of group of fields and hide the
others.

But for sure JS part for plugin would be a great improvement for
developping complex plugins.


2015-05-07 18:41 GMT+02:00 Vitaly Kramskikh :

> Samuel,
>
> There are plans to solve this:
>
> 1) Add a flag/field to control declaration so it can have multiple values:
>
>   ntp_list:
> *multiple_values: true*
> value:
>   - "1.1.1.1"
>   - "2.2.2.2"
> label: "NTP server list"
> description: "List of upstream NTP servers"
> type: "text"
>
> Now we use one input with comma-separated values to enter DNS and NTP
> servers which is hacky. This proposal with also solve your issue, but won't
> help for Simon's case (as there are groups of 2 fields).
>
> 2) For complex controls we plan to implement support for JS parts of
> plugins , so you
> can implement configuration UI of any complexity by providing custom JS.
> repo_setup control in 6.1 is a great example of a complex control.
>
> For 6.1 I suggest you to use current DNS/NTP approach (comma separated
> values) or Simon's approach (though I'd use action: hide instead of action:
> disable)
>
>
> 2015-05-07 17:36 GMT+03:00 Simon Pasquier :
>
>> Hello Samuel,
>> As far as I know, this isn't possible unfortunately. For our own needs,
>> we ended up adding a fixed-size list with all items but the first one
>> disabled. When you enter something in the first input box, it enabled the
>> second box and so on (see [1]). In any case, this would be a good
>> addition...
>> BR,
>> Simon
>> [1]
>> https://github.com/stackforge/fuel-plugin-elasticsearch-kibana/blob/master/environment_config.yaml#L21
>>
>> On Thu, May 7, 2015 at 3:37 PM, Samuel Bartel <
>> samuel.bartel@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> I am working on two plugins for fuel : logrotate and cinder-netapp (to
>>> add multibackend feature)
>>>
>>> In this two plugins I face the same problem. Is it possible in the
>>> environment yaml config describing the fields to display for the plugin in
>>> the UI to have some dynamic element.
>>>
>>> I explain my need. I would like to be able to add additional element by
>>> clicking on a “+” button as the IP range for network tab in order to be
>>> able to:
>>>
>>> -add new log file to manage for the logrorate instead of having a static
>>> list
>>>
>>> -add extra netapp filer/volume instead ofbeing able to setup only one
>>> for the cinder netapp in a multibackend scope.
>>>
>>> For the cinder netapp for example, I would be able to access to the
>>> netapp server hostname with:
>>>
>>> $::fuel_settings[‘cinder_netapp’][0][‘netapp_server_hostname’]  #for the
>>> first one
>>>
>>> $::fuel_settings[‘cinder_netapp’][1][‘netapp_server_hostname’]  #for the
>>> second  one
>>>
>>> And so on.
>>>
>>>
>>>
>>> Can we do that with the actual plugin feature.  If not is it planned to
>>> add such a feature?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Samuel
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Boris Pavlovic]

Joshua,


Makes sense, perhaps all the test (and/or test-like) frameworks could share
> some code + common config that does this, seems to be something simple (and
> something that all could use for pre-testing validation of all the expected
> services being alive/active/up/responding...)?


In Rally this is part of life cycle of running task.
Not sure that it is possible to share it, because it is thigh related to
checking what did you write in task. =)


Best regards,
Boris Pavlovic

On Thu, May 7, 2015 at 9:54 PM, Joshua Harlow  wrote:

> Sean Dague wrote:
>
>> On 05/07/2015 02:29 PM, Joshua Harlow wrote:
>>
>>> Boris Pavlovic wrote:
>>>
 Sean,

 Nobody is able to track and know *everything*.

 Friendly reminder that Heat is going to be removed and not installed by
 default would help to avoid such situations.

>>> Doesn't keystone have a service listing? Use that in rally (and
>>> elsewhere?), if keystone had a service and each service had a API
>>> discovery ability, there u go, profit! ;)
>>>
>>
>> Service listing for test jobs is actually quite dangerous, because then
>> something can change something about which services are registered, and
>> you automatically start skipping 30% of your tests because you react
>> correctly to this change. However, that means the job stopped doing what
>> you think it should do.
>>
>> *This has happened multiple times in the past*. And typically days,
>> weeks, or months go by before someone notices in investigating an
>> unrelated failure. And then it's days, weeks, or months to dig out of
>> the regressions introduced.
>>
>> So... test jobs should be extremely explicit about what they setup and
>> what they expect.
>>
>
> Makes sense, perhaps all the test (and/or test-like) frameworks could
> share some code + common config that does this, seems to be something
> simple (and something that all could use for pre-testing validation of all
> the expected services being alive/active/up/responding...)?
>
> ^^ Just an idear,
>
> -Josh
>
>
>> -Sean
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Boris Pavlovic]

>
> So... test jobs should be extremely explicit about what they setup and
> what they expect.


+2

Best regards,
Boris Pavlovic

On Thu, May 7, 2015 at 9:44 PM, Sean Dague  wrote:

> On 05/07/2015 02:29 PM, Joshua Harlow wrote:
> > Boris Pavlovic wrote:
> >> Sean,
> >>
> >> Nobody is able to track and know *everything*.
> >>
> >> Friendly reminder that Heat is going to be removed and not installed by
> >> default would help to avoid such situations.
> >
> > Doesn't keystone have a service listing? Use that in rally (and
> > elsewhere?), if keystone had a service and each service had a API
> > discovery ability, there u go, profit! ;)
>
> Service listing for test jobs is actually quite dangerous, because then
> something can change something about which services are registered, and
> you automatically start skipping 30% of your tests because you react
> correctly to this change. However, that means the job stopped doing what
> you think it should do.
>
> *This has happened multiple times in the past*. And typically days,
> weeks, or months go by before someone notices in investigating an
> unrelated failure. And then it's days, weeks, or months to dig out of
> the regressions introduced.
>
> So... test jobs should be extremely explicit about what they setup and
> what they expect.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net

[Morgan Fainberg]

On May 7, 2015 at 11:21:00 AM, Chris St. Pierre (chris.a.st.pie...@gmail.com) 
wrote:
Jinkies, that sounds like *work*. Got any links to docs I can start diving 
into? In particular, keystone audit events and anything that might be handy 
about the solution proposal you mention. Keystone is mostly foreign territory 
to me so some learning will be in order.


The event notifications are documented here: 
http://docs.openstack.org/developer/keystone/event_notifications.html
As to the rest of the topic, there are a few threads in the past on the ML such 
as http://lists.openstack.org/pipermail/openstack-dev/2015-February/055801.html

I don’t think we’ve really gotten much further at this point than that.

Thanks!

On Thu, May 7, 2015 at 12:49 PM, Morgan Fainberg  
wrote:
Hi Chris,

So there is no rule saying you can't ask keystone. However, we do emit events 
(audit, needs to be configured) to the message bus when tenants (or in v3 
parlance, projects) are deleted. This allows nova to mark things in a way to 
cleanup / do direct cleanup. 

There have been a few conversations about this, but we haven't made significant 
progress (as far as I know) on this topic. 

The best solution proposal (iirc) was that we need to creat a listener or 
similar that the other services could hook a callback to that will do the 
cleanup directly rather than require blocking the main API for the cleanup. 

Keystone is open to these improvements and ideas. It just doesn't scale of 
every action from every service has to ask keystone if  still exists. 
Let's make sure we don't start using a pattern that will cause significant 
issues down the road.  

--Morgan

Sent via mobile

On May 7, 2015, at 09:37, Chris St. Pierre  wrote:

This bug recently came to my attention: 
https://bugs.launchpad.net/nova/+bug/1241587

I've reopened it, because it is an actual problem, especially for people using 
nova-network and Rally, which creates and deletes tons of tenants.

The obvious simple solution is to allow deletion of the 'default' security 
group if it is assigned to a tenant that doesn't exist, but I wasn't sure what 
the most acceptable way to do that within Nova would be. Is it acceptable to 
perform a call to the Keystone API to check for the tenant? Or is there 
another, better way?

Alternatively, is there a better way to tackle the problem altogether?

Thanks!

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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Joshua Harlow]

Sean Dague wrote:

On 05/07/2015 02:29 PM, Joshua Harlow wrote:

Boris Pavlovic wrote:

Sean,

Nobody is able to track and know *everything*.

Friendly reminder that Heat is going to be removed and not installed by
default would help to avoid such situations.

Doesn't keystone have a service listing? Use that in rally (and
elsewhere?), if keystone had a service and each service had a API
discovery ability, there u go, profit! ;)


Service listing for test jobs is actually quite dangerous, because then
something can change something about which services are registered, and
you automatically start skipping 30% of your tests because you react
correctly to this change. However, that means the job stopped doing what
you think it should do.

*This has happened multiple times in the past*. And typically days,
weeks, or months go by before someone notices in investigating an
unrelated failure. And then it's days, weeks, or months to dig out of
the regressions introduced.

So... test jobs should be extremely explicit about what they setup and
what they expect.


Makes sense, perhaps all the test (and/or test-like) frameworks could 
share some code + common config that does this, seems to be something 
simple (and something that all could use for pre-testing validation of 
all the expected services being alive/active/up/responding...)?


^^ Just an idear,

-Josh



-Sean



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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Sean Dague]

On 05/07/2015 02:29 PM, Joshua Harlow wrote:
> Boris Pavlovic wrote:
>> Sean,
>>
>> Nobody is able to track and know *everything*.
>>
>> Friendly reminder that Heat is going to be removed and not installed by
>> default would help to avoid such situations.
> 
> Doesn't keystone have a service listing? Use that in rally (and
> elsewhere?), if keystone had a service and each service had a API
> discovery ability, there u go, profit! ;)

Service listing for test jobs is actually quite dangerous, because then
something can change something about which services are registered, and
you automatically start skipping 30% of your tests because you react
correctly to this change. However, that means the job stopped doing what
you think it should do.

*This has happened multiple times in the past*. And typically days,
weeks, or months go by before someone notices in investigating an
unrelated failure. And then it's days, weeks, or months to dig out of
the regressions introduced.

So... test jobs should be extremely explicit about what they setup and
what they expect.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Boris Pavlovic]

Joshua,


Doesn't keystone have a service listing? Use that in rally (and
> elsewhere?), if keystone had a service and each service had a API discovery
> ability, there u go, profit! ;)


Exactly that happened. We were running benchmarks against Heat and Rally
task validation start failing saying  that there is no heat service=)

Best regards,
Boris Pavlovic

On Thu, May 7, 2015 at 9:29 PM, Joshua Harlow  wrote:

> Boris Pavlovic wrote:
>
>> Sean,
>>
>> Nobody is able to track and know *everything*.
>>
>> Friendly reminder that Heat is going to be removed and not installed by
>> default would help to avoid such situations.
>>
>
> Doesn't keystone have a service listing? Use that in rally (and
> elsewhere?), if keystone had a service and each service had a API discovery
> ability, there u go, profit! ;)
>
>
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>> On Thu, May 7, 2015 at 8:06 PM, Sean Dague > > wrote:
>>
>> On 05/07/2015 12:51 PM, Boris Pavlovic wrote:
>>  > Hi stackers,
>>  >
>>  > Recently was merged patch that removes Heat from list of service
>> that
>>  > are installed by default DevStack
>>  >
>>  > Please next time make sure that all PTL of all projects in
>> OpenStack
>>  > know about such big not backward compatible changes.
>>  >
>>  > P.S This change paralyzed work on Rally for 2 days. =(
>>
>> This should in no way impact gate jobs, they should all be explicitly
>> setting service lists themselves for their environments. The ensure
>> devstack-gate model is built around that. If they are not, then that
>> is
>> a bug in how they were built.
>>
>> This has also been a long time coming, we merged the direction patch
>> for
>> this in Feb in the FUTURE.rst document.
>>
>>  -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Joshua Harlow]

Boris Pavlovic wrote:

Sean,

Nobody is able to track and know *everything*.

Friendly reminder that Heat is going to be removed and not installed by
default would help to avoid such situations.


Doesn't keystone have a service listing? Use that in rally (and 
elsewhere?), if keystone had a service and each service had a API 
discovery ability, there u go, profit! ;)






Best regards,
Boris Pavlovic

On Thu, May 7, 2015 at 8:06 PM, Sean Dague mailto:s...@dague.net>> wrote:

On 05/07/2015 12:51 PM, Boris Pavlovic wrote:
 > Hi stackers,
 >
 > Recently was merged patch that removes Heat from list of service that
 > are installed by default DevStack
 >
 > Please next time make sure that all PTL of all projects in OpenStack
 > know about such big not backward compatible changes.
 >
 > P.S This change paralyzed work on Rally for 2 days. =(

This should in no way impact gate jobs, they should all be explicitly
setting service lists themselves for their environments. The ensure
devstack-gate model is built around that. If they are not, then that is
a bug in how they were built.

This has also been a long time coming, we merged the direction patch for
this in Feb in the FUTURE.rst document.

 -Sean

--
Sean Dague
http://dague.net

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

Re: [openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net

[Chris St. Pierre]

Jinkies, that sounds like *work*. Got any links to docs I can start diving
into? In particular, keystone audit events and anything that might be handy
about the solution proposal you mention. Keystone is mostly foreign
territory to me so some learning will be in order.

Thanks!

On Thu, May 7, 2015 at 12:49 PM, Morgan Fainberg 
wrote:

> Hi Chris,
>
> So there is no rule saying you can't ask keystone. However, we do emit
> events (audit, needs to be configured) to the message bus when tenants (or
> in v3 parlance, projects) are deleted. This allows nova to mark things in a
> way to cleanup / do direct cleanup.
>
> There have been a few conversations about this, but we haven't made
> significant progress (as far as I know) on this topic.
>
> The best solution proposal (iirc) was that we need to creat a listener or
> similar that the other services could hook a callback to that will do the
> cleanup directly rather than require blocking the main API for the cleanup.
>
> Keystone is open to these improvements and ideas. It just doesn't scale of
> every action from every service has to ask keystone if  still
> exists. Let's make sure we don't start using a pattern that will cause
> significant issues down the road.
>
> --Morgan
>
> Sent via mobile
>
> On May 7, 2015, at 09:37, Chris St. Pierre 
> wrote:
>
> This bug recently came to my attention:
> https://bugs.launchpad.net/nova/+bug/1241587
>
> I've reopened it, because it is an actual problem, especially for people
> using nova-network and Rally, which creates and deletes tons of tenants.
>
> The obvious simple solution is to allow deletion of the 'default' security
> group if it is assigned to a tenant that doesn't exist, but I wasn't sure
> what the most acceptable way to do that within Nova would be. Is it
> acceptable to perform a call to the Keystone API to check for the tenant?
> Or is there another, better way?
>
> Alternatively, is there a better way to tackle the problem altogether?
>
> Thanks!
>
> --
> Chris St. Pierre
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?

[Paul Michali]

Sridar R is planning on having a proposal for DM VPN ready (today?) that he
wants to propose for Liberty release. We're going to have a VPN meeting
next Tuesday (per his request), to discuss this more.

Regards,

PCM

On Thu, May 7, 2015 at 10:58 AM Mathieu Rohon 
wrote:

> Hi,
>
> On Wed, May 6, 2015 at 8:42 AM, Salvatore Orlando 
> wrote:
>
>> I think Paul is correctly scoping this discussion in terms of APIs and
>> management layer.
>> For instance, it is true that dynamic routing support, and BGP support
>> might be a prerequisite for BGP VPNs, but it should be possible to have at
>> least an idea of how user and admin APIs for this VPN use case should look
>> like.
>>
>
> the spec [4] is mainly focusing on API and data model. Of course there
> might be some overlap with BGP support and/or dynamic routing support, but
> this is more about implementation details to my POV.
> We hope we'll see some good progress about the API during reviews and
> design summit, since it seem to suit to several players.
>
>
>> In particular the discussion on service chaining is a bit out of scope
>> here. I'd just note that [1] seems to have a lot of overlap with
>> group-based-policies [2], and that it appears to be a service that consumes
>> Neutron rather than an extension to it.
>>
>> The current VPN service was conceived to be fairly generic. IPSEC VPN is
>> the only implemented one, but SSL VPN and BGP VPN were on the map as far as
>> I recall.
>> Personally having a lot of different VPN APIs is not ideal for users. As
>> a user, I probably don't even care about configuring a VPN. What is
>> important for me is to get L2 or L3 access to a network in the cloud;
>> therefore I would seek for common abstractions that might allow a user for
>> configuring a VPN service using the same APIs. Obviously then there will be
>> parameters which will be specific for the particular class of VPN being
>> created.
>>
>
>> I listened to several contributors in the area in the past, and there are
>> plenty of opinions across a spectrum which goes from total abstraction
>> (just expose "edges" at the API layer) to what could be tantamount to a
>> RESTful configuration of a VPN appliance. I am not in a position such to
>> prescribe what direction the community should take; so, for instance, if
>> the people working on XXX VPN believe the best way forward for them is to
>> start a new project, so be it.
>>
>
> that's what BGP VPN and Edge VPN did by creating their own stackforge
> project. But I think the idea was more about sharing the framework upstream
> after failing at finding a consensus during design summits, rather than
> promoting the fact that this has nothing to do with other VPN stuff in
> Neutron.
>
>
>>
>> The other approach would obviously to build onto the current APIs. The
>> only way the Neutron API layer provides to do that is to extend and
>> extension. This sounds terrible, and it is indeed terrible. There is a
>> proposal for moving toward versioned APIs [3], but until that proposal is
>> approved and implemented extensions are the only thing we have.
>>
>
> Advanced services, such as VPNaaS, are out of the scope of the current
> proposal [3]. It might take a while before the VPNaaS team moves to the
> micro-versionning framework.
>
>
>> From an API perspective the mechanism would be simpler:
>> 1 - declare the extension, and implement get_required_extension to put
>> 'vpnaas' as a requirement
>> 2 - implement a DB mixin for it providing basic CRUD operations
>> 3 - add it to the VPN service plugin and add its alias to
>> 'supported_extensions_aliases' (step 2 and 3 can be merged if you wish not
>> to have a mixin)
>>
>> What might be a bit more challenging is defining how this reflects onto
>> VPN. Ideally you would have a driver for every VPN type you support, and
>> then have a little dispatcher to route the API call to the appropriate
>> driver according to the VPN type.
>>
>> Salvatore
>>
>> [1]
>> https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining
>> [2] https://wiki.openstack.org/wiki/GroupBasedPolicy
>> [3] https://review.openstack.org/#/c/136760
>>
>
> [4]  https://review.openstack.org/#/c/177740/
>
>
>> On 6 May 2015 at 07:14, Vikram Choudhary 
>> wrote:
>>
>>>  Hi Paul,
>>>
>>>
>>>
>>> Thanks for starting this mail thread.  We are also eyeing for supporting
>>> MPBGP in neutron and will like to actively participate in this discussion.
>>>
>>> Please let me know about the IRC channels which we will be following for
>>> this discussion.
>>>
>>>
>>>
>>> Currently, I am following below BP’s for this work.
>>>
>>> https://blueprints.launchpad.net/neutron/+spec/edge-vpn
>>>
>>> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing
>>>
>>> https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework
>>>
>>>
>>> https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol
>>>
>>>
>>>
>>> Moreover, a similar kind of work is 

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Boris Pavlovic]

Sean,

Thank you for advice. We are going to fix jobs ASAP.

Here is the patch: https://review.openstack.org/#/c/181088/
But seems like it's not ready yet.

Best regards,
Boris Pavlovic



On Thu, May 7, 2015 at 8:40 PM, Sean Dague  wrote:

> On 05/07/2015 01:37 PM, Boris Pavlovic wrote:
> > Sean,
> >
> > Nobody is able to track and know *everything*.
> >
> > Friendly reminder that Heat is going to be removed and not installed by
> > default would help to avoid such situations.
>
> Sure, but that misses the first point, that gate jobs should really be
> explicit about the services they run.
>
> It's a vast surprise that anything running in our gate just runs with
> "defaults".
>
> So I would suggest now is an excellent time to make the rally jobs work
> like the grenade and tempest jobs and be explicit about such things.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] removing Angus Salkeld and Nick Barcet from ceilometer-core‏

[gordon chung]

hi folks,
as both have moved on to other endeavours, today we will be removing two 
founding contributors of Ceilometer from the core team. thanks to both of you 
for guiding the project in it's early days!
cheers,gord
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Morgan Fainberg]

> On May 7, 2015, at 10:40, Sean Dague  wrote:
> 
>> On 05/07/2015 01:37 PM, Boris Pavlovic wrote:
>> Sean,
>> 
>> Nobody is able to track and know *everything*.
>> 
>> Friendly reminder that Heat is going to be removed and not installed by
>> default would help to avoid such situations.
> 
> Sure, but that misses the first point, that gate jobs should really be
> explicit about the services they run.
> 
> It's a vast surprise that anything running in our gate just runs with
> "defaults".
> 
> So I would suggest now is an excellent time to make the rally jobs work
> like the grenade and tempest jobs and be explicit about such things.

Huge +1. Gate jobs absolutely should be explicit. Guessing what is being tested 
is no fun. 

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

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

Re: [openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net

[Morgan Fainberg]

Hi Chris,

So there is no rule saying you can't ask keystone. However, we do emit events 
(audit, needs to be configured) to the message bus when tenants (or in v3 
parlance, projects) are deleted. This allows nova to mark things in a way to 
cleanup / do direct cleanup. 

There have been a few conversations about this, but we haven't made significant 
progress (as far as I know) on this topic. 

The best solution proposal (iirc) was that we need to creat a listener or 
similar that the other services could hook a callback to that will do the 
cleanup directly rather than require blocking the main API for the cleanup. 

Keystone is open to these improvements and ideas. It just doesn't scale of 
every action from every service has to ask keystone if  still exists. 
Let's make sure we don't start using a pattern that will cause significant 
issues down the road.  

--Morgan

Sent via mobile

> On May 7, 2015, at 09:37, Chris St. Pierre  
> wrote:
> 
> This bug recently came to my attention: 
> https://bugs.launchpad.net/nova/+bug/1241587
> 
> I've reopened it, because it is an actual problem, especially for people 
> using nova-network and Rally, which creates and deletes tons of tenants.
> 
> The obvious simple solution is to allow deletion of the 'default' security 
> group if it is assigned to a tenant that doesn't exist, but I wasn't sure 
> what the most acceptable way to do that within Nova would be. Is it 
> acceptable to perform a call to the Keystone API to check for the tenant? Or 
> is there another, better way?
> 
> Alternatively, is there a better way to tackle the problem altogether?
> 
> Thanks!
> 
> -- 
> Chris St. Pierre
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Sean Dague]

On 05/07/2015 01:37 PM, Boris Pavlovic wrote:
> Sean,
> 
> Nobody is able to track and know *everything*.
> 
> Friendly reminder that Heat is going to be removed and not installed by
> default would help to avoid such situations. 

Sure, but that misses the first point, that gate jobs should really be
explicit about the services they run.

It's a vast surprise that anything running in our gate just runs with
"defaults".

So I would suggest now is an excellent time to make the rally jobs work
like the grenade and tempest jobs and be explicit about such things.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Boris Pavlovic]

Sean,

Nobody is able to track and know *everything*.

Friendly reminder that Heat is going to be removed and not installed by
default would help to avoid such situations.



Best regards,
Boris Pavlovic

On Thu, May 7, 2015 at 8:06 PM, Sean Dague  wrote:

> On 05/07/2015 12:51 PM, Boris Pavlovic wrote:
> > Hi stackers,
> >
> > Recently was merged patch that removes Heat from list of service that
> > are installed by default DevStack
> >
> > Please next time make sure that all PTL of all projects in OpenStack
> > know about such big not backward compatible changes.
> >
> > P.S This change paralyzed work on Rally for 2 days. =(
>
> This should in no way impact gate jobs, they should all be explicitly
> setting service lists themselves for their environments. The ensure
> devstack-gate model is built around that. If they are not, then that is
> a bug in how they were built.
>
> This has also been a long time coming, we merged the direction patch for
> this in Feb in the FUTURE.rst document.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

[Dan Prince]

On Thu, 2015-05-07 at 17:36 +0200, Giulio Fidente wrote:
> On 05/07/2015 03:31 PM, Dan Prince wrote:
> > On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:
> 
> [...]
> 
> >> I think the change is good, I am assuming we don't want the shared parts
> >> to get duplicated into the two .pp though.
> >
> > So again. Duplicating the puppet class includes doesn't bother me too
> > much. Some of the logic (perhaps the DB creation) should move over to
> > puppet-tripleo however. But I would like to see us not go crazy with the
> > composition layer... using the stackforge/puppet modules directly is
> > best I think.
> 
> but it is not only includes really, I understand we would like it to be 
> so, but it isn't
> 
> eg, this would be duplicated, if not moved elsewhere:
> 
> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/manifests/overcloud_controller.pp#L166-L227
> 
> this as well:
> 
> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/manifests/overcloud_controller.pp#L296-L333
> 
> and there are quite a lot of similar examples, the change from marios as 
> well, ended up duplicating lots of code:

I would say the choice we make here is a bit of a gray area (A
preference).

Yes, there is some duplication but I suppose my preference (with our
present architecture) is to live with that as opposed to having the
conditional $enable_pacemaker mess that is occurring in
overcloud_controller.pp. I'm mostly looking at things like the rabbitmq
and galera implementations which have duplication w/ either approach
(using $enable_pacemaker or the fork approach I'm suggesting here). For
example:

http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/puppet/manifests/overcloud_controller.pp#n229

Like Emilien points out a wrapper approach could significantly clean up
some things... but we don't have that yet w/ puppet-pacemaker. And also,
that moves us closer to use a composition layer anyways. All points
worth considering but I still think forking the two implementations
for now may be cleaner in the short term while we evolve our manifests.

Dan

> 
> https://review.openstack.org/#/c/180833/
> 
> > Any conversion code in Puppet (functions using split, downcase, etc) I
> > view as technical debt which should ideally we would eventually be able
> > to convert within the Heat templates themselves into formats usable by
> > Hiera directly. Any duplication around that sort of thing would
> > eventually get cleaned up as Heat gets an extra function or two.
> 
> FWIW, I do agree with the longish-term plan, most of the duplicated code 
> *should go away when some more string manipulation can be covered by 
> heat* but I still think that will be some of it, not all and yet this 
> isn't the case today (and I don't know when it will be honestly)
> 
> I think a split will still be worth some duplication when we will start 
> supporting *multiple controllers without pacemaker* as well, today not 
> so much
> 
> on the other hand, we can very well get rid of the ifs today by 
> deploying *with* pacemaker in single node scenario as well! we already 
> have EnablePacemaker always set to true for dev purposes, even on single 
> node

EnablePacemaker is set to 'false' by default. IMO it should be opt-in:

http://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=1f7426a014f0f83ace4d2b3531014e22f7778b4d

Dan




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

Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

[Fox, Kevin M]

So... rabbit is not multitenant I think. You share a rabbit across multiple 
tenants's vms? How do you protect one tenant's vm's from getting commands sent 
to it by another tenant?

Thanks,
Kevin

From: Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com]
Sent: Thursday, May 07, 2015 9:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

Hi,

When we use Murano in production there is a MQ service which is running on 
OpenStack controllers but it listens on public interface. It means that both 
Murano which is running on OpenStack controllers and Agent on VMs have an 
access to this MQ via external (public) network.
When Murano creates a new deployment it actually deploys a private network and 
attach it to the router which acts as a gateway to external networking. So it 
is specific application deployment topology which allows VMs to communicate 
with MA via external network.

Thanks
Gosha

On Thu, May 7, 2015 at 1:28 AM, Filip Blaha 
mailto:filip.bl...@hp.com>> wrote:
yes. I agree that direction is important from only networking piont of view. 
Usually is more probable that VM on neutron network will be able to access O~S 
service ( VM --> rabbit) then opposite direction from O~S service to VM running 
on neutron network (mistral --> VM).

Filip



On 05/06/2015 06:39 PM, Georgy Okrokvertskhov wrote:
Connection direction here is important only in the frame of networking 
connectivity problem solving. The networking in OpenStack in general works in 
such a way so that connections from VM are allowed to almost anywhere. In 
Murano production deployment we use separate MQ instance so that VMs have no 
access to OpenStack MQ.

In the sense who initiates task execution it always a Murano service which 
publishes tasks (shell script + necessary files) in the MQ so that agent can 
pull them and execute.

Thanks
Gosha



On Wed, May 6, 2015 at 9:31 AM, Filip Blaha 
mailto:filip.bl...@hp.com>> wrote:
Hello

one more note on that. There is difference in direction who initiates 
connection. In case of murano agent --> rabbit MQ is connection initiated from 
VM to openstack service(rabbit). In case of std.ssh mistral action is direction 
opposite from openstack service (mistral) to ssh server on VM.

Filip


On 05/06/2015 06:00 PM, Pospisil, Radek wrote:
Hello,

I think that the generic question is - can be O~S services also accessible on 
Neutron networks, so VM (created by Nova) can access it? We (I and Filip) were 
discussing this today and we were not make a final decision.
Another example is Murano agent running on VMs - it connects to RabbitMQ which 
is also accessed by Murano engine

   Regards,

Radek

-Original Message-
From: Blaha, Filip
Sent: Wednesday, May 06, 2015 5:43 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action

Hello

We are considering implementing  actions on services of a murano environment 
via mistral workflows. We are considering whether mistral std.ssh action could 
be used to run some command on an instance. Example of such action in murano 
could be restart action on Mysql DB service.
Mistral workflow would ssh to that instance running Mysql and run "service 
mysql restart". From my point of view trying to use SSH to access instances 
from mistral workflow is not good idea but I would like to confirm it.

The biggest problem I see there is openstack networking. Mistral service 
running on some openstack node would not be able to access instance via its 
fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from 
namespace of its gateway router e.g. "ip netns exec qrouter-... ssh 
cirros@10.0.0.5" but I think it is not good to rely on 
implementation detail of  neutron and use it. In multinode openstack deployment 
it could be even more complicated.

In other words I am asking whether we can use std.ssh mistral action to access 
instances via ssh on theirs fixed IPs? I think no but I would like to confirm 
it.

Thanks
Filip

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

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




__
OpenStack Development Mailing List 

Re: [openstack-dev] [Ceilometer][Gnocchi] How to try ceilometer with gnocchi ?

[Chris Dent]

On Thu, 7 May 2015, Tim Bell wrote:


Thanks... are the dependencies only in ceilometer (i.e. could we
upgrade to Kilo ceilometer with Gnocchi) and keep the rest of the
cloud at Juno ? It'll be a while before our cloud gets to Kilo but
we'd really like to have metering at scale... we can do a test set up
but this would not be addressing the production challenges.


You might try gnocchi in a virtualenv or gnocchi plus ceilometer in
a virtualenv so that their dependencies are not fighting with
anything else (or just all that stuff on its own host, of course).

There's a dispatcher for ceilometer to put data into gnocchi, but that
dispatcher is in the gnocchi code base (for now, it's going to move at
some point in the future). That's where you might encounter issues.

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

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

Re: [openstack-dev] [TaskFlow]Create Tables for SQLAlchemy backend issue

[Joshua Harlow]

No problem,

Probably more DKIM/SPF... issues (oh well, I give up on resolving that 
stuff anymore...) causing emails to go in weird places (aka your spam 
folder)...


Feel free to jump on IRC to:

irc://chat.freenode.net/openstack-state-management

-Josh

jeffty wrote:


  Thanks Josh. I run that and it works. Tables were created
  successfully. Also if I create table, foreign keys and index that also
  work. Except for table alembic_version. Seems taskflow works well
  without this table.


It's wired that my gmail didn't receive ur response and I have to go to
the mailing list archive page to find my post and reply.

Thanks again for your kindly help.


  [openstack-dev] [TaskFlow]Create Tables for SQLAlchemy backend issue

*Joshua Harlow*harlowja at outlook.com

/Wed May 6 05:37:06 UTC 2015/

  * Previous message: [openstack-dev] [TaskFlow]Create Tables for
SQLAlchemy backend issue

  * Next message: [openstack-dev] [Fuel] Swagger documentation

  * *Messages sorted by:* [ date ]


[ thread ]


[ subject ]


[ author ]





Good question!

U have to call into the following:

http://docs.openstack.org/developer/taskflow/persistence.html#taskflow.persistence.base.Connection.upgrade

This is getting renamed (hopefully to a more obvious name) in the
following review:https://review.openstack.org/#/c/180351/  (others got
confused by this one also).

https://blueprints.launchpad.net/taskflow/+spec/storage-initialize-instead-of-upgrade

Hope that helps,

-Josh

jeffty wrote:

/  Hi there,

/>/
/>/  I’m trying to use mysql to store lobbooks and atom etc.
/>/
/>/  Here is the code:
/>/
/>/  backend = backends.fetch({
/>/
/>/  'connection':'mysql://test:test@192.168.1.10/test',
/>/
/>/  'user': test,
/>/
/>/  'password': test,
/>/
/>/  })
/>/
/>/  book, flow_detail = pu.temporary_flow_detail(backend=backend)
/>/
/>/  And I got below errors:
/>/
/>/  taskflow.exceptions.StorageFailure: Failed saving logbook
/>/  'e34f21c0-72cf-48be-ad96-766befa55ab3'
/>/
/>/  ProgrammingError: (ProgrammingError) (1146,"Table'flow.logbooks'
/>/  doesn't exist")'SELECT logbooks.created_at, logbooks.updated_at,
/>/  logbooks.meta,logbooks.name  , logbooks.uuid \nFROM 
logbooks \nWHERE
/>/  logbooks.uuid = %s'  ('e34f21c0-72cf-48be-ad96-766befa55ab3',)
/>/
/>/  After checked
/>/  http://docs.openstack.org/developer/taskflow/persistence.html  , there
/>/  are 3 tables to be created.
/>/
/>/  So we need to create these tables manually right? Or is there any API
/>/  for the tables initiation?
/>/
/>/  Thanks.
/>/
/>/  __
/>/  OpenStack Development Mailing List (not for usage questions)
/>/  Unsubscribe:OpenStack-dev-request at lists.openstack.org  
?subject:unsubscribe
/>/  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev/


2015-05-06 13:14 GMT+08:00 jeffty mailto:wantwater...@gmail.com>>:

Hi there,

__ __

I’m trying to use mysql to store lobbooks and atom etc.

__ __

Here is the code:

__ __

backend = backends.fetch({

'connection': 'mysql://test:test@192.168.1.10/test
',

'user': test,

'password': test,

})

__ __

book, flow_detail = pu.temporary_flow_detail(backend=backend)

__ __

And I got below errors:

__ __

taskflow.exceptions.StorageFailure: Failed saving logbook
'e34f21c0-72cf-48be-ad96-766befa55ab3'

   ProgrammingError: (ProgrammingError) (1146, "Table
'flow.logbooks' doesn't exist") 'SELECT logbooks.created_at,
logbooks.updated_at, logbooks.meta, logbooks.name
, logbooks.uuid \nFROM logbooks \nWHERE
logbooks.uuid = %s' ('e34f21c0-72cf-48be-ad96-766befa55ab3',)

__ __

After checked
http://docs.openstack.org/developer/taskflow/persistence.html ,
there are 3 tables to be created.

__ __

So we need to create these tables manually right? Or is there any
API for the tables initiation?

__ __

Thanks.




_

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

[Dan Prince]

On Thu, 2015-05-07 at 10:42 -0400, Emilien Macchi wrote:
> 
> On 05/06/2015 10:32 PM, Dan Prince wrote:
> (...)
> > 
> > I think this split is a good compromise and would probably even speed up
> > the implementation of the remaining pacemaker features too. And removing
> > all the pacemaker conditionals we have from the non-pacemaker version
> > puts us back in a reasonably clean state I think.
> > 
> 
> I don't really like having a "fork" of the controller code, which could
> become pain to maintain. (ie: each new feature on controllers has to be
> coded in both manifests).

I wouldn't say the fork is ideal. But I do like it better than having
one big unreadable manifest. Keep in mind the Heat templates for both
implementations are mostly shared... so I think it is a reasonable
compromise to keep the code cleaner than it is with inline conditionals
for all pacemaker services.

This wasn't something that was planned... rather it just evolved. And
now actually seeing the pacemaker stuff I'd like to isolate it entirely
from the non-pacemaker implementation. If down the road we get a wrapper
and can cleanly de-duplicate some things then so be it.


> 
> I really prefer having parameters & Hiera in the party to enable or not
> Pacemaker.
> 
> FWIW, here is how we did in SpinalStack:
> 
> 1) Install Pacemaker / Corosync:
> https://github.com/stackforge/puppet-openstack-cloud/blob/master/manifests/clustering.pp
> 
> 2) Create a wrapper to manage resources:
> https://github.com/stackforge/puppet-openstack-cloud/blob/master/manifests/clustering/pacemaker_service.pp
> (that use collocation and order wrappers too)
> 
> 3) Example for Nova API: disable Pacemaker by default:
> https://github.com/stackforge/puppet-openstack-cloud/blob/master/manifests/compute/api.pp#L74
> 
> 4) Since puppet-openstack_extras manage the service in the catalog with
> Pacemaker, the code is the same for Pacemaker / non-pacemaker usage:
> https://github.com/stackforge/puppet-openstack-cloud/blob/master/manifests/compute/api.pp#L81-L90
> 
> 5) If pacemaker is enabled (yes, we have a condition...): we enable the
> resource:
> https://github.com/stackforge/puppet-openstack-cloud/blob/master/manifests/compute/api.pp#L81-L90
> 
> 
> The pacemaker wrapper is
> https://github.com/stackforge/puppet-openstack_extras/blob/master/manifests/pacemaker/service.pp
> so 100% upstream.
> We are using puppetlabs-corosync and not puppet-pacemaker so the code is
> much cleaner and Puppetish (providers, etc).
> The code is really lightweight in the composition layer and flexible to
> add more options easily.
> 
> We are using puppet-pacemaker now, so we can't (now at least) use
> openstack_extras wrapper, but still we can take this approach in
> consideration.

Right. I think this is the rub. puppet-pacemaker doesn't support the
wrapper. And for whatever reason we have choosen to use it instead of
the corosync based version. This is why we've ended up where we are at
today.

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



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

Re: [openstack-dev] [Ceilometer][Gnocchi] How to try ceilometer with gnocchi ?

[Tim Bell]

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: 07 May 2015 17:42
> To: Tim Bell
> Cc: OpenStack Development Mailing List (not for usage questions); Luo Gangyi
> Subject: Re: [openstack-dev] [Ceilometer][Gnocchi] How to try ceilometer with
> gnocchi ?
> 
> On Wed, May 06 2015, Tim Bell wrote:
> 
> > Sorry to add another question, can Gnocchi be installed on a Juno
> > cloud or do we need to be running Kilo ?
> 
> Considering the dependency of Gnocchi, I've little hope it'd work with Juno.
> 

Thanks... are the dependencies only in ceilometer (i.e. could we upgrade to 
Kilo ceilometer with Gnocchi) and keep the rest of the cloud at Juno ? It'll be 
a while before our cloud gets to Kilo but we'd really like to have metering at 
scale... we can do a test set up but this would not be addressing the 
production challenges.

Tim

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

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

Re: [openstack-dev] [oslo] Adding Mehdi Abaakouk (sileht) to oslo-core

[Boris Pavlovic]

+1!

On Thu, May 7, 2015 at 7:24 PM, Mike Bayer  wrote:

>
>
> On 5/7/15 11:01 AM, Joshua Harlow wrote:
>
>> +1 for Mehdi, hooray to that!
>>
>> http://gph.is/19n19VQ (haha),
>>
>> -Josh
>>
>
>
> +1, welcome aboard
>
>
>
>
>> ozamiatin wrote:
>>
>>> +1 for adding Mehdi to oslo-core!
>>>
>>> Thanks,
>>> Oleksii Zamiatin
>>>
>>> 07.05.15 17:36, Davanum Srinivas пишет:
>>>
 Dear Oslo folks,

 I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already
 leading the oslo.messaging team and helping with Tooz, and futurist
 efforts.

 I am hoping to get Mehdi more involved across the board in Oslo.

 Thanks,
 Dims


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

Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Sean Dague]

On 05/07/2015 12:51 PM, Boris Pavlovic wrote:
> Hi stackers, 
> 
> Recently was merged patch that removes Heat from list of service that
> are installed by default DevStack 
> 
> Please next time make sure that all PTL of all projects in OpenStack
> know about such big not backward compatible changes. 
> 
> P.S This change paralyzed work on Rally for 2 days. =( 

This should in no way impact gate jobs, they should all be explicitly
setting service lists themselves for their environments. The ensure
devstack-gate model is built around that. If they are not, then that is
a bug in how they were built.

This has also been a long time coming, we merged the direction patch for
this in Feb in the FUTURE.rst document.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

[Dan Prince]

On Thu, 2015-05-07 at 10:26 -0400, Jay Dobies wrote:
> >>> Something like this:
> >>>
> >>> https://review.openstack.org/#/c/180833/
> 
> I'm not convinced this is a good user experience though. You have 
> configuration effectively in two places. If you want to enable Galera, 
> or enable ceph storage, it's a parameter. But not pacemaker. To enable 
> that, you have to look in the resource registry instead.

I'm not sure there is a better way to architect it that doesn't use the
resource registry. Heat doesn't support get_file: {get_param:
ManifestName} so we can't dynamically select an alternate template via a
parameter either.

We enable Puppet by changing the resource registry. Additionally, it is
very likely other things (network architecture related) are going to
make heavy use of the resource registry as well.

Yes, it is different from some of the other feature parameters... but I
think that is probably okay. In this regard maybe pacemaker is more of
an overlay rather than something you just enable via a parameter.

Dan

> 
> >
> >> I have two mild concerns about this approach:
> >>
> >> 1) We'd duplicate the logic (or at least the inclusion logic) for the
> >> common parts in two places, making it prone for the two .pp variants to
> >> get out of sync. The default switches from "if i want to make a
> >> difference between the two variants, i need to put in a conditional" to
> >> "if i want to *not* make a difference between the two variants, i need
> >> to put this / include this in two places".
> >
> > The goal for these manifests is that we would just be doing 'include's
> > for various stackforge puppet modules. If we have
> > 'include ::glance::api' in two places that doesn't really bother me.
> > Agree that it isn't ideal but I don't think it bothers me too much. And
> > the benefit is we can get rid of pacemaker conditionals for all the
> > things.
> >
> >>
> >> 2) If we see some other bit emerging in the future, which would be
> >> optional but at the same time "omnipresent" in a similar way as
> >> Pacemaker is, we'll see the same if/else pattern popping up. Using the
> >> same solution would mean we'd have 4 .pp files (a 2x2 matrix) doing the
> >> same thing to cover all scenarios. This is a somewhat hypothetical
> >> concern at this point, but it might become real in the future (?).
> >
> > Sure. It could happen. But again maintaining all of those in a single
> > file could be quite a mess too. And if we are striving to set all or our
> > Hiera data in Heat (avoiding use of some of the puppet functions we now
> > make use of like split, etc) this would further de-duplicate it I think.
> >
> > Again having duplication that includes just the raw puppet classes
> > doesn't bother me too much.
> >
> >>
> >>>
> >>> If we were to split out the controller into two separate templates I
> >>> think it might be appropriate to move a few things into puppet-tripleo
> >>> to de-duplicate a bit. Things like the database creation for example.
> >>> But probably not all of the services... because we are trying as much as
> >>> possible to use the stackforge puppet modules directly (and not our own
> >>> composition layer).
> >>
> >> I think our restraint from having a composition layer (extracting things
> >> into puppet-tripleo) is what's behind my concern no. 1 above. I know one
> >> of the arguments against having a composition layer is that it makes
> >> things less hackable, but if we could amend puppet modules without
> >> rebuilding or altering the image, it should mitigate the problem a bit
> >> [1]. (It's almost a matter that would deserve a separate thread though :) )
> >>
> >>>
> >>> I think this split is a good compromise and would probably even speed up
> >>> the implementation of the remaining pacemaker features too. And removing
> >>> all the pacemaker conditionals we have from the non-pacemaker version
> >>> puts us back in a reasonably clean state I think.
> >>>
> >>> Dan
> >>>
> >>
> >> An alternative approach could be something like:
> >>
> >> if hiera('step') >= 2 {
> >>   include ::tripleo::mongodb
> >> }
> >>
> >> and move all the mongodb related logic to that class and let it deal
> >> with both pacemaker and non-pacemaker use cases. This would reduce the
> >> stress on the top-level .pp significantly, and we'd keep things
> >> contained in logical units. The extracted bits will still have
> >> conditionals but it's going to be more manageable because the bits will
> >> be a lot smaller. So this would mean splitting up the manifest per
> >> service rather than based on pacemaker on/off status. This would require
> >> more extraction into puppet-tripleo though, so it kinda goes against the
> >> idea of not having a composition layer. It would also probably consume a
> >> bit more time to implement initially and be more disruptive to the
> >> current state of things.
> >>
> >> At this point i don't lean strongly towards one or the other solution, i
> >> just want us to have an o

[openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that

[Boris Pavlovic]

Hi stackers,

Recently was merged patch that removes Heat from list of service that are
installed by default DevStack

Please next time make sure that all PTL of all projects in OpenStack know
about such big not backward compatible changes.

P.S This change paralyzed work on Rally for 2 days. =(


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

[openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net

[Chris St. Pierre]

This bug recently came to my attention:
https://bugs.launchpad.net/nova/+bug/1241587

I've reopened it, because it is an actual problem, especially for people
using nova-network and Rally, which creates and deletes tons of tenants.

The obvious simple solution is to allow deletion of the 'default' security
group if it is assigned to a tenant that doesn't exist, but I wasn't sure
what the most acceptable way to do that within Nova would be. Is it
acceptable to perform a call to the Keystone API to check for the tenant?
Or is there another, better way?

Alternatively, is there a better way to tackle the problem altogether?

Thanks!

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

Re: [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI

[Vitaly Kramskikh]

Samuel,

There are plans to solve this:

1) Add a flag/field to control declaration so it can have multiple values:

  ntp_list:
*multiple_values: true*
value:
  - "1.1.1.1"
  - "2.2.2.2"
label: "NTP server list"
description: "List of upstream NTP servers"
type: "text"

Now we use one input with comma-separated values to enter DNS and NTP
servers which is hacky. This proposal with also solve your issue, but won't
help for Simon's case (as there are groups of 2 fields).

2) For complex controls we plan to implement support for JS parts of plugins
, so you can
implement configuration UI of any complexity by providing custom JS.
repo_setup control in 6.1 is a great example of a complex control.

For 6.1 I suggest you to use current DNS/NTP approach (comma separated
values) or Simon's approach (though I'd use action: hide instead of action:
disable)


2015-05-07 17:36 GMT+03:00 Simon Pasquier :

> Hello Samuel,
> As far as I know, this isn't possible unfortunately. For our own needs, we
> ended up adding a fixed-size list with all items but the first one
> disabled. When you enter something in the first input box, it enabled the
> second box and so on (see [1]). In any case, this would be a good
> addition...
> BR,
> Simon
> [1]
> https://github.com/stackforge/fuel-plugin-elasticsearch-kibana/blob/master/environment_config.yaml#L21
>
> On Thu, May 7, 2015 at 3:37 PM, Samuel Bartel  > wrote:
>
>> Hi all,
>>
>>
>>
>> I am working on two plugins for fuel : logrotate and cinder-netapp (to
>> add multibackend feature)
>>
>> In this two plugins I face the same problem. Is it possible in the
>> environment yaml config describing the fields to display for the plugin in
>> the UI to have some dynamic element.
>>
>> I explain my need. I would like to be able to add additional element by
>> clicking on a “+” button as the IP range for network tab in order to be
>> able to:
>>
>> -add new log file to manage for the logrorate instead of having a static
>> list
>>
>> -add extra netapp filer/volume instead ofbeing able to setup only one for
>> the cinder netapp in a multibackend scope.
>>
>> For the cinder netapp for example, I would be able to access to the
>> netapp server hostname with:
>>
>> $::fuel_settings[‘cinder_netapp’][0][‘netapp_server_hostname’]  #for the
>> first one
>>
>> $::fuel_settings[‘cinder_netapp’][1][‘netapp_server_hostname’]  #for the
>> second  one
>>
>> And so on.
>>
>>
>>
>> Can we do that with the actual plugin feature.  If not is it planned to
>> add such a feature?
>>
>>
>>
>> Regards,
>>
>>
>> Samuel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?

[David Medberry]

If you need a local guy to go twist Jon Corbets arm, there are plenty of us
within arms/cars reach. I think this would be the best possible outcome.

Although LWN is primarily subscriber funded, realize that many of those
subscribers are corporate subscribers that provide access to all their
employees. Having "corporate subscribers" in addition to the OpenStack
Foundation is probably key.

I'm not privy to their detailed business model, but that's my experience
and present understanding.

On Wed, May 6, 2015 at 7:13 PM, Hugh Blemings  wrote:

> On 6/05/2015 23:34, James Bottomley wrote:
>
>> On Wed, 2015-05-06 at 11:54 +0200, Thierry Carrez wrote:
>>
>>> Hugh Blemings wrote:
>>>
 +2

 I think asking LWN if they have the bandwidth and interest to do this
 would be ideal - they've credibility in the Free/Open Source space and a
 proven track record.  Nice people too.

>>>
>>> On the bandwidth side, as a regular reader I was under the impression
>>> that they struggled with their load already, but I guess if it comes
>>> with funding that could be an option.
>>>
>>> On the interest side, my past tries to invite them to the OpenStack
>>> Summit so that they could cover it (the way they cover other
>>> conferences) were rejected, so I have doubts in that area as well.
>>>
>>> Anyone having a personal connection that we could leverage to pursue
>>> that option further ?
>>>
>>
>> Sure, be glad to.
>>
>> I've added Jon to the cc list (if his openstack mail sorting scripts
>> operate like mine, that will get his attention).
>>
>> I already had a preliminary discussion with him: lwn.net is interested
>> but would need to hire an extra person to cover the added load.  That
>> makes it quite a big business investment for them.
>>
>
> Excellent - I think Jon and Co. could bring a great deal to the table here
> and if that means finding a way to provide funding that would be effort
> well spent.
>
> Cheers,
> Hugh
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TaskFlow]Create Tables for SQLAlchemy backend issue

[jeffty]

Thanks Josh. I run that and it works. Tables were created successfully.
Also if I create table, foreign keys and index that also work. Except for
table alembic_version. Seems taskflow works well without this table.

It's wired that my gmail didn't receive ur response and I have to go to the
mailing list archive page to find my post and reply.

Thanks again for your kindly help.

[openstack-dev] [TaskFlow]Create Tables for SQLAlchemy backend issue*Joshua
Harlow* harlowja at outlook.com

*Wed May 6 05:37:06 UTC 2015*


   - Previous message: [openstack-dev] [TaskFlow]Create Tables for
   SQLAlchemy backend issue
   
   - Next message: [openstack-dev] [Fuel] Swagger documentation
   
   - *Messages sorted by:* [ date ]
   
[ thread ]
   

[ subject ]
   

[ author ]
   


--

Good question!

U have to call into the following:
http://docs.openstack.org/developer/taskflow/persistence.html#taskflow.persistence.base.Connection.upgrade

This is getting renamed (hopefully to a more obvious name) in the
following review: https://review.openstack.org/#/c/180351/ (others got
confused by this one also).
https://blueprints.launchpad.net/taskflow/+spec/storage-initialize-instead-of-upgrade

Hope that helps,

-Josh

jeffty wrote:
>* Hi there,
*>>* I’m trying to use mysql to store lobbooks and atom etc.
*>>* Here is the code:
*>>* backend = backends.fetch({
*>>* 'connection': 'mysql://test:test@192.168.1.10/test
',
*>>* 'user': test,
*>>* 'password': test,
*>>* })
*>>* book, flow_detail = pu.temporary_flow_detail(backend=backend)
*>>* And I got below errors:
*>>* taskflow.exceptions.StorageFailure: Failed saving logbook
*>* 'e34f21c0-72cf-48be-ad96-766befa55ab3'
*>>* ProgrammingError: (ProgrammingError) (1146, "Table 'flow.logbooks'
*>* doesn't exist") 'SELECT logbooks.created_at, logbooks.updated_at,
*>* logbooks.meta, logbooks.name , logbooks.uuid
\nFROM logbooks \nWHERE
*>* logbooks.uuid = %s' ('e34f21c0-72cf-48be-ad96-766befa55ab3',)
*>>* After checked
*>* http://docs.openstack.org/developer/taskflow/persistence.html
 ,
there
*>* are 3 tables to be created.
*>>* So we need to create these tables manually right? Or is there any API
*>* for the tables initiation?
*>>* Thanks.
*>>* __
*>* OpenStack Development Mailing List (not for usage questions)
*>* Unsubscribe: OpenStack-dev-request at lists.openstack.org
?subject:unsubscribe
*>* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
*


2015-05-06 13:14 GMT+08:00 jeffty :

> Hi there,
>
>
>
> I’m trying to use mysql to store lobbooks and atom etc.
>
>
>
> Here is the code:
>
>
>
> backend = backends.fetch({
>
> 'connection': 'mysql://test:test@192.168.1.10/test',
>
> 'user': test,
>
> 'password': test,
>
> })
>
>
>
> book, flow_detail = pu.temporary_flow_detail(backend=backend)
>
>
>
> And I got below errors:
>
>
>
> taskflow.exceptions.StorageFailure: Failed saving logbook
> 'e34f21c0-72cf-48be-ad96-766befa55ab3'
>
>   ProgrammingError: (ProgrammingError) (1146, "Table 'flow.logbooks'
> doesn't exist") 'SELECT logbooks.created_at, logbooks.updated_at,
> logbooks.meta, logbooks.name, logbooks.uuid \nFROM logbooks \nWHERE
> logbooks.uuid = %s' ('e34f21c0-72cf-48be-ad96-766befa55ab3',)
>
>
>
> After checked
> http://docs.openstack.org/developer/taskflow/persistence.html , there are
> 3 tables to be created.
>
>
>
> So we need to create these tables manually right? Or is there any API for
> the tables initiation?
>
>
>
> Thanks.
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Ceph software version in next releases

[Dmitry Borodaenko]

Kamil,

Thanks for reminding us about that blueprint, we're definitely
considering Hammer and as soon as we have enough confidence in its
stability we'll integrate it into 7.0. I'll check with our Ceph team
to make sure they update the blueprint to refer to Hammer instead of
Giant.

We already have Ceph 0.80.9 packaged for 6.1:
http://mirror.fuel-infra.org/fwm/6.1/ubuntu/pool/main/c/ceph/

-DmitryB


On Thu, May 7, 2015 at 3:12 AM, Rogon, Kamil  wrote:
> Hello,
>
>
>
> I would like to ask what Ceph versions are scheduled for next releases.
>
>
>
> I see the blueprint [1] for upgrading to next stable release (from Firefly
> to Giant), but it is still in drafting state.
>
> That upgrade is important for Fuel 7.0 release, as this introduces a lot of
> improvements in case of flash backends which is essential nowadays.
>
> I think you should consider next Ceph version (Hammer) as this is marked as
> LTS and should supersede 0.80.x Firefly. What’s more this is already lunched
> [2].
>
>
>
> Regarding the upcoming 6.0.1 / 6.1 release I understand that you are stick
> with Firefly branch. However will it be updated from 0.80.7 to 0.80.9? It
> fixes some performance regression in librbd [3].
>
>
>
> [1] https://blueprints.launchpad.net/fuel/+spec/upgrade-ceph
>
> [2] http://ceph.com/docs/next/releases/
>
> [3] http://docs.ceph.com/docs/next/release-notes/#v0-80-9-firefly
>
>
>
>
>
> Regards,
>
> Kamil Rogon
>
> 
>
> Intel Technology Poland sp. z o.o.
> KRS 101882
> ul. Slowackiego 173
> 80-298 Gdansk
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dmitry Borodaenko

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

[openstack-dev] Re: [oslo] Adding Mehdi Abaakouk (sileht) to oslo-core

[Mike Bayer]

On 5/7/15 11:01 AM, Joshua Harlow wrote:

+1 for Mehdi, hooray to that!

http://gph.is/19n19VQ (haha),

-Josh



+1, welcome aboard




ozamiatin wrote:

+1 for adding Mehdi to oslo-core!

Thanks,
Oleksii Zamiatin

07.05.15 17:36, Davanum Srinivas пишет:

Dear Oslo folks,

I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already
leading the oslo.messaging team and helping with Tooz, and futurist
efforts.

I am hoping to get Mehdi more involved across the board in Oslo.

Thanks,
Dims




__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

[Georgy Okrokvertskhov]

Hi,

When we use Murano in production there is a MQ service which is running on
OpenStack controllers but it listens on public interface. It means that
both Murano which is running on OpenStack controllers and Agent on VMs have
an access to this MQ via external (public) network.
When Murano creates a new deployment it actually deploys a private network
and attach it to the router which acts as a gateway to external networking.
So it is specific application deployment topology which allows VMs to
communicate with MA via external network.

Thanks
Gosha

On Thu, May 7, 2015 at 1:28 AM, Filip Blaha  wrote:

>  yes. I agree that direction is important from only networking piont of
> view. Usually is more probable that VM on neutron network will be able to
> access O~S service ( VM --> rabbit) then opposite direction from O~S
> service to VM running on neutron network (mistral --> VM).
>
> Filip
>
>
>
> On 05/06/2015 06:39 PM, Georgy Okrokvertskhov wrote:
>
>   Connection direction here is important only in the frame of networking
> connectivity problem solving. The networking in OpenStack in general works
> in such a way so that connections from VM are allowed to almost anywhere.
> In Murano production deployment we use separate MQ instance so that VMs
> have no access to OpenStack MQ.
>
>  In the sense who initiates task execution it always a Murano service
> which publishes tasks (shell script + necessary files) in the MQ so that
> agent can pull them and execute.
>
>  Thanks
>  Gosha
>
>
>
> On Wed, May 6, 2015 at 9:31 AM, Filip Blaha  wrote:
>
>> Hello
>>
>> one more note on that. There is difference in direction who initiates
>> connection. In case of murano agent --> rabbit MQ is connection initiated
>> from VM to openstack service(rabbit). In case of std.ssh mistral action is
>> direction opposite from openstack service (mistral) to ssh server on VM.
>>
>> Filip
>>
>>
>> On 05/06/2015 06:00 PM, Pospisil, Radek wrote:
>>
>>> Hello,
>>>
>>> I think that the generic question is - can be O~S services also
>>> accessible on Neutron networks, so VM (created by Nova) can access it? We
>>> (I and Filip) were discussing this today and we were not make a final
>>> decision.
>>> Another example is Murano agent running on VMs - it connects to RabbitMQ
>>> which is also accessed by Murano engine
>>>
>>>Regards,
>>>
>>> Radek
>>>
>>> -Original Message-
>>> From: Blaha, Filip
>>> Sent: Wednesday, May 06, 2015 5:43 PM
>>> To: openstack-dev@lists.openstack.org
>>> Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action
>>>
>>> Hello
>>>
>>> We are considering implementing  actions on services of a murano
>>> environment via mistral workflows. We are considering whether mistral
>>> std.ssh action could be used to run some command on an instance. Example of
>>> such action in murano could be restart action on Mysql DB service.
>>> Mistral workflow would ssh to that instance running Mysql and run
>>> "service mysql restart". From my point of view trying to use SSH to access
>>> instances from mistral workflow is not good idea but I would like to
>>> confirm it.
>>>
>>> The biggest problem I see there is openstack networking. Mistral service
>>> running on some openstack node would not be able to access instance via its
>>> fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from
>>> namespace of its gateway router e.g. "ip netns exec qrouter-... ssh
>>> cirros@10.0.0.5" but I think it is not good to rely on implementation
>>> detail of  neutron and use it. In multinode openstack deployment it could
>>> be even more complicated.
>>>
>>> In other words I am asking whether we can use std.ssh mistral action to
>>> access instances via ssh on theirs fixed IPs? I think no but I would like
>>> to confirm it.
>>>
>>> Thanks
>>> Filip
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
>  Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
>
> __
> OpenStack

Re: [openstack-dev] [chef] Feedback to move IRC Monday meeting and time.

[JJ Asghar]

> On May 6, 2015, at 11:33 PM, Samuel Cassiba  wrote:
> 
> This has actually caused a situation that I’d like to make public. In the 
> documentation the times for the meetings are suggested at the top of the 
> hour, we have ours that start at :30 past. This allows for our friends and 
> community members on the west coast of the United States able to join at a 
> pseudo-reasonable time.  The challenge is, if we move it forward to the top 
> of the hour, we may lose the west coast, but if we move it back to the top of 
> the next hour we may lose our friends in Germany and earlier time zones.
> 
> Moving it to the top of the hour would still fall in the realm of 
> pseudo-reasonable, as reasonable as meetings in that timeframe can be. 0800 
> is more reasonable than 0730. ;-)
> 
> By doing that, it would allow the group to remain as inclusive as possible, 
> while still allowing time for commutes for us west coasters.
> 

Awesome! Yeah so it looks like we’ve gotten some positive feedback about moving 
the meeting to 1600GMT. We’ll discuss it and ideally make it official on 
Monday, and it’s already added to the agenda[1].


-JJ

[1]: https://etherpad.openstack.org/p/openstack-chef-meeting-20150511 

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

Re: [openstack-dev] [oslo] Adding Mehdi Abaakouk (sileht) to oslo-core

[Flavio Percoco]

On 07/05/15 10:36 -0400, Davanum Srinivas wrote:

Dear Oslo folks,

I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already
leading the oslo.messaging team and helping with Tooz, and futurist
efforts.

I am hoping to get Mehdi more involved across the board in Oslo.


#@!$@#$ yeah! +1!

--
@flaper87
Flavio Percoco


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

[openstack-dev] [cinder] Liberty Midcycle Meetup

[Mike Perez]

Survey: https://www.surveymonkey.com/s/6QRKV6Z

This will determine, when, where and get a rough count.

We will review the results in the next Cinder Meeting [1], which is
2015-05-16 at 16:00 UTC on #openstack-meeting

[1] - https://wiki.openstack.org/wiki/CinderMeetings

--
Mike Perez

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

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

[Giulio Fidente]

On 05/07/2015 05:36 PM, Giulio Fidente wrote:

On 05/07/2015 03:31 PM, Dan Prince wrote:

On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:


[...]


and there are quite a lot of similar examples, the change from marios as
well, ended up duplicating lots of code:

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


here I should have linked this change instead:

https://review.openstack.org/#/c/181015/1

from marios, built on your first
--
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [oslo] Adding Mehdi Abaakouk (sileht) to oslo-core

[Julien Danjou]

On Thu, May 07 2015, Davanum Srinivas wrote:

> I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already
> leading the oslo.messaging team and helping with Tooz, and futurist
> efforts.
>
> I am hoping to get Mehdi more involved across the board in Oslo.

+1 of course!

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


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

Re: [openstack-dev] [Murano] Murano projects pylint job

[Filip Blaha]

Hello

pylint job was merged. At first we focused on refactor class code 
issues. Test patch set with code duplication [1]. If you have any 
suggestions about the job and code checks feel free to contact me.


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

Regards
Filip




On 04/02/2015 10:56 AM, Ekaterina Chernova wrote:

Hi Filip and Serg!

I support the idea!

Let's discuss more details in IRC and summarize everything on the next 
community meeting on Tuesday.


Regards,
Kate.

On Thu, Apr 2, 2015 at 11:31 AM, Filip Blaha > wrote:


Hi Serg

we can inspire in other projects like sahara. Important is that
pylint job should produce reasonable size meaningful output.
Pylint without any configuration produces huge output. So we
should point out which code checks are interesting for us and
configure pylint accordingly. I will do some research on that.

Regards
Filip


On 04/01/2015 05:57 PM, Serg Melikyan wrote:

Hi Filip,

I think adding pylint job to Murano gates is an awesome idea,
have you checked out how to do this?

On Wed, Apr 1, 2015 at 4:03 PM, Filip Blaha mailto:filip.bl...@hp.com>> wrote:

Hello

I have noticed that some openstack projects [1] use pylint
gate job. From my point of view it could simplify code
reviews even as non-voing job and generally it could improve
code quality. Some code issues like code duplication are not
easy to discover during code review so automatic job would be
helpful. Please let me know your opinion about that. Thanks

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

Regards
Filip


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.

http://mirantis.com  |
smelik...@mirantis.com 

+7 (495) 640-4904, 0261
+7 (903) 156-0836


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


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