[openstack-dev] [nova] FFE Request - VMware better display names
Hi, I would like to request a FFE for the following BP https://blueprints.launchpad.net/nova/+spec/vmware-better-display-names The code is self contained within the Vmware driver. It enables an vCenter admin to have better visibility of the OpenStack deployment. This is super useful for troubleshooting. The BP has two patches: 1. Places instances in folders instead of the root folder - https://review.openstack.org/#/c/165060/. There is a matching Cinder patch (https://review.openstack.org/#/c/193095) 2. Use the instance name as part of the name of the backend - https://review.openstack.org/#/c/166608 The code is backwards compatible. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.
The gate is under heavy load at the moment. Maybe in a day or two it will get back to usual… From: Tang Chen tangc...@cn.fujitsu.commailto:tangc...@cn.fujitsu.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 22, 2015 at 11:57 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system. Hi Abhishek, On 07/22/2015 03:56 PM, Abhishek Shrivastava wrote: Hi Tang, Reboot your master vm and then try the same. Also after restarting check the status of zuul and zuul-merger. I found the problem. zuul could not fetch repo because of the proxy.. And as a result, merge failed. So the job was not run. Now it is OK. :) Thanks. :) On Wed, Jul 22, 2015 at 12:14 PM, Tang Chen tangc...@cn.fujitsu.commailto:tangc...@cn.fujitsu.com wrote: On 07/22/2015 12:49 PM, Tang Chen wrote: Hi all, When I send a patch to gerrit, my zuul is notified, but jenkins jobs are not run. My CI always reports the following error: Merge Failed.This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. I think, because the patch cannot be merged, the jobs are not run. Referring to https://www.mediawiki.org/wiki/Gerrit/Advanced_usagehttps://urldefense.proofpoint.com/v2/url?u=https-3A__www.mediawiki.org_wiki_Gerrit_Advanced-5Fusaged=BQMCAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=xPjZxaKbI6A4_QChVH5yd1mZH5dpUhZpBpBgzv53YxEs=uPutfRk7Ex5dkTVYP7ZbGR11euc8pSs1G0txZICkGWMe=, I did update my master branch and make sure it is up-to-date. But it doesn't work. And other CIs from other companies didn't report this error. process_event_queue() |-- pipeline.manager.addChange() |-- report Unable to find change queue for change Change 0x7fa7ef8b6250 204446,1 in project openstack-dev/sandbox 204446 is my patch number. Anyone knows why is that ? Thanks. And also, when zuul tries to get the patch from gerrit, it executes: gerrit query --format json --all-approvals --comments --commit-message --current-patch-set --dependencies --files --patch-sets --submit-records 204337 When I try to execute it myself, it reports:Permission denied (publickey). I updated my ssh key, and uploaded the new public key to gerrit, but it doesn't work. Does anyone have any idea what's going on here ? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- [https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ] Thanks Regards, Abhishek Cloudbyte Inc.https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cloudbyte.comd=BQMCAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=xPjZxaKbI6A4_QChVH5yd1mZH5dpUhZpBpBgzv53YxEs=KOIy9LLJBcxT-zC6XENVPpTuvQS7kAtxH169pLrA-sMe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] ceph gate unstable
Hi, It seems like the gating is failing with cep tests: http://logs.openstack.org/29/199129/6/check/gate-tempest-dsvm-full-ceph/bfe423d/logs/testr_results.html.gz Is anyone looking into this? Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1475837] [NEW] RBAC network support breaks decomposed plugins
)
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
line 435, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 500 != 201
** Affects: neutron
Importance: Critical
Assignee: Gary Kotton (garyk)
Status: In Progress
** Changed in: neutron
Importance: Undecided = Critical
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1475837
Title:
RBAC network support breaks decomposed plugins
Status in neutron:
In Progress
Bug description:
ft1.1586:
vmware_nsx.neutron.tests.unit.vmware.test_nsx_v_plugin.TestPortsV2.test_delete_port_public_network_StringException:
Empty attachments:
stderr
stdout
pythonlogging:'': {{{
2015-07-17 19:35:37,537 INFO [neutron.manager] Loading core plugin:
vmware_nsx.neutron.plugins.vmware.plugin.NsxVPlugin
2015-07-17 19:35:37,744 INFO
[vmware_nsx.neutron.plugins.vmware.plugins.managers] Configured router type
driver names: ['distributed', 'exclusive', 'shared']
2015-07-17 19:35:37,745 INFO
[vmware_nsx.neutron.plugins.vmware.plugins.managers] Loaded type driver names:
['exclusive', 'distributed', 'shared']
2015-07-17 19:35:37,745 INFO
[vmware_nsx.neutron.plugins.vmware.plugins.managers] Registered types:
['exclusive', 'distributed', 'shared']
2015-07-17 19:35:37,745 INFO
[vmware_nsx.neutron.plugins.vmware.plugins.managers] Tenant router_types:
['shared', 'distributed', 'exclusive']
2015-07-17 19:35:37,745 INFO [neutron.manager] Service L3_ROUTER_NAT is
supported by the core plugin
2015-07-17 19:35:37,756ERROR [neutron.api.extensions] Extension path
'neutron/tests/unit/extensions' doesn't exist!
2015-07-17 19:35:37,761ERROR [neutron.api.extensions] Extension path
'neutron/tests/unit/extensions' doesn't exist!
2015-07-17 19:35:37,762 WARNING [neutron.notifiers.nova] Authenticating to
nova using nova_admin_* options is deprecated. This should be done using an
auth plugin, like password
2015-07-17 19:35:37,763 WARNING [neutron.quota] subnet is already registered.
2015-07-17 19:35:37,764 WARNING [neutron.notifiers.nova] Authenticating to
nova using nova_admin_* options is deprecated. This should be done using an
auth plugin, like password
2015-07-17 19:35:37,765 WARNING [neutron.quota] subnetpool is already
registered.
2015-07-17 19:35:37,765 WARNING [neutron.notifiers.nova] Authenticating to
nova using nova_admin_* options is deprecated. This should be done using an
auth plugin, like password
2015-07-17 19:35:37,767 WARNING [neutron.quota] network is already
registered.
2015-07-17 19:35:37,767 WARNING [neutron.notifiers.nova] Authenticating to
nova using nova_admin_* options is deprecated. This should be done using an
auth plugin, like password
2015-07-17 19:35:37,768 WARNING [neutron.quota] port is already registered.
2015-07-17 19:35:37,889 INFO
[vmware_nsx.neutron.plugins.vmware.plugins.nsx_v] Added {'sg_id': '0',
'vnic_id': '1'}(sg_id)s member to NSX security group 1
2015-07-17 19:35:37,934ERROR [neutron.api.v2.resource] create failed
Traceback (most recent call last):
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/src/neutron/neutron/api/v2/resource.py,
line 83, in resource
result = method(request=request, **args)
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py,
line 146, in wrapper
ectxt.value = e.inner_exc
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py,
line 119, in __exit__
six.reraise(self.type_, self.value, self.tb)
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py,
line 136, in wrapper
return f(*args, **kwargs)
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/src/neutron/neutron/api/v2/base.py,
line 412, in create
item[self._resource])
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/src/neutron/neutron/api/v2/base.py,
line 690, in _validate_network_tenant_ownership
resource_item['network_id'])
File vmware_nsx/neutron/plugins/vmware/plugins/nsx_v.py, line 733, in
get_network
net_result = self._make_network_dict(network)
File
/home/jenkins/workspace/gate-vmware-nsx-python27/.tox/py27/src/neutron/neutron/db/db_base_plugin_common.py,
line 228, in _make_network_dict
entry.target_tenant in ('*', context.tenant_id)):
AttributeError: 'NoneType' object has no attribute 'tenant_id'
}}}
pythonlogging:'neutron.api.extensions': {{{
2015-07-17 19:35:37,756ERROR [neutron.api.extensions] Extension path
'neutron/tests/unit/extensions' doesn't exist!
2015-07-17 19:35:37,761ERROR
Re: [Openstack] Help regarding making multiple concurrent compute requests.
Hi, In theory the requests are treated in parallel. It depends on the deployment. Nova API should handle all of the requests at the same time. Each request will be placed a message queue and that request scheduled. Thanks Gary From: Dhvanan Shah dhva...@gmail.commailto:dhva...@gmail.com Date: Wednesday, July 15, 2015 at 9:27 AM To: Uszov, Márk m...@roico.netmailto:m...@roico.net Cc: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] Help regarding making multiple concurrent compute requests. Hi Mark, Sorry, I should have framed my question better. What I'm trying to look for here is a way in which I can make requests for multiple instances at a given instant of time. basically what I'm trying to find here is if the nova-api gets multiple requests with the same time how does it handle them all, are they handled synchronously, that is only after one request is completed the next is sent for scheduling or it can be done asynchronously that is before a request is scheduled to a host an other request can come in start out its processing. And is there a way to mimic a situation of multiple requests for vm's with different configurations being requested at the same time, that is with the same time stamp, so that the scheduler does not bias on the basis of time as to which one to schedule first. Regards, Dhvanan On Tue, Jul 14, 2015 at 5:21 PM, Uszov, Márk m...@roico.netmailto:m...@roico.net wrote: Hi Dhvanan, Maybe that is just my mistake, but I can not understand what you need. :-) What do you mean on multiple concurrent compute connection? Regards, Mark 2015. júl. 14. 8:48 ezt írta (Dhvanan Shah dhva...@gmail.commailto:dhva...@gmail.com): Hi, I am Dhvanan and I and am new to OpenStack, I wanted to know if there is a way to make multiple concurrent compute requests through the nova-api. It would be great if someone would help me out with this! Cheers, Dhvanan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.orgmailto: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] Switching the bug status of ~200 bugs at once; Problem?
+1 On 7/10/15, 1:32 PM, Sean Dague s...@dague.net wrote: On 07/10/2015 04:09 AM, Markus Zoeller wrote: I'd like to switch the status of ~200 bugs at once to adjust the bookkeeping in LaunchPad. This will concern Confirmed and Triaged bugs which have an assignee [1]. AFAIK they should be In Progress. I'm concerned if this would affect some reports I'm not aware of in a bad way. So, if you think this is a bad thing, please speak up. FWIW, I'll use an enhanced version of [2] which I will provide in the next days. A few days later I'll have a version ready which can update stale In Progress bugs by querying Gerrit. [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_1GbhJWud=BQIC Agc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYB k8YTeq9N3-diTlNj4GyNcm=l81nvT6_KcJY11CmckP4tRUoT25Y8Hn7zMMGBuD2vC8s=0Jw 7eQetRMf4t5LhJi52-n_tjW5h71s56yiu-UO6eh4e= [2] https://review.openstack.org/#/c/197060/ I would not do that. Bugs with assignee tend to get ignored by other people looking at the problem, and in *most* cases the assignee is not actually working on the bug. I would instead go the other direction and pop any In Progress bug that has seen no activity in the last 60 days back to Confirmed. -Sean -- Sean Dague https://urldefense.proofpoint.com/v2/url?u=http-3A__dague.netd=BQICAgc=S qcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9 N3-diTlNj4GyNcm=l81nvT6_KcJY11CmckP4tRUoT25Y8Hn7zMMGBuD2vC8s=8XJOGkHSUvo Uv8dQrHymUt_XXKtMf0hpWsKYuUzoWnse= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1471751] [NEW] VMware: unable to delete VM with attached volumes
Public bug reported:
When the ESX running the VM's was deleted or removed the following
exception occurred when the instance was deleted via OpenStack:
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher
ManagedObjectNotFound: The object has already been deleted or has not been
completely created
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher Cause: Server
raised fault: 'The object has already been deleted or has not been completely
created'
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher Faults:
[ManagedObjectNotFound]
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher Details:
{'obj': 'vm-2073'}
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher
2015-07-02 21:33:00.653 21297 ERROR oslo.messaging._drivers.common [-]
Returning exception The object has already been deleted or has not been
completely created
Cause: Server raised fault: 'The object has already been deleted or has not
been completely created'
Faults: [ManagedObjectNotFound]
Details: {'obj': 'vm-2073'} to caller
This prevent the instance from being deleted in openstack
** Affects: nova
Importance: High
Assignee: Gary Kotton (garyk)
Status: New
** Tags: vmware
** Changed in: nova
Importance: Undecided = High
** Changed in: nova
Assignee: (unassigned) = Gary Kotton (garyk)
** Tags added: 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/1471751
Title:
VMware: unable to delete VM with attached volumes
Status in OpenStack Compute (Nova):
New
Bug description:
When the ESX running the VM's was deleted or removed the following
exception occurred when the instance was deleted via OpenStack:
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher
ManagedObjectNotFound: The object has already been deleted or has not been
completely created
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher Cause:
Server raised fault: 'The object has already been deleted or has not been
completely created'
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher Faults:
[ManagedObjectNotFound]
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher Details:
{'obj': 'vm-2073'}
2015-07-02 21:33:00.638 21297 TRACE oslo.messaging.rpc.dispatcher
2015-07-02 21:33:00.653 21297 ERROR oslo.messaging._drivers.common [-]
Returning exception The object has already been deleted or has not been
completely created
Cause: Server raised fault: 'The object has already been deleted or has not
been completely created'
Faults: [ManagedObjectNotFound]
Details: {'obj': 'vm-2073'} to caller
This prevent the instance from being deleted in openstack
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1471751/+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] - Proposing Miguel Angel Ajo for the Control Plane core team
A huge +1 From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, July 6, 2015 at 1:02 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron_30d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=wtlrQoPt-2_Vjl5Rdv1KGgEI39ZxWLjLaTIBoLekdAUs=dugIWGpPBq2bNc4K-YDr5xpXa9QNJJBcyuTJQSyqB9Ue= http://stackalytics.com/report/contribution/neutron/60https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron_60d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=wtlrQoPt-2_Vjl5Rdv1KGgEI39ZxWLjLaTIBoLekdAUs=w_ZyyB6TTx5iVNO4K6Y7XVvHFWUqSKzTGqLpYmx9tM0e= http://stackalytics.com/report/contribution/neutron/90https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron_90d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=wtlrQoPt-2_Vjl5Rdv1KGgEI39ZxWLjLaTIBoLekdAUs=MWwJYp2X4xncnFCsxCdFCRTvLd9t6cbnbLnwsEgVaxce= -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][oslo-vmware] Core review team
Hi, Over time the team of people working in the project has changed and evolved. We would like to add the following people following their contributions for the project: * Eric Brown We would like to remove the following people as they are no longer working on the project and thank them for their contributions: * Vui Lam * Arnaud Legendre * Kartik Bommepally * Subbu * Shawn Hartsock Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] - breaking changes for plugins/drivers
One of the hidden costs of an external plugin that things break. This is something that happens to us at least once a week. We have been proactive in this by doing the following: 1. Running the decomposed plugin unit tests with every neutron change - this gives us an indication of which patch broke and why 2. Running the Ci The onus is on the decomposed maintainers. Having said that the ability to actually do some development is liberating. A luta continua From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 1, 2015 at 1:49 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] - breaking changes for plugins/drivers For the second one, I think we made it clear before that no plugins must rely on neutron.openstack.* contents. Where was this made clear? I didn't know about this until it broke and I'm a very frequent contributor and reviewer, which is the core of my complaint. The updated wiki is helpful, but doing it after-the-fact only helps when people try to figure out why they can't make changes to their repos. In that patch there were 3 in-tree third party plugins that had to be updated. That should have given a hint that it was likely to break other plugins as well. The other annoying lesson from that is that plugins/drivers still in tree are getting better treatment than the ones that went through the split process. We need to be much more diligent about announcing these things ahead of time or we need to be clear that Neutron is completely unstable as a framework and third party drivers should basically never import anything from the neutron namespace. On Tue, Jun 30, 2015 at 11:58 PM, Ihar Hrachyshka ihrac...@redhat.commailto:ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/01/2015 08:22 AM, Kevin Benton wrote: Hi, We have had at least two breaking changes merge this week for out-of-tree drivers/plugins. These are just the two I noticed that broke the Big Switch CI (the one I keep an eye on since I had set it up): 1. Removed test_lib that changes config files. https://review.openstack.org/#/c/196583/ 2. Removed the loopingcall common util with no deprecation cycle or announcement. https://review.openstack.org/#/c/192999/ I proposed a revert for 1 that merged, but I don't particularly want to keep fighting this. What is our current policy on this? Just change whatever we want and tell plugin maintainers this is just the way things work? For the first one, the revert is justified. For the second one, I think we made it clear before that no plugins must rely on neutron.openstack.* contents. Now I've made it mentioned at: https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage If your plugin is using any of neutron.openstack.* contents, just stop doing it. It's going to break. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVk4+AAAoJEC5aWaUY1u57OE8IAKDqKudi5zOUxRPc4Elzsdw4 mASF5Mtguj5q9OUpYIyeOkbsIKmOwop4tbGjz52L+OZ8aLq1XptpKLUuX6mBL3lS m0/DtD2RlBRTmiO/kyBxeqJbsj7nZU9eoiDJ88gN51IetN1kIR09rAbmdkoduhK2 FIrFLJhhuVqmb8S377cbSgJ46kC1DeDa2xhtFWB39iIKO3ZTwO7ia5KRipTSTyNV 4ngB0+d8EgMfmsKj4Bd7/btkg5rI+o4qNgd4L1Ncd1BQzPiOzzeeGo0lAe86Kf7z KUH2Sw6n6mIUZJSGzDP4cigGqSsilBaurryK90G/Go1q7BEMRFVyrGHObnMBZTw= =qSnW -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] The unbearable lightness of specs
+1 On 6/27/15, 1:25 PM, neil.jer...@metaswitch.com neil.jer...@metaswitch.com wrote: +1 also Original Message From: Fox, Kevin M Sent: Friday, 26 June 2015 21:15 To: OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs +1 From: Tim Bell [tim.b...@cern.ch] Sent: Friday, June 26, 2015 12:26 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: 26 June 2015 16:42 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs On 2015-06-25 16:39:56 + (+), Tim Bell wrote: [...] One of the problems that I¹ve seen is with specs etiquette where people -1 because they have a question. This is a question of education rather than a fundamental issue with the process. http://docs.openstack.org/infra/manual/developers.html#peer-review has been updated with a 7th entry addressing this in particular. Hopefully that will help realign reviewers on acceptable vs. unacceptable use of -1 for certain types of questions over time. I also feel that stackalytics should credit people of a 0 review comment on specs. Currently, I think that only non-zero reviews are considered as a contribution. My understanding of the workflow is that a 0 is in many cases is the constructive way to respond and therefore should be considered as a contribution. Tim -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev- requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] The unbearable lightness of specs
We are not in a good way. The 'drivers' team is very small and just have a small handful of people approving these specs is a huge bottleneck. Taking into the fact that the core team is relatively small the cores will most probably not even get to reviewing the code when it is posted, so it will need to be reverted to the next release I think that the time has come for us to seriously contemplate splitting parts of nova out like what was done with neutron - that has been a very successful venture From: Sergey Nikitin sniki...@mirantis.commailto:sniki...@mirantis.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 25, 2015 at 2:58 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs I've repeatedly stated that the fact that we created an even smaller clique of people to approve specs (nova-drivers which is a tiny subset of the already fr too small nova-core) is madness, as it creates an even worse review burden on them, and thus worsens the bottleneck than we already have. I agree that the number of people who can approve specs is too small at the moment. But relatively few people are actually reviewing specs so building trust here is difficult. I agree that the number of people who can approve specs is too small at the moment too. But I disagree that we have few people who actually reviews specs. For example I had a spec (approved for Juno and Kilo, but not approved for Liberty) https://review.openstack.org/#/c/177112/ which has nine +1 and zero +2. I implemented this spec a long time ago but I spent about 2 months to reaprove spec in Liberty. And it's not reapproved yet. Especially strange for me is that not all nova cores have core status in nova-specs repository. Now we have 14 nova cores and only 7 nova-spec cores. I think if a contributor worked hard to become a nova core, he or she is competent to get a nova-spec core status. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1240653] Re: VMware: move file name handling to utility methods
This has been addressed in the oslo vmware library. ** Changed in: nova Status: Confirmed = 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/1240653 Title: VMware: move file name handling to utility methods Status in OpenStack Compute (Nova): Won't Fix Bug description: It's tempting to use os.path to create proper file names in nova- compute. However for the vmware driver this breaks if nova-compute is run on windows.We should use utility methods to create the filename/path so that people don't need to know to not to use os.path. Another option is to use os_posix.path() To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1240653/+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][neutron] Requirements validations
Hi, In the vmware_nsx project we have done the following: 1. In the test_requirements file we have a link to the neutron master [1]. The purpose for this is that the master branch needs to be in sync with the neutron branch and all unit tests have to pass. So each time there is a change in neutron or vmware_nsx we validate that nothing is broken. 2. On the infra side we have: *the bot that posts updates for requirements. This keeps the requirements file in sync. * The requirements validation scrip running We have now hit an issue where the requirements validation is failing. For example [2]. The problem is that the requirements validation does not like: pkg_resources.RequirementParseError: Expected version spec in -e git://git.openstack.org/openstack/neutron.git at git://git.openstack.org/openstack/neutron.git Any suggestions for addressing this issue? Has anyone else hit this? Thanks Gary [1]. https://github.com/openstack/vmware-nsx/blob/master/test-requirements.txt#L5 [2] http://logs.openstack.org/60/194360/1/check/gate-vmware-nsx-requirements/b294b53/console.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][neutron] Requirements validations
On 6/23/15, 12:52 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/23/2015 11:16 AM, Gary Kotton wrote: Hi, In the vmware_nsx project we have done the following: 1. In the test_requirements file we have a link to the neutron master [1]. The purpose for this is that the master branch needs to be in sync with the neutron branch and all unit tests have to pass. So each time there is a change in neutron or vmware_nsx we validate that nothing is broken. 2. On the infra side we have: 1. the bot that posts updates for requirements. This keeps the requirements file in sync. 2. The requirements validation scrip running We have now hit an issue where the requirements validation is failing. For example [2]. The problem is that the requirements validation does not like: pkg_resources.RequirementParseError: Expected version spec in -e git://git.openstack.org/openstack/neutron.git at git://git.openstack.org/openstack/neutron.git² Any suggestions for addressing this issue? Has anyone else hit this? http://lists.openstack.org/pipermail/openstack-dev/2015-June/065747.html Move the dep to tox.ini, as e.g. *aas repos do. Brilliant! And it works too. Gracias Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJViSxlAAoJEC5aWaUY1u57VbIIANj7MEcjpHJeMblQED6FhfBu i1fDbmCrCNphOjqIq63vG6JsUnM09gyTqFs08y7R7IqzQMFqRmBf8AzYB9dHUZvf PjK8vGjLZgFJJH/wgVzXoD5gpASNrD43nFpQ+dT5xRXnJx5J7fxnNJUBd6WelepG iU9K8NOd9d7S/7GwetryZRiPnGdVagZZ+XOnBnGkJuj40FPTVxP/YeyFfeYRzTdv bhob1dcG9SO61lJsbrvBFC3V0EFDZ5ov5lXcXhJuSrERsCDcc0p8APwULJyzYtiX Ps7W9r1aw24SHw1g2/NFXTw8PUl83iOPCwIVAmqGi5MakCb+PXhrvvhNAJBuFn4= =qvn7 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0
Hi, The email mail below was a little cryptic so here is the general plan to move forwards: 1. Oslo.vmware:- rebase and update the patch https://review.openstack.org/#/c/114503. This will sort out the issues that we have with the exception hierarchy 2. Nova: hopefully manage to get reviews for https://review.openstack.org/191569. This will ensure that Nova works with the exceptions in the existing and future formats (and ensure that we do not go through the debacle that we hit with 0.13.0). Please note that I have tested this with the current version and the aforementioned evrsion and it works 3. We will make a few extra cleanups in Nova as there are some exceptions in the driver that are imported from oslo.vmware and they are specific for nova. So hopefully we can get concensus on the plan and move forwards. A luta continua Thanks Gary On 6/14/15, 5:34 PM, Gary Kotton gkot...@vmware.com wrote: Hi, I agree with Vipin. Can we please address the exception handling. We already have the patches. Thanks Gary On 6/14/15, 12:41 PM, Vipin Balachandran vbalachand...@vmware.com wrote: Dims, There are some problems with exception hierarchy which need to be fixed. -Original Message- From: Davanum Srinivas [mailto:dava...@gmail.com] Sent: Tuesday, June 09, 2015 7:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0 Gary, Tracy, Vipin and other contributors, Is oslo.vmware API solid enough for us to bump to 1.0.0? if not, what's left to be done? thanks, dims -- Davanum Srinivas :: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_dimsd=B Q ICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=CTAUyaHvyUUJ-0QHvizt Q xBhCDLLSg1DksoSE4TOfZ8m=kJNU_fkxhspoxLdOSLde2j2GO0QDJLhUi8W9uh6x5V4s=_U 0 Uo0Fogc_CkxUAPs9E2ql0AbSNYzFJ4YRjsq7qdv8e= _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1464979] [NEW] VMware: _get_power_state does not set correct power state
Public bug reported: In the event that an instance is deleted during the driver get_info method then the instance may not be correctly set. This is due to the fact that the VMware driver does not raise the correct exception. ** Affects: nova Importance: Undecided 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 OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1464979 Title: VMware: _get_power_state does not set correct power state Status in OpenStack Compute (Nova): In Progress Bug description: In the event that an instance is deleted during the driver get_info method then the instance may not be correctly set. This is due to the fact that the VMware driver does not raise the correct exception. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1464979/+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] Gerrit maintenance concluded
Thanks for doing this! On 6/13/15, 4:26 AM, Jeremy Stanley fu...@yuggoth.org wrote: Our maintenance has concluded successfully without incident and the accompanying Gerrit outage was roughly an hour. We moved 57 repositories to new Git namespaces: stackforge/cookbook-openstack-bare-metal - openstack/cookbook-openstack-bare-metal stackforge/cookbook-openstack-block-storage - openstack/cookbook-openstack-block-storage stackforge/cookbook-openstack-client - openstack/cookbook-openstack-client stackforge/cookbook-openstack-common - openstack/cookbook-openstack-common stackforge/cookbook-openstack-compute - openstack/cookbook-openstack-compute stackforge/cookbook-openstack-dashboard - openstack/cookbook-openstack-dashboard stackforge/cookbook-openstack-data-processing - openstack/cookbook-openstack-data-processing stackforge/cookbook-openstack-database - openstack/cookbook-openstack-database stackforge/cookbook-openstack-identity - openstack/cookbook-openstack-identity stackforge/cookbook-openstack-image - openstack/cookbook-openstack-image stackforge/cookbook-openstack-integration-test - openstack/cookbook-openstack-integration-test stackforge/cookbook-openstack-network - openstack/cookbook-openstack-network stackforge/cookbook-openstack-object-storage - openstack/cookbook-openstack-object-storage stackforge/cookbook-openstack-ops-database - openstack/cookbook-openstack-ops-database stackforge/cookbook-openstack-ops-messaging - openstack/cookbook-openstack-ops-messaging stackforge/cookbook-openstack-orchestration - openstack/cookbook-openstack-orchestration stackforge/cookbook-openstack-telemetry - openstack/cookbook-openstack-telemetry stackforge/dragonflow - openstack/dragonflow stackforge/mistral - openstack/mistral stackforge/mistral-dashboard - openstack/mistral-dashboard stackforge/mistral-extra - openstack/mistral-extra stackforge/networking-bgpvpn - openstack/networking-bgpvpn stackforge/networking-cisco - openstack/networking-cisco stackforge/networking-l2gw - openstack/networking-l2gw stackforge/networking-midonet - openstack/networking-midonet stackforge/networking-odl - openstack/networking-odl stackforge/networking-ofagent - openstack/networking-ofagent stackforge/networking-ovn - openstack/networking-ovn stackforge/octavia - openstack/octavia stackforge/openstack-chef-repo - openstack/openstack-chef-repo stackforge/openstack-chef-specs - openstack/openstack-chef-specs stackforge/puppet-ceilometer - openstack/puppet-ceilometer stackforge/puppet-cinder - openstack/puppet-cinder stackforge/puppet-designate - openstack/puppet-designate stackforge/puppet-glance - openstack/puppet-glance stackforge/puppet-gnocchi - openstack/puppet-gnocchi stackforge/puppet-heat - openstack/puppet-heat stackforge/puppet-horizon - openstack/puppet-horizon stackforge/puppet-ironic - openstack/puppet-ironic stackforge/puppet-keystone - openstack/puppet-keystone stackforge/puppet-manila - openstack/puppet-manila stackforge/puppet-modulesync-configs - openstack/puppet-modulesync-configs stackforge/puppet-monasca - openstack/puppet-monasca stackforge/puppet-neutron - openstack/puppet-neutron stackforge/puppet-nova - openstack/puppet-nova stackforge/puppet-openstack-specs - openstack/puppet-openstack-specs stackforge/puppet-openstack_extras - openstack/puppet-openstack_extras stackforge/puppet-openstacklib - openstack/puppet-openstacklib stackforge/puppet-sahara - openstack/puppet-sahara stackforge/puppet-swift - openstack/puppet-swift stackforge/puppet-tempest - openstack/puppet-tempest stackforge/puppet-tripleo - openstack/puppet-tripleo stackforge/puppet-trove - openstack/puppet-trove stackforge/puppet-tuskar - openstack/puppet-tuskar stackforge/puppet-vswitch - openstack/puppet-vswitch stackforge/python-mistralclient - openstack/python-mistralclient stackforge/vmware-nsx - openstack/vmware-nsx We moved and also renamed 1 repository: stackforge/ironic-discoverd - openstack/ironic-inspector We retired 3 unmaintained/abandoned repositories: stackforge/fuel-plugin-external-nfs - stackforge-attic/fuel-plugin-external-nfs stackforge/fuel-plugin-group-based-policy - stackforge-attic/fuel-plugin-group-based-policy stackforge/zvm-driver - stackforge-attic/zvm-driver I've uploaded these .gitreview
Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team
+1 From: Akihiro MOTOKI amot...@gmail.commailto:amot...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, June 12, 2015 at 8:20 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team +1 2015-06-11 23:34 GMT+09:00 Henry Gessau ges...@cisco.commailto:ges...@cisco.com: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and DB core reviewer team. Ann has been a long time contributor in Neutron showing expertise particularly in database matters. She has also worked with and contributed code to the oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the Neutron database healing effort that was completed in the Juno cycle. Her deep knowledge of databases and backends, and her expertise with oslo.db, sqlalchemy and alembic will be very important in this area. Ann is a trusted member of our community and her review stats [2][3][4] place her comfortably with other Neutron core reviewers. She consistently catches database issues early when patches are submitted for review, and shows dedication to helping developers understand and perfect their database-related changes. Existing Neutron core reviewers from the API and DB area of focus, please vote +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl. [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron-2Dgroup_90d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=NyetsTvwqeeB9g_IeOFBT96-p9ybHEwOY7oEF7WHzQQs=UfXR658klk2zl2fYQaizVDo-1Ve6nLCilVQr9YqbJIEe= [4] http://stackalytics.com/?user_id=akamyshnikovametric=markshttps://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_-3Fuser-5Fid-3Dakamyshnikova-26metric-3Dmarksd=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=NyetsTvwqeeB9g_IeOFBT96-p9ybHEwOY7oEF7WHzQQs=wIJOvRNJV-wRMFA8DxC1ngzBjz7Tlmvoot3DB8WE_q4e= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0
Hi, I agree with Vipin. Can we please address the exception handling. We already have the patches. Thanks Gary On 6/14/15, 12:41 PM, Vipin Balachandran vbalachand...@vmware.com wrote: Dims, There are some problems with exception hierarchy which need to be fixed. -Original Message- From: Davanum Srinivas [mailto:dava...@gmail.com] Sent: Tuesday, June 09, 2015 7:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0 Gary, Tracy, Vipin and other contributors, Is oslo.vmware API solid enough for us to bump to 1.0.0? if not, what's left to be done? thanks, dims -- Davanum Srinivas :: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_dimsd=BQ ICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=CTAUyaHvyUUJ-0QHviztQ xBhCDLLSg1DksoSE4TOfZ8m=kJNU_fkxhspoxLdOSLde2j2GO0QDJLhUi8W9uh6x5V4s=_U0 Uo0Fogc_CkxUAPs9E2ql0AbSNYzFJ4YRjsq7qdv8e= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team
+1 From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 11, 2015 at 9:15 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer team. He has been extensively reviewing the entire codebase[2] and his feedback on patches related to the reference implementation has been very useful. This includes everything ranging from the AMPQ API to OVS flows. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for his addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-group/90https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron-2Dgroup_90d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=A2TGKyHtjvHMoKAlUFNuhtp-EzJCAvuVDvWuJUrU1wks=9R8xJGSgvpUrtXxNWiW9X8dZVgUoEaCH5GvU6rrGBqUe= Cheers -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team
+1 On 6/13/15, 1:41 AM, Carl Baldwin c...@ecbaldwin.net wrote: +1! On Fri, Jun 12, 2015 at 1:44 PM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I would like Rossella Sblendido to be a member of the control plane core reviewer team. Her review stats are in line with other cores[2] and her feedback on patches related to the agents has been great. Additionally, she has been working quite a bit on the blueprint to restructure the L2 agent code so she is very familiar with the agent code and the APIs it leverages. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for her addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html# core-review-hierarchy 2. https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_repo rt_contribution_neutron-2Dgroup_30d=BQICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVe Aw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=Cd2HEEvj DeuSBMv1Qe-5Asfui8itK9iR66T3yA628Z4s=fJdXlJ3K8B9p79uT3PtCWc6vtPJ3NbTPpiK cPlOIlcIe= Cheers -- Kevin Benton _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] [neutron] Which node should run dnsmasq?
Hi, The DHCP agent runs the dnsmasq process. That is done on the network node. Thanks Gary On 6/12/15, 2:35 PM, Uwe Sauter uwe.sauter...@gmail.com wrote: Hi, == TL;DR == Which neutron service manages the DNSMASQ processes? Does this run on the controller node or the networking node? == Long story == I have a five node Juno installation (1 controller, 1 storage, 1 network and 2 compute nodes). I followed the Juno Red Hat installation guide [1] up to the point where the dashboard was installed, making modifications where necessary to account for the additional nodes. I'm using Neutron / ML2 as networking component with GRE tenant networks. I am able to sucessfully start a Cirros VM but that instance won't get an IP address. To resolve this I followed a link [2] that told to add logging to dnsmasq. Here the relevant parts on the *network* node: /etc/neutron/dhcp_agent.ini [DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq use_namespaces = True dhcp_delete_namespaces = True verbose = True dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf /etc/neutron/dnsmasq-neutron.conf dhcp-option-force=26,1454 log-facility = /var/log/neutron/dnsmasq.log log-dhcp Then I realized that there were no dnsmasq processes on the networking node but only on the controller node. Is this correct? I was under the impression that neutron-dhcp-agent (running on the networking node) is the service that maintains DHCP on the tenant networks. So the question is: Which service manages dnsmasq and on which node should that run on? Thanks, Uwe [1] http://docs.openstack.org/juno/install-guide/install/yum/content/ [2] https://ask.openstack.org/en/question/63110/unable-to-get-dhcp-lease-in-ju no/ ___ 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] Proposing Brian Haley to Neutron L3 Core Reviewer Team
+1 On 6/10/15, 10:11 PM, Carl Baldwin c...@ecbaldwin.net wrote: Folks, As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to propose Brian Haley as a member of the Neutron L3 core reviewer team. Brian has been a long time contributor in Neutron showing expertise particularly in IPv6, iptables, and Linux kernel matters. His knowledge and involvement will be very important especially in this area. Brian has become a trusted member of our community. His review stats [2][3][4] place him comfortably with other Neutron core reviewers. He regularly runs proposed patches himself and gives insightful feedback. He has shown a lot of interest in the success of Neutron. Existing Neutron core reviewers from the L3 area of focus, please vote +1/-1 for the addition of Brian to the core reviewer team. Specifically, I'm looking for votes from Henry, Assaf, and Mark. Thanks! Carl [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#a dding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley% 2540hp.com%253E%22,n,z [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_repor t_contribution_neutron-2Dgroup_90d=BQICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw -YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EYr3Yah7ycZ Qas7q-FniGQk1c2IcuaNRkdgLh28c32cs=DxJhY-IC3-TXBe_0_as2PqMmpCmdXFG2S-g7pFy G8KAe= [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_-3Fus er-5Fid-3Dbrian-2Dhaley-26metric-3Dmarksd=BQICAgc=Sqcl0Ez6M0X8aeM67LKIiD JAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EYr3 Yah7ycZQas7q-FniGQk1c2IcuaNRkdgLh28c32cs=3qH-V02o3t8eWJvqN9KOqihB97dX7EKx szQyRaL458oe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1463688] [NEW] Period task shuts down instance
Public bug reported: When the periodic task ran it detected that an instance was in a conflicting state. That is Nova was under the impression that the instance was running and it was actually not. This was due to an outage on the backend. When the instance was starting up again the period task forced the instance to shutdown. In some cases this is too extreme and the admin should decide on the action to take. ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: nova Importance: Undecided = High -- 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/1463688 Title: Period task shuts down instance Status in OpenStack Compute (Nova): In Progress Bug description: When the periodic task ran it detected that an instance was in a conflicting state. That is Nova was under the impression that the instance was running and it was actually not. This was due to an outage on the backend. When the instance was starting up again the period task forced the instance to shutdown. In some cases this is too extreme and the admin should decide on the action to take. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1463688/+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 1462424] [NEW] VMware: stable icehouse unable to spawn VM
Public bug reported: Unable to boot VM due to patch https://github.com/openstack/nova/commit/539d632fdea1696dc74fd2fb05921466f804e19e This is with VC 6. The reason is: nova-scheduler.log.1:2015-06-02 16:01:49.280 1174 ERROR nova.scheduler.filter_scheduler [req-18c26579-09e7-4287-b401-27ac3505e7c3 bf28f7d47bf348d6ab6bcf31f0f96c92 04ad461fb68d4b80b2911b3fe0f6b1f9] [instance: 5b3cca48-a295-4aa0-9176-798c174aeb3f] Error from last host: icehouse (node domain-c9(compute)): [u'Traceback (most recent call last):\n', u' File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1379, in _build_instance\nset_access_ip=set_access_ip)\n', u' File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 410, in decorated_function\nreturn function(self, context, *args, **kwargs)\n', u' File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1797, in _spawn\nLOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File /usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py, line 68, in __exit__\nsix.reraise(self.type_, self.value, self.tb)\n', u' File /usr/lib/python2.7/dist-pack ages/nova/compute/manager.py, line 1794, in _spawn\n block_device_info)\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py, line 629, in spawn\nadmin_password, network_info, block_device_info)\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py, line 689, in spawn\n_power_on_vm()\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py, line 685, in _power_on_vm\nself._session._wait_for_task(power_on_task)\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py, line 966, in _wait_for_task\nret_val = done.wait()\n', u' File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait\n return hubs.get_hub().switch()\n', u' File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 187, in switch\n return self.greenlet.switch()\n', uAttributeError: TaskInfo instance has no attribute 'name'\n] ** Affects: nova Importance: Critical Status: New ** Changed in: nova Importance: Undecided = Critical -- 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/1462424 Title: VMware: stable icehouse unable to spawn VM Status in OpenStack Compute (Nova): New Bug description: Unable to boot VM due to patch https://github.com/openstack/nova/commit/539d632fdea1696dc74fd2fb05921466f804e19e This is with VC 6. The reason is: nova-scheduler.log.1:2015-06-02 16:01:49.280 1174 ERROR nova.scheduler.filter_scheduler [req-18c26579-09e7-4287-b401-27ac3505e7c3 bf28f7d47bf348d6ab6bcf31f0f96c92 04ad461fb68d4b80b2911b3fe0f6b1f9] [instance: 5b3cca48-a295-4aa0-9176-798c174aeb3f] Error from last host: icehouse (node domain-c9(compute)): [u'Traceback (most recent call last):\n', u' File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1379, in _build_instance\nset_access_ip=set_access_ip)\n', u' File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 410, in decorated_function\nreturn function(self, context, *args, **kwargs)\n', u' File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1797, in _spawn\nLOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File /usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py, line 68, in __exit__\nsix.reraise(self.type_, self.value, self.tb)\n', u' File /usr/lib/python2.7/dist-pa ckages/nova/compute/manager.py, line 1794, in _spawn\n block_device_info)\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py, line 629, in spawn\nadmin_password, network_info, block_device_info)\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py, line 689, in spawn\n_power_on_vm()\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py, line 685, in _power_on_vm\nself._session._wait_for_task(power_on_task)\n', u' File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py, line 966, in _wait_for_task\nret_val = done.wait()\n', u' File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait\n return hubs.get_hub().switch()\n', u' File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 187, in switch\n return self.greenlet.switch()\n', uAttributeError: TaskInfo instance has no attribute 'name'\n] To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1462424/+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 1461732] Re: duplicate detach volume in nova
*** This bug is a duplicate of bug 1461734 ***
https://bugs.launchpad.net/bugs/1461734
** This bug is no longer a duplicate of bug 1461733
duplicate detach volume in nova
** This bug has been marked a duplicate of bug 1461734
duplicate detach volume in nova
--
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/1461732
Title:
duplicate detach volume in nova
Status in OpenStack Compute (Nova):
New
Bug description:
right now, there are risk that nova will process duplicate detach request. To
recur this problem. You can
1) create a server
2) attach a volume
3) detach multi-times
you can use the bash downside:
for i in {1..20}
do
nova volume-detach server-id volume-id
done
probably you will see the volume is in detaching for ever.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1461732/+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 1461065] [NEW] Security groups may break
Public bug reported: Commit https://github.com/openstack/nova/commit/171e5f8b127610d93a230a6f692d8fd5ea0d0301 converted instance dicts to objects. There are cases for the security groups where these should still be dicts. This will cause update of security groups to break. ** Affects: nova Importance: Undecided Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: kilo-backport-potential ** Tags added: kilo-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/1461065 Title: Security groups may break Status in OpenStack Compute (Nova): In Progress Bug description: Commit https://github.com/openstack/nova/commit/171e5f8b127610d93a230a6f692d8fd5ea0d0301 converted instance dicts to objects. There are cases for the security groups where these should still be dicts. This will cause update of security groups to break. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461065/+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] Progressing/tracking work on libvirt / vif drivers
Hi, At the summit this was discussed in the nova sessions and there were a number of concerns regarding security etc. Thanks Gary From: Irena Berezovsky irenab@gmail.commailto:irenab@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 2, 2015 at 1:44 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers Hi Ian, I like your proposal. It sounds very reasonable and makes separation of concerns between neutron and nova very clear. I think with vif plug script support [1]. it will help to decouple neutron from nova dependency. Thank you for sharing this, Irena [1] https://review.openstack.org/#/c/162468/ On Tue, Jun 2, 2015 at 10:45 AM, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: VIF plugging, but not precisely libvirt VIF plugging, so I'll tout this to a hopefully interested audience. At the summit, we wrote up a spec we were thinking of doing at [1]. It actually proposes two things, which is a little naughty really, but hey. Firstly we propose that we turn binding into a negotiation, so that Nova can offer binding options it supports to Neutron and Neutron can pick the one it likes most. This is necessary if you happen to use vhostuser with qemu, as it doesn't work for some circumstances, and desirable all around, since it means you no longer have to configure Neutron to choose a binding type that Nova likes and Neutron can choose different binding types depending on circumstances. As a bonus, it should make inter-version compatibility work better. Secondly we suggest that some of the information that Nova and Neutron currently calculate independently should instead be passed from Neutron to Nova, simplifying the Nova code since it no longer has to take an educated guess at things like TAP device names. That one is more contentious, since in theory Neutron could pass an evil value, but if we can find some pattern that works (and 'pattern' might be literally true, in that you could get Nova to confirm that the TAP name begins with a magic string and is not going to be a physical device or other interface on the box) I think that would simplify the code there. Read, digest, see what you think. I haven't put it forward yet (actually I've lost track of which projects take specs at this point) but I would very much like to get it implemented and it's not a drastic change (in fact, it's a no-op until we change Neutron to respect what Nova passes). [1] https://etherpad.openstack.org/p/YVR-nova-neutron-binding-spec On 1 June 2015 at 10:37, Neil Jerram neil.jer...@metaswitch.commailto:neil.jer...@metaswitch.com wrote: On 01/06/15 17:45, Neil Jerram wrote: Many thanks, John Dan. I'll start by drafting a summary of the work that I'm aware of in this area, at https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. OK, my first draft of this is now there at [1]. Please could folk with VIF-related work pending check that I haven't missed or misrepresented them? Especially, please could owners of the 'Infiniband SR-IOV' and 'mlnx_direct removal' changes confirm that those are really ready for core review? It would be bad to ask for core review that wasn't in fact wanted. Thanks, Neil [1] https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)
Hi, We have reverted the problematic patch (I suggest that you all add the word balagan to your lexicons). Anyways, the plan forwards is as follows: 1. To update the nova code to use the correct exceptions and to ensure that it will not break moving forwards 2. To clean up the exceptions in oslo.vmware and to make use of the Vim exceptions Thanks and sorry for the troubles Gary From: Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, May 27, 2015 at 9:38 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty) On Wed, May 27, 2015 at 11:23 AM, Davanum Srinivas dava...@gmail.commailto:dava...@gmail.com wrote: Joe, Given that the code once lived in nova and the team across has spent quite a bit of time to turn it into a library which at last count was adopted by 6 projects at least. i'd like to give the team some credit. Agreed, they have done a great job. I was just pointing out a lot of OpenStack libs don't use semver's 0.x.x clause much. openstack/ceilometer/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/cinder/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/congress/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance_store/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/nova/test-requirements.txt:oslo.vmware=0.11.1,!=0.13.0 # Apache-2.0 Shit happens! the team that works on oslo.vmware overlaps nova too and others. There were several solutions that came up quickly as well. we can't just say nothing should ever break or we should not use 0.x.x then we can never make progress. This is not going to get any better either with the big tent coming up. All that matters is how quickly we can recover and move on with our collective sanity intact. Let's work on that in addition as well. I'd also want to give some more say in the actual folks who are contributing and working on the code as well in the specific discussion. Anyway, with the global-requirements block of 0.13.0, nova should unclog and we'll try to get something out soon in 0.13.1 to keep @haypo's python34 effort going as well. Thanks! I think it would be good to move to 1.x.x soon to show that the API is stable. But then again we do have a lot of other libraries that are below 0.x.x so maybe we should look at that more holistically. +1000 to release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general. i'd like to hear specific things we can do that we are not doing both for libraries under our collective care as well as things we use from the general python community. For openstack libraries that have a fairly limited number of consumers we can test source of the lib against target unit test suites, in addition to a devstack run. So oslo.vmware would have a job running source oslo.vmware against nova py27 unit tests. As for in general, is cooking up a plan. thanks, dims On Wed, May 27, 2015 at 1:52 PM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: On Wed, May 27, 2015 at 12:54 AM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, I prefer the patched posted by Sabari. The patch has two changes: It fixes unit tests In the even that an instance spawn fails then it catches an exception to warn the admin that the guestId may be invalid. The only degradation may be that the warning will no longer be there. I think that the admin can get this information from the logged exception too. So this breakage takes us into some strange waters. oslo.vmware is at version 0.x.x which according to semver [0] means Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. If that is accurate, then nova should not be using oslo.vmware, since we shouldn't use an unstable library in production. If we are treating the API as stable then semver says we need to rev the major version (MAJOR version when you make incompatible API changes). What I am trying to say is, I don't know how you can say the nova unit tests are 'wrong.' either nova using oslo.vmware is 'wrong' or oslo.vmware breaking the API is 'wrong'. With OpenStack being so large and having so many dependencies (many of them openstack owned), we should focus on making sure we release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general (lifeless has a big arch he is working on here AFAIK). So I am not in favor of the nova unit test change as a fix here. [0] http://semver.org/https://urldefense.proofpoint.com/v2
Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team
+1 From: Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 28, 2015 at 5:31 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team +1 On Thu, May 28, 2015 at 5:01 PM, Henry Gessau ges...@cisco.commailto:ges...@cisco.com wrote: +1 On Thu, May 28, 2015, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and knowledge in testing will be critical to the team in Liberty and beyond. In addition to that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has become a trusted member of our community. His review stats place him in the pack with the rest of the Neutron core reviewers. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the core reviewer team. Thanks! Kyle [1] http://stackalytics.com/report/contribution/neutron-group/180https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron-2Dgroup_180d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=YsRSQSmhC86UN32ApoB1eZ3-GvjWxmVvOKmK0S2XnL8s=U1p8QBZflttlASSnmrzyMvPf53xUEfkWQvFrVeEc_1oe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)
Hi, I prefer the patched posted by Sabari. The patch has two changes: 1. It fixes unit tests 2. In the even that an instance spawn fails then it catches an exception to warn the admin that the guestId may be invalid. The only degradation may be that the warning will no longer be there. I think that the admin can get this information from the logged exception too. Thanks Gary From: Sabari Murugesan sabari.b...@gmail.commailto:sabari.b...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, May 27, 2015 at 6:20 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty) Matt I posted a patch https://review.openstack.org/#/c/185830/1 to fix the nova tests and make it compatible with the oslo.vmware 0.13.0 release. I am fine with the revert and g-r blacklist as oslo.vmware broke the semver but we can also consider this patch as an option. Thanks Sabari On Tue, May 26, 2015 at 2:53 PM, Davanum Srinivas dava...@gmail.commailto:dava...@gmail.com wrote: Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.commailto:mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware,
[openstack-dev] [nova] xen project retrigger
Hi, Anyone know how to retriever this CI? Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stepping down from Neutron core team
-1 From: Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 21, 2015 at 11:32 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Stepping down from Neutron core team On May 21, 2015 9:06 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: After putting the whole OpenStack networking contributors community through almost 8 cycles of pedant comments and annoying what if questions, it is probably time for me to relieve neutron contributors from this burden. It has been a pleasure for me serving the Neutron community (or Quantum as it was called at the time), and now it feel right - and probably overdue - to relinquish my position as a core team member in a spirit of rotation and alternation between contributors. Note: Before you uncork your champagne bottles, please be aware that I will stay in the Neutron community as a contributors and I might still end up reviewing patches. Thanks for being so understanding with my pedant remarks, Salvatore If I could -1 this as a patch, I would. But seriously. Salvatore, thanks for all the years of work you've put into Neutron. Please note that just because you've stepped down from the core reviewer team doesn't mean we won't be relying on you to be a part of the community. Thanks, Kyle Kyle, I think you should -2 this one. ;) Maybe we should put the core team list in a repo just so you can. All joking aside, @Salv, I have appreciated your feedback much more than you give yourself credit for, maybe more than I let on. You don't need to be a core to give it, so keep it coming. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][vmware] Minimum VC version
Hi, We would like to indicate that we do not support versions below 5.1.0 of the VC. Is anyone aware of people using versions below with OpenStack. Patch https://review.openstack.org/#/c/183711/ proposes exiting Nova compute if a lower version is used. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][vmware] Minimum VC version
On 5/15/15, 3:57 PM, Dan Smith d...@danplanet.com wrote: The proposed patch also drops support for 5.0, which as I understand it is not EOL'd? The documentation appears to indicate that some functionality will not work with 5.1, but it's not explicitly clear what that it is. Yeah, I guess I assumed that anyone on 5.0 was just late moving to =5.1, where people on 4.x might have a license standing in their way. Maybe refusing 5.0 and warning about 5.5 (which is what is now being tested) is the right thing to do? That sounds reasonable to me. I would even go for as much as refusing below 5.1.0. It would be interesting to know if anyone is actually using below 5.1.0 --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Openstack VMware integration issue
Hi, Can you please check on your VC – it looks like you already have an instance called - 35e1ac5c-013d-458d-ad2e-af20987cca1 Thanks Gary From: Satish Patel satish@gmail.commailto:satish@gmail.com Date: Tuesday, May 12, 2015 at 8:28 AM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Openstack VMware integration issue We have successfully integrate Openstack (2014.1.2.1) with VMware (6.x). I can see VMware hypervisour on Openstack GUI but when i go and launch VM i am seeing following error in scheduler.log Seems BUG in VCDriver, any suggestion? 2015-05-10 22:08:13.931 15964 INFO nova.scheduler.filter_scheduler [req-731cbaa5-5a71-439d-81cc-01053a9c962b b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Attempting to build 1 instance(s) uuids: [u'35e1ac5c-013d-458d-ad2e-af20987cca17'] 2015-05-10 22:08:13.933 15964 ERROR nova.scheduler.filter_scheduler [req-731cbaa5-5a71-439d-81cc-01053a9c962b b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] [instance: 35e1ac5c-013d-458d-ad2e-af20987cca17] Error from last host: lnx1iico08x (node domain-c18(ICO-VM)): [u'Traceback (most recent call last):\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1340, in _build_instance\nset_access_ip=set_access_ip)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 401, in decorated_function\nreturn function(self, context, *args, **kwargs)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1779, in _spawn\nLOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, line 68, in __exit__\nsix.reraise(self.type_, self.value, self.tb)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1765, in _spawn\nblock_device_info)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 854, in spawn\nadmin_password, network_info, block_device_info)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 757, in spawn\n_power_on_vm()\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 540, in _power_on_vm\nself._session._wait_for_task(power_on_task)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 1220, in _wait_for_task\nret_val = done.wait()\n', u' File /usr/lib/python2.6/site-packages/eventlet/event.py, line 116, in wait\n return hubs.get_hub().switch()\n', u' File /usr/lib/python2.6/site-packages/eventlet/hubs/hub.py, line 187, in switch\n return self.greenlet.switch()\n', uAttributeError: TaskInfo instance has no attribute 'name'\n] 2015-05-10 22:08:13.967 15964 INFO nova.scheduler.filter_scheduler [req-731cbaa5-5a71-439d-81cc-01053a9c962b b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Choosing host WeighedHost [host: lnx1iico08x, weight: 1.0] for instance 35e1ac5c-013d-458d-ad2e-af20987cca17 2015-05-10 22:08:20.682 15964 INFO nova.scheduler.filter_scheduler [req-731cbaa5-5a71-439d-81cc-01053a9c962b b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Attempting to build 1 instance(s) uuids: [u'35e1ac5c-013d-458d-ad2e-af20987cca17'] 2015-05-10 22:08:20.691 15964 ERROR nova.scheduler.filter_scheduler [req-731cbaa5-5a71-439d-81cc-01053a9c962b b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] [instance: 35e1ac5c-013d-458d-ad2e-af20987cca17] Error from last host: lnx1iico08x (node domain-c18(ICO-VM)): [u'Traceback (most recent call last):\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1340, in _build_instance\nset_access_ip=set_access_ip)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 401, in decorated_function\nreturn function(self, context, *args, **kwargs)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1779, in _spawn\nLOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, line 68, in __exit__\nsix.reraise(self.type_, self.value, self.tb)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1765, in _spawn\nblock_device_info)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 854, in spawn\nadmin_password, network_info, block_device_info)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 418, in spawn\n_execute_create_vm()\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 414, in _execute_create_vm\nself._session._wait_for_task(vm_create_task)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py,
Re: [Openstack] Openstask + VMware with NO networking possible
Hi, There are a number of different networking solutions when using the Vmware drivers. If you make use of the vmware_nsx neutron networking repo then you have the following three: 1. NSX-MH 2. NSXv 3. Simple DVS The simple DVS enables you to spin up Vms and get network connectivty. This does not have security groups and layer 3 support. Thanks Gary From: Satish Patel satish@gmail.commailto:satish@gmail.com Date: Sunday, May 10, 2015 at 6:00 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Openstask + VMware with NO networking possible I am doing some testing and experiment, I have install openstack and integrate with VMware but somehow i am not able to deploy instance on VMware but i can see error. Just wonder we are using Neutron networking, so do i have to use NSX configured on VMware? at this stage i don't care about networking, only i care it create VM auto matically. is it possible to deploy VM without configuring network component? ___ 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] URGENT - Openstack + VMWare VM deployed but openstack doesn't know
Hi, Which version are you using? Thanks Gary From: Satish Patel satish@gmail.commailto:satish@gmail.com Date: Sunday, May 10, 2015 at 4:23 AM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] URGENT - Openstack + VMWare VM deployed but openstack doesn't know We have integrate Openstack with VMware (vCenter 6.x), If i launch instance from openstack GUI and VM has been deployed on VMware but still openstack think its not deployed and it tried 3 time to create VM and in end throwing error in status but i can see VM is up and running on VMware Host. What is wrong with openstack? 2015-05-09 20:48:48.625 29674 INFO nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Attempting to build 1 instance(s) uuids: [u'060dba43-3065-4927-bf1f-50abdc72da7d'] 2015-05-09 20:48:48.695 29674 INFO nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Choosing host WeighedHost [host: lnx01, weight: 1.0] for instance 060dba43-3065-4927-bf1f-50abdc72da7d 2015-05-09 20:49:48.299 29674 INFO nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Attempting to build 1 instance(s) uuids: [u'060dba43-3065-4927-bf1f-50abdc72da7d'] 2015-05-09 20:49:48.302 29674 ERROR nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] [instance: 060dba43-3065-4927-bf1f-50abdc72da7d] Error from last host: lnx01 (node domain-c18(IMP-VM)): [u'Traceback (most recent call last):\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1340, in _build_instance\nset_access_ip=set_access_ip)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 401, in decorated_function\nreturn function(self, context, *args, **kwargs)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1779, in _spawn\nLOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, line 68, in __exit__\nsix.reraise(self.type_, self.value, self.tb)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1765, in _spawn\nblock_device_info)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 854, in spawn\nadmin_password, network_info, block_device_info)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 757, in spawn\n_power_on_vm()\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 540, in _power_on_vm\nself._session._wait_for_task(power_on_task)\n', u' File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 1220, in _wait_for_task\nret_val = done.wait()\n', u' File /usr/lib/python2.6/site-packages/eventlet/event.py, line 116, in wait\n return hubs.get_hub().switch()\n', u' File /usr/lib/python2.6/site-packages/eventlet/hubs/hub.py, line 187, in switch\n return self.greenlet.switch()\n', uAttributeError: TaskInfo instance has no attribute 'name'\n] 2015-05-09 20:49:48.366 29674 INFO nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Choosing host WeighedHost [host: lnx01, weight: 1.0] for instance 060dba43-3065-4927-bf1f-50abdc72da7d 2015-05-09 20:49:59.409 29674 INFO nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] Attempting to build 1 instance(s) uuids: [u'060dba43-3065-4927-bf1f-50abdc72da7d'] 2015-05-09 20:49:59.411 29674 ERROR nova.scheduler.filter_scheduler [req-1e440c82-21c4-4010-9d99-b2623c7547a1 b872b754f8774f64b3344e1ef9c245db 49de35ef22bb4bb08355fb2bb163a588] [instance: 060dba43-3065-4927-bf1f-50abdc72da7d] Error from last host: lnx01 (node domain-c18(IMP-VM)): [u'Traceback (most recent call last):\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1340, in _build_instance\nset_access_ip=set_access_ip)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 401, in decorated_function\nreturn function(self, context, *args, **kwargs)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1779, in _spawn\nLOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, line 68, in __exit__\nsix.reraise(self.type_, self.value, self.tb)\n', u' File /usr/lib/python2.6/site-packages/nova/compute/manager.py,
Re: [Openstack] Openstack with ESXi host integration
Hi, At the moment the Nova driver only supports VC. The ESX support was deprecated. Thanks Gary From: Satish Patel satish@gmail.commailto:satish@gmail.com Date: Friday, May 8, 2015 at 5:12 PM To: openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: [Openstack] Openstack with ESXi host integration Hi, I recently installed openstack using devstack but now i have one standalone ESXi host which i want to integrate with Openstack, it is possible without Vcenter we can integrate ESXi host only in Openstack? I only found document about Vcenter integration but not single one about Standalone ESXi host. Suggest me. ___ 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 1451834] [NEW] VMware: unable to boot an instance with NFS 4.1
Public bug reported: 2015-05-05 06:26:38.349 ERROR nova.compute.manager [req-856a9b7a-37f8-4885-a872-042c63b57ba7 demo demo] [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] Instance failed to spawn 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] Traceback (most recent call last): 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/compute/manager.py, line 2475, in _build_resources 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] yield resources 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/compute/manager.py, line 2347, in _build_and_run_instance 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] block_device_info=block_device_info) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 512, in spawn 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] admin_password, network_info, block_device_info) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/vmops.py, line 581, in spawn 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] extra_specs) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/vmops.py, line 464, in _get_vm_config_info 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] allowed_ds_types) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/ds_util.py, line 147, in get_datastore 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] % datastore_regex.pattern) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] DatastoreNotFound: Datastore regex NFS did not match any datastores 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] The reason for this is that the new NFS type is NFS41. This support was added in ESX 6.0 ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: kilo-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/1451834 Title: VMware: unable to boot an instance with NFS 4.1 Status in OpenStack Compute (Nova): In Progress Bug description: 2015-05-05 06:26:38.349 ERROR nova.compute.manager [req-856a9b7a-37f8-4885-a872-042c63b57ba7 demo demo] [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] Instance failed to spawn 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] Traceback (most recent call last): 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/compute/manager.py, line 2475, in _build_resources 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] yield resources 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/compute/manager.py, line 2347, in _build_and_run_instance 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] block_device_info=block_device_info) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 512, in spawn 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] admin_password, network_info, block_device_info) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/vmops.py, line 581, in spawn 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] extra_specs) 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] File /opt/stack/nova/nova/virt/vmwareapi/vmops.py, line 464, in _get_vm_config_info 2015-05-05 06:26:38.349 TRACE nova.compute.manager [instance: 790de6c2-3e54-4c99-bf1c-f548ed14081f] allowed_ds_types) 2015-05-05 06:26:38.349 TRACE nova.compute.manager
[Yahoo-eng-team] [Bug 1451389] [NEW] Nova gate nroke due to failed unit test
Public bug reported:
[x]
ft1.13172:
nova.tests.unit.virt.vmwareapi.test_read_write_util.ReadWriteUtilTestCase.test_ipv6_host_read_StringException:
Empty attachments:
pythonlogging:''
stderr
stdout
Traceback (most recent call last):
File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 1201, in patched
return func(*args, **keywargs)
File nova/tests/unit/virt/vmwareapi/test_read_write_util.py, line 49, in
test_ipv6_host_read
verify=False)
File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 846, in assert_called_once_with
return self.assert_called_with(*args, **kwargs)
File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 835, in assert_called_with
raise AssertionError(msg)
AssertionError: Expected call: request('get',
'https://[fd8c:215d:178e:c51e:200:c9ff:fed1:584c]:7443/folder/tmp/fake.txt?dcPath=fake_dcdsName=fake_ds',
stream=True, headers={'User-Agent': 'OpenStack-ESX-Adapter'},
allow_redirects=True, verify=False)
Actual call: request('get',
'https://[fd8c:215d:178e:c51e:200:c9ff:fed1:584c]:7443/folder/tmp/fake.txt?dcPath=fake_dcdsName=fake_ds',
stream=True, headers={'User-Agent': 'OpenStack-ESX-Adapter'},
allow_redirects=True, params=None, verify=False)
** Affects: nova
Importance: Critical
Assignee: Gary Kotton (garyk)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) = Gary Kotton (garyk)
** Changed in: nova
Importance: Undecided = Critical
** 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/1451389
Title:
Nova gate nroke due to failed unit test
Status in OpenStack Compute (Nova):
In Progress
Bug description:
[x]
ft1.13172:
nova.tests.unit.virt.vmwareapi.test_read_write_util.ReadWriteUtilTestCase.test_ipv6_host_read_StringException:
Empty attachments:
pythonlogging:''
stderr
stdout
Traceback (most recent call last):
File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 1201, in patched
return func(*args, **keywargs)
File nova/tests/unit/virt/vmwareapi/test_read_write_util.py, line 49, in
test_ipv6_host_read
verify=False)
File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 846, in assert_called_once_with
return self.assert_called_with(*args, **kwargs)
File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 835, in assert_called_with
raise AssertionError(msg)
AssertionError: Expected call: request('get',
'https://[fd8c:215d:178e:c51e:200:c9ff:fed1:584c]:7443/folder/tmp/fake.txt?dcPath=fake_dcdsName=fake_ds',
stream=True, headers={'User-Agent': 'OpenStack-ESX-Adapter'},
allow_redirects=True, verify=False)
Actual call: request('get',
'https://[fd8c:215d:178e:c51e:200:c9ff:fed1:584c]:7443/folder/tmp/fake.txt?dcPath=fake_dcdsName=fake_ds',
stream=True, headers={'User-Agent': 'OpenStack-ESX-Adapter'},
allow_redirects=True, params=None, verify=False)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1451389/+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] Proposal to add Melanie Witt to nova-core
+1 From: Alex Xu sou...@gmail.commailto:sou...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 6:30 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core I'm not core, but I want to +1 :) 2015-04-30 19:30 GMT+08:00 John Garbutt j...@johngarbutt.commailto:j...@johngarbutt.com: Hi, I propose we add Melanie to nova-core. She has been consistently doing great quality code reviews[1], alongside a wide array of other really valuable contributions to the Nova project. Please respond with comments, +1s, or objections within one week. Many thanks, John [1] https://review.openstack.org/#/dashboard/4690 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1444446] [NEW] VMware: resizing a instance that has no root disk fails
Public bug reported: 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py, line 1278, in _resize_create_ephemerals 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher ds_ref = vmdk.device.backing.datastore 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher AttributeError: 'NoneType' object has no attribute 'backing' 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher 2015-04-13 21:25:51.442 7852 ERROR oslo.messaging._drivers.common [-] Returning exception 'NoneType' object has no attribute 'backing' to caller ** Affects: nova Importance: Undecided 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 OpenStack Compute (nova). https://bugs.launchpad.net/bugs/146 Title: VMware: resizing a instance that has no root disk fails Status in OpenStack Compute (Nova): In Progress Bug description: 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py, line 1278, in _resize_create_ephemerals 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher ds_ref = vmdk.device.backing.datastore 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher AttributeError: 'NoneType' object has no attribute 'backing' 2015-04-13 21:25:51.437 7852 TRACE oslo.messaging.rpc.dispatcher 2015-04-13 21:25:51.442 7852 ERROR oslo.messaging._drivers.common [-] Returning exception 'NoneType' object has no attribute 'backing' to caller To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/146/+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 1444439] [NEW] Resource tracker: unable to start nova compute
/instance.py, line 564, in get_by_uuid 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup use_slave=use_slave) 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup File /opt/stack/nova/nova/db/api.py, line 651, in instance_get_by_uuid 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup columns_to_join, use_slave=use_slave) 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup File /opt/stack/nova/nova/db/sqlalchemy/api.py, line 233, in wrapper 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup return f(*args, **kwargs) 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup File /opt/stack/nova/nova/db/sqlalchemy/api.py, line 1744, in instance_get_by_uuid 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup columns_to_join=columns_to_join, use_slave=use_slave) 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup File /opt/stack/nova/nova/db/sqlalchemy/api.py, line 1756, in _instance_get_by_uuid 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup raise exception.InstanceNotFound(instance_id=uuid) 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup InstanceNotFound: Instance 42264e24-1385-41f1-8dfc-120a1891ab05 could not be found. 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.821 TRACE nova.openstack.common.threadgroup 2015-04-15 04:47:04.824 INFO oslo_vmware.api [req-2d7c5d01-438c-494c-a382-b7c55b71d8be None None] Logging out and terminating the current session with ID = f4fcb. nicira@Ubuntu1404Server:~/devstack$ ** Affects: nova Importance: Critical Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: kilo-rc-potential ** Changed in: nova Importance: Undecided = Critical ** 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/139 Title: Resource tracker: unable to start nova compute Status in OpenStack Compute (Nova): In Progress Bug description: After a failure of the resize and a deletion of the instance. I am unable to restart the nova compute due to the exception below. The instance was deleted via nova api. The DB is as follows: mysql select * from migrations; +-+-+++--+--+---++--+--+--+--+--+-+ | created_at | updated_at | deleted_at | id | source_compute | dest_compute | dest_host | status | instance_uuid| old_instance_type_id | new_instance_type_id | source_node | dest_node| deleted | +-+-+++--+--+---++--+--+--+--+--+-+ | 2015-04-15 09:44:02 | 2015-04-15 09:44:08 | NULL | 1 | Ubuntu1404Server | Ubuntu1404Server | 10.160.94.173 | post-migrating | 42264e24-1385-41f1-8dfc-120a1891ab05 | 10 | 11 | domain-c167(DVS) | domain-c167(DVS) | 0 | | 2015-04-15 09:48:13 | 2015-04-15 10:19:48 | NULL | 2 | Ubuntu1404Server | Ubuntu1404Server | 10.160.94.173 | reverted | fcab4bde-d93e-4d79-ae35-9d1306da10a4 | 10 | 11 | domain-c167(DVS) | domain-c167(DVS) | 0 | | 2015-04-15 10:23:56 | 2015-04-15 10:24:03 | NULL | 3 | Ubuntu1404Server | Ubuntu1404Server | 10.160.94.173 | post-migrating | d074bbc0-b912-4c85-a02b-aabf56d45f0b | 10 | 11 | domain-c167(DVS) | domain-c167(DVS) | 0 | | 2015-04-15 10:27:45 | 2015-04-15 10:28:16 | NULL | 4 | Ubuntu1404Server | Ubuntu1404Server | 10.160.94.173 | reverted | 21e59c96-fa2f-45e3-9070-e982a2dafea6 | 10 | 11 | domain-c167(DVS) | domain-c167(DVS) | 0 | | 2015-04-15 10:28:43 | 2015-04-15 10:29:16 | NULL | 5 | Ubuntu1404Server | Ubuntu1404Server | 10.160.94.173 | confirming | 21e59c96-fa2f-45e3-9070-e982a2dafea6 | 10 | 11 | domain-c167(DVS) | domain-c167(DVS) | 0 | | 2015-04-15 10:35:15 | 2015-04-15 10:53:16 | NULL
Re: [openstack-dev] In loving memory of Chris Yeoh
Hi, I am very saddened to read this. Not only will Chris be missed on a professional level but on a personal level. He was a real mensh (http://www.thefreedictionary.com/mensh). He was always helpful and supportive. Wishing his family a long life. Thanks Gary On 4/13/15, 4:33 AM, Michael Still mi...@stillhq.com wrote: Hi, as promised I now have details of a charity for people to donate to in Chris' memory: https://urldefense.proofpoint.com/v2/url?u=http-3A__participate.freetobrea the.org_site_TR-3Fpx-3D1582460-26fr-5Fid-3D2710-26pg-3Dpersonal-23.VSscH5S Ud90d=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzk WT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm sD8s=B3EgunFqBdY8twmv-iJ7G7xvKZ4Th48oB4HKSv2uGKge= In the words of the family: We would prefer that people donate to lung cancer research in lieu of flowers. Lung cancer has the highest mortality rate out of all the cancers, and the lowest funding out of all the cancers. There is a stigma attached that lung cancer is a smoker's disease, and that sufferers deserve their fate. They bring it on through lifestyle choice. Except that Chris has never smoked in his life, like a surprisingly large percentage of lung cancer sufferers. These people suffer for the incorrect beliefs of the masses, and those that are left behind are equally innocent. We shouldn't be doing this now. He shouldn't be gone. We need to do more to fix this. There will be charity envelopes available at the funeral, or you can choose your preferred research to fund, should you wish to do so. You have our thanks. Michael On Wed, Apr 8, 2015 at 2:49 PM, Michael Still mi...@stillhq.com wrote: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven¹t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ŒHackfest¹ programming contests for a number of years at Australia¹s open source conference -- linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa¹s memories of her dad need to last her a long time, so we¹ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_form s_d_1kX-2DePqAO7Cuudppwqz1cqgBXAsJx27GkdM-2DeCZ0c1V8_viewformd=AwIGaQc= Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTe q9N3-diTlNj4GyNcm=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRmsD8s=iihsaOMe lNeIR3VZapWKjr5KLgMQArZ3nifKDo1yy8oe= Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lokigames.com_hac k_d=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkW T5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm sD8s=9SJI7QK-jzCsVUN2hTXSthqiXNEbq2Fvl9JqQiX9tfoe= -- Rackspace Australia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1443082] [NEW] VMware: console access result in repeated keystrokes
Public bug reported: When there is bad network connectivity it may result n keystrokes being repeated when accessing the console. Please see http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=196 ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: vmware ** Tags added: 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/1443082 Title: VMware: console access result in repeated keystrokes Status in OpenStack Compute (Nova): In Progress Bug description: When there is bad network connectivity it may result n keystrokes being repeated when accessing the console. Please see http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=196 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1443082/+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 CI
Thanks! On 4/12/15, 3:04 PM, Davanum Srinivas dava...@gmail.com wrote: Gary, John, Just to speed things up, i filed a backport: https://review.openstack.org/#/c/172710/ thanks, dims On Sun, Apr 12, 2015 at 4:23 AM, John Garbutt j...@johngarbutt.com wrote: I have updated the bug so it's high priority and tagged with kilo-rc-potential, and added your note from below as a comment on the bug. It looks like it might be worth a backport so it gets into RC2? Can anyone take that bit on please? Thanks, John On Sunday, April 12, 2015, Gary Kotton gkot...@vmware.com wrote: Hi, Can a core please take a look at https://review.openstack.org/#/c/171037. The CI is broken due to commit e7ae5bb7fbdd5b79bde8937958dd0a645554a5f0. Thanks Gary _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_dimsd=Aw ICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JY Bk8YTeq9N3-diTlNj4GyNcm=O_vdKYuE0xFSaX6xbIHw3qdu0asR94NVcbUKhC9t2vss=zv9 uaaxIRcEZR4SDIuS8EJW7YjE4-2QEZKZtxKcl4owe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] VMware CI
Hi, Can a core please take a look at https://review.openstack.org/#/c/171037. The CI is broken due to commit e7ae5bb7fbdd5b79bde8937958dd0a645554a5f0. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler
On 4/3/15, 8:24 PM, Dugger, Donald D donald.d.dug...@intel.com wrote: The goal is not `splitting for the sake of splitting'. The goal is to have a separate scheduler that is ultimately usable by other projects inside OpenStack. Currently Cinder has its own filter based scheduler (duplicating scheduling code in 2 places seems silly), Neutron will need scheduling services, there are multiple places where a common scheduling service would be beneficial. + 1 -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Ed Leafe [mailto:e...@leafe.com] Sent: Friday, April 3, 2015 10:59 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/03/2015 11:42 AM, Dugger, Donald D wrote: Yes the current effort is to clean up the scheduler interfaces but one of the main goals of that clean up is to make it possible to then split out the scheduler to a separate project. I don't want to lose focus on the ultimate goal of creating the split. I don't agree that the ultimate goal is splitting the scheduler. IMO, the goal is to create 1) a clean, robust interface along with 2) a scalable architecture. Those improvements will 1) allow the scheduler to be split cleanly, and 2) justify splitting it out. Splitting for the sake of splitting is pointless. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVHsbeAAoJEKMgtcocwZqLdysQAIJ6nThjqgNgJu1hLW4n6MDY Db57k+37b5M5h6Z633jrXSTWCuqjIwUIW2G1+PQMsXq7FcWguAG7fxhVizE4s0h0 RhucmNQ1GWj6eFNfpSljC0WAdZEDhuXnPcxi2OyMwRr0j2lqYcJvPKBmuobS8Rbl xD9ciIlVELtHPm2dsj1HkB8TO7fgESjdv+I2QPU9C31ubp0CYlwSAPCdAhN9g+B0 WVCEnq+7ADn95G+/z77Wlx6s83KkCh89C+h2ivgGI4mHeWJskXT9lr9lsC342DO9 GoWvDvRF5H9/imx6Jh4avipH55YCZfZ9T+2eOPVoAYkXujPiX13tqM8UkBj7KCDx /FJNatC0aTDPYGMgOW329pGWkP9n2ceW1gMlyHpmMFJHCaAdmM+gqnjnarT1UECr 13yndy9axjubisZ71hdGgBi/Sy1FbG5+XVshWyAUgzoJZurDtg4RhhUdw8n0iQKd SuA3E9Z+PI6gTulp532JdHBVOpsG2P+9QOzLwBEnpSp8WmuU8h2EVMm6A3Zdrf+4 zIUL8lvpDwZ/0KBHSF6WptZspSXe/OwOKlQYO2geHkeARANv3Tv/h3HB/7SW1Bz0 8N5K2aDK/adzfzagrV0S3f201JoFC90JSXgA4dDdtHr8/oUj1kw3QoTACVrvPvYP ayW76hfM68cjJ3DyhXys =5h63 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1439585] [NEW] VMware: when booting with --ephemeral and we fail to default the adapter_type available from the image.
Public bug reported: This causes the spawn to fail ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: nova Importance: Undecided = High -- 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/1439585 Title: VMware: when booting with --ephemeral and we fail to default the adapter_type available from the image. Status in OpenStack Compute (Nova): In Progress Bug description: This causes the spawn to fail To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1439585/+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 1381061] Re: VMware: ESX hosts must not be externally routable
This is a documentation issue and not a nova bug ** No longer affects: nova -- 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/1381061 Title: VMware: ESX hosts must not be externally routable Status in OpenStack Manuals: Triaged Bug description: Change I70fd7d3ee06040d6ce49d93a4becd9cbfdd71f78 removed passwords from VNC hosts. This change is fine because we proxy the VNC connection and do access control at the proxy, but it assumes that ESX hosts are not externally routable. In a non-OpenStack VMware deployment, accessing a VM's console requires the end user to have a direct connection to an ESX host. This leads me to believe that many VMware administrators may leave ESX hosts externally routable if not specifically directed otherwise. The above change makes a design decision which requires ESX hosts not to be externally routable. There may also be other reasons. We need to ensure that this is very clearly documented. This may already be documented, btw, but I don't know how our documentation is organised, and would prefer that somebody more familiar with it assures themselves that this has been given appropriate weight. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-manuals/+bug/1381061/+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 1346549] Re: VMware: Storage error: Unable to find iSCSI Target
I hit the same issue and it was due to the way in which cinder was configured. My understanding is that this is the case here as this is the CI. Since updating the config is up and running. ** Changed in: nova Status: Incomplete = 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/1346549 Title: VMware: Storage error: Unable to find iSCSI Target Status in OpenStack Compute (Nova): Invalid Bug description: The following Tempest tests are failing with the VMware nova driver: tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON.test_delete_server_while_in_attached_volume tempest.api.compute.servers.test_delete_server.DeleteServersTestXML.test_delete_server_while_in_attached_volume tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestXML.test_rescued_vm_detach_volume The following error is seen in the logs: Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 134, in _dispatch_and_reply incoming.message)) File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 177, in _dispatch return self._do_dispatch(endpoint, method, ctxt, args) File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 123, in _do_dispatch result = getattr(endpoint, method)(ctxt, **new_args) File /opt/stack/nova/nova/compute/manager.py, line 405, in decorated_function return function(self, context, *args, **kwargs) File /opt/stack/nova/nova/exception.py, line 88, in wrapped payload) File /opt/stack/nova/nova/openstack/common/excutils.py, line 82, in __exit__ six.reraise(self.type_, self.value, self.tb) File /opt/stack/nova/nova/exception.py, line 71, in wrapped return f(self, context, *args, **kw) File /opt/stack/nova/nova/compute/manager.py, line 290, in decorated_function pass File /opt/stack/nova/nova/openstack/common/excutils.py, line 82, in __exit__ six.reraise(self.type_, self.value, self.tb) File /opt/stack/nova/nova/compute/manager.py, line 276, in decorated_function return function(self, context, *args, **kwargs) File /opt/stack/nova/nova/compute/manager.py, line 318, in decorated_function kwargs['instance'], e, sys.exc_info()) File /opt/stack/nova/nova/openstack/common/excutils.py, line 82, in __exit__ six.reraise(self.type_, self.value, self.tb) File /opt/stack/nova/nova/compute/manager.py, line 306, in decorated_function return function(self, context, *args, **kwargs) File /opt/stack/nova/nova/compute/manager.py, line 4269, in attach_volume bdm.destroy(context) File /opt/stack/nova/nova/openstack/common/excutils.py, line 82, in __exit__ six.reraise(self.type_, self.value, self.tb) File /opt/stack/nova/nova/compute/manager.py, line 4266, in attach_volume return self._attach_volume(context, instance, driver_bdm) File /opt/stack/nova/nova/compute/manager.py, line 4287, in _attach_volume self.volume_api.unreserve_volume(context, bdm.volume_id) File /opt/stack/nova/nova/openstack/common/excutils.py, line 82, in __exit__ six.reraise(self.type_, self.value, self.tb) File /opt/stack/nova/nova/compute/manager.py, line 4279, in _attach_volume do_check_attach=False, do_driver_attach=True) File /opt/stack/nova/nova/virt/block_device.py, line 45, in wrapped ret_val = method(obj, context, *args, **kwargs) File /opt/stack/nova/nova/virt/block_device.py, line 249, in attach connector) File /opt/stack/nova/nova/openstack/common/excutils.py, line 82, in __exit__ six.reraise(self.type_, self.value, self.tb) File /opt/stack/nova/nova/virt/block_device.py, line 240, in attach device_type=self['device_type'], encryption=encryption) File /opt/stack/nova/nova/virt/vmwareapi/driver.py, line 646, in attach_volume mountpoint) File /opt/stack/nova/nova/virt/vmwareapi/volumeops.py, line 388, in attach_volume self._attach_volume_iscsi(connection_info, instance, mountpoint) File /opt/stack/nova/nova/virt/vmwareapi/volumeops.py, line 363, in _attach_volume_iscsi reason=_(Unable to find iSCSI Target)) StorageError: Storage error: Unable to find iSCSI Target To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1346549/+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 1289205] Re: VMware: 404 Not Found error when create snapshot
Would it be possible that you please try with the latest code. The whole snapot has been improved to use streamoptimized images ** Changed in: nova Status: Incomplete = 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/1289205 Title: VMware: 404 Not Found error when create snapshot Status in OpenStack Compute (Nova): Invalid Bug description: When try to create instance snapshot via 'nova image-create', I hint following error in the nova log file: 2014-03-07 03:04:35.436 7213 DEBUG nova.virt.vmwareapi.vmware_images [req-d82fb9c2-9325-43a4-814a-4ea1bae14c5c 8f4bfb793af946b6a25288456143e920 e4a913fb2d1e4a33a4acacc806dd6153] [instance: 23261217-c2e6-472c-85e9-9afbd708391d] Uploading image 64a0b47b-ba53-4e7b-9877-f56186916d73 to the Glance image server upload_image /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmware_images.py:141 2014-03-07 03:04:35.437 7213 DEBUG nova.virt.vmwareapi.read_write_util [req-d82fb9c2-9325-43a4-814a-4ea1bae14c5c 8f4bfb793af946b6a25288456143e920 e4a913fb2d1e4a33a4acacc806dd6153] aaa-https://172.16.151.254/folder/vmware_temp/be5acd3b-b68b-4e6e-9039-43dd7bf910bf-flat.vmdk?dsName=datastore1dcPath=smartlcouds __init__ /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/read_write_util.py:162 2014-03-07 03:04:35.438 7213 DEBUG nova.virt.vmwareapi.read_write_util [req-d82fb9c2-9325-43a4-814a-4ea1bae14c5c 8f4bfb793af946b6a25288456143e920 e4a913fb2d1e4a33a4acacc806dd6153] bbb-urllib2.Request instance at 0xd36d680 __init__ /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/read_write_util.py:163 2014-03-07 03:04:35.477 7213 DEBUG nova.compute.manager [req-d82fb9c2-9325-43a4-814a-4ea1bae14c5c 8f4bfb793af946b6a25288456143e920 e4a913fb2d1e4a33a4acacc806dd6153] [instance: 23261217-c2e6-472c-85e9-9afbd708391d] Cleaning up image 64a0b47b-ba53-4e7b-9877-f56186916d73 decorated_function /usr/lib/python2.6/site-packages/nova/compute/manager.py:317 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] Traceback (most recent call last): 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 313, in decorated_function 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] *args, **kwargs) 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2525, in snapshot_instance 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] task_states.IMAGE_SNAPSHOT) 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2560, in _snapshot_instance 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] update_task_state) 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 614, in snapshot 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] _vmops.snapshot(context, instance, name, update_task_state) 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 939, in snapshot 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] _upload_vmdk_to_image_repository() 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 933, in _upload_vmdk_to_image_repository 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] file_path=%s/%s-flat.vmdk % (self._tmp_folder, random_name)) 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmware_images.py, line 147, in upload_image 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] kwargs.get(file_path)) 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager [instance: 23261217-c2e6-472c-85e9-9afbd708391d] File /usr/lib/python2.6/site-packages/nova/virt/vmwareapi/read_write_util.py, line 164, in __init__ 2014-03-07 03:04:35.477 7213 TRACE nova.compute.manager
[Yahoo-eng-team] [Bug 1353977] Re: VMware vCenter Driver copy_virtual_disk failed with fileType error
Can you please retry with the latest code. If it preoduces lets open
again an address. There has beena ton of changes since last year...
** Changed in: nova
Status: Incomplete = 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/1353977
Title:
VMware vCenter Driver copy_virtual_disk failed with fileType error
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Test Environment:
VMware vCenter version: 5.1
Image: Sparse + ide
Log:
---
2014-08-07 07:49:18.949 25720 WARNING nova.virt.vmwareapi.driver [-] Task
[CopyVirtualDisk_Task] (returnval){
value = task-4469
_type = Task
} status: error A specified parameter was not correct.
fileType
2014-08-07 07:49:18.950 25720 WARNING nova.virt.vmwareapi.error_util [-]
Fault InvalidArgument not matched.
2014-08-07 07:49:18.950 25720 ERROR nova.compute.manager
[req-8f4578d9-834d-4e4d-a309-f4d117cc7a13 None] [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] Instance failed to spawn
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] Traceback (most recent call last):
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2111, in
_build_resources
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] yield resources
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1997, in
_build_and_run_instance
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] block_device_info=block_device_info)
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 643, in
spawn
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] admin_password, network_info,
block_device_info)
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vmops.py, line 399, in
spawn
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] copy_spec)
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/vm_util.py, line 1312,
in copy_virtual_disk
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] session._wait_for_task(vmdk_copy_task)
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 1013, in
_wait_for_task
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] ret_val = done.wait()
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/eventlet/event.py, line 120, in wait
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] return hubs.get_hub().switch()
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] File
/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py, line 187, in switch
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] return self.greenlet.switch()
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] VMwareDriverException: A specified
parameter was not correct.
2014-08-07 07:49:18.950 25720 TRACE nova.compute.manager [instance:
069fc3ba-52cd-44fe-9035-7551d70f2daf] fileType
-
The following code causes this issue. When disk_type is 'sparse' and
adapter_type is 'ide' copy_spec will be set as None.
API CopyVirtualDisk_Task: If destSpec not specified, a preallocated format
and 'busLogic' adapter type is assume. So adapter_type is force modified from
'ide' to 'busLogic'.
from vmops.py
if not is_iso and disk_type == sparse:
# Copy the sparse virtual disk to a thin virtual disk
disk_type = thin
copy_spec = self.get_copy_virtual_disk_spec(client_factory,
adapter_type,
[Yahoo-eng-team] [Bug 1244752] Re: VMwareVCDriver: VSAN datastores cannot be used
This support was added in the K cycle ** Changed in: nova Status: Incomplete = Fix Released -- 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/1244752 Title: VMwareVCDriver: VSAN datastores cannot be used Status in OpenStack Compute (Nova): Fix Released Bug description: Currently the VC driver does not support the use of VSAN datastores as a storage for nova instances. It does not even allow a VSAN datastore to be selected for use. The fix will involve considerable change to how disk images are imported/exported as well as handling a new streamOptimized vmdk file type. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1244752/+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] Core API vs extension: the subnet pool feature
Hi, I am also fine with the shim extension. Thanks Gary On 3/31/15, 1:44 AM, Carl Baldwin c...@ecbaldwin.net wrote: Thanks for your support, Akihiro. We will get this up for review very soon. Carl On Mon, Mar 30, 2015 at 2:59 PM, Akihiro Motoki amot...@gmail.com wrote: Hi Carl, I am now reading the detail from Salvatore, but would like to response this first. I don't want to kill this useful feature too and move the thing forward. I am fine with the empty/shim extension approach. The subnet pool is regarded as a part of Core API, so I think this extension can be always enabled even if no plugin declares to use it. Sorry for interrupting the work at the last stage, and thank for understanding. Akihiro 2015-03-31 5:28 GMT+09:00 Carl Baldwin c...@ecbaldwin.net: Akihiro, If we go with the empty extension you proposed in the patch will that be acceptable? We've got to stop killing new functionality on the very last day like this . It just kills progress. This proposal isn't new. Carl On Mar 30, 2015 11:37 AM, Akihiro Motoki amot...@gmail.com wrote: Hi Neutron folks (API folks may be interested on this) We have another discussion on Core vs extension in the subnet pool feature reivew https://review.openstack.org/#/c/157597/. We did the similar discussion on VLAN transparency and MTU for a network model last week. I would like to share my concerns on changing the core API directly. I hope this help us make the discussion productive. Note that I don't want to discuss the micro-versioning because it mainly focues on Kilo FFE BP. I would like to discuss this topic in today's neutron meeting, but I am not so confident I can get up in time, I would like to send this mail. The extension mechanism in Neutron provides two points for extensibility: - (a) visibility of features in API (users can know which features are available through the API) - (b) opt-in mechanism in plugins (plugin maintainers can decide to support some feature after checking the detail) My concerns mainly comes from the first point (a). If we have no way to detect it, users (including Horizon) need to do a dirty work around to determine whether some feature is available. I believe this is one important point in API. On the second point, my only concern (not so important) is that we are making the core API change at this moment of the release. Some plugins do not consume db_base_plugin and such plugins need to investigate the impact from now on. On the other hand, if we use the extension mechanism all plugins need to update their extension list in the last moment :-( My vote at this moment is still to use an extension, but an extension layer can be a shim. The idea is to that all implementation can be as-is and we just add an extension module so that the new feature is visible thru the extension list. It is not perfect but I think it is a good compromise regarding the first point. I know there was a suggestion to change this into the core API in the spec review and I didn't notice it at that time, but I would like to raise this before releasing it. For longer term (and Liberty cycle), we need to define more clear guideline on Core vs extension vs micro-versioning in spec reviews. Thanks, Akihiro ___ ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki amot...@gmail.com _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1379682] Re: instance_template_name does not work for vmware driver
*** This bug is a duplicate of bug 1330873 *** https://bugs.launchpad.net/bugs/1330873 ** This bug has been marked a duplicate of bug 1330873 Instance name set in horizon is not set in VMware vCenter -- 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/1379682 Title: instance_template_name does not work for vmware driver Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Manuals: Fix Released Bug description: Currently vmware driver will adopt uuid for instance names. This will lead two problems: 1) instance name template will not apply for vmware driver. But it will display instance name with nova show command. It will be misleading. [root@cmwo cmwo]# nova show temp-vm-host1-99 +--+---+ | Property | Value | +--+---+ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | cluster01 | | OS-EXT-SRV-ATTR:host | vcenter-cluster01 | | OS-EXT-SRV-ATTR:hypervisor_hostname | domain-c129(cluster01) | | OS-EXT-SRV-ATTR:instance_name| instance-00ec | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state| - | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2014-10-09T10:02:15.00 | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2014-10-09T09:59:15Z | | demovlan network | 25.0.0.21 | | flavor | m1.tiny (1) | | hostId | 0cfba386e1e5cad832d2fbc316c33ca6a124c3d0b386127a55707070 | | id | 6d3e0f11-0a4c-46eb-a3a6-4e397d917228 | 2) This uuid is not user friendly for VM names. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1379682/+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 1437863] [NEW] API: doing nova list when neutron service is down has an internal error
Public bug reported: nicira@Ubuntu1204Server:~$ nova list ERROR (ClientException): The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-014bcadf-317f-4d2f-b0a0-dbebfc90bedf) The trace from the API is below 2015-03-29 06:50:05.244 ERROR nova.api.openstack [req-014bcadf-317f-4d2f-b0a0-dbebfc90bedf demo demo] Caught error: Unable to establish connection to http://10.0.0.40:9696/v2.0/ports.json?device_id=be9cd6ae-091e-47ba-b3f8-4139b6326df2 2015-03-29 06:50:05.244 TRACE nova.api.openstack Traceback (most recent call last): 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/__init__.py, line 125, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack return req.get_response(self.application) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send 2015-03-29 06:50:05.244 TRACE nova.api.openstack application, catch_exc_info=False) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application 2015-03-29 06:50:05.244 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack return resp(environ, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py, line 634, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack return self._call_app(env, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py, line 554, in _call_app 2015-03-29 06:50:05.244 TRACE nova.api.openstack return self._app(env, _fake_start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack return resp(environ, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack return resp(environ, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/routes/middleware.py, line 136, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack response = self.app(environ, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack return resp(environ, start_response) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func 2015-03-29 06:50:05.244 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/wsgi.py, line 756, in __call__ 2015-03-29 06:50:05.244 TRACE nova.api.openstack content_type, body, accept) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/wsgi.py, line 847, in _process_stack 2015-03-29 06:50:05.244 TRACE nova.api.openstack request, action_args) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/wsgi.py, line 710, in post_process_extensions 2015-03-29 06:50:05.244 TRACE nova.api.openstack **action_args) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/compute/contrib/security_groups.py, line 471, in detail 2015-03-29 06:50:05.244 TRACE nova.api.openstack self._extend_servers(req, list(resp_obj.obj['servers'])) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/compute/contrib/security_groups.py, line 422, in _extend_servers 2015-03-29 06:50:05.244 TRACE nova.api.openstack servers)) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/network/security_group/neutron_driver.py, line 353, in get_instances_security_groups_bindings 2015-03-29 06:50:05.244 TRACE nova.api.openstack ports = self._get_ports_from_server_list(servers, neutron) 2015-03-29 06:50:05.244 TRACE nova.api.openstack File /opt/stack/nova/nova/network/security_group/neutron_driver.py, line 312, in _get_ports_from_server_list 2015-03-29 06:50:05.244 TRACE nova.api.openstack
Re: [openstack-dev] [Neutron] initial OVN testing
Hi, I have added a few comments to the review and have a fixed a few issues that I have encountered along the way. I guess we can discuss on gerrit. Thanks Gary On 3/27/15, 12:54 AM, Russell Bryant rbry...@redhat.com wrote: Gary and Kyle, I saw in my IRC backlog that you guys were briefly talking about testing the Neutron ovn ml2 driver. I suppose it's time to add some more code to the devstack integration to install the current ovn branch and set up ovsdb-server to serve up the right database for this. I'll try to work on that tomorrow. Of course, note that all we can set up right now is the northbound database. None of the code that reacts to updates to that database is merged yet. We can still go ahead and test our code and make sure the expected data makes it there, though. Here's some more detail about the pieces ... When I was writing ovn-nbctl [1], I was testing using ovs-sandbox. It's a script that sets up a handy development environment for ovs. It has ovn support if you pass the -o option [2]. To run it, it would be something like ... $ git clone https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitc h_ovs.gitd=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZ BmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3_L162t5yzwj7_ElFgaXTUhr 2xEDAk0cs=l4rfZ9jttb06ukaHzMgz_RDzsQDjUEf25puSLaKEZZEe= $ cd ovs $ git checkout ovn $ ./boot.sh $ ./configure $ make $ make SANDBOXFLAGS=-o sandbox From there you can run ovn-nbctl. Here's a script to demonstrate the various commands: https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_russe llb_946953e8675063c0c756d=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtX t-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3_L162t5y zwj7_ElFgaXTUhr2xEDAk0cs=vG12ShRj8kDdsQLwzI-4_s0aG41duG-_wlTwR2jWpmke= To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). When running in ovs-sandbox, ovn-nbctl's help output shows: --db=DATABASE connect to DATABASE (default: unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock) and further down, it provides some more detail: Active database connection methods: tcp:IP:PORT PORT at remote IP ssl:IP:PORT SSL PORT at remote IP unix:FILE Unix domain socket named FILE Passive database connection methods: ptcp:PORT[:IP] listen to TCP PORT on IP pssl:PORT[:IP] listen for SSL on PORT on IP punix:FILE listen on Unix domain socket FILE [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_piperm ail_dev_2015-2DMarch_052757.htmld=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3 _L162t5yzwj7_ElFgaXTUhr2xEDAk0cs=NBPDQRkeI_pZKdXfwzZ11QKpjccl2wFKhVZr8rgK KCwe= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_piperm ail_dev_2015-2DMarch_052353.htmld=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3 _L162t5yzwj7_ElFgaXTUhr2xEDAk0cs=36n_EGBEv4v5nS3DoHsBHfgCoJQxXB176pfnHnbt 8eIe= -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Reviews for #164308 - Expand valid server group name character set
On 3/25/15, 10:27 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 3/25/2015 3:01 PM, Jennifer Mulsow wrote: Would anyone be willing to review https://review.openstack.org/#/c/164308/ (Expand valid server group name character set)? It has a few +1s, but there hasn't been any activity on it in a couple days. Thank you, Jennifer Mulsow Cloud Systems Software Development IBM Systems Technology Group _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The mailing list is not a place for requesting reviews, so please don't do it. There are many changes out there [1] so be patient. Patience is a virtue Virtue is a grace Grace is a little girl who did not wash her face [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__russellbryant.net_open stack-2Dstats_nova-2Dopenreviews.htmld=AwICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAX VeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=gGbXW25 u34EN2GJi2Sg9o3WuMOduvWDweBWw6GVk9Mss=lkRiYyVRgwOzneMEaQMyEC_60J2Q89LGopR Ez_QVl2Ye= -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )
On 3/25/15, 3:21 PM, Sean Dague s...@dague.net wrote: On 03/25/2015 09:03 AM, Gary Kotton wrote: From: Jordan Pittier jordan.pitt...@scality.com mailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwIF aQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYB k8YTeq9N3-diTlNj4GyNcm=WR2WbwJKtngJUjJEo4yFahEnv7RtC3NDaDsZFuzSukws=2Jr ZtoZF3o4ThkkR34bJH77FMeEorM65K2FQR9pKSuMe= https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwM FaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JY Bk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5S S-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... This means these systems don't show up in the CI rollup block - https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514 884_screenshot-5F158.pngd=AwIFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNt Xt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=WR2WbwJKtngJUjJEo4 yFahEnv7RtC3NDaDsZFuzSukws=47UEXfmar4lGrIce8bEgHwvws7Lw0DPGWdEzPSDDAXQe = https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_651 4884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMN tXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2 k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8 e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. Right, honestly, I don't want these turned off, I want them reporting in a more standard format. But I do think if they don't report in a standard format it will cause problems and add to them being ignored. Vmware Nova CI has been updated. Please see https://review.openstack.org/#/c/167713/ as an example. -Sean -- Sean Dague https://urldefense.proofpoint.com/v2/url?u=http-3A__dague.netd=AwIFaQc=S qcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9 N3-diTlNj4GyNcm=WR2WbwJKtngJUjJEo4yFahEnv7RtC3NDaDsZFuzSukws=xIhHqi-2NYa hyaoPL1ItksCYtWuk6fTgcobpaGGpjUQe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1436872] [NEW] OVN mechanism driver does not work
Public bug reported: 2015-03-26 07:36:09.617 ERROR neutron.plugins.ml2.managers [req-7e81f1ef-ef9d-4e65-9c75-873c40de95df demo be356f97e093403c9fc2ebed44823a98] Mechanism driver 'ovn' failed in create_network_postcommit 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers Traceback (most recent call last): 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers File /opt/stack/neutron/neutron/plugins/ml2/managers.py, line 323, in _call_on_drivers 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers getattr(driver.obj, method_name)(context) 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers File /usr/local/lib/python2.7/dist-packages/networking_ovn/ml2/mech_driver.py, line 59, in create_network_postcommit 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers network = context.current() 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers TypeError: 'dict' object is not callable 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers ** Affects: networking-ovn Importance: High 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/1436872 Title: OVN mechanism driver does not work Status in Neutron integration for OVN: In Progress Bug description: 2015-03-26 07:36:09.617 ERROR neutron.plugins.ml2.managers [req-7e81f1ef-ef9d-4e65-9c75-873c40de95df demo be356f97e093403c9fc2ebed44823a98] Mechanism driver 'ovn' failed in create_network_postcommit 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers Traceback (most recent call last): 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers File /opt/stack/neutron/neutron/plugins/ml2/managers.py, line 323, in _call_on_drivers 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers getattr(driver.obj, method_name)(context) 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers File /usr/local/lib/python2.7/dist-packages/networking_ovn/ml2/mech_driver.py, line 59, in create_network_postcommit 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers network = context.current() 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers TypeError: 'dict' object is not callable 2015-03-26 07:36:09.617 TRACE neutron.plugins.ml2.managers To manage notifications about this bug go to: https://bugs.launchpad.net/networking-ovn/+bug/1436872/+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] CI report formatting (citrix / hyperv / vmware )
From: Jordan Pittier jordan.pitt...@scality.commailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.netmailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/resulthttps://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.pnghttps://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. What's fair warning to get these systems postings into the standard format? It realistically should be a very quick change by them, but will help quite a lot in reviewing code. -Sean -- Sean Dague http://dague.nethttps://urldefense.proofpoint.com/v2/url?u=http-3A__dague.netd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=zvLmRDIA_kZRg-RYLMhXhNfvNXq3Ni_9LKyJYxD5Nioe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1436462] [NEW] VMware: no validations for CPU levels
Public bug reported: When creating a CPI shar of type pele we get the following exception: 2015-03-25 10:15:44.577 ERROR nova.compute.manager [req-bfe67c3d-0926-4648-8901-027b5912a079 demo demo] [instance: db4c58e7-6606-470d-b315-330528af941a] Error: Error parsing string pele as enum type SharesLevel while parsing serialized value of type vim.SharesInfo.Level at line 10, column 1227 while parsing property level of static type SharesLevel while parsing serialized DataObject of type vim.SharesInfo at line 10, column 1189 while parsing property shares of static type SharesInfo while parsing serialized DataObject of type vim.ResourceAllocationInfo at line 10, column 1109 while parsing property cpuAllocation of static type ResourceAllocationInfo while parsing serialized DataObject of type vim.vm.ConfigSpec at line 1, column 323 while parsing call information for method CreateVM_Task at line 1, column 256 while parsing SOAP body at line 1, column 246 while parsing SOAP envelope at line 1, column 38 while parsing HTTP request for method createVm on object of type vim.Folder at line 1, column 0 Cause: Server raised fault: ' Error parsing string pele as enum type SharesLevel while parsing serialized value of type vim.SharesInfo.Level at line 10, column 1227 while parsing property level of static type SharesLevel while parsing serialized DataObject of type vim.SharesInfo at line 10, column 1189 while parsing property shares of static type SharesInfo while parsing serialized DataObject of type vim.ResourceAllocationInfo at line 10, column 1109 while parsing property shares of static type SharesInfo while parsing serialized DataObject of type vim.ResourceAllocationInfo at line 10, column 1109 while parsing property cpuAllocation of static type ResourceAllocationInfo while parsing serialized DataObject of type vim.vm.ConfigSpec at line 1, column 323 while parsing call information for method CreateVM_Task at line 1, column 256 while parsing SOAP body at line 1, column 246 while parsing SOAP envelope at line 1, column 38 while parsing HTTP request for method createVm on object of type vim.Folder at line 1, column 0' Faults: [InvalidRequest] ** Affects: nova Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress ** 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/1436462 Title: VMware: no validations for CPU levels Status in OpenStack Compute (Nova): In Progress Bug description: When creating a CPI shar of type pele we get the following exception: 2015-03-25 10:15:44.577 ERROR nova.compute.manager [req-bfe67c3d-0926-4648-8901-027b5912a079 demo demo] [instance: db4c58e7-6606-470d-b315-330528af941a] Error: Error parsing string pele as enum type SharesLevel while parsing serialized value of type vim.SharesInfo.Level at line 10, column 1227 while parsing property level of static type SharesLevel while parsing serialized DataObject of type vim.SharesInfo at line 10, column 1189 while parsing property shares of static type SharesInfo while parsing serialized DataObject of type vim.ResourceAllocationInfo at line 10, column 1109 while parsing property cpuAllocation of static type ResourceAllocationInfo while parsing serialized DataObject of type vim.vm.ConfigSpec at line 1, column 323 while parsing call information for method CreateVM_Task at line 1, column 256 while parsing SOAP body at line 1, column 246 while parsing SOAP envelope at line 1, column 38 while parsing HTTP request for method createVm on object of type vim.Folder at line 1, column 0 Cause: Server raised fault: ' Error parsing string pele as enum type SharesLevel while parsing serialized value of type vim.SharesInfo.Level at line 10, column 1227 while parsing property level of static type SharesLevel while parsing serialized DataObject of type vim.SharesInfo at line 10, column 1189 while parsing property shares of static type SharesInfo while parsing serialized DataObject of type vim.ResourceAllocationInfo at line 10, column 1109 while parsing property shares of static type SharesInfo while parsing serialized DataObject of type vim.ResourceAllocationInfo at line 10, column 1109 while parsing property cpuAllocation of static type ResourceAllocationInfo while parsing serialized DataObject of type vim.vm.ConfigSpec at line 1, column 323 while parsing call information for method CreateVM_Task at line 1, column 256 while parsing SOAP body at line 1, column 246 while parsing SOAP envelope at line 1, column 38 while parsing HTTP request for method createVm on object of type vim.Folder at line 1, column 0' Faults: [InvalidRequest] To manage notifications about this bug go to: https
Re: [OpenStack-Infra] [openstack-dev] Gerrit downtime on 2015-03-21
Please see http://lists.openstack.org/pipermail/openstack-infra/2015-February/002425.h tml That should explain. On 3/23/15, 8:53 AM, trinath.soman...@freescale.com trinath.soman...@freescale.com wrote: Hi- The Issue is resolved. Its an update to the NEW IP address of Gerrit. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: trinath.soman...@freescale.com [mailto:trinath.soman...@freescale.com] Sent: Monday, March 23, 2015 11:57 AM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-infra@lists.openstack.org Subject: Re: [OpenStack-Infra] [openstack-dev] Gerrit downtime on 2015-03-21 Hi- I get this error from my CI Zuul debug Log. 2015-03-23 12:16:45,618 ERROR gerrit.GerritWatcher: Exception on ssh event stream: Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/zuul/lib/gerrit.py, line 64, in _run key_filename=self.keyfile) File /usr/local/lib/python2.7/dist-packages/paramiko/client.py, line 236, in connect retry_on_signal(lambda: sock.connect(addr)) File /usr/local/lib/python2.7/dist-packages/paramiko/util.py, line 278, in retry_on_signal return function() File /usr/local/lib/python2.7/dist-packages/paramiko/client.py, line 236, in lambda retry_on_signal(lambda: sock.connect(addr)) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 111] Connection refused Kindly help me resolve the issue. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: James E. Blair [mailto:cor...@inaugust.com] Sent: Saturday, March 21, 2015 9:46 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-infra@lists.openstack.org Subject: Re: [openstack-dev] Gerrit downtime on 2015-03-21 cor...@inaugust.com (James E. Blair) writes: Hi, Gerrit will be unavailable for a few hours starting at 1500 UTC on Saturday, March 21. Gerrit is up and running on the new server. Actual downtime was about 1 hour from 1500 to 1600. Please let us know either here or on Freenode in #openstack-infra if you notice any problems. -Jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [openstack-dev] Gerrit downtime on 2015-03-21
Please see http://lists.openstack.org/pipermail/openstack-infra/2015-February/002425.h tml That should explain. On 3/23/15, 8:53 AM, trinath.soman...@freescale.com trinath.soman...@freescale.com wrote: Hi- The Issue is resolved. Its an update to the NEW IP address of Gerrit. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: trinath.soman...@freescale.com [mailto:trinath.soman...@freescale.com] Sent: Monday, March 23, 2015 11:57 AM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-in...@lists.openstack.org Subject: Re: [OpenStack-Infra] [openstack-dev] Gerrit downtime on 2015-03-21 Hi- I get this error from my CI Zuul debug Log. 2015-03-23 12:16:45,618 ERROR gerrit.GerritWatcher: Exception on ssh event stream: Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/zuul/lib/gerrit.py, line 64, in _run key_filename=self.keyfile) File /usr/local/lib/python2.7/dist-packages/paramiko/client.py, line 236, in connect retry_on_signal(lambda: sock.connect(addr)) File /usr/local/lib/python2.7/dist-packages/paramiko/util.py, line 278, in retry_on_signal return function() File /usr/local/lib/python2.7/dist-packages/paramiko/client.py, line 236, in lambda retry_on_signal(lambda: sock.connect(addr)) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 111] Connection refused Kindly help me resolve the issue. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: James E. Blair [mailto:cor...@inaugust.com] Sent: Saturday, March 21, 2015 9:46 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-in...@lists.openstack.org Subject: Re: [openstack-dev] Gerrit downtime on 2015-03-21 cor...@inaugust.com (James E. Blair) writes: Hi, Gerrit will be unavailable for a few hours starting at 1500 UTC on Saturday, March 21. Gerrit is up and running on the new server. Actual downtime was about 1 hour from 1500 to 1600. Please let us know either here or on Freenode in #openstack-infra if you notice any problems. -Jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [infra] git review
Hi, Any idea when this will be up and running again: gkotton@ubuntu:~/nova$ git review Problem running 'git remote update gerrit' Fetching gerrit ssh: connect to host review.openstack.org port 29418: Network is unreachable fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. error: Could not fetch gerrit Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron extenstions
support it turns out some more modes are required, and we decided to change the subnet core resource. It is the exception. Thanks, Akihiro 2015-03-20 8:23 GMT+09:00 Armando M. arma...@gmail.commailto:arma...@gmail.com: Forwarding my reply to the other thread here: If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: an opt-in approach: this means we know the expected behavior of the plugin as someone has coded the plugin in such a way that the API change is supported; an opt-out approach: if the API change does not require explicit backend support, and hence can be deemed supported by all plugins. a 'core' extension (ones available in neutron/extensions) should be implemented at least by the reference implementation; Now, there might have been examples in the past where criteria were not met, but these should be seen as exceptions rather than the rule, and as such, fixed as defects so that an attribute/resource/operation that is accidentally exposed to a plugin will either be honored as expected or an appropriate failure is propagated to the user. Bottom line, the server must avoid to fail silently, because failing silently is bad for the user. Now both features [1] and [2] violated the opt-in criterion above: they introduced resources attributes in the core models, forcing an undetermined behavior on plugins. I think that keeping [3,4] as is can lead to a poor user experience; IMO it's unacceptable to let a user specify the attribute, and see that ultimately the plugin does not support it. I'd be fine if this was an accident, but doing this by design is a bit evil. So, I'd suggest the following, in order to keep the features in Kilo: Patches [3, 4] did introduce config flags to control the plugin behavior, but it looks like they were not applied correctly; for instance, the vlan_transparent case was only applied to ML2. Similarly the MTU config flag was not processed server side to ensure that plugins that do not support advertisement do not fail silently. This needs to be rectified. As for VLAN transparency, we'd need to implement work item 5 (of 6) of spec [2], as this extension without at least a backend able to let tagged traffic pass doesn't seem right. Ensure we sort out the API tests so that we know how the features behave. Now granted that controlling the API via config flags is not the best solution, as this was always handled through the extension mechanism, but since we've been talking about moving away from extension attributes with [5], it does sound like a reasonable stop-gap solution. Thoughts? Armando [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html [2] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html [3] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z [4] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z [5] https://review.openstack.org/#/c/136760/ On 19 March 2015 at 14:56, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: On 19 March 2015 at 11:44, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, Just the fact that we did this does not make it right. But I guess that we are starting to bend the rules. I think that we really need to be far more diligent about this kind of stuff. Having said that we decided the following on IRC: 1. Mtu will be left in the core (all plugins should be aware of this and treat it if necessary) 2. Vlan-transparency will be moved to an extension. Pritesh is working on this. The spec started out as an extension, and in its public review people requested that it not be an extension and that it should instead be core. I accept that we can change our minds, but I believe there should be a good reason for doing so. You haven't given that reason here and you haven't even said who the 'we' is that decided this. Also, as the spec author, I had a conversation with you all but there was no decision at the end of it (I presume that came afterward) and I feel that I have a reasonable right to be involved. Could you at least summarise your reasoning here? I admit that I prefer this to be in core, but I'm not terribly choosy and that's not why I'm asking. I'm more concerned that this is changing our mind at literally the last moment, and in turn wasting a developer's time, when there was a perfectly good process to debate this before coding was begun, and again when the code was up for review, both of which apparently failed. I'd like to understand how we avoid getting here again in the future. I'd also like to be certain we are not simply reversing a choice on a whim. -- Ian
Re: [openstack-dev] [oslo][cinder][nova][neutron] going forward to oslo-config-generator ...
Hi, One of the issues that we had in Nova was that when we moved to oslo libraries configuration options support by the libraries were no longer present in the generated configuration file. Is this something that is already supported or planned (sorry for being a little ignorant here). In neutron things may be a little more challenging as there are many different plugins and with the decomposition things may have additional challenges. The configuration binding is done via the external decomposed code and not in the neutron code base. So it is not clear how that code may be parsed to generate the sample configuration. Thanks Gary On 3/21/15, 12:01 AM, Jay S. Bryant jsbry...@electronicjungle.net wrote: All, Let me start with the TLDR; Cinder, Nova and Neutron have lots of configuration options that need to be processed by oslo-config-generator to create the project.conf.sample file. There are a couple of different ways this could be done. I have one proposal out, which has raised concerns, there is a second approach that could be taken which I am proposing below. Please read on if you have a strong opinion on the precedent we will try to set in Cinder. :-) We discussed in the oslo meeting a couple of weeks ago a plan for how Cinder was going to blaze a trail to the new oslo-config-generator. The result of that discussion and work is here: [1] It needs some more work but has the bare bones pieces there to move to using oslo-config-generator. With the change I have written extensive hacking checks that ensure that any lists that are registered with register_opts() are included in the base cinder/opts.py file that is then a single entry point that pulls all of the options together to generate the cinder.conf.sample file. This has raised concern, however, that whenever a developer adds a new list of configuration options, they are going to have to know to go back to cinder/opts.py and add their module and option list there. The hacking check should catch this before code is submitted, but we are possibly setting ourselves up for cases where the patch will fail in the gate because updates are not made in all the correct places and because pep8 isn't run before the patch is pushed. It is important to note, that this will not happen every time a configuration option is changed or added, as was the case with the old check-uptodate.sh script. Only when a new list of configuration options is added which is a much less likely occurrence. To avoid this happening at all it was proposed by the Cinder team that we use the code I wrote for the hacking checks to dynamically go through the files and create cinder/opts.py whenever 'tox -egenconfig' is run. Doing this makes me uncomfortable as it is not consistent with anything else I am familiar with in OpenStack and is not consistent with what other projects are doing to handle this problem. In discussion with Doug Hellman, the approach also seemed to cause him concern. So, I don't believe that is the right solution. An alternative that may be a better solution was proposed by Doug: We could even further reduce the occurrence of such issues by moving the list_opts() function down into each driver and have an entry point for oslo.config.opts in setup.cfg for each of the drivers. As with the currently proposed solution, the developer doesn't have to edit a top level file for a new configuration option. This solution adds that the developer doesn't have to edit a top level file to add a new configuration item list to their driver. With this approach the change would happen in the driver's list_opts() function, rather than in cinder/opts.py . The only time that setup.cfg would needed to edited is when a new package is added or when a new driver is added. This would reduce some of the already minimal burden on the developer. We, however, would need to agree upon some method for aggregating together the options lists on a per package (i.e. cinder.scheduler, cinder.api) level. This approach, however, also has the advantage of providing a better indication in the sample config file of where the options are coming from. That is an improvement over what I have currently proposed. Does Doug's proposal sound more agreeable to everyone? It is important to note that the fact that some manual intervention is required to 'plumb' in the new configuration options was done by design. There is a little more work required to make options available to oslo-config-generator but the ability to use different namespaces, different sample configs, etc were added with the new generator. These additional capabilities were requested by other projects. So, moving to this design does have the potential for more long-term gain. Thanks for taking the time to consider this! Jay [1] https://review.openstack.org/#/c/165431/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Neutron] VLAN transparency support
Hi, So at the moment we have something that is half baked. Say we take the MTU support as an example: There is a configuration flag ‘advertise_mtu’ (the default value is False) – this is set by an admin, but a tenant can define the mtu setting when creating a network. So by default the tenant setting are ignored. So I suggest the following: 1. https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py#L697 * we do a convert_to': convert_to_int (if someone passes any other type here it will break the dnsmasq * We add in another validation that checks against the configuration. It should throw an exception if the tenant has set an MTU and the admin has not set the advertise_mtu flag We can take the similar approach to the ‘vlan_transparent’ but I have no idea what that actually means as part of the API. I am really not in favor of this even being in core. Thanks Gary From: Armando M. arma...@gmail.commailto:arma...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, March 20, 2015 at 12:33 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: * an opt-in approach: this means we know the expected behavior of the plugin as someone has coded the plugin in such a way that the API change is supported; * an opt-out approach: if the API change does not require explicit backend support, and hence can be deemed supported by all plugins. * a 'core' extension (ones available in neutron/extensions) should be implemented at least by the reference implementation; Now, there might have been examples in the past where criteria were not met, but these should be seen as exceptions rather than the rule, and as such, fixed as defects so that an attribute/resource/operation that is accidentally exposed to a plugin will either be honored as expected or an appropriate failure is propagated to the user. Bottom line, the server must avoid to fail silently, because failing silently is bad for the user. Now both features [1] and [2] violated the opt-in criterion above: they introduced resources attributes in the core models, forcing an undetermined behavior on plugins. I think that keeping [3,4] as is can lead to a poor user experience; IMO it's unacceptable to let a user specify the attribute, and see that ultimately the plugin does not support it. I'd be fine if this was an accident, but doing this by design is a bit evil. So, I'd suggest the following, in order to keep the features in Kilo: * Patches [3, 4] did introduce config flags to control the plugin behavior, but it looks like they were not applied correctly; for instance, the vlan_transparent case was only applied to ML2. Similarly the MTU config flag was not processed server side to ensure that plugins that do not support advertisement do not fail silently. This needs to be rectified. * As for VLAN transparency, we'd need to implement work item 5 (of 6) of spec [2], as this extension without at least a backend able to let tagged traffic pass doesn't seem right. * Ensure we sort out the API tests so that we know how the features behave. Now granted that controlling the API via config flags is not the best solution, as this was always handled through the extension mechanism, but since we've been talking about moving away from extension attributes with [5], it does sound like a reasonable stop-gap solution. Thoughts? Armando [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html [2] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html [3] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z [4] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z [5] https://review.openstack.org/#/c/136760/ On 19 March 2015 at 12:01, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually = the supported MTU on the network. I did not see this in the code (maybe I missed something). From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 8:44 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Per the other discussion on attributes, I believe the change walks
[openstack-dev] [Neutron] VLAN transparency support
Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN transparency support
Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron extenstions
Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes - mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron extenstions
Hi, Until now all changes to the API’s have been made in separate extensions and not in the base. These should actually be on the provider networks extension. First this code is not supported by any of the plugins other than the ML2 (I am not sure if this break things – it certain broke the unit tests). Secondly these two changes do not have open source reference implementations (but that is digressing from the problem). I really think that we need to revert these and have the extensions done in the standard fasion. Thanks Gary From: Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 6:20 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Neutron extenstions Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just always be on? Thanks, Brandon From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Sent: Thursday, March 19, 2015 11:01 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Neutron extenstions Hi Gary, First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a stricter standard on that? Thanks, doug On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes – mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN transparency support
With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually = the supported MTU on the network. I did not see this in the code (maybe I missed something). From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 8:44 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC: - backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, which should have been implemented in the patches (otherwise I will downvote the patch myself) - behaviour should be as before with the additional feature that you can now tell more about what the plugin is thinking - whether they should be core or an extension - this is a more personal opinion, but on the grounds that all networks are either trunks or not, and all networks have MTUs, I think they do want to be core. I would like to see plugin developers strongly encouraged to consider what they can do on both elements, whereas an extension tends to sideline functionality from view so that plugin writers don't even know it's there for consideration. Aside from that, I'd like to emphasise the value of these patches, so hopefully we can find a way to get them in in some form in this cycle. I admit I'm interested in them because they make it easier to do NFV. But they also help normal cloud users and operators, who otherwise have to do some really strange things [1]. I think it's maybe a little unfair to post reversion patches before discussion, particularly when the patch works, passes tests and implements an approved spec correctly. -- Ian. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1138958d=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=NzYY0bOpToH9ZNwzqI_SpQHiPFRXD_nfb1bM3qAw7Css=FlF57GYJqeWgx5ivxnK5kfWlyTIc1ZFbdlXoi2cfdhwe= (admittedly first link I found, but there's no shortage of them) On 19 March 2015 at 05:32, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron extenstions
Hi, Just the fact that we did this does not make it right. But I guess that we are starting to bend the rules. I think that we really need to be far more diligent about this kind of stuff. Having said that we decided the following on IRC: 1. Mtu will be left in the core (all plugins should be aware of this and treat it if necessary) 2. Vlan-transparency will be moved to an extension. Pritesh is working on this. Thanks Gary On 3/19/15, 8:30 PM, Sean M. Collins s...@coreitpro.com wrote: On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote: There are precedents for this. For example, the attributes that currently exist for IPv6 advertisement are very similar: I'll also note that the API changes landed in Icehouse, but the implementation missed the Icehouse deadline and was landed in Juno, so for a time the attributes were hidden from users. https://review.openstack.org/#/c/85869/ -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Kilo FeatureFreeze is March 19th, FeatureProposalFreeze has happened
Hi, Not 100% sure that I understand. This is for the BP¹s and specs that were approved for Kilo. Bug fixes if I understand are going to be reviewed until the release of Kilo. Is launchpad not a sufficient source for highlighting bugs? Thanks Gary On 3/11/15, 2:13 PM, John Garbutt j...@johngarbutt.com wrote: Hi, Just a quick update on where we are at with the release: https://wiki.openstack.org/wiki/Kilo_Release_Schedule Please help review all the code we want to merge before FeatureFreeze: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking https://launchpad.net/nova/+milestone/kilo-3 Please note, 19th March is: kilo-3 release, General FeatureFreeze, StringFreeze, DepFreeze (that includes all high priority items) Generally patches that don't look likely to merge by 19th March are likely to get deferred around 17th March, to make sure we get kilo-3 out the door. As ever, there may be exceptions, if we really need them, but they will have to be reviewed by ttx for their impact on the overall integrated release of kilo. More details will be shared nearer the time. A big ask at this time, is to highlight any release critical bugs that we need to fixe before we can release kilo (and that involves testing things). We are likely to use the kilo-rc-potential tag to track those bugs, more details on that soon. Any questions, please do ask (here or on IRC). Thanks, johnthetubaguy PS Just a reminder you are now free to submit specs for liberty. Specs where there is no clear agreement will be the best candidates for a discussion slot at the summit. Again more on that later. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [vmware] Alternate meeting times
Hi, As mentioned a few weeks ago we would like to have alternate meeting times for the Vmware driver(s) meeting. So for all interested lets meet tomorrow at 10:00 UTC on #openstack-meeting-4. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote: On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Agree 100% Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━ ━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━ ━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here
Re: [openstack-dev] [neutron] Proposal to add Ihar Hrachyshka as a Neutron Core Reviewer
+100Š.000 Very long overdue! On 3/4/15, 10:23 PM, Maru Newby ma...@redhat.com wrote: +1 from me, Ihar has been doing great work and it will be great to have him finally able to merge! On Mar 4, 2015, at 11:42 AM, Kyle Mestery mest...@mestery.com wrote: I'd like to propose that we add Ihar Hrachyshka to the Neutron core reviewer team. Ihar has been doing a great job reviewing in Neutron as evidence by his stats [1]. Ihar is the Oslo liaison for Neutron, he's been doing a great job keeping Neutron current there. He's already a critical reviewer for all the Neutron repositories. In addition, he's a stable maintainer. Ihar makes himself available in IRC, and has done a great job working with the entire Neutron team. His reviews are thoughtful and he really takes time to work with code submitters to ensure his feedback is addressed. I'd also like to again remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out and reinforce that +1/-1 reviews are super useful, and I encourage everyone to continue reviewing code across Neutron as well as the other OpenStack projects, regardless of your status as a core reviewer on these projects. Existing Neutron cores, please vote +1/-1 on this proposal to add Ihar to the core reviewer team. Thanks! Kyle [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_repo rt_contribution_neutron-2Dgroup_90d=AwICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVe Aw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=Ai-ZNicr eqkmcjZEmVtR4ztEWETwC-yUThK_vJ_vFtcs=QOgsZ0G74PZQYC8kvsozIDeWHYMn7t_Rk6p zqBLFui0e= _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic
Hi, I am just relaying pain-points that we encountered in neutron. As I have said below it makes the development process a lot quicker for people working on external drivers. I personally believe that it fragments the community and feel that the external drivers loose the community contributions and inputs. Thanks Gary On 2/28/15, 7:58 PM, Clint Byrum cl...@fewbar.com wrote: I'm not sure I understand your statement Gary. If Ironic defines what is effectively a plugin API, and the vendor drivers are careful to utilize that API properly, the two sets of code can be released entirely independent of one another. This is how modules work in the kernel, X.org drivers work, and etc. etc. Of course, vendors could be irresponsible and break compatibility with older releases of Ironic, but that is not in their best interest, so I don't see why anybody would need to tightly couple. As far as where generic code goes, that seems obvious: it all has to go into Ironic and be hidden behind the plugin API. Excerpts from Gary Kotton's message of 2015-02-28 09:28:55 -0800: Hi, There are pros and cons for what you have mentioned. My concern, and I mentioned them with the neutron driver decomposition, is that we are are loosing the community inputs and contributions. Yes, one can certainly move faster and freer (which is a huge pain point in the community). How are generic code changes percolated to your repo? Do you have an automatic CI that detects this? Please note that when itonic release you will need to release your repo so that the relationship is 1:1... Thanks Gary From: Ramakrishnan G rameshg87.openst...@gmail.commailto:rameshg87.openst...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o rg Date: Saturday, February 28, 2015 at 8:28 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o rg Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic Hello All, This is about adding vendor drivers in Ironic. In Kilo, we have many vendor drivers getting added in Ironic which is a very good thing. But something I noticed is that, most of these reviews have lots of hardware-specific code in them. This is something most of the other Ironic folks cannot understand unless they go and read the hardware manuals of the vendor hardware about what is being done. Otherwise we just need to blindly mark the file as reviewed. Now let me pitch in with our story about this. We added a vendor driver for HP Proliant hardware (the *ilo drivers in Ironic). Initially we proposed this same thing in Ironic that we will add all the hardware specific code in Ironic itself under the directory drivers/modules/ilo. But few of the Ironic folks didn't agree on this (Devananda especially who is from my company :)). So we created a new module proliantutils, hosted in our own github and recently moved it to stackforge. We gave a limited set of APIs for Ironic to use - like get_host_power_status(), set_host_power(), get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforg e_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwICAgc=Sq cl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9 N3-diTlNj4GyNcm=QRyrevJwoHB6GFxiTDorDRShZ79rnf-SwtdVwGiYfccs=e9_q3eOLqT eI3oNwT_0fur3qzpFLUy9wxVPEjujfAMse= https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor ge_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwMFaQc=S qcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq 9N3-diTlNj4GyNcm=m5_FxZnmz3 cyIvavSV DImH6xLR79L-svbcYKkjdcnb8s=fjlOB2ORYcne-cyYnZJO8bdpi4J8rbfCAbmciPllmFIe= ). We have only seen benefits in doing it. Let me bring in some examples: 1) We tried to add support for some lower version of servers. We could do this without making any changes in Ironic (Review in proliantutils https://review.openstack.org/#/c/153945/) 2) We are adding support for newer models of servers (earlier we use to talk to servers in protocol called RIBCL, newer servers we will use a protocol called RIS) - We could do this with just 14 lines of actual code change in Ironic (this was needed mainly because we didn't think we will have to use a new protocol itself when we started) - https://review.openstack.org/#/c/154403/ Now talking about the advantages of putting hardware-specific code in Ironic: 1) It's reviewed by Openstack community and tested: No. I doubt if I throw in 600 lines of new iLO specific code that is here (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor ge_proliantutils_blob_master_proliantutils_ilo_ris.pyd=AwICAgc=Sqcl0Ez6 M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diT lNj4GyNcm=QRyrevJwoHB6GFxiTDorDRShZ79rnf-SwtdVwGiYfccs=tEA3ZOH2Gu6GxHBG PfPB0x9LeHuMcYAcDbqbQyPVHZAe=
Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic
Hi, There are pros and cons for what you have mentioned. My concern, and I mentioned them with the neutron driver decomposition, is that we are are loosing the community inputs and contributions. Yes, one can certainly move faster and freer (which is a huge pain point in the community). How are generic code changes percolated to your repo? Do you have an automatic CI that detects this? Please note that when itonic release you will need to release your repo so that the relationship is 1:1... Thanks Gary From: Ramakrishnan G rameshg87.openst...@gmail.commailto:rameshg87.openst...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Saturday, February 28, 2015 at 8:28 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic Hello All, This is about adding vendor drivers in Ironic. In Kilo, we have many vendor drivers getting added in Ironic which is a very good thing. But something I noticed is that, most of these reviews have lots of hardware-specific code in them. This is something most of the other Ironic folks cannot understand unless they go and read the hardware manuals of the vendor hardware about what is being done. Otherwise we just need to blindly mark the file as reviewed. Now let me pitch in with our story about this. We added a vendor driver for HP Proliant hardware (the *ilo drivers in Ironic). Initially we proposed this same thing in Ironic that we will add all the hardware specific code in Ironic itself under the directory drivers/modules/ilo. But few of the Ironic folks didn't agree on this (Devananda especially who is from my company :)). So we created a new module proliantutils, hosted in our own github and recently moved it to stackforge. We gave a limited set of APIs for Ironic to use - like get_host_power_status(), set_host_power(), get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=m5_FxZnmz3cyIvavSVDImH6xLR79L-svbcYKkjdcnb8s=fjlOB2ORYcne-cyYnZJO8bdpi4J8rbfCAbmciPllmFIe=). We have only seen benefits in doing it. Let me bring in some examples: 1) We tried to add support for some lower version of servers. We could do this without making any changes in Ironic (Review in proliantutils https://review.openstack.org/#/c/153945/) 2) We are adding support for newer models of servers (earlier we use to talk to servers in protocol called RIBCL, newer servers we will use a protocol called RIS) - We could do this with just 14 lines of actual code change in Ironic (this was needed mainly because we didn't think we will have to use a new protocol itself when we started) - https://review.openstack.org/#/c/154403/ Now talking about the advantages of putting hardware-specific code in Ironic: 1) It's reviewed by Openstack community and tested: No. I doubt if I throw in 600 lines of new iLO specific code that is here (https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_ris.pyd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=m5_FxZnmz3cyIvavSVDImH6xLR79L-svbcYKkjdcnb8s=vYNQ8MopljQOqje3T_aIhtw0oZPK4tFHGnlcbBH6wace=) for Ironic folks, they will hardly take a look at it. And regarding testing, it's not tested in the gate unless we have a 3rd party CI for it. [We (iLO drivers) also don't have 3rd party CI right now, but we are working on it.] 2) Everything gets packaged into distributions automatically: Now the hardware-specific code that we add in Ironic under drivers/modules/vendor/ will get packaged into distributions, but this code in turn will have dependencies which needs to be installed manually by the operator (I assume vendor specific dependencies are not considered by Linux distributions while packaging Openstack Ironic). Anyone installing Ironic and wanting to manage my company's servers will again need to install these dependencies manually. Why not install the wrapper if there is one too. I assume we only get these advantages by moving all of hardware-specific code to a wrapper module in stackforge and just exposing some APIs for Ironic to use: * Ironic code would be much cleaner and easier to maintain * Any changes related to your hardware - support for newer hardware, bug fixes in particular models of hardware, would be very easy. You don't need to change Ironic code for that. You could just fix the bug in your module, release a new version
[openstack-dev] [nova] Shared storage support
Hi, There is an issue with the statistics reported when a nova compute driver has shared storage attached. That is, there may be more than one compute node reporting on the shared storage. A patch has been posted - https://review.openstack.org/#/c/155184. The direction here was to add a extra parameter to the dictionary that the driver returns for the resource utilization. The DB statistics calculation would take this into account and then do calculations accordingly. I am not really in favor of the approach for a number of reasons: 1. Over the last few cycles we have been making a move to trying to better define data structures and models that we use. More specifically we have been moving to object support 2. A change in the DB layer may break this support. 3. We are trying to have versioning of various blobs of data that are passed around My thinking is that the resource tracker should be aware that the compute node has shared storage and the changes done there. I do not think that the compute node should rely on the changes being done in the DB layer - that may be on a different host and even run a different version. I understand that this is a high or critical bug but I think that we need to discuss more on it and try have a more robust model. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute
On 2/23/15, 2:05 PM, Matthew Booth mbo...@redhat.com wrote: On 20/02/15 11:48, Matthew Booth wrote: Gary Kotton came across a doozy of a bug recently: https://bugs.launchpad.net/nova/+bug/1419785 In short, when you start a Nova compute, it will query the driver for instances and compare that against the expected host of the the instance according to the DB. If the driver is reporting an instance the DB thinks is on a different host, it assumes the instance was evacuated while Nova compute was down, and deletes it on the hypervisor. However, Gary found that you trigger this when starting up a backup HA node which has a different `host` config setting. i.e. You fail over, and the first thing it does is delete all your instances. Gary and I both agree on a couple of things: 1. Deleting all your instances is bad 2. HA nova compute is highly desirable for some drivers We disagree on the approach to fixing it, though. Gary posted this: https://review.openstack.org/#/c/154029/ I've already outlined my objections to this approach elsewhere, but to summarise I think this fixes 1 symptom of a design problem, and leaves the rest untouched. If the value of nova compute's `host` changes, then the assumption that instances associated with that compute can be identified by the value of instance.host becomes invalid. This assumption is pervasive, so it breaks a lot of stuff. The worst one is _destroy_evacuated_instances(), which Gary found, but if you scan nova/compute/manager for the string 'self.host' you'll find lots of them. For example, all the periodic tasks are broken, including image cache management, and the state of ResourceTracker will be unusual. Worse, whenever a new instance is created it will have a different value of instance.host, so instances running on a single hypervisor will become partitioned based on which nova compute was used to create them. In short, the system may appear to function superficially, but it's unsupportable. I had an alternative idea. The current assumption is that the `host` managing a single hypervisor never changes. If we break that assumption, we break Nova, so we could assert it at startup and refuse to start if it's violated. I posted this VMware-specific POC: https://review.openstack.org/#/c/154907/ However, I think I've had a better idea. Nova creates ComputeNode objects for its current configuration at startup which, amongst other things, are a map of host:hypervisor_hostname. We could assert when creating a ComputeNode that hypervisor_hostname is not already associated with a different host, and refuse to start if it is. We would give an appropriate error message explaining that this is a misconfiguration. This would prevent the user from hitting any of the associated problems, including the deletion of all their instances. I have posted a patch implementing the above for review here: https://review.openstack.org/#/c/158269/ I have to look at what you have posted. I think that this topic is something that we should speak about at the summit and this should fall under some BP and well defined spec. I really would not like to see existing installations being broken if and when this patch lands. It may also affect Ironic as it works on the same model. 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Priority tracking
Just for a few clarifications: 1. The link below is for the nova priority tracking 2. It was requested that we do not add bug fixes to that list. There are other tracking tools for that 3. The list does have a Quick/Trivial Hit Bugs. Please read the description before you start to add to that list. Feel free to reach out to the guys who regularly contribute to this list if you feel that you want to dive in A luta continua Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, February 23, 2015 at 2:19 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] Priority tracking Hi, Not sure if everyone is aware of this. There is a ether pad where the priority of the project appears: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking. This has the major bullets for the K cycle. So in short - if you reviews are not on the page they may not get review cycles :) Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Priority tracking
Hi, Not sure if everyone is aware of this. There is a ether pad where the priority of the project appears: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking. This has the major bullets for the K cycle. So in short - if you reviews are not on the page they may not get review cycles :) Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] LOG.debug()
Hi, Please see http://docs.openstack.org/openstack-ops/content/logging_monitoring.html If you have installed from packages this may be in /var/log/nova/nova-compute.log Thanks Gary From: Vedsar Kushwaha vedsarkushw...@gmail.commailto:vedsarkushw...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, February 18, 2015 at 4:52 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] LOG.debug() Hello World, I'm new to openstack and python too :). In the file: https://github.com/openstack/nova/blob/master/nova/scheduler/filters/ram_filter.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_master_nova_scheduler_filters_ram-5Ffilter.pyd=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=DJEz4nE1qVf12YKxUwG0LN0yBMtl3warl36Oqq4Vqpos=ONUtXkRDFMM8mfVHff8Fc3zFe9AdJohiOZBUe7P6P3Ie= where does the LOG.debug() is storing the information? -- Vedsar Kushwaha M.Tech-Computational Science Indian Institute of Science __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1402509] Re: vmware with Distribute VirtualSwitch
Please see https://review.openstack.org/154771 for the initial implementation ** Changed in: nova Status: Incomplete = 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/1402509 Title: vmware with Distribute VirtualSwitch Status in OpenStack Compute (Nova): Invalid Bug description: I have two hosts in one vcenter cluster use Distribute VirtualSwitch. Before I launch a instance,i need add port_group first. why not add port_group in nova if the port_group is not exist, and how i can do it. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1402509/+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] Feature Freeze Exception for vmware-driver-domain-metadata
Retitled From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Saturday, February 14, 2015 at 8:01 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] FFE request for vmware-driver-domain-metadata Hi, This support was added to the libvirt driver in J. The support is isolated to the Vmware driver and enables admins to get a better understanding of what is happening with the running instances. Any chance of getting a sponsor for this? https://review.openstack.org/#/c/141028/ This also enables the admin to do queries on the VC about instances, for example by AZ, flavor, etc. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Use of egg snapshots of neutron code in neutron-*aas projects/distributing openstack
Hi, The same issue is the for the backe end drivers. I think that they always need to be aligned with the master branch. When we cut stable all of the aaS and drivers also need to be cut. This was one of the pain points that we brought up with the split and the consensus was: we¹ll deal with it when we get to the bridge. Thanks Gary On 2/16/15, 5:13 PM, James Page james.p...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Folks The split-out drivers for vpn/fw/lb as-a-service all make use of a generated egg of the neutron git repository as part of their unit test suite dependencies. This presents a bit of a challenge for us downstream in distributions, as we can't really pull in a full source egg of neutron from git.openstack.org; we have the code base for neutron core available (python-neutron), but that does not appear to be enough (see [0]). I would appreciate if dev's working in this area could a) review the bug and the problems we are seeing a b) think about how this can work for distributions - I'm happy to create a new 'neutron-testing' type package from the neutron codebase to support this stuff, but right now I'm a bit unclear on exactly what its needs to contain! Cheers James [0] https://bugs.launchpad.net/neutron/+bug/1422376 - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU4gj5AAoJEL/srsug59jD5agP/1NFgrLQjD7+d0OrxSByD+b0 DEwlbSwFGvV6sIbjzP8/9ibUmxnCOcwW9Enn4+Ukp4KuhuWKuiEZYdOARkuEupaz IyDw3F9NzytnER2s+sn2+tddQloTjCk0vzk+e5uH19ovwoLBmFOd/g5d+yNYt/SB ozzA3S4WTyG8vws2AOBcubJkg1wYzyUSGATceBqYLFMa7e7GuazRR/XohOwa7iux T1+4t72juhXUiFiPn4GD2aWjl30Eer0+juHdlje6EHtSRnODJXnYeEHIw/ndmTCy gEmMZ3c9fUoJC51HBeOSjX+Mg5Hq/AaGLLQHU+shklg6pgXKZ1ZKFAYD5rjWrXB2 jxPM0vFcJEh2yfMHTsgbgP6AnYF5g7/36izTdJsXWDgEJoE7Zt2J+NX5+SLTihtt GbWIUh5ZstZXBD85u4o8iB+whhpzZd7rE/GRK2Ax/kY8WnB8xeiU5wA5AQN6nTMr XPT/ObXsXKnyrLgn4KkRZymEeDO1yaaVrtGtLxF2Dap2CpH8so7hLQw/3KYxDsTP 8dptOS4EzVm+jZPdAHMHIqsyA2wnRfyauPAyYDEeVioCUkijinrt61x62OM5s8+X MbAOyjGGOPVXq0tFChbB9ZdSkMDNvj98sv1xhZ1yHmoKvJ56EM1drh7HhcJWD6/v dv9uUmY4DhVlvjYKwPgY =C4vr -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] authentication issues
On 2/16/15, 12:48 PM, Kashyap Chamarthy kcham...@redhat.com wrote: On Mon, Feb 16, 2015 at 09:54:30AM +, Gary Kotton wrote: Hi, With the current master in devstack I am unable to create a neutron network. It looks like there is an issue with keystone. Anyone else hit this? Thanks Gary Hmm, I don't see any such issue here, I'm using: Nova+Neutron+Keystone+Glance with libvirt/KVM drivers. Thanks. I will double check. And, these are the commits I'm at: DevStack commit 13c7ccc9d5d7ee8b88c2ee7d4af8990a075440a2 Glance commit cd60a24a7d32d4ca0be36f7afa4d082193958989 Merge: 803c540 4a78e85 Keystone commit c06591dd470aaa595206100d0176ccc0575d58b7 Author: OpenStack Proposal Bot openstack-in...@lists.openstack.org Neutron commit 12b0d4d9792d83fd559de59f2dd7b9f532f89398 Merge: 7a0a2a1 a3ab3eb Nova commit 69f4b44691ddabc2cfa8c08539a51d255646e173 Merge: ea1f1d6 353e823 requirements commit ec1c788c2bfac3ef964396b92f8a090b60dbb4ef $ neutron net-list +--+-+ + | id | name| subnets | +--+-+ + | ec39ff23-9319-4526-aa55-fdd0ec172bc5 | private | 2192c1b9-d1de-406d-ab7e-ba142a9b7d3d 10.1.0.0/24 | | d2994e9c-649a-4668-a6bc-a71ff2362e74 | public | 94cf7c03-7352-4b8d-8b00-21227c7414a4 172.24.4.0/24 | +--+-+ + $ ps -ef | grep -i neutron kashyapc 12983 12954 1 05:43 pts/700:00:03 python /usr/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini kashyapc 13040 13014 0 05:43 pts/800:00:02 python /usr/bin/neutron-openvswitch-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini kashyapc 13159 13049 0 05:43 pts/900:00:00 python /usr/bin/neutron-dhcp-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/dhcp_agent.ini root 13252 13040 0 05:43 pts/800:00:00 sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ovsdb-client monitor Interface name,ofport --format=json root 13254 13252 0 05:43 pts/800:00:00 /usr/bin/python /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ovsdb-client monitor Interface name,ofport --format=json kashyapc 13263 13175 0 05:43 pts/10 00:00:00 python /usr/bin/neutron-l3-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini kashyapc 13348 13273 0 05:43 pts/11 00:00:00 python /usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/metadata_agent.ini kashyapc 13369 13348 0 05:43 pts/11 00:00:00 python /usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/metadata_agent.ini kashyapc 13370 13348 0 05:43 pts/11 00:00:00 python /usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/metadata_agent.ini kashyapc 13371 13348 0 05:43 pts/11 00:00:00 python /usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/metadata_agent.ini kashyapc 13372 13348 0 05:43 pts/11 00:00:00 python /usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/metadata_agent.ini kashyapc 13940 1 0 05:43 ?00:00:00 /usr/bin/python /usr/bin/neutron-ns-metadata-proxy --pid_file=/home/kashyapc/src/cloud/data/neutron/external/pids/ef5ae22b-86 d2-42c0-8be4-95f75683bbfd.pid --metadata_proxy_socket=/home/kashyapc/src/cloud/data/neutron/metadata_pro xy --router_id=ef5ae22b-86d2-42c0-8be4-95f75683bbfd --state_path=/home/kashyapc/src/cloud/data/neutron --metadata_port=9697 --metadata_proxy_user=1000 --metadata_proxy_group=1000 --debug --verbose -- /kashyap __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack] authentication issues
Hi, With the current master in devstack I am unable to create a neutron network. It looks like there is an issue with keystone. Anyone else hit this? Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][vmware] MS update
Hi, MS is back up and running. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Summit Voting and ATC emails?
Hi, Yes, I think that they go out in batches. It would be best to check with Stefano if you have any issues. Thanks Gary On 2/15/15, 4:11 AM, Nick Chase nch...@mirantis.com wrote: Does anybody know if a) ATC emails have started to go out yet, and b) when proposal voting will start? Thanks --- Nick __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] FFE request for vmware-driver-domain-metadata
Hi, This support was added to the libvirt driver in J. The support is isolated to the Vmware driver and enables admins to get a better understanding of what is happening with the running instances. Any chance of getting a sponsor for this? https://review.openstack.org/#/c/141028/ This also enables the admin to do queries on the VC about instances, for example by AZ, flavor, etc. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Question about force_host skip filters
Hi, I think that the filters should be applied to the list of hosts that are in 'force_hosts'. I am not sure if this is what you are suggesting. If this is not then case then it sounds like a bug. Thanks Gary From: Rui Chen chenrui.m...@gmail.commailto:chenrui.m...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 12, 2015 at 11:05 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] Question about force_host skip filters Hi: If we boot instance with 'force_hosts', the force host will skip all filters, looks like that it's intentional logic, but I don't know the reason. I'm not sure that the skipping logic is apposite, I think we should remove the skipping logic, and the 'force_hosts' should work with the scheduler, test whether the force host is appropriate ASAP. Skipping filters and postponing the booting failure to nova-compute is not advisable. On the other side, more and more options had been added into flavor, like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and more difficult. Best Regards. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
On 2/12/15, 1:33 PM, Chmouel Boudjnah chmo...@enovance.com wrote: Jaume Devesa devv...@gmail.com writes: Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? as you stated I don't think there is a clear advantage or disadvantage but IMO having too many repositories is not very user friendly and I would recommend to have the plugin directly in the repo. For things like glusterfs which is not a native openstack project it makes sense that the plugin is hosted externally of the project. I am in favor of having these in the devstack reop. I think that keeping everything under the same umbrella is the healthiest model. Moving things to different repos is a a challenge and leads to endless problems (that is my two cents) Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Question about force_host skip filters
I understand the fact that an opertaor can and should be able to place the VM where she/he wants. The VM should just adhere to the scheduling constraints :) (which are defined in the filters) :) From: Rui Chen chenrui.m...@gmail.commailto:chenrui.m...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 12, 2015 at 1:51 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Question about force_host skip filters filters should be applied to the list of hosts that are in 'force_hosts'. Yes, @Gray, it's my point. Operator can live-migrate a instance to a specified host and skip filters, it's apposite and important, I agree with you. But when we boot instance, we always want to launch a instance successfully or get a clear failure reason, if the filters are applied for the force host, operator maybe find out that he is doing something wrong at earlier time. For example, he couldn't boot a pci instance on a force host that don't own pci device. and I don't think 'force_hosts' is operator action, the default value is 'is_admin:True' in policy.json, but in some case the value may be changed so that the regular user can boot instance on specified host. 2015-02-12 17:44 GMT+08:00 Sylvain Bauza sba...@redhat.commailto:sba...@redhat.com: Le 12/02/2015 10:05, Rui Chen a écrit : Hi: If we boot instance with 'force_hosts', the force host will skip all filters, looks like that it's intentional logic, but I don't know the reason. I'm not sure that the skipping logic is apposite, I think we should remove the skipping logic, and the 'force_hosts' should work with the scheduler, test whether the force host is appropriate ASAP. Skipping filters and postponing the booting failure to nova-compute is not advisable. On the other side, more and more options had been added into flavor, like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and more difficult. Any action done by the operator is always more important than what the Scheduler could decide. So, in an emergency situation, the operator wants to force a migration to an host, we need to accept it and do it, even if it doesn't match what the Scheduler could decide (and could violate any policy) That's a *force* action, so please leave the operator decide. -Sylvain Best Regards. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [vmware-api] Weekly meeting
Hi, Over the last few IRC meetings we have discussed the following: 1. Providing a platform for people other than those working on the Nova driver to take part. There are efforts with the Glance, Cinder, Ceilometer and Neutron projects. Hopefully people working on those can also take part and we can share and discuss ideas, painpoints, bugs etc. 2. Meeting time. We have also spoken about alternating the meeting times so that people in different timezones can take part. At the moment we have Wednesday 17:00 UTC. How does the option of alternate weeks doing at 9:00 UTC? Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
