[00:10] <roaksoax> bigjools: thanks!
[00:10] <bigjools> back at ya
[00:54] <Azendale> Is there anywhere to set what targets to get ephemeral images for (in my case I only want saucy and amd64 and i386) when I run maas-import-pxe-files?
[05:57] <bigjools> jtv: have you ever seen the wsgi wrapper failing to start up, complaining about "Connection reset by peer" ?
[05:58] <bigjools> it's trying to run refresh_nodegroup so I suspect rabbitmq is being crap
[06:32] <bigjools> rvba: I have spent all freaking day chasing trivial problems so I can get to examine this bug of yours on my home server
[06:32] <bigjools> *still* have not fixed all the problems
[06:33] <rvba> bigjools: trivial problems in MAAS or juju-core?
[06:33] <bigjools> for some reason, the juju binary on my maas test server is producing a totally bogus Auth header, so maas kicks everything out with a 401
[06:33] <bigjools> this is my last blocker
[06:33] <bigjools> same binary works on canonistack and elsewhere
[06:33] <bigjools> so.... I am at a loss
[06:34] <rvba> hum…
[06:35] <rvba> I'd draw my McGyver kit and log things inside piston's code to get to the bottom of the error…
[06:35] <bigjools> it;s not maas
[06:35] <bigjools> it's juju
[06:36] <bigjools> the auth header is wrong
[06:36] <rvba> Right, but in what way exactly?
[06:36] <bigjools> https://bugs.launchpad.net/juju-core/+bug/1239496
[06:36] <bigjools> that way
[06:37] <rvba> Very odd that I didn't see that problem at all in the lab…
[06:37] <bigjools> only happens on my home server
[06:38] <rvba> The only obvious difference is realm="MAAS+API" (sent by juju).
[06:39] <bigjools> not so
[06:39] <bigjools> check the token
[06:39] <bigjools> and signature
[06:43] <rvba> Well, they differ but that's normal.
[06:43] <rvba> Their size are similar.
[06:43] <rvba> That's the only check that my naked eye can do.
[06:44] <bigjools> rvba: the difference is not normal
[06:45] <bigjools> I compared headers from maas-cli and an old juju and they were almost identical
[06:45] <bigjools> these ones are vastly different
[06:45] <rvba> The timestamp and the nonce are used to compute the signature.
[06:45] <rvba> "almost identical"?
[06:46] <bigjools> signature was different but token was the same
[06:46] <bigjools> in this example token is not the same
[06:48] <rvba> Hum, you're right, the token should be the same…
[06:48] <rvba> Did you inspect the DB to see what the tokens are in there?
[06:54] <bigjools> no
[06:55] <bigjools> rvba: having said that, I just got one to work and the token sent is different
[06:56] <rvba> If your juju conf hasn't changed, that is weird.  The token should be dictated by your api key.
[06:57] <bigjools> rvba: I see different tokens on different requests
[06:57] <rvba> Maybe I'm missing something then…
[06:59] <bigjools> rvba: my bad - it was a celery request I had in there ...
[06:59] <bigjools> see the last comment on the bug
[07:03] <rvba> bigjools: replied…
[07:03] <bigjools> rvba: see #maas
[07:07] <rvba> bigjools: you're definitely right, the whole point of having different API keys that can be changed is to accommodate the case where the credentials are compromised.
[07:08] <bigjools> rvba: people are also using them for different juju environments
[07:08] <bigjools> hence my other bug
[07:08] <bigjools> but we need to talk about that scenario anyway
[07:32] <bigjools> rvba: I am fast-installing one of my microservers - so far 15 minutes later nothing going on
[07:32] <bigjools> I guess it's broken - possibly with this bug
[07:32] <rvba> bigjools: not normal, I *just* used it in the lab.
[07:33] <bigjools> the --commission thing I suspect
[07:33] <bigjools> but can't get in to the node to find out ...
[07:33] <rvba> --constraints you mean…?
[07:33] <bigjools> uhhhh yes :)
[07:33] <rvba> Try sshing into the allocated node.
[07:34] <rvba> The node should be up and running.
[07:34] <rvba> bigjools: check /var/log/cloud-init-output.log on that node… the last line should be the invocation of jujud with the empty --constraints.
[07:35] <bigjools> too late
[07:35] <rvba> bigjools: one workaround is to explicitly use constraints when bootstrapping.
[07:35] <bigjools> anyway juju status was dead
[07:35] <rvba> Another is to build from source.
[07:35] <rvba> It's normal, jujud is not up.
[07:35] <rvba> So juju status can't work.
[07:35] <rvba> But again, the bootstrap node should be up and running.
[07:35] <bigjools> soooooo, juju bootstrap --upload-tools seems to be broken
[07:35] <rvba> Only the juju side of things crashed.
[07:35] <rvba> ??
[07:36] <rvba> Well, if all the calls to the API are broken on your machine I'm not surprised.
[07:36] <bigjools> that's working now
[07:36] <rvba> Ah.
[07:37] <rvba> Then run juju bootstrap --upload-tools with "-v" to see what's going on.
[07:37] <bigjools> I did
[07:37] <bigjools> http://paste.ubuntu.com/6234893/
[07:37] <rvba> HAha
[07:37] <rvba> The dreaded EOF error.
[07:37] <rvba> Destroy and re-bootstrap.
[07:38] <bigjools> you know of this error
[07:38] <rvba> I've seen if from time to time unfortunately.
[07:38] <bigjools> same again
[07:39] <bigjools> happening every time
[07:39] <rvba> Weird.
[08:14] <gmb> allenap: When you've got a sec, can you take another look at https://code.launchpad.net/~gmb/maas/fix-bug-1184589/+merge/190601 for me?
[08:14] <allenap> gmb: Certainly can.
[08:14] <gmb> allenap: Although it hasn't pushed yet...
[08:14] <gmb> Bear with me; sudden LP FUBAR
[08:18] <gmb> Wups
[08:19]  * gmb kills the wget that was eating my bandwidth
[08:54] <rvba> bigjools: fwiw, allenap and I talked about the bug you were referring to in the call, here is a summary of the two options we talked about (one of which is using tags, the other one basically boils down to using the API key itself as you suggest): http://pad.ubuntu.com/DnNONX6kFB
[08:55] <rvba> bigjools: well, more precisely, we didn't think of using the API key but to use the environment's UUID to flag the nodes.
[08:55] <rvba> bigjools: so your idea of using the API key is a third option.
[08:56] <bigjools> ok
[08:56] <bigjools> let's talk pros and cons
[08:57] <rvba> bigjools: well, the first thing to do is to list what it means doing first… because I'm still a bit fuzzy on that…
[09:05] <rvba> allenap: care to review: https://code.launchpad.net/~rvb/maas/change-freq/+merge/190894 ?
[09:05] <allenap> rvba: Sure.
[09:06] <allenap> rvba: Done!
[09:06] <rvba> Thanks.
[09:07] <allenap> gmb: Sorry, I wrote the updated review for your wrapper branch then forgot to submit when the team call started.
[09:10] <allenap> bigjools, rvba: Fwiw, I don't think we should use API key, because the ability to share an environment between people but using different API keys will go away. Perhaps a hash based on admin-secret. Something that comes from Juju anyway.
[09:11] <rvba> bigjools: as I said before, I agree with allenap.  The ability to use a different key without losing one's environment seems pretty important to me.
[09:12] <rvba> bigjools: what allenap suggest is the option 2 in http://pad.ubuntu.com/DnNONX6kFB.
[09:12] <rvba> We discarded it at the time in favor of the tag solution because solution 1 seemed simpler and it didn't imply making changes in MAAS for the solve purpose of accommodating juju.
[09:14] <lifeless> MAAS kind of exists to support juju though, right?
[09:14] <bigjools> rvba, allenap: +1
[09:15] <allenap> rvba: I guess the tag is interesting because it does expose to others those nodes that are part of an environment.
[09:15] <allenap> lifeless: Shhhh ;)
[09:15] <rvba> lifeless: true, but it is better to let juju use generic stuff (tags) as opposed to doing thing juju-specific in juju.
[09:15] <rvba> in MAAS*
[09:15] <allenap> lifeless: You're right though. We're just trying to be constructively lazy.
[15:54] <bladernr_> is there an armhf port of maas and dependencies?  I'm (just for fun) trying to install MAAS on an arm system to use as a region and cluster controller.  This is just a crazy idea I had that is fraught with peril, but I thought I'd try for the lulz.
[15:56] <roaksoax> rvba: howdy!!
[15:56] <roaksoax> rvba: so I see there are more fixes than last week
[15:56] <roaksoax> rvba: are you looking to SRU those too?
[15:58] <rbasak> bladernr_: yes, there is. No specific port needed. It Just Works. Additionally, there is support for some armhf server hardware.
[15:59] <rbasak> (ie. to bootstrap armhf server machines to use as nodes)
[15:59] <rbasak> To use MAAS as a region or cluster controller on armhf should Just Work, providing of course that Ubuntu is supported on that particular system. Please file bugs appropriately.
[16:00] <bladernr_> rbasak: so the rub is that my secret project is putting maas, maas-region-controller and maas-cluster-controller on a raspberry pi… it's currently running a debian port (Raspbian) since Ubuntu doesn't support armv6.
[16:00] <bladernr_> so I'm trying to run maas in a non-ubuntu environment
[16:01]  * bladernr_ hides
[16:01] <rbasak> That's not supported of course, as you already understand. You may have some issues with dependencies and perhaps have to port the occasional Ubuntu patch. Perhaps difficult depending on the relevant experience for the person doing it, but tractable IMHO.
[16:02] <rbasak> Really what you'd be doing is porting MAAS to Debian, rather than doing anything ARM-specific I think.
[16:03] <bladernr_> hrmmm.. ok, that gives me an idea… thanks.
[17:13] <roaksoax> allenap: around?
[18:50] <allenap> roaksoax: What's up?
[23:33] <bigjools> roaksoax: https://bugs.launchpad.net/bugs/1239758
[23:33] <bigjools> odd....