| === urulama__ is now known as urulama | ||
| === apuimedo is now known as apuimedo|away | ||
| === apuimedo|away is now known as apuimedo | ||
| apuimedo | beisner: gnuoy: I'm trying to use my private openstack cloud | 16:33 |
|---|---|---|
| apuimedo | but i'm getting some problems bootstrapping | 16:34 |
| apuimedo | http://paste.ubuntu.com/13216879/ | 16:35 |
| apuimedo | do you think it could be due to not being an admin (I have perms for creating instances and nets though) | 16:35 |
| beisner | hi apuimedo, could you paste a (sanitized) `juju stat --format tabular` for the private cloud? | 16:36 |
| beisner | it'll help me to understand the services and topology | 16:37 |
| apuimedo | ok | 16:38 |
| apuimedo | beisner: I get the same error | 16:39 |
| apuimedo | trying to do the juju stat | 16:39 |
| beisner | apuimedo, do you have openstack already deployed? | 16:39 |
| apuimedo | yes, I have several instances running on this cloud | 16:39 |
| apuimedo | now I want juju to create its machines there too | 16:40 |
| beisner | apuimedo, ok, so i'm referring to that cloud that is deployed. can you juju stat that cloud? | 16:40 |
| beisner | apuimedo, ie. 1 layer down. | 16:40 |
| apuimedo | beisner: that cloud has been deployed with ansible, not juju | 16:40 |
| apuimedo | beisner: does juju need admin level credentials for the bootstrapping? | 16:41 |
| beisner | apuimedo, ok. in that case, i'd need to see your environments.yaml file, `keystone catalog` and `keystone endpoint-list` output. | 16:41 |
| beisner | apuimedo, no, shouldn't need to be admin @ the undercloud. | 16:41 |
| apuimedo | cool, thanks | 16:42 |
| beisner | apuimedo, sanitized for sensitive data on those pastes, of course. | 16:42 |
| beisner | also can you show `apt-cache policy juju` ? | 16:43 |
| apuimedo | sure | 16:43 |
| apuimedo | beisner: http://paste.ubuntu.com/13216940/ | 16:43 |
| beisner | apuimedo, what vers of openstack is the cloud? | 16:45 |
| apuimedo | Kilo | 16:46 |
| apuimedo | I was talking with my operator | 16:46 |
| beisner | apuimedo, it may not be directly related to the issue at hand, but you can use ppa:juju/stable to get the current stable release of Juju (1.25). https://launchpad.net/~juju/+archive/ubuntu/stable | 16:46 |
| apuimedo | he fixed some of my credentials and now I got past that error | 16:46 |
| apuimedo | oh, that sounds like a good idea anyway | 16:46 |
| apuimedo | http://paste.ubuntu.com/13216957/ | 16:47 |
| beisner | apuimedo, it looks like a previous juju bootstrap didn't get completely destroyed. can you remove (back up if you want to) the /home/ubuntu/.juju/environments/openstack.jenv file, then see if juju stat exits ok (showing no enviro bootstrapped)? | 16:47 |
| apuimedo | beisner: ^^ that will be due to the streams, right? | 16:47 |
| beisner | apuimedo, i'd rm that .jenv file to make sure the basic juju stat cmd is good. then do a `juju bootstrap --debug` ... which will show more detail if there's a failure somewhere. | 16:48 |
| apuimedo | cool. I'll try that now | 16:49 |
| apuimedo | beisner: http://paste.ubuntu.com/13216996/ | 16:53 |
| apuimedo | yeah... It seems I have to define the images somehow in the environment | 16:53 |
| apuimedo | I have to say the guide I found online was not the clearest | 16:53 |
| beisner | apuimedo, i think this is what you're after : https://jujucharms.com/docs/1.25/howto-privatecloud | 16:56 |
| apuimedo | yes. That's the one I'm looking at beisner | 16:57 |
| jcastro | lazypower: mbruzek: check this out: https://sysdig.com/digging-into-kubernetes-with-sysdig/ | 17:02 |
| lazypower | interesting | 17:02 |
| mbruzek | jcastro: cool | 17:03 |
| beisner | apuimedo, images and metadata are the things to sort out for the private cloud juju usage. i've got a test cloud building, and will be able to step through that on my end later today. | 17:05 |
| beisner | in the past, i've used that guide. | 17:05 |
| apuimedo | I'm doing that now | 17:05 |
| apuimedo | let's see if I succeed :-) | 17:06 |
| beisner | apuimedo, be aware too - it looks like you're hitting a destroy bug (for which a fix is underway). the bug is that the destroy errors out, leaving the .jenv file behind, and you have to manually rm it after destroying. but that won't affect bootstrapping or deploying. | 17:06 |
| beisner | https://bugs.launchpad.net/bugs/1512399 | 17:06 |
| mup | Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <bug-squad> <openstack> <sts> <uosci> <Go OpenStack Exchange:In Progress by gz> <juju-core:Triaged> <juju-core | 17:06 |
| mup | 1.25:Triaged> <https://launchpad.net/bugs/1512399> | 17:06 |
| apuimedo | cool | 17:06 |
| apuimedo | thanks beisner | 17:06 |
| beisner | yw apuimedo - let us know how you turn out | 17:07 |
| apuimedo | I will, thanks | 17:07 |
| apuimedo | beisner: I set up agent-metadata-url and image-metadata-url | 17:18 |
| apuimedo | but somehow it seems it still goes to | 17:18 |
| apuimedo | 2015-11-10 17:17:53 DEBUG juju.environs.simplestreams simplestreams.go:429 read metadata index at "http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson" | 17:19 |
| apuimedo | :( | 17:19 |
| apuimedo | ok, my mistake | 17:21 |
| apuimedo | I had a typo :P | 17:21 |
| apuimedo | sorry about that | 17:21 |
| apuimedo | got it bootstrapping ;-) | 17:25 |
| apuimedo | thanks for the help beisner! | 17:25 |
| beisner | apuimedo, woot! you're welcome. happy deploying. | 17:39 |
| apuimedo | beisner: is it possible to specify the ram amount when adding machine | 19:00 |
| beisner | hi apuimedo - juju can use constraints to choose the nearest specs match presented by your cloud. i believe "equal or greater" logic is used in that. `nova flavor-list` will show the machine sizes you have to choose from. | 19:03 |
| beisner | https://jujucharms.com/docs/1.25/charms-constraints | 19:03 |
| apuimedo | juju machine add --constraints mem=8G | 19:03 |
| apuimedo | like so? | 19:03 |
| apuimedo | it worked | 19:05 |
| apuimedo | thanks | 19:05 |
| beisner | apuimedo, ok good :) | 19:11 |
| === urulama is now known as urulama__ | ||
| blr | is the new lxd provider going to obviate the local provider? | 20:28 |
| jose | blr: well, local uses lxc, which lxd is based on (I believe) | 20:36 |
| blr | jose: right, just curious if the long term intention is to replace the local/lxc provider | 20:39 |
| rick_h__ | blr: yes in time the lxd provider, with better isolation and ability tondo things like HA will deprecate the local provider. | 20:41 |
| blr | rick_h__: nice | 20:42 |
| blr | lazypower: if you're about, have a simple MP for charmhelpers that could use a look (https://code.launchpad.net/~blr/charm-helpers/pip-constraints/+merge/276062) | 20:49 |
| apuimedo | beisner: is there any way to make juju deploy lxc to the machines on openstack providers with the juju-br0 model that it uses when the machine is provided by maas? | 21:11 |
| rick_h__ | frobware: ^ this was done for the machine registration work and isn't part of OS provider work atm? Or is it planned/part of it? | 21:17 |
| beisner | apuimedo, i believe the juju openstack provider is designed to use 1 nova instance per juju unit. i don't think there is currently support for juju deploying services to lxc containers within nova instances via the openstack provider. | 21:17 |
| apuimedo | beisner: well, it does deploy the lxc containers | 21:18 |
| beisner | apuimedo, rick_h__ ... and i was about to say, let me check though. ;-) thanks rick_h__ ... fwiw - that would be immensely useful for us in openstack engineering too (juju/goose support for lxc containers on nova instances). | 21:18 |
| apuimedo | but obviously they are unreachable | 21:18 |
| rick_h__ | beisner: well you can use provision to an lxc on a nova vm with --to=lxc and such. | 21:18 |
| beisner | apuimedo, right, i think it will, but then they are marooned in my experience. | 21:18 |
| rick_h__ | beisner: at least I wanted to think that was possible with normal --to support | 21:18 |
| apuimedo | beisner: I just had my nova instances remove the anti spoofing filter | 21:19 |
| apuimedo | so if they would just have the bridge on the eth0 device | 21:19 |
| apuimedo | it would all work | 21:19 |
| apuimedo | or putting different /24 on each nova vm | 21:19 |
| rick_h__ | apuimedo: beisner frobware leads the team working on networking and can best speak to that atm. however he's EU and EOD | 21:19 |
| beisner | rick_h__, something legacy is ringing a vague bell with goose -- where it didn't / couldn't know about all of the various neutron bits to wire up in advance. | 21:19 |
| apuimedo | EU here too :P | 21:20 |
| rick_h__ | beisner: yea, I'll not be surprised that maas has it because it's more knowledgable | 21:20 |
| apuimedo | well, what I do is every time I put up a nova VM | 21:20 |
| apuimedo | you get a new port | 21:20 |
| apuimedo | so you can immediately do whatever to remove the filter | 21:20 |
| === natefinch is now known as natefinch-afk | ||
| rick_h__ | beisner: apuimedo jrwren had an interesting post around the bridge http://jrwren.wrenfam.com/blog/2015/11/10/converting-eth0-to-br0-and-getting-all-your-lxc-or-lxd-onto-your-lan/ | 22:20 |
| rick_h__ | not sure if it's helpful at all, but fyi | 22:20 |
| apuimedo | rick_h__: I was considering doing it like that | 22:21 |
| apuimedo | the problem for OSt deployments is that the dhcp should not give you an address | 22:22 |
| apuimedo | so what I was thinking of was to make juju call neutron to set routes between the VMs | 22:22 |
| apuimedo | and, of course, use a /24 net per VM | 22:23 |
| apuimedo | rick_h__: do you happen to know who's in charge of networking in the context of the openstack provider? | 22:23 |
| rick_h__ | apuimedo: frobware's team | 22:24 |
| apuimedo | ok | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!