Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Jiri Tomasek]

On 01/06/2016 11:48 AM, Dougal Matthews wrote:



On 5 January 2016 at 17:09, Jiri Tomasek > wrote:


On 12/23/2015 07:40 PM, Steven Hardy wrote:

On Wed, Dec 23, 2015 at 11:05:05AM -0600, Ben Nemec wrote:

On 12/23/2015 10:26 AM, Steven Hardy wrote:

On Wed, Dec 23, 2015 at 09:28:59AM -0600, Ben Nemec wrote:

On 12/23/2015 03:19 AM, Dougal Matthews wrote:


On 22 December 2015 at 17:59, Ben Nemec

>> wrote:

 Can we just do git like I've been
suggesting all along? ;-)

 More serious discussion inline. :-)

 On 12/22/2015 09:36 AM, Dougal Matthews
wrote:
 > Hi all,
 >
 > This topic came up in the 2015-12-15
meeting[1], and again briefly
 today.
 > After working with the code that came
out of the deployment library
 > spec[2] I
 > had some concerns with how we are
storing the templates.
 >
 > Simply put, when we are dealing with
100+ files from
 tripleo-heat-templates
 > how can we ensure consistency in Swift
without any atomicity or
 > transactions.
 > I think this is best explained with a
couple of examples.
 >
 >  - When we create a new deployment plan
(upload all the templates
 to swift)
 >how do we handle the case where
there is an error? For example,
 if we are
 >uploading 10 files - what do we do
if the 5th one fails for
 some reason?
 >There is a patch to do a manual
rollback[3], but I have
 concerns about
 >doing this in Python. If Swift is
completely inaccessible for a
 short
 >period the rollback wont work either.
 >
 >  - When deploying to Heat, we need to
download all the YAML files from
 > Swift.
 >This can take a couple of seconds.
What happens if somebody
 starts to
 >upload a new version of the plan in
the middle? We could end up
 trying to
 >deploy half old and half new files.
We wouldn't have a
 consistent view of
 >the database.
 >
 > We had a few suggestions in the meeting:
 >
 >  - Add a locking mechanism. I would be
concerned about deadlocks or
 > having to
 >lock for the full duration of a deploy.

 There should be no need to lock the plan
for the entire deploy.  It's
 not like we're re-reading the templates
at the end of the deploy today.
  It's a one-shot read and then the plan
could be unlocked, at least as
 far as I know.


Good point. That would be holding the lock for
longer than we need.

 The only option where we wouldn't need
locking at all is the
 read-copy-update model Clint mentions,
which might be a valid option as
 well.  Whatever we do, there are going to
be concurrency issues though.
  For example, what happens if two users

Re: [openstack-dev] in which function does neutronv2 assign IP address for instance?

[Ihar Hrachyshka]

张晨  wrote:


hi everyone,

i have a question for the neutron code in liberty: how does neutron  
assign IP address for instance?


in nova.network, it seems that neutron sever gets a feasible ip from the  
DB pool, which looks like this:
nova.compute.manager.ComputeVirtAPI._allocate_network_async() ->  
nova.network.api.API.allocate_for_instance() ->  
nova.network.manager.NetworkManager.allocate_for_instance() ->  
nova.network..manager.NetworkManager_allocate_fixed_ips()


but in nova.network.neutronv2.0, It looks like this:
nova.compute.manager.ComputeVirtAPI._allocate_network_async() ->  
neutronv2.api.allocate_for_instance()
and it seems that  in neutronv2.api.allocate_for_instance(), it doesn't  
fetch IP address from DB if the para "fixed_ip" == none in  
allocate_for_instance, but directly calls "_create_port" for a REST API.


so my question is whether neutron server will surely assign a fixed IP  
from DB for instance? Or else, it allows the DHCP agent to take over the  
IP-MAC selection?


Neutron will always pre-allocate a specific address for a port. DHCP  
service does not work with ranges that it manages, but relies on Neutron to  
provide specific mac-to-IP mappings for each port.


Specific IP addresses are allocated for ports by calling to IPAM driver:  
https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/db_base_plugin_v2.py?id=70606fa29a754fba0c1106c6aa722879503fc0a9#n1197


Ihar

__
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] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 5 January 2016 at 17:09, Jiri Tomasek  wrote:

> On 12/23/2015 07:40 PM, Steven Hardy wrote:
>
>> On Wed, Dec 23, 2015 at 11:05:05AM -0600, Ben Nemec wrote:
>>
>>> On 12/23/2015 10:26 AM, Steven Hardy wrote:
>>>
 On Wed, Dec 23, 2015 at 09:28:59AM -0600, Ben Nemec wrote:

> On 12/23/2015 03:19 AM, Dougal Matthews wrote:
>
>>
>> On 22 December 2015 at 17:59, Ben Nemec > > wrote:
>>
>>  Can we just do git like I've been suggesting all along? ;-)
>>
>>  More serious discussion inline. :-)
>>
>>  On 12/22/2015 09:36 AM, Dougal Matthews wrote:
>>  > Hi all,
>>  >
>>  > This topic came up in the 2015-12-15 meeting[1], and again
>> briefly
>>  today.
>>  > After working with the code that came out of the deployment
>> library
>>  > spec[2] I
>>  > had some concerns with how we are storing the templates.
>>  >
>>  > Simply put, when we are dealing with 100+ files from
>>  tripleo-heat-templates
>>  > how can we ensure consistency in Swift without any atomicity or
>>  > transactions.
>>  > I think this is best explained with a couple of examples.
>>  >
>>  >  - When we create a new deployment plan (upload all the
>> templates
>>  to swift)
>>  >how do we handle the case where there is an error? For
>> example,
>>  if we are
>>  >uploading 10 files - what do we do if the 5th one fails for
>>  some reason?
>>  >There is a patch to do a manual rollback[3], but I have
>>  concerns about
>>  >doing this in Python. If Swift is completely inaccessible
>> for a
>>  short
>>  >period the rollback wont work either.
>>  >
>>  >  - When deploying to Heat, we need to download all the YAML
>> files from
>>  > Swift.
>>  >This can take a couple of seconds. What happens if somebody
>>  starts to
>>  >upload a new version of the plan in the middle? We could
>> end up
>>  trying to
>>  >deploy half old and half new files. We wouldn't have a
>>  consistent view of
>>  >the database.
>>  >
>>  > We had a few suggestions in the meeting:
>>  >
>>  >  - Add a locking mechanism. I would be concerned about
>> deadlocks or
>>  > having to
>>  >lock for the full duration of a deploy.
>>
>>  There should be no need to lock the plan for the entire deploy.
>> It's
>>  not like we're re-reading the templates at the end of the deploy
>> today.
>>   It's a one-shot read and then the plan could be unlocked, at
>> least as
>>  far as I know.
>>
>>
>> Good point. That would be holding the lock for longer than we need.
>>
>>  The only option where we wouldn't need locking at all is the
>>  read-copy-update model Clint mentions, which might be a valid
>> option as
>>  well.  Whatever we do, there are going to be concurrency issues
>> though.
>>   For example, what happens if two users try to make updates to
>> the plan
>>  at the same time?  If you don't either merge the changes or
>> disallow one
>>  of them completely then one user's changes might be lost.
>>
>>  TBH, this is further convincing me that we should just make this
>> git
>>  backed and let git handle the merging and conflict resolution
>> (never
>>  mind the fact that it gets us a well-understood version control
>> system
>>  for "free").  For updates that don't conflict with other
>> changes, git
>>  can merge them automatically, but for merge conflicts you just
>> return a
>>  rebase error to the user and make them resolve it.  I have a
>> feeling
>>  this is the behavior we'll converge on eventually anyway, and
>> rather
>>  than reimplement git, let's just use the real thing.
>>
>>
>> I'd be curious to hear more how you would go about doing this with
>> git. I've
>> never automated git to this level, so I am concerned about what
>> issues we
>> might hit.
>>
> TBH I haven't thought it through to that extent yet.  I'm mostly
> suggesting it because it seems like a fit for the template storage
> requirements - we know we want version control, we want to be able to
> merge changes from multiple sources, and we want some way to handle
> merge conflicts.  Git does all of this already.
>
> That said, I'm not sure about everything here.  For example, how would
> you expose merge conflicts to the user?  I don't know that I would want
> to force a user to learn git in 

[openstack-dev] in which function does neutronv2 assign IP address for instance?

[张晨]

hi everyone,


i have a question for the neutron code in liberty: how does neutron assign IP 
address for instance?


in nova.network, it seems that neutron sever gets a feasible ip from the DB 
pool, which looks like this:
nova.compute.manager.ComputeVirtAPI._allocate_network_async() -> 
nova.network.api.API.allocate_for_instance() -> 
nova.network.manager.NetworkManager.allocate_for_instance() -> 
nova.network..manager.NetworkManager_allocate_fixed_ips()


but in nova.network.neutronv2.0, It looks like this:
nova.compute.manager.ComputeVirtAPI._allocate_network_async() -> 
neutronv2.api.allocate_for_instance()
and it seems that  in neutronv2.api.allocate_for_instance(), it doesn't fetch 
IP address from DB if the para "fixed_ip" == none in allocate_for_instance, but 
directly calls "_create_port" for a REST API.


so my question is whether neutron server will surely assign a fixed IP from DB 
for instance? Or else, it allows the DHCP agent to take over the IP-MAC 
selection?





__
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] Client checking of server version

[Jay Dobies]

I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access
older versions of servers (that's a pretty simplistic description; see
[2] for the spec).

Before the holiday, Steve Hardy and I were talking about the
complications involved. In my case, there's no good way to differentiate
an older server from a legitimate error.


Hmmm, it's true that you'll likely just get a 400 error, but I'd hope
that the error message is at least somewhat unique.


Unfortunately, it's not, but I don't think it's due to a Heat problem so 
much as just the nature of the issue. Here's what's happening.


New Client: doesn't do client-side environment resolution before sending 
it to the server.


Old Server: expects the environment to be fully populated and ignores 
the environment file(s) in the files dict.


The result is the server spits back an error saying that, in my 
scenario, there is no type mapping for jdob::Resource1.


The problem is, I get the exact same result for New Client + New Server 
+ incomplete environment files.


The reason I was looking for some sort of version checking is to avoid 
having logic that just says "Maybe it's because it's an old server, 
lemme resolve the environments and send the request again." It feels 
really wrong to trigger two create requests when it's the templates 
themselves that are wrong.



Since the API isn't versioned to the extent that we can leverage that


I mean... it totally is but so far we've chosen not to bump that
version. And we mostly got away with it because we were only adding
functionality. So far.


value, I was looking into using the template versions call. Something
along the lines of:

   supported_versions = hc.template_versions.list()
   version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
   mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of
generalized utility method in the client, under the assumption that
we'll need this sort of check in the future for the same backward
compatibility requirements.

So a few questions:

1. Does anyone strongly disagree to checking supported template versions
as a way of determining the specifics of the server API.


Yes.

Template versions are supposed to be pluggable, and are explicitly under
control of the operator. We shouldn't be systematically inferring
anything about the server version based on this; in general there's no
causal relationship.


2. Does anything like this already exist that I can use?


Not really; there's the "heat build-info" command, but that is also
explicitly under the control of the operator (and is empty by default).


3. If not, any suggestions on where I should put it? I see a
heat.common.utils module but I'm not sure if there is a convention
against that module (or common in general) making live server calls.

Thanks :D


[1] https://review.openstack.org/#/c/239504/
[2] https://review.openstack.org/#/c/226157/

__

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] [doc] DocImpact vs. reno

[Jeremy Stanley]

On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
[...]
> I think auto openning against a project, and shuffling it to
> manuals manually (with details added by humans) would be fine.
> 
> It's not clear to me why a new job was required for that.

The new check job was simply a requirement of the Docs team, since
they were having trouble triaging auto-generated bugs they were
receiving and wanted to enforce the inclusion of some expository
metadata.
-- 
Jeremy Stanley

__
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] proposing Alex Schultz part of core team

[Sebastien Badia]

On Tue, Jan 05, 2016 at 12:55:01PM (-0500), Emilien Macchi wrote:
> Hi,
> 
> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> the last months in the Puppet OpenStack group:
> * He's doing a lot of reviews and they are very valuable. He's in my
> opinion fully aware of our conventions and has nice insights to improve
> our modules.
> * He's very helpful to work on bugs or new features when needed.
> * Always present during meetings and actively participating.
> * Always on IRC, he never hesitates to give a hand on something or help
> people.
> 
> I think we're very lucky to have Alex part of our group and I would like
> to promote him core reviewer of all our modules.
> 
> Team, please vote if you like the idea,

Hi,
A big +1 for me!

Seb

-- 
Sebastien Badia


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] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[AFEK, Ifat (Ifat)]

Hi,

We would like to be notified once an alarm state is changed, so we prefer using 
the message bus. 
As far as I understand, ceilometer and aodh APIs do not provide immediate 
notifications. If we use the APIs, we will have to poll the data periodically 
and look for changes, and we will get them in delay. By listening to the 
message bus we can get the notifications immediately, like we do with other 
openstack components. 

Is there an advantage in using the API instead? 
And what do you mean by "aggregation on events data"? what kind of aggregations 
can we do?

Thanks,
Ifat.

> -Original Message-
> From: liusheng [mailto:liusheng1...@126.com]
> Sent: Wednesday, January 06, 2016 10:10 AM
> 
> Hi Ifat,
> 
> what way do you want to use the alarm change notifications? using
> events from Ceilometer API or directly collecting the notifications
> from message bus?
> if we configure Ceilometer to listen the notifications from aodh, the
> notifications about alarm changes will be converted to events and
> stored in Ceilometer storage. if you want to use the events about alarm
> changes, the same info can be queried by "alarm-history" API, may be
> you want to do aggregation on events data ?
> 
> Thanks
> Liu sheng
> 
> 在 2016/1/5 21:37, AFEK, Ifat (Ifat) 写道:
> >> -Original Message-
> >> From: gord chung [mailto:g...@live.ca]
> >> Sent: Friday, December 11, 2015 10:17 PM
> >>
> >> the original reason this was implemented i believe was to track
> alarm
> >> state changes as an event in ceilometer events. i still see this as
> a
> >> valid use case but it does duplicate some of the functionality of
> >> alarm history.
> >>
> >> i think the main items are to not flood the message bus with
> messages
> >> that no one is listening to. but if there is a use case for it, i'm
> >> happy to see it remain (and improved).
> >>
> >> you can check the patch that Liusheng referenced, but the basic
> >> concept is as mentioned: send message when an alarm state is
> changed.
> >>
> > Hi Gord,
> >
> > We had some further discussions about this issue in Vitrage team, and
> we decided we do want to use Aodh notifications about alarm state
> changes.
> >
> > One reason is that we want to be notified about every alarm, yet we
> don't want to register our web-hook on each alarm definition
> separately. The other reason is that we already listen to message bus
> notifications of other openstack components (like nova), and we would
> like to handle aodh notifications the same way we handle all other
> openstack notifications.
> >
> > We will be happy if this code remains.
> >
> > Thanks,
> > Ifat.
__
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] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[gord chung]

On 06/01/2016 8:11 AM, AFEK, Ifat (Ifat) wrote:

Hi,

We would like to be notified once an alarm state is changed, so we prefer using 
the message bus.
As far as I understand, ceilometer and aodh APIs do not provide immediate 
notifications. If we use the APIs, we will have to poll the data periodically 
and look for changes, and we will get them in delay. By listening to the 
message bus we can get the notifications immediately, like we do with other 
openstack components.

Is there an advantage in using the API instead?
And what do you mean by "aggregation on events data"? what kind of aggregations 
can we do?

Thanks,
Ifat.


is the idea that you don't want to use a webhook to be notified? when an 
alarm is computed by aodh-evaluator, it sends this alarm (via message 
queue) to aodh-notifier which in turns does the webhook. if you just 
disable aodh-notifier, the alarm won't be consumed and you can listen to 
it yourself.


alternatively, it was discussed that maybe adding a zaqar notifier would 
be useful. that way, aodh-notifier would send alarm to zaqar and you 
could configure it to requeue or maybe send a smtp.


--
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] [TripleO] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 6 January 2016 at 12:30, Ryan Brown  wrote:

> On 12/23/2015 04:19 AM, Dougal Matthews wrote:
>
>>
>>
>> On 22 December 2015 at 17:59, Ben Nemec > > wrote:
>>
>> Can we just do git like I've been suggesting all along? ;-)
>>
>> More serious discussion inline. :-)
>>
>> On 12/22/2015 09:36 AM, Dougal Matthews wrote:
>>  > Hi all,
>>  >
>>  > This topic came up in the 2015-12-15 meeting[1], and again
>> briefly today.
>>  > After working with the code that came out of the deployment library
>>  > spec[2] I
>>  > had some concerns with how we are storing the templates.
>>  >
>>  > Simply put, when we are dealing with 100+ files from
>> tripleo-heat-templates
>>  > how can we ensure consistency in Swift without any atomicity or
>>  > transactions.
>>  > I think this is best explained with a couple of examples.
>>  >
>>  >  - When we create a new deployment plan (upload all the templates
>> to swift)
>>  >how do we handle the case where there is an error? For
>> example, if we are
>>  >uploading 10 files - what do we do if the 5th one fails for
>> some reason?
>>  >There is a patch to do a manual rollback[3], but I have
>> concerns about
>>  >doing this in Python. If Swift is completely inaccessible for
>> a short
>>  >period the rollback wont work either.
>>  >
>>  >  - When deploying to Heat, we need to download all the YAML files
>> from
>>  > Swift.
>>  >This can take a couple of seconds. What happens if somebody
>> starts to
>>  >upload a new version of the plan in the middle? We could end
>> up trying to
>>  >deploy half old and half new files. We wouldn't have a
>> consistent view of
>>  >the database.
>>  >
>>  > We had a few suggestions in the meeting:
>>  >
>>  >  - Add a locking mechanism. I would be concerned about deadlocks or
>>  > having to
>>  >lock for the full duration of a deploy.
>>
>> There should be no need to lock the plan for the entire deploy.  It's
>> not like we're re-reading the templates at the end of the deploy
>> today.
>>   It's a one-shot read and then the plan could be unlocked, at least
>> as
>> far as I know.
>>
>>
>> Good point. That would be holding the lock for longer than we need.
>>
>>
>> The only option where we wouldn't need locking at all is the
>> read-copy-update model Clint mentions, which might be a valid option
>> as
>> well.  Whatever we do, there are going to be concurrency issues
>> though.
>>   For example, what happens if two users try to make updates to the
>> plan
>> at the same time?  If you don't either merge the changes or disallow
>> one
>> of them completely then one user's changes might be lost.
>>
>> TBH, this is further convincing me that we should just make this git
>> backed and let git handle the merging and conflict resolution (never
>> mind the fact that it gets us a well-understood version control system
>> for "free").  For updates that don't conflict with other changes, git
>> can merge them automatically, but for merge conflicts you just return
>> a
>> rebase error to the user and make them resolve it.  I have a feeling
>> this is the behavior we'll converge on eventually anyway, and rather
>> than reimplement git, let's just use the real thing.
>>
>>
>> I'd be curious to hear more how you would go about doing this with git.
>> I've
>> never automated git to this level, so I am concerned about what issues we
>> might hit.
>>
>> Do you happen to know of any good sources that I can find out more?
>>
>
> One source of inspiration could be the way Openshift handles things. You
> get a git URL to push your $whatever to, and they have git hooks that
> deploy when you push. This would be perfect for merge conflict situations.
> Imagine two cases.
>

Interesting. I hadn't even considered that we could act as a git remote.
That would
be pretty neat. It would mean that we are very tied to git, which isn't
necessarily a
bad thing but it is something to consider.


Normal case:
> 1. User does stuff in web interface or over API
> 2. The API adds templates and such to git repo, then deploys as needed
> 3. User is happy!
>
> Merge conflict case:
> 1. User does stuff in web interface or over API
> 2. The API tries, but there's a merge conflict. It hands back a 409 and a
> git URL
> 3. User clones the repo and resolves conflict
> 4. User pushes repo back up
> 5. API deploys stuff
> 6. User is happy!
>
>
>
> /2 cents
>>
>> >  - Store the files in a tarball (so we only deal with one file). I
>> think we
>> >could still hit issues with multiple operations unless we
>> guarantee that
>> >only one instance of the API is ever running.
>> >
>> > I think these could 

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Ryan Brown]

On 12/23/2015 04:19 AM, Dougal Matthews wrote:



On 22 December 2015 at 17:59, Ben Nemec > wrote:

Can we just do git like I've been suggesting all along? ;-)

More serious discussion inline. :-)

On 12/22/2015 09:36 AM, Dougal Matthews wrote:
 > Hi all,
 >
 > This topic came up in the 2015-12-15 meeting[1], and again
briefly today.
 > After working with the code that came out of the deployment library
 > spec[2] I
 > had some concerns with how we are storing the templates.
 >
 > Simply put, when we are dealing with 100+ files from
tripleo-heat-templates
 > how can we ensure consistency in Swift without any atomicity or
 > transactions.
 > I think this is best explained with a couple of examples.
 >
 >  - When we create a new deployment plan (upload all the templates
to swift)
 >how do we handle the case where there is an error? For
example, if we are
 >uploading 10 files - what do we do if the 5th one fails for
some reason?
 >There is a patch to do a manual rollback[3], but I have
concerns about
 >doing this in Python. If Swift is completely inaccessible for
a short
 >period the rollback wont work either.
 >
 >  - When deploying to Heat, we need to download all the YAML files
from
 > Swift.
 >This can take a couple of seconds. What happens if somebody
starts to
 >upload a new version of the plan in the middle? We could end
up trying to
 >deploy half old and half new files. We wouldn't have a
consistent view of
 >the database.
 >
 > We had a few suggestions in the meeting:
 >
 >  - Add a locking mechanism. I would be concerned about deadlocks or
 > having to
 >lock for the full duration of a deploy.

There should be no need to lock the plan for the entire deploy.  It's
not like we're re-reading the templates at the end of the deploy today.
  It's a one-shot read and then the plan could be unlocked, at least as
far as I know.


Good point. That would be holding the lock for longer than we need.


The only option where we wouldn't need locking at all is the
read-copy-update model Clint mentions, which might be a valid option as
well.  Whatever we do, there are going to be concurrency issues though.
  For example, what happens if two users try to make updates to the plan
at the same time?  If you don't either merge the changes or disallow one
of them completely then one user's changes might be lost.

TBH, this is further convincing me that we should just make this git
backed and let git handle the merging and conflict resolution (never
mind the fact that it gets us a well-understood version control system
for "free").  For updates that don't conflict with other changes, git
can merge them automatically, but for merge conflicts you just return a
rebase error to the user and make them resolve it.  I have a feeling
this is the behavior we'll converge on eventually anyway, and rather
than reimplement git, let's just use the real thing.


I'd be curious to hear more how you would go about doing this with git. I've
never automated git to this level, so I am concerned about what issues we
might hit.

Do you happen to know of any good sources that I can find out more?


One source of inspiration could be the way Openshift handles things. You 
get a git URL to push your $whatever to, and they have git hooks that 
deploy when you push. This would be perfect for merge conflict 
situations. Imagine two cases.


Normal case:
1. User does stuff in web interface or over API
2. The API adds templates and such to git repo, then deploys as needed
3. User is happy!

Merge conflict case:
1. User does stuff in web interface or over API
2. The API tries, but there's a merge conflict. It hands back a 409 and 
a git URL

3. User clones the repo and resolves conflict
4. User pushes repo back up
5. API deploys stuff
6. User is happy!




/2 cents

>  - Store the files in a tarball (so we only deal with one file). I think 
we
>could still hit issues with multiple operations unless we guarantee 
that
>only one instance of the API is ever running.
>
> I think these could potentially be made to work, but at this point are we
> using the best tool for the job?
>
> For alternatives, I see a can think of a couple of options:
>
> - Use a database, like we did for Tuskar and most OpenStack API's do.

I kind of like this, in particular because it would allow us to handle
migrations between versions the same way as other OpenStack services.


Yeah, I feel like this is the "safe" option. It's a well trodden and
tested path.

I'm not entirely sure how it maps to our template configuration method
though.  Storing a bunch of template blobs 

Re: [openstack-dev] [ansible] tox functional testing rename

[Jesse Pretorius]

On 20 December 2015 at 19:24, Paul Belanger  wrote:
>
>
> I've proposed a series of patches[1] to rename tox -eansible-functional to
> tox -efunctional. While the change is trival, it is meant to workaround an
> interpreter issue with tox[2]. Additionally, the change brings our tox.ini
> inline with other OpenStack projects launching functional tests from tox.
>
>
Thanks for doing this Paul!
__
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] Austin Summit Panel on Generation of Sample Configuration Option Files

[Martin Hickey]

Hi Jay,

+1 on the lack of consistency between projects. When adding the generator
to Neutron, we could not find a consistent pattern so we tried to adopt as
best as possible.

Let me know if you need any feedback on the Neutron experience.

Regards,
Martin




From:   "Jay S. Bryant" 
To: openst...@nemebean.com, "OpenStack Development Mailing List
(not for usage questions)" 
Date:   05/01/2016 19:56
Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Ben,

Please see my in-line responses ...

On 01/04/2016 05:43 PM, Ben Nemec wrote:
> On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
>> Hello,
>>
>>
>> In brainstorming ideas for talks at the upcoming summit, I thought about
>> some of the things I had worked on for Cinder and what could still be
>> improved. One of the things I have been looking into is the generation
>> of sample configuration option files. Upon initial research it looks
>> like none of the main projects are doing it the same way.
> I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> (at least) are all using the oslo-config-generator tool for this.  There
> might be some slight variation in how they call it, but they are using
it.
Yes, we know that they are all using oslo-config-generator but there is
not consistency
in how the information that oslo-config-generator needs to do its job is
being created.
Kendall is looking to better understand what we should be doing and try
to bring
greater consistency between the projects.

> I only vaguely recall having discussions about this with Cinder, so I'd
> be interested in a refresher around why Cinder didn't want to do it the
> same way.  I kind of considered it a solved problem.
So, the challenge Cinder has is the fact that there are many
configuration options with all the
different drivers.  We had proposed a static cinder/opts.py file with
hacking checks to ensure
that all new options were pulled into the file.  This was considered
undesirable.  This lead to
the current solution where we are working to find all the possible
option lists to dynamically
create the cinder/opts.py file.  Similar to what we used to do with the
old config generator.

For Nova, having a dynamic solution is less important as they don't have
options changing
as frequently.  It appears that Neutron was less concerned about the
potentially dynamic nature
of options in their drivers.

> For reference:
> Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
> Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
> which calls
>
https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17

> Keystone: https://github.com/openstack/keystone/blob/master/tox.ini#L148
> Etc...
>
>> I thought it
>> might be interesting to get a panel together to talk about how it is
>> done for each project, why it is done that way for each project, and
>> maybe discuss a more universal approach that could be implemented in
>> oslo and used by all the projects. Please let me know if you have
>> knowledge on your project’s method and are interested in being part of a
>> panel.
>>
>>
>> If you are interested in looking at Cinder’s approach, here is the patch
>> I implemented to make the generation of the sample config file dynamic:
>> https://review.openstack.org/#/c/219700/
>>
>>
>> All the Best,
>>
>> *Kendall J. Nelson*
>> Software Engineer &
>>
>> Openstack Cinder Contributor
>> 
>> *E-mail:*_kjnel...@us.ibm.com_ 
>> *Cell Phone:*(952) 215- 4025*
>> IRC Nickname:*diablo_rojo
>> IBM
>>
>> 3605 Hwy 52 N
>> Rochester, MN 55901-1407
>> United States
>>
>>
>>
>>
>>
>>
__
>> 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

[openstack-dev] [chef] deprecation and removal of old branches

[Jan Klare]

Hi everybody,

due to a hint on this patch https://review.openstack.org/#/c/264130/1 
 i walked through some of our 
cookbooks and found that we never actually deprecated or removed the old 
branches for most of our cookbooks. To do this, we just need to define which 
branches exactly we want to keep. As far as i remember we agreed on supporting 
n + 1, which would be stable/kilo and stable/liberty imho. I would like to 
remove all the unsupported branches as fast as possible to clean this up. If 
you think otherwise, please write an short answer to this mailing list until 
the end of this week. If nothing prevents the cleanup, i will contact infra at 
the beginning of the next week and ask them to help me with the deletion of all 
old and unsupported branches.

Cheers,
Jan

—
irc: jklare__
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] [doc] DocImpact vs. reno

[Sean Dague]

On 01/05/2016 11:07 PM, Lana Brindley wrote:
> 
>> On 6 Jan 2016, at 1:19 PM, Jeremy Stanley  wrote:
>>
>> On 2016-01-06 11:43:34 +1100 (+1100), Lana Brindley wrote:
>> [...]
>>> I’m starting to think that DocImpact needs to simply be retired then
>>
>> Alternatively, let the remaining projects which currently auto-open
>> bugs for openstack-manuals switch to opening bugs against themselves
>> and allow their bug triagers to redirect them to the docs team once
>> the requisite details are determined. And then if those projects
>> don't want to do the work of enforcing or researching the reasons
>> for docimpact headers in individual changes, they can decide to stop
>> supporting them on a project-by-project basis.
> 
> Well, we’ve already done that for big tent projects. The new job was the 
> solution for the ‘defcore’ projects, which we were guinea-pigging in Nova 
> before rolling it out to the others. But if Nova rejects it, I think that 
> maybe we’re dead in the water.

I think auto openning against a project, and shuffling it to manuals
manually (with details added by humans) would be fine.

It's not clear to me why a new job was required for that.

-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] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

[Roman Podoliaka]

Hi Mike,

Thank you for this brilliant analysis! We've been seeing such timeout
errors in downstream periodically and this is the first time someone
has analysed the root cause thoroughly.

On Fri, Dec 18, 2015 at 10:33 PM, Mike Bayer  wrote:
> Hi all -
>
> Let me start out with the assumptions I'm going from for what I want to
> talk about.
>
> 1. I'm looking at Nova right now, but I think similar things are going
> on in other Openstack apps.
>
> 2. Settings that we see in nova.conf, including:
>
> #wsgi_default_pool_size = 1000
> #max_pool_size = 
> #max_overflow = 
> #osapi_compute_workers = 
> #metadata_workers = 
>
>
> are often not understood by deployers, and/or are left unchanged in a
> wide variety of scenarios.If you are in fact working for deployers
> that *do* change these values to something totally different, then you
> might not be impacted here, and if it turns out that everyone changes
> all these settings in real-world scenarios and zzzeek you are just being
> silly thinking nobody sets these appropriately, then fooey for me, I guess.

My understanding is that DB connection pool / workers number options
are usually changed, while the number of eventlet greenlets is not:

http://codesearch.openstack.org/?q=wsgi_default_pool_size=nope==
http://codesearch.openstack.org/?q=max_pool_size=nope==

I think it's for "historical" reasons when MySQL-Python was considered
to be the default DB API driver and we had to work around its
concurrency issues with eventlet by using multiple forks of services.

But as you point out even with a non-blocking DB API driver like
pymysql we are still having problems with timeouts due to pool vs
greenlets number settings.

> 3. There's talk about more Openstack services, at least Nova from what I
> heard the other day, moving to be based on a real webserver deployment
> in any case, the same way Keystone is.   To the degree this is true
> would also mitigate what I'm seeing but still, there's good changes that
> can be made here.

I think, ideally we'd like to have "wsgi container agnostic" apps not
coupled to eventlet or anything else - so that it will be up to a
deployer to choose the application server.

> But if we only have a super low number of greenlets and only a few dozen
> workers, what happens if we have more than 240 requests come in at once,
> aren't those connections going to get rejected?  No way!  eventlet's
> networking system is better than that, those connection requests just
> get queued up in any case, waiting for a greenlet to be available.  Play
> with the script and its settings to see.

Right, it must be controlled by the backlog argument value here:

https://github.com/openstack/oslo.service/blob/master/oslo_service/wsgi.py#L80

> But if we're blocking any connection attempts based on what's available
> at the database level, aren't we under-utilizing for API calls that need
> to do a lot of other things besides DB access?  The answer is that may
> very well be true!   Which makes the guidance more complicated based on
> what service we are talking about.   So here, my guidance is oriented
> towards those Openstack services that are primarily doing database
> access as their primary work.

I believe, all our APIs are pretty much DB oriented.

> Given the above caveat, I'm hoping people can look at this and verify my
> assumptions and the results.Assuming I am not just drunk on eggnog,
> what would my recommendations be?  Basically:
>
> 1. at least for DB-oriented services, the number of 1000 greenlets
> should be *way* *way* lower, and we most likely should allow for a lot
> more connections to be used temporarily within a particular worker,
> which means I'd take the max_overflow setting and default it to like 50,
> or 100.   The Greenlet number should then be very similar to the
> max_overflow number, and maybe even a little less, as Nova API calls
> right now often will use more than one connection concurrently.

I suggest we tweak the config options values in both oslo.service and
oslo.db to provide reasonable production defaults and document the
"correlation" between DB connection pool / greenlet workers number
settings.

> 2. longer term, let's please drop the eventlet pool thing and just use a
> real web server!  (but still tune the connection pool appropriately).  A
> real web server will at least know how to efficiently direct requests to
> worker processes.   If all Openstack workers were configurable under a
> single web server config, that would also be a nice way to centralize
> tuning and profiling overall.

I'd rather we simply not couple to eventlet unconditionally and allow
deployers to choose the WSGI container they want to use.

Thanks,
Roman

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

Re: [openstack-dev] [openstack-ansible][designate] Regarding Designate install through Openstack-Ansible

[Jesse Pretorius]

Hi Swati,

You're making good progress!

I've reviewed 1 and it looks right.
With regards to 2, it seems that according to [1] you need to run
'designate-manage database sync' after setting up the database. We have a
similar pattern in [2] which you can model from.

With regards to 4, the task 'Get Modern PIP using fallback URL' should
never fail, so something is wrong there. Did you confirm that the container
actually does have access to the internet (via a ping or something)? If so,
did you confirm that it's not an MTU issue which is causing dropped
packets? Alternatively it could also be that your lxc-net is using the same
internal IP range as something in the path of traffic from the container to
the internet.

[1]
http://docs.openstack.org/developer/designate/getting-started.html#initialize-start-the-central-service
[2]
https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_cinder/tasks/cinder_db_setup.yml

On 28 December 2015 at 10:49, Sharma Swati6  wrote:

>
> Hi All,
>
> Thanks alot for your valuable feedback Jesse.
>
> *Point 1 :*
>
> I have made the appropriate Designate entry in the file here :*
> /playbooks/defaults/repo_packages/openstack_services.yml* and uploaded it
> for review here :
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/defaults/repo_packages/openstack_services.yml
> Here, I have taken the* 'designate_git_install_branch:'* as the most
> recent one on '17.12.2015'
>
>
>
> *Point 2 :*The execution of tasks and handlers is very well explained in
> your answer. Thanks for that :)
>
>
>
> *Point 3 :*With regards to creating a DB user & DB, I have modeled the
> file from glance and placed it here:
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/roles/os_designate/tasks/designate_db_setup.yml
>
>
>
> *Point 4 :*I also raised that I am facing an error while running the
> playbook, for which I have pasted the results at
> http://paste.openstack.org/show/482171/ . On IRC, Jesse 
> recommended to attach the designate container first and check the internet
> connection.
> I did attach the new designate_container and pinged some address for the
> connectivity check. This works fine here, but I get the same error while
> running playbook.
> *Any other probable cause? *
>
> Once this is done, I will checkout the next step suggested by Jesse, i.e.
> to see the designate service in the Keystone service catalog and  interact
> with it via the CLI?
>
> Please share your suggestions.
>
> Thanks & Regards
> Swati Sharma
> System Engineer
> Tata Consultancy Services
> Mailto: sharma.swa...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Jesse Pretorius  wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> From: Jesse Pretorius 
> Date: 12/17/2015 04:35PM
> Cc: pandey.pree...@tcs.com, Partha Datta 
> Subject: Re: [openstack-dev] Regarding Designate install through
> Openstack-Ansible
>
> Hi Swati,
>
> It looks like you're doing well so far! In addition to my review feedback
> via IRC, let me try to answer your questions.
>
> The directory containing the files which hold the SHA's is here:
>
> https://github.com/openstack/openstack-ansible/tree/master/playbooks/defaults/repo_packages
>
> Considering that Designate is an OpenStack Service, the appropriate
> entries should be added into this file:
>
> https://github.com/openstack/openstack-ansible/blob/master/playbooks/defaults/repo_packages/openstack_services.yml
>
> The order of the services is generally alphabetic, so Designate should be
> added after Cinder and before Glance.
>
> I'm not sure I understand your second question, but let me try and respond
> with what I think you're asking. Assuming a running system with all the
> other components, and an available container for Designate, the workflow
> will be:
>
> 1 - you execute the os-designate-install.yml playbook.
> 2 - Ansible executes the pre-tasks, then the role at
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/os-designate-install.yml#L64
> 3 - Ansible then executes
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/roles/os_designate/tasks/main.yml
> 4 - Handlers are triggered when you notify them, for example:
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/roles/os_designate/tasks/designate_post_install.yml#L54
>
> Does that help you understand how the tasks and handlers are included for
> execution? Does that answer your question?
>
> With regards to creating a DB user & DB - as you've modeled the role from
> Aodh, which doesn't use Galera, you're missing that part An example you can
> model from is here:
> 

Re: [openstack-dev] [heat] Client checking of server version

[Jay Dobies]

On 01/05/2016 04:37 PM, Steven Hardy wrote:

On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote:

I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access older
versions of servers (that's a pretty simplistic description; see [2] for the
spec).

Before the holiday, Steve Hardy and I were talking about the complications
involved. In my case, there's no good way to differentiate an older server
from a legitimate error.

Since the API isn't versioned to the extent that we can leverage that value,
I was looking into using the template versions call. Something along the
lines of:

   supported_versions = hc.template_versions.list()
   version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
   mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of generalized
utility method in the client, under the assumption that we'll need this sort
of check in the future for the same backward compatibility requirements.

So a few questions:

1. Does anyone strongly disagree to checking supported template versions as
a way of determining the specifics of the server API.


Ok, so some valid concerns have been raised over deriving things using the
HOT version (although I do still wonder if the environment itself should be
versioned, just like the templates, then we could rev the environment
verion and say it supports a list, vs changing anything in the API, but
that's probably a separate discussion).

Taking a step back for a moment, the original discussion was around
providing transparent access to the new interface via heatclient, but that
isn't actually a hard requirement - the old interface works fine for many
users, so we could just introduce a new interface (which would eventually
become the default, after all non-EOL heat versions released support the
new API argument):

Currently we do:

heat stack-create foo -f foo.yaml -e a.yaml -e b.yaml

And this implies some client-side resolution of the multiple -e arguments.

-e is short for "--environment-file", but we could introduce a new format,
e.g "-E", short for "--environment-files":

heat stack-create foo -f foo.yaml -E a.yaml -E b.yaml

This option would work the same way as the current interface, but it would
pass the files unmodified for resolution inside heat (by using the new API
format), and as it's opt-in, it's leaving all the current heatclient
interfaces alone without any internal fallback logic?


+1

My only concern is that the default isn't to exercise the "preferred" 
approach.


However, perhaps I'm viewing things wrong with that as being preferred 
instead of just an alternate for non-heatclient. IIRC, the code is 
largely the same, just being called from two separate places (client v. 
server), so it's not an issue of duplication or the actual logic growing 
stale. And it shouldn't really be an issue of the server-side path 
accidentally breaking since there is CI around it. So maybe my concerns 
are overblown.


It does feel weird to have to document something like that, trying to 
describe the differences between -e and -E, but I suppose if we mark -e 
as deprecated it should be understandable enough.


This also has the benefit of letting this code land without having to do 
a major implementation of micro-versions, so that's a plus :)




Steve

__
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] [nova] Next meeting is tomorrow 2100UTC

[Sylvain Bauza]

Hi,

Just a reminder that we're alternating meetings [1] but since this week 
number is odd, the next meeting will be held on Thursday Jan 7th at 2100UTC.
Explanations can be found here 
http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html


"Odd" and "Even" meetings will be alternating starting next week.

-Sylvain

[1] http://eavesdrop.openstack.org/#Nova_Team_Meeting

__
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] [doc] DocImpact vs. reno

[Sean Dague]

On 01/06/2016 09:02 AM, Jeremy Stanley wrote:
> On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
> [...]
>> I think auto openning against a project, and shuffling it to
>> manuals manually (with details added by humans) would be fine.
>>
>> It's not clear to me why a new job was required for that.
> 
> The new check job was simply a requirement of the Docs team, since
> they were having trouble triaging auto-generated bugs they were
> receiving and wanted to enforce the inclusion of some expository
> metadata.

Sure, but if that triage is put back on the Nova team, that seems fine.

It also doesn't make sense to me there would be a DocImpact change that
wouldn't also have a reno section. The reason someone thinks that a
change needs reflection in the manual is that it adds/removes/changes a
feature that would also show up in release notes. Perhaps my imagination
isn't sufficient to come up with a scenario where DocImpact is valid,
but we wouldn't have content in one of those sections.

-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] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

[Yuriy Nesenenko]

Sorry, of course this
https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L575

On Wed, Jan 6, 2016 at 5:57 PM, Yuriy Nesenenko 
wrote:

> You can use this function
> https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L5
>
> On Wed, Jan 6, 2016 at 5:44 PM, Pradip Mukhopadhyay <
> pradip.inte...@gmail.com> wrote:
>
>> Hello,
>>
>>
>> From CLI, I can see the host-name in the cinder show command as follows:
>>
>> | os-vol-host-attr:host |  openstack4@mySCSIBackend#pool1
>> |
>>
>> How this info can be accessed from the cinder python client?
>>
>> I can access other information (id, size, name etc.) as follows:
>>
>> >>> volumes = cinder.volumes.list()
>>
>> >>> volumes
>>
>> []
>>
>> >>> volumes[0].id
>>
>> u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'
>>
>> >>> volumes[0].volume_type
>>
>> u'iscsi_1'
>>
>>
>>
>> Thanks,
>> Pradip
>>
>>
>>
>> __
>> 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] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

[Pradip Mukhopadhyay]

Hello,


>From CLI, I can see the host-name in the cinder show command as follows:

| os-vol-host-attr:host |  openstack4@mySCSIBackend#pool1
|

How this info can be accessed from the cinder python client?

I can access other information (id, size, name etc.) as follows:

>>> volumes = cinder.volumes.list()

>>> volumes

[]

>>> volumes[0].id

u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'

>>> volumes[0].volume_type

u'iscsi_1'



Thanks,
Pradip
__
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] [QA] No meetings for the next 2 weeks

[Matthew Treinish]

On Thu, Dec 17, 2015 at 04:06:38PM -0500, Matthew Treinish wrote:
> 
> Hi Everyone,
> 
> As we discussed during today's QA meeting we'll not be holding the weekly QA
> meeting for the next 2 weeks. Most people will be on vacation anyway, so this
> likely isn't a big surprise. 
> 
> The next meeting will be on Jan. 7th at 0900 UTC.

Just a correction to this, the meeting tomorrow will be at 1700 UTC *not* 0900 
UTC.
After reading ttx's note [1] about the double "odd" weeks in the ical. I double
checked the time in the official ical for meetings and tomorrow's meeting is
scheduled for 1700 UTC.

-Matt Treinish

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html


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] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Martin Hickey]

Hey Kendall,

Sure. Count me in! :)

Thanks,,
Martin




From:   "Kendall J Nelson" 
To: "OpenStack Development Mailing List \(not for usage questions
\)" 
Date:   06/01/2016 16:57
Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Hey Martin,

I thought it might be interesting to get a panel discussion at the Summit
to discuss the lack of consistency/ work towards a more universal way of
using the oslo config generator. Would you be interested? I was hoping to
get someone from Neutron, Nova and Keystone and I could represent Cinder.

All the Best,

 Kendall J. Nelson  
 Software Engineer &





Openstack Cinder Contributor
 
 
 
 E-mail: kjnel...@us.ibm.com IBM 
 Cell Phone: (952) 215- 4025 
 IRC Nickname: diablo_rojo 3605 Hwy 52 N 
   Rochester, MN 
  55901-1407 
   United States 
 



Inactive hide details for "Martin Hickey" ---01/06/2016 06:34:59 AM---Hi
Jay, +1 on the lack of consistency between projects. W"Martin Hickey"
---01/06/2016 06:34:59 AM---Hi Jay, +1 on the lack of consistency between
projects. When adding the generator

From: "Martin Hickey" 
To: jsbry...@electronicjungle.net, "OpenStack Development Mailing List
\(not for usage questions\)" 
Date: 01/06/2016 06:34 AM
Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Hi Jay,

+1 on the lack of consistency between projects. When adding the generator
to Neutron, we could not find a consistent pattern so we tried to adopt as
best as possible.

Let me know if you need any feedback on the Neutron experience.

Regards,
Martin


Inactive hide details for "Jay S. Bryant" ---05/01/2016 19:56:25---Ben,
Please see my in-line responses ..."Jay S. Bryant" ---05/01/2016
19:56:25---Ben, Please see my in-line responses ...

From: "Jay S. Bryant" 
To: openst...@nemebean.com, "OpenStack Development Mailing List (not for
usage questions)" 
Date: 05/01/2016 19:56
Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Ben,

Please see my in-line responses ...

On 01/04/2016 05:43 PM, Ben Nemec wrote:
> On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
>> Hello,
>>
>>
>> In brainstorming ideas for talks at the upcoming summit, I thought about
>> some of the things I had worked on for Cinder and what could still be
>> improved. One of the things I have been looking into is the generation
>> of sample configuration option files. Upon initial research it looks
>> like none of the main projects are doing it the same way.
> I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> (at least) are all using the oslo-config-generator tool for this.  There
> might be some slight variation in how they call it, but they are using
it.
Yes, we know that they are all using oslo-config-generator but there is
not consistency
in how the information that oslo-config-generator needs to do its job is
being created.
Kendall is looking to better understand what we should be doing and try
to bring
greater consistency between the projects.

> I only vaguely recall having discussions about this with Cinder, so I'd
> be interested in a refresher around why Cinder didn't want to do it the
> same way.  I kind of considered it a solved problem.
So, the challenge Cinder has is the fact that there are many
configuration options with all the
different drivers.  We had proposed a static cinder/opts.py file with
hacking checks to ensure
that all new options were pulled into the file.  This was considered
undesirable.  This lead to
the current solution where we are working to find all the possible
option lists to dynamically
create the cinder/opts.py file.  Similar to what we used to do with the
old config generator.

For Nova, having a dynamic solution is less important as they don't have
options changing
as frequently.  It appears that Neutron was less concerned about the
potentially dynamic nature
of options in their drivers.

> For reference:
> Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
> Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
> which calls
>

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Matt Kassawara]

I would like involvement in this discussion too from a documentation
perspective... particularly maintaining the configuration reference and
possibly standardizing how packagers include dynamic configuration files.

On Wed, Jan 6, 2016 at 10:53 AM, Martin Hickey 
wrote:

> Hey Kendall,
>
> Sure. Count me in! :)
>
> Thanks,,
> Martin
>
>
> [image: Inactive hide details for "Kendall J Nelson" ---06/01/2016
> 16:57:41---Hey Martin, I thought it might be interesting to get a]"Kendall
> J Nelson" ---06/01/2016 16:57:41---Hey Martin, I thought it might be
> interesting to get a panel discussion at the
>
> From: "Kendall J Nelson" 
> To: "OpenStack Development Mailing List \(not for usage questions\)" <
> openstack-dev@lists.openstack.org>
> Date: 06/01/2016 16:57
>
> Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> --
>
>
>
> Hey Martin,
>
> I thought it might be interesting to get a panel discussion at the Summit
> to discuss the lack of consistency/ work towards a more universal way of
> using the oslo config generator. Would you be interested? I was hoping to
> get someone from Neutron, Nova and Keystone and I could represent Cinder.
>
> All the Best,
> *Kendall J. Nelson*
> Software Engineer  Cinder Contributor
> --
> *E-mail:* *kjnel...@us.ibm.com* 
> *Cell Phone:* (952) 215- 4025
> *IRC Nickname:* diablo_rojo
> [image: IBM]
>
> 3605 Hwy 52 N
> Rochester, MN 55901-1407
> United States
>
>
> [image: Inactive hide details for "Martin Hickey" ---01/06/2016 06:34:59
> AM---Hi Jay, +1 on the lack of consistency between projects. W]"Martin
> Hickey" ---01/06/2016 06:34:59 AM---Hi Jay, +1 on the lack of consistency
> between projects. When adding the generator
>
> From: "Martin Hickey" 
> To: jsbry...@electronicjungle.net, "OpenStack Development Mailing List
> \(not for usage questions\)" 
> Date: 01/06/2016 06:34 AM
> Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> --
>
>
>
> Hi Jay,
>
> +1 on the lack of consistency between projects. When adding the generator
> to Neutron, we could not find a consistent pattern so we tried to adopt as
> best as possible.
>
> Let me know if you need any feedback on the Neutron experience.
>
> Regards,
> Martin
>
>
> [image: Inactive hide details for "Jay S. Bryant" ---05/01/2016
> 19:56:25---Ben, Please see my in-line responses ...]"Jay S. Bryant"
> ---05/01/2016 19:56:25---Ben, Please see my in-line responses ...
>
> From: "Jay S. Bryant" 
> To: openst...@nemebean.com, "OpenStack Development Mailing List (not for
> usage questions)" 
> Date: 05/01/2016 19:56
> Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> --
>
>
>
> Ben,
>
> Please see my in-line responses ...
>
> On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> >> Hello,
> >>
> >>
> >> In brainstorming ideas for talks at the upcoming summit, I thought about
> >> some of the things I had worked on for Cinder and what could still be
> >> improved. One of the things I have been looking into is the generation
> >> of sample configuration option files. Upon initial research it looks
> >> like none of the main projects are doing it the same way.
> > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> > (at least) are all using the oslo-config-generator tool for this.  There
> > might be some slight variation in how they call it, but they are using
> it.
> Yes, we know that they are all using oslo-config-generator but there is
> not consistency
> in how the information that oslo-config-generator needs to do its job is
> being created.
> Kendall is looking to better understand what we should be doing and try
> to bring
> greater consistency between the projects.
>
> > I only vaguely recall having discussions about this with Cinder, so I'd
> > be interested in a refresher around why Cinder didn't want to do it the
> > same way.  I kind of considered it a solved problem.
> So, the challenge Cinder has is the fact that there are many
> configuration options with all the
> different drivers.  We had proposed a static cinder/opts.py file with
> hacking checks to ensure
> that all new options were pulled into the file.  This was considered
> undesirable.  This lead to
> the current solution where we are working to find all the possible
> option lists to dynamically
> create the cinder/opts.py file.  Similar to what we used to do with the
> old config generator.
>
> For Nova, having a dynamic solution is less important as they don't have
> options changing
> as frequently.  It appears that 

[openstack-dev] [trove] Nominating Mariam John to Trove Core

[Amrith Kumar]

Members of the Trove team,

I would like to nominate Mariam John (johnma on IRC) to the Trove core review 
team.

Mariam has been an active member of the Trove team for some time now. She added 
support for IBM DB2 in Trove and provided elements for building Trove guest 
images. She also implemented code that provided CouchDB support in Trove. She 
has been an active reviewer and I have found her review comments to be 
insightful and useful.

You can review her activity report at

http://stackalytics.com/report/users/mariamj

Members of the Trove core team, please reply to this message with your feedback 
to this proposed change.

Thanks,

-amrith

__
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] Austin Summit Panel on Generation of Sample Configuration Option Files

[Doug Hellmann]

Excerpts from Kendall J Nelson's message of 2016-01-05 13:48:46 -0600:
> 
> Okay, to clarify, you are saying pip freeze to get the list of libraries
> for the oslo.config.opts section in entry
> points here https://github.com/openstack/cinder/blob/master/setup.cfg#L44 ?

We do have a convention that the entry point name matches the library
name. Those values should be listed in the input file for the config
generator. They should *not* be listed in your setup.cfg.

Doug

> 
> 
> All the Best,
>   
>Kendall J. Nelson  
>Software Engineer &
>   
> 
> 
> Openstack Cinder Contributor
>
>
>
>E-mail: kjnel...@us.ibm.com IBM 
>Cell Phone: (952) 215- 4025 
>IRC Nickname: diablo_rojo 3605 Hwy 52 N 
>  Rochester, MN 
> 55901-1407 
>  United States 
>
> 
> 
> 
> 
> 
> From:Joshua Harlow 
> To:"OpenStack Development Mailing List (not for usage questions)"
> 
> Date:01/04/2016 04:40 PM
> Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> 
> 
> 
> So just out of curiosity:
> 
> https://review.openstack.org/#/c/219700/14/cinder/config/generate_cinder_opts.py
> 
> 
> Why does this not use
> https://github.com/openstack/cinder/blob/master/setup.cfg#L44 to find
> the exposed cinder configuration options (and drivers that cinder
> has/provides should expose a similar entrypoint and so-on)?
> 
> Also just brainstorming, but said 'generate_cinder_opts.py' should
> likely also have the output of `pip freeze` (sorted and canonicalized
> would be best to) because the generated opts that are found in other
> libraries (those libraries should/typically expose an entrypoint to list
> there own opts) depend on *exactly* what version of the package(s) is
> installed (yes I know this makes the application <-> library API for
> those libraries extremely weak/non-existent but this is how things have
> gone).
> 
> -Josh
> 
> Kendall J Nelson wrote:
> > Hello,
> >
> >
> > In brainstorming ideas for talks at the upcoming summit, I thought about
> > some of the things I had worked on for Cinder and what could still be
> > improved. One of the things I have been looking into is the generation
> > of sample configuration option files. Upon initial research it looks
> > like none of the main projects are doing it the same way. I thought it
> > might be interesting to get a panel together to talk about how it is
> > done for each project, why it is done that way for each project, and
> > maybe discuss a more universal approach that could be implemented in
> > oslo and used by all the projects. Please let me know if you have
> > knowledge on your project’s method and are interested in being part of a
> > panel.
> >
> >
> > If you are interested in looking at Cinder’s approach, here is the patch
> > I implemented to make the generation of the sample config file dynamic:
> > https://review.openstack.org/#/c/219700/
> >
> >
> > All the Best,
> >
> > *Kendall J. Nelson*
> > Software Engineer &
> >
> > Openstack Cinder Contributor
> > 
> > *E-mail:*_kjnel...@us.ibm.com_ 
> > *Cell Phone:*(952) 215- 4025*
> > IRC Nickname:*diablo_rojo
> > IBM
> >
> > 3605 Hwy 52 N
> > Rochester, MN 55901-1407
> > United States
> >
> >
> >
> >

__
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] Austin Summit Panel on Generation of Sample Configuration Option Files

[Kendall J Nelson]

Excellent!

I will get a proposal written up in the next few days here and I will
include you both in it. If there is anyone else you know in other projects
that might be interested as well, feel free to send them my way :)

All the Best,
  
   Kendall J. Nelson  
   Software Engineer &
  


Openstack Cinder Contributor
   
   
   
   E-mail: kjnel...@us.ibm.com IBM 
   Cell Phone: (952) 215- 4025 
   IRC Nickname: diablo_rojo 3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   





From:   Matt Kassawara 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   01/06/2016 12:36 PM
Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



I would like involvement in this discussion too from a documentation
perspective... particularly maintaining the configuration reference and
possibly standardizing how packagers include dynamic configuration files.

On Wed, Jan 6, 2016 at 10:53 AM, Martin Hickey 
wrote:
  Hey Kendall,

  Sure. Count me in! :)

  Thanks,,
  Martin


  Inactive hide details for "Kendall J Nelson" ---06/01/2016 16:57:41---Hey
  Martin,I thought it might be interesting to get a"Kendall J Nelson"
  ---06/01/2016 16:57:41---Hey Martin, I thought it might be interesting to
  get a panel discussion at the

  From: "Kendall J Nelson" 
  To: "OpenStack Development Mailing List \(not for usage questions\)" <
  openstack-dev@lists.openstack.org>
  Date: 06/01/2016 16:57



  Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
  Sample Configuration Option Files



  Hey Martin,

  I thought it might be interesting to get a panel discussion at the Summit
  to discuss the lack of consistency/ work towards a more universal way of
  using the oslo config generator. Would you be interested? I was hoping to
  get someone from Neutron, Nova and Keystone and I could represent Cinder.


  All the Best,
 
 Kendall J. Nelson   
 Software Engineer & 
 

  Openstack Cinder Contributor
   
   
   
 E-mail: kjnel...@us.ibm.com   IBM 
 Cell Phone: (952) 215- 4025   
 IRC Nickname: diablo_rojo   3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   



  Inactive hide details for "Martin Hickey" ---01/06/2016 06:34:59 AM---Hi
  Jay, +1 on the lack of consistency between projects. W"Martin Hickey"
  ---01/06/2016 06:34:59 AM---Hi Jay, +1 on the lack of consistency between
  projects. When adding the generator

  From: "Martin Hickey" 
  To: jsbry...@electronicjungle.net, "OpenStack Development Mailing List
  \(not for usage questions\)" 
  Date: 01/06/2016 06:34 AM
  Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
  Sample Configuration Option Files



  Hi Jay,

  +1 on the lack of consistency between projects. When adding the generator
  to Neutron, we could not find a consistent pattern so we tried to adopt
  as best as possible.

  Let me know if you need any feedback on the Neutron experience.

  Regards,
  Martin


  Inactive hide details for "Jay S. Bryant" ---05/01/2016 19:56:25---Ben,
  Please see my in-line responses ..."Jay S. Bryant" ---05/01/2016
  19:56:25---Ben, Please see my in-line responses ...

  From: "Jay S. Bryant" 
  To: openst...@nemebean.com, "OpenStack Development Mailing List (not for
  usage questions)" 
  Date: 05/01/2016 19:56
  Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
  Sample Configuration Option Files



  Ben,

  Please see my in-line responses ...

  On 01/04/2016 05:43 PM, Ben Nemec wrote:
  > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
  >> Hello,
  >>
  >>
  >> In brainstorming ideas for talks at the 

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Doug Hellmann]

Excerpts from Kendall J Nelson's message of 2016-01-05 13:52:10 -0600:
> Hey Doug,
> 
> To respond to your points :)
> 
> 1. We are actually including the resulting opts.py file from
> generate_cinder_opts.py so that deployers can distribute. That was added in
> a subsequent patch- sorry for that confusion.

Great, that wasn't clear based on looking at that one patch but if
you're shipping the file in the sdist that does address one of my
concerns.

> 
> 2. As for support for generating different configuration files for
> different cinder services, we haven't faced that request yet. It could be
> something to look into though since it could very well be a requirement in
> the future though.

Yes, it's something to keep in mind. It was an important feature of the
new config generator, but not all projects are using it, yet.

> 
> 3. To your third point, I now see the flaw in how we are getting options
> from keystone. Not entirely sure how to handle getting them though. Can you
> elaborate on a better approach? I briefly looked into the nova setup.cfg,
> but couldn't find any references to keystone.

You don't need to mention keystone in your setup.cfg at all. The
config generator uses a config file to tell it which entry points
it should query for options. It looks like for cinder that file is
cinder/config/cinder-config-generator.conf. The "namespace" entries
there refer to the plugin names to be loaded. If you ensure that
all of the entry points for dependencies of cinder are listed there,
you'll get all of the options in your sample config.

Some dependencies may have multiple entry points. oslo.middleware
is a good example of this. It has oslo.middleware, oslo.middleware.cors,
oslo.middleware.sizelimit, and oslo.middleware.ssl. You should include
the entry points for the middleware you rely on. Check the documentation
for other libraries to see if they have similar cases. If you don't find
info about config generator entry points in the docs for a library,
please file a bug for the project so we can update them.

Using the config generator is described in the docs at
http://docs.openstack.org/developer/oslo.config/generator.html but
I can see maybe that's not clear (and detailed) enough, so I'll put
an item on my todo list to work on those instructions, unless another
Oslo team member beats me to it.

Doug


> 
> All the Best,
>   
>Kendall J. Nelson  
>Software Engineer &
>   
> 
> 
> Openstack Cinder Contributor
>
>
>
>E-mail: kjnel...@us.ibm.com IBM 
>Cell Phone: (952) 215- 4025 
>IRC Nickname: diablo_rojo 3605 Hwy 52 N 
>  Rochester, MN 
> 55901-1407 
>  United States 
>
> 
> 
> 
> 
> 
> From:Doug Hellmann 
> To:openstack-dev 
> Date:01/05/2016 09:45 AM
> Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> 
> Excerpts from Ben Nemec's message of 2016-01-04 17:43:20 -0600:
> > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> > > Hello,
> > >
> > >
> > > In brainstorming ideas for talks at the upcoming summit, I thought
> about
> > > some of the things I had worked on for Cinder and what could still be
> > > improved. One of the things I have been looking into is the generation
> > > of sample configuration option files. Upon initial research it looks
> > > like none of the main projects are doing it the same way.
> >
> > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> > (at least) are all using the oslo-config-generator tool for this.  There
> > might be some slight variation in how they call it, but they are using
> it.
> >
> > I only vaguely recall having discussions about this with Cinder, so I'd
> > be interested in a refresher around why Cinder didn't want to do it the
> > same way.  I kind of considered it a solved problem.
> 
> My memory of the discussion was that the Cinder team objected to
> maintaining an entry point to be inspected by the config generator.
> Unfortunately, because we now have options defined in many libraries, we
> can't rely on grep as a global strategy. It worked for incubated Oslo
> code, but won't for libraries.
> 
> There are a number of issues with the current implementation in cinder:
> 
> 1. It looks like the patch referenced in the original email is
>

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Doug Hellmann]

Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600:
> Ben,
> 
> Please see my in-line responses ...
> 
> On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> >> Hello,
> >>
> >>
> >> In brainstorming ideas for talks at the upcoming summit, I thought about
> >> some of the things I had worked on for Cinder and what could still be
> >> improved. One of the things I have been looking into is the generation
> >> of sample configuration option files. Upon initial research it looks
> >> like none of the main projects are doing it the same way.
> > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> > (at least) are all using the oslo-config-generator tool for this.  There
> > might be some slight variation in how they call it, but they are using it.
> Yes, we know that they are all using oslo-config-generator but there is 
> not consistency
> in how the information that oslo-config-generator needs to do its job is 
> being created.
> Kendall is looking to better understand what we should be doing and try 
> to bring
> greater consistency between the projects.
> 
> > I only vaguely recall having discussions about this with Cinder, so I'd
> > be interested in a refresher around why Cinder didn't want to do it the
> > same way.  I kind of considered it a solved problem.
> So, the challenge Cinder has is the fact that there are many 
> configuration options with all the
> different drivers.  We had proposed a static cinder/opts.py file with 
> hacking checks to ensure
> that all new options were pulled into the file.  This was considered 
> undesirable.  This lead to
> the current solution where we are working to find all the possible 
> option lists to dynamically
> create the cinder/opts.py file.  Similar to what we used to do with the 
> old config generator.

I proposed, I think, that each driver should have its own entry point,
cinder.foo, cinder.bar, etc. Each entry point refers to a single
function, which can be maintained inside the driver code by the driver
author. Each would then be registered in setup.cfg and listed in the
input file for the config generator. If you also ensure that all of the
options for a given driver are in their own section of the config file,
you'll have a nice neat sample with all of the options. If a deployer or
distributor wants to generate a file that only includes the driver in
use, that's possible by passing different inputs to the config
generator.

> 
> For Nova, having a dynamic solution is less important as they don't have 
> options changing
> as frequently.  It appears that Neutron was less concerned about the 
> potentially dynamic nature
> of options in their drivers.
> 
> > For reference:
> > Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
> > Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
> > which calls
> > https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17
> > Keystone: https://github.com/openstack/keystone/blob/master/tox.ini#L148
> > Etc...
> >
> >> I thought it
> >> might be interesting to get a panel together to talk about how it is
> >> done for each project, why it is done that way for each project, and
> >> maybe discuss a more universal approach that could be implemented in
> >> oslo and used by all the projects. Please let me know if you have
> >> knowledge on your project’s method and are interested in being part of a
> >> panel.
> >>
> >>
> >> If you are interested in looking at Cinder’s approach, here is the patch
> >> I implemented to make the generation of the sample config file dynamic:
> >> https://review.openstack.org/#/c/219700/
> >>
> >>
> >> All the Best,
> >>
> >> *Kendall J. Nelson*
> >> Software Engineer &
> >>
> >> Openstack Cinder Contributor
> >> 
> >> *E-mail:*_kjnel...@us.ibm.com_ 
> >> *Cell Phone:*(952) 215- 4025*
> >> IRC Nickname:*diablo_rojo
> >> IBM
> >>
> >> 3605 Hwy 52 N
> >> Rochester, MN 55901-1407
> >> United States
> >>
> >>
> >>
> >>
> >>
> >> __
> >> 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

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Kendall J Nelson]

Hey Doug,

This definitely sounds like something to look into. Would you be
interested in being a part of a panel at the upcoming summit in Austin to
discuss this?

All the Best,
  
   Kendall J. Nelson  
   Software Engineer &
   OpenStack Contributor  
  


   
   
   
   E-mail: kjnel...@us.ibm.com IBM 
   Cell Phone: (952) 215- 4025 
   IRC Nickname: diablo_rojo 3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   






From:   Doug Hellmann 
To: openstack-dev 
Date:   01/06/2016 01:03 PM
Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600:
> Ben,
>
> Please see my in-line responses ...
>
> On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> >> Hello,
> >>
> >>
> >> In brainstorming ideas for talks at the upcoming summit, I thought
about
> >> some of the things I had worked on for Cinder and what could still be
> >> improved. One of the things I have been looking into is the generation
> >> of sample configuration option files. Upon initial research it looks
> >> like none of the main projects are doing it the same way.
> > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> > (at least) are all using the oslo-config-generator tool for this.
There
> > might be some slight variation in how they call it, but they are using
it.
> Yes, we know that they are all using oslo-config-generator but there is
> not consistency
> in how the information that oslo-config-generator needs to do its job is
> being created.
> Kendall is looking to better understand what we should be doing and try
> to bring
> greater consistency between the projects.
>
> > I only vaguely recall having discussions about this with Cinder, so I'd
> > be interested in a refresher around why Cinder didn't want to do it the
> > same way.  I kind of considered it a solved problem.
> So, the challenge Cinder has is the fact that there are many
> configuration options with all the
> different drivers.  We had proposed a static cinder/opts.py file with
> hacking checks to ensure
> that all new options were pulled into the file.  This was considered
> undesirable.  This lead to
> the current solution where we are working to find all the possible
> option lists to dynamically
> create the cinder/opts.py file.  Similar to what we used to do with the
> old config generator.

I proposed, I think, that each driver should have its own entry point,
cinder.foo, cinder.bar, etc. Each entry point refers to a single
function, which can be maintained inside the driver code by the driver
author. Each would then be registered in setup.cfg and listed in the
input file for the config generator. If you also ensure that all of the
options for a given driver are in their own section of the config file,
you'll have a nice neat sample with all of the options. If a deployer or
distributor wants to generate a file that only includes the driver in
use, that's possible by passing different inputs to the config
generator.

>
> For Nova, having a dynamic solution is less important as they don't have
> options changing
> as frequently.  It appears that Neutron was less concerned about the
> potentially dynamic nature
> of options in their drivers.
>
> > For reference:
> > Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
> > Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
> > which calls
> >
https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17

> > Keystone:
https://github.com/openstack/keystone/blob/master/tox.ini#L148
> > Etc...
> >
> >> I thought it
> >> might be interesting to get a panel together to talk about how it is
> >> done for each project, why it is done that way for each project, and
> >> maybe discuss a more universal approach that could be implemented in
> >> oslo and used by all the projects. Please let me know if you have
> >> knowledge on your project’s method and are interested in being part of
a
> >> panel.
> >>
> >>
> >> If you are interested in looking at Cinder’s approach, here is the
patch
> >> I implemented to make the generation of the sample config file
dynamic:
> 

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Doug Hellmann]

Excerpts from Kendall J Nelson's message of 2016-01-06 13:07:30 -0600:
> Hey Doug,
> 
> This definitely sounds like something to look into. Would you be
> interested in being a part of a panel at the upcoming summit in Austin to
> discuss this?

I'm not sure what you mean by "panel." Are you planning a cross-project
design session?

Doug

> 
> All the Best,
>   
>Kendall J. Nelson  
>Software Engineer &
>OpenStack Contributor  
>   
> 
> 
>
>
>
>E-mail: kjnel...@us.ibm.com IBM 
>Cell Phone: (952) 215- 4025 
>IRC Nickname: diablo_rojo 3605 Hwy 52 N 
>  Rochester, MN 
> 55901-1407 
>  United States 
>
> 
> 
> 
> 
> 
> 
> From:Doug Hellmann 
> To:openstack-dev 
> Date:01/06/2016 01:03 PM
> Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> 
> Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600:
> > Ben,
> >
> > Please see my in-line responses ...
> >
> > On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> > >> Hello,
> > >>
> > >>
> > >> In brainstorming ideas for talks at the upcoming summit, I thought
> about
> > >> some of the things I had worked on for Cinder and what could still be
> > >> improved. One of the things I have been looking into is the generation
> > >> of sample configuration option files. Upon initial research it looks
> > >> like none of the main projects are doing it the same way.
> > > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> > > (at least) are all using the oslo-config-generator tool for this.
> There
> > > might be some slight variation in how they call it, but they are using
> it.
> > Yes, we know that they are all using oslo-config-generator but there is
> > not consistency
> > in how the information that oslo-config-generator needs to do its job is
> > being created.
> > Kendall is looking to better understand what we should be doing and try
> > to bring
> > greater consistency between the projects.
> >
> > > I only vaguely recall having discussions about this with Cinder, so I'd
> > > be interested in a refresher around why Cinder didn't want to do it the
> > > same way.  I kind of considered it a solved problem.
> > So, the challenge Cinder has is the fact that there are many
> > configuration options with all the
> > different drivers.  We had proposed a static cinder/opts.py file with
> > hacking checks to ensure
> > that all new options were pulled into the file.  This was considered
> > undesirable.  This lead to
> > the current solution where we are working to find all the possible
> > option lists to dynamically
> > create the cinder/opts.py file.  Similar to what we used to do with the
> > old config generator.
> 
> I proposed, I think, that each driver should have its own entry point,
> cinder.foo, cinder.bar, etc. Each entry point refers to a single
> function, which can be maintained inside the driver code by the driver
> author. Each would then be registered in setup.cfg and listed in the
> input file for the config generator. If you also ensure that all of the
> options for a given driver are in their own section of the config file,
> you'll have a nice neat sample with all of the options. If a deployer or
> distributor wants to generate a file that only includes the driver in
> use, that's possible by passing different inputs to the config
> generator.
> 
> >
> > For Nova, having a dynamic solution is less important as they don't have
> > options changing
> > as frequently.  It appears that Neutron was less concerned about the
> > potentially dynamic nature
> > of options in their drivers.
> >
> > > For reference:
> > > Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
> > > Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
> > > which calls
> > >
> https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17
> 
> > > Keystone:
> https://github.com/openstack/keystone/blob/master/tox.ini#L148
> > > Etc...
> > >
> > >> I thought it
> > >> might be interesting to get a panel together to talk about how it is
> > >> done for each project, why it is done that way for each project, and
> > >> maybe 

Re: [openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

[Duncan Thomas]

Try client.volumes..get(id).__dict__['

*os-vol-host-attr:host'] *

*Ugly, but it seems to work*

On 6 January 2016 at 18:20, Pradip Mukhopadhyay 
wrote:

> Thanks, Yuriy.
>
> My question was: how can I retrieve the "host@backend#pool" from the
> pythonclient API of volume listing? Once I have that, I should use this
> method to extract the pool-name.
>
> But how can I access this info? CLI is showing this as in the following
> field:
>
> stack@openstack4:~/devstack$ cinder show
> e8be1df5-64fb-43fa-aacd-9bebba17fba5
>
> +---+--+
> |Property   |
> Value |
>
> +---+--+
> |  attachments  |
> []  |
> |   availability_zone   |
> nova |
> |bootable   |
> false |
> |  consistencygroup_id  |
> None |
> |   created_at  |
> 2016-01-06T14:21:32.00  |
> |  description  |
> None |
> |   encrypted   |
> False |
> |   id  |
> e8be1df5-64fb-43fa-aacd-9bebba17fba5 |
> |metadata   |
> {}  |
> |migration_status   |
> None |
> |  multiattach  |
> False |
> |  name |
> None |
> | *os-vol-host-attr:host |  openstack4@SCSIBackend#pool1*
> |
> | os-vol-mig-status-attr:migstat|
> None |
> | os-vol-mig-status-attr:name_id|
> None |
> |  os-vol-tenant-attr:tenant_id |
> 4713f79411844a29b3f53d5fd7502784   |
> |   os-volume-replication:driver_data   |
> None |
> | os-volume-replication:extended_status |
> None |
> |   replication_status  |
> disabled   |
> |  size |
> 1   |
> |  snapshot_id  |
> None |
> |  source_volid |
> None |
> | status|
> available   |
> |   updated_at  |
> 2016-01-06T14:21:34.00  |
> |user_id|
> 89b4af10bc1a473caff22384c844bc6f   |
> |  volume_type  |
> iscsi_1|
>
> +---+--+
>
>
>
> Now in python client API, I am not able to get that field :(
>
>
>
> >>> volumes = cinder.volumes.list()
>
> >>> volumes
>
> []
>
> >>> type(volumes[0])
> 
>
> >>> volumes[0].id
>
> u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'
>
> >>> volumes[0].host
> Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "/usr/local/lib/python2.7/dist-packages/cinderclient/openstack/common/apiclient/base.py",
> line 464, in __getattr__
> raise AttributeError(k)
> AttributeError: host
> >>> volumes[0].os-vol-host-attr
> Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "/usr/local/lib/python2.7/dist-packages/cinderclient/openstack/common/apiclient/base.py",
> line 464, in __getattr__
> raise AttributeError(k)
> AttributeError: os
>
>
>
>
> Essentially what is the way to get the attribute from the API?
>
>
>
>
> Thanks,
>
> Pradip
>
>
>
> On Wed, Jan 6, 2016 at 9:28 PM, Yuriy Nesenenko 
> wrote:
>
>> Sorry, of course this
>> https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L575
>>
>> On Wed, Jan 6, 2016 at 5:57 PM, Yuriy Nesenenko 
>> wrote:
>>
>>> You can use this function
>>> https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L5
>>>
>>> On Wed, Jan 6, 2016 at 5:44 PM, Pradip Mukhopadhyay <
>>> pradip.inte...@gmail.com> wrote:
>>>
 Hello,


 From CLI, I can see the host-name in the cinder show command as follows:

 | os-vol-host-attr:host |  openstack4@mySCSIBackend#pool1
 |

 How this info can be accessed from the cinder python client?

 I can access other information (id, size, name etc.) as follows:

 >>> volumes = cinder.volumes.list()

 >>> volumes

 []

 >>> volumes[0].id

 u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'

 >>> volumes[0].volume_type

 u'iscsi_1'



 Thanks,
 Pradip




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

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Kendall J Nelson]

Yeah something like that- I'm new to the process so I may have the
terminology wrong. So far I have Martin Hickey and Matt Kassawara and
myself. I was hoping to get someone from Nova and maybe someone from
Keystone as well.

All the Best,
  
   Kendall J. Nelson  
   Software Engineer &
   OpenStack Contributor  
  


   
   
   
   E-mail: kjnel...@us.ibm.com IBM 
   Cell Phone: (952) 215- 4025 
   IRC Nickname: diablo_rojo 3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   






From:   Doug Hellmann 
To: openstack-dev 
Date:   01/06/2016 01:22 PM
Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Excerpts from Kendall J Nelson's message of 2016-01-06 13:07:30 -0600:
> Hey Doug,
>
> This definitely sounds like something to look into. Would you be
> interested in being a part of a panel at the upcoming summit in Austin to
> discuss this?

I'm not sure what you mean by "panel." Are you planning a cross-project
design session?

Doug

>
> All the Best,
>
>Kendall J. Nelson
>Software Engineer &
>OpenStack Contributor
>
>
>
>
>
>
>E-mail: kjnel...@us.ibm.com IBM
>Cell Phone: (952) 215- 4025
>IRC Nickname: diablo_rojo 3605 Hwy 52 N
>  Rochester, MN
> 55901-1407
>  United States
>
>
>
>
>
>
>
> From:Doug Hellmann 
> To:openstack-dev 
> Date:01/06/2016 01:03 PM
> Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation
of
> Sample Configuration Option Files
>
> Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600:
> > Ben,
> >
> > Please see my in-line responses ...
> >
> > On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> > >> Hello,
> > >>
> > >>
> > >> In brainstorming ideas for talks at the upcoming summit, I thought
> about
> > >> some of the things I had worked on for Cinder and what could still
be
> > >> improved. One of the things I have been looking into is the
generation
> > >> of sample configuration option files. Upon initial research it looks
> > >> like none of the main projects are doing it the same way.
> > > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and
Heat
> > > (at least) are all using the oslo-config-generator tool for this.
> There
> > > might be some slight variation in how they call it, but they are
using
> it.
> > Yes, we know that they are all using oslo-config-generator but there is
> > not consistency
> > in how the information that oslo-config-generator needs to do its job
is
> > being created.
> > Kendall is looking to better understand what we should be doing and try
> > to bring
> > greater consistency between the projects.
> >
> > > I only vaguely recall having discussions about this with Cinder, so
I'd
> > > be interested in a refresher around why Cinder didn't want to do it
the
> > > same way.  I kind of considered it a solved problem.
> > So, the challenge Cinder has is the fact that there are many
> > configuration options with all the
> > different drivers.  We had proposed a static cinder/opts.py file with
> > hacking checks to ensure
> > that all new options were pulled into the file.  This was considered
> > undesirable.  This lead to
> > the current solution where we are working to find all the possible
> > option lists to dynamically
> > create the cinder/opts.py file.  Similar to what we used to do with the
> > old config generator.
>
> I proposed, I think, that each driver should have its own entry point,
> cinder.foo, cinder.bar, etc. Each entry point refers to a single
> function, which can be maintained inside the driver code by the driver
> author. Each would then be registered in setup.cfg and listed in the
> input file for the config generator. If you also ensure that all of the
> options for a given driver are in their own section of the config file,
> you'll have a nice neat sample with all of the options. If a deployer or
> distributor wants to generate a file that only includes the driver in
> use, 

Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

[Vyvial, Craig]

Thanks for the nomination Amrith and I think Mariam will be a great addition to 
the core team.

+1

-Craig

On Jan 6, 2016, at 12:39 PM, Amrith Kumar 
> wrote:

Members of the Trove team,

I would like to nominate Mariam John (johnma on IRC) to the Trove core review 
team.

Mariam has been an active member of the Trove team for some time now. She added 
support for IBM DB2 in Trove and provided elements for building Trove guest 
images. She also implemented code that provided CouchDB support in Trove. She 
has been an active reviewer and I have found her review comments to be 
insightful and useful.

You can review her activity report at

http://stackalytics.com/report/users/mariamj

Members of the Trove core team, please reply to this message with your feedback 
to this proposed change.

Thanks,

-amrith

__
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] [Nova] Next CellsV2 meeting is Jan 13 at 2100UTC

[Andrew Laski]

See subject :)

As explained in 
http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html 
a recurring calendar event based on alternating weeks will now be 
incorrect.  I had to fix my calendar and I expect others will want to do 
the same.


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

[openstack-dev] [Designate] Old Reviews

[Hayes, Graham]

Hi All,

We have built up a lot of old reviews, that can be removed.

So, this day next week I proposed I abandon any reviews that have not
been updated in 42 days.

If people want to Unabandon any changes, please do - this is not about

In our repos the following list would be abandoned if there is no update:

http://paste.openstack.org/show/483150/

If everyone is in agreement - I will do this around 18:00 UTC next
Wednesday (13/01/2016)

Graham

-- 
Graham Hayes



__
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] [Horizon] Updating XStatic packages

[Rajat Vig]

I did update some of the low hanging packages where the upgrades seemed
safe to do and noted the patch numbers in the same EtherPad.

I wasn't sure what to mark the effort against. So I created some bugs.
Should it be a blueprint?

-Rajat

On Wed, Jan 6, 2016 at 2:18 AM, Rob Cresswell (rcresswe)  wrote:

> Hi all,
>
> While the automated system is broken, I’d like to work on manually
> releasing a few of the XStatic packages. This will *only* be the release
> stage; we will still use gerrit to review the package content as usual.
>
> List of packages current versions, and their upstreams, can be found here:
> https://etherpad.openstack.org/p/horizon-libs
>
> If anyone has spare time, please consider investigating some of the
> dependencies listed above. To update an XStatic package, propose a change
> to its repo as you would with Horizon; they are all in the OpenStack
> namespace. For example, Xstatic-Angular can be found at
> http://git.openstack.org/cgit/openstack/xstatic-angular/
>
> Thanks,
> Rob
>
> __
> 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] [puppet] [neutron] Serious bug in puppet neutron cli json output parsing.

[Sofer Athlan-Guyot]

Mike Dorman  writes:

> I wonder if we should just refactor the Neutron provider to support
> either format? That way we stay independent from whatever the
> particular installation’s cliff/tablib situation is.
>
> We can probably safely assume that none of the Neutron objects will
> have attributes called ‘Field’ or ‘Value’, so it would be fairly easy
> to detect which format is there.

Hum, oki, so you need two parsers as the two outputs are different and a
"format detector" (cliff or clifftab).  Furthermore the clifftab always
returns its stuff in a json array, so "[{" was chosen as a starting tag.
Unfortunately cliff can return a json hash as well.  So you have to
somehow detect the start tag as well.

Considering that the first tag detection was the original problem[1], I
submitted this patch[2] which solves the problem for csv output quite
easily.  So with[3] we can have a not randomly buggy neutron parser.

That sound simpler than a tag detector + format detector + 2 parsers.

[1] https://bugs.launchpad.net/puppet-neutron/+bug/1508511
[2] https://review.openstack.org/#/c/263874/
[3] https://review.openstack.org/262809
>
> Mike
>
> From: Denis Egorenko 
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" 
> Date: Thursday, December 31, 2015 at 5:59 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [puppet] [neutron] Serious bug in puppet
> neutron cli json output parsing.
>
> Last I checked, which was quite a while ago, openstackclient didn't
> support everything we were using from the neutron client.
>
> That's true. Openstack client doesn't support all features of neutron
> client [1].
>
> I would prefer use 3) option, but, unfortunately, i also don't see
> way, how to detect stevedore and cliff.
>
> [1]
> https://github.com/openstack/python-openstackclient/blob/master/setup.cfg#L329-
> L339
>
> 2015-12-30 19:53 GMT+03:00 Colleen Murphy :
>
> 
> 
> 
> 
> On Wed, Dec 30, 2015 at 8:37 AM, Sofer Athlan-Guyot
>  wrote:
> 
> Hi,
> 
> I have added neutron people as they may help to find a
> solution.
> 
> After banging my head against the wall for a whole afternoon I
> discovered a serious bug in puppet neutron module.
> 
> I not going to repeat here the detail of the bug report[1].
> Basically:
> - neutron_port
> - neutron_subnet
> - neutron_router
> - neutron_network
> 
> may break idempotency randomly and won't work at all when
> clifftablib is
> removed from the package dependency of python-openstackclient
> (Mitaka[2])
> 
> So the problem is that neutron cli json output on liberty (at
> least, and
> maybe before) is not consistent and may come from cliff or
> clifftablib.
> I didn't test it but the same may apply to openstack cli. As
> we don't
> use the openstack cli json output it's not a issue (for puppet
> modules)
> 
> The available solution I can see are:
> 1. go back to parsing csv, shell output (revert [3])
> 2. find a way to leverage openstacklib parsing for neutron as
> well
> 3. keep json and parse the right output (cliff) and find a way
> to make
> sure that it is always used by stevedore
> 4. ?
> 
> Last I checked, which was quite a while ago, openstackclient didn't
> support everything we were using from the neutron client. I would
> like to reevaluate that and go with option 2 if we can. Otherwise
> option 1 seems reasonable.
> 
> From my point of view 3) is not a option, but other may disagree.
> 
> The problem is tricky and the fact that the CI cannot detect
> this is
> trickier[4].
> 
> So before Mitaka, the json parsing should go. I would love to
> see an
> interface that all puppet modules would use (solution 2). The
> current
> openstacklib parses openstack client well enough. The neutron
> command
> is not that different and I think there is space for code
> reuse. This
> would be a long term solution. It would bring the advantage of
> having
> only one interface to change if it was decided to use the API
> directly
> for instance[5]
> 
> In the meantime, a quick solution to this bug must be found.
> 
> Looking forward to your comments.
> 
> Regards,
> 
> [1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
> [2]
> 

Re: [openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

[Pradip Mukhopadhyay]

Thanks, Yuriy.

My question was: how can I retrieve the "host@backend#pool" from the
pythonclient API of volume listing? Once I have that, I should use this
method to extract the pool-name.

But how can I access this info? CLI is showing this as in the following
field:

stack@openstack4:~/devstack$ cinder show
e8be1df5-64fb-43fa-aacd-9bebba17fba5
+---+--+
|Property   |
Value |
+---+--+
|  attachments  |
[]  |
|   availability_zone   |
nova |
|bootable   |
false |
|  consistencygroup_id  |
None |
|   created_at  |
2016-01-06T14:21:32.00  |
|  description  |
None |
|   encrypted   |
False |
|   id  |
e8be1df5-64fb-43fa-aacd-9bebba17fba5 |
|metadata   |
{}  |
|migration_status   |
None |
|  multiattach  |
False |
|  name |
None |
| *os-vol-host-attr:host |  openstack4@SCSIBackend#pool1*
|
| os-vol-mig-status-attr:migstat|
None |
| os-vol-mig-status-attr:name_id|
None |
|  os-vol-tenant-attr:tenant_id |
4713f79411844a29b3f53d5fd7502784   |
|   os-volume-replication:driver_data   |
None |
| os-volume-replication:extended_status |
None |
|   replication_status  |
disabled   |
|  size |
1   |
|  snapshot_id  |
None |
|  source_volid |
None |
| status|
available   |
|   updated_at  |
2016-01-06T14:21:34.00  |
|user_id|
89b4af10bc1a473caff22384c844bc6f   |
|  volume_type  |
iscsi_1|
+---+--+



Now in python client API, I am not able to get that field :(



>>> volumes = cinder.volumes.list()

>>> volumes

[]

>>> type(volumes[0])


>>> volumes[0].id

u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'

>>> volumes[0].host
Traceback (most recent call last):
  File "", line 1, in 
  File
"/usr/local/lib/python2.7/dist-packages/cinderclient/openstack/common/apiclient/base.py",
line 464, in __getattr__
raise AttributeError(k)
AttributeError: host
>>> volumes[0].os-vol-host-attr
Traceback (most recent call last):
  File "", line 1, in 
  File
"/usr/local/lib/python2.7/dist-packages/cinderclient/openstack/common/apiclient/base.py",
line 464, in __getattr__
raise AttributeError(k)
AttributeError: os




Essentially what is the way to get the attribute from the API?




Thanks,

Pradip



On Wed, Jan 6, 2016 at 9:28 PM, Yuriy Nesenenko 
wrote:

> Sorry, of course this
> https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L575
>
> On Wed, Jan 6, 2016 at 5:57 PM, Yuriy Nesenenko 
> wrote:
>
>> You can use this function
>> https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L5
>>
>> On Wed, Jan 6, 2016 at 5:44 PM, Pradip Mukhopadhyay <
>> pradip.inte...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>>
>>> From CLI, I can see the host-name in the cinder show command as follows:
>>>
>>> | os-vol-host-attr:host |  openstack4@mySCSIBackend#pool1
>>> |
>>>
>>> How this info can be accessed from the cinder python client?
>>>
>>> I can access other information (id, size, name etc.) as follows:
>>>
>>> >>> volumes = cinder.volumes.list()
>>>
>>> >>> volumes
>>>
>>> []
>>>
>>> >>> volumes[0].id
>>>
>>> u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'
>>>
>>> >>> volumes[0].volume_type
>>>
>>> u'iscsi_1'
>>>
>>>
>>>
>>> Thanks,
>>> Pradip
>>>
>>>
>>>
>>>
>>> __
>>> 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 

Re: [openstack-dev] [chef] deprecation and removal of old branches

[Samuel Cassiba]

I'm +1 on this idea. Looking at other OpenStack projects (Nova, Neutron,
etc.) on GitHub, they only have stable/liberty and stable/kilo, with
anything older dropped. We're already following this support model, so I
think the cleanup should happen, that way there isn't any ambiguity on
which branches are actually supported.



On Wed, Jan 6, 2016 at 5:50 AM, Jan Klare  wrote:

> Hi everybody,
>
> due to a hint on this patch https://review.openstack.org/#/c/264130/1 i
> walked through some of our cookbooks and found that we never actually
> deprecated or removed the old branches for most of our cookbooks. To do
> this, we just need to define which branches exactly we want to keep. As far
> as i remember we agreed on supporting n + 1, which would be stable/kilo and
> stable/liberty imho. I would like to remove all the unsupported branches as
> fast as possible to clean this up. If you think otherwise, please write an
> short answer to this mailing list until the end of this week. If nothing
> prevents the cleanup, i will contact infra at the beginning of the next
> week and ask them to help me with the deletion of all old and unsupported
> branches.
>
> Cheers,
> Jan
>
> —
> irc: jklare
>
> __
> 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] Client checking of server version

[Zane Bitter]

On 06/01/16 08:53, Jay Dobies wrote:

I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access
older versions of servers (that's a pretty simplistic description; see
[2] for the spec).

Before the holiday, Steve Hardy and I were talking about the
complications involved. In my case, there's no good way to differentiate
an older server from a legitimate error.


Hmmm, it's true that you'll likely just get a 400 error, but I'd hope
that the error message is at least somewhat unique.


Unfortunately, it's not, but I don't think it's due to a Heat problem so
much as just the nature of the issue. Here's what's happening.


Ah, OK, so we are silently ignoring invalid data in the request here:

http://git.openstack.org/cgit/openstack/heat/tree/heat/api/openstack/v1/stacks.py#n359

That seems like a bug to me. We could fix that and backport it to at 
least a couple of releases. It would mean that the client would still be 
broken on any older release that didn't have the patch though.



New Client: doesn't do client-side environment resolution before sending
it to the server.

Old Server: expects the environment to be fully populated and ignores
the environment file(s) in the files dict.

The result is the server spits back an error saying that, in my
scenario, there is no type mapping for jdob::Resource1.

The problem is, I get the exact same result for New Client + New Server
+ incomplete environment files.

The reason I was looking for some sort of version checking is to avoid
having logic that just says "Maybe it's because it's an old server,
lemme resolve the environments and send the request again." It feels
really wrong to trigger two create requests when it's the templates
themselves that are wrong.


Agree.


Since the API isn't versioned to the extent that we can leverage that


I mean... it totally is but so far we've chosen not to bump that
version. And we mostly got away with it because we were only adding
functionality. So far.


value, I was looking into using the template versions call. Something
along the lines of:

   supported_versions = hc.template_versions.list()
   version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
   mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of
generalized utility method in the client, under the assumption that
we'll need this sort of check in the future for the same backward
compatibility requirements.

So a few questions:

1. Does anyone strongly disagree to checking supported template versions
as a way of determining the specifics of the server API.


Yes.

Template versions are supposed to be pluggable, and are explicitly under
control of the operator. We shouldn't be systematically inferring
anything about the server version based on this; in general there's no
causal relationship.


2. Does anything like this already exist that I can use?


Not really; there's the "heat build-info" command, but that is also
explicitly under the control of the operator (and is empty by default).


3. If not, any suggestions on where I should put it? I see a
heat.common.utils module but I'm not sure if there is a convention
against that module (or common in general) making live server calls.

Thanks :D


[1] https://review.openstack.org/#/c/239504/
[2] https://review.openstack.org/#/c/226157/

__


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] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Kendall J Nelson]

Hey Martin,

   I thought it might be interesting to get a panel discussion at the
Summit to discuss the lack of consistency/ work towards a more universal
way of using the oslo config generator. Would you be interested? I was
hoping to get someone from Neutron, Nova and Keystone and I could represent
Cinder.

All the Best,
  
   Kendall J. Nelson  
   Software Engineer &
  


Openstack Cinder Contributor
   
   
   
   E-mail: kjnel...@us.ibm.com IBM 
   Cell Phone: (952) 215- 4025 
   IRC Nickname: diablo_rojo 3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   





From:   "Martin Hickey" 
To: jsbry...@electronicjungle.net, "OpenStack Development Mailing
List \(not for usage questions\)"

Date:   01/06/2016 06:34 AM
Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Hi Jay,

+1 on the lack of consistency between projects. When adding the generator
to Neutron, we could not find a consistent pattern so we tried to adopt as
best as possible.

Let me know if you need any feedback on the Neutron experience.

Regards,
Martin


Inactive hide details for "Jay S. Bryant" ---05/01/2016 19:56:25---Ben,
Please see my in-line responses ..."Jay S. Bryant" ---05/01/2016
19:56:25---Ben, Please see my in-line responses ...

From: "Jay S. Bryant" 
To: openst...@nemebean.com, "OpenStack Development Mailing List (not for
usage questions)" 
Date: 05/01/2016 19:56
Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
Sample Configuration Option Files



Ben,

Please see my in-line responses ...

On 01/04/2016 05:43 PM, Ben Nemec wrote:
> On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
>> Hello,
>>
>>
>> In brainstorming ideas for talks at the upcoming summit, I thought about
>> some of the things I had worked on for Cinder and what could still be
>> improved. One of the things I have been looking into is the generation
>> of sample configuration option files. Upon initial research it looks
>> like none of the main projects are doing it the same way.
> I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> (at least) are all using the oslo-config-generator tool for this.  There
> might be some slight variation in how they call it, but they are using
it.
Yes, we know that they are all using oslo-config-generator but there is
not consistency
in how the information that oslo-config-generator needs to do its job is
being created.
Kendall is looking to better understand what we should be doing and try
to bring
greater consistency between the projects.

> I only vaguely recall having discussions about this with Cinder, so I'd
> be interested in a refresher around why Cinder didn't want to do it the
> same way.  I kind of considered it a solved problem.
So, the challenge Cinder has is the fact that there are many
configuration options with all the
different drivers.  We had proposed a static cinder/opts.py file with
hacking checks to ensure
that all new options were pulled into the file.  This was considered
undesirable.  This lead to
the current solution where we are working to find all the possible
option lists to dynamically
create the cinder/opts.py file.  Similar to what we used to do with the
old config generator.

For Nova, having a dynamic solution is less important as they don't have
options changing
as frequently.  It appears that Neutron was less concerned about the
potentially dynamic nature
of options in their drivers.

> For reference:
> Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
> Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
> which calls
>
https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17

> Keystone: https://github.com/openstack/keystone/blob/master/tox.ini#L148
> Etc...
>
>> I thought it
>> might be interesting to get a panel together to talk about how it is
>> done for each project, why it is done that way for each project, and
>> maybe discuss a more universal approach that could be implemented in
>> oslo and used by all the projects. Please let me know if you have
>> knowledge on your project’s method and are interested in being part of a
>> 

Re: [openstack-dev] [heat] Client checking of server version

[Zane Bitter]

On 05/01/16 16:37, Steven Hardy wrote:

On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote:

I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access older
versions of servers (that's a pretty simplistic description; see [2] for the
spec).

Before the holiday, Steve Hardy and I were talking about the complications
involved. In my case, there's no good way to differentiate an older server
from a legitimate error.

Since the API isn't versioned to the extent that we can leverage that value,
I was looking into using the template versions call. Something along the
lines of:

   supported_versions = hc.template_versions.list()
   version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
   mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of generalized
utility method in the client, under the assumption that we'll need this sort
of check in the future for the same backward compatibility requirements.

So a few questions:

1. Does anyone strongly disagree to checking supported template versions as
a way of determining the specifics of the server API.


Ok, so some valid concerns have been raised over deriving things using the
HOT version (although I do still wonder if the environment itself should be
versioned, just like the templates, then we could rev the environment
verion and say it supports a list, vs changing anything in the API, but
that's probably a separate discussion).

Taking a step back for a moment, the original discussion was around
providing transparent access to the new interface via heatclient, but that
isn't actually a hard requirement - the old interface works fine for many
users, so we could just introduce a new interface (which would eventually
become the default, after all non-EOL heat versions released support the
new API argument):

Currently we do:

heat stack-create foo -f foo.yaml -e a.yaml -e b.yaml

And this implies some client-side resolution of the multiple -e arguments.

-e is short for "--environment-file", but we could introduce a new format,
e.g "-E", short for "--environment-files":

heat stack-create foo -f foo.yaml -E a.yaml -E b.yaml

This option would work the same way as the current interface, but it would
pass the files unmodified for resolution inside heat (by using the new API
format), and as it's opt-in, it's leaving all the current heatclient
interfaces alone without any internal fallback logic?


That would certainly work, but it sounds like a usability/support 
nightmare :(


Is there a reason we wouldn't consider bumping the API version to 1.1 
for this? We'll have to figure out how to do it some time.


cheers,
Zane.

__
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] [QA] Mitaka Code Sprint

[Matthew Treinish]

Hi Everyone,

As we've done the past 2 cycles we'll be having another QA code sprint this
cycle. I've felt these sprints have been very effective in the past and helped
us make good progress on several work items in a short amount of time, so I
think having another sprint will work well again for Mitaka.

The sprint will take place on February 22-24th, Dell has offered to sponsor the
event and it'll be held at Microsoft's New England Research and Development
Center in Cambridge, Massachusetts.

More details can be found on the following wiki page, and if you're planning on
attending please sign up using the wiki page:

https://wiki.openstack.org/wiki/QA/CodeSprintMitakaBoston

Thanks,

Matthew Treinish


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] [puppet] proposing Alex Schultz part of core team

[Yanis Guenane]

+1

On 01/05/2016 06:55 PM, Emilien Macchi wrote:
> Hi,
>
> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> the last months in the Puppet OpenStack group:
> * He's doing a lot of reviews and they are very valuable. He's in my
> opinion fully aware of our conventions and has nice insights to improve
> our modules.
> * He's very helpful to work on bugs or new features when needed.
> * Always present during meetings and actively participating.
> * Always on IRC, he never hesitates to give a hand on something or help
> people.
>
> I think we're very lucky to have Alex part of our group and I would like
> to promote him core reviewer of all our modules.
>
> Team, please vote if you like the idea,
>
> 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


__
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] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[liusheng]

Hi Ifat,

what way do you want to use the alarm change notifications? using events 
from Ceilometer API or directly collecting the notifications from 
message bus?
if we configure Ceilometer to listen the notifications from aodh, the 
notifications about alarm changes will be converted to events and stored 
in Ceilometer storage. if you want to use the events about alarm 
changes, the same info can be queried by "alarm-history" API, may be you 
want to do aggregation on events data ?


Thanks
Liu sheng

在 2016/1/5 21:37, AFEK, Ifat (Ifat) 写道:

-Original Message-
From: gord chung [mailto:g...@live.ca]
Sent: Friday, December 11, 2015 10:17 PM

the original reason this was implemented i believe was to track alarm
state changes as an event in ceilometer events. i still see this as a
valid use case but it does duplicate some of the functionality of alarm
history.

i think the main items are to not flood the message bus with messages
that no one is listening to. but if there is a use case for it, i'm
happy to see it remain (and improved).

you can check the patch that Liusheng referenced, but the basic concept
is as mentioned: send message when an alarm state is changed.


Hi Gord,

We had some further discussions about this issue in Vitrage team, and we 
decided we do want to use Aodh notifications about alarm state changes.

One reason is that we want to be notified about every alarm, yet we don't want 
to register our web-hook on each alarm definition separately. The other reason 
is that we already listen to message bus notifications of other openstack 
components (like nova), and we would like to handle aodh notifications the same 
way we handle all other openstack notifications.

We will be happy if this code remains.

Thanks,
Ifat.


__
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] [puppet] proposing Alex Schultz part of core team

[Cody Herriges]

Emilien Macchi wrote:
> Hi,
> 
> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> the last months in the Puppet OpenStack group:
> * He's doing a lot of reviews and they are very valuable. He's in my
> opinion fully aware of our conventions and has nice insights to improve
> our modules.
> * He's very helpful to work on bugs or new features when needed.
> * Always present during meetings and actively participating.
> * Always on IRC, he never hesitates to give a hand on something or help
> people.
> 
> I think we're very lucky to have Alex part of our group and I would like
> to promote him core reviewer of all our modules.
> 
> Team, please vote if you like the idea,
> 

All positive here. +1.


-- 
Cody



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

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

[Mike Bayer]

On 01/06/2016 09:11 AM, Roman Podoliaka wrote:
> Hi Mike,
> 
> Thank you for this brilliant analysis! We've been seeing such timeout
> errors in downstream periodically and this is the first time someone
> has analysed the root cause thoroughly.
> 
> On Fri, Dec 18, 2015 at 10:33 PM, Mike Bayer  wrote:
> 
>> But if we only have a super low number of greenlets and only a few dozen
>> workers, what happens if we have more than 240 requests come in at once,
>> aren't those connections going to get rejected?  No way!  eventlet's
>> networking system is better than that, those connection requests just
>> get queued up in any case, waiting for a greenlet to be available.  Play
>> with the script and its settings to see.
> 
> Right, it must be controlled by the backlog argument value here:
> 
> https://github.com/openstack/oslo.service/blob/master/oslo_service/wsgi.py#L80

oh wow, totally missed that!  But, how does backlog here interact with
multiple processes?   E.g. all workers are saturated, it will place a
waiting connection onto a random greenlet which then has to wait?  It
would be better if the "backlog" were pushed up to the parent process,
not sure if that's possible?



__
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] [trove] Adding support for HBase in Trove

[Amrith Kumar]

TL;DR Should Trove treat HBase as a special database because one use case is as 
part of a large multi-node Hadoop cluster, and therefore either not support it 
at all, or necessarily use Sahara to provision and manage a cluster? There are 
pro's and con's and it is argued that the con's outweigh the pro's and a 
blueprint/specification, and an implementation for basic Trove support for 
HBase independent of Sahara has been submitted for review. See [3], [4] and 
[5]. The benefits include the ability to provide the commonly used (in 
development) standalone mode operation, and eliminate the dependency on an 
additional OpenStack project thereby simplifying deployment. Comments and 
feedback are welcome on the implementation, as well as the specification and 
the approach.

The long version follows below.

The OpenStack Trove mission is to provide scalable and reliable Cloud Database 
as a Service provisioning functionality for both relational and non-relational 
database engines, and to continue to improve its fully-featured and extensible 
open source framework [1].

An important aspect of the Trove value proposition is that it provides a common 
control plane, a common API, and a common set of abstractions are used to 
manage a number of different relational, and non-relational database 
technologies. The common API contains primitives to create database instances 
and clusters of a number of databases including MySQL (MariaDB, Percona too), 
PostgreSQL, MongoDB, Cassandra, CouchDB, Couchbase, IBM DB2, Vertica, and 
Redis. 

Cluster support is also available for a number of databases including MongoDB, 
Percona XtraDB cluster and Vertica, with more to come imminently. 

In effect, Trove is a framework for provisioning and managing the lifecycle of 
a number of different database technologies; it provides only the control 
plane. Users can do things like provisioning instances and clusters, resizing 
them, taking backups and creating new instances and clusters from previous 
backups, establish and manage complex topologies including replication and 
clustering, and resize instances and clusters. 

Trove does interfere with the data plane, the applications interact directly 
with the database using the native API's for each database technology.

Users of OpenStack look to Trove to provide a consistent set of interfaces for 
managing their database resources in a variety of use-cases ranging from 
small-scale prototyping, development, testing, and all the way through 
production. Apache HBase is an open-source, distributed, versioned, 
non-relational database [2] and users of HBase face many of the challenges that 
Trove addresses for other databases. Therefore adding support for HBase in 
Trove seems not only reasonable, but also consistent with the goal of the 
(Trove) project.

A spec proposing the addition of HBase support for Trove was submitted [3] and 
a first phase of code implementing this HBase support has also been submitted 
for review [4], [5]. The process that has been followed is consistent with 
other Trove datastores; add basic support and then progressively augment it in 
subsequent releases. The code submitted allows you to provision an HBase 
instance (which will launch on a Nova instance), build an HBase guest image 
using the elements provided, resize the storage and the instance, take a 
"backup" of the instance and store that backup on Swift, and at a later time 
you can launch a new instance from that "backup".

One can operate HBase with or without HDFS; in fact HBase documents the 
standalone mode of operation [6] where HBase is completely operational on a 
single node and data is stored on the local file system. This standalone mode 
provides a very useful construct for development and testing, and at a later 
stage an application can be seamlessly migrated to work with an HBase 
installation of some other "run mode" like "Fully Distributed".

Code submitted in [4] and [5] as described in [3] implement support for two 
modes of operation namely "Standalone" and "Pseudo-Distributed". At a later 
stage, support will be added for "Fully Distributed" consistent with the way in 
which clustering support was delivered for other datastores like MySQL and 
MongoDB.

Some have opined that Trove should not directly get into the business of 
orchestrating Hadoop Clusters or anything to do with HBase, arguing that this 
is something that Sahara already does, and should remain the sole domain of 
Sahara.

I believe that since HBase is perfectly operable without HDFS, it seems 
inappropriate to tightly couple HBase with Sahara whose primary motivation is 
to provision 'data-intensive application clusters' [7]. Furthermore, as we have 
found with other datastores, it is my belief that having a common 
implementation model across multiple deployment topologies is a benefit for 
Trove. Other considerations such as similarity to other databases supported by 
Trove motivated a choice as 

Re: [openstack-dev] [puppet] proposing Alex Schultz part of core team

[Alex Schultz]

On Wed, Jan 6, 2016 at 4:40 PM, Emilien Macchi  wrote:
>
>
> On 01/05/2016 12:55 PM, Emilien Macchi wrote:
>> Hi,
>>
>> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
>> the last months in the Puppet OpenStack group:
>> * He's doing a lot of reviews and they are very valuable. He's in my
>> opinion fully aware of our conventions and has nice insights to improve
>> our modules.
>> * He's very helpful to work on bugs or new features when needed.
>> * Always present during meetings and actively participating.
>> * Always on IRC, he never hesitates to give a hand on something or help
>> people.
>>
>> I think we're very lucky to have Alex part of our group and I would like
>> to promote him core reviewer of all our modules.
>>
>> Team, please vote if you like the idea,
>
> Quite enough positive votes.
>
> Welcome Alex and thanks for your hard work!
> --
> Emilien Macchi
>

Thanks everyone. I look forward to continuing to improve the puppet modules.

-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] [trove] Adding support for HBase in Trove

[Fox, Kevin M]

just my 2 cents... I think you can do both. The great thing about Trove is that 
its providing an abstract api so users just deal with provisioning db's, 
scaling db's, etc.

Having a simple plugin that doesn't depend on all of Sahara, for the case a 
user only wants a single node HBase does make sense. Its much easier for an Op 
to support that case if thats all their users ever want. But, thats probably as 
far as that plugin ever should go. If you need scale up/down, etc, then your 
starting to reimplement large swaths of Sahara, and like the Cinder plugin for 
Nova, there could be a plugin that works identically to the stand alone one 
that converts the same api over to a Sahara compatible one. You then farm the 
work over to Sahara.

Then, its up to the ops to choose features and the overhead of supporting 
Sahara, or not, and you don't have to support implementing a whole cluster 
management system for Trove that already exists.

Thanks,
Kevin

From: Amrith Kumar [amr...@tesora.com]
Sent: Wednesday, January 06, 2016 3:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove] Adding support for HBase in Trove

TL;DR Should Trove treat HBase as a special database because one use case is as 
part of a large multi-node Hadoop cluster, and therefore either not support it 
at all, or necessarily use Sahara to provision and manage a cluster? There are 
pro's and con's and it is argued that the con's outweigh the pro's and a 
blueprint/specification, and an implementation for basic Trove support for 
HBase independent of Sahara has been submitted for review. See [3], [4] and 
[5]. The benefits include the ability to provide the commonly used (in 
development) standalone mode operation, and eliminate the dependency on an 
additional OpenStack project thereby simplifying deployment. Comments and 
feedback are welcome on the implementation, as well as the specification and 
the approach.

The long version follows below.

The OpenStack Trove mission is to provide scalable and reliable Cloud Database 
as a Service provisioning functionality for both relational and non-relational 
database engines, and to continue to improve its fully-featured and extensible 
open source framework [1].

An important aspect of the Trove value proposition is that it provides a common 
control plane, a common API, and a common set of abstractions are used to 
manage a number of different relational, and non-relational database 
technologies. The common API contains primitives to create database instances 
and clusters of a number of databases including MySQL (MariaDB, Percona too), 
PostgreSQL, MongoDB, Cassandra, CouchDB, Couchbase, IBM DB2, Vertica, and Redis.

Cluster support is also available for a number of databases including MongoDB, 
Percona XtraDB cluster and Vertica, with more to come imminently.

In effect, Trove is a framework for provisioning and managing the lifecycle of 
a number of different database technologies; it provides only the control 
plane. Users can do things like provisioning instances and clusters, resizing 
them, taking backups and creating new instances and clusters from previous 
backups, establish and manage complex topologies including replication and 
clustering, and resize instances and clusters.

Trove does interfere with the data plane, the applications interact directly 
with the database using the native API's for each database technology.

Users of OpenStack look to Trove to provide a consistent set of interfaces for 
managing their database resources in a variety of use-cases ranging from 
small-scale prototyping, development, testing, and all the way through 
production. Apache HBase is an open-source, distributed, versioned, 
non-relational database [2] and users of HBase face many of the challenges that 
Trove addresses for other databases. Therefore adding support for HBase in 
Trove seems not only reasonable, but also consistent with the goal of the 
(Trove) project.

A spec proposing the addition of HBase support for Trove was submitted [3] and 
a first phase of code implementing this HBase support has also been submitted 
for review [4], [5]. The process that has been followed is consistent with 
other Trove datastores; add basic support and then progressively augment it in 
subsequent releases. The code submitted allows you to provision an HBase 
instance (which will launch on a Nova instance), build an HBase guest image 
using the elements provided, resize the storage and the instance, take a 
"backup" of the instance and store that backup on Swift, and at a later time 
you can launch a new instance from that "backup".

One can operate HBase with or without HDFS; in fact HBase documents the 
standalone mode of operation [6] where HBase is completely operational on a 
single node and data is stored on the local file system. This standalone mode 
provides a very useful construct for development and 

Re: [openstack-dev] [puppet] proposing Alex Schultz part of core team

[Iury Gregory]

Congrats Alex! :D

2016-01-06 20:59 GMT-03:00 Alex Schultz :

> On Wed, Jan 6, 2016 at 4:40 PM, Emilien Macchi  wrote:
> >
> >
> > On 01/05/2016 12:55 PM, Emilien Macchi wrote:
> >> Hi,
> >>
> >> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> >> the last months in the Puppet OpenStack group:
> >> * He's doing a lot of reviews and they are very valuable. He's in my
> >> opinion fully aware of our conventions and has nice insights to improve
> >> our modules.
> >> * He's very helpful to work on bugs or new features when needed.
> >> * Always present during meetings and actively participating.
> >> * Always on IRC, he never hesitates to give a hand on something or help
> >> people.
> >>
> >> I think we're very lucky to have Alex part of our group and I would like
> >> to promote him core reviewer of all our modules.
> >>
> >> Team, please vote if you like the idea,
> >
> > Quite enough positive votes.
> >
> > Welcome Alex and thanks for your hard work!
> > --
> > Emilien Macchi
> >
>
> Thanks everyone. I look forward to continuing to improve the puppet
> modules.
>
> -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
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Gate failure

[Kevin Benton]

Ugh, this test is racey. I should have paid closer attention before I
+2'ed, my bad.

It just iterates external ports and uses an IP not in that list so if
another test grabbed the same IP, the floating IP creation request
specifying that IP will fail.

Revert proposed here: https://review.openstack.org/#/c/264573/

On Wed, Jan 6, 2016 at 9:00 PM, Clark Boylan  wrote:

> On Wed, Jan 6, 2016, at 08:48 PM, Henry Gessau wrote:
> > Armando M.  wrote:
> > > Hi folks,
> > >
> > > Due to [1], Neutron related jobs (api, and lbaas) are failing. Please
> hold
> > > your +A button until the issue is resolved.
> > >
> > > Thanks,
> > > Armando
> > >
> > > [1] https://review.openstack.org/#/c/256164/
> >
> > That fix has merged, but now we have a new issue [2] in the api job. :(
> >
> > [2] https://bugs.launchpad.net/neutron/+bug/1531706
> >
> It appears that that test class at least is allocating unused floating
> IPs in resource_setup(). At the very least you can probably stop
> overallocating to give yourself some breathing room. I do not think this
> explains how an entire /24 of IPs gets used up so there may be a leak
> elsewhere.
>
> Clark
>
> __
> 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
>



-- 
Kevin Benton
__
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] [QA] Meeting Thursday January 7th at 9:00 UTC

[Ken'ichi Ohmichi]

Hi everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, January 7th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_7th_2016_.281700_UTC.29

Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones the next
meeting will be at:

03:00 EDT
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

Thanks
Ken Ohmichi

__
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] Gate failure

[Clark Boylan]

On Wed, Jan 6, 2016, at 08:48 PM, Henry Gessau wrote:
> Armando M.  wrote:
> > Hi folks,
> > 
> > Due to [1], Neutron related jobs (api, and lbaas) are failing. Please hold
> > your +A button until the issue is resolved.
> > 
> > Thanks,
> > Armando 
> > 
> > [1] https://review.openstack.org/#/c/256164/
> 
> That fix has merged, but now we have a new issue [2] in the api job. :(
> 
> [2] https://bugs.launchpad.net/neutron/+bug/1531706
> 
It appears that that test class at least is allocating unused floating
IPs in resource_setup(). At the very least you can probably stop
overallocating to give yourself some breathing room. I do not think this
explains how an entire /24 of IPs gets used up so there may be a leak
elsewhere.

Clark

__
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] [QA] Meeting Thursday January 7th at 9:00 UTC

[Ken'ichi Ohmichi]

Sorry, as 
http://lists.openstack.org/pipermail/openstack-dev/2016-January/083397.html
the next meeting should be scheduled at 1700 UTC, not 0900 UTC.

Thanks


2016-01-07 11:27 GMT+09:00 Ken'ichi Ohmichi :
> Hi everyone,
>
> Please reminder that the weekly OpenStack QA team IRC meeting will be
> Thursday, January 7th at 9:00 UTC in the #openstack-meeting channel.
>
> The agenda for the meeting can be found here:
>
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_7th_2016_.281700_UTC.29
>
> Anyone is welcome to add an item to the agenda.
>
> To help people figure out what time 9:00 UTC is in other timezones the next
> meeting will be at:
>
> 03:00 EDT
> 18:00 JST
> 18:30 ACST
> 11:00 CEST
> 04:00 CDT
> 02:00 PDT
>
> Thanks
> Ken Ohmichi

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

[openstack-dev] [neutron][gate] neutron-dvsm-api gate failures

[Gariganti, Sudhakar Babu (ESSN - HP Networking R)]

Hi All,

Not sure if this already is being looked into. neutron-dvsm-api gate has been 
failing consistently offlate.

The only test failing in the gate is 
neutron.tests.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON.
 test_create_floatingip_with_specified_ip_address

There are quite a few reviews which seem to be affected by this.
   https://review.openstack.org/222522
   https://review.openstack.org/228026
   https://review.openstack.org/264438

Can somebody help fixing the gate.

-Sudhakar.
__
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] [openstacksdk][nose] Namespace conflict?

[Qiming Teng]

Hi,

We have been using python-openstacksdk for some time, so far so good.
Just encountered a problem when running latest devstack environment.
The error looks something like:

$ python testsdk.py
Traceback (most recent call last):
  File "testsdk.py", line 2, in 
from openstack import profile
ImportError: cannot import name profile

After examining the /usr/lib/python2.7/site-packages directory, I found
the package 'openstack.nose-plugin', which is using the 'openstack'
namespace. I have no idea what this package is about, why it was
installed and maybe I shouldn't care. The real problem is that this
package is using the 'openstack' namespace. It has only one file:

  /usr/lib/python2.7/site-packages/openstack/nose_plugin.py

This is conflicting with openstacksdk, which was installed somewhere
else. openstacksdk is also using this namespace.

Suggestions to solve this conflict?

Thanks in advance.

Regards,
  Qiming 


__
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] deprecation and removal of old branches

[JJ Asghar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 1/6/16 10:22 AM, Samuel Cassiba wrote:
> I'm +1 on this idea. Looking at other OpenStack projects (Nova, Neutron,
> etc.) on GitHub, they only have stable/liberty and stable/kilo

Sounds good to me too.


- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWjbnBAAoJEDZbxzMH0+jTbTcP/i/RbxfmQ2T3wasWUKLup9Y3
bbsiUcfocw40ZT2Y/i/fLiH+mGfIRcvXTLMkYdwji7jhoes2Vt3l+S/CmDR9kb59
hqxiIft/6kfW3JLjtjkAZtZ5xwa+QSN8DY4aZnnVU9mjdCgDH0DZRuwOZcERZH0Q
6gQeIFp0udGVLfDaF32mEdKRRbSlRil6reciDg6W7g+/1lCys8H7ig0/5rqQxE0o
GmKxyGOlEnpPjpVQz1JeBadktHNjRPOJ1ihiHmC8XusMdg0FDppiJUmLd8gmLFNY
hRpD2QFHjzlsy+7u5chsiN+ctjawuEZsHCeDD3UDAiSQjptHQy8jw7gl+V4nQry6
SSpRYkdfV8k5Pf3nsJ8Yyt0SqYggnqjok7DQ9VxEiLdMyQbG+DE7CQI6w/TxmniC
oiScygu8dCh+KUZ7OXUSBWquHWln6eQlWgJNqv/o4UxZJl9NLxkhDU7OgvMvvCjl
I1Gx2BdNIcknZhG3KfzUfj1j97whVJkJyHvWMem+pj2BXFY3eIcAkHKx9nHO+cNy
hBFWoCUXGJHxsUMHhDH7FhbuvQR8qCHVaRvmMaKMyO+6S+5R1Q/L4dYvxZjHNScn
3JcWaC5+k91Acj6DYrv4hxszUBtM+KpyG/13Z9ed+qwd6QxH8beKD82kES1ZEl+P
crT1uNDOT9ToRLWRHEwd
=2adb
-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][python-client-api] Retrieve host-name attribute of Cinder Volume

[Pradip Mukhopadhyay]

Thanks a ton Duncan. It's just awesome.

>>> volumes[0].__dict__['os-vol-host-attr:host']
u'openstack4@cmodeSCSIBackend#pool1'
>>>



--pradip



On Thu, Jan 7, 2016 at 12:53 AM, Duncan Thomas 
wrote:

> Try client.volumes..get(id).__dict__['
>
> *os-vol-host-attr:host'] *
>
> *Ugly, but it seems to work*
>
> On 6 January 2016 at 18:20, Pradip Mukhopadhyay 
> wrote:
>
>> Thanks, Yuriy.
>>
>> My question was: how can I retrieve the "host@backend#pool" from the
>> pythonclient API of volume listing? Once I have that, I should use this
>> method to extract the pool-name.
>>
>> But how can I access this info? CLI is showing this as in the following
>> field:
>>
>> stack@openstack4:~/devstack$ cinder show
>> e8be1df5-64fb-43fa-aacd-9bebba17fba5
>>
>> +---+--+
>> |Property   |
>> Value |
>>
>> +---+--+
>> |  attachments  |
>> []  |
>> |   availability_zone   |
>> nova |
>> |bootable   |
>> false |
>> |  consistencygroup_id  |
>> None |
>> |   created_at  |
>> 2016-01-06T14:21:32.00  |
>> |  description  |
>> None |
>> |   encrypted   |
>> False |
>> |   id  |
>> e8be1df5-64fb-43fa-aacd-9bebba17fba5 |
>> |metadata   |
>> {}  |
>> |migration_status   |
>> None |
>> |  multiattach  |
>> False |
>> |  name |
>> None |
>> | *os-vol-host-attr:host |  openstack4@SCSIBackend#pool1*
>> |
>> | os-vol-mig-status-attr:migstat|
>> None |
>> | os-vol-mig-status-attr:name_id|
>> None |
>> |  os-vol-tenant-attr:tenant_id |
>> 4713f79411844a29b3f53d5fd7502784   |
>> |   os-volume-replication:driver_data   |
>> None |
>> | os-volume-replication:extended_status |
>> None |
>> |   replication_status  |
>> disabled   |
>> |  size |
>> 1   |
>> |  snapshot_id  |
>> None |
>> |  source_volid |
>> None |
>> | status|
>> available   |
>> |   updated_at  |
>> 2016-01-06T14:21:34.00  |
>> |user_id|
>> 89b4af10bc1a473caff22384c844bc6f   |
>> |  volume_type  |
>> iscsi_1|
>>
>> +---+--+
>>
>>
>>
>> Now in python client API, I am not able to get that field :(
>>
>>
>>
>> >>> volumes = cinder.volumes.list()
>>
>> >>> volumes
>>
>> []
>>
>> >>> type(volumes[0])
>> 
>>
>> >>> volumes[0].id
>>
>> u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'
>>
>> >>> volumes[0].host
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File
>> "/usr/local/lib/python2.7/dist-packages/cinderclient/openstack/common/apiclient/base.py",
>> line 464, in __getattr__
>> raise AttributeError(k)
>> AttributeError: host
>> >>> volumes[0].os-vol-host-attr
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File
>> "/usr/local/lib/python2.7/dist-packages/cinderclient/openstack/common/apiclient/base.py",
>> line 464, in __getattr__
>> raise AttributeError(k)
>> AttributeError: os
>>
>>
>>
>>
>> Essentially what is the way to get the attribute from the API?
>>
>>
>>
>>
>> Thanks,
>>
>> Pradip
>>
>>
>>
>> On Wed, Jan 6, 2016 at 9:28 PM, Yuriy Nesenenko 
>> wrote:
>>
>>> Sorry, of course this
>>> https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L575
>>>
>>> On Wed, Jan 6, 2016 at 5:57 PM, Yuriy Nesenenko >> > wrote:
>>>
 You can use this function

 https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L5

 On Wed, Jan 6, 2016 at 5:44 PM, Pradip Mukhopadhyay <
 pradip.inte...@gmail.com> wrote:

> Hello,
>
>
> From CLI, I can see the host-name in the cinder show command as
> follows:
>
> | os-vol-host-attr:host |  openstack4@mySCSIBackend#pool1
> |
>
> How this info can be accessed from the cinder python client?
>
> I can access other information (id, size, name etc.) as follows:
>
> >>> volumes = cinder.volumes.list()
>
> >>> volumes
>
> []
>
> >>> volumes[0].id
>
> 

Re: [openstack-dev] [trove] Adding support for HBase in Trove

[Amrith Kumar]

Kevin Fox writes:

> as far as that plugin ever should go. If you need scale up/down, etc, then
> your starting to reimplement large swaths of Sahara, and like the Cinder
> plugin for Nova, there could be a plugin that works identically to the stand
> alone one that converts the same api over to a Sahara compatible one. You
> then farm the work over to Sahara.

I believe that this is not the case. The entire framework for integration with 
Cinder, Nova etc., already exists in Trove. 

Recall that trove already deals with about a dozen databases, several of which 
have support for clusters. 

The code to add HBase support to trove doesn't have to implement all of this 
framework that already exists. 

All that is being implemented is (literally) a Trove 'plugin' for HBase and a 
mechanism to build a HBase guest image.

-amrith

> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: Wednesday, January 06, 2016 7:32 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> just my 2 cents... I think you can do both. The great thing about Trove is 
> that
> its providing an abstract api so users just deal with provisioning db's, 
> scaling
> db's, etc.
> 
> Having a simple plugin that doesn't depend on all of Sahara, for the case a
> user only wants a single node HBase does make sense. Its much easier for an
> Op to support that case if thats all their users ever want. But, thats 
> probably
> as far as that plugin ever should go. If you need scale up/down, etc, then
> your starting to reimplement large swaths of Sahara, and like the Cinder
> plugin for Nova, there could be a plugin that works identically to the stand
> alone one that converts the same api over to a Sahara compatible one. You
> then farm the work over to Sahara.
> 
> Then, its up to the ops to choose features and the overhead of supporting
> Sahara, or not, and you don't have to support implementing a whole cluster
> management system for Trove that already exists.
> 
> Thanks,
> Kevin
> 
> From: Amrith Kumar [amr...@tesora.com]
> Sent: Wednesday, January 06, 2016 3:15 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> TL;DR Should Trove treat HBase as a special database because one use case is
> as part of a large multi-node Hadoop cluster, and therefore either not
> support it at all, or necessarily use Sahara to provision and manage a 
> cluster?
> There are pro's and con's and it is argued that the con's outweigh the pro's
> and a blueprint/specification, and an implementation for basic Trove support
> for HBase independent of Sahara has been submitted for review. See [3], [4]
> and [5]. The benefits include the ability to provide the commonly used (in
> development) standalone mode operation, and eliminate the dependency
> on an additional OpenStack project thereby simplifying deployment.
> Comments and feedback are welcome on the implementation, as well as the
> specification and the approach.
> 
> The long version follows below.
> 
> The OpenStack Trove mission is to provide scalable and reliable Cloud
> Database as a Service provisioning functionality for both relational and non-
> relational database engines, and to continue to improve its fully-featured
> and extensible open source framework [1].
> 
> An important aspect of the Trove value proposition is that it provides a
> common control plane, a common API, and a common set of abstractions are
> used to manage a number of different relational, and non-relational
> database technologies. The common API contains primitives to create
> database instances and clusters of a number of databases including MySQL
> (MariaDB, Percona too), PostgreSQL, MongoDB, Cassandra, CouchDB,
> Couchbase, IBM DB2, Vertica, and Redis.
> 
> Cluster support is also available for a number of databases including
> MongoDB, Percona XtraDB cluster and Vertica, with more to come
> imminently.
> 
> In effect, Trove is a framework for provisioning and managing the lifecycle of
> a number of different database technologies; it provides only the control
> plane. Users can do things like provisioning instances and clusters, resizing
> them, taking backups and creating new instances and clusters from previous
> backups, establish and manage complex topologies including replication and
> clustering, and resize instances and clusters.
> 
> Trove does interfere with the data plane, the applications interact directly
> with the database using the native API's for each database technology.
> 
> Users of OpenStack look to Trove to provide a consistent set of interfaces for
> managing their database resources in a variety of use-cases ranging from
> small-scale prototyping, development, testing, and all the way through
> production. 

Re: [openstack-dev] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[liusheng]

Hi Ifat,

I meant new API to get statistcs on events data, like "statistics" API 
on samples data, that has been discussed but not implemented yet.  
because I thought you'd like to use events data about alarm changes. if 
you want to directly use the notification messages just because you want 
to be real-time notified, how about gordon's suggestion ?


Thanks
Liu sheng

在 2016/1/6 21:11, AFEK, Ifat (Ifat) 写道:

Hi,

We would like to be notified once an alarm state is changed, so we prefer using 
the message bus.
As far as I understand, ceilometer and aodh APIs do not provide immediate 
notifications. If we use the APIs, we will have to poll the data periodically 
and look for changes, and we will get them in delay. By listening to the 
message bus we can get the notifications immediately, like we do with other 
openstack components.

Is there an advantage in using the API instead?
And what do you mean by "aggregation on events data"? what kind of aggregations 
can we do?

Thanks,
Ifat.


-Original Message-
From: liusheng [mailto:liusheng1...@126.com]
Sent: Wednesday, January 06, 2016 10:10 AM

Hi Ifat,

what way do you want to use the alarm change notifications? using
events from Ceilometer API or directly collecting the notifications
from message bus?
if we configure Ceilometer to listen the notifications from aodh, the
notifications about alarm changes will be converted to events and
stored in Ceilometer storage. if you want to use the events about alarm
changes, the same info can be queried by "alarm-history" API, may be
you want to do aggregation on events data ?

Thanks
Liu sheng

在 2016/1/5 21:37, AFEK, Ifat (Ifat) 写道:

-Original Message-
From: gord chung [mailto:g...@live.ca]
Sent: Friday, December 11, 2015 10:17 PM

the original reason this was implemented i believe was to track

alarm

state changes as an event in ceilometer events. i still see this as

a

valid use case but it does duplicate some of the functionality of
alarm history.

i think the main items are to not flood the message bus with

messages

that no one is listening to. but if there is a use case for it, i'm
happy to see it remain (and improved).

you can check the patch that Liusheng referenced, but the basic
concept is as mentioned: send message when an alarm state is

changed.

Hi Gord,

We had some further discussions about this issue in Vitrage team, and

we decided we do want to use Aodh notifications about alarm state
changes.

One reason is that we want to be notified about every alarm, yet we

don't want to register our web-hook on each alarm definition
separately. The other reason is that we already listen to message bus
notifications of other openstack components (like nova), and we would
like to handle aodh notifications the same way we handle all other
openstack notifications.

We will be happy if this code remains.

Thanks,
Ifat.

__
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] [Horizon] naming of Javascript bits

[Rajat Vig]

Richard

My preference is the same as what you've got there.
Fully namespaced Services and Controller allow for better reusability and
possibly maintainability.
If all "deleteService" were named just that, it'll be mighty confusing to
use it in other places.

With regards to tying the folder path and the Service/Controller I'd mostly
go with that as that encourages simpler rules on how to namespace.

For the particular patch you mentioned, the namespaces had a bit of churn
which is sort of reflected in what exists in the patch now.

If we decide a convention, then we can go and change the bits when the
files change next.

-Rajat



On Wed, Jan 6, 2016 at 10:30 PM Richard Jones 
wrote:

> Hi Horizon folks,
>
> We've been pretty good about namespacing the new angular code (to the
> extreme of having a bunch of very similar module files littered around, but
> that's angular/JS for you, so I'm not going to go on about it ).
>
> Anyhoo. One thing I've noticed is that the services, factories and
> controllers inside those modules aren't being consistently named. We have
> got a mix of:
>
> Launch Instance:
>
>   .module('horizon.dashboard.project.workflow.launch-instance')
>   .factory('launchInstanceModel', launchInstanceModel);
>
> The new Images panel:
>
>   .module('horizon.app.core.images')
>   .factory('horizon.app.core.images.row-actions.service', rowActions);
>
> and in the same patch:
>
>   .module('horizon.app.core.images')
>   .factory('horizon.app.core.images.actions.deleteService', deleteService);
>
> I actually prefer the second form because it matches the filename
> ("row-actions.service.js") even though the module namespace doesn't match
> the file path ("/static/app/core/images/table/").
>
> Your thoughts?
>
>
>  Richard
> __
> 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] [horizon][help][angularjs] facing issue with my angularjs patch

[masco]

Hello All,
I am I am adding QoS panel in angularjs.
i have submitted a patch for adding panel with delete action button in 
this patch https://review.openstack.org/#/c/247997/ it is working as 
expected.
over that i have added for edit QoS policy action in this patch 
https://review.openstack.org/#/c/259022/

this not working as expected.
the problem is:
when i am clicking the edit policy button the form widget is opening but 
there is no content in that.

no error in console too.
anybody familiar with angularjs can look into this patch and correct me 
where i am wrong.
it is blocking me to add other action buttons for the same. so any help 
will be very much appreciated.

how to test the QoS patch is available in commit message.

Thanks in advance,
Masco.

__
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] Gate failure

[Kevin Benton]

Ah, that was a bit misleading. We're not leaking any floating IPs. The
create method for them adds them to a list that is cleaned up on teardown.

The issue was that the get_unused_ip method was iterating over v4 and v6
subnets. So if it happened to pick a v6 subnet, it would cause the test to
request a floating IP address with a v6 IP address, which isn't valid.

Fix is up here: https://review.openstack.org/264599

On Wed, Jan 6, 2016 at 10:03 PM, Kevin Benton  wrote:

> I spoke too soon. The test is racey and needs to be fixed, but that wasn't
> the cause of this failure. Floating IPs are being leaked as Clark
> suggested.  I'm looking into it now.
>
> On Wed, Jan 6, 2016 at 9:09 PM, Kevin Benton  wrote:
>
>> Ugh, this test is racey. I should have paid closer attention before I
>> +2'ed, my bad.
>>
>> It just iterates external ports and uses an IP not in that list so if
>> another test grabbed the same IP, the floating IP creation request
>> specifying that IP will fail.
>>
>> Revert proposed here: https://review.openstack.org/#/c/264573/
>>
>> On Wed, Jan 6, 2016 at 9:00 PM, Clark Boylan 
>> wrote:
>>
>>> On Wed, Jan 6, 2016, at 08:48 PM, Henry Gessau wrote:
>>> > Armando M.  wrote:
>>> > > Hi folks,
>>> > >
>>> > > Due to [1], Neutron related jobs (api, and lbaas) are failing.
>>> Please hold
>>> > > your +A button until the issue is resolved.
>>> > >
>>> > > Thanks,
>>> > > Armando
>>> > >
>>> > > [1] https://review.openstack.org/#/c/256164/
>>> >
>>> > That fix has merged, but now we have a new issue [2] in the api job. :(
>>> >
>>> > [2] https://bugs.launchpad.net/neutron/+bug/1531706
>>> >
>>> It appears that that test class at least is allocating unused floating
>>> IPs in resource_setup(). At the very least you can probably stop
>>> overallocating to give yourself some breathing room. I do not think this
>>> explains how an entire /24 of IPs gets used up so there may be a leak
>>> elsewhere.
>>>
>>> Clark
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>>
>> --
>> Kevin Benton
>>
>
>
>
> --
> Kevin Benton
>



-- 
Kevin Benton
__
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] proposing Alex Schultz part of core team

[Emilien Macchi]

On 01/05/2016 12:55 PM, Emilien Macchi wrote:
> Hi,
> 
> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> the last months in the Puppet OpenStack group:
> * He's doing a lot of reviews and they are very valuable. He's in my
> opinion fully aware of our conventions and has nice insights to improve
> our modules.
> * He's very helpful to work on bugs or new features when needed.
> * Always present during meetings and actively participating.
> * Always on IRC, he never hesitates to give a hand on something or help
> people.
> 
> I think we're very lucky to have Alex part of our group and I would like
> to promote him core reviewer of all our modules.
> 
> Team, please vote if you like the idea,

Quite enough positive votes.

Welcome Alex and thanks for your hard work!
-- 
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] [trove] Nominating Mariam John to Trove Core

[Peter Stachowski]

I agree!

+1

Peter

-Original Message-
From: Vyvial, Craig [mailto:craig.vyv...@hpe.com] 
Sent: January-06-16 2:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

Thanks for the nomination Amrith and I think Mariam will be a great addition to 
the core team.

+1

-Craig

On Jan 6, 2016, at 12:39 PM, Amrith Kumar 
> wrote:

Members of the Trove team,

I would like to nominate Mariam John (johnma on IRC) to the Trove core review 
team.

Mariam has been an active member of the Trove team for some time now. She added 
support for IBM DB2 in Trove and provided elements for building Trove guest 
images. She also implemented code that provided CouchDB support in Trove. She 
has been an active reviewer and I have found her review comments to be 
insightful and useful.

You can review her activity report at

http://stackalytics.com/report/users/mariamj

Members of the Trove core team, please reply to this message with your feedback 
to this proposed change.

Thanks,

-amrith

__
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-dev] [release][stable][nova] python-novaclient release 2.23.3 (kilo)

[doug]

We are delighted to announce the release of:

python-novaclient 2.23.3: Client library for OpenStack Compute API

This release is part of the kilo stable release series.

With source available at:

https://git.openstack.org/cgit/openstack/python-novaclient

With package available at:

https://pypi.python.org/pypi/python-novaclient

For more details, please see below and:

https://launchpad.net/python-novaclient/+milestone/2.23.3

Please report issues through launchpad:

https://bugs.launchpad.net/python-novaclient


Changes in python-novaclient 2.23.2..2.23.3
---

b1b51a6 subunit2html has moved.
c8ff644 Updated from global requirements
861d761 Revert 'Remove image to local block device mapping'

Diffstat (except docs and test files)
-

novaclient/v2/servers.py| 8 
requirements.txt| 4 ++--
4 files changed, 18 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9f20356..1b23cb7 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ oslo.serialization<1.5.0,>=1.4.0 # Apache-2.0
-oslo.utils<1.5.0,>=1.4.0 # Apache-2.0
+oslo.utils!=1.4.1,<1.5.0,>=1.4.0 # Apache-2.0
@@ -11 +11 @@ PrettyTable<0.8,>=0.7
-requests!=2.4.0,>=2.2.0
+requests!=2.4.0,<2.8.0,>=2.2.0



__
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] Client checking of server version

[Jay Dobies]

On 01/06/2016 12:05 PM, Zane Bitter wrote:

On 05/01/16 16:37, Steven Hardy wrote:

On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote:

I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access
older
versions of servers (that's a pretty simplistic description; see [2]
for the
spec).

Before the holiday, Steve Hardy and I were talking about the
complications
involved. In my case, there's no good way to differentiate an older
server
from a legitimate error.

Since the API isn't versioned to the extent that we can leverage that
value,
I was looking into using the template versions call. Something along the
lines of:

   supported_versions = hc.template_versions.list()
   version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
   mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of
generalized
utility method in the client, under the assumption that we'll need
this sort
of check in the future for the same backward compatibility requirements.

So a few questions:

1. Does anyone strongly disagree to checking supported template
versions as
a way of determining the specifics of the server API.


Ok, so some valid concerns have been raised over deriving things using
the
HOT version (although I do still wonder if the environment itself
should be
versioned, just like the templates, then we could rev the environment
verion and say it supports a list, vs changing anything in the API, but
that's probably a separate discussion).

Taking a step back for a moment, the original discussion was around
providing transparent access to the new interface via heatclient, but
that
isn't actually a hard requirement - the old interface works fine for many
users, so we could just introduce a new interface (which would eventually
become the default, after all non-EOL heat versions released support the
new API argument):

Currently we do:

heat stack-create foo -f foo.yaml -e a.yaml -e b.yaml

And this implies some client-side resolution of the multiple -e
arguments.

-e is short for "--environment-file", but we could introduce a new
format,
e.g "-E", short for "--environment-files":

heat stack-create foo -f foo.yaml -E a.yaml -E b.yaml

This option would work the same way as the current interface, but it
would
pass the files unmodified for resolution inside heat (by using the new
API
format), and as it's opt-in, it's leaving all the current heatclient
interfaces alone without any internal fallback logic?


That would certainly work, but it sounds like a usability/support
nightmare :(

Is there a reason we wouldn't consider bumping the API version to 1.1
for this? We'll have to figure out how to do it some time.


I started to look into the Nova specs on how they handle micro versions. 
I have a few other things on my plate I want to finish up this week, but 
I should be able to take a stab at a POC for it.



cheers,
Zane.

__
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] [neutron][networking-sfc] API clarification questions

[Paul Carver]

On 10/28/2015 04:14, Giuseppe (Pino) de Candia wrote:

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant > wrote:

I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html







We have similarly been experimenting with a MidoNet implementation of
the SFC API.



Russell, Giuseppe,

Have you looked any further at OVN/MidoNet implementations of the SFC API?

It's been a long road to get the initial OvS implementation done and 
there are still some pieces that haven't been merged yet but we'd be 
very interested in feedback on the pluggable driver model.


The intent has always been to create a common SFC API with an 
ML2-inspired separation of the API from the backend so that service 
chains can be created using the same API calls across multiple SDN 
controller backends.


I'd like to capture feedback on the driver model and whether we've got 
the right bits in place to allow for hooking in various SDN controllers.



__
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-translator][tacker] Etherpad for TOSCA NFV to Heat translation

[HADDLETON, Robert W (Bob)]

I created an Etherpad [1] to discuss the mapping of TOSCA NFV objects 
[2] to Heat resources by heat-translator, in support of this [3] blueprint.


The related tosca-parser work [4][5] is finishing up, so the next step 
is to map these objects into Heat resources.


This will likely be a work-in-progress for a while, but please 
comment/edit/etc if you have any input.


Thanks

Bob

[1] https://etherpad.openstack.org/p/tosca-nfv-heat-translation
[2] 
http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd02/tosca-nfv-v1.0-csd02.html

[3] https://blueprints.launchpad.net/heat-translator/+spec/tosca-nfv-support
[4] https://blueprints.launchpad.net/tosca-parser/+spec/tosca-nfv-support
[5] https://review.openstack.org/#/c/253689/5

__
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] Next CellsV2 meeting is Jan 13 at 2100UTC

[melanie witt]

On Jan 6, 2016, at 11:41, Andrew Laski  wrote:

> As explained in 
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html a 
> recurring calendar event based on alternating weeks will now be incorrect.  I 
> had to fix my calendar and I expect others will want to do the same.

Ah, I got caught up in this today with my calendar events -- thanks for the 
explanation.

-melanie








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

Re: [openstack-dev] [puppet] proposing Alex Schultz part of core team

[Denis Egorenko]

Hi,

Alex is doing great job! +1 from my side!

2016-01-06 16:27 GMT+03:00 Sebastien Badia :

> On Tue, Jan 05, 2016 at 12:55:01PM (-0500), Emilien Macchi wrote:
> > Hi,
> >
> > Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> > the last months in the Puppet OpenStack group:
> > * He's doing a lot of reviews and they are very valuable. He's in my
> > opinion fully aware of our conventions and has nice insights to improve
> > our modules.
> > * He's very helpful to work on bugs or new features when needed.
> > * Always present during meetings and actively participating.
> > * Always on IRC, he never hesitates to give a hand on something or help
> > people.
> >
> > I think we're very lucky to have Alex part of our group and I would like
> > to promote him core reviewer of all our modules.
> >
> > Team, please vote if you like the idea,
>
> Hi,
> A big +1 for me!
>
> Seb
>
> --
> Sebastien Badia
>
> __
> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Deployment Engineer
Mirantis
__
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] Is Swift a good choice of database for the TripleO API?

[Arkady_Kanevsky]

When you state Swift I assume you mean TripleO will use swift APIs to access 
objects in it (template, metadata, etc).
There are many environment where there is no swift but Ceph or other object 
store that can be used for it using swift APIs.

Are all these will be under single user/project that TripleO will create for 
overcloud.
While deployment is in progress or operational the "files" will be read-only.
That would work for production but not for development.

Feels that we are moving toward identity management for users of for heat 
templates for TripleO.
Arkady

From: Jiri Tomasek [mailto:jtoma...@redhat.com]
Sent: Wednesday, January 06, 2016 5:27 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] Is Swift a good choice of database for 
the TripleO API?

On 01/06/2016 11:48 AM, Dougal Matthews wrote:


On 5 January 2016 at 17:09, Jiri Tomasek 
> wrote:
On 12/23/2015 07:40 PM, Steven Hardy wrote:
On Wed, Dec 23, 2015 at 11:05:05AM -0600, Ben Nemec wrote:
On 12/23/2015 10:26 AM, Steven Hardy wrote:
On Wed, Dec 23, 2015 at 09:28:59AM -0600, Ben Nemec wrote:
On 12/23/2015 03:19 AM, Dougal Matthews wrote:

On 22 December 2015 at 17:59, Ben Nemec 

>> wrote:

 Can we just do git like I've been suggesting all along? ;-)

 More serious discussion inline. :-)

 On 12/22/2015 09:36 AM, Dougal Matthews wrote:
 > Hi all,
 >
 > This topic came up in the 2015-12-15 meeting[1], and again briefly
 today.
 > After working with the code that came out of the deployment library
 > spec[2] I
 > had some concerns with how we are storing the templates.
 >
 > Simply put, when we are dealing with 100+ files from
 tripleo-heat-templates
 > how can we ensure consistency in Swift without any atomicity or
 > transactions.
 > I think this is best explained with a couple of examples.
 >
 >  - When we create a new deployment plan (upload all the templates
 to swift)
 >how do we handle the case where there is an error? For example,
 if we are
 >uploading 10 files - what do we do if the 5th one fails for
 some reason?
 >There is a patch to do a manual rollback[3], but I have
 concerns about
 >doing this in Python. If Swift is completely inaccessible for a
 short
 >period the rollback wont work either.
 >
 >  - When deploying to Heat, we need to download all the YAML files from
 > Swift.
 >This can take a couple of seconds. What happens if somebody
 starts to
 >upload a new version of the plan in the middle? We could end up
 trying to
 >deploy half old and half new files. We wouldn't have a
 consistent view of
 >the database.
 >
 > We had a few suggestions in the meeting:
 >
 >  - Add a locking mechanism. I would be concerned about deadlocks or
 > having to
 >lock for the full duration of a deploy.

 There should be no need to lock the plan for the entire deploy.  It's
 not like we're re-reading the templates at the end of the deploy today.
  It's a one-shot read and then the plan could be unlocked, at least as
 far as I know.


Good point. That would be holding the lock for longer than we need.

 The only option where we wouldn't need locking at all is the
 read-copy-update model Clint mentions, which might be a valid option as
 well.  Whatever we do, there are going to be concurrency issues though.
  For example, what happens if two users try to make updates to the plan
 at the same time?  If you don't either merge the changes or disallow one
 of them completely then one user's changes might be lost.

 TBH, this is further convincing me that we should just make this git
 backed and let git handle the merging and conflict resolution (never
 mind the fact that it gets us a well-understood version control system
 for "free").  For updates that don't conflict with other changes, git
 can merge them automatically, but for merge conflicts you just return a
 rebase error to the user and make them resolve it.  I have a feeling
 this is the behavior we'll converge on eventually anyway, and rather
 than reimplement git, let's just use the real thing.


I'd be curious to hear more how you would go about doing this with git. I've
never automated git to this level, so I am concerned about what issues we
might hit.
TBH I haven't thought it through to that extent yet.  I'm mostly
suggesting it because it seems like a fit for the template storage
requirements - we know we want version control, we want to be able to
merge changes from multiple sources, and we want some way to handle
merge conflicts.  Git does all of this already.

That said, I'm not sure about everything here.