[00:55] <bloodice> I have different physical servers i want to use for specific packages.  Is there a way to link the MAAS name and setup to a specific machine in Juju?  This would allow me to allocate the charms to the appropriate servers.
[01:32] <blahdeblah> bloodice: We use MAAS tags for that
[02:03] <thumper> lazyPower: damn... elasticsearch is failing the install hook now
[02:03] <thumper> apt.cache.FetchFailedException: W:Failed to fetch http://packages.elasticsearch.org/elasticsearch/1.2/debian/dists/stable/main/binary-amd64/Packages  403  Forbidden
[02:04] <thumper> lazyPower: I hope it is intermittent and temporary
[02:21] <jose> thumper: that looks like an error server-side, probably moved files or changed to https
[02:21] <jose> not moved files, but changed paths
[07:47] <lazyPower> https://askubuntu.com/questions/576500/juju-bundle-deploy-in-one-machine-in-lxc/579585#579585
[08:39] <seal> lazyPower: o/
[08:39] <lazyPower> o/ seal
[08:40] <seal> is there a particular order in which to execute the flannel-docker?
[08:40] <seal> I was unable to communictae with other host
[08:40] <seal> will post the order which I ran it in a sec
[08:41] <lazyPower> seal: the order dependencies were resolved in the latest iteration of the charm i do believe.
[08:41] <seal> http://paste.ubuntu.com/9952491/
[08:41]  * lazyPower looks
[08:42] <lazyPower> hmm, that looks correct to me - can you get me the output of `juju run --service docker 'ifconfig -a'` ?
[08:43] <lazyPower> sorry, docker-api, in your given example.
[08:43] <lazyPower> hmm, that looks correct to me - can you get me the output of `juju run --service api-docker 'ifconfig -a'` ?
[08:43] <seal> sorry this the correct code http://paste.ubuntu.com/9952527/
[08:44] <lazyPower> so, you've got a single docker host, and you've made the connections to ETCD and flannel - which should have setup the docker0 bridge. This is why i want to take a peek at ifconfig -a to see whats going on with the docker0 bridge adapter.
[08:45] <seal> ok one sec will set it up quickly and ping you if you are still around
[08:45] <seal> destroyed the last environment :)
[08:59] <lazyPower> ok, np seal
[14:08] <rbasak> sinzui: src/bitbucket.org/kardianos/osext/LICENSE is wrong. It's been fixed upstream though.
[14:08] <sinzui> :/
[14:08] <rbasak> sinzui: can you arrange to pull the latest in please, assuming that doesn't break any dependants?
[14:09] <sinzui> I will
[14:09] <rbasak> sinzui: it might be worth instituting a licence review policy before permitting changes to dependencies.tsv.
[14:09] <rbasak> Thanks
[14:09] <sinzui> rbasak, I think it will be after the fact, engineers change deps all the time. I think we need a report of what change for review every week
[14:12] <rbasak> sinzui: OK
[14:13] <rbasak> sinzui: this isn't a blocker. Logically I think it's acceptable as it's fixed upstrema, and I've written a note accordingly.
[14:21] <sinzui> rbasak, I reported bug 1416425 and am handing it off to developers
[14:21] <mup> Bug #1416425: src/bitbucket.org/kardianos/osext/LICENSE is wrong <licensing> <packaging> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416425>
[14:25] <rbasak> sinzui: thanks. Next...
[14:25] <rbasak> sinzui: why has juju/cmd changed license?
[14:26] <rbasak> sinzui: I don't mind particularly, but I do have to update the copyright file to follow all these changes, and it's not optimal for me to discover these all in the diffs.
[14:26] <rbasak> It's driving me up the wall a little right now.
[14:27] <sinzui> rbasak, I don't know about the change, sorry. I will ask
[14:28] <rbasak> sinzui: it's not so much that it changed, but more that it feels like these changes are almost slipping past me. We should sort out a process so that I can follow licensing issues and changes more easily.
[14:30] <sinzui> rbasak, Noted. I will bring this up as an issue in the release meeting in 2 hours. We will need a policy to catch and review licensing changes before we *consider* a release
[14:31] <rbasak> Thanks.
[14:39] <rbasak> sinzui: github.com/juju/syslog has an incorrect LICENSE file.
[14:40] <rbasak> Google's third clause has been removed.
[14:40] <sinzui> :(
[14:41] <rbasak> Not fixed upstream. Can I leave this one with you? I think if it's fixed upstream it's OK to take it.
[14:41] <rbasak> (without updating it, for now)
[14:44] <sinzui> rbasak, I am confused https://github.com/juju/syslog/blob/master/LICENSE shows me a bsd 2-clause license. How does this relate to google?
[14:47] <rbasak> sinzui: right, but for example https://github.com/juju/syslog/blob/master/syslog.go refers to the Go LICENSE which hasn't been shipped.
[14:48] <sinzui> ah
[14:48] <sinzui> thank you rbasak
[14:48] <rbasak> sinzui: it seems that the author derived from Go, but just included some arbitrary LICENSE file instead of the Go LICENSE file.
[14:48] <rbasak> No problem.
[14:48] <rbasak> I'll keep slogging through.
[14:49] <rbasak> sinzui: next question. https://github.com/juju/testing/issues/32 hasn't been addressed. Is this reported to the right place?
[14:50] <sinzui> rbasak, possibly not. I report bugs against https://bugs.launchpad.net/juju-core when I want core engineers to fix the issue. I don't think the team reads github issues unless pressed
[14:53] <skay> we are sedding some juju status output to get the instance id, and I was wondering if there is a nicer way to do that? juju status <service> <field> doesn't exist but would it be nice?
[14:53] <rbasak> OK, I'll copy it over.
[14:54] <rbasak> Copied to https://bugs.launchpad.net/juju-core/+bug/1416430, thanks.
[14:54] <mup> Bug #1416430: Some files refer to an include license file that is not included <licensing> <juju-core:New> <https://launchpad.net/bugs/1416430>
[14:55] <rbasak> sinzui: next issue. juju/utils introduced a bunch of files claiming AGPLv3, refering to a LICENSE file, when all other files are LGPLv3 and so is the LICENSE file.
[14:55] <rbasak> Should these be LGPLv3?
[14:56] <sinzui> I don't know, but I agree that LGPLv3 is right.
[14:57] <sinzui> rbasak, I suspect someone moved code and didn't check the license when they moved it
[14:57] <rbasak> Yeah that sounds likely.
[14:58] <rbasak> I'm going to stop now. I'll carry on later. Probably next week.
[14:58]  * skay discovers --json and is much happier
[14:58]  * skay means --format not --json
[15:01] <sinzui> rbasak, I will report a bug about the utils issue. For each licensing bug, I have target 1.23, 1.22, and 1.21, and we can see people are working on them https://bugs.launchpad.net/juju-core/+milestone/1.21.2
[15:09] <jamespage> rick_h_, hey - is there a way to use juju-gui in a do what I tell you mode
[15:10] <jamespage> updating bundles that use lxc containers etc... is a pita right now as I appear to have to use  MAAS environment todo the updates
[15:11] <rbasak> sinzui: thanks
[15:14] <rick_h_> jamespage: not following. You mean without the commit stage?
[15:14] <jamespage> rick_h_, I really just want a demo environment where I can tweak things
[15:14] <jamespage> rick_h_, but the demo online appears to ignore machine placements
[15:14] <rick_h_> jamespage: you mean have it work like the demo url?
[15:15] <jamespage> rick_h_, yup
[15:15] <rick_h_> jamespage: oh, hmmm, how are you defining machines? it should support what it exports.
[15:15] <rick_h_> jamespage: so to put it in the same mode there's a sandbox setting on the gui to set
[15:15] <rick_h_> jamespage: looking for exact config attr
[15:16] <rick_h_> jamespage: juju set juju-gui "sandbox=true"
[15:16] <jamespage> rick_h_, this bundle - https://jujucharms.com/u/openstack-charmers/openstack/
[15:22] <rick_h_> jamespage: so few things. One, that sandbox setting should get you into a 'demo mode' and the bundle.yaml you dump out from the gui should reimport with drag/drop.
[15:22] <rick_h_> jamespage: looking your bundle doesn't show in the old api so not sure what's up. looking into it
[15:24] <aisrael> Is there a safe way to compact juju's monodb database?
[15:26] <rick_h_> jamespage: loading up for flight but if you need anything hit up hatch or frankban and they'll help out.
[15:57] <jamespage> hatch, frankban: when I import/export that bundle through a gui in sandbox mode, I lose the machine placement - any ideas?
[15:58] <hatch> jamespage: sorry that's not yet implemented
[15:58] <jamespage> hatch, its not implemented in the sandbox mode?
[15:58] <frankban> jamespage: the GUI does not support machine placement in bundles yet
[15:58] <jamespage> frankban, really?
[15:59] <hatch> frankban:  I thought that was only in sandbox mode
[15:59] <jamespage> frankban, but I created this bundle on a MAAS deployment using juju-gui ?
[16:00] <frankban> hatch: oh, so we have machine placement (as defined by the new bundle spec) in real env in the GUI?
[16:01] <hatch> hmm - I'm not actually confident on that now :)
[16:01] <hatch> let me look at the source
[16:02] <frankban> hatch: thank you
[16:04] <hatch> frankban: looks like it just passes the bundle file through so as long as the deployer supports it...
[16:04] <hatch> jamespage: is it not working for you in a real env or just in sandbox mode?
[16:04] <jamespage> hatch, it worked ok on a MAAS environment (import/export)
[16:05] <jamespage> hatch, but that's a pita for doing a small change to a bundle
[16:05] <hatch> that's a good point - you are able to modify the file manually though
[16:05] <jamespage> hatch, but not for sandbox - as soon as I import the bundle it looses its placement data
[16:05] <jamespage> hatch, I was able to modify the file manually
[16:05] <hatch> yeah sandbox is definitely not supported for those machines
[16:05] <hatch> er machine placement
[16:06] <hazmat> hatch, gui doesn't export placement data?
[16:07] <hatch> hazmat: it doesn't support placement data on import in sandbox mode. I'm just tracing the export code now (it's been a bit since I've been in there)
[16:11] <hatch> hazmat: if I'm reading the code correctly it should be exporting machine placement data as well
[16:12] <hatch> jamespage: so you would like to import a bundle file into sandbox so that you can modify it without hacking on the yaml file directly?
[16:22] <jamespage> hatch, +1 yes please
[16:23] <hatch> jamespage: would you be able to create a bug to that effect?
[16:26] <jamespage> hatch, I can do that
[16:31] <hatch> jamespage: thanks!
[16:32] <hazmat> hatch, its annotating x/y gui placement, but machine placement?
[16:33] <hatch> I don't understand the question
[16:34] <hazmat> hatch, its not exporting unit to machine placement, just service x/y on canvas
[16:36] <hatch> hazmat: ok I'll have to look into that because according to the export code it should be exporting the machine placement details
[16:37] <hazmat> hatch, not sure how, unless its storing placement as annotation, that info is loss and would have to be inferred. anyways, not seeing that on demo.jujucahrms.com
[16:37] <rick_h_> hazmat: jamespage we decided not to implement deployer logic in JS for importing with placement hoping we were going to get core support and skip that.
[16:37] <hatch> hazmat: https://github.com/juju/juju-gui/blob/develop/app/models/models.js#L2320
[16:38] <rick_h_> hazmat: jamespage but as priorities go that's a decision from last sprint we should look at again as it's something we should give users
[16:38] <jamespage> export is ok
[16:39] <rick_h_> jamespage: correct, and atm there's a bug in export hatch is looking at. I think we missed an update as we've upgraded to the new charmstore api and that should be a quick fix hopefully.
[16:39] <hazmat> hatch, interesting, might be a bug, that looks like its trying to infer it, but its not triggering on demo site in sandbox
[16:42] <hatch> hazmat: ok I'll be sure to check that out - I'm now fixing an export bug which was just discovered
[18:18] <bloodice> I have different physical servers i want to use for specific packages.  Is there a way to link the MAAS name and setup to a specific machine in Juju?  This would allow me to allocate the charms to the appropriate servers.
[21:38] <bloodice> I have different physical servers i want to use for specific packages.  Is there a way to link the MAAS name and setup to a specific machine in Juju?  This would allow me to allocate the charms to the appropriate servers.
[21:38] <stokachu> bloodice: --to option
[21:39] <bloodice> That lets me select the machine, but there doesnt seem to be a way for me tell juju when i create a machine which server to take from MAAS
[21:40] <stokachu> bloodice: when you juju bootstrap?
[21:43] <bloodice> well, when i bootstrapped, it just grabbed a server
[21:43] <stokachu> bloodice: yep do juju bootstrap --to <maas-hostname>
[21:44] <bloodice> but after the gui is up and running, there doesnt seem to be a way to say "i want this specific server in MAAS"
[21:44] <stokachu> not sure about the gui, but cli you use --to <hostname>
[21:44] <bloodice> so after Juju is online, i can go into the console and create a machine with the --to command using the maas hostname?
[21:45] <stokachu> bloodice: yep
[21:46] <bloodice> hrm
[22:43] <bloodice> i ran this command "juju deploy --to c7yra.maas mysql" and i get: invalid --to parameter "c7yra.maas"
[22:44] <bloodice> i tried "juju add-machine --to c7yra.maas" and got: error: flag provided but not defined: --to
[22:53] <bloodice> ack, ok, i got it to work, but i really dont like it...  i needed to use the tag feature, so "juju add-machine --constraints tags=c7yra.mass"
[22:55] <bloodice> it just adds a machine with a number, but i have no way of seeing that 8 is server c7yra.mass in the gui.  Status does show the server name though.
[22:57] <bloodice> welp, that doesnt work anyhow... status says:  ({"tags": ["No such tag(s): ''c7yra.maas''."]})'
[23:08] <heartones> can any one help with JuJu installation I am getting not able to connect: Permission denied (publickey,password).
[23:19] <sebas5384> just passing to drop something I did the other night for Juju + Vagrant https://github.com/sebas5384/vju