[00:02] <bigjools> yes
[00:02] <Valduare> interesting
[00:03] <Valduare> any kernel I wish to serve?
[00:03] <Valduare> or something custom from maas?
[00:03] <bigjools> it uses stuff from maas.ubuntu.com/images at the moment
[00:03] <bigjools> but you can replace what maas downloads with your own if you want
[00:03] <Valduare> so supported arm hardware only then
[00:03] <Valduare> ah
[00:03] <bigjools> boot kernels live in /var/lib/maas/tftp/
[00:04] <bigjools> and ephemerals for installation are in /var/lib/maas/ephemeral/
[00:04] <Valduare> ephemerals?
[00:04] <bigjools> the latter is served up with iscsi when installing the OS
[00:04] <bigjools> yes they are very large images that contain the installation media
[00:05] <bigjools> so we netboot to start up the installer, after that it local boots
[00:05] <Valduare> so maas is using local storage?
[00:06] <bigjools> yes, theres no support for net mounted root fs yet
[00:08] <Valduare> right now I got a freenas box with 4 drives in it, zfs mirrors and then the two mirrors striped together, serving iscsi to a gigabyte ga-e350n mobo with 16 gigs of ram running esxi to host 14 vms
[00:22] <Valduare> looks like for now i’ll stick with my ga-e350n boards
[00:35] <Valduare> bigjools: so maas is just metal as service,
[00:36] <Valduare> how does that play along with openstack and all the other stuff
[00:36] <bigjools> Valduare: maas is the bare metal provisioner, Juju is the service orchestrator
[00:37] <bigjools> Juju deploys openstack
[00:39] <Valduare> so If I have 3 or 4 amd e350 boxes
[00:39] <Valduare> with this juju, maas stuff is there a controller host?
[00:40] <bigjools> yes, juju maintains a "bootstrap" host
[00:40] <bigjools> you also need a least one host for maas
[00:41] <Valduare> can these be virtualized?
[00:44] <bigjools> yes
[00:44] <bigjools> maas can manage virtualized hosts as well
[00:44] <bigjools> nodes, I mean, not hosts
[00:45] <Valduare> interesting
[00:50] <Valduare> looks like with my little hardware I may just need to skip maas for now?
[00:51] <bigjools> I don't know
=== CyberJacob is now known as CyberJacob|Away
[02:05] <bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/new-import-script-integration/+merge/212535
[02:05] <bigjools> jtv: yes I am aware you have those comments coming in another branch.  Sorry :(
[02:05] <bigjools> but they will get blown away if we rewrite the file anyway
[02:06] <jtv> Everything will get blown away if we rewrite the file.  Just saying they need to be moved... _some_where.  :)
[02:08] <bigjools> yes
[02:08] <bigjools> but where!
[02:09] <jtv> Good question.
[02:09] <jtv> You're moving the whole "boot" section..?  Shouldn't storage still be in pserv.yaml?
[02:10] <jtv> I don't suppose there's a way to inject comments while dumping to yaml...
[02:10] <bigjools> jtv: why should it be in pserv?
[02:11] <jtv> The information is shared with pserv, isn't it?
[02:11] <bigjools> oh god, don't tell me pserv needs it to serve tftp
[02:11] <bigjools> argh
[02:11] <jtv> I was going to, but if you don't want me to...
[02:18] <bigjools> jtv: it is still using "root" as a config item
[02:19] <bigjools> which was changed to default to /var/lib/maas/boot-resources/current/
[02:19] <jtv> Yes
[02:19] <jtv> No
[02:19] <jtv> Wait
[02:19] <jtv> You mean you ditched the "storage" item?
[02:20] <bigjools> I didn't
[02:20] <bigjools> it's still there
[02:20] <bigjools> I am saying that the tftp server uses "root"
[02:20] <bigjools> and the import script uses "storage"
[02:20] <bigjools> they are not the same value
[02:21] <bigjools> I am happy to keep it that way
[02:22] <jtv> Ah so
[02:24] <jtv> Please update the arch: "*" entries to arches: ["*"]
[02:25] <bigjools> ok
[02:33] <jtv> Shall I just go to work on the UEFI card then?
[02:34] <bigjools> jtv: no, I think Blake started that, and Gavin said he was getting involved too
[02:34] <jtv> Oh
[02:35] <bigjools> you ok with my branch?
[02:35]  * jtv relooks
[02:35] <jtv> Still eseing the old "arch" instead of "arches"...
[02:36] <jtv> Also, it'd be good to move the additional documentation over from pserv.yaml before deleting it — for those who aren't going to see the file rewritten right away.
[02:40] <bigjools> jtv: I'll move that over
[02:40] <bigjools> jtv: I had not merged the latest changes so missed it
[02:41] <jtv> Thanks.
[02:45] <bigjools> jtv: are you sure that text is right?  You don't need separate sources, just separate selections I think
[02:45] <jtv> I'm not sure, no.  But how would you put in multiple selections?
[02:46] <bigjools> the selections section is repeatable isn't it?
[02:46] <bigjools> oh maye not.  It ought to be
[02:50] <bigjools> jtv: ok it's pushed up if you would like to re-check
[02:50] <jtv> Re-checking.
[02:51] <jtv> Maybe the "selections" section is repeatable...  if so, it'd be nice to have that said somewhere.
[02:52] <bigjools> jtv: I don't think it is, it ends up as "filters" in the boot_merge() func
[02:52] <jtv> Hmm... but that is a list of dicts, right?
[02:52] <jtv> It's all so infuriatingly unclear.
[02:53] <bigjools> jtv: oh wait yes!
[02:53] <bigjools> it's a list of dicts
[02:53] <jtv> What a way to run a railroad...
[02:54] <bigjools> I will test this out
[02:56] <bigjools> jtv: it works, I am going to add another selections section to the example config to make this obvious
[02:56] <jtv> OK.
[02:56] <bigjools> jtv: in fact I think the one there now should be commented out and we add one in for just trusty
[02:57] <jtv> Yes, that makes sense.
[02:58] <bigjools> huh something weird is happening, I had both amd64 and i386 and it only downloaded i386
[03:00] <bigjools> jtv: christ it's worse than not working.  It only gets the *last* selection
[03:06] <bigjools> jtv: awaiting your review
[03:06]  * bigjools eats
[03:07] <jtv> The last selection?  How!?
[03:49] <bigjools> jtv: I have NFI.  It's easy to recreate on canonistack
[04:04] <jtv> Package build failed.
[04:05] <jtv> It's patch #02, to pserv.yaml.
[04:05] <jtv> Good thing we have "make package" — much easier to discover these things.
[04:06] <bigjools> ah
[04:07] <bigjools> jtv: we need a forked packaging branch now then.... joy.
[04:07] <jtv> Looks easy to patch — but it means forking the packaging branch...  :/
[04:08] <jtv> Two minds, one thought.
[04:08] <bigjools> well it just needs a "quilt refresh" IRC
[04:08] <bigjools> IIRC
[04:08] <jtv> With a "series file."
[04:34] <jtv> bigjools: are you available for a pre-imp?
[04:34] <bigjools> jtv: give me a few minutes and then yes
[04:34] <jtv> Great, thanks.
[04:39] <bigjools> jtv: you want a link or an invite?
[04:39] <jtv> bigjools: I was thinking talky.
[04:39] <bigjools> ah yes
[04:39] <bigjools> I'm in
[05:01] <AskUbuntu> Error in creating juju bootstrap | http://askubuntu.com/q/438851
[05:11] <bigjools> jtv: ok I figured out why multiple selections were not working
[05:11] <bigjools> PEBKAC, in short
=== CyberJacob|Away is now known as CyberJacob
[07:19] <gmb> bigjools, rvba, jtv: New import script question: Is there a preferred MAAS-ish way to exit from a script, or is good old sys.exit() fine?
[07:20] <bigjools> gmb: depends on what sort of script it is!
[07:20] <gmb> bigjools: Well, fair point. I'm talking about exiting boot_resources.main() when there's no config file.
[07:20] <bigjools> give this is a basic one, sys.exit seems ok
[07:21] <gmb> bigjools: Okidoke.
[07:26] <gmb> bigjools: Is there a trick for running these scripts in the dev environment? This is slightly new territory for me.
[07:26] <bigjools> gmb: bin/py <script>
[07:26] <gmb> bigjools: !! You'd think I'd never worked on Launchpad. Ta.
[07:26] <bigjools> :)
[07:26]  * gmb adds tea to brain.
[07:27] <bigjools> gmb: one gotcha, it still looks for /etc/maas/<thing>.yaml
[07:27] <gmb> bigjools: Okay, thanks.
[07:27] <bigjools> I thought we had got around that but it seems not
[07:30] <rvba> gmb: you can pass --config-file <my file> to the script.
[07:31] <rvba> (If you run it through scripts/maas-import-pxe-files)
[07:34] <bigjools> yeah
[07:52] <bigjools> gmb: thou hast mist tests sire
[07:52] <gmb> bigjools: Rly?
[07:52] <gmb> bigjools: I thunk it was untested.
[07:52] <bigjools> gmb: well you could start :)
[07:52] <bigjools> and this one is easy
[07:52] <gmb> bigjools: Damn you. Fair point though :)
[07:58] <jtv> gmb: I wouldn't sys.exit() from main() itself, because that will be run from celery.  But from the command-line script it'd be fine of course — insofar as it matters.
[07:58] <gmb> jtv: Do you have a preferred option? Not sys.exit()ing would also be easier to test, come to think of it.
[07:58] <jtv> At least, I seem to remember that main() is part of what would run from celery...
[07:58] <jtv> Exactly.
[07:58] <jtv> It's library code.  I wouldn't do sys.exit() except in the command-line script itself.
[07:59] <jtv> If main() is a function, IMHO it should act like a function: return if successful (for some value of), raise on failure.
[08:00] <gmb> jtv: Makes perfect sense. On it.
[08:00] <jtv> We could get clever with returning an exit code, but are there really any points in that?
[08:00] <bigjools> gmb: oh yes jtv is right, raise an exception that is caught in the outer wrapper
[08:00] <jtv> OK.  Always happy to upset people's plans.  :)
[08:00] <gmb> jtv: Depends on how many failure states there are :). In this case, no.
[08:01] <gmb> jtv: Or rather, I'm happy for that to be SEP.
[08:01] <jtv> That's the spirit.
[09:10] <rvba> It tries to download http://archive.ubuntu.com/ubuntupool/main/s/shim-signed/shim-signed_1.5~13.10.1+0.4-0ubuntu4_amd64.deb and fails.
[09:12] <rvba> Looks like there is a slash missing between 'ubuntu' and 'pool'.
[09:30] <rvba> Anyone up for a trivial review? https://code.launchpad.net/~rvb/maas/fix-download-url/+merge/212567
[09:32] <jtv> I'll take it.
[09:32] <rvba> Ta
[09:32] <allenap> rvba: I am Mr Trivial.
[09:33] <allenap> rvba: Where are the tests? <sniggers>
[09:33] <rvba> allenap: grrrr
[09:33] <bigjools> yo
[09:33] <rvba> bigjools: I'm sorry to say that the fix to get more details about errors from scripts run by celery is not working 100%: here is what I was getting when the import script was failing: http://paste.ubuntu.com/7150376/.  And I know for a fact that the script was echoing things.
[09:39] <frankban> maas devs: I am looking at bug 1277445 trying to track down the issue. Given the "could not compose userdata for bootstrap node" error, this seems related to maasEnviron.StartInstance not being able to find the tools URL. Is it a known issue?
[09:39] <ubot5> Error: Launchpad bug 1277445 could not be found
[09:40] <frankban> https://bugs.launchpad.net/ubuntu-advantage/+bug/1277445
[09:59] <rvba> Hi frankban, looks like environs.ComposeUserData (called from maasEnviron.StartInstance) broke indeed. This doesn't look related to the tools.
[10:05] <frankban> rvba: morning. The code paths seems to be ComposeUserData -> cloudinit.Configure -> ConfigureJuju -> verifyConfig and in verifyConfig we have cfg.Tools.URL == ""
[10:08] <frankban> rvba: tools seems to be retrieved in maas.acquireNode
[10:11] <rvba> frankban: you're right… this code changed a lot since I last had a look at it…
[10:12] <rvba> frankban: the "picked arbitrary tools" comment in acquireNode() seems fishy…
[10:12] <bigjools> rvba: the script was probably not printing stuff in a way that the task can see, perhaps stdout/stderr got disconnected?
[10:12] <bigjools> rvba: at least we get one more bit of info:
[10:12] <bigjools> [2014-03-25 09:32:06,783: ERROR/Worker-2] import_boot_images: Command `sudo -n -E maas-import-pxe-files` returned non-zero exit status 1:
[10:13] <rvba> bigjools: yeah, it's better than nothing.
[10:13] <frankban> rvba: yeah. do you think this is something you have to tackle, should I assign this to the maas team? or to juju-core? this just seems not related to the GUI at all.
[10:13] <rvba> bigjools: but I know for a fact that the script did "echo 'could not download $url'"… seeing that would have helped :)
[10:13] <bigjools> rvba: I suspect that the child process is sufficiently detached that the task is losing its stdout/stderr
[10:14] <rvba> Yeah, sounds probable.
[10:15]  * bigjools EODs
[10:15] <rvba> frankban: I think the juju people will be in a better position to help you pinpoint where the problem is.  Don't get me wrong, if it's a problem in MAAS we will be more than happy to help, but at this stage, it looks like a problem with this particular installation and juju.
[10:17] <frankban> rvba: fair enough, I'll ping them then, thank you
[10:17] <rvba> welcome
[10:23] <jtv> Why doesn't provisioningserver.config.Config's load_from_cache() use its own load()!?
[10:24] <jtv> I thought I was smart and could just patch load().  :)
[10:27] <jtv> allenap, you may be able to help with this.  I must be missing something obvious.
[10:27] <jtv> I'm patching out a class method.
[10:28] <jtv> But a plain old call to that class method then fails with:
[10:28] <jtv> TypeError: unbound method <patched-out method>() must be called with <Class> instance as first argument (got <next parameter type> instance instead)
[10:29] <jtv> My fake is a plain old function.  It doesn't matter whether I make it take a "cls" argument or not; the problem seems to happen in the binding of the original call.
[10:29] <jtv> Ahhh, @classmethod seems to do it.
[10:30] <jtv> Looks a bit weird to decorate a nested function with a @classmethod, but oh well!
[10:30] <jtv> Thanks for being my passive debug partner.  :)
[10:36] <allenap> jtv: Hehe. It would be interesting to see some example code for that.
[10:36]  * allenap will be biab.
=== _zchander_ is now known as zchander
[10:42] <gmb> rvba, allenap, jtv: Can on of you gents give this this once over again so I can land it? https://code.launchpad.net/~gmb/maas/INTEGRATION-BRANCH-stop-with-no-config/+merge/212555
[10:42] <jtv> Absolutely.
[10:42] <jtv> Because I think I had a glance earlier and left a minor comment.
[10:45] <gmb> Y'did.
[10:46] <gmb> A very thoughtful and useful one :)
[11:04] <jtv> And here are some more.  :)
[11:14] <rvba> I just put 3 branches up for review: two small and one medium, take your pick:
[11:14] <rvba> https://code.launchpad.net/~rvb/maas/network-listing-pagination/+merge/212579
[11:14] <rvba> https://code.launchpad.net/~rvb/maas/zone-listing-pagination/+merge/212578
[11:14] <rvba> https://code.launchpad.net/~rvb/maas/move-boot-image-different-page/+merge/212572
[11:16] <jtv> Grr.  I was hoping to code for a while.  :)
[11:16] <jtv> rvba: I'll do some more reviewing.  Maybe you can review mine?
[11:16] <jtv> https://code.launchpad.net/~jtv/maas/bootresources-rewrite-marker/+merge/212584
[11:16] <rvba> jtv: sure
=== CyberJacob is now known as CyberJacob|Away
[16:13] <gmb> rvba, allenap: Are you still happy with Jools's idea to merge the integration branch today.
[16:13] <gmb> ?
[16:15] <rvba> gmb: I think we need smoser to update the daily simplestreams' data and to publish the new data for the releases first.
[16:15] <gmb> rvba: Ah, you're right. I completely forgot that part of the conversation, sorry. Arvobrain.
[16:15] <smoser> if i get you daily is that good enough?
[16:15] <gmb> rvba: ^^
[16:16] <rvba> Well, technically yes, the daily images should suffice (for the int. tests to pass).
[16:18] <rvba> gmb: I've already updated the config with the daily URL.
[16:19] <gmb> rvba: Can we do a run of the integration tests on the integration branch before we merge?
[16:19] <gmb> Just for the sake of not having to revert or scramble to fix it
[16:19] <rvba> gmb: that's exactly what I'm doing now.
[16:20] <gmb> rvba: I knew as I was typing it that you would be. But I wanted to seem OTB.
[16:20] <gmb> Damn, no itv around for OTB.
[16:20] <gmb> *jtv
[16:21] <gmb> Phuket.
[16:21] <smoser> rvba, ok. you should have correct (in once sense) data on daily stuff now
[16:21] <rvba> smoser: ta
[16:21] <smoser> "in one sense", because i did something there that isn't valid, and may piss off your improter if it has old state.
[16:22] <smoser> i updated the kernel and initrd data for existing 'version's rather than creating a new version.
[16:22] <rvba> Should be fine, we're installing from scratch.
[16:23] <smoser> yeah. it should be fine there.
[16:27] <Fishy__> Has anyone gotten a cobbler server to forward new machines over to my maas server?
[16:28] <Fishy__> or help on getting cobbler / maas to coexist on the same network
[16:28] <rvba> gmb: can you check that the test suite passes on the feature branch?
[16:28] <gmb> rvba: Sure.
[16:29] <rvba> This way, if the tests pass in the lab, we'll be ready to merge it.
[16:42] <allenap> roaksoax: Do you know anyone who has a really good handle on python-apt, and who might be able to help with the shim-signed problem?
[16:43] <roaksoax> allenap: i'd probably ask slangasek but using python-apt seems painful
[16:44] <allenap> roaksoax: Okeydoke. I’m following up because cjwatson recommended it, so I reckon there’s got to be something there.
[16:45] <roaksoax> allenap: afaik python-apt would use the current sources.list to install the package fron the archive
[16:45] <roaksoax> if thats ehat you are looking on doing then thats what it should be done
[16:46] <roaksoax> i'd ask slangasek how to manage getting the shim + uodates to slangasek though
[16:46] <allenap> roaksoax: python-apt also has some lower level libraries that might be of use.
[16:47] <roaksoax> cool
[16:58] <gmb> rvba: Is this what you're seeing? https://pastebin.canonical.com/107113/
[16:59] <rvba> gmb: no, that's because you have a maas package installed.  I forget which.
[16:59] <gmb> Gaaaaah.
[17:01] <rvba> gmb: http://paste.ubuntu.com/7152093/ that's what I'm seeing.
[17:01] <rvba> gmb: like I said, it's the configure_me thingy
[17:01] <gmb> rvba: Right.
[17:02] <gmb> rvba: I'm poking at it now. Just switching locations whilst it runs...
[17:02]  * gmb -> bbiab
[17:17] <rvba> gmb: I fixed the problem, it was just a syntax issue in the config file.
[17:19] <rvba> gmb: smoser: actually, the integration tests deploy stuff (with juju) using precise.  So we need the precise simplestream stream.
[17:19] <smoser> rvba, ?
[17:20] <smoser> that data hould be there, no.
[17:20] <smoser> ?
[17:20] <rvba> Hum, the daily images should be there indeed…
[17:22] <rvba> I see, we didn't configure the package to import the precise daily images.
[17:24] <rvba> gmb: I fixed the code to do that.  Should work now.
=== zchander is now known as zchander_work
=== zchander_ is now known as zchander
=== CyberJacob|Away is now known as CyberJacob
=== CyberJacob is now known as CyberJacob|Away