matsubarasmoser, how odd. is there anything I can do to debug this further?00:06
matsubarasmoser, I don't think it's using the daily image, MAAS images have been configured with maas-import-pxe-files00:07
smosermatsubara, can you get console logs ?00:11
smoseri'd like to see them.00:12
smoserwhat version of maas are you using ?00:12
matsubarasmoser, I'm looking at the console through the Raritan java client but it doesn't seem to allow me to change the tty or boot into recovery mode00:12
matsubarasmoser, I'm using the latest package from the daily builds archive:  maas - 0.1+bzr1002+dfsg-0+1007+87~ppa0~quantal100:13
smosermatsubara, can you get ttyS0 logs ?00:21
smoser(serial console)00:21
matsubarasmoser, how could I get those?00:21
smoserwhat made you think yo uwere waiting on eth1 ?00:21
smoserwell, its possible there is serial over ethernet or some way to get at a serial console.00:21
matsubarathe console is halted at the eth0: link become ready00:22
matsubarasmoser, I can show you an screenshot, just a sec00:22
smosermatsubara, ok. if the console is all you have to debug, and you can't get a serial console, then you'll want to edit one of the maas files and remove 'console=ttyS0'00:29
matsubarasmoser, https://dl.dropbox.com/u/551281/node-eth-ready.png00:30
smosereasiest thing to do is just add 'console=tty1' to all of the APPEND lines in the template files in /usr/lib/python2.7/dist-packages/provisioningserver/pxe/00:31
smoserthat will make your graphical console the place where messages get written.00:32
smoseri made the change to use serial console00:32
smoserwhich, honestly, i think is right.00:32
smoserno one will ever have text logs of a graphical console00:32
smosermatsubara, i dont think anything there is unexpected.00:33
smoseryou're just not seeing output becausae its going to the serial console.00:33
smoserdid you follow the above ?00:33
smoserhow to change the console= ?00:33
smosermatsubara, ^00:33
matsubarasmoser, yes, let me change those files00:33
smosermatsubara, you gonna be around a while?00:34
smoseri have got to step away for 20 minutes at least.00:34
matsubarasmoser, like this:  APPEND {{kernel_params(arch="amd64") | kernel_command | console=tty1}} ?00:34
smoserbut i can come back or we can pick up tomorrow.00:35
smoseri'd just add it outside the }}00:35
matsubarasmoser, yes, I'll be around00:35
smoserAPPEND {{kernel_params(arch="amd64") | kernel_command}} console=tty100:35
smoser(basically just append that string to the end of those 'APPEND' lines)00:35
matsubarasmoser, cool. did that and am rebooting the node00:36
matsubarasmoser, https://dl.dropbox.com/u/551281/node-eth-ready%3Dconsol-tty1.png00:39
matsubaraso I guess what's failing is maas-enlist and not the network interface readyness00:40
smosermatsubara, you should get mor output than that.01:06
matsubarasmoser, that's all I got with that change01:06
smoseri'm not sure what would be saying 'hostname' like that.01:06
smoserthe hostname is 'maas-enlist' because that is what the kernel cmdline says to set it to.01:07
matsubarasmoser, I did notice that console=tty0 was still in the parameters for the kernel when the node booted01:07
smoser"no response after 2 seconds" giving up01:07
smoseri didnt think i saw that bfore01:07
smoseroh, wait, but it does retry, i'm almost certain of that.01:07
smoserroaksoax, is there anyway we can get ttyS0 output in that lab?01:08
smoseripmi or something?01:08
smosermatsubara, is there any doc on that lab? i've not played in it.01:11
matsubarasmoser, https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab01:11
smosermatsubara, you added 'console=tty1' to each of those files ?01:13
smoseryou should see hte kernel cmdline printed to the console01:13
smoserand you can verify that the last thing on it should be 'console=tty1'01:13
smoserwe can also add '--verbose' and 'debug=101:13
smoserand that will give you no shortage of data01:14
matsubarasmoser, I added to both APPEND lines. let me add those two other options01:14
smoserwhich file ?01:14
matsubarasorry, yes01:14
smoseris probably the rigth one for enlistment and commissioning01:14
matsubarasmoser, https://dl.dropbox.com/u/551281/node.png01:20
smosermatsubara, can you just let that sit there? it should get furhter eventually.01:41
smosersomething else shoudl happen. it might be 300+ seconds. but *something* should happen01:41
smosermatsubara, well... good news and bad news.01:55
smosergood news, i just successfully enlistsed a node following http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt01:55
smoserwithout using the 'daily' ephemeral image (which is what you were doing).01:56
smosermatsubara, ah. i wonder.01:56
smoserdid you knwo that you have to fix dhcp ?01:56
smoseri'll look more at this tomrrow with you if thats ok.01:56
smoserbut i'm not really sure what i could have regressed.01:57
matsubarasmoser, what fix to dhcp?02:20
matsubarasmoser, if I let it sit there it stays there, doesn't seem to time out02:21
roaksoaxsmoser: yeah ipmi should be your best bet if those have ipmi02:29
smoserwell, in my setup next-server got set incorrectly.02:39
smoserso i had to fix 'next-server' in /etc/dhcp/dhcpd.conf02:39
matsubarasmoser, right, I fixed that running dpkg-reconfigure maas-dhcp02:40
smoserthat wouldn't get fixed by that.02:40
smoseri dont think02:40
smoseror if it does, then i misunderstand the problem.02:40
matsubarasmoser, I ran dpkg-reconfigure maas and then dpkg-reconfigure maas-dhcp to get the proper dhcpd.conf written02:41
smoserah. ok. so then you have dhcpd running on the same interface as maas-server02:42
smoser(ie, eth0 for you probably)02:42
jtv(meanwhile, any new information on the “cp” problems in maas-import-ephemerals?)02:42
matsubarasmoser, yes02:42
smosermatsubara, how long did you let it sit at that ?  and did you do so with --verbose and debug=1?02:44
smoseryou may have to let it set for 5 minutes.02:44
smoserbut something should time out.02:44
matsubarasmoser, nope, I let it sit for awhile, I guess more than 5 min. I can try it again02:44
smosermatsubara, the other thing we can do is take the 'console=ttyS0' out of /usr/share/pyshared/provisioningserver/kernel_opts.py and restart maas-pserv02:48
smoserbut i really dont think thats going to have an affect.02:48
smoserthe only other guess i have is that I changed 'ip=dhcp' to 'ip=::::<hostname>'02:49
smoserbut my test here verified that that generally works even on the precise image.02:49
smoserto be clear, I changed kernel paramters, adding 'console=ttyS0'02:50
jtvsmoser: sorry to interrupt — maybe you thought my questions were rhetorical or something, but I really need to know.  Is it only for our own dhcpd instance that the leases file needs to be root-owned?  If so, how can we work around that?  If not, how does the regular dhcpd write to it?02:50
smoserand 'console=tty1'02:50
smoserits only the leases file.02:50
smoserit opens it for wrigint before dropping permissions is what I suspect02:50
jtvI am asking a question about the leases file.02:50
jtvYou answer with “it's only the leases file.”02:50
jtvI think we're still talking at cross purposes.02:50
smoser"regular dhcpd" writes that file as root (look at /etc/init/dhcp-isc-server.conf)02:51
smoserwe need to do exactly the same thing.02:51
jtvBut the dhcpd doesn't run as root, does it?02:51
smoserit opens it for wrigint before dropping permissions is what I suspect02:52
jtvWhat is wrigint?02:52
jtvThen don't type it wrong twice!02:52
jtvIf you repeat an obvious mistake, you reinforce the notion that you're doing it deliberately — leaving me with the puzzle of what you mean if not the obvious.02:53
smoserbut if you looked at /etc/init/dhcp-isc-server.conf or actually played with this, you'd see.02:53
jtvI did look at dhcpd-isc-server.conf… and in fact it's where I copied my own version from.02:54
smoserchown root:root /var/lib/dhcp /var/lib/dhcp/dhcpd.leases02:55
smoserchown root:root /var/lib/dhcp/dhcpd.leases~02:55
smoserwhere yours did:02:55
smoserchown maas:dhcp $LFILE02:55
smoserchmod g+w $LFILE02:55
jtvInteresting — I wonder if I just missed that comment.02:56
jtvNope: the comment is not there in the version of isc-dhcp-server that I have installed!02:56
matsubarasmoser, not sure if it changes anything but I'm running this on quantal (I upgraded the QA lab to quantal last Friday)02:56
jtvThe version I get installed chowns the leases file to dhcpd:dhcpd.02:57
smosermatsubara, well, it should not hcange anything.02:57
jtvSo this looks like a Quantal change.02:57
jtvWhat I did was apparently right for Precise, and what you ran into was new to Quantal.  I wonder why they made that change.02:58
smoserit would seem potentially a change in behavior from upstream 4.1.ESV-R4 -> 4.2.203:05
roaksoaxjtv: cause it is usually better to run a daemon as a user and not as root03:13
matsubarasmoser, apparently it doesn't time out. it's been stuck there for more than 5 min03:16
matsubarasmoser, last message is eth1: no IPv6 routers present03:17
smoserthats random.03:17
smoserit seems to me like you're not getting a dhcp response.03:17
smoseror you got one on the wrong interface.03:17
smoserbut i really think the former.03:17
smoserroaksoax, it runs as non-root in precise also.03:18
smoserit really seems like a bug (regression) to me that their code now opens the leases file before it drops its permissions.03:18
smoserbut, that is the way it is, and we'll just have to deal with that or come up with some solution that works both on precise and quantal.03:18
smosermatsubara, see above.  again, i can poke at this some tomorrow.03:19
matsubarasmoser, ok. I'll ping you. thanks!03:19
matsubarait's strange because it does get the IP adress and gets the image from the tftp server03:20
roaksoaxsmoser: most likely, the changelog doesn't seem to provide any hint of the change on permission for the leases file though03:20
smoserupstream changelog?03:20
smoserthe ubuntu bzr log is screwed up due to the importer sucking03:21
smoseri already blamed mdlesuer for something that wasn't his fault as a result :)03:21
roaksoaxsmoser: i'm checking on debian's changelog03:22
jtvroaksoax: that's the funny thing — dhcpd was _already_ running as its own user.  The change I'm wondering about is that the leases file must now apparently be owned by root rather than by the one user that's supposed to read and write the file.03:23
roaksoaxjtv: right, so I'm wondering if this was due to a recent upload, and if so, have you identified which one is it?":03:24
roaksoaxjtv: this could also be related to the fact that we are running our own dhcp server too03:26
jtvroaksoax: those are exactly the answers I've been trying to get out of Scott.  And now it finally turns out that he's been looking at a different version of the package than I got.03:27
jtvIt turns out that the leases file needs to be root-owned _in the regular Quantal isc-dhcp-server package_.03:28
jtvNot funny — cost me days off this end of my life and probably a few years off the other end.  “Why don't you just look at the file?  It's so simple.  I'm not going to answer direct questions.”03:29
jtvWell in retrospect maybe it is a little funny.03:29
jtvAnyway, the Quantal package's upstart script chowns the leases file to root, and has a comment saying that this is required.  The precise version didn't have any of that.03:30
jtvSo it's not related to the fact that we're running our own instance — it just complicates running our own instance.03:31
roaksoaxjtv: right, but if we are running our own version, it still meeans we assign permissions as maas:root or maas:dhcp03:32
jtvWell that's the thing: _something_ in the package seems to be requiring root:root, so apparently it has to be root:root.03:33
jtvIn Quantal.03:34
jtvBut making it root-owned may actually break the Precise version.03:34
roaksoaxjtv: right, so it is simply different permissions for each verison of the package03:36
jtvCan we do that easily?03:36
jtvroaksoax: does that mean I should just propose separate (but similar) branches for the packaging and packaging-precise branches?03:39
roaksoaxjtv: the precise packaging branch has changes stacked on top of the quantal branch03:40
roaksoaxjtv: so the process should be propose to quantal03:40
roaksoaxthen apply precise changes and commit to precise03:40
roaksoaxor propose to precise too03:40
jtvOK I'll focus on getting it working on quantal then.03:41
roaksoaxjtv: ok, let me know if I can help with anything (of course i'd take care of it tomorrow_03:43
roaksoaxjtv: or just drop me an email with what's needed to get changed and I will take a look at it tomrorow03:43
roaksoaxnow i'm off to bed03:43
jtvThanks and good night!03:43
=== matsubara is now known as matsubara-afk
=== matsubara-afk is now known as matsubara
rbasakallenap: I have an issue with gen_pxe_template_filenames. I need an ARM-specific version of config.template, but this isn't currently possible. See http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/src/provisioningserver/pxe/config.py#L4514:12
rbasakallenap: can we get rid of config.template altogether and require every template to have a purpose?14:12
rbasakalexmoldovan: or alternatively have a config.template.{arch} fallback before config.template?14:12
rbasakuh, allenap14:13
allenaprbasak: First thing, the docstring lies; config.{purpose}.template will always be tried before config.template.14:15
allenaprbasak: Ignore that.14:15
allenapI am very tired right now :)14:15
allenaprbasak: If you mean you want the same template for multiple purposes, then I suggest using symlinks.14:16
allenaprbasak: These already exist for other templates.14:16
allenapWhere these equals symlinks.14:17
rbasakI don't think that solves my problem14:17
rbasakI need config.template to be different on ARM14:17
allenaprbasak: config.arm.template with symlinks for each purpose?14:18
rbasakSo we either need to drop config.template and use specific purpose templates only (in which case I can use the existing override), or we need to add an extra override14:18
allenapI don't really understand the problem.14:18
rbasakWe could do that, but then it wouldn't be parallel to x8614:18
rbasakIf we do that, then we want config.template with x86 symlinks for each purpose too14:18
rbasakI want to do the same as what's there already with just the exception for arm present, rather than arranging everythign there differently for arm and thus confusing future work14:19
allenaprbasak: I don't think that's a problem - not being symmetrical - but I think I still don't really see what the issue is. Another way to do it might be:14:23
allenapget rid of the {purpose} lookup, and instead pass purpose in to the template's namespace. Then the template can choose what to render.14:24
allenaprbasak: I think that actually makes more sense in terms of making these templates useful for multiple architectures.14:27
allenapEnabling a new piece of hardware would mean providing templates for all purposes on its arch, not just a subset.14:27
rbasakallenap: that's a fairly hefty change and I'm not sure what benefit it would give us given where we are right now. We don't know what'll happen to the boot purposes in the end either, right?14:28
rbasakallenap: I think I'd prefer to add a fallback to config.<arch>.template which I know won't break anything14:28
rbasak(and is a trivial change)14:29
allenaprbasak: Yeah, I still don't see why it's needed. It complicates the lookup, which can already be hard to follow. Just use symlinks for now. There are three boot purposes to make links for : commissioning, install, and local.14:31
rbasakallenap: so we already have a config.commissioning.template and a config.local.template14:33
rbasakallenap: can I just rename the existing config.template to config.install.template then?14:33
rbasakallenap: then I can have easy armhf overrides as necessary14:34
allenaprbasak: Yeah, that makes sense. That was your original suggestion too. Sorry, I'm not in a fit state to field questions today!14:35
rbasakallenap: no worries. I wasn't sure if there were other boot purposes too before. I'll test and get a merge proposal in.14:36
allenaprbasak: get_boot_purpose can also return "poweroff", but this isn't handled anywhere. That's returned for nodes that really ought not to be booting.14:37
rbasakallenap: is that just an fyi or will it affect my proposed change?14:38
rbasakAIUI, I can ignore that?14:38
allenaprbasak: fyi14:38
mgzcan I mark my own mps approved if they have an approve vote and I've done the requested changes?14:38
rbasakRight. Thanks!14:38
allenapmgz: Yes.14:39
mgzallenap: ta14:39
allenapmgz: For small changes you can +1 and land your own mps too if waiting for a review is going to block you.14:39
rvbamgz: don't forget to set the commit message otherwise the MP won't be picked up by tarmac.14:39
mgzrvba: also ta14:40
mgz"[bug=]"... seriously?14:40
mgznot pulling the author/bug details from bzr is bad enough, but we want to pander to commit log parsers so dumb they can't cope with a missing field?14:43
mgzor is tarmac adding that?14:44
rvbaYep, tarmac does that.14:44
mgzokay, /me bops tarmac on the head for being silly14:45
smoserthis make any sense to anyone15:51
ubot5Ubuntu bug 1051626 in MAAS "next-server written wrong" [Critical,Confirmed]15:51
smosersee my last comment there. i'm not sure what is making the pxe boot take a different path15:51
smoserallenap, where is your maas cli branch ?15:52
smosernever mind15:52
roaksoaxrvba: btw.. were you able to look on the release support branch?16:00
allenapsmoser: Weird indeed!16:03
rvbaroaksoax: we talked about it this morning during the standup.  Jeroen pointed out that you should use the new model BootImage, instead of getting the list of releases from the command line tool.16:04
roaksoaxrvba: we are not getting the releases from a command line tool16:04
roaksoaxrvba: the realeases are being get from python-distro-info16:04
=== matsubara is now known as matsubara-lunch
rvbaroaksoax: ah right, I see that now.  I was just wonder were that UbuntuDistroInfo was coming from.16:05
rvbaroaksoax: still, BootImage should probably be used instead.16:05
roaksoaxrvba: what's that now ?16:05
rvbaroaksoax: src/maasserver/models/bootimage.py16:06
roaksoaxrvba: right, so hold on, how we want to obtain the releases from what boot images we have available, since we should obtain the bootimages from the releaes that we have available16:07
roaksoaxrvba: i mean... we should obtain images from release, not release from images available16:07
smoserallenap, at the risk of seeming completely stupid.16:08
smoserhow can i play wiht maascli16:08
roaksoaxjtv: still around?16:08
rvbaroaksoax: maas-import-pxe-files should populate BootImage.16:09
rvbaand maas-import-pxe-files uses distro-info.16:09
allenapsmoser: Branch lp:~allenap/maas/command-line, make, then use bin/maascli api login --help to get started.16:09
allenapsmoser: It hasn't landed yet :-/16:10
roaksoaxrvba: right, but IMHO, maas-import-pxe-files should obtain the images from the releasea MAAS knows about, not the other way around16:10
smoserallenap, well, 'make bin/maascli' was failing for me16:10
smoseri had'nt 'amke install-dependencies' yet16:10
roaksoaxrvba: so maas-import-pxe-files should obtain the releases tht MAAS support16:10
roaksoaxrvba: so maas should determine what releases it supports, not a helper script16:10
smoserbut truthfully, the point of 'make' is that it would have recognized i'd not done that :)16:10
smoserplus, i already have maas installed on the system via package. i hate pypy16:11
rvbaroaksoax: your suggestion makes sense to me.16:11
smoseranyway, i'm getting there.16:11
roaksoaxrvba: ok, so we really need to get something in asap as it is really delaying my work16:11
roaksoaxrvba: improvements can always con after we have the main parts in16:12
roaksoaxsuch as better determining the avaalble releases16:12
rvbaroaksoax: granted.  So my suggestion is this: hardcode the available versions for now: XXX = ['precise', 'quantal']16:12
rvbaroaksoax: the rest can stay as is.16:13
roaksoaxrvba: OK16:16
roaksoaxrvba: do you also want split braches?16:16
rvbaroaksoax: you could simply split that branch into two: one for the db change and one for the rest but I'm ok with one branch if that's easier for you.16:17
smoserrbasak, lp:~smoser/maas/maas.ubuntu.com.images-ephemeral now has my pushed branch16:17
roaksoaxrvba: i'll split it for better understanding16:17
smoseri hadn't updated previously. i thought i had pushed.16:18
roaksoaxrvba: though, will it get merged before having all the tests addressed?16:18
rbasaksmoser: I'm having trouble building your PPA mountall with sbuild16:18
rvbaroaksoax: usually, the tests should be done in the same branch.16:18
smoserrbasak, why?16:19
smoser(fwiw, what is there is == to what is in lp:ubuntu/mountall at the moment)16:19
roaksoaxrvba: ok, so that means fixing looooooooooots of them16:19
rbasaksmoser: http://paste.ubuntu.com/1213219/16:19
smoserbut note, that lp:ubuntu/mountal != whats in the archive.16:19
rbasaksmoser: looks like it wants plymouth-dev instead of libplymouth-dev16:20
rbasaksmoser: http://osdir.com/ml/general/2012-03/msg44302.html looks like the same problem16:20
rvbaroaksoax: really?  Since there is a default release, I don't expect this to break that many tests…16:20
roaksoaxrvba: the new attribute brekas them I think16:22
roaksoaxrvba: i'll have to recheck16:22
smoserrbasak, you're trying to build in quantal, right?16:24
smoseryeah, looks like it.16:24
rbasakin a quantal chroot, in precise16:24
rbasakI found --resolve-alternatives16:24
rbasaktrying it now16:24
rvbaroaksoax: only 2 failures.  We should manage :)16:25
rbasakOK that seems to have worked16:25
roaksoaxok cool16:25
rbasakLooks like it's intended sbuild behaviour16:25
=== cmagina is now known as cmagina_away
roaksoaxrvba: alright, I'll do the changes and re-submit the merge proposal(s)16:26
rvbaroaksoax: cool.  One more thing, let's set the default to be '' instead of None so won't have to check for both every time we want to know if the value is empty.16:26
roaksoaxrvba: ok cool16:26
rbasaksmoser: http://people.canonical.com/~rbasak/mountall_2.41~ppa415_armhf.deb but I can loopback mount the ephemeral image once it's installed to stick that in, right? And you want me to regenerate an image from lp:~smoser/maas/maas.ubuntu.com.images-ephemeral and test with that?16:28
smoserrbasak, yeah, pull the m.u.c branch. then edit ARCHES to put armhf in it.16:30
smoserand run16:30
smoseror, you dont really need all the launcher stuff16:31
smoserjust download the .tar.gz file, extract and then run16:31
smoser./maas-cloudimg2ephemeral disk.img arm-kernel arm-initrd arm-manifest16:31
smoserand it should handle it16:31
smoser(then mount loopback and dpkg -i the mountall)16:32
rbasakWhat .tar.gz file? Will a branch checkout do?16:32
rbasaksmoser: ^^16:33
smoserworking on it16:37
smoserrbasak, http://paste.ubuntu.com/1213255/16:46
smoserit looks a lot like that16:46
smoserbut then add the moutnall16:46
smoserand that is not working for me on amd64 on quantal right now16:47
smoseras the apt-add-repository is failing16:47
rbasaksmoser: I'm not with you16:48
rbasaksmoser: we're trying to get me to generate an armhf ephemeral image, right?16:48
rbasakwhat's nelson?16:48
smosermy local '$mirror'16:48
rbasakwhat can I use instead?16:48
rbasaksmoser: so I don't run the command on the first line, right?16:49
=== cmagina_away is now known as cmagina
smoserrbasak, shoot.17:01
smoserdo not run the first line17:01
smoseronly subsequent17:01
smoserbad paste17:01
rbasakalmost there17:01
rbasakdiscovering some dependencies - qemu-user-static and rsync17:03
smoserthat looks a bit better17:03
smoseryou should not need qemu-user-static17:03
smoserif you're doing this on arm17:03
rbasakI'm not17:03
smoserand rsync?17:03
rbasakA script seemed to use rsync17:03
smoseri dont think so17:03
rbasakI'm doing this on my test maas machine, which is virtualised amd6417:03
smoserah. you're right . tree2query does17:03
smoserrbasak, but for this exercise you dont need tree2query17:06
rbasaksmoser: it failed without rsync17:06
smoseryou're nto running tree2query17:07
* rbasak shrugs17:07
smoserand if you're hitting that cod then something else is wrong17:08
smoserrbasak, shoot. thats a bug. let me fix that.17:10
smoseri'm sorry17:10
rbasakit's ok17:11
rbasakI can cope with needing to install rsync :)17:11
rbasaksmoser: dd: writing `/tmp/maas-cloudimg2ephemeral.LKQPwv/mp.K8gUX1/tmp/zero': No space left on device17:12
rbasakis that a problem?17:12
rbasakor intentional to zero out unused space?17:12
rbasakOK so I think I have an image17:13
rbasakin ~/dl?17:13
rbasaksmoser: now what?17:14
rbasaksmoser: I don't understand the different forms these images can take17:14
rbasakThis doesn't look like something that maas-import-ephemerals can read, and I don't see an initrd.gz17:15
smoserrbasak, it updates $img in place17:16
smoserand copied out kernel and intiramfs to the places you told it to17:16
smoserdont use maas-import-ephemerals, just copy those files to the right places.17:16
rbasakOK I think I follow17:16
=== matsubara-lunch is now known as matsubara
smoserrbasak, 39. i think is reasonable.17:25
smoserr39 in that branch.17:25
smoseralmost finished here.17:25
smoserrvba, why do you want to hardcode a list of releases?17:26
smoserwe've solved this problem in distro with 'distro-info' and it magically gets serviced for you.17:27
rvbasmoser: it's just a temporary measure.  We want a central place to store that information.17:27
smosertemporary as in how long?17:28
smoserif temporary as in its-going-to-go-in-12.1017:28
smoserthen use distro-info the shell utility17:28
rvbaJeroen has recently created the BootImage table so it sounds reasonable to use that.17:28
rvbaTemporary as in get-andres-unblocked right now.17:29
rvbasmoser: definitely not something that should go in 12.10.  I'll talk to Jeroen about that tomorrow.  But BootImage should be populated by maas-import-pxe-files which uses distro-info.17:33
=== cmagina is now known as cmagina_away
rbasaksmoser: it's trying to hit archive.ubuntu.com and not ports17:49
smoserrbasak, can i see logs ?17:52
rbasaksmoser: so at least two problems that I can see17:55
rbasakIt hits archive.ubuntu.com17:55
rbasakand resolv.conf is still broken17:55
rbasaksmoser: I'm EOD+1h now17:55
rbasaksmoser: but if it'll help I can show you how to test on this machine yourself17:55
rbasakIt's pretty straightforward17:56
smoserrbasak, your'e not booting that image.17:56
rbasaksmoser: I just this moment realised that17:57
rbasaksmoser: so I only see one /var/lib/maas/...disk.img which I've replaced17:59
smoserrbasak, restart tgtd17:59
smoserand make usre you updated your v/ar/lib/maas/tftp/..... kernel and initrd.gz17:59
smosersorry. i know you're edo17:59
rbasakor /var/lib/maas/ephemeral?18:00
rbasakthe latter I've done18:00
rbasakthe former comes from d-i netinst, no?18:00
rbasaksmoser: looks like it's timing out on nonet again18:03
rbasaksmoser: we need to get it so you can test directly I think18:03
smoserrbasak, lets just look more tomorrow.18:04
smoseri'll try to get in kind of early.18:04
smoserand we can poke at it together.18:04
rbasakok, ping me when you're in18:04
smoserrbasak, /var/lib/maas/tftp/amd64/generic/precise/commissioning/ is not install though18:05
smoserits the kernel copied from import-ephemerals18:05
rbasakgood point18:06
rbasakso I probably just ran the wrong initrd against the image18:06
rbasaknever mind, I'll try again tomorrow18:06
smoserrbasak, shoot.18:09
smoserwhat does os.uname report on arm ?18:09
roaksoaxrvba: still around?18:12
rvbaroaksoax: unfortunately, yes :)18:13
roaksoaxrvba: are you gonna be here long?18:13
rvbaroaksoax: probably not.18:14
roaksoaxrvba: so I should start then: https://code.launchpad.net/~andreserl/maas/add_node_distro_series/+merge/12501018:14
rbasaksmoser: http://paste.ubuntu.com/1213406/18:19
smoserrbasak, and uname -m ?18:19
smoseractually. that is good enough.18:19
rbasaksmoser: armv7l18:20
smoserrbasak, sorr to abuse you18:21
smoserdpkg --print-architecture18:21
smoserprints armhf, right?18:21
rbasaksmoser: armhf18:21
roaksoaxrvba: https://code.launchpad.net/~andreserl/maas/distro_series_support/+merge/12501218:21
smoserthen i dont know what is going wrong with mirror selection.18:21
rbasakIt might be that I used the wrong initrd18:22
rbasakI'll test tomorrow18:22
smoserwell, that would possibly cause errors, but not *those* errors :)18:22
roaksoaxrvba: where do I modify apidoc?18:22
roaksoaxsince I'm adding a parameter to "start"18:22
rvbaroaksoax: in the docstring of the API method.18:22
roaksoaxrvba: should we explain what it is used for?18:24
rvbaroaksoax: yes.18:24
roaksoaxrvba: and finally: https://code.launchpad.net/~andreserl/maas/add_api_parameter_for_ubuntu_series/+merge/12501618:31
roaksoaxrvba: now, does these two tests satisfy the new methods added on src/maasserver/models/node.py (get_distro_Series and set_distro_series)18:45
roaksoaxrvba: http://paste.ubuntu.com/1213438/18:46
rvbaroaksoax: looks ok to me.18:47
rvbaroaksoax: I'll step out in a few minutes but I'll review your branches tomorrow.  Thanks for all the changes and for refactoring your work into separate branches.18:49
roaksoaxrvba: no prob ;)18:49
roaksoaxand thanks for reviewing18:51
smosermatsubara, around ?19:22
smoseri'm finally into the lenovo lab19:23
=== flacoste changed the topic of #maas to: 3 weeks until Final Freeze | Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/
smosermatsubara, ping19:38
matsubarahi smoser19:57
smosermatsubara, hi.20:06
smosersorry. just saw this.20:06
smoseri'm poking at the lab right now.20:06
matsubarasmoser, I'm sharing the terminal with you. did you reinstall maas there?20:07
smoseri've only edited the commissioning kernel cmdline20:07
matsubarasmoser, ok. I think it should be fine to boot a node and see the same issue we were talking about yesterday20:08
matsubaraI thought I had purged the install but it's still there20:08
smoseri think your initial thought was right.20:08
smoseri think we are waiting on eth1 to come up20:08
matsubarahmm so is it a problem with the image itself?20:09
matsubarasmoser, ^20:09
smoserwell, sort of.20:10
smosermatsubara, yeah. my kernel cmdline changes regressed this.20:15
matsubarasmoser, let me know if you need help test things out there. Are you using the browser based raritan client?20:17
matsubarasmoser, or the java client?20:17
smoserthe browser didnt' work at all20:19
=== cmagina_away is now known as cmagina
roaksoaxsmoser: i had to install oracle's java client20:23
roaksoaxor java plugin i mean20:23
smosermatsubara, ok.20:24
smoseri am running the standalone and it doesn't completely suck20:25
matsubarasmoser, I'm using the standalone as well.20:25
smosermatsubara, so here is what i found20:26
smosermy kernel commadnline cleanups regressed this.20:26
smoserso i'll submit an mp for that trivial-ish short term fix.20:26
smoserand will pursue a better packaging fix.20:27
matsubarasmoser, cool. thanks20:27
matsubaradid you file a bug for this?20:27
smoseri will do that20:27
smoseralso, you seem to have a bug or misconfiguration of dns20:27
smoseri dont know, but the node thinks its should be able to get dns from
smoserbut that does'nt work20:28
matsubarasmoser, yeah, dns is not working as it was supposed to. Julian asked me to try a few changes to named.conf.options but I didn't yet because of this issue20:28
smoserwell, dns does work for me in my tests20:29
roaksoaxsmoser: so enlistment would also be affected maybe if having an external DNS?20:29
smoserat least caching portion of dns does20:29
smoserroaksoax, i'm confused20:29
roaksoaxsmoser: enlistment tries to detect a DNS server and see whether a host has a DNS entry for it20:30
roaksoaxsmoser: so if cloud-init correctly thinkgs there a DNS, enlistment is affected20:31
matsubarasmoser, with the changes bigjools suggested to named.conf.options the `host security.ubuntu.com` resolves20:31
roaksoaxsmoser: I'll get https://code.launchpad.net/~jtv/maas/packaging-custom-dhcpd/+merge/124594 merged if yoiu dont have any more objections20:32
roaksoaxcomments or suggestions20:33
smosermatsubara, roaksoax https://code.launchpad.net/~smoser/maas/lp1052660/+merge/12504620:52
smoserack that would be nice.20:52
smosermatsubara, that will fix your issue on that system.20:53
matsubarasmoser, thank you20:53
smoseryou will still not have console to the graphical console20:53
roaksoaxsmoser: done20:54
smoserto get that you will need to either locally edit files or get https://bugs.launchpad.net/maas/+bug/1044503 fixed.20:55
ubot5Ubuntu bug 1044503 in MAAS "kernel command line is not easily customizable" [High,Triaged]20:55
smoserrbasak, just saying this out loud so i might remember it.20:59
smoserfor getting BOOTIF to be pegged to 'eth0' (due to limitation of cloud-init and /etc/network/interfaces)20:59
smoserwe might be able to make use of the fact that udev reads rules from /run/udev/rules.d/.21:00
smoserie, we can write those in the initramfs21:00
smoserok. i'm out for th enight.21:02
=== cmagina_ is now known as cmagina_away
=== matsubara is now known as matsubara-afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!