[01:46] <mwhudson> bigjools: if i say the words "curtin" and "arm64" or "armhf" in the same sentence does that provoke any thoughts?
[01:46] <bigjools> scary ones
[01:46] <mwhudson> heh
[01:47] <bigjools> I don't know if it's ever been tried on those arches
[01:47] <bigjools> arm IO mean
[01:47] <bigjools> gah can't type today
[01:47] <mwhudson> the thing that's lurking in my mind is the need (on current platforms) to run flash-kernel
[01:47] <bigjools> if you can find an image, give it a go :)
[01:47] <mwhudson> what sort of images does curtin usually install?  cloud images?
[01:48] <bigjools> they're big tarballs IIRC
[01:48] <mwhudson> bigjools: if i say the words "curtin" and "documentation" in the same sentence...
[01:48] <bigjools> wheeeeeee
[01:50] <mwhudson> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/examples/basic.yaml is just installing a clout root.tar.gz
[01:50] <mwhudson> *cloud
[01:52] <mwhudson> i didn't think those had kernels in though
[01:54] <bigjools> the kernels are downloaded separately
[01:59] <mwhudson> oh!
[02:00] <mwhudson> bigjools: do you know where it gets them from?
[02:01] <bigjools> mwhudson: http://maas.ubuntu.com/images
[02:02] <bigjools> http://maas.ubuntu.com/images/ephemeral-v2/releases/streams/v1/com.ubuntu.maas:v2:download.json
[02:02] <mwhudson> ah ok
[02:04] <mwhudson> bigjools: do you know where in curtin (which 'stage') the kernel gets handled?
[02:04] <bigjools> I don't, sorry
[02:05] <bigjools> it's a bit of a black hole to me, and as you note there's no docs
[02:05] <mwhudson> i bet smoser doesn't have anything else to do this cycle
[02:07] <mwhudson> one way appears to be more or less "chroot /target apt-get install linux-image"
[02:07] <mwhudson> which ought to work fine x-platform
[02:09] <bigjools> yeah
[02:09]  * bigjools brb
[02:09] <mwhudson> actually i think that's more or less what it always does, not sure it uses the simplestreams data
[02:10] <mwhudson> oh hahaha
[02:10] <mwhudson>     machine = platform.machine()
[02:11] <mwhudson>     if machine.startswith('armv7'):
[02:11] <mwhudson>         update_initramfs(target)
[02:11] <mwhudson>     else:
[02:11] <mwhudson>         setup_grub(cfg, target)
[02:11] <mwhudson> yeah so about that...
[02:11] <mwhudson> not sure why the update_initramfs part is necessary, that's done by installing the kernel pacakge
[02:11] <mwhudson> unless triggers are disabled or some such insanity
[02:15] <jhobbs> does the kernel package get installed on a curtin install?
[02:15] <jhobbs> it's not part of the image that gets unpacked?
[02:15] <mwhudson> jhobbs: that's the way i read it
[02:16] <mwhudson> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/commands/curthooks.py#L139
[02:19] <jhobbs> i added that line; iirc the initramfs wasn't getting run until that setup_grub() ran
[02:19] <jhobbs> which didn't work on armhf, so i just did update_initramfs
[02:19] <mwhudson> huh
[02:20] <mwhudson> maybe there is some conditionality then; the kernel package is only installed if there is no kernel in the installed image or something
[02:20] <mwhudson> but i don't see that
[02:27] <mwhudson> now
[02:27] <mwhudson> can i remember why i was interested in this question?
[02:36] <mwhudson> jhobbs: so the way maas uses curtin is that it netboots a cloud image and uses cloud init data to run curtin?
[02:36] <mwhudson> how does the cloud init data get to the machine?
[02:38] <jhobbs> mwhudson: wget from maas more or less
[02:38] <mwhudson> ah so the cloud-init user-data is "get more config from this url"?
[02:40] <mwhudson> ah yes
[02:50] <mwhudson> ah i think you can put something like ds=nocloud-net[s=$url] on the kernel command line
[02:50] <mwhudson> and then cloud-init will hit $url/user-data and $url/meta-data
[07:11] <jtv> bigjools: We don't really support multiple IPs per NIC for cluster interfaces, but I figured we could either say TFB, or treat them as multiple interfaces.
[07:11] <jtv> Depending on whether any actual need arises.
[07:11] <bigjools> jtv: treat them as aliased separate interfaces
[07:11] <bigjools> I did think about it at the time
[07:12] <jtv> I guess we could only manage one anyway.
[07:12] <jtv> Doesn't make much sense to run two dhcpds (for the same IP version) on the same NIC but for different networks.
[07:12] <jtv> (Not counting VLANs where you've got, from our perspective, different NICs anyway)
[07:16] <bigjools> no, you'd run a single dhcpd for all interfaces like we do now
[07:17] <jtv> Same thing applies regardless — dhcp daemon or dhcp service, you can't just serve two unrelated dynamic IP ranges on the same NIC without some way to configure which client should go in which range.
[07:18] <jtv> We neither have nor, to my knowledge, need such configuration.  :)
[07:18] <bigjools> cheap karma: https://code.launchpad.net/~julian-edwards/maas/ui-fixes/+merge/223506
[07:19] <bigjools> jtv: right, the whole thing is somewhat nonsensical
[07:20] <jtv> Cheap karma?  Coming!
[07:23] <rvba> bigjools: haha, I see the wrong capitalization came from Django generating the labels based on the name of the fields. :)
[07:23] <bigjools> rvba: corrrrrect
[07:23] <bigjools> rvba: I am learning too much about Django lately.
[07:23] <bigjools> *twitch*
[07:24] <rvba> bigjools: too late, I'm anointing you "APAC Django expert attaché to the MAAS team" ;)
[07:24]  * bigjools sets up mail forwarder to rvba for anything with "django" into
[07:25] <bigjools> s/into/in it/
[07:25]  * bigjools having a bad typing day
[07:35] <jtv> Recapitalising words is one of those things frameworks really oughtn't be doing for us.
[07:35] <jtv> bigjools, did you run into one of those "Ip address" fields?
[07:35] <bigjools> jtv: I bumped my nose on it
[07:36] <jtv> Exercise: auto-capitalise MAISON DU THE for display as a title.
[07:37] <jtv> "Oh, ‘the’ is an article, let's lower-case that."
[07:37] <jtv> (I believe it should become thé)
[07:37] <jtv> (Sorry, Thé)
[07:38] <rvba> jtv: shouldn't it by "MAISON DU THÉ" in the first place?
[07:40] <jtv> In principle, yes — but aren't all-caps names like this often displayed without the accents?
[07:40] <rvba> Very often indeed.  But it doesn't make it right.
[07:41] <jtv> But it's easy to think nobody will care, when actually some piece of software may come along and make assumptions about how your capitalisation rules work.
[07:42] <jtv> And don't get me started on how the Scots are going to fill out fields labeled "Mac"...
[07:42] <jtv> "Ach, I entered ‘Gregor’ but it doesnae work!”
[07:53] <rvba> jtv: care to review a tiny branch? https://code.launchpad.net/~rvb/maas/fix-manpage-generation/+merge/223511
[07:53] <jtv> OK
[07:53] <rvba> Ta
[08:59] <rvba> jtv: I also want to get started on doing some actual coding on IPv6.  Could we have a call (it will be short) to coordinate our work on this?
[09:01] <jtv> rvba: sure — there's some low-hanging fruit.
[09:06] <bigjools> rvba, jtv: please make sure you leave something obvious for me to do
[09:06] <bigjools> since I won't be able to pre-imp unless you volunteer to stay up late :)
[09:06] <jtv> bigjools: there'll be stuff left...  any questions about the cards on the board?
[09:06] <rvba> bigjools: did you talk with Andres about the additional work he wanted to get done on the DHCP stuff?
[09:07] <bigjools> jtv: I've not looked yet
[09:07] <bigjools> rvba: sort of
[09:08] <jtv> bigjools: they all have detailed descriptions... if you see something unclear about one, it's probably going to be unclear about all of them, so let me know.
[09:08] <bigjools> jtv: ok ta
[09:09] <bigjools> jtv: I guess the first thing is to try and get ipv6 working on my test network
[09:09] <jtv> There are also a bunch of known jobs that you can do without though.
[09:12] <bigjools> jtv: why a feature flag?
[09:15] <jtv> bigjools: because there are places where it doesn't look as if we can do both IPv4 and IPv6 — we'll have to choose.
[09:15] <bigjools> jtv: example?
[09:15] <jtv> Which do we tell dhcpd to serve?
[09:16] <bigjools> isn't that automatic depending on what format IP addresses are entered in the cluster interface edit form?
[09:16] <jtv> Which cluster addresses do we discover?
[09:16] <bigjools> all of them, like now
[09:16] <jtv> We don't do that now.
[09:16] <jtv> We only discover the IPv4 ones.
[09:17] <bigjools> that's all of them then, barring the ones we are about to add
[09:17] <jtv> ...
[09:18] <bigjools> we already discover all ipv4, we just add discovery of ipv6 interfaces.
[09:18] <bigjools> and if you set them to be managed, we tell dhcpd to serve on there
[09:19] <jtv> Yes, we can do that one dynamically.
[09:20] <jtv> We'll need some validation changes to make it work that way of course.
[09:23] <jtv> The problem is that right now we have a bunch of places that will quietly give wrong answers if we mix IPv4 and IPv6.  A feature flag buys us the freedom to fix those without breaking normal operation.
[09:23]  * jtv steps out for about 2 minutes
[09:25] <bigjools> jtv: I say just do it right up front
[09:26] <bigjools> a feature flag is just procrastinating
[09:30] <jtv> bigjools: I think we can do it without a feature flag, if we can continue to run celery and such as IPv4, assuming the DNS stuff works out.
[09:49] <AskUbuntu> MaaS region controller with 2 Cluster | http://askubuntu.com/q/484951
[10:40] <bigjools> jtv: I think that would be OK from what I read
[11:55] <jtv> gmb: just spotted one of my pet antipatterns in update_mac_cluster_interfaces.  When you find yourself writing a search loop, extract it.  Don't do what you need to do inside the loop body and then decide that you're only going to do it once, so you can return.
[11:55] <jtv> "Find item.  If found, process item."
[11:56] <jtv> Not: "Loop over items.  If item is what I want, process item.  Break out of loop as an optimisation."
[15:47] <Solution-X> anyone here do much with MAAS? I have a fresh install of 14.04 installed as MAAS controller that is being cranky and refuses to load the images. Installed OS, booted up, apt-upgrade, reboot, create MAAS user, login, click download images. Also tried "sudo maas-import-pxe-files" after as a backup and that completes but does not result in the webpage recognizing the images' existence. Also checked
[15:47] <Solution-X> celery.log and it doesnt spit any errors/warns.
[15:49] <jtv> Solution-X: and the boot images do not show up in the UI?
[15:50] <jtv> It should normally be the one or the other — you get the images, or there's going to be an error in that log...
[15:50] <jtv> (Be aware that the download is huge...)
[15:53] <Solution-X> correct
[15:53] <Solution-X> which is whats confusing me
[15:55] <jtv> In the celery.log, do you see the import task at least starting and finishing?  Or only starting, or neither?
[15:55] <Solution-X> give me a moment and ill drop a paste in...there may be something im simply not seeing
[15:56] <jtv> OK.  I'll have to leave soon, but would like a look.
[15:56] <Solution-X> just started and saw the start task and iftop is showing traffic
[15:57] <jtv> Then that sounds as if it's probably still downloading.  Have a look in /var/lib/maas/boot-resources/cache; you should see the files growing.
[15:58] <Solution-X> that is my impression as well
[15:59] <jtv> You should see a snapshot directory in /var/lib/maas/boot-resources, too.
[15:59] <Solution-X> im trying to more or less tail the process to you without shoving all the logs down your throat
[15:59] <Solution-X> cache  snapshot-20140618-092857  snapshot-20140618-095234  snapshot-20140618-100031  snapshot-20140618-100657  snapshot-20140618-100932  snapshot-20140618-115549
[16:00] <jtv> Looks like you're running a bunch of downloads at the same time, or maybe started a few that were aborted.
[16:00] <Solution-X> probably aborted
[16:01] <jtv> Hope so, because if they're still running they may slow you down.
[16:01] <Solution-X> iftop traffic has subsided, load is 0 https://privatepaste.com/a98fcd3f02
[16:01] <Solution-X> bad formatting but that link is celery
[16:02] <jtv> It goes through phases; it may be unpacking an image file.
[16:02] <jtv> Yup, your imports are probably still running.
[16:04] <jtv> If you're running maas 1.5 (the default for 14.04), make sure you only have one instance of the import script running.  If the downloads are too much, review /etc/maas/bootresources.yaml.  (Finicky syntax, so be careful).
[16:04] <jtv> That file is no longer there in 1.6, but in 1.5 it'll help you restrict what gets downloaded.
[16:05] <jtv> If the script was going through an unpacking phase just now, watch for changes in the latest snapshot directory.
[16:05] <jtv> Gotta run now!
[16:05]  * jtv runs
[16:39] <Solution-X> looks like one of the previous tasks was causing the subsequent imports to fail...maybe i click import when it was already attempting an import when i first set it up...cleared the snapshots and ran another import, this time it was successful
[16:39] <Solution-X> thanks again for the help and advice!
[16:53] <jtv> Clearing the snapshots shouldn't make much of a difference, but they can pile up a bit.  They won't use much space though, because it's all links into the cache dir.
[17:20] <MilesDenver> Is there a way to turn off "maas maas nodes accept-all"
[18:20] <wrale_> is maas 1.3.1 the latest packaged for ubuntu 12.04.4?
[18:21] <wrale_> will i still be able to use juju with this version?
[18:26] <wrale_> is there a simple way of installing the latest version of maas on precise?
[19:52] <MilesDenver> Back working on my system that never Commissions.  I can now look at the install logs, but I'm not seeing the problem.
[20:03] <MilesDenver> The only problems I'm find are possibly not problems
[20:03] <MilesDenver> Could not open device at /dev/ipmi0, so Unable to start ipmievd during installation.
[20:03] <MilesDenver> and ci-info: no authorized ssh keys fingerprints found for user ubuntu.
[20:05] <MilesDenver> Anyone have troubleshooting suggestions?
[20:29] <MilesDenver> My cloud-init.log does show an awful lot of "Failed at attempted import of 'modulename'" -- http://pastebin.com/1daAfrTp
[20:56] <MilesDenver> I suspect I have this problem which is possibly hardware related - https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1321885
[20:56] <MilesDenver> I'm going to manually build and curse the time I've wasted
[20:58] <jhobbs> MilesDenver: can you test running this script on your server
[20:58] <jhobbs> http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/etc/maas/templates/commissioning-user-data/snippets/maas_ipmi_autodetect.py
[20:58] <jhobbs> if you could run that and post the output to the bug that would be good
[20:59] <MilesDenver> hmmm. ok
[20:59] <jhobbs> you'll have to isntall freeipmi-utils first
[20:59] <jhobbs> and run it as root
[20:59] <jhobbs> that's the script that does ipmi config/detection
[20:59] <jhobbs> unfortunately it's hard to get good output from it from the logs
[21:03] <MilesDenver> Where does it output?
[21:04] <jhobbs> it just outputs to console
[21:04] <jhobbs> when you run it yourself
[21:04] <MilesDenver> hmmm, it only output "maas,WOzMJ8pfeG,172.26.0.186,LAN_2_0"
[21:05] <jhobbs> well, that's a good sign
[21:05] <jhobbs> can you use those credentials to access the system?
[21:05] <MilesDenver> oh... with some kind of IPMI tool.
[21:05] <jhobbs> ah yeah
[21:06] <jhobbs> from a remote system, you could use ipmitool - ipmitool -H 172.26.0.186 -U maas -P WOzMJ8pfeG power status
[21:06] <jhobbs> can you also post the output of ipmi-locate ?
[21:09] <MilesDenver> thanks - ipmi-locate http://pastebin.com/Zjtt8s80
[21:10] <MilesDenver> and the ipmitool responds "Error: Unable to establish LAN session Unable to get Chassis Power Status" which likely means a firewall problem
[21:12] <jhobbs> MilesDenver: yeah it looks like detection and configuration is working
[21:12] <jhobbs> MilesDenver: can you ping that host from the maas server?
[21:12] <MilesDenver> I'm supposed to be building an OpenStack Compute Node on this system.  Tomorrow I need to build it manually
[21:13] <jhobbs> ah
[21:13] <jhobbs> out of time for debug then?
[21:13] <MilesDenver> jhobbs well, I can probably debug a bit longer
[21:14] <jhobbs> err, can you try this command ipmitool -H  172.26.0.186 -U maas -P WOzMJ8pfeG power status
[21:14] <jhobbs> oops
[21:14] <jhobbs> ipmitool -Ilanplus -H  172.26.0.186 -U maas -P WOzMJ8pfeG power status
[21:16] <MilesDenver> jhobbs: sure.... long wait (probably my firewall) then
[21:16] <MilesDenver> "Error: Unable to establish IPMI v2 / RMCP+ session Unable to get Chassis Power Status"
[21:16] <jhobbs> k
[21:16] <jhobbs> yeah i agree - sounds like a network issue
[21:16] <lifeless> or a wedged BMC
[21:17] <MilesDenver> lifeless: it's network.  I've never asked for the ports to be opened.
[21:17] <lifeless> MilesDenver: oops;)
[21:20] <MilesDenver> Seems like there is beer downstairs.  I'll come back to this tomorrow, but we have an all hands meeting in 10 minutes.
[21:21] <MilesDenver> Actually, I'll probalby end up on the patio with my laptop in about an hour
[21:21] <jhobbs> sounds rough
[21:21] <MilesDenver> wish you were here