On 26/06/13 15:44, Dolph Mathews wrote:
> Identity API v3 support will be exposed on the CLI through the
> python-openstackclient project [6].
I wonder if this will be the turning point for adoption of
python-openstackclient? Hopefully! :)
Thanks,
Kiall
_
Wani wrote:
But packstack script has created the nova user with no ability to login
As /etc/passwd says: nova:x:162:162:OpenStack Nova
Daemons:/var/lib/nova:/sbin/nologin
On Wed, May 29, 2013 at 5:45 PM, Mac Innes, Kiall
mailto:ki...@hp.com>> wrote:
On 29/05/13 13:11, Nehal J. Wani wrot
On 29/05/13 13:11, Nehal J. Wani wrote:
> 2013-05-29 17:39:04.795 5106 TRACE nova.openstack.common.rpc.amqp
> ProcessExecutionError: Unexpected error while running command.
> 2013-05-29 17:39:04.795 5106 TRACE nova.openstack.common.rpc.amqp
> Command: ssh 10.3.3.58 mkdir -p
> /var/lib/nova/instance
On 15/05/13 14:22, Daniel Ellison wrote:
> On May 15, 2013, at 9:08 AM, "Mac Innes, Kiall" wrote:
>> Personally, I would make use of a bind mount[1] rather than trying to
>> relocate..
>>
>> A bind mount is just like a symlink, with the exception of AppA
Personally, I would make use of a bind mount[1] rather than trying to relocate..
A bind mount is just like a symlink, with the exception of AppArmor (and I
presume SELinux) will handle it "correctly"..
Thanks,
Kiall
[1]: http://docs.1h.com/Bind_mounts
On 15/05/13 14:02, Daniel Ellison wrote:
On 14/05/13 12:02, Stanislav Pugachev wrote:
Hi,
I've added a blueprint
https://blueprints.launchpad.net/hacking/+spec/absolute-paths-of-os-binaries
Please, take a look and let's discuss it if it makes sense.
Thank you
Stas.
Am I correct in thinking that, if the attacker is able to modify $PATH
On 12/05/13 16:52, Monty Taylor wrote:
> I mention our erstwhile nascent DNSaaS project as an example
> of pre-incubation... hopefully someone in that project will do the thing
> I just mentioned and will come to us at incubation time with a name that
> is not a CLEAR violation. I mean, we can't be
While I don't use Quantum either, If I was deploying today.. I would.
nova-network (the thing Quantum is replacing) is on it's way out, and
deploying with nova-network today just means you'll have to migrate in
1-2 releases (6-12 months).
Kiall Mac Innes
HP Cloud Services - DNSaaS
Mobile: +3
On 07/04/13 23:39, Filipe Manco wrote:
>
> The way to go is upgrade to Ubuntu 13.04, right?
Or, Downgrade to 12.04.
12.04 will get packages for OpenStack Grizzly, Havana and "I", 13.04 on
the other hand will get Grizzly and that's it. If you want Havana,
you'll need to upgrade to 13.10, or dow
On 03/04/13 11:03, Sam Stoelinga wrote:
> To prevent this happening to somebody else we could do the following:
> 1. In the documentation explicitly tell the user that when you enable
> multi_host that you can't use vncserver_listen=0.0.0.0
> 2. Do some sanity checks on nova.conf options, if we not
Obviously, I'm biased, But I'll +1 this!
I'll also add that we have a conference session at 11:50am on the
Monday, and an unconference room at 2:40pm on the same day.
Anyone who's interested, please attend :)
Hope to see you there!
Kiall Mac Innes
HP Cloud Services - DNSaaS
Mobile: +353 86
On 13/02/13 17:07, Scott Devoid wrote:
> We're also lacking support for setting --endpoint-type in keystone. In
> my case, it's trying to use adminURL when publicURL is the only one
> externally reachable.
The keystone client doesn't use the --endpoint-type flag, since you have
to supply a URL in
Hi Patrick,
Both the cinder and nova CLI's support a --endpoint-type argument, it
defaults to publicURL.
If you use '--endpoint-type internalURL' it should do the right thing..
Thanks,
Kiall
On 13/02/13 11:09, Patrick Petit wrote:
> Dear All,
>
> How can I direct nova CLI to use the internal
13 matches
Mail list logo
