Juju with Devstack on Virtualbox
leetobin at gmail.com
Thu Jan 24 17:33:38 UTC 2013
Excellent, thanks for the clarification John. I'll update my
environments.yaml file now.
On 24 January 2013 15:15, John Meinel <john at arbash-meinel.com> wrote:
> There is an "openstack_s3" provider and an "openstack" provider that uses
> swift. I'm using the latter, and it is working fine.
> On Jan 24, 2013 4:51 PM, "Lee Tobin" <leetobin at gmail.com> wrote:
>> Thanks for the reply Martin. Yes, I should have been more explicit when
>> explaining my problem.
>> I understand it's not the done thing to experiment with Juju in this
>> manner however I wanted to do quite a bit of destructive testing hence the
>> virtualised environment.
>> During install, I tweaked config files quite a bit so I'm not surprised
>> it has zombie entries.
>> The openstack provier doesn't support swift though? Correct? Swift is
>> also a requirement for my testing.
>> I'll try investigating the 'instance_type' issue you discovered.
>> On 23 January 2013 17:59, Martin Packman <martin.packman at canonical.com>wrote:
>>> On 19/01/2013, Lee Tobin <leetobin at gmail.com> wrote:
>>> > Hello,
>>> > I'm new to Juju, it looks great however could someone please help?
>>> Note that the normal way to experiment with Juju on your own box is to
>>> use the local provider:
>>> If you want to test Juju on Openstack you really need a number of
>>> machines, so getting an account on the HP Cloud is one of the easiest
>>> I doubt anyone else has tried running Juju against devstack in a VM,
>>> so even if you get your Openstack deployment fixed, you may still find
>>> you can't do much with it.
>>> > So, I've created 2 VMs in Virtualbox, a Juju box and a Devstack box.
>>> > node Devstack box with swift running.
>>> It's really helpful when reporting problems to be explicit about what
>>> exactly you're using, what version of Ubuntu, what version of
>>> Openstack set up how, what version of Juju, and so on.
>>> The first confusing thing is you're using the EC2 provider rather than
>>> the native Openstack one, but have a bunch of extra config options in
>>> your environments.yaml that don't actually apply. If you switch,
>>> running `juju -v bootstrap` gives details about the underlying
>>> Openstack api calls and their responses, which can be useful for
>>> diagnosing problems.
>>> Unmangled from your log, the most relevent exception seems indicate
>>> your openstack deployment is slightly misconfigured:
>>> Traceback (most recent call last):
>>> File "/opt/stack/nova/nova/compute/manager.py", line 688, in
>>> injected_files, admin_password)
>>> File "/opt/stack/nova/nova/compute/manager.py", line 960, in _spawn
>>> File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1039, in spawn
>>> File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1952, in
>>> self.firewall_driver.prepare_instance_filter(instance, network_info)
>>> File "/opt/stack/nova/nova/virt/firewall.py", line 188, in
>>> ipv4_rules, ipv6_rules = self.instance_rules(instance, network_info)
>>> File "/opt/stack/nova/nova/virt/firewall.py", line 403, in
>>> File "/opt/stack/nova/nova/network/api.py", line 253, in
>>> result = self._get_instance_nw_info(context, instance)
>>> File "/opt/stack/nova/nova/network/api.py", line 263, in
>>> 'rxtx_factor': instance['instance_type']['rxtx_factor'],
>>> TypeError: string indices must be integers
>>> You could try working out how your 'instance_type' ended up being a
>>> string rather than a dict, but as mentioned at the start, you probably
>>> just want to use something other than a local devstack for playing
>>> with juju.
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju