Re: [Openstack] Essex volume attach issue on Debian Wheezy
On Wed, Dec 05, 2012 at 11:46:46AM -0800, Vishvananda Ishaya wrote: and /etc/nova/rootwrap.d/volume.filters contains the line: iscsiadm_usr: CommandFilter, /usr/bin/iscsiadm, root ? Vish You were right. This filter was not defined on compute nodes, but Debian is still using essex, so /etc/nova/rootwrap.d is not present [1], rootwrap filters are defined at /usr/share/pyshared/nova/rootwrap/ iscsiadm filter is defined in volume.py: filters.CommandFilter(/usr/bin/iscsiadm, root), but that file is included in nova-volume package: dpkg -S /usr/share/pyshared/nova/rootwrap/volume.py nova-volume: /usr/share/pyshared/nova/rootwrap/volume.py This is a problem (a bug?) because nova-volume is not installed on computer nodes. Putting this filter in compute.py on compute nodes resolves this issue and rootwrap works properly. I'm facing a new issue :-), but it will be reported at another thread Can someone confirm that this is a possible bug? or perhaps I'm doing something wrong Alberto [1] http://wiki.openstack.org/Packager/Rootwrap ___ 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] S3 Token
Hi, I'm working on removing the swift+keystone middleware from keystone, we have moved it already as keystoneauth since last OpenStack release into the main swift repository. One thing that left in keystone is the s3_token middleware. Since in OpenStack/Swift we are not supporting third party API this could not be moved there. The options : 1) Keep s3token in keystone 2) Remove s3token from keystone and try to convince the swift3 maintainer to integrate it. 3) Try to figure out if there is actually people using this and if not just nuke it. 4) move s3token to its own repo on github somewhere. i personally would vote for number three, I don't think much people using this (i.e: swift+keystone+s3) or at least I didn't hear many feedback about the middleware. Chmouel. ___ 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] S3 Token
Hi Chmouel, On 9 December 2012 00:22, Chmouel Boudjnah chmo...@chmouel.com wrote: i personally would vote for number three, I don't think much people using this (i.e: swift+keystone+s3) or at least I didn't hear many feedback about the middleware. Option 3 is very unpalatable IMHO. People have existing clients using the EC2 creds with libraries such as Boto and Libcloud, so any kind of complete removal would need to be staged over releases to give fair warning. What's more, surely part of the point in providing the AWS APIs in the first place is to ease porting, requiring different creds for EC2 and S3 APIs unnecessarily complicates that. I vote for option 1 or 2. -- Cheers, ~Blairo ___ 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] S3 Token
Hi Chmouel - We get a lot of questions from the doc about supporting S3, but I don't know if it's with Keystone or without. Basically, it's this page that gets a lot of feedback and use: http://docs.openstack.org/trunk/openstack-object-storage/admin/content/configuring-openstack-object-storage-with-s3_api.html So, tell me if that's s3 token? Or just using S3 creds sans Keystone? That would help me help you decide how to proceed. Whew. :) Thanks, Anne On Sat, Dec 8, 2012 at 2:49 PM, Blair Bethwaite blair.bethwa...@gmail.comwrote: Hi Chmouel, On 9 December 2012 00:22, Chmouel Boudjnah chmo...@chmouel.com wrote: i personally would vote for number three, I don't think much people using this (i.e: swift+keystone+s3) or at least I didn't hear many feedback about the middleware. Option 3 is very unpalatable IMHO. People have existing clients using the EC2 creds with libraries such as Boto and Libcloud, so any kind of complete removal would need to be staged over releases to give fair warning. What's more, surely part of the point in providing the AWS APIs in the first place is to ease porting, requiring different creds for EC2 and S3 APIs unnecessarily complicates that. I vote for option 1 or 2. -- Cheers, ~Blairo ___ 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
