=== Aaton is now known as Aaton_off
[03:56] <jtv> bigjools: could you sanity-check my updated tftp directory layout at the bottom of this document?  https://docs.google.com/a/canonical.com/document/d/1lpaxXmABGz7ytfc7TrXHCwin7B08EJBEHVyG92KO2qw/edit#
[03:56] <bigjools> jtv: yup
[03:56] <jtv> Thanks.
[03:57] <bigjools> jtv: we have a call shortly, we can discuss?
[03:59] <jtv> Yes
[04:01] <bigjools> jtv: ok waiting for you on skype
[04:01] <jtv> Coming
=== Aaton_off is now known as Aaton
[05:41] <bigjools> *cobblerrage*
[05:45] <bigjools> jtv: have you seen cobbler just suddenly decide to stop authenticating on the web ui?
[05:45] <bigjools> the log says:
[05:45] <bigjools> Wed Jun 13 05:39:20 2012 - INFO | REMOTE invalid token; user(???)
=== matsubara_ is now known as matsubara
[06:48] <jtv> bigjools: you get that exact authentication failure if your token has expired — or for any other kind of problem with the token IIRC.
[06:48] <bigjools> jtv: yes I know, but I am logging in to the web ...
[06:48] <jtv> Ah
=== Aaton is now known as Aaton_off
[10:45] <Daviey> rbasak: Hey, jtc mentioned that you said pxelinux.cfg/default cannot be customised for different architectures
[10:45] <Daviey> I'm missing your concern.
[10:45] <Daviey> jtv*
[10:45] <rbasak> You need to serve a different pxelinux.cfg/default for each architecture, eg. by having different pxelinux.cfg directories
[10:46] <rbasak> Otherwise you'll end up serving the wrong arch kernel
[10:46] <jtv> Hi rbasak
[10:46] <rbasak> Hello!
[10:46] <rbasak> Does that make sense?
[10:46] <Daviey> rbasak: I thought we were looking to make them arch named?
[10:46] <rbasak> You could for example have pxelinux.cfg/amd64/default and pxelinux.cfg/armhf/highbank/default
[10:47] <rbasak> Set DHCP "filename" to pxelinux.cfg/amd64/pxelinux.0
[10:47] <rbasak> Or pxelinux.cfg/armhf/highbank/pxelinux.0 if the highbank vendor string is detected
[10:47] <rbasak> But the default files need to be distinct, and pointed to by the dirname part of the DHCP filename entry
[10:48] <Daviey> rbasak: hwhat is wrong with dhcp 209?
[10:48] <jtv> Isn't pxelinux.cfg assumed to be in the same directory as the DHCP filename?
[10:48] <rbasak> Yes, exactly
[10:48] <rbasak> Daviey: dhcp 209: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/927781/comments/2
[10:48] <ubot5`> Ubuntu bug 927781 in u-boot-linaro (Ubuntu) "PXELINUX implementation doesn't respect dhcp ConfigFile or PathPrefix values" [Undecided,In progress]
[10:49] <rbasak> Daviey: ie. no dhcp 209
[10:49] <Daviey> rbasak: 209 = pxelinux.cfg/default-armhf-highbank ?
[10:49] <Daviey> rbasak: i thought we were getting that bug fixed
[10:49] <rbasak> Daviey: AIUI, it's a wontfix because the feature is already supported via the filename dirname
[10:50] <rbasak> Justin did implement the 209 feature, but I don't think it went anywhere after that
[10:50] <Daviey> rbasak: before Justin left, he wrote a patch for 209
[10:50] <Daviey> hah
[10:50] <rbasak> jhobbs pointed out in comment 2 that the existing support is sufficient
[10:51] <rbasak> It's just a question of how we arrange the pxelinux.cfg directory
[10:51] <rbasak> And this is only really necessary for the default files
[10:51] <rbasak> You could for example only serve a subarchdirectory filename entry for unknown MACs, and for known MACs just make the MAC-based config file correct for the architecture that we know it is
[10:51] <rbasak> Assuming that we know the architecture as soon as we know the MAC
[10:52] <Daviey> well default file handling is a PITA
[10:53] <Daviey> we'd need /var/lib/tftpboot/pxelinux.cfg/$arch/$flavour/default
[10:53] <rbasak> It isn't nice, but getting U-Boot support for 209 into every vendor firmware isn't really practical AFAICT
[10:53] <Daviey> rbasak: can you investigate if we can at least get that patch in trunk?
[10:54] <rbasak> That's a pretty big task to pick up
[10:54] <rbasak> I didn't even write the patch remember
[10:54] <rbasak> I'm not sure it's worth it given our current priorities
[10:55] <Daviey> rbasak: Yeah, i asked Justin to write the patch.. but i suspect he won't follow through with it now :)
[10:55] <Daviey> rbasak: current priority is pretty clear from #8.. we are still doing it wrong.
[10:55] <rbasak> I think we need to assume that the patch won't be present in vendor firmwares
[10:56] <jtv> If it helps, the question that's blocking us now is what would be a sensible directory structure for the files we need to serve on tftp.
[10:56] <rbasak> I'm not sure I understand what #8 means
[10:56] <Daviey> rbasak: it's a big task to submita pull request for this patch?
[10:56] <rbasak> We need to have a different kernel for every subarch
[10:57] <rbasak> Daviey: it's a big task to follow it through and potentially fix future bugs found in relation to the patch
[10:57] <Daviey> ok, fine, i'll just do it myself.
=== matsubara_ is now known as matsubara-lunch
[10:57] <rbasak> If we need to have a different kernel for every subarch, we need to have a mapping from vendor class identifiers to our subarch names
[10:58] <rbasak> The mapping is within each default file
[10:59] <rbasak> Apart from the specific paths in use, I don't see how we could do it differently
[10:59] <rbasak> jtv: I think a sensible directory structure would be:
[10:59] <rbasak> pxelinux.cfg/amd64/{pxelinux.0,default}
[11:00] <rbasak> pxelinux.cfg/armhf/{armadaxp,highbank}/default
[11:00] <rbasak> pxelinux.cfg/combined/<mac>
[11:00] <rbasak> or if you don't like combined, just put each <mac> entry in the correct arch/subarch directory
[11:00] <jtv> Actually I wasn't expecting to be able to rearrange things inside the pxelinux.cfg directory… how do we tell clients what to look for in there?
[11:01] <rbasak> They look for their mac address in the directory that pxelinux.0 came from, which is specified by the DHCP filename field
[11:02] <jtv> So pxelinux.0 is inside the pxelinux.cfg?
[11:03] <rbasak> Oh, good point
[11:03] <jtv> (Stupid perpetual unity crashes…)
[11:03] <rbasak> I'm wrong. The pxelinux.cfg directory is expected to be in the same directory as pxelinux.0
[11:03] <jtv> That's what I thought.
[11:03] <rbasak> Let me try again
[11:03] <jtv> Have a look at the updated google doc.
[11:04] <rbasak> amd64/pxelinux.0
[11:04] <jtv> https://docs.google.com/a/canonical.com/document/d/1lpaxXmABGz7ytfc7TrXHCwin7B08EJBEHVyG92KO2qw/edit#
[11:04] <jtv> Near the bottom
[11:04] <rbasak> amd64/pxelinux.cfg/default
[11:04] <rbasak> armhf/{armadaxp,highbank}/pxelinux.cfg/default
[11:04] <jtv> The examples in the doc don't include release name yet though.
[11:04] <jtv> rbasak: the example you give is included there
[11:05] <jtv> ISTM we can create subdirectories for the initrds and kernels per release, and keep everything else as in the doc?
[11:07]  * jtv fiddles
[11:09] <jtv> There.  That's assuming that a node's specific config file will contain a reference to the right initrd/kernel, with its path.
[11:09] <jtv> Ooo, comments are flowing.  Thanks Robie.
[11:11] <rbasak> jtv, Daviey: would a quick G+ be worth it? I think it's important we get this right, I haven't made any mistakes and we're all clear on how this wil work :)
[11:13] <jtv> Sure.
[11:13] <jtv> Who wants to set up a hangout?
[11:14]  * rbasak does one
[11:18] <rbasak> Daviey: ?
[11:19] <Daviey> rbasak: I think 209 is the /right/ fix TBH
[11:19] <rbasak> Daviey: I agree, but I'm being pragmatic. It's never gonna happen.
[11:19] <rbasak> Since some vendors will never have caught up
[11:20] <Daviey> rbasak: you know we are stakeholders in defining this stuff, right?
[11:21] <Daviey> rbasak: we may well need to chainload into 'someting smarter' regardless.. Depending on embedded firmware for anything is a limitation we need to be careful folding into.
[11:22] <jtv> Daviey: coming into the hangout?
[11:22] <rbasak> Daviey: can you join our G+?
=== matsubara-lunch is now known as matsubara
=== Aaton_off is now known as Aaton
=== Aaton is now known as Aaton_off
=== matsubara is now known as matsubara-afk
=== hazmat is now known as kapilt
=== Aaton_off is now known as Aaton
=== kapilt is now known as hazmat
[22:30] <kurt_> Can anyone tell me what the mechanism is in maas that copies ssh keys from ~/.ssh/id_rsa.pub to the boot image?
=== Aaton is now known as Aaton_off