[06:37] <ging> i've not been having much luck getting maas to work on 13.10 as the server, would going back to 12.04 give me something more stable or is the latest the best to go for?
[06:38] <bigjools> latest is best
[07:02] <ging> and for a commission ditro is 13.10 also still the best to use?
[07:03] <ging> or does that depend what actual distro you want to install?
[07:17] <bigjools> ging: we generally only test with precise for that
[07:18] <ging> ok i will leave it set on that
[07:34] <ging> what does provisioning from other distros gain for you? is it more stable / quick to provision from the distro you are installing?
[08:22] <jtv1> ging: not particularly, no.  But there might be some more recent driver your hardware needs.
[08:33] <ging> well i don't understand this at all, i have tried several provisioning images and they all fail once the machine is installed and tries to connect to the archive mirror
[08:35] <ging> does not seem to be a network issue because i can connect to the mirror with wget
[08:37] <ging> maybe it is a network issue
[08:38] <jtv> Then it may be a proxy issue.
[08:38] <jtv> The nodes download their packages via the proxy running on the region controller.
[08:38] <jtv> You could try if you can wget with the http_proxy variable set to that proxy.
[08:39] <ging> ah
[08:39] <ging> that will be why
[08:39] <jtv> Well it's only an idea of where to look for a possible problem.
[08:39] <jtv> Normally, this should just work.
[08:40] <ging> the proxy on the region controller is broken and i can't get it to work
[08:42] <jtv> It's squid-deb-proxy, if that helps.  You could see if it's running, and whether it logged anything.
[08:42] <ging> i had to manually disable it in user_data_config.template to get it as far as installing
[08:42] <ging> yeah something has gone completely wrong with it, as soon as anything connects to it it crashes
[08:42] <jtv> !
[08:43] <ging> i've done apt-get purge on it and delete all it's cached files and reinstalled but it still crashes
[08:43] <jtv> No log messages?
[08:44] <ging> http://pastebin.com/Bi8JTGxx
[08:45] <ging> it is very strange i've been asking in the squid channel see if anyone can make sense of it
[08:46] <ging> i've given the server 16 gig of ram just incase it was lack of memory
[08:46] <jtv> Well it's not plain squid, it's squid-deb-proxy.  I'd look there primarily, just because it'll get less use.
[08:47] <jtv> If all use of squid-deb-proxy uses squid, then squid probably gets a lot more testing etc.
[08:47] <jtv> Whoa.  That looks like a corrupted file.
[08:48] <jtv> Or just perhaps a problem with the hardware — let's hope not.
[08:48] <jtv> Something you could try is to purge squid-deb-proxy and squid, and then see if it's left any state behind in /var/cache, /var/lib etc.
[08:49] <jtv> Because that log looks to me as if it left a file behind there that got corrupted, perhaps because of a power outage while it was being written or something.
[08:50] <jtv> It's only logged as a "warning," but coming right before the segfault it's the most obvious candidate.
[08:52] <ging> i think i might have figured it out
[08:53] <ging> it started of with 512 meg of ram when it was built, it gave it 16gig but swap is still set at 500meg
[08:55] <jtv> More memory should never be a problem.  :)
[08:56] <jtv> Unless you've got it overclocked and the dimms don't match up, of course...
[08:56] <ging> it's a vm
[08:57] <jtv> I don't think there's any reason nowadays why memory shouldn't be bigger than available swap.  ISTR that rule went out the window.
[08:57] <jtv> Could the host be running out of memory maybe?  Or if the guest is 32-bit, maybe it runs out of address space?
[09:05] <ging> i think it was just the fact it had a tiny swap partion and way trying to use it
[09:16] <ging> no it still crashes with a bigger swap partition
[09:17] <ging> i will try purging squid and squid-deb-proxy
[14:06] <roaksoax> rvba: howdy!! What is the most recent revision you want released?
[14:07] <rvba> Hi roaksoax, actually, we have a problem with the integrations tests so I'd like to postpone the release (of MAAS) by a day or two if that's all right with you.
[14:08] <rvba> integration*
[14:10] <roaksoax> rvba: yeah that's fine
[14:10] <roaksoax> rvba: maas-test is a go though?
[14:10] <rvba> roaksoax: yep
[14:10] <roaksoax> rvba: ok cool!
[14:17] <jamespage> does the version of 'maas-import-ephemerals' provide feedback on what its doing? on saucy it give me zip....
[14:17] <jamespage> does the *newest* version...
[14:17] <jamespage> that should have read
[14:18] <roaksoax> jamespage: it doesn't!
[14:18] <roaksoax> rvba: ^^ can we address that ASAP please?
[14:18] <jamespage> roaksoax, its quite disconcerting
[14:18] <roaksoax> tych0: ^^
[14:18] <jamespage> roaksoax, I'm happy to raise a bug
[14:18] <roaksoax> jamespage: agreed!
[14:18] <roaksoax> jamespage: please do!
[14:19] <jamespage> roaksoax, the only way I can tell its actually doing something is because I've got the network indicators on in byoby
[14:19] <roaksoax> jamespage: yeah! We have requested this to be addressed before, I guess noone has gotten to it, or it has been forgotten
[14:20] <jamespage> bug raising now
[14:20] <tych0> there is callback support, i don't think anyone ever decided what the output should look like
[14:20] <jamespage> some options to switch to daily stream would be nice as well
[14:20] <jamespage> fwiw I have the same compliant with juju
[14:20]  * jamespage stops whinging and raises a bug
[14:22] <roaksoax> tych0: IIRC, we did at the sprint
[14:22] <roaksoax> smoser: ^^
[14:23] <smoser> well, that import-ephemerals needs all sorts of work.
[14:23] <jamespage> bug 1271189 and bug 1271188
[14:24] <smoser> some progress output would be useful thats for sure.
[14:24] <smoser> theres other things that could be improved there too
[14:24] <tych0> jamespage: it does support switching to the daily stream
[14:24] <tych0> you can point it anywhere with --url
[14:24] <jamespage> tych0, oh - does it
[14:25] <roaksoax> tych0: is that documented in the manpage?
[14:25] <smoser> its in help output
[14:25] <smoser> but its not wonderful anyway
[14:25] <smoser> we really ned to thikn about how better to address that.
[14:25] <tych0> roaksoax: probably not :-)
[14:25] <jamespage> tych0, oh - I see
[14:25] <roaksoax> heh :)
[14:25] <jamespage> you need url and products
[14:26] <jamespage> (a --daily shorthand would be nice)
[14:26] <smoser> (i only knew it was in '--help' becauase rharper came asking me about it last week)
[14:26]  * jamespage has to admit he just hacked his local copy to get working
[14:26] <tych0> do you have to set products?
[14:26] <tych0> i thought there may have been defaults
[14:26] <smoser> right now, rbasak has somehwat convinced me that specifying 'product' id is not so important
[14:26] <smoser> and that maas should search really on tags only, not on product id.
[14:37] <rvba> roaksoax: Fixing this script is tricky.  It's completely intertwined with simplestreams which means that progress report will have to use simplestreams' features…
[14:37] <roaksoax> smoser: ^^
[14:37] <roaksoax> tych0: ^^
[14:37] <smoser> which is fine
[14:37] <tych0> simplestreams should have support for callbacks, though
[14:37] <tych0> i did it as part of the re-write
[14:38] <smoser> it does
[14:38] <tych0> i think the plan was to chang eit when you guys figured out what output you wanted
[14:38] <smoser> well, simplestreams has the update callbacks.
[14:38] <smoser> but maas-import-ephemerals does not use them
[14:38] <tych0> right
[14:38] <smoser> simply putting a '.' on the screen every X MB would be useful.
[14:38] <rvba> tych0: am I wrong or only part of the import process has been migrated to simplestreams?
[14:39] <tych0> well, simplestreams just does ephemerals
[14:39] <smoser> import of di kernels does not use simplestreams
[14:39] <tych0> not the pxe files
[14:39] <rvba> Right, that's what I had in mind.
[14:39] <rvba> Which means effective reporting should address both types of imports.
[14:40] <rvba> But yeah, usability-wise I agree that it's pretty important.
[14:40] <smoser> ok... so some info here might be useful.
[14:40] <smoser> there are 2 things that will affect "import" going forward.
[14:41] <smoser> a.) strikov and rbasak and I talked yesterday about "enablement packages" ... making maas able to serve up kernels and boot media for new arches/"subarches" and supporting better, and having sstream data on some server to describe that.
[14:42] <smoser>  thats relevant, because the data that strikov was porposing woudl have 'di-kernel' and 'di-initrd' (debian installer) data also, which is what you're currently getting with import-pxe-data.
[14:43] <smoser> b.) we may change the format of the ephemeral image download to help address 'a'.
[14:43] <smoser> ie, instead of it being a .tar.gz, it might end up being a squashfs filesystem or something/