Re: [Openstack] Future of this General Mailing list
+1 on the improved branding On Oct 20, 2012, at 9:44 PM, Frans Thamura fr...@meruvian.org wrote: Hi Stef I thnk @lists.openstack.org is a good.branding compare to @launchpad.net Frans Thamura Meruvian On Oct 21, 2012 9:24 AM, Stefano Maffulli stef...@openstack.org wrote: [I realized now I replied privately only. This meant to be public.] On Fri 12 Oct 2012 02:13:54 PM PDT, Frans Thamura wrote: is this mailing list move to the new mailing list? Yes, it will move to lists.openstack.org as soon as possible. Here is what needs to happen: - export list of subscribers and preferences from Launchpad (DONE) - test the exported list in a dev environment (TODO) Once the test is done, we need to define and publish a roadmap with deadline to close the LP list, close the LP list/team to new subscriptions/messages, export the final list from LP, import it into lists.openstack.org and move on. Honestly this last phase is not very clear to me yet. With the organization of the Summit taking priority, this task slipped in background. If you think this migration is urgent please state your reasons and the community may find resources to raise priority. /stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Openstack networking
Good afternoon, Is it anyway of avoid redirecting and managing all the traffic with just one vm?. I mean can I have several nova-networks for handling the traffic??. I'm going to use XenAPI and XenCloudPlatform, and going to have an vlan per project. I would like to know how to make the bridging, vlan, etc components on Linux scalable…. for just avoiding depending all the network traffic in just one machine…. Is that possible in Openstack? How other network configs could I do for scaling better?. Another aspect I would like too know if it's possible too… is the fact of just directly assigning public ip to instances… and avoiding having a public and a private ip…..Is all this possible??. Best regards, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack networking
Or does each nova-compute node has to have it's own nova network service in the same vm??? El 21/10/2012, a las 15:55, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Good afternoon, Is it anyway of avoid redirecting and managing all the traffic with just one vm?. I mean can I have several nova-networks for handling the traffic??. I'm going to use XenAPI and XenCloudPlatform, and going to have an vlan per project. I would like to know how to make the bridging, vlan, etc components on Linux scalable…. for just avoiding depending all the network traffic in just one machine…. Is that possible in Openstack? How other network configs could I do for scaling better?. Another aspect I would like too know if it's possible too… is the fact of just directly assigning public ip to instances… and avoiding having a public and a private ip…..Is all this possible??. Best regards, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] OpenStack + Nova-manage service list + Script for non-admin users
Dear ALL, I want to write a script which shows the number of physical machines on our lab's cloud. This script should show detailed list of all the OpenStack running services filtered by host and service name. It should also show the list of all VM instances launched on each physical host. Using an admin privilege i still can see on the command line by running the following commands #*nova-manage service list* # shows list of all the OpenStack running services filtered by host and service name #*nova list * #list the running instances #*nova show InstanceID* (for example, d1df1b5a-70c4-4fed-98b7-423362f2c47c) #information associated with the instance *is there anyway to wire a script which populates the above information for a non-admin user? I mean, for a user who don't have enough privilege to access the databases.* Any script tip on how I can approach this problem is highly appreciated. Thank you very so much for your time and taking my request in to consideration. With best regards, Desta ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
+1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. On Oct 20, 2012, at 21:07, Adam Young ayo...@redhat.commailto:ayo...@redhat.com wrote: On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: From: heckj he...@mac.commailto:he...@mac.com Subject: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Date: October 19, 2012 1:51:16 PM PDT To: OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org Reply-To: OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org The topic of what a token can or can't represent for the upcoming V3 Keystone API came up - and I wanted to share the conversation a bit more broadly to get feedback. A bit of history: In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user tenant/project (what's been called a scoped token) Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes. Apparently Rackspace's internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services. The quandary: In the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a default tenant is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it's possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default. I would like to make default tenant a configuration option, and have it disabled by default. Unscoped tokens are a very useful construct. In the case where the user has many roles across a multitude of projects, it is possible to create huge tokens. I would prefer unscoped tokens to remain, and to be associated with no tenant. The only operation Keystone should provide with them is the ability to enumerate tenants, so something like Horizon can then request an appropriately scoped token. I am also in favor of limiting the scope of a token to an endpoint. Even more-so than tenants, scoping a token to an end point increases security. Once a token has been scoped to an endpoint, it can only be used on that endpoint. If an endpoint gets compromised, the damage is limited to resources that endpoint already has access to. This, in conjunction with pre-auths, could allow a user to perform an action with a minimum of risk in a public cloud environment. A few folks from Rackspace touched on this at the very tail end of the V3 API review session on Thursday, bringing up that they had an issue with the token being scoped to a single tenant. Since this has significant implications to both security and a potential user experience flow, I wanted to bring the issue up across the broader community for discussion. The request outstanding: Rackspace folks are requesting that the token not be limited to a single tenant/project, but instead provides a list of potential tenants against which the token should be considered valid. I would like the world to know that we are affectionately calling such tokens sloppy tokens and Joe Savak has adopted the nickname of Sloppy Joe for championing them. Allowing it as an option is fine, but I would not recommend that this become the norm, or that we enable this feature by default. Brief (maybe shoddy) analysis: This would potentially imply changes to what gets passed as a part of the authentication reference in the context passed using auth_token
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
On Oct 21, 2012 12:11 PM, Joe Savak joe.sa...@rackspace.com wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Isn't that a security issue in and of itself? Shouldn't we force re-auth to change the password? Nate ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum OVS Agent as service
Hi, You are running a (very) old version of my guide. Try to read it again or follow official documentation available. Regards Emilien Macchi // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com // 10 rue de la Victoire 75009 Paris - Mail original - De: Srikanth Kumar Lingala srikanthkumar.ling...@gmail.com À: Dan Wendlandt d...@nicira.com Cc: openstack@lists.launchpad.net Envoyé: Jeudi 18 Octobre 2012 07:10:53 Objet: Re: [Openstack] Quantum OVS Agent as service Hi Dan, I am following Folsom Installation guide provided by Emilien Macchi. In that document it is mentioned to create a bridge 'br-int' attached to 'eth1' through ovs. And also it suggests to assign this ' br-int ' bridge as ' integration_bridge ' and ' br-eth1 ' as ' bridge_mappings ' in '/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini' like the following: integration_bridge = br-int bridge_mappings = default:br-eth1 Please clarify me, is it necessary to enable 'bridge_mappings' field. Regards, Srikanth. On Wed, Oct 17, 2012 at 10:13 PM, Dan Wendlandt d...@nicira.com wrote: It sounds like your config file is saying that you have an OVS bridge named br-eth1, but it looks like you do not. Did you intend to do this, or is this a config copied from somewhere else? If you actually intended to use VLANs that send traffic out eth1, you can do the following: # create bridge ovs-vsctl add-br br-eth1 # add eth1 as a port on this bridge ovs-vsctl add-port br-eth1 eth1 dan On Wed, Oct 17, 2012 at 1:53 AM, Srikanth Kumar Lingala srikanthkumar.ling...@gmail.com wrote: Hi all, If we run Quantum OVS Agent as a service ... 'service quantum-plugin-openvswitch-agent start', it is unable to start the agent. It is throwing the following error to '/var/log/quantum/agent-ovs.log' Stderr: 'Device br-eth1 does not exist.\n' 2012-10-16 12:48:10 ERROR [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Bridge br-eth1 for physical network default does not exist if we run the agent manually like the following command, it is able to start: /usr/bin/quantum-openvswitch-agent -- --config-file=/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini --log-file=/var/log/quantum/agent-ovs.log --config-file=/etc/quantum/quantum.conf Please suggest. -- Srikanth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack networking
In fact you can run multiple nova-networks, which I call it as multiple instances mode, and multi-host mode with each nova-network on each nova-compute. in multiple instance mode, you can use nova-manage network modify to host a given network on a given host, which is running a nova-network: ./bin/nova-manage network modify --help Usage: nova-manage network modify args [options] Options: -h, --helpshow this help message and exit --fixed_range=x.x.x.x/yy Network to modify --project=project name Project name to associate --host=host Host to associate --disassociate-project Disassociate Network from Project --disassociate-host Disassociate Host from Project On 10/21/2012 11:19 PM, Egoitz Aurrekoetxea Aurre wrote: t Or does each nova-compute node has to have it's own nova network service in the same vm??? El 21/10/2012, a las 15:55, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Good afternoon, Is it anyway of avoid redirecting and managing all the traffic with just one vm?. I mean can I have several nova-networks for handling the traffic??. I'm going to use XenAPI and XenCloudPlatform, and going to have an vlan per project. I would like to know how to make the bridging, vlan, etc components on Linux scalable…. for just avoiding depending all the network traffic in just one machine…. Is that possible in Openstack? How other network configs could I do for scaling better?. Another aspect I would like too know if it's possible too… is the fact of just directly assigning public ip to instances… and avoiding having a public and a private ip…..Is all this possible??. Best regards, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Why OpenStack use openvpn?
Hi guys, I've noticed there is a discussion regarding if the community should purchase public MAC OUI to provide vpn service incase the private sites have the default MAC assignments. I googled but didn't reach out any useful material to address my concern. Have you got the similar question ever on your mind? First, why we use openvpn? I know it's kind of arch question, like how to choose a right opensource software. On the other way, please let me know your point why we don't choose IPSEC or other VPNs. Secondly, what the scenario is it to avoid assigning the default MAC addresses? Is it site-to-site or for an alone PC to access back to private LAN? Thirdly, if default MAC assignment only influences L2 VPN in terms of site-to-site access, what about IPSEC or SSL VPN? To my understanding, the packets unencapped at the edge of destination network, they are going to face the similar issue no mather what kind of VPN is, source and dest MAC addresses are on the same network and it makes network devices confused. Really appreciate your any input. Thanks, Howard ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] using cinder to create volumes error
When I create volumes by cinder, error occurs in cinder-volume.log
2012-10-22 10:58:25 DEBUG cinder.volume.manager
[req-f51ade4d-5bed-4f24-b492-528b9baca625 cd7e95086cfc4693945f37e59c1b7206
67456c69ae074be4b4ba0af7048b5ceb] volume
volume-e224dfdb-913c-4135-811d-eb075a551de8: creating export create_volume
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py:155
2012-10-22 10:58:25 28674 ERROR cinder.openstack.common.rpc.amqp [-]
Exception during message handling
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp Traceback
(most recent call last):
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py,
line 276, in _process_data
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp rval =
self.proxy.dispatch(ctxt, version, method, **args)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py,
line 145, in dispatch
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp return
getattr(proxyobj, method)(ctxt, **kwargs)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 163, in
create_volume
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
volume_ref['id'], {'status': 'error'})
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
self.gen.next()
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 156, in
create_volume
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
model_update = self.driver.create_export(context, volume_ref)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/driver.py, line 380, in
create_export
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
volume_path)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py, line 112, in
create_iscsi_target
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
utils.ensure_tree(FLAGS.volumes_dir)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/utils.py, line 1049, in
ensure_tree
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
os.makedirs(path)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/os.py, line 157, in makedirs
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
mkdir(name, mode)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp OSError:
[Errno 13] Permission denied: '/usr/lib/python2.7/dist-packages/volumes'
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
Then I manually create directory volumes in
/usr/lib/python2.7/dist-packages and give 777 to it
but error again:
2012-10-22 11:21:43 ERROR cinder.volume.iscsi
[req-d965ffd6-aff8-4c2d-b3c0-c6aaca4cebf0 cd7e95086cfc4693945f37e59c1b7206
67456c69ae074be4b4ba0af7048b5ceb] Failed to create iscsi target for volume
id:volume-a430f00e-53fa-44e9-9470-f604d63b88b8. Please ensure your tgtd
config file contains 'include /usr/lib/python2.7/dist-packages/volumes/*'
2012-10-22 11:21:43 28674 ERROR cinder.openstack.common.rpc.amqp [-]
Exception during message handling
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp Traceback
(most recent call last):
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py,
line 276, in _process_data
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp rval =
self.proxy.dispatch(ctxt, version, method, **args)
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py,
line 145, in dispatch
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp return
getattr(proxyobj, method)(ctxt, **kwargs)
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 163, in
create_volume
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp
volume_ref['id'], {'status': 'error'})
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp
self.gen.next()
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 156, in
create_volume
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp
Re: [Openstack] using cinder to create volumes error
On Sun, Oct 21, 2012 at 9:24 PM, livemoon mwjpi...@gmail.com wrote:
When I create volumes by cinder, error occurs in cinder-volume.log
2012-10-22 10:58:25 DEBUG cinder.volume.manager
[req-f51ade4d-5bed-4f24-b492-528b9baca625 cd7e95086cfc4693945f37e59c1b7206
67456c69ae074be4b4ba0af7048b5ceb] volume
volume-e224dfdb-913c-4135-811d-eb075a551de8: creating export create_volume
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py:155
2012-10-22 10:58:25 28674 ERROR cinder.openstack.common.rpc.amqp [-]
Exception during message handling
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp Traceback
(most recent call last):
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py,
line 276, in _process_data
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp rval
= self.proxy.dispatch(ctxt, version, method, **args)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py,
line 145, in dispatch
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
return getattr(proxyobj, method)(ctxt, **kwargs)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 163, in
create_volume
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
volume_ref['id'], {'status': 'error'})
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
self.gen.next()
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 156, in
create_volume
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
model_update = self.driver.create_export(context, volume_ref)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/driver.py, line 380, in
create_export
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
volume_path)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py, line 112, in
create_iscsi_target
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
utils.ensure_tree(FLAGS.volumes_dir)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/utils.py, line 1049, in
ensure_tree
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
os.makedirs(path)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/os.py, line 157, in makedirs
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
mkdir(name, mode)
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp OSError:
[Errno 13] Permission denied: '/usr/lib/python2.7/dist-packages/volumes'
2012-10-22 10:58:25 28674 TRACE cinder.openstack.common.rpc.amqp
Then I manually create directory volumes in
/usr/lib/python2.7/dist-packages and give 777 to it
but error again:
2012-10-22 11:21:43 ERROR cinder.volume.iscsi
[req-d965ffd6-aff8-4c2d-b3c0-c6aaca4cebf0 cd7e95086cfc4693945f37e59c1b7206
67456c69ae074be4b4ba0af7048b5ceb] Failed to create iscsi target for volume
id:volume-a430f00e-53fa-44e9-9470-f604d63b88b8. Please ensure your tgtd
config file contains 'include /usr/lib/python2.7/dist-packages/volumes/*'
2012-10-22 11:21:43 28674 ERROR cinder.openstack.common.rpc.amqp [-]
Exception during message handling
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp Traceback
(most recent call last):
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py,
line 276, in _process_data
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp rval
= self.proxy.dispatch(ctxt, version, method, **args)
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py,
line 145, in dispatch
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp
return getattr(proxyobj, method)(ctxt, **kwargs)
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/dist-packages/cinder/volume/manager.py, line 163, in
create_volume
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp
volume_ref['id'], {'status': 'error'})
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp
self.gen.next()
2012-10-22 11:21:43 28674 TRACE cinder.openstack.common.rpc.amqp File
Re: [Openstack] Glance snapshots of VMs are invisble in horizon and glance image-list
Great catch! That totally fixed it, it was missing in the glance-registry.conf but present in glance-api.conf. [paste_deploy] flavor = keystone Sam On Sat, Oct 20, 2012 at 12:07 AM, Brian Waldon bcwal...@gmail.com wrote: It looks like you aren't deploying Glance with Keystone authentication enabled. Add a [paste_deploy] section to glannce-api and glance-registry configs with a single entry: flavor=keystone. On Oct 19, 2012, at 12:19 AM, Sam Stoelinga wrote: Hi all, When I create a snapshot of a VM, the snapshot just vanishes or is hidden. *Scenario:* 1. Create a vm with local storage 2. Create a snapshot of the VM after its running succesfully 3. In horizon create a snapshot of the VM 4. You get redirected to Image Snapshots page but there is no sign of the snapshot. *Some more debugging:* glance image-list +--+--+-+--+-++ | ID | Name | Disk Format | Container Format | Size| Status | +--+--+-+--+-++ | 6d196c6a-b210-45f7-a4ab-4d98e5b2a31b | cirros-0.3.0-x86_64-disk | qcow2 | bare | 9761280 | active | +--+--+-+--+-++ nova image-list +--+--++--+ | ID | Name | Status | Server | +--+--++--+ | 6d196c6a-b210-45f7-a4ab-4d98e5b2a31b | cirros-0.3.0-x86_64-disk | ACTIVE | | | 33d37a0b-0c4d-4976-8580-9e7bf8b53776 | test snapshot| ACTIVE | 526e1738-1b44-4509-900e-b29beed7e0f7 | +--+--++--+ As you can see glance image-list and nova image-list return different results. The snapshot has in fact been created correctly as you can see here: ls /var/lib/glance/images/6d196c6a-b210-45f7-a4ab-4d98e5b2a31b -lh -rw-r- 1 glance glance 9.4M Oct 19 14:24 /var/lib/glance/images/6d196c6a-b210-45f7-a4ab-4d98e5b2a31b *This is the snapshot image detail: * glance image-show 33d37a0b-0c4d-4976-8580-9e7bf8b53776 +---+--+ | Property | Value| +---+--+ | Property 'base_image_ref' | 6d196c6a-b210-45f7-a4ab-4d98e5b2a31b | | Property 'image_location' | snapshot | | Property 'image_state'| available| | Property 'image_type' | snapshot | | Property 'instance_uuid' | 526e1738-1b44-4509-900e-b29beed7e0f7 | | Property 'owner_id' | c21b7e53480b497aac6683d618a6b3ce | | Property 'user_id'| 4899e879f62846f1a4926b781a7489f6 | | checksum | 46742031d20be7eabf52e55c9e7bf345 | | container_format | bare | | created_at| 2012-10-19T06:59:45 | | deleted | False| | disk_format | qcow2| | id| 33d37a0b-0c4d-4976-8580-9e7bf8b53776 | | is_public | False| | min_disk | 0| | min_ram | 0| | name | test snapshot| | protected | False| | size | 14352384 | | status| active | | updated_at| 2012-10-19T06:59:55 | +---+--+ nova image-show 33d37a0b-0c4d-4976-8580-9e7bf8b53776 +-+--+ | Property| Value| +-+--+ | created | 2012-10-19T06:59:45Z | | id | 33d37a0b-0c4d-4976-8580-9e7bf8b53776 | | metadata base_image_ref | 6d196c6a-b210-45f7-a4ab-4d98e5b2a31b | | metadata image_location | snapshot | | metadata image_state| available| | metadata image_type | snapshot
