Re: [Openstack] [openstack][nova][vwware]Does present vmware driver support resource pool?
Hi, There was talk at the last summit about supporting resource pools. My recollection is that there were too many edge cases found. Please note that this is something that I not officially tested with minesweeper. Thanks Gary From: Kai KT Tong tong...@cn.ibm.commailto:tong...@cn.ibm.com Date: Wednesday, August 6, 2014 at 1:38 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] [openstack][nova][vwware]Does present vmware driver support resource pool? Hi all: I found that if I configure resource pool as the cluster way: /etc/nova/nova.conf cluster_name=resource pool name It works and retrieve the resource pool as a cluster. Such as: [cid:1__=c7bbf7bfdfa98c1b8f9e8a93df...@cn.ibm.com] I want to know whether it is as design. Is there official doc? Thanks. Thanks Best Regards , Kai KT Tong ** Cloud Smarter Infrastructure China Development China Software Development Lab, Notes ID: Kai KT Tong/China/IBM@IBMCN E-Mail : tong...@cn.ibm.commailto:tong...@cn.ibm.com Tel: 86-10-82453574 ** Shangdi Software Park Ring Build 2RW337 Shangdi, Haidian District, Beijing 100193, P.R.China ** ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
On 8/4/14, 5:39 PM, mar...@redhat.com mandr...@redhat.com wrote: On 03/08/14 13:07, Gary Kotton wrote: Hi, Happy you asked about this. This is an idea that we have: Below is a suggestion on how we can improve the metadata service. This can be done by leveraging the a Load balancers supports X-Forwarded-For.The following link has two diagrams. The first is the existing support (may be a little rusty here, so please feel free to correct) and the second is the proposal. https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/drawin gs/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBRk=oIvRg1%2BdGAgOoM1BIlLLqw% 3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=pDHtkey4 U%2FmCkIGoEa0vUaWK4o93GK5Ep2QhTvy2gAw%3D%0As=98f30ec826fdd475b3ecca4a22b a6d3664652d7281a1a95b88eba9de570cc678 C-0E/edit?usp=sharing Metadata proxy support: the proxy will receive the HTTP request. It will then perform a query to the Neutron service (1) to retrieve the tenant id and the instance id from the neutron service. A proxy request will be sent to Nova for the metadata details (2). Proposed support: 1. There will be a load balancer vip 254.169.254.169 (this can be reached either via the L3 agent of the DG on the DHCP. 2. The LB will have a server farm of all of the Nova API's (this makes the soon highly available) 1. Replace the destination IP and port with the Nova metadata IP and port 2. Replace the source IP with the interface IP 3. Insert the header X-Fowarded-For (this will have the original source IP of the VM) 1. When the Nova metadata service receives the request, according to a configuration variable (https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/ nova/blob/master/nova/api/metadata/handler.pyk=oIvRg1%2BdGAgOoM1BIlLLqw% 3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=pDHtkey4 U%2FmCkIGoEa0vUaWK4o93GK5Ep2QhTvy2gAw%3D%0As=5f11211dd96938ae5a319c12eb6 e01f9fa585d76aa5ee6a36a96561644fbb625 #L134), will interface with the neutron service to get the instance_id and the tenant id. This will be done by using a new extension. With the details provided by Neutron Nova will provide the correct metadata for the instance 2. A new extension will be added to Neutron that will enable a port lookup. The port lookup will have two input values and will return the port which has the instance id and the tenant id. 1. LB source IP this is the LB source IP that interfaces with the Nova API. When we create the edge router for the virtual network we will have a mapping of the edge LB ip - network id. This will enable us to get the virtual network for the port 2. Fixed port IP this with the virtual network will enable us to get the specific port. Hopefully in the coming days a spec will be posted that will provide more details thanks for that info Gary, the diagram in particular forced me to go read a bit about the metadata agent (i was mostly just proxying for the original question). I obviously miss a lot of the details (will be easier once the spec is out) but it seems like you're proposing an addition (port-lookup) that will change the way the metadata agent is called; in fact does it make the neutron metadata proxy obsolete? I will keep a look out for the spec, At the moment there is already a port lookup. This is done by the metadata proxy. The proposed solution will have less hops and fewer elements that can fail. Hopefully we Can get the spec posted in the near future. Sadly this will not be approved for Juno. thanks, marios Thanks Gary On 8/1/14, 6:11 PM, mar...@redhat.com mandr...@redhat.com wrote: Hi all, I have been asked by a colleague about the status of A/A HA for neutron-* processes. From the 'HA guide' [1], l3-agent and metadata-agent are the only neutron components that can't be deployed in A/A HA (corosync/pacemaker for a/p is documented as available 'out of the box' for both). The l3-agent work is approved for J3 [4] but I am unaware of any work on the metadata-agent and can't see any mention in [2][3]. Is this someone has looked at, or is planning to (though ultimately K would be the earliest right?)? thanks! marios [1] http://docs.openstack.org/high-availability-guide/content/index.html [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan [3] https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron /% 2Bmilestone/juno-3k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF 6h goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5 cN I73%2B0jJ8%3D%0As=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19 da 3d88681da [4] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3 -h igh-availability.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Group Based Policy and the way forward
Hi, Is there any description of how this will be consumed by Nova. My concern is this code landing there. Thanks Gary From: Robert Kukura kuk...@noironetworks.commailto:kuk...@noironetworks.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, August 5, 2014 at 5:20 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward On 8/4/14, 4:27 PM, Mark McClain wrote: All- tl;dr * Group Based Policy API is the kind of experimentation we be should attempting. * Experiments should be able to fail fast. * The master branch does not fail fast. * StackForge is the proper home to conduct this experiment. The disconnect here is that the Neutron group-based policy sub-team that has been implementing this feature for Juno does not see this work as an experiment to gather data, but rather as an important innovative feature to put in the hands of early adopters in Juno and into widespread deployment with a stable API as early as Kilo. The group-based policy BP approved for Juno addresses the critical need for a more usable, declarative, intent-based interface for cloud application developers and deployers, that can co-exist with Neutron's current networking-hardware-oriented API and work nicely with all existing core plugins. Additionally, we believe that this declarative approach is what is needed to properly integrate advanced services into Neutron, and will go a long way towards resolving the difficulties so far trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron model. Like any new service API in Neutron, the initial group policy API release will be subject to incompatible changes before being declared stable, and hence would be labeled experimental in Juno. This does not mean that it is an experiment where to fail fast is an acceptable outcome. The sub-team's goal is to stabilize the group policy API as quickly as possible, making any needed changes based on early user and operator experience. The L and M cycles that Mark suggests below to revisit the status are a completely different time frame. By the L or M cycle, we should be working on a new V3 Neutron API that pulls these APIs together into a more cohesive core API. We will not be in a position to do this properly without the experience of using the proposed group policy extension with the V2 Neutron API in production. If we were failing miserably, or if serious technical issues were being identified with the patches, some delay might make sense. But, other than Mark's -2 blocking the initial patches from merging, we are on track to complete the planned work in Juno. -Bob Why this email? --- Our community has been discussing and working on Group Based Policy (GBP) for many months. I think the discussion has reached a point where we need to openly discuss a few issues before moving forward. I recognize that this discussion could create frustration for those who have invested significant time and energy, but the reality is we need ensure we are making decisions that benefit all members of our community (users, operators, developers and vendors). Experimentation I like that as a community we are exploring alternate APIs. The process of exploring via real user experimentation can produce valuable results. A good experiment should be designed to fail fast to enable further trials via rapid iteration. Merging large changes into the master branch is the exact opposite of failing fast. The master branch deliberately favors small iterative changes over time. Releasing a new version of the proposed API every six months limits our ability to learn and make adjustments. In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs. The results have been very mixed as operators either shy away from testing/offering the API or embrace the API with the expectation that the community will provide full API support and migration. In both cases, the experiment fails because we either could not get the data we need or are unable to make significant changes without accepting a non-trivial amount of technical debt via migrations or draft API support. Next Steps -- Previously, the GPB subteam used a Github account to host the development, but the workflows and tooling do not align with OpenStack's development model. I’d like to see us create a group based policy project in StackForge. StackForge will host the code and enable us to follow the same open review and QA processes we use in the main project while we are developing and testing the API. The infrastructure there will benefit us as we will have a separate review velocity and can frequently publish libraries to PyPI. From a technical perspective, the 13 new entities in GPB [1] do not require any changes to
Re: [openstack-dev] [Neutron] Group Based Policy and the way forward
Ok, thanks for the clarification. This means that it will not be done automagically as it is today – the tenant will need to create a Neutron port and then pass that through. Thanks Gary From: Robert Kukura kuk...@noironetworks.commailto:kuk...@noironetworks.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, August 5, 2014 at 8:13 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward On 8/5/14, 11:04 AM, Gary Kotton wrote: Hi, Is there any description of how this will be consumed by Nova. My concern is this code landing there. Hi Gary, Initially, an endpoint's port_id is passed to Nova using nova boot ... --nic port-id=port-uuid ..., requiring no changes to Nova. Later, slight enhancements to Nova would allow using commands such as nova boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic epg-id=endpoint-group-uuid -Bob Thanks Gary From: Robert Kukura kuk...@noironetworks.commailto:kuk...@noironetworks.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, August 5, 2014 at 5:20 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward On 8/4/14, 4:27 PM, Mark McClain wrote: All- tl;dr * Group Based Policy API is the kind of experimentation we be should attempting. * Experiments should be able to fail fast. * The master branch does not fail fast. * StackForge is the proper home to conduct this experiment. The disconnect here is that the Neutron group-based policy sub-team that has been implementing this feature for Juno does not see this work as an experiment to gather data, but rather as an important innovative feature to put in the hands of early adopters in Juno and into widespread deployment with a stable API as early as Kilo. The group-based policy BP approved for Juno addresses the critical need for a more usable, declarative, intent-based interface for cloud application developers and deployers, that can co-exist with Neutron's current networking-hardware-oriented API and work nicely with all existing core plugins. Additionally, we believe that this declarative approach is what is needed to properly integrate advanced services into Neutron, and will go a long way towards resolving the difficulties so far trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron model. Like any new service API in Neutron, the initial group policy API release will be subject to incompatible changes before being declared stable, and hence would be labeled experimental in Juno. This does not mean that it is an experiment where to fail fast is an acceptable outcome. The sub-team's goal is to stabilize the group policy API as quickly as possible, making any needed changes based on early user and operator experience. The L and M cycles that Mark suggests below to revisit the status are a completely different time frame. By the L or M cycle, we should be working on a new V3 Neutron API that pulls these APIs together into a more cohesive core API. We will not be in a position to do this properly without the experience of using the proposed group policy extension with the V2 Neutron API in production. If we were failing miserably, or if serious technical issues were being identified with the patches, some delay might make sense. But, other than Mark's -2 blocking the initial patches from merging, we are on track to complete the planned work in Juno. -Bob Why this email? --- Our community has been discussing and working on Group Based Policy (GBP) for many months. I think the discussion has reached a point where we need to openly discuss a few issues before moving forward. I recognize that this discussion could create frustration for those who have invested significant time and energy, but the reality is we need ensure we are making decisions that benefit all members of our community (users, operators, developers and vendors). Experimentation I like that as a community we are exploring alternate APIs. The process of exploring via real user experimentation can produce valuable results. A good experiment should be designed to fail fast to enable further trials via rapid iteration. Merging large changes into the master branch is the exact opposite of failing fast. The master branch deliberately favors small iterative changes over time. Releasing a new version of the proposed API every six months limits our ability to learn and make adjustments. In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs. The results have been very mixed as operators either shy away from testing/offering the API or embrace the API
[openstack-dev] [Nova] VMware update
Hi, A few updates regarding the driver: 1. Spawn refactor. This is coming along very nicely. It would be great if the following patches can get some TLC (this will enable us to start working on the next phases - finish spawn treatment and upgrading code to work with oslo.vmware): * https://review.openstack.org/#/c/104146/ * https://review.openstack.org/#/c/105454/ 2. ESX driver deprecation: * https://review.openstack.org/101744 - this will enable a setup using the ESX driver to upgrade to the VC driver * https://review.openstack.org/#/c/108854/ - ESX driver deprecation - this needs a few additional eyes Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core
+1 On 8/1/14, 7:15 PM, Mitsuhiro Tanino mitsuhiro.tan...@hds.com wrote: +1 Regards, Mitsuhiro Tanino mitsuhiro.tan...@hds.com HITACHI DATA SYSTEMS c/o Red Hat, 314 Littleton Road, Westford, MA 01886 -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Thursday, July 31, 2014 7:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core On 07/30/2014 05:10 PM, Russell Bryant wrote: On 07/30/2014 05:02 PM, Michael Still wrote: Greetings, I would like to nominate Jay Pipes for the nova-core team. Jay has been involved with nova for a long time now. He's previously been a nova core, as well as a glance core (and PTL). He's been around so long that there are probably other types of core status I have missed. Please respond with +1s or any concerns. +1 Further, I'd like to propose that we treat all of existing +1 reviews as +2 (once he's officially added to the team). Does anyone have a problem with doing that? I think some folks would have done that anyway, but I wanted to clarify that it's OK. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
Hi, Happy you asked about this. This is an idea that we have: Below is a suggestion on how we can improve the metadata service. This can be done by leveraging the a Load balancers supports X-Forwarded-For.The following link has two diagrams. The first is the existing support (may be a little rusty here, so please feel free to correct) and the second is the proposal. https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR C-0E/edit?usp=sharing Metadata proxy support: the proxy will receive the HTTP request. It will then perform a query to the Neutron service (1) to retrieve the tenant id and the instance id from the neutron service. A proxy request will be sent to Nova for the metadata details (2). Proposed support: 1. There will be a load balancer vip 254.169.254.169 (this can be reached either via the L3 agent of the DG on the DHCP. 2. The LB will have a server farm of all of the Nova API's (this makes the soon highly available) 1. Replace the destination IP and port with the Nova metadata IP and port 2. Replace the source IP with the interface IP 3. Insert the header X-Fowarded-For (this will have the original source IP of the VM) 1. When the Nova metadata service receives the request, according to a configuration variable (https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py #L134), will interface with the neutron service to get the instance_id and the tenant id. This will be done by using a new extension. With the details provided by Neutron Nova will provide the correct metadata for the instance 2. A new extension will be added to Neutron that will enable a port lookup. The port lookup will have two input values and will return the port which has the instance id and the tenant id. 1. LB source IP this is the LB source IP that interfaces with the Nova API. When we create the edge router for the virtual network we will have a mapping of the edge LB ip - network id. This will enable us to get the virtual network for the port 2. Fixed port IP this with the virtual network will enable us to get the specific port. Hopefully in the coming days a spec will be posted that will provide more details Thanks Gary On 8/1/14, 6:11 PM, mar...@redhat.com mandr...@redhat.com wrote: Hi all, I have been asked by a colleague about the status of A/A HA for neutron-* processes. From the 'HA guide' [1], l3-agent and metadata-agent are the only neutron components that can't be deployed in A/A HA (corosync/pacemaker for a/p is documented as available 'out of the box' for both). The l3-agent work is approved for J3 [4] but I am unaware of any work on the metadata-agent and can't see any mention in [2][3]. Is this someone has looked at, or is planning to (though ultimately K would be the earliest right?)? thanks! marios [1] http://docs.openstack.org/high-availability-guide/content/index.html [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan [3] https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/% 2Bmilestone/juno-3k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6h goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5cN I73%2B0jJ8%3D%0As=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19da 3d88681da [4] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-h igh-availability.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
Hi, The link below is broken. Please see - https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR C-0E/edit In short this will give a highly available service without the need for the metadata proxy. It will also have one less hop = better performance. Thanks Gary On 8/3/14, 1:07 PM, Gary Kotton gkot...@vmware.com wrote: Hi, Happy you asked about this. This is an idea that we have: Below is a suggestion on how we can improve the metadata service. This can be done by leveraging the a Load balancers supports X-Forwarded-For.The following link has two diagrams. The first is the existing support (may be a little rusty here, so please feel free to correct) and the second is the proposal. https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfB R C-0E/edit?usp=sharing Metadata proxy support: the proxy will receive the HTTP request. It will then perform a query to the Neutron service (1) to retrieve the tenant id and the instance id from the neutron service. A proxy request will be sent to Nova for the metadata details (2). Proposed support: 1. There will be a load balancer vip 254.169.254.169 (this can be reached either via the L3 agent of the DG on the DHCP. 2. The LB will have a server farm of all of the Nova API's (this makes the soon highly available) 1. Replace the destination IP and port with the Nova metadata IP and port 2. Replace the source IP with the interface IP 3. Insert the header X-Fowarded-For (this will have the original source IP of the VM) 1. When the Nova metadata service receives the request, according to a configuration variable (https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.p y #L134), will interface with the neutron service to get the instance_id and the tenant id. This will be done by using a new extension. With the details provided by Neutron Nova will provide the correct metadata for the instance 2. A new extension will be added to Neutron that will enable a port lookup. The port lookup will have two input values and will return the port which has the instance id and the tenant id. 1. LB source IP this is the LB source IP that interfaces with the Nova API. When we create the edge router for the virtual network we will have a mapping of the edge LB ip - network id. This will enable us to get the virtual network for the port 2. Fixed port IP this with the virtual network will enable us to get the specific port. Hopefully in the coming days a spec will be posted that will provide more details Thanks Gary On 8/1/14, 6:11 PM, mar...@redhat.com mandr...@redhat.com wrote: Hi all, I have been asked by a colleague about the status of A/A HA for neutron-* processes. From the 'HA guide' [1], l3-agent and metadata-agent are the only neutron components that can't be deployed in A/A HA (corosync/pacemaker for a/p is documented as available 'out of the box' for both). The l3-agent work is approved for J3 [4] but I am unaware of any work on the metadata-agent and can't see any mention in [2][3]. Is this someone has looked at, or is planning to (though ultimately K would be the earliest right?)? thanks! marios [1] http://docs.openstack.org/high-availability-guide/content/index.html [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan [3] https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/ % 2Bmilestone/juno-3k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6 h goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5c N I73%2B0jJ8%3D%0As=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19d a 3d88681da [4] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3- h igh-availability.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1351892] [NEW] Missing packages on clean environment
Public bug reported:
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
Package libvirt was not found in the pkg-config search path.
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
running install
running build
/usr/bin/pkg-config --print-errors --atleast-version=0.9.11 libvirt
Package libvirt was not found in the pkg-config search path.
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
error: command '/usr/bin/pkg-config' failed with exit status 1
Cleaning up...
Command /home/gkotton/nova/.tox/py27/bin/python2.7 -c import setuptools,
tokenize;__file__='/home/gkotton/nova/.tox/py27/build/libvirt-python/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))
install --record /tmp/pip-OvSALh-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/home/gkotton/nova/.tox/py27/include/site/python2.7 failed with error code 1 in
/home/gkotton/nova/.tox/py27/build/libvirt-python
Traceback (most recent call last):
File ../bin/pip, line 11, in module
sys.exit(main())
File
/home/gkotton/nova/.tox/py27/local/lib/python2.7/site-packages/pip/__init__.py,
line 185, in main
return command.main(cmd_args)
File
/home/gkotton/nova/.tox/py27/local/lib/python2.7/site-packages/pip/basecommand.py,
line 161, in main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 66:
ordinal not in range(128)
** Affects: nova
Importance: Medium
Assignee: Gary Kotton (garyk)
Status: New
** Changed in: nova
Milestone: None = juno-3
** Changed in: nova
Assignee: (unassigned) = Gary Kotton (garyk)
** Changed in: nova
Importance: Undecided = Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1351892
Title:
Missing packages on clean environment
Status in OpenStack Compute (Nova):
New
Bug description:
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
Package libvirt was not found in the pkg-config search path.
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
running install
running build
/usr/bin/pkg-config --print-errors --atleast-version=0.9.11 libvirt
Package libvirt was not found in the pkg-config search path.
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
error: command '/usr/bin/pkg-config' failed with exit status 1
Cleaning up...
Command /home/gkotton/nova/.tox/py27/bin/python2.7 -c import setuptools,
tokenize;__file__='/home/gkotton/nova/.tox/py27/build/libvirt-python/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))
install --record /tmp/pip-OvSALh-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/home/gkotton/nova/.tox/py27/include/site/python2.7 failed with error code 1 in
/home/gkotton/nova/.tox/py27/build/libvirt-python
Traceback (most recent call last):
File ../bin/pip, line 11, in module
sys.exit(main())
File
/home/gkotton/nova/.tox/py27/local/lib/python2.7/site-packages/pip/__init__.py,
line 185, in main
return command.main(cmd_args)
File
/home/gkotton/nova/.tox/py27/local/lib/python2.7/site-packages/pip/basecommand.py,
line 161, in main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 66:
ordinal not in range(128)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1351892/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1351892] Re: Missing packages on clean environment
Added in
https://github.com/openstack/nova/commit/21bf0219f66ca9041bc0cf9c29e3a23c054d125c
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1351892
Title:
Missing packages on clean environment
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
Package libvirt was not found in the pkg-config search path.
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
running install
running build
/usr/bin/pkg-config --print-errors --atleast-version=0.9.11 libvirt
Package libvirt was not found in the pkg-config search path.
Perhaps you should add the directory containing `libvirt.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libvirt' found
error: command '/usr/bin/pkg-config' failed with exit status 1
Cleaning up...
Command /home/gkotton/nova/.tox/py27/bin/python2.7 -c import setuptools,
tokenize;__file__='/home/gkotton/nova/.tox/py27/build/libvirt-python/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))
install --record /tmp/pip-OvSALh-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/home/gkotton/nova/.tox/py27/include/site/python2.7 failed with error code 1 in
/home/gkotton/nova/.tox/py27/build/libvirt-python
Traceback (most recent call last):
File ../bin/pip, line 11, in module
sys.exit(main())
File
/home/gkotton/nova/.tox/py27/local/lib/python2.7/site-packages/pip/__init__.py,
line 185, in main
return command.main(cmd_args)
File
/home/gkotton/nova/.tox/py27/local/lib/python2.7/site-packages/pip/basecommand.py,
line 161, in main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 66:
ordinal not in range(128)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1351892/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Summit Session Voting
Hi, Feel free to share. :) Thanks Gary From: Adam Lawson alaw...@aqorn.commailto:alaw...@aqorn.com Date: Saturday, August 2, 2014 at 9:02 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org, openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org Subject: [Openstack] Summit Session Voting How are folks getting the word out for their session ideas? I submitted 4 including one I'm really passionate about. Is there a rule against sharing links to our ideas with the mailing list here? As a start-up, we don't have hundreds of employee votes for our own company unfortunately so it looks like creativity will be helpful! Mahalo, Adam Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [http://www.aqorn.com/images/logo.png] ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [NFV] Meeting summary 2014-07-30
Hi, There are a few other issues which may be related: - https://review.openstack.org/103091 - https://review.openstack.org/103094 They are both related to the attachment of new interfaces to a VM Thanks Gary On 7/30/14, 9:38 PM, Steve Gordon sgor...@redhat.com wrote: Meeting summary https://etherpad.openstack.org/p/nfv-meeting-agenda (russellb, 14:00:32) review actions from last week (russellb, 14:00:48) ACTION: bauzas to update list with link to new dash (sgordon, 14:02:34) https://review.openstack.org/#/c/95805/2 (sgordon, 14:02:54) https://review.openstack.org/#/c/107797/1 (sgordon, 14:03:00) http://lists.openstack.org/pipermail/openstack-dev/2014-July/040660.html (sgordon, 14:03:25) http://lists.openstack.org/pipermail/openstack-dev/2014-July/040877.html (sgordon, 14:03:30) blueprints (sgordon, 14:09:00) https://wiki.openstack.org/wiki/Meetings/NFV#Active_Blueprints (sgordon, 14:09:56) https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne t/nova/%2Bspec/multiple-if-1-netk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0 pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=4hyUls13ARfPKXhxLZ3RCDg 0%2FLV9bMof84KfsAlukEI%3D%0As=2957d6d18d8b4344978647ddb83e5cee9c8ece19525 97d8d83d05cbe9bd818c6 (sgordon, 14:10:13) multiple-if-1-net approved, code up for review (sgordon, 14:10:26) https://review.openstack.org/#/c/98488/ (sgordon, 14:11:33) https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne t/neutron/%2Bspec/nfv-vlan-trunksk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH 0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=4hyUls13ARfPKXhxLZ3RCD g0%2FLV9bMof84KfsAlukEI%3D%0As=90a365e2e3c3ae1d5b298e474c064d35a954edf1c9 36780222d25fe3c6794774 (sgordon, 14:12:59) https://review.openstack.org/#/c/97714/ (sgordon, 14:13:17) https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne t/neutron/%2Bspec/ml2-ovs-portsecurityk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=4hyUls13ARfPKXhxL Z3RCDg0%2FLV9bMof84KfsAlukEI%3D%0As=4c7413f4dcc18319edae3375e014a3d741728 39f92ec410bf3a3ee8703c17d5a (sgordon, 14:15:12) Team goals and structure (sgordon, 14:16:33) Broader communication with wider development (nova, neutron, etc.) communities required to illustrate what NFV is and is not, current state and progress (sgordon, 14:26:14) Feedback from nova midcycle is that more needs to be done to front load the earlier release milestones late in the previous cycle (sgordon, 14:26:50) Cross-project design session proposal for Kilo summit needs to be co-ordinated and have specific goals to be accepted (sgordon, 14:30:32) ACTION: Bring possible topics/goals for cross-project session to next week's meeting. (sgordon, 14:33:44) meeting times (sgordon, 14:39:10) https://urldefense.proofpoint.com/v1/url?u=http://whenisgood.net/exzzbi8k =oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh CZFxPEq8%3D%0Am=4hyUls13ARfPKXhxLZ3RCDg0%2FLV9bMof84KfsAlukEI%3D%0As=aaf f33561d0d9b00650f18becbcc80c4fdbd5beb27af3239f79b6abdda8f51b9 (sgordon, 14:40:00) please vote on future meeting times by EoW (sgordon, 14:40:10) open discussion (sgordon, 14:44:27) ACTION: sgordon confirm future meeting times at next week's meeting (sgordon, 14:46:51) ACTION: adrian-hoban to follow up on M/L regarding potential for pre-loading the early kilo milestones (sgordon, 14:55:24) ACTION: smazziotta to report on outcome of ETSI NFV gaps discussion at next week's meeting (sgordon, 14:56:06) Full logs: http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-30-14.00.log. html -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to deprecate a plugin
In Nova we have done the following: - add a warning in the current version that this will be deprecated in K - start of K drop the code It is also important to have an upgrade path. What happens if I have my RYU plugin in production and I upgrade to the next version. That should be clearly documented. I think that maybe we should consider on working on a migration scheme - from plugin A to plugin B. Thanks Gary On 7/30/14, 8:17 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, what's the right procedure to deprecate a plugin? we (ryu team) are considering deprecating ryu plugin, in favor of ofagent. probably in K-timeframe, if it's acceptable. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] objects notifications
On 7/30/14, 7:26 AM, Dan Smith d...@danplanet.com wrote: When reviewing https://review.openstack.org/#/c/107954/ it occurred to me that maybe we should consider having some kind of generic object wrapper that could do notifications for objects. Any thoughts on this? I think it might be good to do this in a repeatable, but perhaps not totally automatic way. I can see that any time instance gets changed in certain ways, that we'd want a notification about it. However, there are probably some cases that don't fit that. For example, instance.system_metadata is mostly private to nova I think, so I'm not sure we'd want to emit a notification for that. Plus, we'd probably end up with some serious duplication if we just do it implicitly. What if we provided a way to declare the fields of an object that we want to trigger a notification? Something like: I think that this is a nice idea that we should look into NOTIFICATION_FIELDS = ['host', 'metadata', ...] @notify_on_save(NOTIFICATION_FIELDS) @base.remotable def save(context): ... --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] stable branches failure to handle review backlog
On 7/30/14, 8:22 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Wed, 2014-07-30 at 09:01 +0200, Flavio Percoco wrote: As a stable-maint, I'm always hesitant to review patches I've no understanding on, hence I end up just checking how big is the patch, whether it adds/removes new configuration options etc but, the real review has to be done by someone with good understanding of the change. Something I've done in the past is adding the folks that had approved the patch on master to the stable/maint review. They should know that code already, which means it shouldn't take them long to review it. All the sanity checks should've been done already. With all that said, I'd be happy to give *-core approval permissions on stable branches, but I still think we need a dedicated team that has a final (or at least relevant) word on the patches. Maybe what we need to do is give *-core permission to +2 the patches, but only stable/maint team has *approval* permission. Then, the cores can review the code, and stable/maint only has to verify applicability to the stable branchŠ +1 -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] objects notifications
Hi, When reviewing https://review.openstack.org/#/c/107954/ it occurred to me that maybe we should consider having some kind of generic object wrapper that could do notifications for objects. Any thoughts on this? Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] [Spec freeze exception] VMware DVS support
Hi, I would like to propose the following for spec freeze exception: * https://review.openstack.org/#/c/105369 This is an umbrella spec for a number of VMware DVS support specs. Each has its own unique use case and will enable a lot of existing VMware DVS users to start to use OpenStack. For https://review.openstack.org/#/c/102720/ we have the following which we can post when the internal CI for the NSX-v is ready (we are currently working on this): - core plugin functionality - layer 3 support - security group support Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1345460] [NEW] VMware: resize fails when there is more than one compute node
(msg) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp NotFound: The resource domain-c1122(compute02) does not exist 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp 2014-07-16 18:14:57.595 13228 DEBUG nova.openstack.common.vmware.api [-] Waiting for function _invoke_api to return. func /usr/lib/python2.7/dist-packages/nova/openstack/common/vmware/api.py:120 2014-07-16 18:14:57.598 13228 DEBUG nova.openstack.common.vmware.api [-] Invoking _invoke_api; retry count is 0. _func /usr/lib/python2.7/dist-packages/nova/openstack/common/vmware/api.py:83 2014-07-16 18:14:57.598 13228 DEBUG nova.openstack.common.vmware.api [-] Invoking method module 'nova.virt.vmwareapi.vim_util' from '/usr/lib/python2.7/dist-packages/nova/virt/vmwareap ** Affects: nova Importance: Critical Assignee: Gary Kotton (garyk) Status: New ** Changed in: nova Importance: Undecided = Critical ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = juno-2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1345460 Title: VMware: resize fails when there is more than one compute node Status in OpenStack Compute (Nova): New Bug description: Doing a nova resize on an instance when using the vsphere driver will cause the instance to go in to error state. The problem is that the scheduler will pick another host to spin up a new resized instance and when the user confirms nova will fail because its looking for the instance on the old compute. Here is the traceback. 2014-07-16 18:14:55.271 13228 DEBUG amqp [-] Closed channel #1 _do_close /usr/lib/python2.7/dist-packages/amqp/channel.py:88 2014-07-16 18:14:55.271 13228 DEBUG amqp [-] using channel_id: 1 __init__ /usr/lib/python2.7/dist-packages/amqp/channel.py:70 2014-07-16 18:14:55.273 13228 DEBUG amqp [-] Channel open _open_ok /usr/lib/python2.7/dist-packages/amqp/channel.py:420 2014-07-16 18:14:55.299 13228 ERROR nova.openstack.common.rpc.amqp [req-3cae0e1d-2cf4-4da7-9aac-0ea5279b829d cherkasj 37af63b6867d4fe38ac312ca626ce186] Exception during message handling 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last): 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py, line 461, in _process_data 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp **args) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py, line 172, in dispatch 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp result = getattr(proxyobj, method)(ctxt, **kwargs) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 353, in decorated_function 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp return function(self, context, *args, **kwargs) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 90, in wrapped 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp payload) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 73, in wrapped 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp return f(self, context, *args, **kw) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 294, in decorated_function 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp function(self, context, *args, **kwargs) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 271, in decorated_function 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp e, sys.exc_info()) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 258, in decorated_function 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp return function(self, context, *args, **kwargs) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2683, in confirm_resize 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp do_confirm_resize(context, instance, migration_id) 2014-07-16 18:14:55.299 13228 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py, line 246, in inner 2014-07-16 18:14:55.299 13228 TRACE
Re: [openstack-dev] [nova][glance] Allow Nova to use either Glance V1 or V2: Call for reviews to get the spec merged
+1 From: Arnaud Legendre alegen...@vmware.commailto:alegen...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, July 18, 2014 at 12:52 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][glance] Allow Nova to use either Glance V1 or V2: Call for reviews to get the spec merged The spec to allow Nova to support Glance v1 and v2 got an exception for the Juno Spec Freeze: see [1]. The spec has been created in April and went through 16 iterations. The spec has been discussed several times already especially at the last Glance meetup in Washington D.C. A couple of updates: - The performances issues found in V2 have been fixed [2] - We will use Glance V1 as the default API in Juno (see comments about that here [3]) - The changes made to the Nova codebase won't be destructive meaning that each Nova functionality will be working equally with V1 and V2. I think this is a good time to get this approved and go forward. Please review the spec as soon as possible to get it merged: https://review.openstack.org/#/c/84887/ Thanks, Arnaud [1] https://etherpad.openstack.org/p/nova-juno-spec-priorities [2] http://git.openstack.org/cgit/openstack/glance/commit/?id=0711daa7c27af0332d39dd7a2d906205611cce8b [3] https://review.openstack.org/#/c/84887/14/specs/juno/use-glance-v2-api.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo.vmware] Updates
Hi, I just thought it would be nice to give the community a little update about the current situation: 1. Version is 0.4 (https://github.com/openstack/requirements/blob/master/global-requirements.txt#L58) * This is used by glance and ceilometer * There is a patch in review for Nova to integrate with this - https://review.openstack.org/#/c/70175/. 2. Current version in development will have the following highlights: * Better support for suds faults * Support for VC extensions - this enables for example Nova to mark a VM as being owned by OpenStack * Retry mechanism is 'TaskInProgress' exception is thrown Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VMware networking
Hi, I am sorry but I had to attend a meeting now. Can we please postpone this to tomorrow? Thanks Gary On 7/8/14, 11:19 AM, Gary Kotton gkot...@vmware.com wrote: Hi, Just an update and a progress report: 1. Armando has created an umbrella BP - https://review.openstack.org/#/q/status:open+project:openstack/neutron-spe c s+branch:master+topic:bp/esx-neutron,n,z 2. Whoever is proposing the BP’s can you please fill in the table - https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/documen t/d/1vkfJLZjIetPmGQ6GMJydDh8SSWz60iUhuuKhYMJk=oIvRg1%2BdGAgOoM1BIlLLqw%3D %3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=SvPJghzudWc d764hV5HdpNELoKWhcqrGB2hyww4WB90%3D%0As=74fad114ce48f985c58e1b4e1bdc7efa2 ed2376034e7ebd8cb82f0829915cf01 qoz8/edit?usp=sharing Lets meet again next week Monday at the same time and same place and plan future steps. How does that sound? Thanks Gary On 7/2/14, 2:27 PM, Gary Kotton gkot...@vmware.com wrote: Hi, Sadly last night night we did not have enough people to make any progress. Lets try again next week Monday at 14:00 UTC. The meeting will take place on #openstack-vmware channel Alut a continua Gary On 6/30/14, 6:38 PM, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Jun 30, 2014 at 10:18 AM, Armando M. arma...@gmail.com wrote: Hi Gary, Thanks for sending this out, comments inline. Indeed, thanks Gary! On 29 June 2014 00:15, Gary Kotton gkot...@vmware.com wrote: Hi, At the moment there are a number of different BP¹s that are proposed to enable different VMware network management solutions. The following specs are in review: VMware NSX-vSphere plugin: https://review.openstack.org/102720 Neutron mechanism driver for VMWare vCenter DVS network creation:https://review.openstack.org/#/c/101124/ VMware dvSwitch/vSphere API support for Neutron ML2: https://review.openstack.org/#/c/100810/ I've commented in these reviews about combining efforts here, I'm glad you're taking the lead to make this happen Gary. This is much appreciated! In addition to this there is also talk about HP proposing some for of VMware network management. I believe this is blueprint [1]. This was proposed a while ago, but now it needs to go through the new BP review process. [1] - https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad . n et/neutron/%2Bspec/ovsvapp-esxi-vxlank=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D% 0 A r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZ u 1 a8dOes8mbE9NM9gvjG2PnJXhUU0%3D%0As=622a539e40b3b950c25f0b6cabf05bc81bb 6 1 159077c00f12d7882680e84a18b Each of the above has specific use case and will enable existing vSphere users to adopt and make use of Neutron. Items #2 and #3 offer a use case where the user is able to leverage and manage VMware DVS networks. This support will have the following limitations: Only VLANs are supported (there is no VXLAN support) No security groups #3 the spec indicates that it will make use of pyvmomi (https://urldefense.proofpoint.com/v1/url?u=https://github.com/vmware/ p y vmomik=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2Bf D t ysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1a8dOes8mbE9NM9gvjG2PnJXhUU0% 3 D %0As=436b19122463f2b30a5b7fa31880f56ad0127cdaf0250999eba43564f8b559b9 ) . There are a number of disclaimers here: This is currently blocked regarding the integration into the requirements project (https://review.openstack.org/#/c/69964/) The idea was to have oslo.vmware leverage this in the future (https://urldefense.proofpoint.com/v1/url?u=https://github.com/opensta c k /oslo.vmwarek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgo M Q u%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1a8dOes8mbE9NM9gvjG2Pn J X hUU0%3D%0As=e1559fa7ae956d02efe8a65e356f8f0dbfd8a276e5f2e0a4761894e17 1 6 84b03) Item #1 will offer support for all of the existing Neutron API¹s and there functionality. This solution will require a additional component called NSX (https://www.vmware.com/support/pubs/nsx_pubs.html). It's great to see this breakdown, it's very useful in order to identify the potential gaps and overlaps amongst the various efforts around ESX and Neutron. This will also ensure a path towards a coherent code contribution. It would be great if we could all align our efforts and have some clear development items for the community. In order to do this I¹d like suggest that we meet to sync and discuss all efforts. Please let me know if the following sounds ok for an initial meeting to discuss how we can move forwards: - Tuesday 15:00 UTC - IRC channel #openstack-vmware I am available to join. We can discuss the following: Different proposals Combining efforts Setting a formal time for meetings and follow ups Looking forwards to working on this stuff with the community
Re: [Openstack] OpenStack K naming poll
What about Kilimanjaro? On 7/10/14, 4:34 PM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, As you may know, OpenStack development cycles and releases are named after cities, counties, street names or reference items placed near where the corresponding design summit will happen. The current release cycle, Juno, is named after a city in Georgia (USA), chosen by popular vote. We'd like your help again in selecting the right name for the development cycle and release coming after Juno. Our next summit will happen in Paris (France) in November. K candidate names were proposed, selected and checked for name issues... leaving 5 candidates on the final public poll. Please take a moment to participate to our poll: https://www.surveymonkey.com/s/openstack-k-naming and order the 5 candidates in your personal order of preference! You can find the rationale behind each name at: https://wiki.openstack.org/wiki/Release_Naming Thanks! -- Thierry Carrez (ttx) ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Neutron] VMware networking
Hi, Just an update and a progress report: 1. Armando has created an umbrella BP - https://review.openstack.org/#/q/status:open+project:openstack/neutron-spec s+branch:master+topic:bp/esx-neutron,n,z 2. Whoever is proposing the BP’s can you please fill in the table - https://docs.google.com/document/d/1vkfJLZjIetPmGQ6GMJydDh8SSWz60iUhuuKhYMJ qoz8/edit?usp=sharing Lets meet again next week Monday at the same time and same place and plan future steps. How does that sound? Thanks Gary On 7/2/14, 2:27 PM, Gary Kotton gkot...@vmware.com wrote: Hi, Sadly last night night we did not have enough people to make any progress. Lets try again next week Monday at 14:00 UTC. The meeting will take place on #openstack-vmware channel Alut a continua Gary On 6/30/14, 6:38 PM, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Jun 30, 2014 at 10:18 AM, Armando M. arma...@gmail.com wrote: Hi Gary, Thanks for sending this out, comments inline. Indeed, thanks Gary! On 29 June 2014 00:15, Gary Kotton gkot...@vmware.com wrote: Hi, At the moment there are a number of different BP¹s that are proposed to enable different VMware network management solutions. The following specs are in review: VMware NSX-vSphere plugin: https://review.openstack.org/102720 Neutron mechanism driver for VMWare vCenter DVS network creation:https://review.openstack.org/#/c/101124/ VMware dvSwitch/vSphere API support for Neutron ML2: https://review.openstack.org/#/c/100810/ I've commented in these reviews about combining efforts here, I'm glad you're taking the lead to make this happen Gary. This is much appreciated! In addition to this there is also talk about HP proposing some for of VMware network management. I believe this is blueprint [1]. This was proposed a while ago, but now it needs to go through the new BP review process. [1] - https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad. n et/neutron/%2Bspec/ovsvapp-esxi-vxlank=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0 A r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu 1 a8dOes8mbE9NM9gvjG2PnJXhUU0%3D%0As=622a539e40b3b950c25f0b6cabf05bc81bb6 1 159077c00f12d7882680e84a18b Each of the above has specific use case and will enable existing vSphere users to adopt and make use of Neutron. Items #2 and #3 offer a use case where the user is able to leverage and manage VMware DVS networks. This support will have the following limitations: Only VLANs are supported (there is no VXLAN support) No security groups #3 the spec indicates that it will make use of pyvmomi (https://urldefense.proofpoint.com/v1/url?u=https://github.com/vmware/p y vmomik=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD t ysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1a8dOes8mbE9NM9gvjG2PnJXhUU0%3 D %0As=436b19122463f2b30a5b7fa31880f56ad0127cdaf0250999eba43564f8b559b9) . There are a number of disclaimers here: This is currently blocked regarding the integration into the requirements project (https://review.openstack.org/#/c/69964/) The idea was to have oslo.vmware leverage this in the future (https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstac k /oslo.vmwarek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoM Q u%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1a8dOes8mbE9NM9gvjG2PnJ X hUU0%3D%0As=e1559fa7ae956d02efe8a65e356f8f0dbfd8a276e5f2e0a4761894e171 6 84b03) Item #1 will offer support for all of the existing Neutron API¹s and there functionality. This solution will require a additional component called NSX (https://www.vmware.com/support/pubs/nsx_pubs.html). It's great to see this breakdown, it's very useful in order to identify the potential gaps and overlaps amongst the various efforts around ESX and Neutron. This will also ensure a path towards a coherent code contribution. It would be great if we could all align our efforts and have some clear development items for the community. In order to do this I¹d like suggest that we meet to sync and discuss all efforts. Please let me know if the following sounds ok for an initial meeting to discuss how we can move forwards: - Tuesday 15:00 UTC - IRC channel #openstack-vmware I am available to join. We can discuss the following: Different proposals Combining efforts Setting a formal time for meetings and follow ups Looking forwards to working on this stuff with the community and providing a gateway to using Neutron and further enabling the adaption of OpenStack. I think code contribution is only one aspect of this story; my other concern is that from a usability standpoint we would need to provide a clear framework for users to understand what these solutions can do for them and which one to choose. Going forward I think it would be useful if we produced an overarching blueprint that outlines all the ESX options being proposed for OpenStack Networking (and the existing ones, like NSX - formerly known as NVP, or nova-network
Re: [openstack-dev] [nova] Instances randomly failing rebuild on ssh-key errors for non-migration resize - new blueprint
Hi, Please note that you will need to draft a nova spec for the BP. Thanks Gary On 7/8/14, 11:38 AM, Dafna Ron d...@redhat.com wrote: Hi, Bug https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova /%2Bbug/1323578k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoM Qu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=HC6k%2BrchF4bFsit%2FJpRKthSIEkRHfbNQMaqF %2FXg%2FEM0%3D%0As=124c7e1347d725305463188783d574021db49df08a80b0cefd3596 283c73bcf3 was closed since the design is add the localhost to the list of targets and not to only migrate to localhost. I think that there is an issue with that since the user will still randomly fail resize with ssh-key errors when they configure nova to work with allow_resize_to_same_host=True which I think is misleading. I opened a new Blueprint to allow configuring nova to resize on same host only: https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne t/nova/%2Bspec/no-migration-resizek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=HC6k%2BrchF4bFsit%2FJ pRKthSIEkRHfbNQMaqF%2FXg%2FEM0%3D%0As=680867ddfcbdda53a84100884da48811731 b6c9bb816a6f26ac787326e07d968 Thanks, Dafna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Openstack image boot slow
Hi, This should be set by default. Please see http://www.pixelbeat.org/docs/openstack_libvirt_images/ This may help Thanks Gary From: Nhan Cao nhanc...@gmail.commailto:nhanc...@gmail.com Date: Sunday, July 6, 2014 at 3:31 PM To: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Cc: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] Openstack image boot slow hi, thank for reply. how i set cache of libvirt in nova.conf ? 2014-07-06 19:26 GMT+07:00 Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com: Hi, The first boot is usually slow as the image needs to be cached. From that moment on it should be a little quicker. Thanks gary From: Nhan Cao nhanc...@gmail.commailto:nhanc...@gmail.com Date: Sunday, July 6, 2014 at 3:06 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Openstack image boot slow hi guys, i created an images follow tutorial: http://docs.openstack.org/image-guide/content/centos-image.html but when i run it on my openstack lab, it boot very slow. can you tell me some tips to optimize image. Thanks! ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Openstack image boot slow
Hi, The first boot is usually slow as the image needs to be cached. From that moment on it should be a little quicker. Thanks gary From: Nhan Cao nhanc...@gmail.commailto:nhanc...@gmail.com Date: Sunday, July 6, 2014 at 3:06 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Openstack image boot slow hi guys, i created an images follow tutorial: http://docs.openstack.org/image-guide/content/centos-image.html but when i run it on my openstack lab, it boot very slow. can you tell me some tips to optimize image. Thanks! ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[openstack-dev] [Nova} NFV patches
Hi, There are some patches that are relevant to the NFV support. There are as follows: 1. Current exception handling for interface attachment is broken - https://review.openstack.org/103091 2. The V2 port attach is a blocking call. This cannot be changed so a proposal to have the V3 as non blocking has been posted - https://review.openstack.org/103094 3. Logging hints have been added in Neutron api - https://review.openstack.org/#/c/100258/ Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VMware networking
Hi, Sadly last night night we did not have enough people to make any progress. Lets try again next week Monday at 14:00 UTC. The meeting will take place on #openstack-vmware channel Alut a continua Gary On 6/30/14, 6:38 PM, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Jun 30, 2014 at 10:18 AM, Armando M. arma...@gmail.com wrote: Hi Gary, Thanks for sending this out, comments inline. Indeed, thanks Gary! On 29 June 2014 00:15, Gary Kotton gkot...@vmware.com wrote: Hi, At the moment there are a number of different BP¹s that are proposed to enable different VMware network management solutions. The following specs are in review: VMware NSX-vSphere plugin: https://review.openstack.org/102720 Neutron mechanism driver for VMWare vCenter DVS network creation:https://review.openstack.org/#/c/101124/ VMware dvSwitch/vSphere API support for Neutron ML2: https://review.openstack.org/#/c/100810/ I've commented in these reviews about combining efforts here, I'm glad you're taking the lead to make this happen Gary. This is much appreciated! In addition to this there is also talk about HP proposing some for of VMware network management. I believe this is blueprint [1]. This was proposed a while ago, but now it needs to go through the new BP review process. [1] - https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n et/neutron/%2Bspec/ovsvapp-esxi-vxlank=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1 a8dOes8mbE9NM9gvjG2PnJXhUU0%3D%0As=622a539e40b3b950c25f0b6cabf05bc81bb61 159077c00f12d7882680e84a18b Each of the above has specific use case and will enable existing vSphere users to adopt and make use of Neutron. Items #2 and #3 offer a use case where the user is able to leverage and manage VMware DVS networks. This support will have the following limitations: Only VLANs are supported (there is no VXLAN support) No security groups #3 the spec indicates that it will make use of pyvmomi (https://urldefense.proofpoint.com/v1/url?u=https://github.com/vmware/py vmomik=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDt ysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1a8dOes8mbE9NM9gvjG2PnJXhUU0%3D %0As=436b19122463f2b30a5b7fa31880f56ad0127cdaf0250999eba43564f8b559b9). There are a number of disclaimers here: This is currently blocked regarding the integration into the requirements project (https://review.openstack.org/#/c/69964/) The idea was to have oslo.vmware leverage this in the future (https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack /oslo.vmwarek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQ u%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MX5q1Rh4UyhnoZu1a8dOes8mbE9NM9gvjG2PnJX hUU0%3D%0As=e1559fa7ae956d02efe8a65e356f8f0dbfd8a276e5f2e0a4761894e1716 84b03) Item #1 will offer support for all of the existing Neutron API¹s and there functionality. This solution will require a additional component called NSX (https://www.vmware.com/support/pubs/nsx_pubs.html). It's great to see this breakdown, it's very useful in order to identify the potential gaps and overlaps amongst the various efforts around ESX and Neutron. This will also ensure a path towards a coherent code contribution. It would be great if we could all align our efforts and have some clear development items for the community. In order to do this I¹d like suggest that we meet to sync and discuss all efforts. Please let me know if the following sounds ok for an initial meeting to discuss how we can move forwards: - Tuesday 15:00 UTC - IRC channel #openstack-vmware I am available to join. We can discuss the following: Different proposals Combining efforts Setting a formal time for meetings and follow ups Looking forwards to working on this stuff with the community and providing a gateway to using Neutron and further enabling the adaption of OpenStack. I think code contribution is only one aspect of this story; my other concern is that from a usability standpoint we would need to provide a clear framework for users to understand what these solutions can do for them and which one to choose. Going forward I think it would be useful if we produced an overarching blueprint that outlines all the ESX options being proposed for OpenStack Networking (and the existing ones, like NSX - formerly known as NVP, or nova-network), their benefits and drawbacks, their technical dependencies, system requirements, API supported etc. so that a user can make an informed decision when looking at ESX deployments in OpenStack. Thanks Gary Cheers, Armando ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin
[openstack-dev] [Nova] Turbo hipster
Hi, This appears to be broken over the last 24 hours. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] neutron, nova and vif_plugging_* in nova.conf
Hi,
Controller node only.
Thanks
Gary
On 6/23/14, 7:59 PM, Dmitry S. Makovey dmi...@athabascau.ca wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/22/2014 12:36 AM, Gary Kotton wrote:
Hi, The flag makes the libvirt driver use the instance event
mechanism to wait for neutron to confirm that the VIF plugging is
complete before actually starting the VM. In order for this to work
correctly you also Need to make sure that Neutron is aware of these
event.
so my guess is we're talking about:
notify_nova_on_port_status_changes = True
notify_nova_on_port_data_changes = True
nova_url = http://{{ h }}:8774/v2
nova_region_name = MyRegion
nova_admin_username = admin
nova_admin_tenant_id = MyProject
nova_admin_password = VeryS3cr3tP4ssw0rd
nova_admin_auth_url = http://keystone.myorg.com:35357/v2.0
in neutron.conf on controller node? or should it be both network node
and controller node?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iD8DBQFTqFzWyDrVuGfS98QRAmYbAKCmIcII+fMxsvJUhfEylCgIA7LkjgCfYFTH
8EVkRnxKUSPvEir8VKYHMyI=
=lS5O
-END PGP SIGNATURE-
--
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or
privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] neutron, nova and vif_plugging_* in nova.conf
Hi, The flag makes the libvirt driver use the instance event mechanism to wait for neutron to confirm that the VIF plugging is complete before actually starting the VM. In order for this to work correctly you also Need to make sure that Neutron is aware of these event. Thanks Gary On 6/22/14, 12:40 AM, Dmitry S. Makovey dmi...@athabascau.ca wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, while setting up RDO version of OpenStack I've had some issues (see thread struggling with neutron inside VM ) and one suggestion I came across ( http://openstack.redhat.com/Workarounds#nova:_instances_started_in_error_s tate ) was to modify nova.conf to include: vif_plugging_is_fatal: false vif_plugging_timeout: 0 while this workaround helped so far, I would like to know what are the downsides to above workaround? I've spun up sample instances so far and was able to connect using namespaces etc. Am I laying down a garden rake just to walk over it later? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTpfu0yDrVuGfS98QRAhGQAJ4gLTmtQzIwx9rrro4BgHaMnBR/YwCfYmnB 4SDcyjfviEpCYMNxuvq3Tbw= =4uoH -END PGP SIGNATURE- -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [nova][vmware] Future of Vim and PBM in Nova: summary of IRC discussion
Hi, Thanks for the updated mail. I have a number of comments: 1. I agree with the proposed changes regarding the SPBM. I think that the proposal and changes put forward by Radoslav are great. 2. It would be nice to see the integration of the oslo.vmware code. This is pending the spawn rewrite, and a number of other patches in review. So hopefully with a little help and eyes on those reviews we will be able to move forwards with this. 3. Regarding the VIM rewrite proposal. I am not 100% sure what you want to achieve here. I think that it would actually rock the boat and cause a lot of instability. Over the course of the last 3 cycles we have worked very hard to stabilize the Vmware driver. The initial idea was to do a forklift to oslo and then address issues there (supporting the existing API¹s - currently used by Glance and Ceilometer, and a WIP Nova patch). If the new proposal can be be implemented under the existing API¹s then great. If not I think that it will be a wrong direction at the moment. Sadly we are in a mode where we are all stalled on the spawn rewrites. I think that once we have upgraded to oslo then we can open the discussion again. In addition to this there is also the idea of upgrading to pyvmomi in the future, which may also require a rewrite of the code in oslo. My two cents here, lets wait. Regarding the proposed spec it would be great if you could actually add in the proposed API¹s and their comparison to the existing ones. That would give the community a clear picture on what is required. Yeah, things can be improved, but lets at least have a concrete plan on how to do that and not go on a wild journey and have to revert everything a few months down the line. Thanks Gary On 6/20/14, 1:47 PM, Matthew Booth mbo...@redhat.com wrote: For anybody who missed it, we discussed the following 2 outstanding reviews yesterday: vmwareapi oslo.vmware library integration https://review.openstack.org/#/c/70175/ VMware: initial support for SPBM https://review.openstack.org/#/c/6/ The issue is that oslo.vmware already contains nascent support for SPBM, so these are really 2 patches trying to achieve the same thing by different, incompatible means. After some discussion, we agreed that we would abandon the Nova SPBM patch to concentrate on the oslo.vmware patch. This patch has languished, but Vui is going to bring it up to date. It also has an approved BP. We also agreed that we only want 1 refactor review queue. As the oslo.vmware patch touches so much code, it inevitably conflicts with the spawn refactor. Therefore we will either rebase oslo.vmware on to the spawn refactor, or vice versa. As both patch sets are primarily on Vui, he will make the call about which is least disruptive. Radoslav has identified some non-disruptive cleanup work which he originally put into the Nova SPBM patch. He will now move this into oslo.vmware. This cleanup will be 100% backwards compatible, requiring no client updates whatsoever to continue working. We also need to add some additional features to SPBM support in oslo.vmware. These will be added, ensuring they don't impact any existing Vim users, and the oslo.vmware version bumped. I am continuing to advocate a significant rewrite of the Vim API. However, as we aren't proposing any backwards incompatible changes at the moment there is no current incentive to bring this forward. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][Oslo.cfg] Configuration string substitution
Hi,
I have encountered a problem with string substitution with the nova
configuration file. The motivation was to move all of the glance settings to
their own section (https://review.openstack.org/#/c/100567/). The
glance_api_servers had default setting that uses the current glance_host and
the glance port. This is a problem when we move to the 'glance' section.
First and foremost I think that we need to decide on how we should denote the
string substitutions for group variables and then we can dive into
implementation details. Does anyone have any thoughts on this?
My thinking is that when we use we should use a format of $group.key. An
example is below.
Original code:
cfg.ListOpt('glance_api_servers',
default=['$glance_host:$glance_port'],
help='A list of the glance api servers available to nova. '
'Prefix with https:// for ssl-based glance api servers. '
'([hostname|ip]:port)'),
Proposed change (in the glance section):
cfg.ListOpt('api_servers',
default=['$glance.host:$glance.port'],
help='A list of the glance api servers available to nova. '
'Prefix with https:// for ssl-based glance api servers. '
'([hostname|ip]:port)',
deprecated_group='DEFAULT',
deprecated_name='glance_api_servers'),
This would require some preprocessing on the oslo.cfg side to be able to
understand the $glance is the specific group and then host is the requested
value int he group.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Oslo.cfg] Configuration string substitution
On 6/18/14, 4:19 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote:
On Wed, Jun 18, 2014 at 4:47 AM, Gary Kotton gkot...@vmware.com wrote:
Hi,
I have encountered a problem with string substitution with the nova
configuration file. The motivation was to move all of the glance
settings to
their own section (https://review.openstack.org/#/c/100567/). The
glance_api_servers had default setting that uses the current
glance_host and
the glance port. This is a problem when we move to the Œglance¹ section.
First and foremost I think that we need to decide on how we should
denote
the string substitutions for group variables and then we can dive into
implementation details. Does anyone have any thoughts on this?
My thinking is that when we use we should use a format of
$group.key. An
example is below.
Original code:
cfg.ListOpt('glance_api_servers',
default=['$glance_host:$glance_port'],
help='A list of the glance api servers available to
nova. '
'Prefix with
https://urldefense.proofpoint.com/v1/url?u=https:///k=oIvRg1%2BdGAgOoM1B
IlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=t
PCYaurIa1F3hEMCd5LOOfvP785BZFa8M58fXpp0Lcw%3D%0As=2ac62a772fd5bd58fa7cf7
0a973956ba97f933d649fb2f95be7b7d3e18d2b086 for ssl-based glance api
servers.
'
'([hostname|ip]:port)'),
Proposed change (in the glance section):
cfg.ListOpt('api_servers',
default=[Œ$glance.host:$glance.port'],
help='A list of the glance api servers available to
nova. '
'Prefix with
https://urldefense.proofpoint.com/v1/url?u=https:///k=oIvRg1%2BdGAgOoM1B
IlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=t
PCYaurIa1F3hEMCd5LOOfvP785BZFa8M58fXpp0Lcw%3D%0As=2ac62a772fd5bd58fa7cf7
0a973956ba97f933d649fb2f95be7b7d3e18d2b086 for ssl-based glance api
servers.
'
'([hostname|ip]:port)¹,
deprecated_group='DEFAULT¹,
deprecated_name='glance_api_servers'),
This would require some preprocessing on the oslo.cfg side to be able to
understand the $glance is the specific group and then host is the
requested
value int he group.
Thanks
Gary
Do we need to set the variable off somehow to allow substitutions that
need the literal '.' after a variable? How often is that likely to
come up?
To be honest I think that this is a real edge case. I had a chat with
markmc on IRC and he suggested a different approach, which I liked,
regarding the specific patch. That is, to set the default to None and when
the data is accessed to check if it is is None. If so then provide the
default values.
We may still nonetheless need something like this in the future.
Doug
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load
On 6/17/14, 1:56 PM, Duncan Thomas duncan.tho...@gmail.com wrote: A far more effective way to reduce the load of trivial review issues on core reviewers is for none-core reviewers to get in there first, spot the problems and add a -1 - the trivial issues are then hopefully fixed up before a core reviewer even looks at the patch. The fundamental problem with review is that there are more people submitting than doing regular reviews. If you want the review queue to shrink, do five reviews for every one you submit. +1 What you give is what you get! A -1 from a none-core (followed by a +1 when all the issues are fixed) is far, far, far more useful in general than a +1 on a new patch. On 17 June 2014 11:04, Matthew Booth mbo...@redhat.com wrote: We all know that review can be a bottleneck for Nova patches.Not only that, but a patch lingering in review, no matter how trivial, will eventually accrue rebases which sap gate resources, developer time, and will to live. It occurs to me that there are a significant class of patches which simply don't require the attention of a core reviewer. Some examples: * Indentation cleanup/comment fixes * Simple code motion * File permission changes * Trivial fixes which are obviously correct The advantage of a core reviewer is that they have experience of the whole code base, and have proven their ability to make and judge core changes. However, some fixes don't require this level of attention, as they are self-contained and obvious to any reasonable programmer. Without knowing anything of the architecture of gerrit, I propose something along the lines of a '+1 (trivial)' review flag. If a review gained some small number of these, I suggest 2 would be reasonable, it would be equivalent to a +2 from a core reviewer. The ability to set this flag would be a privilege. However, the bar to gaining this privilege would be low, and preferably automatically set, e.g. 5 accepted patches. It would be removed for abuse. Is this practical? Would it help? Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Starting contributing to project
Hi, I would suggest that you start from the master branch. Good luck. Thanks HGary On 6/15/14, 11:10 PM, Sławek Kapłoński sla...@kaplonski.pl wrote: Hello, I want to start contributing to neutron project. I found bug which I want to try fix: https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/neut ron/%2Bbug/1204956k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6h goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=dP2CZk5H6DBGb0c6WGiN01Xa7nUB4zYub3RbN WU%2B1wM%3D%0As=699d64d0369e412e78c3511245e8453e30603f4b3bc90a1d0fc69c0ac fda44d6 and I have question about workflow in such case. Should I clone neutron reposiotory from branch master and do changes based on master branch or maybe should I do my changes starting from any other branch? What should I do next when I will for example do patch for such bug? Thanks in advance for any help and explanation about that -- Best regards Slawek Kaplonski sla...@kaplonski.pl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints
On 6/14/14, 1:05 AM, Anita Kuno ante...@anteaya.info wrote: On 06/13/2014 05:58 PM, Carlos Gonçalves wrote: Let me add to what I've said in my previous email, that Instituto de Telecomunicacoes and Portugal Telecom are also available to host and organize a mid cycle sprint in Lisbon, Portugal. Please let me know who may be interested in participating. Thanks, Carlos Goncalves On 13 Jun 2014, at 10:45, Carlos Gonçalves m...@cgoncalves.pt wrote: Hi, I like the idea of arranging a mid cycle for Neutron in Europe somewhere in July. I was also considering inviting folks from the OpenStack NFV team to meet up for a F2F kick-off. I did not know about the sprint being hosted and organised by eNovance in Paris until just now. I think it is a great initiative from eNovance even because it¹s not being focused on a specific OpenStack project. So, I'm interested in participating in this sprint for discussing Neutron and NFV. Two more people from Instituto de Telecomunicacoes and Portugal Telecom have shown interested too. Neutron and NFV team members, who¹s interested in meeting in Paris, or if not available on the date set by eNovance in other time and place? Thanks, Carlos Goncalves On 13 Jun 2014, at 08:42, Sylvain Bauza sba...@redhat.com wrote: Le 12/06/2014 15:32, Gary Kotton a écrit : Hi, There is the mid cycle sprint in July for Nova and Neutron. Anyone interested in maybe getting one together in Europe/Middle East around the same dates? If people are willing to come to this part of the world I am sure that we can organize a venue for a few days. Anyone interested. If we can get a quorum then I will be happy to try and arrange things. Thanks Gary Hi Gary, Wouldn't it be more interesting to have a mid-cycle sprint *before* the Nova one (which is targeted after juno-2) so that we could discuss on some topics and make a status to other folks so that it would allow a second run ? There is already a proposal in Paris for hosting some OpenStack sprints, see https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Neutron already has two sprints scheduled: https://wiki.openstack.org/wiki/Sprints Those sprints are both in the US. It is a very long way to travel. If there are a group of people that can get together in Europe then it would be great. Thanks, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] VMware ESX Driver Deprecation
Hi, In the Icehouse cycle it was decided to deprecate the VMware ESX driver. The motivation for the decision was: * The driver is not validated by Minesweeper * It is not clear if there are actually any users of the driver Prior to jumping into the proposal we should take into account that the current ESX driver does not work with the following branches: * Master (Juno) * Icehouse * Havana The above are due to VC features that were added over the course of these cycles. On the VC side the ESX can be added to a cluster and the running VM's will continue to run. The problem is how that are tracked and maintained in the Nova DB. Option 1: Moving the ESX(s) into a nova managed cluster. This would require the nova DB entry for the instance running on the ESX to be updated to be running on the VC host. If the VC host restarts at point during the above then all of the running instances may be deleted (this is due to the fact that _destroy_evacuated_instances is invoked when a nova compute is started https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L673). This would be disastrous for a running deployment. If we do decide to go for the above option we can perform a cold migration of the instances from the ESX hosts to the VC hosts. The fact that the same instance will be running on the ESX would require us to have a 'noop' for the migration. This can be done by configuration variables but that will be messy. This option would require code changes. Option 2: Provide the administrator with tools that will enable a migration of the running VM's. 1. A script that will import OpenStack VM's into the database - the script will detect VM's running on a VC and import them to the database. 2. A scrip that will delete VM's running on a specific host The admin will use these as follows: 1. Invoke the deletion script for the ESX 2. Add the ESX to a VC 3. Invoke the script for importing the OpenStack VM's into the database 4. Start the nova compute with the VC driver 5. Terminate all Nova computes with the ESX driver This option requires the addition of the scripts. The advantage is that it does not touch any of the running code and is done out of band. A variant of option 2 would be to have a script that updates the host for the ESX VM's to the VC host. Due to the fact that the code is not being run at the moment I am in favor of the external scripts as it will be less disruptive and not be on a critical path. Any thoughts or comments? Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core
+1 On 6/15/14, 6:15 AM, Chris Behrens cbehr...@codestud.com wrote: +1 On Jun 13, 2014, at 3:40 PM, Michael Still mi...@stillhq.com wrote: Greetings, I would like to nominate Ken'ichi Ohmichi for the nova-core team. Ken'ichi has been involved with nova for a long time now. His reviews on API changes are excellent, and he's been part of the team that has driven the new API work we've seen in recent cycles forward. Ken'ichi has also been reviewing other parts of the code base, and I think his reviews are detailed and helpful. Please respond with +1s or any concerns. References: https://review.openstack.org/#/q/owner:ken1ohmichi%2540gmail.com+status:o pen,n,z https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com,n,z https://urldefense.proofpoint.com/v1/url?u=http://www.stackalytics.com/?m odule%3Dnova-group%26user_id%3Doomichik=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0 Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=kMfBWe6o2%2BQDf QNNU1pcKVuu7ezNLimr6qLaM9vObMI%3D%0As=d9b50754db9a4e9f859919399efbb4f0a5 bc69a949139611e8423a523601caa2 As a reminder, we use the voting process outlined at https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our core team. Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
I think that is a very good point. This should maybe be addressed in the API layer as you have suggested. Thanks Gary From: Day, Phil Day philip@hp.commailto:philip@hp.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, June 13, 2014 at 4:22 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? I guess the question I'm really asking here is: Since we know resize down won't work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ? From: Andrew Laski [mailto:andrew.la...@rackspace.com] Sent: 13 June 2014 13:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 06/13/2014 08:03 AM, Day, Phil wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. That's what I thought - but many of the drivers seem to at least partially support it based on the code, hence the question on here to find out of that is really supported and works - or is just inconsistent error checking across drivers. My grumpy dev answer is that what works is not resizing down. I'm familiar with the xen driver resize operation and will say that it does work when the guest filesystem and partition sizes are accommodating, but there's no good way to know whether or not it will succeed without actually trying it. So when it fails it's after someone was waiting on a resize that seemed like it was working and then suddenly didn't. If we want to aim for what's going to work consistently across drivers, it's probably going to end up being not resizing disks down. From: Aryeh Friedman [mailto:aryeh.fried...@gmail.com] Sent: 13 June 2014 11:12 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil philip@hp.commailto:philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones - which seems fair enough I guess (you can't drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn't it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn't support resize hyperv: Checks only for root disk (https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py%23L99-L108k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=1meUXb4syMIPy2G%2BHcsy3qccL7i2ULAgEaQdNbTNnOk%3D%0As=18797dc88941e101a48538fe1b7e74595d19af8bd10c4305df404b5309ee66f2 ) libvirt: fails for a reduction of either root or ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py%23L4918-L4923k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=1meUXb4syMIPy2G%2BHcsy3qccL7i2ULAgEaQdNbTNnOk%3D%0As=a00cd8642bba9bd0a6b788f3aabdeace918e86a6129ace3bce316a9d3a613592 ) vmware: doesn't seem to check at all ? xen: Allows resize down for root but not for ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py%23L1015-L1032k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=1meUXb4syMIPy2G%2BHcsy3qccL7i2ULAgEaQdNbTNnOk%3D%0As=7507996a7fb34b0497f85386caf7980f73d0c90fe2f59e15b3c4c87e30157e82 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer,
[openstack-dev] [Nova]{neutron] Mid cycle sprints
Hi, There is the mid cycle sprint in July for Nova and Neutron. Anyone interested in maybe getting one together in Europe/Middle East around the same dates? If people are willing to come to this part of the world I am sure that we can organize a venue for a few days. Anyone interested. If we can get a quorum then I will be happy to try and arrange things. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova]{neutron] Mid cycle sprints
This part of the world == Israel (it has been a long week :))
From: administrator gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, June 12, 2014 at 4:32 PM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova]{neutron] Mid cycle sprints
Hi,
There is the mid cycle sprint in July for Nova and Neutron. Anyone interested
in maybe getting one together in Europe/Middle East around the same dates? If
people are willing to come to this part of the world I am sure that we can
organize a venue for a few days. Anyone interested. If we can get a quorum then
I will be happy to try and arrange things.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Diagnostics spec
Hi, Any chance of getting a review on https://review.openstack.org/84691. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Is there a sample application source code run on openStack?
Hi, A very simple example is running devstack. That loads an image ins to glance and walla! In addition to this I am sure that you can run heat on top of that and you can see a application from A - Z. Www.devstack.org Thanks Gary From: hossein zabolzadeh zabolza...@gmail.commailto:zabolza...@gmail.com Date: Monday, June 9, 2014 at 2:41 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Is there a sample application source code run on openStack? Hi there. Is there any source code available for cloud-ready application that can be run on the openStack cloud(Simple Hello World app)? I want to see how existing applications can be changed in a way to work on the openStack cloud. Thanks in advance. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Yahoo-eng-team] [Bug 1275773] Re: VMware session not logged out on VMwareAPISession garbage collection
The issue was addressed by remove the __del__ from the class. This was done in https://github.com/openstack/nova/commit/b28530ce83302dacae90c385c5431fb1a758ef0a ** Changed in: nova Status: Triaged = Fix Committed ** Changed in: nova Status: Fix Committed = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1275773 Title: VMware session not logged out on VMwareAPISession garbage collection Status in OpenStack Compute (Nova): Won't Fix Bug description: A bug in VMwareAPISession.__del__() prevents the session being logged out when the session object is garbage collected. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1275773/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1325812] [NEW] HACKING rst does not have rules N320
Public bug reported: Commit 9235ada8c2c250603dc5b299cc08bb7a982d4fc6 did not add the rule to the HACKING.rst ** Affects: nova Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Importance: Undecided = Medium ** Changed in: nova Milestone: None = juno-1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1325812 Title: HACKING rst does not have rules N320 Status in OpenStack Compute (Nova): In Progress Bug description: Commit 9235ada8c2c250603dc5b299cc08bb7a982d4fc6 did not add the rule to the HACKING.rst To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1325812/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1324120] [NEW] NSX: exception when creating a flat network
.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session RuntimeError: maximum recursion depth exceeded 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session Problem is the line https://github.com/openstack/neutron/blob/master/neutron/plugins/vmware/plugins/base.py#L1012. A flat network will return an object instead of 0 ** Affects: neutron Importance: High Assignee: Gary Kotton (garyk) Status: New ** Tags: icehouse-backport-potential ** Changed in: neutron Importance: Undecided = High ** Changed in: neutron Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: neutron Milestone: None = juno-1 ** Tags added: icehouse-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1324120 Title: NSX: exception when creating a flat network Status in OpenStack Neutron (virtual network service): New Bug description: 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session File /usr/lib/python2.7/dist-packages/MySQLdb/converters.py, line 97, in Instance2Str 2014-05-28 05:38:02.696 TRACE neutron.openstack.common.db.sqlalchemy.session return d[o.__class__](o, d) 2014-05-28 05:38:02.696 TRACE
Re: [openstack-dev] [neutron] Proposed changes to core team
+1 On 5/26/14 1:35 PM, Akihiro Motoki amot...@gmail.com wrote: +1 from me too. Akihiro On Thu, May 22, 2014 at 5:59 AM, Kyle Mestery mest...@noironetworks.com wrote: I would like to propose a few changes to the Neutron core team. Looking at how current cores are contributing, both in terms of review [1] as well as project participation and attendance at the summit sessions last week, I am proposing a few changes. As cores, I believe reviews are critical, but I also believe interacting with the Neutron and OpenStack communities in general is important. The first change I'd like to propose is removing Yong Sheng Gong from neutron-core. Yong has been a core for a long time. I'd like to thank him for all of his work on Neutron over the years. Going forward, I'd also to propose that if Yong's participation and review stats improve he could be fast-tracked back to core status. But for now, his review stats for the past 90 days do not line up with current cores, and his participation in general has dropped off. So I am proposing his removal from neutron-core. Since we're losing a core team member, I'd like to propose Carl Baldwin (carl_baldwin) for Neutron core. Carl has been a very active reviewer for Neutron, his stats are well in-line with other core reviewers. Additionally, Carl has been leading the L3 sub-team [2] for a while now. He's a very active member of the Neutron community, and he is actively leading development of some important features for the Juno release. Neutron cores, please vote +1/-1 for the proposed addition of Carl Baldwin to Neutron core. I also wanted to mention the process for adding, removing, and maintaining neutron-core membership is now documented on the wiki here [3]. Thank you! Kyle [1] https://urldefense.proofpoint.com/v1/url?u=http://stackalytics.com/report /contribution/neutron/90k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8 NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jqf%2Fe8eY %2BtGs%2BpsxwPLmUJ14%3D%0As=c2f6363f076a61717a6d783c76fcfca4dd4ba7d33976 a84d0968adf6f437856c [2] https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik i/Meetings/Neutron-L3-Subteamk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0px TUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jqf%2 Fe8eY%2BtGs%2BpsxwPLmUJ14%3D%0As=377c0039155a3e1eda83c067e72f95cc4c8c47a 856f4a95fed8cca401553239e [3] https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik i/NeutronCorek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQ u%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jqf%2Fe8eY%2BtGs%2Bps xwPLmUJ14%3D%0As=326344d08265e042e513b43e0f1ea6060909ae94bed085f197e818e 2d0710920 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs 8Jqf%2Fe8eY%2BtGs%2BpsxwPLmUJ14%3D%0As=74bf5902221c96ab023b45cdb752e444f 1f7024b5c264a3a1c61e1e5fcf13c37 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jq f%2Fe8eY%2BtGs%2BpsxwPLmUJ14%3D%0As=74bf5902221c96ab023b45cdb752e444f1f70 24b5c264a3a1c61e1e5fcf13c37 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Making Image Launch faster in Openstack
Hi, At the summit there was a session about this. Please also see https://review.openstack.org/85792 Thanks Gary From: Rakesh Sinha rakesh.si...@gslab.commailto:rakesh.si...@gslab.com Date: Monday, May 26, 2014 4:35 PM To: Pádraig Brady p...@draigbrady.commailto:p...@draigbrady.com Cc: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] Making Image Launch faster in Openstack Thanks Padraig, but is there any other way than using squid. Like calling API's in glance or calling nova-compute API's or add something in glance code which triggers copy of vmdk to all compute nodes after image is uploaded. On Mon, May 26, 2014 at 5:47 PM, Pádraig Brady p...@draigbrady.commailto:p...@draigbrady.com wrote: On 05/26/2014 12:54 PM, Rakesh Sinha wrote: Hi I am aware that first instance launch over a Compute Node takes time because it has to copy image from the Glance Server to the Compute Node. Since the local copy is available over the Compute now so next time it launches faster. I want that when the Image is uploaded over the Glance Server then only it makes a copy of it over the Compute Server also so that there is no delay even if the Image is launched for the first time or nth time. Please suggest proper methods to achieve so or maybe some code changes. CERN did some work on that: http://coarasa.dyndns.org/?p=162https://urldefense.proofpoint.com/v1/url?u=http://coarasa.dyndns.org/?p%3D162k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=uk5UeNLCDtH4%2Bx1kXlhPNZ8GLyRTbsDUSKlzpqsezDY%3D%0As=b76ce857ca16d18b390c9fd45d1f6282dbf0a49dfbc79bfdea724b1f94837e09 thanks, Pádraig. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] vSphere migration (/sync ?)
Hi, At the moment this is not something that is supported. A number of times this has been discussed and the general consensus of the community is that OpenStack should do the deployment and management. I think that it could be very useful to import existing workloads into OpenStack. It may be worthwhile discussing on the lists. Thanks Gary From: Pierre Pouzols pierre.pouz...@ense.comailto:pierre.pouz...@ense.co Date: Friday, May 23, 2014 5:27 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] vSphere migration (/sync ?) Hi, I'm looking for some migration feedbacks, from vSphere to OpenStack, continuing to use vSphere as hypervisor. Is there a possibility to synchronize the two inventories ? (manually, script, module ?) Thanks ! -- Pierre Pouzols Mail : pierre.pouz...@ense.comailto:pierre.pouz...@ense.co ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Neutron] Need help to start contribute to Neutron
Hi, I would suggest the following: 1. Look at the bugs and see if there is any low hanging fruit - https://bugs.launchpad.net/neutron/+bugs?field.tag=low-hanging-fruit 2. Try and add some additional unit tests – pick a section of code that interests you and try and see that it has some good code coverage with the unit tests 3. Go over the blueprints and see if there is something that interests you – if so, ask the guys driving it if you can help Good luck. Thanks Gary From: Li, Chen chen...@intel.commailto:chen...@intel.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 22, 2014 11:56 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] Need help to start contribute to Neutron Hi list, I have using Openstack/Neutron for a while. And now I hope I can do some contributions too. But neutron is too complicated, I don’t know where to start. In IRC, iwamoto suggested me to work with developer doc team. That sounds like a good idea. But I still doesn’t know what/where I should start with. Can someone help me ? Or just told me anything you think I can work on ? Thanks. -chen I used to working on CentOS, installing neutron directly using command “yum install neutron-xxx”. Now, I have already download neutron code, and run successfully run unittest. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Changing port status
Hi, In general there plaguing is responsible for setting the port status. So for example if you are using the OVS plugin, when the OVS agent attaches the virtual port to the integration bridge it will notify the service and the port status will be set. Thanks Gary From: Shital Patil shital.pa...@gslab.commailto:shital.pa...@gslab.com Date: Wednesday, May 21, 2014 6:06 AM To: Administrator gkot...@vmware.commailto:gkot...@vmware.com Cc: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] Changing port status Thanks a lot for answer So for port state to change from DOWN to ACTIVE do I have to do some changes in physical networks? I am fairly new to openstack and have very basic knowledge on openstack networking so please suggest me a way to achieve this On Tue, May 20, 2014 at 5:27 PM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, At the moment you are able to dynamically add and remove a nic from an instance if and only if you are using Neutron. This is currently supported by libvirt. The code for Vmware is up in review for Juno and in development for the XenAPI. The port will become active when the backend networking implementation has the interface attached to the instance and the virtual nic attached to the virtual network. Thanks Gary From: Shital Patil shital.pa...@gslab.commailto:shital.pa...@gslab.com Date: Tuesday, May 20, 2014 2:21 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Changing port status Hi, I was searching on a way to add multiple interfaces for an instance launched on openstack. I found this concept of ports created within neutron network. I could create port but its status is always down so - 1- What would I need to do to make port status active 2- Is this the right way to add multiple interfaces to instance? Thank you ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] VMware VCDdriver without vCenter
Hi, It was discussed at the recent summit to deprecate the ESX driver. In Icehouse there was a deprecation warning added to the code - https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L103 We need to discuss how we are going to do the migration path. Please note that the VC driver only works if you have a vCenter (which interfaces with one or more ESX's). Thanks Gary From: ZIBA Romain romain.z...@eurogiciel.frmailto:romain.z...@eurogiciel.fr Date: Tuesday, May 20, 2014 11:57 AM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] VMware VCDdriver without vCenter Hello everyone, I have read that ESXdriver will disappear in Openstack Juno version. If I have only one ESXI with no vCenter server, will I be able to use the Openstack VCDdriver? Thanks beforehand. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Changing port status
Hi, At the moment you are able to dynamically add and remove a nic from an instance if and only if you are using Neutron. This is currently supported by libvirt. The code for Vmware is up in review for Juno and in development for the XenAPI. The port will become active when the backend networking implementation has the interface attached to the instance and the virtual nic attached to the virtual network. Thanks Gary From: Shital Patil shital.pa...@gslab.commailto:shital.pa...@gslab.com Date: Tuesday, May 20, 2014 2:21 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Changing port status Hi, I was searching on a way to add multiple interfaces for an instance launched on openstack. I found this concept of ports created within neutron network. I could create port but its status is always down so - 1- What would I need to do to make port status active 2- Is this the right way to add multiple interfaces to instance? Thank you ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Yahoo-eng-team] [Bug 1320867] [NEW] Log debugs should not have translations
Public bug reported: Our translation policy (https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation) calls for not translating debug level logs. This is to help prioritize log translation. Furthermore translation has a performance overhead, even if the log isn't used (since nova doesn't support lazy translation yet). ** Affects: neutron Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1320867 Title: Log debugs should not have translations Status in OpenStack Neutron (virtual network service): In Progress Bug description: Our translation policy (https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation) calls for not translating debug level logs. This is to help prioritize log translation. Furthermore translation has a performance overhead, even if the log isn't used (since nova doesn't support lazy translation yet). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1320867/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1315870] [NEW] VMware: some unit tests taking longer than a second
Public bug reported: nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_file_fault 1.040 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_file_locked 1.030 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_move_file_exists_poll_exception 1.028 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_move_file_exists_exception 1.028 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_cannot_delete_file 1.028 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_general 1.027 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_move_general_exception 1.027 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_not_found 1.026 ** Affects: nova Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: nova Importance: Undecided = Medium ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = juno-1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1315870 Title: VMware: some unit tests taking longer than a second Status in OpenStack Compute (Nova): In Progress Bug description: nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_file_fault 1.040 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_file_locked 1.030 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_move_file_exists_poll_exception 1.028 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_move_file_exists_exception 1.028 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_cannot_delete_file 1.028 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_general 1.027 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_move_general_exception 1.027 nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_spawn_with_delete_exception_not_found 1.026 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1315870/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1314994] [NEW] There are log messages that do not have transtaions
Public bug reported: Following files have log messages that are not translated: neutron/agent/securitygroups_rpc.py neutron/plugins/hyperv/agent/security_groups_driver.py neutron/plugins/hyperv/agent/utilsfactory.py neutron/plugins/plumgrid/plumgrid_plugin/plumgrid_plugin.py ** Affects: neutron Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: neutron Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: neutron Milestone: None = juno-1 ** Changed in: neutron Importance: Undecided = Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1314994 Title: There are log messages that do not have transtaions Status in OpenStack Neutron (virtual network service): In Progress Bug description: Following files have log messages that are not translated: neutron/agent/securitygroups_rpc.py neutron/plugins/hyperv/agent/security_groups_driver.py neutron/plugins/hyperv/agent/utilsfactory.py neutron/plugins/plumgrid/plumgrid_plugin/plumgrid_plugin.py To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1314994/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[openstack-dev] [Infra] Gerrit upgrade
Hi, Thanks to all those involved. Any chance of restoring the Diff side by side button. The new interface may take a while to get used to. In the past there was a link to the current branch patches. That too is missing. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1313322] [NEW] Hacking rules N319 no documented
Public bug reported: Commit ac8bce63f8a7ec8a2ebb214ea7f86ee4f8adecae did not document the rules in the HACKING.rst file ** Affects: nova Importance: Medium Assignee: Gary Kotton (garyk) Status: New ** Changed in: nova Importance: Undecided = Medium ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = juno-1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1313322 Title: Hacking rules N319 no documented Status in OpenStack Compute (Nova): New Bug description: Commit ac8bce63f8a7ec8a2ebb214ea7f86ee4f8adecae did not document the rules in the HACKING.rst file To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1313322/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] [neutron] Neutron Mid-Cycle Meeting
Hi, Any chance of doing this in Europe? Thanks Gary On 4/16/14 4:54 AM, Kyle Mestery mest...@noironetworks.com wrote: Folks: Given all the talk of mid-cycle meetings, I'd like to propose that we do one for Neutron as well. Mark and I talked about this over the past few months, and I've mentioned this to a few other people as well. I think it would be ideal to get everyone together in the July timeframe, but I'd like to hear from others on dates. I've setup an etherpad to track the discussion here [1]. Can people weigh in on which week works for them? If there are events happening on those weeks which would preclude people from attending, I'd also like to hear that. I have a proposed location and sponsor, but I'm open to hearing other options as well if the proposed location doesn't work for anyone. Thanks! Kyle [1] https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/ p/neutron-juno-mid-cycle-meetingk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0 pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=LqFMtBoARpokZvYcobdPZUS WSSXtWpWpuVUzqNOIsAo%3D%0As=4669e387ed5dc7dd4d1317ee92940dac36eb6b7e53754 f5d9d7f8e049159a67b ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=LqFMtBoARpokZvYcobdPZ USWSSXtWpWpuVUzqNOIsAo%3D%0As=a6b2831efac0d6f1d1d23878f9a55c6171f6199c262 0cf41cdd2b85f774aaf6e ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron BP review process for Juno
+1 On 4/16/14 1:35 AM, Carl Baldwin c...@ecbaldwin.net wrote: +1. I think we'll like this process better. I hope to have some of the first blueprints to propose to the new repository very soon. On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery mest...@noironetworks.com wrote: Given the success the Nova team has had in handling reviews using their new nova-specs gerrit repository, I think it makes a lot of sense for Neutron to do the same. With this in mind, I've added instructions to the BP wiki [1] for how to do. Going forward in Juno, this is how Neutron BPs will be handled by the Neutron core team. If you are currently working on a BP or code for Juno which is attached to a BP, please file the BP using the process here [1]. Given this is our first attempt at using this for reviews, I anticipate there may be a few hiccups along the way. Please reply on this thread or reach out in #openstack-neutron and we'll sort through whatever issues we find. Thanks! Kyle [1] https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik i/Blueprints%23Neutronk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NP ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MyzVItNCAzhBG2AUe%2FpCJRMnHjrDq gITgT1fkxc3s0k%3D%0As=caf23da791f6776beb0a12441650f4969ebdd9aa9f35d27f56 0ad144c12bf354 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MyzVItNCAzhBG2AUe% 2FpCJRMnHjrDqgITgT1fkxc3s0k%3D%0As=08c9066de11d376ded51257f7210d3172284f 89c5f46cee9e273f10897f52500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=MyzVItNCAzhBG2AUe%2Fp CJRMnHjrDqgITgT1fkxc3s0k%3D%0As=08c9066de11d376ded51257f7210d3172284f89c5 f46cee9e273f10897f52500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1304917] [NEW] VMware: fakes.py should be moved to the tests directory
Public bug reported: The file nova/virt/vmwareapi/fake.py should be moved to the tests directory. This is solely used in the unit tests. There is no need for this to reside in the virt directory. ** Affects: nova Importance: Wishlist Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: vmware ** Changed in: nova Importance: Undecided = Wishlist ** Changed in: nova Milestone: None = juno-1 ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1304917 Title: VMware: fakes.py should be moved to the tests directory Status in OpenStack Compute (Nova): In Progress Bug description: The file nova/virt/vmwareapi/fake.py should be moved to the tests directory. This is solely used in the unit tests. There is no need for this to reside in the virt directory. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1304917/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1305032] [NEW] Logging under exception handling should make use of save_and_reraise
Public bug reported: When logging exceptions the exception handling should make use of save_and_reraise ** Affects: neutron Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: neutron Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: neutron Importance: Undecided = Medium ** Changed in: neutron Milestone: None = juno-1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1305032 Title: Logging under exception handling should make use of save_and_reraise Status in OpenStack Neutron (virtual network service): In Progress Bug description: When logging exceptions the exception handling should make use of save_and_reraise To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1305032/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1302238] Re: throw exception if no configured affinity filter
*** This bug is a duplicate of bug 1303983 *** https://bugs.launchpad.net/bugs/1303983 This was addressed by https://github.com/openstack/nova/commit/7b8402ed3ba734836119441bdf1a6d6c661c8df2 ** Changed in: nova Status: In Progress = Fix Released ** This bug has been marked a duplicate of bug 1303983 Enable ServerGroup scheduler filters by default -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1302238 Title: throw exception if no configured affinity filter Status in OpenStack Compute (Nova): Fix Released Bug description: After https://blueprints.launchpad.net/nova/+spec/instance-group-api- extension, nova has the feature of creating instance groups with affinity or anti-affinity policy and creating vm instance with affinity/anti-affinity group. If did not enable ServerGroupAffinityFilter and ServerGroupAntiAffinityFilter, then the instance group will not able to leverage affinity/anti-affinity. Take the following case: 1) Create a group with affinity 2) Create two vms with this group 3) The result is that those two vms was not created on the same host. We should throw exception if using server group with no configured affinity filter To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1302238/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1302238] Re: throw exception if no configured affinity filter
** This bug is no longer a duplicate of bug 1303983 Enable ServerGroup scheduler filters by default ** Changed in: nova Status: Fix Released = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1302238 Title: throw exception if no configured affinity filter Status in OpenStack Compute (Nova): In Progress Bug description: After https://blueprints.launchpad.net/nova/+spec/instance-group-api- extension, nova has the feature of creating instance groups with affinity or anti-affinity policy and creating vm instance with affinity/anti-affinity group. If did not enable ServerGroupAffinityFilter and ServerGroupAntiAffinityFilter, then the instance group will not able to leverage affinity/anti-affinity. Take the following case: 1) Create a group with affinity 2) Create two vms with this group 3) The result is that those two vms was not created on the same host. We should throw exception if using server group with no configured affinity filter To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1302238/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1304593] [NEW] VMware: waiste of disk datastore when root disk size of instance is 0
Public bug reported: When an instance has 0 root disk size an extra image is created on the datastore (uuid.0.vmdk that is identical to uuid.vmdk). This is only in the case of a linked clone image and waists space on the datastore. The original image that is cached can be used. ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: icehouse-backport-potential vmware ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = juno-1 ** Changed in: nova Importance: Undecided = High ** Tags added: icehouse-backport-potential vmware -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1304593 Title: VMware: waiste of disk datastore when root disk size of instance is 0 Status in OpenStack Compute (Nova): In Progress Bug description: When an instance has 0 root disk size an extra image is created on the datastore (uuid.0.vmdk that is identical to uuid.vmdk). This is only in the case of a linked clone image and waists space on the datastore. The original image that is cached can be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1304593/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1296873] Re: VMware: InvalidDiskFormat when booting from volume
*** This bug is a duplicate of bug 1296874 ***
https://bugs.launchpad.net/bugs/1296874
** This bug has been marked a duplicate of bug 1296874
VMware: InvalidDiskFormat when booting from volume
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1296873
Title:
VMware: InvalidDiskFormat when booting from volume
Status in OpenStack Compute (Nova):
New
Bug description:
Using the VC Driver, an InvalidDiskFormat is seen when attempting to
boot from a volume. The scenario is:
1. Create a volume of any size
2. Boot from the volume
The following error message is seen:
Traceback (most recent call last):
File /opt/stack/nova/nova/compute/manager.py, line 1306, in
_build_instance
set_access_ip=set_access_ip)
File /opt/stack/nova/nova/compute/manager.py, line 394, in
decorated_function
return function(self, context, *args, **kwargs)
File /opt/stack/nova/nova/compute/manager.py, line 1708, in _spawn
LOG.exception(_('Instance failed to spawn'), instance=instance)
File /opt/stack/nova/nova/openstack/common/excutils.py, line 68, in
__exit__
six.reraise(self.type_, self.value, self.tb)
File /opt/stack/nova/nova/compute/manager.py, line 1705, in _spawn
block_device_info)
File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 611, in spawn
admin_password, network_info, block_device_info)
File /opt/stack/nova/nova/virt/vmwareapi/vmops.py, line 223, in spawn
(file_type, is_iso) = self._get_disk_format(image_meta)
File /opt/stack/nova/nova/virt/vmwareapi/vmops.py, line 189, in
_get_disk_format
raise exception.InvalidDiskFormat(disk_format=disk_format)
InvalidDiskFormat: Disk format None is not acceptable
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1296873/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1300788] [NEW] VMware: exceptions when SOAP message has no body
Public bug reported: Minesweeper logs have the following: 2014-03-26 11:37:09.753 CRITICAL nova.virt.vmwareapi.driver [req-3a274ea6-e731-4bbc-a7fc-e2877a57a7cb MultipleCreateTestJSON-692822675 MultipleCreateTestJSON-47510170] In vmwareapi: _call_method (session=52eb4a1e-04de-de0d-5c6a-746a430570a2) 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver Traceback (most recent call last): 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 856, in _call_method 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver return temp_module(*args, **kwargs) 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/vim.py, line 196, in vim_request_handler 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver raise error_util.VimFaultException(fault_list, excep) 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver VimFaultException: Server raised fault: ' 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver SOAP body not found 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver while parsing SOAP envelope 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver at line 1, column 38 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver while parsing HTTP request before method was determined 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver at line 1, column 0' 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver 2014-03-26 11:37:09.754 WARNING nova.virt.vmwareapi.vmops [req-3a274ea6-e731-4bbc-a7fc-e2877a57a7cb MultipleCreateTestJSON-692822675 MultipleCreateTestJSON-47510170] In vmwareapi:vmops:_destroy_instance, got this exception while un-registering the VM: Server raised fault: ' SOAP body not found while parsing SOAP envelope at line 1, column 38 while parsing HTTP request before method was determined at line 1, column 0' There are cases when the suds returns a message with no body. ** Affects: nova Importance: Undecided Assignee: Gary Kotton (garyk) Status: New ** Tags: havana-backport-potential vmware ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Tags added: havana-backport-potential vmware -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1300788 Title: VMware: exceptions when SOAP message has no body Status in OpenStack Compute (Nova): New Bug description: Minesweeper logs have the following: 2014-03-26 11:37:09.753 CRITICAL nova.virt.vmwareapi.driver [req-3a274ea6-e731-4bbc-a7fc-e2877a57a7cb MultipleCreateTestJSON-692822675 MultipleCreateTestJSON-47510170] In vmwareapi: _call_method (session=52eb4a1e-04de-de0d-5c6a-746a430570a2) 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver Traceback (most recent call last): 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 856, in _call_method 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver return temp_module(*args, **kwargs) 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/vim.py, line 196, in vim_request_handler 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver raise error_util.VimFaultException(fault_list, excep) 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver VimFaultException: Server raised fault: ' 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver SOAP body not found 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver while parsing SOAP envelope 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver at line 1, column 38 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver while parsing HTTP request before method was determined 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver at line 1, column 0' 2014-03-26 11:37:09.753 13830 TRACE nova.virt.vmwareapi.driver 2014-03-26 11:37:09.754 WARNING nova.virt.vmwareapi.vmops [req-3a274ea6-e731-4bbc-a7fc-e2877a57a7cb MultipleCreateTestJSON-692822675 MultipleCreateTestJSON-47510170] In vmwareapi:vmops:_destroy_instance, got this exception while un-registering the VM: Server raised fault: ' SOAP body not found while parsing SOAP envelope at line 1, column 38 while parsing HTTP request before method was determined at line 1, column 0' There are cases when the suds returns a message with no body. To manage notifications about this bug go to: https
Re: [openstack-dev] [nova] An analysis of code review in Nova
Regarding the spawn there are a number of patches up for review at the moment - they are all mutually exclusive and hopefully will make the process a lot smoother. https://review.openstack.org/#/q/topic:bp/vmware-spawn-refactor,n,z In addition to this we have a patch up for review with the OSLO integration - https://review.openstack.org/#/c/70175/ (ideally it would be best that this gets in first) Thanks Gary On 3/22/14 8:03 PM, Chris Behrens cbehr...@codestud.com wrote: I'd like to get spawn broken up sooner rather than later, personally. It has additional benefits of being able to do better orchestration of builds from conductor, etc. On Mar 14, 2014, at 3:58 PM, Dan Smith d...@danplanet.com wrote: Just to answer this point, despite the review latency, please don't be tempted to think one big change will get in quicker than a series of little, easy to review, changes. All changes are not equal. A large change often scares me away to easier to review patches. Seems like, for Juno-1, it would be worth cancelling all non-urgent bug fixes, and doing the refactoring we need. I think the aim here should be better (and easier to understand) unit test coverage. Thats a great way to drive good code structure. Review latency will be directly affected by how good the refactoring changes are staged. If they are small, on-topic and easy to validate, they will go quickly. They should be linearized unless there are some places where multiple sequences of changes make sense (i.e. refactoring a single file that results in no changes required to others). As John says, if it's just a big change everything patch, or a ton of smaller ones that don't fit a plan or process, then it will be slow and painful (for everyone). +1 sounds like a good first step is to move to oslo.vmware I'm not sure whether I think that refactoring spawn would be better done first or second. My gut tells me that doing spawn first would mean that we could more easily validate the oslo refactors because (a) spawn is impossible to follow right now and (b) refactoring it to smaller methods should be fairly easy. The tests for spawn are equally hard to follow and refactoring it first would yield a bunch of more unit-y tests that would help us follow the oslo refactoring. However, it sounds like the osloificastion has maybe already started and that refactoring spawn will have to take a backseat to that. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=q5RejnjmrSIFg0K7ua AZbKHVqAKLHnVAB98J%2BszOfhw%3D%0As=1629f4e9008260c5f8ea577da1bdc69388dbe fa3646803244df992a31d94bc96 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=q5RejnjmrSIFg0K7uaAZb KHVqAKLHnVAB98J%2BszOfhw%3D%0As=1629f4e9008260c5f8ea577da1bdc69388dbefa36 46803244df992a31d94bc96 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1294102] [NEW] VMware: get_object_properties may not return any objects
Public bug reported: 2014-03-18 05:32:28.164 CRITICAL nova.virt.vmwareapi.driver [req-a4d0920a-9ea0-4e3d-b1fe-561133e5b799 None None] In vmwareapi: _call_method (session=52325cb1-82c6-440a-e498-328cf8759e8e) 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver Traceback (most recent call last): 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 835, in _call_method 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver return temp_module(*args, **kwargs) 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/vim_util.py, line 170, in get_dynamic_property 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver property_dict = get_dynamic_properties(vim, mobj, type, [property_name]) 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/vim_util.py, line 180, in get_dynamic_properties 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver if obj_content.objects: 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver AttributeError: 'NoneType' object has no attribute 'objects' 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: havana-backport-potential ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = icehouse-rc1 ** Changed in: nova Importance: Undecided = High ** Tags added: ha ** Tags removed: ha ** Tags added: havana-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1294102 Title: VMware: get_object_properties may not return any objects Status in OpenStack Compute (Nova): In Progress Bug description: 2014-03-18 05:32:28.164 CRITICAL nova.virt.vmwareapi.driver [req-a4d0920a-9ea0-4e3d-b1fe-561133e5b799 None None] In vmwareapi: _call_method (session=52325cb1-82c6-440a-e498-328cf8759e8e) 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver Traceback (most recent call last): 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 835, in _call_method 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver return temp_module(*args, **kwargs) 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/vim_util.py, line 170, in get_dynamic_property 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver property_dict = get_dynamic_properties(vim, mobj, type, [property_name]) 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver File /opt/stack/nova/nova/virt/vmwareapi/vim_util.py, line 180, in get_dynamic_properties 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver if obj_content.objects: 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver AttributeError: 'NoneType' object has no attribute 'objects' 2014-03-18 05:32:28.164 TRACE nova.virt.vmwareapi.driver To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1294102/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1293435] [NEW] VMware: rescue with image that is not linked clone leaves rescue vmdk in the instance folder
Public bug reported: A rescue of an image that is not linked clone will leave the rescue image disk in the original VM folder. The disk will not be cleaned up properly. This leads to a number of problems: 1. usage of unnecessary disk space 2. additional rescues for the same VM may fail ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: havana-backport-potential ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = icehouse-rc1 ** Changed in: nova Importance: Undecided = High ** Tags added: havana-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1293435 Title: VMware: rescue with image that is not linked clone leaves rescue vmdk in the instance folder Status in OpenStack Compute (Nova): In Progress Bug description: A rescue of an image that is not linked clone will leave the rescue image disk in the original VM folder. The disk will not be cleaned up properly. This leads to a number of problems: 1. usage of unnecessary disk space 2. additional rescues for the same VM may fail To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1293435/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[openstack-dev] [Nova client] gate-python-novaclient-pypy
Hi,
The client gate seems to be broken with the following error:
2014-03-10
08:19:39.566http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_566
| Running setup.py install for python-mimeparse
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
|
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Found existing installation: setuptools 2.2
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Uninstalling setuptools:
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Successfully uninstalled setuptools
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Running setup.py install for mccabe
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'entry_points'
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| warnings.warn(msg)
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'zip_safe'
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| warnings.warn(msg)
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
|or: -c --help [cmd1 cmd2 ...]
2014-03-10
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
|or: -c --help-commands
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
|or: -c cmd --help
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
|
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| error: option --single-version-externally-managed not recognized
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| Complete output from command
/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/bin/pypy -c
import setuptools,
tokenize;__file__='/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/build/mccabe/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))
install --record /tmp/tmp.l53ekBaPmF/pip-5i1oDp-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/include/site/python2.7:
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'entry_points'
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
|
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| warnings.warn(msg)
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
|
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'zip_safe'
2014-03-10
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
|
2014-03-10
[Yahoo-eng-team] [Bug 1290261] [NEW] Missing translation support
Public bug reported: There are a number of places that do not contain translation support in the virt drivers ** Affects: nova Importance: Low Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Milestone: None = icehouse-rc1 ** Changed in: nova Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1290261 Title: Missing translation support Status in OpenStack Compute (Nova): In Progress Bug description: There are a number of places that do not contain translation support in the virt drivers To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1290261/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] [nova][vmware] Locking: A can of worms
Hi, I have provided a solution for the single node setup that. That is, we make use of the nova lock utilities to provide locking so that that the cached images will not be removed whilst an instance is spawned. I hope that this will unblock the feature an enable us to continue with the FFE. The reasons for this are as follow: 1. The feature can be disable if a user wishes 2. In the case the user wants to make use of multiple compute nodes we can address the issues via configuration variables, that is, each compute node can use a different cache directory on the datastore. Thanks Gary On 3/7/14 11:03 PM, Vui Chiap Lam vuich...@vmware.com wrote: Thanks Matt, good points raised here. I think at minimum we should address the single-node case by @synchronized-ing all access to the image cache data on the datastore, in a way that is fairly easy to reason about. Spawn failures are not desirable but acceptable in edge cases if a subsequent retry on same or different node can succeed. What we need to absolutely avoid is a partially deleted image cache directory rendering future spawns impossible. There are some non-elegant ways to work around the multi-node scenarios if one really has to (e.g. dedicating a different cache location for each node), but i think the multi-node should get addressed at some point too. There is distributing locking provisions in the a vSphere datastore for files in use (you cannot delete a disk used by a running VM, say). The image cache as implemented exists as a collection of files on a datastore, many of which may not be used by any process. Either that picture changes or we need to adopt some other means to achieve distributed locking. Vui - Original Message - | From: Matthew Booth mbo...@redhat.com | To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org | Sent: Friday, March 7, 2014 8:53:26 AM | Subject: [openstack-dev] [nova][vmware] Locking: A can of worms | | We need locking in the VMware driver. There are 2 questions: | | 1. How much locking do we need? | 2. Do we need single-node or multi-node locking? | | I believe these are quite separate issues, so I'm going to try not to | confuse them. I'm going to deal with the first question first. | | In reviewing the image cache ageing patch, I came across a race | condition between cache ageing and spawn(). One example of the race is: | | Cache Ageingspawn() | * Check timestamps | * Delete timestamp | * Check for image cache directory | * Delete directory | * Use image cache directory | | This will cause spawn() to explode. There are various permutations of | this. For example, the following are all possible: | | * A simple failure of spawn() with no additional consequences. | | * Calling volumeops.attach_disk_to_vm() with a vmdk_path that doesn't | exist. It's not 100% clear to me that ReconfigVM_Task will throw an | error in this case, btw, which would probably be bad. | | * Leaving a partially deleted image cache directory which doesn't | contain the base image. This would be really bad. | | The last comes about because recursive directory delete isn't atomic, | and may partially succeed, which is a tricky problem. However, in | discussion, Gary also pointed out that directory moves are not atomic | (see MoveDatastoreFile_Task). This is positively nasty. We already knew | that spawn() races with itself to create an image cache directory, and | we've hit this problem in practise. We haven't fixed the race, but we do | manage it. The management relies on the atomicity of a directory move. | Unfortunately it isn't atomic, which presents the potential problem of | spawn() attempting to use an incomplete image cache directory. We also | have the problem of 2 spawns using a linked clone image racing to create | the same resized copy. | | We could go through all of the above very carefully to assure ourselves | that we've found all the possible failure paths, and that in every case | the problems are manageable and documented. However, I would place a | good bet that the above is far from a complete list, and we would have | to revisit it in its entirety every time we touched any affected code. | And that would be a lot of code. | | We need something to manage concurrent access to resources. In all of | the above cases, if we make the rule that everything which uses an image | cache directory must hold a lock on it whilst using it, all of the above | problems go away. Reasoning about their correctness becomes the | comparatively simple matter of ensuring that the lock is used correctly. | Note that we need locking in both the single and multi node cases, | because even single node is multi-threaded. | | The next question is whether that locking needs to be single node or | multi node. Specifically, do we currently, or do we plan to, allow an | architecture where
[openstack-dev] [Nova] Tox issues on a clean environment
Hi,
Anyone know how I cam solve the error below:
Running setup.py install for jsonpatch
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
option: 'entry_poimts'
warnings.warn(msg)
changing mode of build/scripts-2.7/jsondiff from 664 to 775
changing mode of build/scripts-2.7/jsonpatch from 664 to 775
changing mode of /home/gk-dev/nova/.tox/py27/bin/jsonpatch to 775
changing mode of /home/gk-dev/nova/.tox/py27/bin/jsondiff to 775
Found existing installation: distribute 0.6.24dev-r0
Not uninstalling distribute at /usr/lib/python2.7/dist-packages, outside
environment /home/gk-dev/nova/.tox/py27
Running setup.py install for setuptools
Installing easy_install script to /home/gk-dev/nova/.tox/py27/bin
Installing easy_install-2.7 script to /home/gk-dev/nova/.tox/py27/bin
Running setup.py install for mccabe
Running setup.py install for cffi
Traceback (most recent call last):
File string, line 1, in module
File /home/gk-dev/nova/.tox/py27/build/cffi/setup.py, line 94, in
module
from setuptools import setup, Feature, Extension
ImportError: cannot import name Feature
Complete output from command /home/gk-dev/nova/.tox/py27/bin/python2.7 -c
import
setuptools;__file__='/home/gk-dev/nova/.tox/py27/build/cffi/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'), __file__, 'exec')) install --record
/tmp/pip-2sWKRK-record/install-record.txt --single-version-externally-managed
--install-headers /home/gk-dev/nova/.tox/py27/include/site/python2.7:
Traceback (most recent call last):
File string, line 1, in module
File /home/gk-dev/nova/.tox/py27/build/cffi/setup.py, line 94, in module
from setuptools import setup, Feature, Extension
ImportError: cannot import name Feature
Cleaning up...
Command /home/gk-dev/nova/.tox/py27/bin/python2.7 -c import
setuptools;__file__='/home/gk-dev/nova/.tox/py27/build/cffi/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'), __file__, 'exec')) install --record
/tmp/pip-2sWKRK-record/install-record.txt --single-version-externally-managed
--install-headers /home/gk-dev/nova/.tox/py27/include/site/python2.7 failed
with error code 1 in /home/gk-dev/nova/.tox/py27/build/cffi
Traceback (most recent call last):
File .tox/py27/bin/pip, line 9, in module
load_entry_point('pip==1.5.4', 'console_scripts', 'pip')()
File
/home/gk-dev/nova/.tox/py27/local/lib/python2.7/site-packages/pip/__init__.py,
line 148, in main
parser.print_help()
File
/home/gk-dev/nova/.tox/py27/local/lib/python2.7/site-packages/pip/basecommand.py,
line 169, in main
log_file_fp.write(text)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 72:
ordinal not in range(128)
ERROR: could not install deps [-r/home/gk-dev/nova/requirements.txt,
-r/home/gk-dev/nova/test-requirements.txt]
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] FFE Request: ISO support for the VMware driver
Hi, Unfortunately we did not get the ISO support approved by the deadline. If possible can we please get the FFE. The feature is completed and has been tested extensively internally. The feature is very low risk and has huge value for users. In short a user is able to upload a iso to glance then boot from that iso. BP: https://blueprints.launchpad.net/openstack/?searchtext=vmware-iso-boot Code: https://review.openstack.org/#/c/63084/ and https://review.openstack.org/#/c/77965/ Sponsors: John Garbutt and Nikola Dipanov One of the things that we are planning on improving in Juno is the way that the Vmops code is arranged and organized. We will soon be posting a wiki for ideas to be discussed. That will enable use to make additions like this a lot simpler in the future. But sadly that is not part of the scope at the moment. Thanks in advance Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1287844] [NEW] VMware: raise an error for invalid disk_format
Public bug reported: We need to raise an exception for an disk_format that is not supported ** Affects: nova Importance: Undecided Assignee: Gary Kotton (garyk) Status: New ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1287844 Title: VMware: raise an error for invalid disk_format Status in OpenStack Compute (Nova): New Bug description: We need to raise an exception for an disk_format that is not supported To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1287844/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] What's the name of IRC channel for novaclient?
Hi, This is the same channel as nova – that is #openstack-nova Thanks Gary From: wu jiang win...@gmail.commailto:win...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, March 3, 2014 10:11 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] What's the name of IRC channel for novaclient? Hi all, I want to know what's the name of IRC channel for novaclient? I want to ask something about one BP. And I don't know whether it exists or not, I don't find it in wiki[1]. If you know the information, please tell me. Thanks very much. Best Wishes, wingwj --- [1]. https://wiki.openstack.org/wiki/IRChttps://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wiki/IRCk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=rSQ7EiJDzvK1G5N5PJ%2F7c%2F%2BRab4oueu7AYnZLnM6rtI%3D%0As=c2fa94b9e6cbf44dc5ba85bd824cad3a4704928d51775f57782da3ef7bb8bc9e ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Instances created using nova compute aren't visible in ESXi
Hi, The instance should be visible from the VC client. The name of the instance should be the OpenStack UUID. Thanks Gary From: Upendra Sahu upendrasah...@gmail.commailto:upendrasah...@gmail.com Date: Tuesday, March 4, 2014 6:08 AM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Instances created using nova compute aren't visible in ESXi I have a ESXi hypervisor (Host1) on which I have installed a VM1 based on Ubuntu 12.4 LTS server. Now I installed single Node Openstack in this VM1. Host1 when viewed using vSphere Client has one vm VM1. As the single node openstack is installed in VM1, created one instance (ins1) in VM1. This ins1 is based on Cirros where the image used is cirros-0.3.0-x86_64-disk.img. Now the openstack VM1 has a ins1 which can be logged into from VM1. here is my query. Since there has been a instance ins1 created, as per my understand of openstack this ins1 should be visible from the vSphere Client. i.e now vSphere Client should show one VM i.e VM1 on which Openstack is installed and ins1 the instance VM created through openstack. Is that understanding wrong. But when I viewed Host1 through Vsphere client, only one VM i.e VM1 alone is visible not the ins1. Is that anything I am doing wrong in the setup. Thanks, Upendra ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] image caching
Hi, At the moment there is no 'pre fetching'. It is a nice idea. Thanks Gary From: Craig Jellick cjell...@godaddy.commailto:cjell...@godaddy.com Date: Wednesday, February 26, 2014 5:25 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] image caching Hi all, Currently, when we deploy a new image, the first VM deployment with that new image to any particular compute node takes longer than normal because the image is not yet cached on the node. Is there a mechanism for pre-caching/pushing new images to compute nodes? I'm thinking we could just force a VM deployment to each node, but wanted to check if there was a better way. /Craig J ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Nova][VMWare] VMware VM snapshot
Hi, This is something that would be nice to add as an extension. At the moment it is not part of our near term development plans. It would be nice to engage the community to discuss and see how this can be exposed correctly using the Nova API's. It may be something worthwhile discussing at the up and coming summit. Thanks Gary From: Qin Zhao chaoc...@gmail.commailto:chaoc...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, February 25, 2014 2:05 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][VMWare] VMware VM snapshot What I mean is the snapshot of vsphere, which is describe in this page -- http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc_50%2FGUID-CA948C69-7F58-4519-AEB1-739545EA94E5.html It is very useful, if the user plan to perform some risky operations in a VM. I am not quite sure if we can model it in Nova, and let the user to create snapshot chain via Nova api. Has it been discussed in design session or mail group? Anybody know that? On Tue, Feb 25, 2014 at 6:40 PM, John Garbutt j...@johngarbutt.commailto:j...@johngarbutt.com wrote: On 25 February 2014 09:27, Qin Zhao chaoc...@gmail.commailto:chaoc...@gmail.com wrote: Hi, One simple question about VCenter driver. I feel the VM snapshot function of VCenter is very useful and is loved by VCenter users. Does anybody think about to let VCenter driver support it? It depends if that can be modelled well with the current Nova/Cinder/Glance primitives. If you do boot from volume, and you see the volume snapshots, and they behave how cinder expects, and you can model that snapshot as an image in glance that you can boot new instances from, then maybe it would work just fine. But we need to take care not to bend the current API primitives too far out of place. I remember there being some talk about this at the last summit. How did that go? John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=HIkeI2LxCwLrVL13ha6fGUuaB%2Fd1GMZdBl5zsu8jMAE%3D%0As=53c780e5a48bdf84774db49876ef2ef822a63a8b8d20e23190bb42273a40c1d0 -- Qin Zhao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt] Is there anything blocking the libvirt driver from implementing the host_maintenance_mode API?
Hi, Plesae note that regarding the Vmware driver the maintenance mode only works with the ESX driver and not the VC driver. For the VC driver there is a patch in review - https://review.openstack.org/#/c/72143/ Thanks Gary From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Sunday, February 23, 2014 3:14 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][libvirt] Is there anything blocking the libvirt driver from implementing the host_maintenance_mode API? So there is no need to implement libvirt driver for the host_maintenance_mode API as host_maintenance_mode is mainly for VMWare and XenServer, also we can use evacuate and os-services/disable for libvirt host maintain, right? Thanks, Jay 2014-02-23 5:22 GMT+08:00 Bruce Montague bruce_monta...@symantec.commailto:bruce_monta...@symantec.com: On Fri Feb 21 21:14:56 UTC 2014 Joe Gordon joe.gordon0 at gmail.comhttps://urldefense.proofpoint.com/v1/url?u=http://gmail.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=aa22811e8ac28f6361f9a621b6fddd174c06e474b0585238e1ef7d294f5fe501 wrote: On Thu, Feb 20, 2014 at 9:38 AM, Matt Riedemann mriedem at linux.vnet.ibm.comhttps://urldefense.proofpoint.com/v1/url?u=http://linux.vnet.ibm.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=d0e9aac9517d6900c84731a432cf9180404b53911f3b683c6d41860465926d44 wrote: On 2/19/2014 4:05 PM, Matt Riedemann wrote: The os-hosts OS API extension [1] showed up before I was working on the project and I see that only the VMware and XenAPI drivers implement it, but was wondering why the libvirt driver doesn't - either no one wants it, or there is some technical reason behind not implementing it for that driver? If I remember correctly maintenance mode is a special thing in Xen. Maintenance mode is pretty heavily used with VMware vCenter. When an environment supports universal live migration of all VMs, it makes sense to migrate all VMs running on a physical machine off of that machine before bringing it down for maintenance, such as upgrading the hardware. Provides some classes of end-users with a more 24x7x365 experience. [1] http://docs.openstack.org/api/openstack-compute/2/content/PUT_os-hosts-v2_updateHost_v2__tenant_id__os-hosts__host_name__ext-os-hosts.htmlhttps://urldefense.proofpoint.com/v1/url?u=http://docs.openstack.org/api/openstack-compute/2/content/PUT_os-hosts-v2_updateHost_v2__tenant_id__os-hosts__host_name__ext-os-hosts.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=8120001d41ddc39e4e5edf7721c4f47ea324a388dfb95cad944a140fa8b257de By the way, am I missing something when I think that this extension is already covered if you're: 1. Looking to get the node out of the scheduling loop, you can just disable it with os-services/disable? 2. Looking to evacuate instances off a failed host (or one that's in maintenance mode), just use the evacuate server action. I don't think your missing anything. -- Thanks, Matt Riedemann -bruce ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=7d513d1b8c61f68ad14e8f896d90dab47a2eb82e320c9a4f6542a0f677b26349 -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Fixed recent gate issues
On 2/19/14 10:31 PM, Alan Pevec ape...@gmail.com wrote: Yeah it's pip weirdness where things falls apart because of version cap. It's basically installing bin/swift from 1.9 when it sees the version requirement but it leaves everything in python-swiftclient namespace from master. So I've actually been looking at this since late yesterday the conclusion we've reached is to just skip the exercises on grizzly. Removing the version cap isn't going to be simple on grizzly because there global requirements wasn't enforced back in grizzly. We'd have to change the requirement for both glance, horizon, and swift and being ~3 weeks away from eol for grizzly I don't think we should mess with that. This failure is only an issue with cli swiftclient on grizzly (and one swift functional test) which as it sits now is just the devstack exercises on grenade. So if we just don't run those exercises on the grizzly side of a grenade run there shouldn't be an issue. I've got 2 patches to do this here: https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/% 23/c/74419/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu% 2BfDtysg45MkPhCZFxPEq8%3D%0Am=PlTk6Hx5SymtM%2BlXLUIqyNGMz3z9JFKMcy7XJRvm k6s%3D%0As=591c1b105d86204158b21bd572a7f589f8ad032359282b84da9bc2b649d1a 3f9 https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/% 23/c/74451/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu% 2BfDtysg45MkPhCZFxPEq8%3D%0Am=PlTk6Hx5SymtM%2BlXLUIqyNGMz3z9JFKMcy7XJRvm k6s%3D%0As=d531e1933102045d5b77138fc42bd8e68ddc3d5b25dd281d94bfb0e9a22b9 a64 Looks like only the latter is needed, devstack-gate core please approve it to unblock stable/havana. It looks like this does not solve the issue. I wonder if we need the same change for stable/havana. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=PlTk6Hx5SymtM%2BlXLUI qyNGMz3z9JFKMcy7XJRvmk6s%3D%0As=8a9c304e78b852d9eaa9063697282ccd38a303300 54aebe635797a8bce793bbe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1278677] Re: VMware driver should cache morefs
Hi, This has already been implemented. Please see - https://review.openstack.org/#/c/60259/ Thanks Gary ** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1278677 Title: VMware driver should cache morefs Status in OpenStack Compute (Nova): Invalid Bug description: The VMware needs to cache morefs as much as possible throughout the codebase. This will avoid extra VC queries. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1278677/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] call for help with nova bug management
I will help out. Thanks Gary From: Tracy Jones tjo...@vmware.commailto:tjo...@vmware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, February 18, 2014 9:48 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] call for help with nova bug management So i have been rather underwhelmed in the enthusiastic response to help out :-) So far only wendar and johnthetubaguy have signed up. I was hoping for at least 3-5 people to help with the initial triage. Please sign up this week if you can help and i’ll schedule the meetings starting next week On Feb 14, 2014, at 2:16 PM, Tracy Jones tjo...@vmware.commailto:tjo...@vmware.com wrote: Hi Folks - I’ve offered to help Russell out with managing nova’s bug queue. The charter of this is as follows 1. Triage the 125 new bugs 2. Ensure that the critical bugs are assigned properly and are making progress Once this part is done we will shift our focus to things like * Bugs in incomplete state with no update by the reporter - they should be set to invalid if they requester does not update them in a timely manner. * Bugs which say they are in progress but no progress is being made. If a bug is assigned and simply being ignored we should remove the assignment so others can grab it and work on it The bug triage policy is defined here https://wiki.openstack.org/wiki/BugTriagehttps://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wiki/BugTriagek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=iM9c3M7WWm7TTEGxg7DO4spZaxt3S5NgP6GRop8sfEE%3D%0As=08b0cf24ea8e2ea9f5e9f40e65000c7571d8f39d2478752bbd05798db182f36d What can you do??? First I need a group of folks to volunteer to help with 1 and 2. I will start a weekly IRC meeting where we work on the triage and check progress on critical (or even high) prio bugs. If you can help out, please sign up at the end of this etherpad and include your timezone. Once I have a few people to help i will schedule the meeting at a time that I hope is convenient for all. https://etherpad.openstack.org/p/nova-bug-managementhttps://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/p/nova-bug-managementk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=iM9c3M7WWm7TTEGxg7DO4spZaxt3S5NgP6GRop8sfEE%3D%0As=200cb74eb4c0ca7611cb39ee5cc35cdd40bcf2bb8e50813b2f4a6c469980832c Thanks in advance for your help. Tracy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [infra] reverify/recheck
Hi, It seems that the command 'reverify bug number' is not working. Anyone else experienced this lately. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] reverify/recheck
Hi, The reverify no bug was removed. But reverify bug # used to work. That no longer does. With the constant gate failures how can we ensure that a approved patch does a retry? Thanks Gary From: Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, February 17, 2014 2:53 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [infra] reverify/recheck Hi Gary, That's normal, this command has been removed since Dec'13, see http://lists.openstack.org/pipermail/openstack-dev/2013-December/021649.htmlhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pipermail/openstack-dev/2013-December/021649.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=d9cbcbde99b7c88c15ca138499de8f36edd4247ce351e41b241d675b09b79956 -Sylvain 2014-02-17 13:00 GMT+01:00 Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com: Hi, It seems that the command 'reverify bug number' is not working. Anyone else experienced this lately. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=21e7f4ebc24f0a13780981720f9332111dd603f3c0661229dc90d82bfb5c3122 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] reverify/recheck
Thanks! That makes sense. Just odd how a -1 was received. On 2/17/14 3:15 PM, Akihiro Motoki mot...@da.jp.nec.com wrote: Hi Gary, According to zuul layout.yaml [1], reverify bug # should still work but it seems to work only when verified score from jenkins is -2. https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack-in fra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml%23 L25k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg4 5MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A s=8fc4d7e6970936977dc85989e4e7e9429afb15f5091a768efa4ce236417d9c9b Note that core team can trigger gate jobs by re-approving the patch. Thanks, Akihiro (2014/02/17 22:03), Gary Kotton wrote: Hi, The reverify no bug was removed. But reverify bug # used to work. That no longer does. With the constant gate failures how can we ensure that a approved patch does a retry? Thanks Gary From: Sylvain Bauza sylvain.ba...@gmail.com mailto:sylvain.ba...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Monday, February 17, 2014 2:53 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [infra] reverify/recheck Hi Gary, That's normal, this command has been removed since Dec'13, see https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pip ermail/openstack-dev/2013-December/021649.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw %3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2Fy HMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0As=826274ca8ad9562b557322274a cdacd97482338456820af8c330b76ea7639838 https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pi permail/openstack-dev/2013-December/021649.htmlk=oIvRg1%2BdGAgOoM1BIlLLq w%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75 uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=d9cbcbde99b7c88c15ca138 499de8f36edd4247ce351e41b241d675b09b79956 -Sylvain 2014-02-17 13:00 GMT+01:00 Gary Kotton gkot...@vmware.com mailto:gkot...@vmware.com: Hi, It seems that the command 'reverify bug number' is not working. Anyone else experienced this lately. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59x Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0As=1a2a59024e18b786b5c2c13535b7f3d050363 ff628dc96b8561e12489d30c0bd https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cg i-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75uRFa7dyD%2F bgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=21e7f4ebc24f0a13780981720f9332111d d603f3c0661229dc90d82bfb5c3122 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59x Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0As=1a2a59024e18b786b5c2c13535b7f3d050363 ff628dc96b8561e12489d30c0bd ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59xIcg 6NKX1O2wlkkHHd42bYQim0k0%3D%0As=1a2a59024e18b786b5c2c13535b7f3d050363ff62 8dc96b8561e12489d30c0bd ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1280758] [NEW] VMware: some unit tests take longer than a second
Public bug reported:
Cleaning up...
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpuu5L9O
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpVXhq0L
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpjoXLG2
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpjYDRp7
Ran 229 (-9) tests in 1.754s (-0.147s)
PASSED (id=32)
Slowest Tests
Test id
Runtime (s)
---
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_login_retries
1.021
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVMTestCase.test_login_retries
1.011
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIConfTestCase.test_configure_without_wsdl_loc_override
0.089
nova.tests.virt.vmwareapi.test_configdrive.ConfigDriveTestCase.test_create_vm_with_config_drive
0.082
nova.tests.virt.vmwareapi.test_configdrive.ConfigDriveTestCase.test_create_vm_with_config_drive_verify_method_invocation
0.067
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIHostTestCase.test_host_startup
0.059
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_cache_dir_disk_created
0.050
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_finish_migration_power_off
0.033
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_detach_vmdk_disk_from_vm
0.029
nova.tests.virt.vmwareapi.test_driver_api.VMwareAPIVCDriverTestCase.test_destroy
0.029
** Affects: nova
Importance: Medium
Assignee: Gary Kotton (garyk)
Status: In Progress
** Tags: vmware
** Changed in: nova
Importance: Undecided = Medium
** Changed in: nova
Assignee: (unassigned) = Gary Kotton (garyk)
** Changed in: nova
Milestone: None = icehouse-3
** Changed in: nova
Status: New = In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1280758
Title:
VMware: some unit tests take longer than a second
Status in OpenStack Compute (Nova):
In Progress
Bug description:
Cleaning up...
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpuu5L9O
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpVXhq0L
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpjoXLG2
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpjYDRp7
Ran 229 (-9) tests in 1.754s (-0.147s)
PASSED (id=32)
Slowest Tests
Test id
Runtime (s
[Yahoo-eng-team] [Bug 1280783] [NEW] Unique match exception does not print the security group
Public bug reported: 2014-02-16 05:18:05.961 TRACE nova raise exception.NoUniqueMatch(msg) 2014-02-16 05:18:05.961 TRACE nova NoUniqueMatch: (uMultiple security groups found matching '%s'. Use an ID to be more specific., 'sec_group') 2014-02-16 05:18:05.961 TRACE nova n-cpu failed to start ** Affects: nova Importance: Undecided Status: Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1280783 Title: Unique match exception does not print the security group Status in OpenStack Compute (Nova): Invalid Bug description: 2014-02-16 05:18:05.961 TRACE nova raise exception.NoUniqueMatch(msg) 2014-02-16 05:18:05.961 TRACE nova NoUniqueMatch: (uMultiple security groups found matching '%s'. Use an ID to be more specific., 'sec_group') 2014-02-16 05:18:05.961 TRACE nova n-cpu failed to start To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1280783/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1280783] Re: Unique match exception does not print the security group
This code was fixed in https://github.com/openstack/nova/commit/9b6b874b23dab5ae6ccecae18c5d5664c4951d80 ** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1280783 Title: Unique match exception does not print the security group Status in OpenStack Compute (Nova): Invalid Bug description: 2014-02-16 05:18:05.961 TRACE nova raise exception.NoUniqueMatch(msg) 2014-02-16 05:18:05.961 TRACE nova NoUniqueMatch: (uMultiple security groups found matching '%s'. Use an ID to be more specific., 'sec_group') 2014-02-16 05:18:05.961 TRACE nova n-cpu failed to start To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1280783/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems
Hi, We are currently looking into that. Thanks Gary From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 13, 2014 11:14 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems Thanks Gary. What about live migration with VCDriver, currently I cannot do live migration in the condition of between ESX servers in one cluster. 2014-02-13 16:47 GMT+08:00 Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com: Hi, The commit https://github.com/openstack/nova/commit/c4bf32c03283cbedade9ab8ca99e5b13b9b86ccbhttps://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/commit/c4bf32c03283cbedade9ab8ca99e5b13b9b86ccbk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=lzrbNoejQXG1NI2jpS6g%2FYJanvcIezST4Uenp6Sd5BI%3D%0As=1a39cfb2c41b8ce978956de28a2773a98b75bcfe4c0f135905dc6aa3257b9570 added a warning that the ESX driver is not tested. My understanding is that there are a number of people using the ESX driver so it should not be deprecated. In order to get the warning removed we will need to have CI on the driver. As far as I know there is no official decision to deprecate it. Thanks Gary From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 13, 2014 4:00 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems Greetings, I was now doing some integration with VMWare VCDriver and have some questions during the integration work. 1) In Hong Kong Summit, it was mentioned that ESXDriver will be dropped, so do we have any plan when to drop this driver? 2) There are many good features in VMWare was not supportted by VCDriver, such as live migration, cold migration and resize within one vSphere cluster, also we cannot get individual ESX Server details via VCDriver. Do we have some planning to make those features worked? -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=lzrbNoejQXG1NI2jpS6g%2FYJanvcIezST4Uenp6Sd5BI%3D%0As=b1d6c73107a271d9b3e2c6948bb4bc32185a964d0af83eb60a510d180a4d75f6 -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems
Hi, The commit https://github.com/openstack/nova/commit/c4bf32c03283cbedade9ab8ca99e5b13b9b86ccb added a warning that the ESX driver is not tested. My understanding is that there are a number of people using the ESX driver so it should not be deprecated. In order to get the warning removed we will need to have CI on the driver. As far as I know there is no official decision to deprecate it. Thanks Gary From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 13, 2014 4:00 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems Greetings, I was now doing some integration with VMWare VCDriver and have some questions during the integration work. 1) In Hong Kong Summit, it was mentioned that ESXDriver will be dropped, so do we have any plan when to drop this driver? 2) There are many good features in VMWare was not supportted by VCDriver, such as live migration, cold migration and resize within one vSphere cluster, also we cannot get individual ESX Server details via VCDriver. Do we have some planning to make those features worked? -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Dnsmasq process not running
Hi, Can you please check that the dnsmasq has the correct permissions? It will need to read/write to the hosts files. If you look in the system log file you may see errors related to this. Thanks gary From: Vikash Kumar vikash.ku...@oneconvergence.commailto:vikash.ku...@oneconvergence.com Date: Thursday, February 13, 2014 4:18 PM To: Openstack Milis openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Dnsmasq process not running Hi all, I have installed openstack grizzly. My VM's were not getting IP. I checked my netork node and found that dnsmasq process is not running. Tried restarting quantum-dhcp-agent but none of the time dnsmasq process came up. How can I solve this problem ? Thanks ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Yahoo-eng-team] [Bug 1279820] [NEW] libvirt: some tests taking longer than 2 seconds
Public bug reported:
py27 develop-inst-nodeps: /home/gkotton/nova
py27 runtests: commands[0] | python -m nova.openstack.common.lockutils python
setup.py test --slowest --testr-args=nova.tests.virt.libvirt
[pbr] Excluding argparse: Python 2.6 only dependency
running test
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmp1dQ_3A
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpSmMObk
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpqnRKjm
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpMKqiiM
Ran 572 tests in 13.283s (-0.814s)
PASSED (id=358)
Slowest Tests
Test id
Runtime (s)
--
---
nova.tests.virt.libvirt.test_libvirt.LibvirtConnTestCase.test_pre_live_migration_plug_vifs_retry_works
2.080
nova.tests.virt.libvirt.test_libvirt.LibvirtConnTestCase.test_pre_live_migration_plug_vifs_retry_fails
2.079
nova.tests.virt.libvirt.test_libvirt_volume.LibvirtVolumeTestCase.test_libvirt_kvm_iser_volume_with_multipath
2.011
nova.tests.virt.libvirt.test_libvirt_volume.LibvirtVolumeTestCase.test_libvirt_kvm_iser_volume_with_multipath_getmpdev
2.010
nova.tests.virt.libvirt.test_libvirt.HostStateTestCase.test_update_status
1.024
nova.tests.virt.libvirt.test_dmcrypt.LibvirtDmcryptTestCase.test_create_volume
1.019
nova.tests.virt.libvirt.test_dmcrypt.LibvirtDmcryptTestCase.test_delete_volume
1.016
nova.tests.virt.libvirt.test_libvirt.CacheConcurrencyTestCase.test_same_fname_concurrency
0.886
nova.tests.virt.libvirt.test_libvirt.LibvirtConnTestCase.test_power_on
0.795
nova.tests.virt.libvirt.test_libvirt.LibvirtConnTestCase.test_hard_reboot
0.643
py33 create: /home/gkotton/nova/.tox/py33
ERROR: InterpreterNotFound: python3.3
** Affects: nova
Importance: Medium
Assignee: Gary Kotton (garyk)
Status: New
** Tags: libvirt
** Changed in: nova
Importance: Undecided = Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1279820
Title:
libvirt: some tests taking longer than 2 seconds
Status in OpenStack Compute (Nova):
New
Bug description:
py27 develop-inst-nodeps: /home/gkotton/nova
py27 runtests: commands[0] | python -m nova.openstack.common.lockutils python
setup.py test --slowest --testr-args=nova.tests.virt.libvirt
[pbr] Excluding argparse: Python 2.6 only dependency
running test
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmp1dQ_3A
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpSmMObk
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpqnRKjm
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpMKqiiM
Ran 572 tests in 13.283s
[Yahoo-eng-team] [Bug 1279317] [NEW] xen: agent tests take longer than 15 secs
Public bug reported:
gkotton@ubuntu:~/nova$ tox nova.tests.virt.xenapi.test_xenapi
py26 create: /home/gkotton/nova/.tox/py26
ERROR: InterpreterNotFound: python2.6
py27 develop-inst-nodeps: /home/gkotton/nova
py27 runtests: commands[0] | python -m nova.openstack.common.lockutils python
setup.py test --slowest --testr-args=nova.tests.virt.xenapi.test_xenapi
[pbr] Excluding argparse: Python 2.6 only dependency
running test
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmp349WwU
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpccaidD
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpMvMcYb
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpzJ2QHG
Ran 201 (+199) tests in 16.446s (+0.396s)
PASSED (id=350)
Slowest Tests
Test id
Runtime (s)
---
---
nova.tests.virt.xenapi.test_xenapi.XenAPIVMTestCase.test_spawn_agent_upgrade_fails_silently
16.223
nova.tests.virt.xenapi.test_xenapi.XenAPIVMTestCase.test_spawn_fails_agent_not_implemented
16.222
nova.tests.virt.xenapi.test_xenapi.XenAPIVMTestCase.test_spawn_fails_with_agent_bad_return
16.034
nova.tests.virt.xenapi.test_xenapi.XenAPIAggregateTestCase.test_add_aggregate_host_raise_err
1.116
nova.tests.virt.xenapi.test_xenapi.XenAPIVMTestCase.test_maintenance_mode
0.297
nova.tests.virt.xenapi.test_xenapi.XenAPIMigrateInstance.test_migrate_disk_and_power_off
0.277
nova.tests.virt.xenapi.test_xenapi.XenAPIVMTestCase.test_spawn_vlanmanager
0.195
nova.tests.virt.xenapi.test_xenapi.XenAPIAggregateTestCase.test_remote_master_non_empty_pool
0.179
nova.tests.virt.xenapi.test_xenapi.XenAPIMigrateInstance.test_migrate_disk_and_power_off_with_zero_gb_old_and_new_works
0.179
nova.tests.virt.xenapi.test_xenapi.XenAPIDom0IptablesFirewallTestCase.test_static_filters
0.171
py33 create: /home/gkotton/nova/.tox/py33
ERROR: InterpreterNotFound: python3.3
** Affects: nova
Importance: Undecided
Status: New
** Tags: xenserver
** Tags added: xenserver
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1279317
Title:
xen: agent tests take longer than 15 secs
Status in OpenStack Compute (Nova):
New
Bug description:
gkotton@ubuntu:~/nova$ tox nova.tests.virt.xenapi.test_xenapi
py26 create: /home/gkotton/nova/.tox/py26
ERROR: InterpreterNotFound: python2.6
py27 develop-inst-nodeps: /home/gkotton/nova
py27 runtests: commands[0] | python -m nova.openstack.common.lockutils python
setup.py test --slowest --testr-args=nova.tests.virt.xenapi.test_xenapi
[pbr] Excluding argparse: Python 2.6 only dependency
running test
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmp349WwU
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmpccaidD
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core
+1 On 2/11/14 1:28 AM, Mark McClain mmccl...@yahoo-inc.com wrote: All- I¹d like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=KKs5yVeNC6c7WnUVDuIoU h%2BlWzSzcE1BVaTK%2B71PUM0%3D%0As=b38d5081ce0f288403c87ba38281d93cd1796c9 3f5482ded0916ee3b26e54774 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week
Hi, I saw that one of the days there will be talk about Gantt. Would it be possible that people not at the local meet up can join this discussion? Thanks Gary From: Dugger, Donald D donald.d.dug...@intel.commailto:donald.d.dug...@intel.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, February 10, 2014 6:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week Let’s cancel the meeting this week, some of us (me for sure) will be tied up at the Icehouse mid-cycle meetup. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Gate broken
Thanks for fixing this. From: Qiu Yu unic...@gmail.commailto:unic...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Saturday, February 8, 2014 9:44 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Gate broken On Sat, Feb 8, 2014 at 3:29 PM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, Anyone aware of: It is caused the new boto 2.25 release. Joe Gordon filed a new bug on this[1], and I just submitted a patch [2] to fix. [1] https://bugs.launchpad.net/nova/+bug/1277790https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova/%2Bbug/1277790k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0As=fd96e0f368b4d139e35c6b7a37c7234dbcb580e81a49fd4fc2b5c5bc95535e0d [2] https://review.openstack.org/#/c/72066/https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/72066/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0As=4eaee74f7d34704dd0e64d6ecbb345ea8f51e1e02cf2532d191d3145d84c1416 Thanks, -- Qiu Yu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Gate broken
Hi,
Anyone aware of:
2014-02-08
06:49:42.022http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_022
| ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --load-list
/tmp/tmp.aaa9SCw11a/tmpuyhFPj
2014-02-08
06:49:42.022http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_022
| ==
2014-02-08
06:49:42.022http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_022
| FAIL: nova.tests.test_objectstore.S3APITestCase.test_unknown_bucket
2014-02-08
06:49:42.023http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_023
| tags: worker-0
2014-02-08
06:49:42.023http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_023
| --
2014-02-08
06:49:42.023http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_023
| Empty attachments:
2014-02-08
06:49:42.024http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_024
| stderr
2014-02-08
06:49:42.024http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_024
| stdout
2014-02-08
06:49:42.024http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_024
|
2014-02-08
06:49:42.025http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_025
| pythonlogging:'': {{{
2014-02-08
06:49:42.025http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_025
| INFO [nova.wsgi] S3 Objectstore listening on 127.0.0.1:53278
2014-02-08
06:49:42.025http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_025
| INFO [nova.S3 Objectstore.wsgi.server] (29932) wsgi starting up on
http://127.0.0.1:53278/
2014-02-08
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
| INFO [nova.S3 Objectstore.wsgi.server] 127.0.0.1 HEAD /falalala/ HTTP/1.1
status: 200 len: 115 time: 0.0010102
2014-02-08
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
| INFO [nova.wsgi] Stopping WSGI server.
2014-02-08
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
| }}}
2014-02-08
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
|
2014-02-08
06:49:42.027http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_027
| Traceback (most recent call last):
2014-02-08
06:49:42.027http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_027
| File nova/tests/test_objectstore.py, line 133, in test_unknown_bucket
2014-02-08
06:49:42.027http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_027
| bucket_name)
2014-02-08
06:49:42.028http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_028
| File
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py,
line 393, in assertRaises
2014-02-08
06:49:42.028http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_028
| self.assertThat(our_callable, matcher)
2014-02-08
06:49:42.028http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_028
| File
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py,
line 406, in assertThat
2014-02-08
06:49:42.029http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_029
| raise mismatch_error
2014-02-08
06:49:42.029http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_029
| MismatchError: bound method S3Connection.get_bucket of
S3Connection:127.0.0.1 returned Bucket: falalala
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
