[00:38] <Tug> when adding a relation to 2 services, events "joined" and "changed" are not synchronized between the 2 services. For instance my hooks execute in that order :
[00:38] <Tug> service1-relation-joined > service1-relation-changed > service2-relation-joined > service2-relation-changed, but what I was expecting would be to have both "joined" hooks completed before running "changed" hooks.
[00:42] <Tug> the issue here is that "joined" hooks execute 'relation-set' commands so we have missing entries in the relation list when running "service1-relation-changed"
[00:42] <Tug> I'll try to ask you guys this during the day ;)
[00:43] <tvansteenburgh> Tug: this is covered in the docs here: https://juju.ubuntu.com/docs/authors-relations-in-depth.html
[00:43] <tvansteenburgh> "In one specific kind of hook, this is easy to deal with. A relation-changed hook can always exit without error when the current remote unit is missing data, because the hook is guaranteed to be run again when that data changes -- and, assuming the remote unit is running a charm that agrees on how to implement the interface, the data will change and the hook will be run again."
[00:44] <tvansteenburgh> so in your relation-changed hook, do a relation-get, and if the value is empty (not there), just exit 0, knowing that your hook will be run again when the data /is/ there
[00:44] <Tug> thx tvansteenburgh, yeah I skipped some parts of the docs
[00:44] <Tug> ;)
[00:45] <tvansteenburgh> Tug: no worries
[00:46] <Tug> well I did that (actually the mongodb charm does that) but I think it fails
[00:46] <Tug> I mean it is not run again
[00:47] <tvansteenburgh> O_o
[00:48] <Tug> the mongos/0 unit is in error state 'hook failed: "mongos-cfg-relation-changed"'
[00:48] <Tug> running resolved -r indeed works
[00:48] <tvansteenburgh> Tug: yeah ok, if a hook fails all events are paused until the failure is resolved
[00:49] <tvansteenburgh> do you know what caused the failure?
[00:49] <tvansteenburgh> ok
[00:49] <Tug> yeah the relation-set
[00:49] <Tug> I mean get
[00:49] <Tug> mongos_relation_changed: relation data not ready.
[00:49] <Tug> mongos_relation_changed returns: False
[00:50] <Tug> ERROR juju.worker.uniter uniter.go:490 hook failed: exit status 1
[00:50] <tvansteenburgh> Tug: if you pastebin the code i can try to help
[00:51] <Tug> yep
[00:51] <tvansteenburgh> but in general, don't use `relation-get` in a config-changed hook
[00:52] <tvansteenburgh> b/c you can't be sure that the relation is established
[00:52] <tvansteenburgh> only use it in relation hooks
[00:54] <Tug> http://bazaar.launchpad.net/~dekervit/charms/precise/mongodb/trunk/view/head:/hooks/hooks.py
[00:55] <Tug> http://bazaar.launchpad.net/~dekervit/charms/precise/mongodb/trunk/view/head:/hooks/hooks.py#L1329
[00:55] <Tug> I did not change too much the original script
[00:56] <Tug> but what we see here is that configsvr_relation_joined() can happen after mongos_relation_changed()
[00:56] <Tug> thus causing relation_gets to return None
[00:56] <Tug> line 1337 (^^)
[00:57] <tvansteenburgh> Tug: yep, that is a normal scenario
[00:58] <sarnold> would a correct fix be to add a new line after 1338 that sets retVal = True  ?
[00:58] <tvansteenburgh> sarnold: yes
[00:58] <sarnold> \o/
[00:58] <Tug> nice :)
[00:58] <Tug> really ?
[00:59] <tvansteenburgh> Tug: yep
[00:59] <Tug> I have to try !
[01:00] <tvansteenburgh> Tug: it's not an error for relation data to not be ready. if that it the case you must return True (exit 0) so that juju will continue processing events, and eventually run your hook again when it does have the data
[01:02] <Tug> (exit 1 you mean ?)
[01:02] <Tug> alright, I'm running the fix :)
[01:04] <tvansteenburgh> Tug: no, exit 0
[01:04] <tvansteenburgh> :P
[01:05] <tvansteenburgh> exit 0 = success, exit > 0 = fail
[01:05] <Tug> really ? I always type exit 1 with debug-hook to say it ended correctly
[01:05] <tvansteenburgh> see lines 1660 - 1663
[01:05] <Tug> ok I was wrong then, good to know :)
[01:06] <Tug> ah yes
[01:06] <tvansteenburgh> Tug: glad to hear you've discovered the joy of debug-hooks though!
[01:07] <Tug> yeah thanks to lazyPow3r a few weeks ago
[01:08] <lazyPower> tvansteenburgh: how do i get root path system independently? i thought os.path.abspath() would return it...
[01:08] <Tug> btw, I just spent a few days improving the mongodb charm, it might help the community later ;)
[01:08] <lazyPower> but its including the CWD
[01:08] <lazyPower> which i do not want.
[01:09] <tvansteenburgh> lazyPower: i don't understand what you want it to return
[01:09] <tvansteenburgh> Tug: that's awesome!
[01:09] <lazyPower> tvansteenburgh: if i say os.path.join('foo','bar') using abs path, iw ant '/foo/bar' to be the return path.
[01:10] <tvansteenburgh> lazyPower: yeah, you'd have to os.path.join('/', 'foo', 'bar')
[01:10] <lazyPower> that kind of defeats the idea of using os.path.join though...
[01:10] <tvansteenburgh> there must be a better way, that's not portable
[01:10] <tvansteenburgh> yeah
[01:10] <tvansteenburgh> well do abspath on foo first
[01:11] <lazyPower> http://paste.ubuntu.com/7460299/
[01:11] <lazyPower> nope.xls
[01:11] <Tug> thanks tvansteenburgh, sarnold it worked
[01:11] <lazyPower> i think abspath always returns from CWD
[01:12] <jose> lazyPower: now that you're on review, I've got a charm that got a +1 from a charm-contributor and a non-reviewing charmer
[01:12] <tvansteenburgh> Tug: great!
[01:12] <lazyPower> jose: offduty :P
[01:12] <lazyPower> i've been on duty when when not duty'ing
[01:12]  * lazyPower takes a vacation to work on other projects
[01:12] <sarnold> Tug: nice :)
[01:13]  * jose flips table
[01:13] <lazyPower> bwahahahaha
[01:13]  * lazyPower dangles carrots in front of jose
[01:13]  * tvansteenburgh laughs and points
[01:13] <lazyPower> jose: which charm? i'll look at it tomorrow
[01:13] <lazyPower> i'm assuming seafile?
[01:13] <jose> you got it right
[01:13] <lazyPower> i figured, i saw extra work in that one this week
[01:13] <jose> looks like you've read your emails
[01:13] <lazyPower> butofcourse
[01:14] <lazyPower> half hour in the morning, half hour at the end of the day
[01:14] <tvansteenburgh> lazyPower: i still don't get what you're trying to achieve. are you making a path to a dir that doesn't exist?
[01:14] <lazyPower> tvansteenburgh: yep
[01:14] <lazyPower> i want to make /vagrant/charms/precise
[01:14] <lazyPower> whcih will not exist by default
[01:15] <lazyPower> i mean, i could get cheap, and just make it on the host... but thats not a fair assumption to make. the script should drive all actions and make assertions.
[01:15] <jose> sudo mkdir /vagrant
[01:15] <lazyPower> this is the equivalent of a nose test for testing the juju vagrant image.
[01:15] <tvansteenburgh> http://stackoverflow.com/questions/12041525/a-system-independent-way-using-python-to-get-the-root-directory-drive-on-which-p
[01:15] <tvansteenburgh> i guess that's the heart of what you want
[01:15] <lazyPower> tvansteenburgh: look at the second answer
[01:15] <lazyPower> :P
[01:15]  * lazyPower edited that like, 5 minutes ago
[01:16] <tvansteenburgh> hey, nice
[01:16] <lazyPower> and its such a hack. you're finding the path to the interpreter, which may or may not be correct on windows.
[01:16] <lazyPower> what if vagrant mounts on C:\\ but the python interpreter is on d:\\
[01:16] <tvansteenburgh> your answer isn't a hack
[01:16] <lazyPower> its not solid though. i just want the root of the current filesystem.
[01:17] <lazyPower> thats the only safe assumption i'm willing to give with windows
[01:17] <lazyPower> i guess this works :|
[01:17]  * lazyPower resigns to using his own hack
[01:17] <lazyPower> a hack, using hacks, to produce hacky scripts
[01:17]  * lazyPower hackety hack hacks
[01:18] <lazyPower> tvansteenburgh: thanks though, appreciate the extra braincells @ the problem.
[01:19]  * tvansteenburgh was not much help
[01:19]  * tvansteenburgh wanders off to eat pie, waving as he goes
[01:19] <sarnold> I thought on windwos you just shoved everything into C:\windows\system32\ and called it a day? :)
[01:20] <lazyPower> sarnold: duh
[01:20] <lazyPower> ;)
[01:20] <sarnold> :)
[01:20] <lazyPower> only real lusers put stuff elsewhere
[01:20] <lazyPower> making it easy to remoev
[01:20] <sarnold> or backup
[01:20] <sarnold> hahaha
[01:20] <lazyPower> i mean, software is so great on that platform why wants to remove it?!
[01:20] <lazyPower> s/why/who/
[01:48] <lazyPower> hey sarnold
[01:48] <sarnold> evening lazyPower :)
[01:48] <lazyPower> http://askubuntu.com/questions/465544/what-is-the-reason-that-i-see-cron-session-opening-and-closing-every-hour-in-va <- this is a good question. Why DOES this happen?
[01:49] <sarnold> lazyPower: heh that is a decent question :)
[01:49] <lazyPower> oh man, did i stump you?
[01:50] <sarnold> heh, no, I'm just saying that for a beginner it'll be utterly impenetrable with no clue where to go for finding the answer :)
[01:50] <sarnold> his or her guess is utterly adorable :)
[01:50] <lazyPower> dang
[01:50] <lazyPower> i keep hoping i'll find an area of grey knowledge and stump you, its become quite the fun game to play.
[01:51] <lazyPower> better know the day it happens i'm pooping the cork on the champagne.
[01:51] <lazyPower> s/pooping/popping
[01:51] <lazyPower> what a typo wow
[01:51] <lazyPower> context... it is everything.
[01:51] <sarnold> haha, look closer to home -- I know nearly nothing about Go. I spent two hours just trying to figure out how to do cscope-like things in it that didn't involve "Step 1: install a Java Servlet Container"
[01:51] <sarnold> lol
[01:53] <lazyPower> but, go isn't home here
[01:54] <lazyPower> i work with pretty much everything *but* go
[01:54] <sarnold> well, I guess if you're just using the API of juju, it wouldn't be your regular stomping grounds either..
[01:54] <lazyPower> until there's a go charm in the store.
[01:54] <sarnold> hehe
[01:54] <lazyPower> then i'll be like "yo dawg"
[01:54] <lazyPower> "whats up with this go code?"
[01:55] <sarnold> and I'll guess my way through it :)
[01:56] <sarnold> the answer there isn't too bad, but if a better one isn't posted when I'm done with dinner, I'll write a -good- one :) hehe
[01:56] <lazyPower> looking forward to it
[04:02] <lifeless> mkdir: cannot create directory �/var/run/rabbitmq�: Permission denied
[04:02] <lifeless> /usr/lib/rabbitmq/bin/rabbitmq-server: 80: /usr/lib/rabbitmq/bin/rabbitmq-server: cannot create /var/run/rabbitmq/pid: Directory nonexistent
[04:03] <lifeless> bah, echannel
[04:03] <lifeless> sorry
[04:20] <cruisibesares> hey guys im testing out juju and maas. So far things are pretty awesome. I also have an aws cluster and i have set that up with a different name in my environments file. Do i need to run an instance of juju for each envionrment with juju bootstrap or is there a way that I can have one gui/juju server that will manage both providers? If you need one juju node per provider can it be colocated with maas? I found this http://askubuntu.
[04:20] <cruisibesares> com/questions/181880/does-each-juju-environment-specified-require-its-own-master-node but im wondering if anything has changed at this point in juju's development. I think that it would be really nice to be able to join all my clouds with one orchestration tool. If its not there now is on the roadmap or am i missing something fundamental?
[11:33] <Cuy> Hi! I'm looking into Juju for service orchestration and the planned deployment of an OpenStack cloud (possibly in combination with Saltstack). Could anyone tell me how resource hungry Juju is? As in: How many servers can I realistically expect to steer from one master? And is there some infrastructure size you would consider a hard limit of Juju's capabilities?
[11:36] <Cuy> Sorry for asking here, but I didn't find any information on these topics anywhere on the net (and I've been looking into service orchestration and configuration management for a few weeks now ;) )
[14:16] <gnuoy> Is it possible to write amulet tests that interrogate the relation sentry for charms which are not yet in the charm store ? The reason I ask is that I'm getting a "request failed with: 404" and it seems to be trying to query  https://manage.jujucharms.com/api/3/charm/...
[14:29] <lazyPower> gnuoy: you can specify a launchpad branch to deploy from.
[14:29] <lazyPower> are you using amulet 1.5?
[14:29] <gnuoy> I am
[14:29] <lazyPower> bueno, that *should* work.
[14:29] <gnuoy> branch: lp:~blah
[14:30] <lazyPower> if it doesn't let me know and i'll ping the parties working on amulet.
[14:30] <lazyPower> that behaviour should have been triaged in 1.4.x of amulet
[14:30] <gnuoy> lazyPower, thanks, I'll give it a whirl
[14:43] <cruisibesares> Hey all i have asked this question last night be im guessing everyone was asleep. I have a physical infrastructure that im running with maas and a cloud in aws. I would like to manage both of these providers with one juju server. Im looked over all the questions concerning juju and maas on ask ubuntu and i found this http://askubuntu.com/questions/181880/does-each-juju-environment-specified-require-its-own-master-node which seems
[14:43] <cruisibesares>  to sugest that you need one juju machine per enviornment. Im wondering if that is still true or if what i want to do is possible using manual provisioning
[14:46] <cruisibesares> i think my main concern is that juju isn't ha and i would like to keep my single point failure on aws
[14:47] <cruisibesares> it has a higher uptime guarantee and more tools
[14:47] <cruisibesares> that and the point of the physical hardware im deploying is to be cheap and expendable
[14:49] <lazyPower> cruisibesares: we don't have cross environment relationships yet. You can do it with the manual provider, but as the provider name implies, there's manual effort involved in it.
 thanks
[14:50] <lazyPower> Its on the roadmap, but i don't have an ETA for X-environment implementation. So at best, you'll want to do 2 bootstrap nodes, one for your maas cluster one for aws, or go manual and do enlistment manually.
[14:51] <lazyPower> cruisibesares: sorry i don't have a better answer for you than 'its coming' :(
[14:51] <cruisibesares> ok great thats really helpful i will consider both of those options thanks so much
[14:51] <cruisibesares> no thats totally fine i get that there is a lot on the roadmap
[14:52] <lazyPower> Yep, features galore are coming in this iteration. I think we have it up for the iteration after this - but that's uncertain. It's still mid to high priority though.
[14:52] <lazyPower> are you on the mailing list? You'll get notices of what lands in teh changelog on the mailing list.
[14:52] <cruisibesares> so now i will just have to gamble on which setup will have cleanest update path
[14:53] <cruisibesares> no im not on the mailing list yet
[14:53] <cruisibesares> thats on the main page for juju?
[14:53] <lazyPower> https://lists.ubuntu.com/mailman/listinfo/juju
[14:54] <lazyPower> you may want to ping the list with your question for other community members that have taken one route vs another - and get feedback. Kind of a straw poll to speak - and see if their experiences align with your goals.
[14:54] <lazyPower> I'm running a manual provider setup between Do and Softlayer that has been pretty solid.
[14:54] <lazyPower> but I'm a minority in that aspect.
[14:55] <lazyPower> and working with a true bootstrap node in the environment that does enlistment for me - is sorely missed. Its not *that* big of a deal to manually enlist but if i were scaling > 10 machines, i'd want this all to be automated for me.
[14:55] <cruisibesares> great idea
[14:55] <lazyPower> Given that you're running with maas and aws - both of which have full providers, it would probably be best to go that route and put some glue around it.
[14:56] <lazyPower> depending on your scaling future :)
[14:56] <cruisibesares> alright well its good to know people are doing it manually
[14:56] <cruisibesares> alright cool i'll try and send something to the mailing list soon
[14:56] <cruisibesares> thanks for your ideas and help
[14:56] <cruisibesares> will give me something fun to play with while i wait :)
[15:02] <lazyPower> anytime
[15:03] <gnuoy> lazyPower, fwiw I've raised Bug#1319437 for the amulet issue
[15:03] <_mup_> Bug #1319437: Amulet breaks when inspecting the relation-sentry regarding charms not in charmstore <Amulet:New> <https://launchpad.net/bugs/1319437>
[15:04] <lazyPower> thanks gnuoy! i'll poke the fellas and let them know
[15:04] <gnuoy> np, thanks for the help
[15:07] <lazyPower> gnuoy: from the creators mouth - <marcoceppi> it's doing the right thing, it assuems OH YOU'RE NOT A LOCALCHARM, LETS USE THE API HERP DERP
[15:07] <lazyPower> so you found a valid corner case, it'll get addressed soon.
[15:07] <gnuoy> lazyPower, it breaks in the same way if the charm is in a local directory rather than lp
[15:08] <lazyPower> gnuoy: should land in 1.5.1
[15:08] <gnuoy> kk
[15:14] <marcoceppi> yay, being quoted verbatium from another channel
[15:34] <pindonga> hi, anyone around to help me with running juju locally? I'm running on trusty, but after an upgrade path from saucy
[15:34] <pindonga> I can't get juju to create the machines with the local provider properly
[15:34] <pindonga> keep getting: WARNING juju.worker.instanceupdater updater.go:231 cannot get instance info for instance "": no instances found
[15:34] <pindonga> I had lxc already set up previously, so I assume this must be an issue with lxc (mis)configuration
[15:34] <cjohnston> wallyworld_: I'm a little confused.. is bug #1306537 fixed in 1.18.3 in the PPA?
[15:35] <_mup_> Bug #1306537: LXC local provider fails to provision precise instances from a trusty host <deploy> <local-provider> <lxc> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Fix Released by wallyworld> <juju-quickstart:Fix Released by frankban> <juju-quickstart (Ubuntu):New> <juju-quickstart (Ubuntu Trusty):New> <https://launchpad.net/bugs/1306537>
[15:51] <lazyPower> sinzui: looks like apparmor is going to be a troublemaker this time around - https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1296384
[15:51] <_mup_> Bug #1296384: LXC apparmor profile broken w/recent trusty update <amd64> <apport-bug> <trusty> <AppArmor:Confirmed> <apparmor (Ubuntu):Triaged> <https://launchpad.net/bugs/1296384>
[15:54] <sinzui> lazyPower, looks like Ubuntu is still ignoring bug 1305280
[15:54] <_mup_> Bug #1305280: apparmor get_cgroup fails when creating lxc with juju local provider <apparmor> <armhf> <local-provider> <lxc> <packaging> <regression> <juju-core:Invalid> <apparmor (Ubuntu):Confirmed> <https://launchpad.net/bugs/1305280>
[15:55] <avoine> pindonga: can you tell me what is your version of lxc + juju-core?
[15:56] <pindonga> avoine, lxc==1.0.3-0ubuntu3 , juju-core==1.18.1-0ubuntu1
[15:57] <cjohnston> pindonga: I wonder if your having bug #1306537 too
[15:57] <_mup_> Bug #1306537: LXC local provider fails to provision precise instances from a trusty host <deploy> <local-provider> <lxc> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Fix Released by wallyworld> <juju-quickstart:Fix Released by frankban> <juju-quickstart (Ubuntu):New> <juju-quickstart (Ubuntu Trusty):New> <https://launchpad.net/bugs/1306537>
[15:58] <avoine> pindonga: what lxc-ls gives you?
[15:59] <pindonga> exit 0 (no output)
[16:02] <pindonga> cjohnston, it's possible, I'm trying to deploy a charm for testing with default-series: trusty, and it looks like something is happening (taking it's time though)
[16:02] <pindonga> and it just failed with: (error: error executing "lxc-start": command get_cgroup failed
[16:02] <pindonga>       to receive response)
[16:04] <cjohnston> there's also bug #1317197 but I'm not sure that'd be it if your getting a cgroup issue
[16:04] <_mup_> Bug #1317197: juju deployed services to lxc containers stuck in pending <oil> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1317197>
[16:15] <pindonga> thx cjohnston the title looks promising, will take a deeper look after lunch
[16:15] <cjohnston> :-)
[16:35] <_mup_> Bug #1319474 was filed: Juju uses hard-coded regions <pyjuju:New> <https://launchpad.net/bugs/1319474>
[16:36] <cjohnston> lazyPower: I have an ansible question for you if you have a moment
[16:38] <_mup_> Bug #1319475 was filed: Juju should support new signing format <pyjuju:New> <https://launchpad.net/bugs/1319475>
[16:49] <didrocks> jcastro: https://github.com/juju/docs/pull/97 mind having a look?
[16:57] <jcastro> on it
[16:57] <jcastro> don't know how I missed that, thanks!
[17:02] <lazyPower> cjohnston: shoot - sorry about the delay was away from my desk.
[17:02] <didrocks> yw man ;)
[17:02] <cjohnston> lazyPower: np..
[17:03] <lazyPower> sinzui: tyhicks in #ubuntu-server has confirmed the apparmor bug is duplicated by one that was supposed to be fixed in reprelease.
[17:03] <lazyPower> *prerelease
[17:03] <lazyPower> cjohnston: but fire when ready :)
[17:03] <cjohnston> lazyPower: I have http://paste.ubuntu.com/7463732/ ... however, it's failing that 'user' isn't found.. I added the when because it was failing for the same reason when I didn't have the when..
[17:04] <cjohnston> I'm wondering if there is something else I should be doing, or maybe if I should add some sort of repeat type something?
[17:04] <cjohnston> It seems like I'm just not getting back the relation data quick enough for ansible
[17:04] <lazyPower> cjohnston: "'user' doesnt' seem like it would expand. Ansible playbooks expand jinja2 variable syntax as of 1.6
[17:04] <lazyPower> so wouldn't it be {{user}}
[17:05] <lazyPower> they depreciated the older style of variable notation using $'s, and i think what you're seeing is related. but i'm not positive.
[17:05] <cjohnston> I tried that.. but I got an error.. let me try it again and see if I can figure the error
[17:06] <lazyPower> capture the error for me and i'll take a look.
[17:06] <cjohnston> ack
[17:27] <cjohnston> lazyPower: http://paste.ubuntu.com/7463825/
[17:29] <lazyPower> cjohnston: looking, 1 sec
[17:29] <lazyPower> cjohnston: where's your line defining user?
[17:29] <lazyPower> there sh9ould be a register play in your playbook that defines the username.
[17:29] <lazyPower> or is it a config option on the charm?
[17:31] <cjohnston> lazyPower: AIUI charmhelpers automatically makes everything in the /etc/ansible/host_vars/localhost available.. is that not the case?
[17:36] <avoine> cjohnston: have you tried without all the quotes single and double?
[17:38] <cjohnston> avoine: based on http://docs.ansible.com/playbooks_conditionals.html#applying-when-to-roles-and-includes when: "'reticulating splines' in output" <-- is how I was operating
[17:41] <cjohnston> Is that not correct?
[17:41] <avoine> I think when you use a variable name instead of plain text you don't need the single quotes
[17:42] <cjohnston> "{{ user }} in current_relation" <-- is what I just tried that gave the traceback I pasted
[17:43] <lazyPower> cjohnston: thats correct
[17:44] <avoine> I would try: user in current_relation
[17:45] <cjohnston> lazyPower: which part are you saying is correct
[17:45] <lazyPower> Thjat the ansible helpers make all config values global keys in the playbook.
[17:46] <lazyPower> i didn't know if that was coming from a config value or from your play
[18:21] <lazyPower> cjohnston: thats strange that its undefined though...
[18:21] <lazyPower> i'm nto sure what to recommend here.
[18:22] <lazyPower> syntax looks fine
[18:39] <balloons> wwitzel3, ah-hah, I've found you after all. heh. Glad I didn't bike, would have been a wet ride
[18:39] <cjohnston> lazyPower: well.. avoine's suggestion didn't cause an error
[18:48] <tvansteenburgh> balloons: o/ (Tim from lunch)
[18:49] <balloons> o/
[19:20] <onezero> Trying to deploy using the "manual" environment via which my bootstrap node will be in an already existing "juju-server" machine.  How do I change the port.  I see bootstrap-host: however there is no "bootstrap-port:" and appending the port at the end of the hostname doesn't work.  Any ideas?
[19:20] <marcoceppi> onezero: it's not a good idea to bootstrap the same server twice
[19:21] <onezero> Why?
[19:21] <onezero> I'm using a docker container.
[19:21] <marcoceppi> onezero: because, juju isn't designed to host more than one bootstrap on a single machine
[19:21] <marcoceppi> you can deploy services to the bootstrap node, but a single node can't have more than one bootstrap running on it
[19:23] <marcoceppi> onezero: I think there might be a communciation issue between bootstrapping and deploying
[19:23] <onezero> In my case a vm is entirely dedicated as a juju server and that's the only function it serves.  It seems like a waste to create a whole new vm for each additional environment...
[19:24] <marcoceppi> onezero: well, you can deploy services to that VM, but that one VM also controls any and all other VMS you wish to spin up in that environment
[19:24] <marcoceppi> it's the orchestration service for that environment
[19:25] <onezero> So basically, if I want to orchestrate multiple environments... I need multiple actual servers.
[19:25] <onezero> One juju server per environment
[19:26] <marcoceppi> onezero: you need atleast one server per environment
[19:27] <marcoceppi> an environment can have 1+ severs which can have n+ charms deployed on to it (either using the whole machine or using containerization kvm, lxc, etc)
[19:27] <marcoceppi> on to it, being on to any of the servers in the environment
[19:28] <marcoceppi> with manual provider you can enlist an additional machine by running juju add-machine <user>@<machine>
[19:28] <marcoceppi> which will make it available in that environment
[19:32] <onezero> I just wanted to keep the orchestration (ie juju bootstrapped node) separated from the actual servers that are being orchestrated.  Basically I have a maas cluster which is my first environment for which I bootstrapped a single vm to serve only that singular purpose of juju orchestration.  Next I have some servers NOT part of maas that I would like to manually deploy charms to... but in order to do that I created a new manual environment in my yaml config.  I
[19:34] <marcoceppi> onezero: yeah, so you want something like cross environment relations, which is on the roadmap but probably won't happen in the next few months
[19:34] <marcoceppi> onezero: you can create a KVM or LXC on the maas bootstrap node
[19:34] <marcoceppi> and use that as your manual provider bootstrap node
[19:35] <marcoceppi> the main problem is there's not isolation, so juju-db will stomp all over itself
[19:35] <marcoceppi> but if you put the bootstrap node in a container inside an existing bootstrap node, there's no real collison
[19:42] <onezero> marco... THANKS a bunch.  Glad to get confirmation of that.
[19:56] <rick_h_> mbruzek: around?
[19:56] <mbruzek> Yes
[19:57] <rick_h_> hey, see PM
[20:12] <l1l> Ok folks, could use some help..
[20:12] <l1l> This is a error I get when trying to view a juju status -e maas
[20:13] <l1l> ERROR state/api: websocket.Dial wss://tngek.maas:17070/: dial tcp: lookup tngek.maas: no such host
[20:16] <jose> l1l: afaik that's because bootstrap hasn't finished
[20:16] <l1l> jose; The machine is already booted, and I can ssh into it.
[20:17] <jose> l1l: bootstrap does some additional things as it needs some tools to be the master :)
[20:17] <jose> did your 'juju bootstrap' finish?
[20:19] <l1l> Yes, it finished with no errors and the node booted up. However, when I try to check the juju status I get that error repeating
[20:21] <jose> hmm, that's weird
[20:21] <jose> maybe someone else would be able to help
[20:22] <l1l> I have googled till blue in the face and have found similiar bugs, but they see a "connection refused" instead of the "no such host". It's apparently related to DNS.
[20:22] <l1l> Thanks though!
[20:22] <jose> np :)
[20:31] <andreas__> l1l: add "nameserver <maas-ip>" to the top of your /etc/resolv.conf temporarily
[20:32] <ahasenack> there might be a way to tell your local resolver to only use that DNS for the .maas domain
[20:35] <ahasenack> dnsmasq has the --server option which seems to suit well, but I haven't used it
[20:37] <l1l> ahasenack; Adding that to the resolv.conf fixes it. So time to point the finger at maas-dns ?
[20:37] <ahasenack> l1l: no
[20:38] <ahasenack> l1l: maas is controlling that zone, so you need to use it for dns when talking to machines in that zone
[20:38] <ahasenack> it's as simple as that
[20:38] <ahasenack> now, that change you just made should be temporary, because that means all your other name resolution queries will go to maas, even the ones that have nothing to do with maas
[20:38] <ahasenack> like google.com, gmail, etc
[20:39] <l1l> Yea, wonder how I can make maas just use that zone.
[20:39] <ahasenack> see man dnsmasq, look for the -S option
[20:40] <ahasenack> and I think you can add a similar option to /etc/dnsmasq.conf, but I haven't tried
[20:40] <ahasenack> would be a way to tell your local resolver, assuming you are on ubuntu and using dnsmasq (the default), to only use the maas dns for resolving names in the .maas domain
[20:40] <ahasenack> that would be on your machine, where you are issuing juju commands, btw
[20:41] <ahasenack> the maas nodes are already using the right dns
[20:41] <l1l> odd, I dont have that dnsmasq.conf
[20:43] <ahasenack> I think ubuntu works with snippets in dnsmasq.d
[20:43] <ahasenack> there might be ubuntu specific documentation about this
[20:43] <ahasenack> I also see a /etc/dnsmasq.d-available/
[20:44] <l1l> hmm, I don't see anything todo with dnsmasq in the /etc dir
[20:47] <ahasenack> I'm on trusty, if that makes a difference
[20:47] <ahasenack> oh, and on a desktop
[20:47] <ahasenack> $ dpkg -S /etc/dnsmasq.d
[20:47] <ahasenack> network-manager: /etc/dnsmasq.d
[20:47] <ahasenack> you might not have network-manager
[20:51] <l1l> does a server install not get the network-manager?