Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

>> Well, it seems to me that the problem is the above blueprint and the code it >> introduced. This is an anti-feature IMO, and probably the best solution >> would be to remove the above code and go back to having a single >> >> nova-compute managing a single vCenter cluster, not multiple ones.

Re: [openstack-dev] [Openstack] [NOVA] Missing network info in nova list

Hello, In nova logs there was not any error or TRACE. Everything looks ok there but I probably found reason and solution of that problem. It was probably related to bug: https://bugs.launchpad.net/nova/+bug/1254320 When I apply this patch on my compute nodes I have no any new instance with missing

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

Hi Divakar, Can I say that the bare metal provisioning is now using kind of "Parent - Child compute" mode? I was also thinking that we can use host:node to identify a kind of "Parent-Child" or "Hierarchy Compute". So can you please show some difference for your "Parent - Child Compute Node" and ba

[openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

Per the last LBaaS meeting. 1. Please find a list of use cases. https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing a) Please review and see if you have additional ones for the project-user b) We can then chose 2-3 use cases to play

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin wrote: > Russell, > > At this point the guard that Nova needs to provide around the instance > does not need to be complex. It would even suffice to keep those > instances hidden from such operations as ³nova list² when invoked by > directly by the

Re: [openstack-dev] [Nova][Neutron] API inconsistencies with security groups

On Sat, Apr 5, 2014 at 10:17 PM, Joshua Hesketh < joshua.hesk...@rackspace.com> wrote: > Hi Chris, > > Thanks for your input. > > > On 4/5/14 9:56 PM, Christopher Yeoh wrote: > >> On Sat, 5 Apr 2014 15:16:33 +1100 >> Joshua Hesketh wrote: >> >>> I'm moving a conversation that has begun on a revie

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

How do these use-cases relate to availability zones or cells, is the assumption that the same private network is available across both? An application owner could look to protect availability not just provide scalability. On 6 April 2014 07:51, Samuel Bercovici wrote: > Per the last LBaaS meeting

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

On 04/06/2014 09:02 AM, Christopher Yeoh wrote: > On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin > wrote: > > Russell, > > At this point the guard that Nova needs to provide around the instance > does not need to be complex. It would even suffice to kee

Re: [openstack-dev] Doc for Trove ?

Anne, >From my understanding, Trove is due to graduate in the Juno release. Is documentation for developers, operators and users not one of the criteria (http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements) ? * Documentation / User support **

[openstack-dev] [heat] Managing changes to the Hot Specification (hot_spec.rst)

Hi folks, There are two problems we should address regarding the growth and change to the HOT specification. First our +2/+A process for normal changes doesn't totally make sense for hot_spec.rst. We generally have some informal bar for controversial changes (of which changes to hot_spec.rs

Re: [openstack-dev] Doc for Trove ?

On Sun, Apr 6, 2014 at 12:44 PM, Tim Bell wrote: > > Anne, > > From my understanding, Trove is due to graduate in the Juno release. > > Is documentation for developers, operators and users not one of the > criteria ( > http://git.openstack.org/cgit/openstack/governance/tree/reference/incubatio

Re: [openstack-dev] Doc for Trove ?

- Original Message - > > Anne, > > From my understanding, Trove is due to graduate in the Juno release. > > Is documentation for developers, operators and users not one of the criteria > (http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirement

Re: [openstack-dev] Doc for Trove ?

Anne, Thanks... pleased to see the documentation is in the pipeline, gaps raised with the TC and that this is not left as an optional afterthought. Is it planned to add something to the installation guides (as for the other projects) such as http://docs.openstack.org/trunk/install-guide/insta

Re: [openstack-dev] [Openstack-docs] Doc for Trove ?

On Sun, Apr 6, 2014 at 1:40 PM, Steve Gordon wrote: > - Original Message - > > > > Anne, > > > > From my understanding, Trove is due to graduate in the Juno release. > > > > Is documentation for developers, operators and users not one of the > criteria > > ( > http://git.openstack.org/cgi

Re: [openstack-dev] Doc for Trove ?

On Sun, Apr 6, 2014 at 1:45 PM, Tim Bell wrote: > > > Anne, > > > > Thanks... pleased to see the documentation is in the pipeline, gaps raised > with the TC and that this is not left as an optional afterthought. > > > > Is it planned to add something to the installation guides (as for the > other

Re: [openstack-dev] Doc for Trove ?

My worry is that many deployers are waiting for programs to reach integrated before looking at them in detail. When something is announced as integrated, there is an expectation that the TC criteria are met. When there is no installation documentation or end user CLI or dashboard information,

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant wrote: > On 04/06/2014 09:02 AM, Christopher Yeoh wrote: > > On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin > > wrote: > > > > Russell, > > > > At this point the guard that Nova needs to provide around the > ins

Re: [openstack-dev] [fuel-dev] [Fuel] Issues about OSTF tests

Timur, sorry for missing your question. We are switching from fuel-dev ML to openstack-dev, and will keep watching for all Fuel-related questions. Back to your question, you can use GET request like this: GET /api/nodes?cluster_id=1 Following is just part of the response: [{"model": "WDC WD3200BP

Re: [openstack-dev] [heat] Managing changes to the Hot Specification (hot_spec.rst)

On 07/04/14 06:23, Steven Dake wrote: > Hi folks, > > There are two problems we should address regarding the growth and > change to the HOT specification. > > First our +2/+A process for normal changes doesn't totally make sense > for hot_spec.rst. We generally have some informal bar for > controv

[openstack-dev] [Fuel][Neutron] Networking Discussions last week

Hi all, we had a number of discussions last week in Moscow, with participation of guys from Russia, Ukraine and Poland. That was a great time!! Thanks everyone who participated. Special thanks to Przemek for great preparations, including the following: https://docs.google.com/a/mirantis.com/presen

Re: [openstack-dev] [TripleO] [Heat] TripleO Heat Templates and merge.py

On 05/04/14 04:47, Tomas Sedovic wrote: > Hi All, > > I was wondering if the time has come to document what exactly are we > doing with tripleo-heat-templates and merge.py[1], figure out what needs > to happen to move away and raise the necessary blueprints on Heat and > TripleO side. > > (merge.py

Re: [openstack-dev] Doc for Trove ?

- Original Message - > > My worry is that many deployers are waiting for programs to reach integrated > before looking at them in detail. When something is announced as integrated, > there is an expectation that the TC criteria are met. > > When there is no installation documentation or e

[openstack-dev] [keystone] event notifications issue

Hi All, I was able to get keystone notification when creating/deleting a tenant by setting these parameters in keystone.conf: (NOTE: the brach that I was using: git branch -v * (no branch) 0d83e7e Bump stable/havana next version to 2013.2.2) ) notification_topics = Key_Notify rpc_backend = keysto

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

Adam, I was imprecise, thank you for correcting that error. I think the net of the statement still holds though: the Keystone token mechanism defines a mechanism for authorization, why doesn't the heat stack manage a token for any behavior that requires authorization? -M _

[openstack-dev] [Ceilomete]

hi, How can i user use Ceilometer API in Python programs?(to show meters,alarms,...)give some python code for example please Sincerly,Chraiti Hachem,software engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

On 07/04/14 12:52, Michael Elder wrote: > > > I think the net of the statement still holds though: the Keystone > token mechanism defines a mechanism for authorization, why doesn't the > heat stack manage a token for any behavior that requires authorization? Heat does use a token, but that token is

[openstack-dev] [Neutron] servicevm: weekly servicevm IRC meeting(April 8, 2014)

Hi. This is a reminder mail for the servicevm IRC meeting April 8, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode - status update - details of dividing the blueprints (Sorry I'm going to write it up from now on.) - design summit plan -- Isaku Yamahata __

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

If Keystone is configured with an external identity provider (LDAP, OpenID, etc), how does the creation of a new user per resource affect that external identity source? My suggestion is broader, but in the same spirit: Could we consider defining an _authorization_ "stack" token (thanks Adam),

Re: [openstack-dev] Operators & Design Summit ideas for Atlanta

So far, there's been no comment from anyone working on nova, so there's been no session proposed. I can, of course, propose a session ... but without buy-in from the project team it's unlikely to be accepted. Regards, Tom On 01/04/14 22:44, Matt Van Winkle wrote: So, I've been watching

Re: [openstack-dev] Operators & Design Summit ideas for Atlanta

It might be that this is happening because there is no clear incumbent for the Nova PTL position. Is it ok to hold off on this until after the outcome of the election is known? Michael On Mon, Apr 7, 2014 at 2:23 PM, Tom Fifield wrote: > So far, there's been no comment from anyone working on nov

Re: [openstack-dev] Operators & Design Summit ideas for Atlanta

If the timing works, that seems fine :) Regards, Tom On 07/04/14 10:32, Michael Still wrote: It might be that this is happening because there is no clear incumbent for the Nova PTL position. Is it ok to hold off on this until after the outcome of the election is known? Michael On Mon, Apr 7

Re: [openstack-dev] [Ceilomete]

This seems like a good place to start: https://github.com/openstack/python-ceilometerclient/blob/master/doc/source/index.rst Regards, Steve Martinelli Software Developer - Openstack Keystone Core Member Phone: 1-905-413-2851 E-mail: steve...@ca.ibm.com 8200 Warden Ave Markham, ON L6G 1C7

Re: [openstack-dev] Cinder: Whats the way to do cleanup during service shutdown / restart ?

Duncan, Thanks for your response. Tho' i agree to what you said.. I am still trying to understand why i see what i see .. i.e. why the base class variables (_mount_shared) shows up empty in __del__ I am assuming here that the obj is not completely gone/deleted, so its vars must still be in scop

Re: [openstack-dev] Cinder: Whats the way to do cleanup during service shutdown / restart ?

To add: I was looking at Nova code and it seems there is a framework for cleanup using the terminate calls.. IIUC this works as libvirt calls terminate on Nova instance when the VM is shutting down/destroying, hence terminate seems to be a good place to do cleanup on Nova side.. something simil

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

On Sun, 2014-04-06 at 06:59 +, Nandavar, Divakar Padiyar wrote: > >> Well, it seems to me that the problem is the above blueprint and the code > >> it introduced. This is an anti-feature IMO, and probably the best solution > >> would be to remove the above code and go back to having a single

Re: [openstack-dev] Summit session for config validation and diagnostic

Oleg, I'm very much interested in this. I believe that as this distributed environment becomes more and more complex, involving many different modules and teams it's becoming crucial to have some common view (and maybe framework) for diagnostics and problem resolution. Thanks, Ezra IBM Rese