[03:38] <jtv> This is annoying.  I'm trying to Q/A my uec2roottar rewrite, but something else is broken.
[03:38] <jtv> Could not find kernel image: amd64/generic/trusty/release/boot-kernel
[03:39] <jtv> I think it's an architecture mismatch: i386/amd64
[03:41] <jtv> Silly of me.  Can't set a node's architecture with default enlistment.
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
=== CyberJacob|Away is now known as CyberJacob
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
[07:32] <jtv> rvba: might not be completely crazy to start a DownloadProgressHandler.
[07:32] <rvba> jtv: that's what I thought.  The thing is that the documentation for this API method is so detailed that it drives people to try and use that method :)
[07:32] <jtv> On the other hand, the design notes had to go _somewhere_.  :)
[07:33] <rvba> heh
[07:33] <jtv> If we just provide a GET to download progress, that wouldn't be very user-friendly but at least API users could get stuff done.
[07:33] <rvba> Indeed.
[07:33] <jtv> And it would get the implementation ball rolling: so much easier to say how it should be _better_ than how it should _be_.  :)
[07:34] <rvba> Also, isn't the import script supposed to do the reporting (using the report_download_progress method)?
[07:34] <rvba> Wasn't that the plan?
=== CyberJacob is now known as CyberJacob|Away
[08:07] <rvba> jtv: something else I wanted your opinion about:  When users upgrade from Saucy, the new entries in bootresources.yaml don't have a 'label' constraint.  As a result, multiple images can be imported (for instance 'rc'/'release')… shouldn't we add a labels=['release'] constraint?  This would be better in sync with what the old config (from which we're migrating) was doing.
[08:07] <rvba> Not sure if it's worth a bug/fixing.  Especially considering the upcoming work on getting rid of bootresources.yaml.
[08:25] <jtv> rvba: maybe wait until we know what we really want, there?  Otherwise we keep modifying and creating this massive history of different default settings.
[08:25] <rvba> jtv: yeah.  But let's keep that problem in mind then.
[08:25] <jtv> Absolutely.
[09:23] <jtv> gmb, this one's for you: https://code.launchpad.net/~jtv/maas/test-1310844/+merge/217006
[09:27] <gmb> jtv: On it, ta
[09:31] <rvba> bigjools: can you please vote on https://code.launchpad.net/~rvb/maas/add-power-params-doc/+merge/216894 ?
[09:36] <rvba> jtv: reviewing your 'python-to-python-imports' branch now
[09:44] <rvba> allenap: I filed https://bugs.launchpad.net/maas/+bug/1312085
[09:44] <ubot5> Launchpad bug 1312085 in MAAS "No documentation for the CLI" [High,Triaged]
=== vladk|offline is now known as vladk
[11:31] <rvba> allenap: care to vote on https://code.launchpad.net/~rvb/maas/add-power-params-doc/+merge/216894 ?
[11:37] <allenap> rvba: Okay, I’m finishing something off right now, then I’ll do it.
[11:41] <rvba> allenap: ta, it's definitely not urgent.
[12:42] <alfs> ran into an interesting issue with usb keys and large rams.
[12:43] <alfs> The machine has 24 GB ram, and I use a 8 GB usb stick for deployment.
[12:44] <alfs> the rootfs gets about 1 GB, and the rest is allocated for swapspace - and e.g. juju bootstrap fails due to insufficient disk space.
[12:47] <alfs> is there some easy way to skip swap altogether, or do I need a customized preseed?
[12:52] <Teduardo> if using MaaS to build/maintain a distributed system, lets use for example openstack. when a new openstack release comes out, can MaaS sensibly handle the upgrade as well?
[12:53] <Teduardo> (maas/juju)
[13:07] <magicrobotmonkey> I'm getting PXE-E11 ARP Timeout when booting a potential node
[14:04] <melmoth> what is the purpose of the new "Network" menu in trusty maas ?
[14:04] <melmoth> i did not have such a one before using the ppa version of maas in precise. what am i suppose to put there ?
[14:06] <rvba> melmoth: maas.ubuntu.com/docs1.5/networks.html
[14:07] <melmoth> ok, so if all my nodes are on the same net as the nic i assigned to the  cluster controller , and dont use other network, i dont need to use this form, right ?
[14:08] <rvba> melmoth: correct
[14:08] <melmoth> good. thanks.
[14:08] <magicrobotmonkey> my node came to the maas-enlisting-node login: prompt
[14:08] <magicrobotmonkey> am I supposed to do something now?
[14:09] <rvba> magicrobotmonkey: no, this should be temporary (i.e. until your node enlists itself).  After a while your node should be powered down by MAAS.
[14:10] <magicrobotmonkey> oh there it goes
[14:10] <magicrobotmonkey> things are happening!
[14:10] <magicrobotmonkey> cool it showed up in the nodes
[14:11] <magicrobotmonkey> this is much better than scraping the switch for mac addresses
[14:19] <magicrobotmonkey> when i hit "commision node" where should I look for a log of whats going on?
=== vladk is now known as vladk|offline
[14:53] <alfs> console output
[14:54] <alfs> I find is the best. Sometimes the commissioning or running hangs, and the console is the best place to see this
[14:54] <magicrobotmonkey> yea ok
[14:55] <magicrobotmonkey> does the commisioning configure ipmi locally? because I've been unable to use ipmitool on these boxes but maas did it somehow
[15:06] <alfs> It adds it's own user
[15:06] <alfs> in the commissioning stage
[15:06] <magicrobotmonkey> ah cool
[15:06] <magicrobotmonkey> thats pretty slick
[15:13] <alfs> still no luck with partitioning. Is there some other source for the partition layout than /etc/maas/preseeds/preseed_master?
[15:14] <alfs> I know my edits are working, e.g. changing from ext4 to ext3, but partman-auto/expert_recipe and partman-auto/choose_recipe just does not bite.
[15:15] <rvba> alfs: that's weird, there is nothing that should override changes in /etc/maas/preseeds/preseed_master.
[15:35] <alfs> Hm.. I commented everything regarding partman in the preseed, and then it (as intended) stops at the partitioning stage
[15:35] <alfs> However I cannot get past iscsi config, i.e. I choose iscsi, finish, and then get thrown back to iscsi config.
[15:36] <alfs> No option to configure, and if I finish partitioning it (of course) has no root fs defined
[15:37] <alfs> perhaps due to the partman early-command not being run to define the disks.. enabling that and trying again
[16:13] <alfs> seems there was a small typo in the expert_recipe, causing it to be ignored, seems to be working now.
[16:17] <magicrobotmonkey> heh yea i think i had a problem like that at one point
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
[17:51] <magicrobotmonkey> do maas nodes use a proxy by default?
[17:51] <magicrobotmonkey> an apt proxy, that is
=== CyberJacob|Away is now known as CyberJacob
[18:11] <Isid0r0> Hey, Does anyone know how to add the new "trusty" disto to an existing MAAS installation? I see it downloaded the OS's but it isn't registering in the settings page as a deployable distro
=== roadmr_ is now known as roadmr
=== kevin is now known as Guest48000
=== kev is now known as Guest49483
[19:39] <alfs> magicrobotmonkey: Yes, the maas server has squid-deb-proxy installed
[19:39] <magicrobotmonkey> cool
[19:39] <magicrobotmonkey> thats super handy
[19:40] <alfs> make sure you use the official archive, otherwise you get bad mirror hangs
[19:40] <alfs> or {cc}.archive.ubuntu.com at least
=== CyberJacob is now known as CyberJacob|Away
=== CyberJacob|Away is now known as CyberJacob
=== CyberJacob is now known as CyberJacob|Away