| flacoste | bigjools: i'm in the hang out | 00:01 |
|---|---|---|
| bigjools | flacoste: hi - I don't see an invitation | 00:02 |
| bigjools | now I do | 00:02 |
| flacoste | bigjools: it was the hang out linked to the event | 00:02 |
| roaksoax | bigjools: right, but my point was that when you only install maas-cluster-controller you need to tell the MAAS URL too right? | 00:03 |
| === matsubara is now known as matsubara-afk | ||
| bigjools | hi jam | 05:00 |
| jam | hi bigjools | 06:41 |
| jam | (I was around earlier, but had to run some errands) anything you need? | 06:41 |
| bigjools | jam: no, just saying hi :) | 06:42 |
| bigjools | well cool, commissioning a new and I see hardware info appearing :) | 06:56 |
| bigjools | new node*{ | 06:56 |
| jam | bigjools: yay | 06:59 |
| bigjools | sadly the ipmi detection is not so good, it thinks the BMC has an ip address of 0.0.0.0 | 07:11 |
| jam | bigjools: that just means it is accessible from everywhere, right? :) | 07:20 |
| bigjools | jam: that's *one* way of looking at it | 07:21 |
| allenap | Morning. | 08:24 |
| rvba | Morning allenap. | 08:24 |
| jam | bigjools: I think I might know how we've had test suite failures in Jenkins. | 09:01 |
| jam | It appears that if you submit a branch, and it fails the test suite | 09:01 |
| jam | Submitting it again just accepts it (without running the tests) | 09:02 |
| bigjools | ! | 09:02 |
| bigjools | I have done that in the past and it didn't land though | 09:02 |
| jam | I could be wrong, but I just resubmitted to MAAS lander, and I think I can show it failing here. | 09:02 |
| jam | bigjools: https://code.launchpad.net/~jameinel/maas/allow-json/+merge/128512 | 09:02 |
| jam | the first failure gave me the 404 | 09:02 |
| jam | so I just resubmit hoping to get an actual error I can work on. | 09:02 |
| jam | But this time, magic it succeeded. | 09:03 |
| bigjools | hummm | 09:03 |
| jam | mgz: http://stackoverflow.com/questions/5907575/how-do-i-use-pagination-with-django-class-based-generic-listviews | 09:06 |
| allenap | jam: Gah, can't import django in provisioningserver :-/ | 09:16 |
| jam | allenap: I have a fix re-submitted for it. | 09:17 |
| jam | but see above | 09:17 |
| allenap | I nearly added "because Django is an nearly unmitigated pos", but I bit my tongue. | 09:17 |
| jam | Maas decided to land my branch again, when I retried because the first time gave me just a 404 | 09:17 |
| mgz | jam: I have fled upstairs, can mumble from here if we want though | 09:17 |
| jam | mgz: well, I'll be chewing for a bit longer, then I'll poke you for mumble :) | 09:18 |
| mgz | ^and I followed your bad example and told the lander to shut up and try again | 09:18 |
| bigjools | allenap: lol | 09:19 |
| jam | allenap: so if you check my latest 'lp:~jameinel/maas/allow-json' I should have fixed the import issues. However, Maas just rejected my change again, and I can't get the context because 404 | 09:21 |
| allenap | Gah. | 09:21 |
| jam | I'm running a full make check to be sure | 09:21 |
| jam | I can just land on trunk, and see if that resolves things? | 09:22 |
| jam | (and why is it that console output used to work, but is now just always giving 404...) | 09:22 |
| allenap | This is annoying. I guess land on trunk. rvba, do you know if/how we can turn off the gated landings in Tarmac, for a while at least? | 09:23 |
| rvba | allenap: no idea, maybe Diogo documented that somewhere but I doubt it. | 09:24 |
| allenap | We just walk round the back then. | 09:24 |
| jam | allenap: it is possible that it was passing for me because I didn't have the latest trunk. I'll make sure to grab it and check one more time. | 09:25 |
| allenap | jam: I'm running it too. | 09:25 |
| bigjools | it'll be in the tarmac conf | 09:25 |
| rvba | jam: the "Private Jenkins URL" works. | 09:26 |
| * bigjools putting kids to bed, back in 20 | 09:26 | |
| jam | rvba: I can get to the public jenkins, it just doesn't have the new job (172) that claims to be failing. | 09:26 |
| jam | And I can't get to the private jenkins | 09:26 |
| jam | allenap: I do see 2 failures in trunk this time, so maybe I can squash them. | 09:27 |
| allenap | jam: You need the test lab VPN config to get to the private URL, see https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab | 09:27 |
| rvba | jam: like Gavin said :) | 09:28 |
| jam | allenap, rvba: Technically, vpn's are illegal in Dubai, because they get around the content restrictions. but I'll probably give it a shot. | 09:28 |
| jam | allenap: so the tests failing in trunk are the 'maascli' ones. | 09:29 |
| jam | not mine. | 09:29 |
| jam | so I'll land my patch to fix my own broken bits. | 09:29 |
| jam | and then we can look to fix the maascli ones. | 09:29 |
| mgz | don't get yourself hauled off to sit in content prison... | 09:30 |
| jam | allenap: 'bin/test.maas maascli.tests.test_integration' has 2 failing tests for me. | 09:30 |
| jam | mgz: is that 'conTENT' or 'CONtent' ? | 09:31 |
| jam | :) | 09:31 |
| rvba | jam: can you try moving away ~/.maascli.db and run the tests? | 09:32 |
| rvba | jam: we have a bug about the tests using that file… | 09:32 |
| jam | allenap: the maascli tests are failing because of 'resources=description['resources']' not existing. | 09:32 |
| jam | rbasak: confirmed | 09:33 |
| jam | Looks like it might be happening in Jenkins as well? | 09:33 |
| rvba | jam: yeah, that's bug 1063721. | 09:33 |
| ubot5 | Launchpad bug 1063721 in MAAS "The CLI tests depend on the content of ~/.maascli.db." [Low,Triaged] https://launchpad.net/bugs/1063721 | 09:33 |
| allenap | jam: Yeah, the ~/.maascli.db is probably causing that. Also, maascli tests should be run with bin/test.maascli. | 09:46 |
| jam | allenap: they still fail, but I see them being run with both | 09:47 |
| jam | as in running 'make check' they run under bin/test.maas from what I can tell, and they fail here. | 09:47 |
| jam | allenap: if they shouldn't run under 'bin/test.maas' I think you need an --exclude=maascli in bin/test.maas | 09:48 |
| jam | (which comes from buildout somehow) | 09:48 |
| allenap | jam: I'll fix that later. | 09:49 |
| allenap | jam: I get a clean run here, for make check with allow-json. | 09:49 |
| jam | allenap: yeah, other than the maascli stuff, I have a clean run. So I landed it on trunk. | 09:51 |
| jam | mgz: poke for great mumbling | 10:07 |
| jam | allenap: maas lander is still failing follow up branches without any context | 10:07 |
| mgz | third time lucky | 10:08 |
| mgz | maas lander let the search change through | 10:09 |
| jam | mgz: https://jenkins.qa.ubuntu.com/job/maas-merger-quantal/ only shows up to 169, not 170-175 which are the ones that are failing. | 10:09 |
| jam | mgz: make harness | 10:27 |
| jam | from maasserver.models import NodeGroup | 10:28 |
| jam | ng = NodeGroup.objects.ensure_master() | 10:28 |
| jam | from maasserver.testing.factory import factory | 10:28 |
| jam | for i in range(?): factory.make_node(nodegroup | 10:28 |
| jam | =ng) | 10:28 |
| jam | allenap: I'm getting "twistd.pserv Unknown command: maas-pserv" any idea how to fix that? | 10:41 |
| allenap | jam: What are you trying to do? | 10:55 |
| jam | allenap: 'make run' | 10:56 |
| jam | however, I think it is because I still had cruft leftover from failing to uninstall maas | 10:56 |
| jam | So maas-txlongpoll was running in the background | 10:56 |
| jam | rather than just the dev one. | 10:56 |
| allenap | jam: Have you moved the directory or anything that might confuse buildout? Check bin/twistd.pserv to see if there's anything obviously wrong there. | 10:58 |
| jam | allenap: still getting the same error after stopping the other. | 10:58 |
| jam | allenap: Also, this is after doing 'make distclean' which should rebuild those things, right? | 10:59 |
| allenap | jam: Yeah, it ought to. The maas-pserv plugin is picked up from twisted/plugins/maasps.py, so make sure that the root of the tree is mentioned in bin/twisted.pserv. | 11:05 |
| allenap | s/twisted/twistd/ | 11:05 |
| jam | allenap: it is. | 11:06 |
| allenap | Bugger. | 11:06 |
| jam | root, etc, src, contrib/python-tx-tftp | 11:06 |
| jam | allenap: so the actual failure is probably 'no module named tftp.backend' | 11:07 |
| jam | the massps.py is suppressing the other import failure | 11:07 |
| allenap | jam: That should be in contrib/python-tx-tftp. | 11:07 |
| jam | which is in the twistd.pserv path | 11:08 |
| allenap | jam: Can you run through twistd.pserv statement-by-statement and then try importing tftp.backend? | 11:10 |
| jam | allenap: if I insert a PDB at the __name__ == '__main__' portion, I can manually import twisted.plugins.maasps and see that it has the ProvisioningServerMaker class in the namespace | 11:16 |
| jam | allenap: however it still tells me 'unknown command maas-pserv' | 11:16 |
| jam | availabe commands are ampq-longpoll, conch, dns, ftp inetd, mail, manhole, news, portforward, procmon, socks, telnet, tftp, txlongpoll, web, words, xmpp-router. | 11:17 |
| jam | I *do* see 171 unhandled messages in the 'celery' queue... :( | 11:19 |
| allenap | jam: I can't think of another reason why it wouldn't work, but that's obviously a failure of my imagination. I'll keep thinking. If you discover the reason, let me know? | 11:25 |
| jtv | Anybody up for a review of some shell code? It's not much: https://code.launchpad.net/~jtv/maas/bug-1050033/+merge/128685 | 11:29 |
| bigjools | jtv: sure | 11:31 |
| jtv | Thanks. | 11:31 |
| bigjools | jtv: just one point - the args are the wrong way around compared to the more traditional order :) | 11:34 |
| jtv | Depends on the example you pick! Unix tradition is: if one positional argument takes just one value, and another may be given multiple times, the one argument goes first. | 11:35 |
| jtv | Insert long discussion here about whether ln's argument order is intuitive. :) | 11:35 |
| jtv | But yes, cp and mv do put the destination last. | 11:35 |
| jtv | I'll change it. | 11:38 |
| rbasak | Most of the time I use ln, I specify the destination only. It'd be confusing if ln were the other way round | 11:38 |
| bigjools | depends on how you think about which is the destination | 11:40 |
| jtv | Exactly. That's what I hate about it. | 11:40 |
| jtv | Now you don't just have to remember argument order, you have to remember which of several obvious ways to think about the whole thing! | 11:41 |
| bigjools | I just remember original file :) | 11:41 |
| * jtv wishes once again he'd pushed his openssh patch upstream half a decade ago, so he could stop it complaining about host keys for dynamic IP addresses changing all the time | 11:48 | |
| bigjools | the 99-temporary-fix-constraints.patch in packaging now needs removing | 11:58 |
| bigjools | package is ftbfs | 11:58 |
| allenap | mgz: Got time for a 1 minute review of https://code.launchpad.net/~allenap/maas/maas-cli-explain-after-login/+merge/128693? | 11:59 |
| mgz | allenap: sure | 12:01 |
| allenap | Ta. | 12:01 |
| mgz | print() is weird | 12:05 |
| allenap | mgz: Why? | 12:06 |
| mgz | putting a bare print before and after is not how I'd do it, but I tend to the (equally weird) print s.join("\n\n") | 12:08 |
| allenap | mgz: It's irrelevant here, because the target is Ubuntu only, but I avoid that so that line-endings are sorted out by Python, but in that I may be misguided. | 12:11 |
| mgz | you're pretty much always printing to a file opened in text mode, so they get translated | 12:12 |
| mgz | (redirecting stdout to something that has been opened as binary or hacking the stream properties is uncommon) | 12:13 |
| smoser | jtv, you should not care about the extension of a initrd. it never should have been changed. | 12:51 |
| smoser | the 'gzip' executable is not at all involved in decompression of an initramfs. | 12:51 |
| smoser | so, dont worry about it. rename it as you need. | 12:52 |
| allenap | rvba, jtv: Anything in flight that needs to be landed today? | 13:13 |
| rvba | allenap: no. | 13:15 |
| jam | allenap: as near as I can tell, twisted/plugins/maasps.py is just not getting imported. Is there a way to tell what is going on? I guess just stepping from the startup? | 13:38 |
| jam | mgz: poke | 13:49 |
| flacoste | roaksoax: latest daily builds is uninstallable for smoser: http://paste.ubuntu.com/1269262/ | 13:50 |
| rvba | flacoste: for me too :/. I just tested it on a branch new canonistack instance. | 13:50 |
| rvba | brand* | 13:50 |
| smoser | roaksoax, seems rooted in this: http://paste.ubuntu.com/1269276/ | 13:51 |
| rbasak | smoser: I have the bug reproduced and ready for a patch, based on my morning's daily (0.1+bzr1226+dfsg-0+1226+124~ppa0~quantal1) rather than current. | 13:51 |
| jam | allenap: I think I found the problem... after uninstalling the package 'maas' it left a *stale* /usr/lib/python2.7/dist-packages/twisted/plugins/maasps.pyc file | 13:52 |
| smoser | so, i would suggest that right now, archive install of freeipmi-tools is uninstallable | 13:53 |
| Daviey | smoser: I did an upload earlier | 13:54 |
| Daviey | Maybe it's still being published | 13:54 |
| allenap | jam: Ach, that's bad. I guess that's a dpkg bug? | 13:54 |
| Daviey | check which version is apt-cache policy | 13:54 |
| jam | allenap: well, I had to manually mess things up because 'apt-get remove maas' was failing. | 13:54 |
| jam | it was *starting* the services it was trying to remove. | 13:54 |
| jam | and then, failing to remove them. | 13:54 |
| jam | so I might have some things a bit broken here | 13:54 |
| jam | however, after fixing *that*, I now have problems wiwth 'maasserver_config' does not exist. | 13:55 |
| allenap | jam: Right. For now we assume it's an anomaly. | 13:55 |
| allenap | Oh no :-/ | 13:55 |
| jam | that and 'response.getcode()' tuple object has no attribute 'getcode' | 13:55 |
| roaksoax | smoser msybe relsted to being promoted to msin¿ | 13:55 |
| roaksoax | smoser doko promoted it this morning | 13:55 |
| jam | ah, I need to 'make syncdb' to get the db, right? | 13:58 |
| roaksoax | smoser is the bug relsted to not being able to commission with console=ttyS0 still present¿ | 14:00 |
| roaksoax | ? | 14:00 |
| jam | allenap: and it would appear I might have broken start_cluster_controller by changing the return value of MAASClient.post() checking | 14:00 |
| smoser | roaksoax, probably. | 14:01 |
| smoser | https://bugs.launchpad.net/maas/+bug/1061977 | 14:01 |
| ubot5 | Ubuntu bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Triaged] | 14:01 |
| smoser | i'm not *totally* opposed to dropping console=ttyS0 from the cmdline | 14:01 |
| roaksoax | smoser ok.. so we still need to be able to modify that then in an easy manner | 14:02 |
| smoser | as i have no other work around. | 14:02 |
| mgz | jam: wiggle? | 14:02 |
| jam | mgz: just checking how things are going, want to mumble? | 14:02 |
| mgz | sure | 14:02 |
| roaksoax | smoser i think we should be able to have an attribute on the node for that | 14:02 |
| roaksoax | smoser shouldnt be that hard to hack | 14:03 |
| bigjools | roaksoax: yes my machines failed to commission with console=ttyS0 today | 14:03 |
| bigjools | also see the comment above about stale .pyc files left around? | 14:03 |
| smoser | roaksoax, well, the one thing we can fix right now is to remove console=ttyS0. | 14:04 |
| smoser | and i'm not completely opposed to that. | 14:04 |
| smoser | i just think it sucks. | 14:04 |
| roaksoax | smoser i think it is important to make it configurable | 14:04 |
| bigjools | how does a bmc get at console output? | 14:05 |
| roaksoax | adding a paramtet shold be a problem really | 14:05 |
| smoser | it all depends. | 14:05 |
| smoser | (how a bmc gets console output) | 14:05 |
| smoser | some bmc will have serial console "SOL" | 14:05 |
| roaksoax | bidjools you have to configure the bmc and then configure maas to tell what parameters to send | 14:05 |
| smoser | which i would think is most common | 14:05 |
| bigjools | also my BMCs are all failing to get a dhcp address, no idea why. they ignore the dhcpoffer from the server | 14:05 |
| jam | allenap: yay, it wasn't me who broke start_cluster_controller. Someone else changed the dispatcher from using urllib2.urlopen to httplib2.Http() | 14:05 |
| smoser | but i really have not enough experience on server hardware to make broad generalizations on such a thing. | 14:06 |
| jam | allenap: start_cluster_controller seems to be the only thing that is using 'response' directly after post | 14:06 |
| roaksoax | bigjools those pyc files .. idk but its definiteky related to the package split as they werent present before the split but i cant figure out whats wrong | 14:06 |
| bigjools | roaksoax: bug in postrm not pulling in debhelper? | 14:07 |
| roaksoax | smoser in sabdfls cluster i had to odify to ttyS1 but he said he configured that on the bios | 14:07 |
| smoser | so... | 14:07 |
| roaksoax | bigjools i thought you merged that and it would have taken cre of it | 14:07 |
| smoser | my personal feeling on this right now is to just drop all 'console=' params from the cmdline on intel | 14:08 |
| smoser | unless bigjools or someone says "i can make that configurable via file in /etc/ "right now"' | 14:08 |
| bigjools | there's an open bug about it | 14:08 |
| jam | allenap: so your change to using httplib2.Http so that you could set the insecure flag | 14:08 |
| roaksoax | i would go for addint the attribute for the node for custom kernel params | 14:08 |
| jam | broke actually all users of dispatch_query | 14:08 |
| smoser | so unless that happens, i think we live with "configurable" meaning 'change .py files' | 14:08 |
| jam | because it used to return a urllib2 file-like object | 14:09 |
| smoser | bigjools, yes, there is. | 14:09 |
| jam | and it now returns a tuple | 14:09 |
| jam | of response_headers, conte | 14:09 |
| jam | content | 14:09 |
| smoser | bug 1044503 | 14:09 |
| jam | we don't have tests that exercise the code | 14:09 |
| ubot5 | Launchpad bug 1044503 in MAAS "kernel command line is not easily customizable" [High,Triaged] https://launchpad.net/bugs/1044503 | 14:09 |
| jam | because all the tests mock out the connection. | 14:09 |
| jam | because we never run an actuall HTTP server to query against. | 14:09 |
| jam | all of the tags stuff would also show up broken, if we could actually get it running (but we are failing early during startup) | 14:10 |
| bigjools | except in the test he added for that change... the irony ... | 14:10 |
| jam | bigjools: :) | 14:10 |
| bigjools | ok it's past midnight, I need to sleep | 14:10 |
| bigjools | night all, good luck | 14:10 |
| jam | bigjools: sleep well. | 14:10 |
| * bigjools intends to :) | 14:10 | |
| rvba | jam: how could that change break things? It's just a tiny encapsulation, and http_request still returns the result of http.request()…? | 14:11 |
| jam | rvba: we used to return urllib2.open() | 14:11 |
| jam | whicgh is a file-like object | 14:11 |
| jam | with an attribute '.getcode()' | 14:11 |
| jam | rvba: httplib2.Http.request() returns a very different object. | 14:11 |
| jam | namely, a tuple | 14:11 |
| rvba | I see. | 14:11 |
| jam | of ({headers}, content) | 14:11 |
| jam | rvba: it only shows up during 'make run' because that is the only time we actually connect to a real server. | 14:12 |
| jam | rvba: so, do we try to update all clients to a new api? try to wrap it in something that looks like a urllib object? | 14:12 |
| jam | revert the insecure=False change? | 14:12 |
| rvba | I don't think we can revert that change just like that. | 14:13 |
| allenap | jam: Revert I think. | 14:13 |
| allenap | I only just made the change this morning. | 14:13 |
| allenap | I'll do it. | 14:13 |
| rvba | Also, sorry for being thick, but here is the change in question | 14:13 |
| rvba | http://paste.ubuntu.com/1269307/ | 14:13 |
| jam | allenap: thanks | 14:13 |
| rvba | We were using httplib2.Http.request() all along. | 14:14 |
| jam | rvba: wrong code | 14:14 |
| jam | this is the one allenap did | 14:14 |
| rvba | Oh, you're talking about a different change I guess. | 14:14 |
| allenap | rvba: apiclient, not maascli. | 14:14 |
| rvba | Ok, | 14:14 |
| rvba | k | 14:14 |
| jam | allenap: yeah, I think we can revert it for now, and land it after tomorrow and think about what we want to do with the changes. Long term, you like httplib2 more? | 14:15 |
| jam | (it at least lets you allow self-signed certs, I guess) | 14:16 |
| allenap | jam: I was trying to "upstream" the changes in maascli to apiclient so that the former can properly use the latter. There's an impedance mismatch between apiclient and our Pistonesque API that's been mostly figured out in maascli. | 14:17 |
| jam | allenap: yeah, I think it would be nice to update to something closer | 14:18 |
| jam | and I don't think we need to have incremental reads from urllib2 | 14:18 |
| jam | (i don't know if we even have incremental there, but it pretends we do) | 14:18 |
| allenap | jam: Care to rubberstamp? https://code.launchpad.net/~allenap/maas/revert-change-to-httplib2-in-apiclient/+merge/128726 | 14:22 |
| jam | allenap: done | 14:23 |
| allenap | Thanks. | 14:23 |
| jam | allenap: I'm glad I updated to trunk to test stuff today. | 14:23 |
| allenap | jam: Me too :) | 14:24 |
| === flacoste changed the topic of #maas to: Final Freeze is today: waiting on upstream fixes for bug 978127| Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ | ||
| flacoste | roaksoax: any way i can be a bug supervisor for the maas package? so that i can set priority | 14:30 |
| roaksoax | flacoste: being member of the bugsquad or being a core dev :) | 14:31 |
| flacoste | pff | 14:31 |
| flacoste | smoser, roaksoax, Daviey: i'm just going to use a tag to highlight the bug fixed in upstream that aren't in the archive | 14:33 |
| flacoste | too much hassle to create tasks when i cannot set the priority on it | 14:33 |
| allenap | jam: I've filed bug 1064437 about it. | 14:33 |
| ubot5 | Launchpad bug 1064437 in MAAS "The expectations of MAASDispatcher.dispatch_query are not tested" [High,Triaged] https://launchpad.net/bugs/1064437 | 14:33 |
| jam | allenap: thanks | 14:33 |
| smoser | flacoste, fair enough | 14:37 |
| roaksoax | flacoste: what trunk rev are we looking to have in the archives today? | 14:39 |
| jam | mgz: Vq2fSMwMvLXFuGJJyp:fZE7P5qGvgPSudZ8Hh:ZNqct3Pm8pFGh8mT5DVy8Py8JCtg4NaG | 14:40 |
| flacoste | roaksoax: 1238 is the latest, but we are missing a few bug fixes still | 14:40 |
| flacoste | roaksoax: so something like 1241 probably | 14:40 |
| roaksoax | flacoste: ok I think we have until 21:00 UTC so we still have a few hours, but i'd require to do some testing first | 14:41 |
| flacoste | roaksoax: 1239 -> revert of allenap revision breaking start_maas_cluster | 14:41 |
| roaksoax | i'll check back in 1 hr | 14:41 |
| flacoste | 1240 -> smoser fix for oauth in maas-enlist | 14:41 |
| flacoste | 1241 -> IPMI auto-config in maas-enlist (optional really) | 14:42 |
| flacoste | roaksoax, Daviey, smoser: https://bugs.launchpad.net/maas/+bugs?field.tag=missing-in-quantal | 14:44 |
| smoser | flacoste, thanks | 14:44 |
| roaksoax | flacoste: 1241 i'll try to make it happen, but this needs support from maas-enlist too | 14:45 |
| roaksoax | flacoste: so there might not be time to finish it | 14:45 |
| flacoste | roaksoax: right, fwiw, the API changes are available | 14:45 |
| roaksoax | flacoste: yes I saw.. I'll be working on it todayt | 14:46 |
| roaksoax | allenap: ping | 14:54 |
| flacoste | jam, allenap: the reversal in 1239 does that mean that self-signed certificate cannot work with the maas-cli anymore? | 14:54 |
| allenap | flacoste: No, it means it wont' work for users of apiclient. maascli doesn't use apiclient; before reverting this was an attempt to "upstream" the remote code in maascli to apiclient. | 14:55 |
| flacoste | allenap: got it | 14:55 |
| roaksoax | allenap: what am I doing wrong? | 14:56 |
| roaksoax | curl --data "op=new&mac_addresses=e4:11:5b:13:81:9d&hostname=&architecture=amd64&subarchitecture=generic&after_commissioning_action=0&power_type=ipmi&power_parameters={"power_address":"test", "power_user":"test", "power_pass":"test"}" http://localhost/MAAS/api/1.0/nodes/ | 14:56 |
| roaksoax | Failed to parse JSON power_parameters | 14:56 |
| rvba | roaksoax: power_parameters='{"power_address":"test"}' | 14:57 |
| rvba | Note the quotes. | 14:57 |
| rvba | json.dumps({"power_address":"test"}) | 14:57 |
| rvba | '{"power_address": "test"}' | 14:57 |
| rvba | You have to pass a json string. | 14:58 |
| roaksoax | rvba: got it :) | 14:58 |
| allenap | roaksoax: Try: curl --data "op=new&mac_addresses=e4:11:5b:13:81:9d&hostname=&architecture=amd64&subarchitecture=generic&after_commissioning_action=0&power_type=ipmi" --data-urlencode="power_parameters={"power_address":"test", "power_user":"test", "power_pass":"test"}" http://localhost/MAAS/api/1.0/nodes/ | 14:58 |
| roaksoax | it was the quotes | 14:58 |
| mgz | so, it seems django can't do internal redirects... | 15:06 |
| rvba | mgz: you mean redirects to an address created with reverse('view-name')? | 15:16 |
| mgz | rvba: I was just going to make /favicon.ico serve the same result as /static/img/favicon.ico ...but that turned out to be non-trivial | 15:17 |
| mgz | I'd just use apache directives ideally, but don't want to upset django | 15:18 |
| rvba | mgz: why do you want to do that? Also, you cannot assume that the homepage of MAAS is '/'. | 15:18 |
| mgz | because currently requesting /favicon.ico is a 404 and it wouldn't hurt to serve it instead | 15:20 |
| rvba | mgz: src/maasserver/templates/maasserver/base.html: <link rel="shortcut icon" href="{{ STATIC_URL }}img/favicon.ico"/> | 15:21 |
| mgz | browsers tend to request that regardless of html giving a different path | 15:21 |
| allenap | roaksoax: Ah right, yes, the quotes. From looking at --trace-ascii output, http://pastebin.ubuntu.com/1269411/ looks to be the correct way to do this. (You could s/--data-urlencode/--form/g I think too). | 15:21 |
| rvba | mgz: really? | 15:21 |
| allenap | roaksoax: --data is a recipe for failures and/or data corruption, because it assumes that the value is already URL encoded. | 15:21 |
| mgz | yes, what if you're not fetching an html page? (not a common case here, but if was easy to fix I'd just fix it) | 15:22 |
| roaksoax | allenap: cool, I;ll test that | 15:22 |
| rvba | mgz: right. Looks very minor to me… but in production, we have the prefix /MAAS in front of all the urls, so if the browser requests /favicon.ico, it won't get anything back and there is not much we can do about it. | 15:31 |
| rbasak | rvba: could we redirect /favicon.ico to /MAAS/favicon.ico in packaging perhaps? Just an idea. | 15:32 |
| rbasak | Not sure what implications that would have though | 15:33 |
| rvba | rbasak: and what if you install another service in /AnotherService… it will get a wrong favicon. | 15:33 |
| rbasak | Yeah exactly | 15:33 |
| rvba | I don't think we want to hijack /favicon.ico. | 15:33 |
| mgz | why are we trying to support serving multiple different things from one hostname exactly? | 15:34 |
| rbasak | It'd be nice to have it on servers that are dedicated to MAAS | 15:34 |
| rbasak | (by default) | 15:34 |
| rbasak | But the only way I can think of doing it cleanly in packaging is perhaps not the best thing to do for today | 15:34 |
| rbasak | I'm thinking of a separate maas-favicon recommends that conflicts with other services in some way | 15:34 |
| mgz | the other magic top level name has a url mapping at the django level, but I guess just sits harmlessly at /MAAS/robots.txt in deployment | 15:36 |
| mgz | anyway, put up a branch with the fix I was actually aiming at | 15:36 |
| smoser | https://code.launchpad.net/~smoser/maas/drop-ttyS0-kernel-opt/+merge/128747 | 15:46 |
| matsubara | rvba, ping | 15:46 |
| rvba | matsubara: pong | 15:47 |
| matsubara | rvba, so, I just tried maas - 0.1+bzr1226+dfsg-0+1229+124~ppa0~quantal1 on a pristine quantal vm and maas-pserv is not started | 15:47 |
| allenap | mgz: Mark said something about having to use an ico for full browser compatibility. Obviously you're still generating an ico, but perhaps he meant something else by it? | 15:48 |
| rvba | matsubara: anything in the upstart log? | 15:48 |
| rvba | mgz: I was about to ask the same question :) | 15:48 |
| matsubara | rvba, just a bunch of lines like this: Removing stale pidfile /run/maas-pserv.pid | 15:49 |
| rvba | matsubara: I'm trying to install the package from the daily ppa right now… | 15:49 |
| matsubara | rvba, and apt/term.log shows this: maas-pserv start/running, process 10156 | 15:50 |
| matsubara | so I think it started but for some reason it failed | 15:50 |
| mgz | allenap: I interpret what he said as assuming he'd generated an ico containing png files, but if fact he didn't | 15:50 |
| rvba | matsubara: pserv not started here :/ | 15:51 |
| allenap | mgz: Right, cool. | 15:51 |
| matsubara | rvba, aha! | 15:51 |
| mgz | the larger sizes won't stop old (pre-vista internet explorer (do we even care..)) from picking out the 16x16 bitmap | 15:52 |
| matsubara | rvba, so on a upgrade it keeps running fine but not on a new install | 15:52 |
| smoser | someone want to ack that for me? i really hate this change. but i think its a requirement at this point in time. | 15:52 |
| matsubara | rvba, do you know of any other logs that might be relevant? | 15:52 |
| rvba | matsubara: yesterday it was fine :/ | 15:52 |
| allenap | matsubara: You'll need at least bzr 1239 to fix the pserv not starting issue, sorry. | 15:52 |
| matsubara | does your upstart log show anything? | 15:52 |
| rvba | allenap: what was the issue again? | 15:52 |
| matsubara | allenap, ah so you knew about it all along | 15:53 |
| allenap | rvba, matsubara: bug 1064437 | 15:53 |
| ubot5 | Launchpad bug 1064437 in MAAS "The expectations of MAASDispatcher.dispatch_query are not tested" [High,Triaged] https://launchpad.net/bugs/1064437 | 15:53 |
| rvba | mgz: what's the benefit of having all but one of the image as a *raw* png? | 15:53 |
| allenap | matsubara: Ha, I only just saw you having problems. | 15:53 |
| matsubara | hmm I can't build new packages. LP is failing to build packages in the daily builds PPA due to a bzr error | 15:54 |
| matsubara | allenap, no worries, just kidding :-) | 15:54 |
| allenap | Phew :) | 15:54 |
| matsubara | thanks for the pointer | 15:54 |
| mgz | rvba: the 'raw' is a little confusing, but, in short, size | 15:54 |
| matsubara | allenap, where do you see logs for this? | 15:54 |
| matsubara | s/this/this error/? | 15:54 |
| mgz | png is a compressed image format, bmp is not | 15:55 |
| mgz | ico was originally a sort of container for bitmaps | 15:55 |
| allenap | matsubara: I don't; jam told me it was broken. | 15:55 |
| mgz | with recent format revisions it can also be a container for pngs | 15:55 |
| mgz | so, storing the larger images as 'raw' png rather than exploding them to bitmaps saves space | 15:56 |
| rvba | allenap: in this bug, you say is breaks start_cluster_controller, but in the package I'm testing, the cluster worker is started ok. | 15:56 |
| rvba | mgz: I see, I got confused by the world 'raw' indeed :) | 15:57 |
| allenap | rvba: What rev are you on? It was only a problem for revision 1234 to 1238 inclusive. | 15:57 |
| matsubara | rvba, allenap: I got the log line in apt/term.log saying maas-pserv was started but after the package install finishes, the process is not running. Maybe it's failing and reporting a success? | 15:58 |
| rvba | bzr1226 | 15:58 |
| rvba | The revision from the package in the daily ppa. | 15:58 |
| allenap | Ah, so that bug isn't the problem. | 15:58 |
| allenap | For matsubara either. | 15:58 |
| rvba | Yep, there is a real problem then. | 15:59 |
| matsubara | I'm using: 0.1+bzr1226+dfsg-0+1229+124~ppa0~quantal1 | 15:59 |
| matsubara | allenap, btw, this two revision numbers are confusing. when you say 1234..1238 do you mean trunk right? | 16:00 |
| rvba | matsubara: if I start the service manually it seems to be started all right. | 16:04 |
| matsubara | rvba, yep | 16:06 |
| rvba | matsubara:trying one more time on another instance. | 16:07 |
| rvba | matsubara: this time it worker :/ | 16:09 |
| matsubara | ! | 16:09 |
| rvba | worked* | 16:09 |
| matsubara | how weird | 16:09 |
| rvba | /var/log/upstart/maas-pserv.log is still full of "Removing stale pidfile /run/maas-pserv.pid" | 16:10 |
| matsubara | yep, just like mine | 16:10 |
| matsubara | I'm trying again as well | 16:10 |
| matsubara | rvba, how are you starting a new pristine env? | 16:10 |
| rvba | I just start a new canonistack instance, add the daily ppa, and then install maas. | 16:11 |
| matsubara | ok | 16:11 |
| matsubara | allenap, rvba have you seen the last package build failure: https://launchpadlibrarian.net/119221274/buildlog.txt.gz ? | 16:13 |
| allenap | matsubara: Yeah, trunk. | 16:13 |
| matsubara | allenap, is this because of your change? | 16:13 |
| * allenap looks | 16:13 | |
| allenap | matsubara: Nope, I haven't been near the files in 99-temporary-fix-constraints.patch. I think that this has probably been fixed in trunk, so the patch can be removed. rbasak, can you help confirm? | 16:16 |
| smoser | Daviey, roaksoax it seems to me that adding maas-ipmi-autodetect to commissioning broke kvm (and possibly anything that doesn't have such a device) | 16:17 |
| smoser | is there a /dev/ entry that we could expect to be present to know whether or not we should go looking ? or some way to tell freeipmi to time out ? | 16:17 |
| mgz | right, seems that patch just needs removing from the packaging branch | 16:17 |
| smoser | it does seem to timeout eventually, but i'd say its in the 2 minute time frame. | 16:18 |
| matsubara | does anyone know how I could install maas without having to answer the package installation questions? I tried to use a debconf seed file (maas.seed: https://pastebin.canonical.com/76135/) but it doesn't seem to work. Well, I get no questions asked but the default-maas-url value is not set to the one in the seed file. | 16:20 |
| smoser | and then on failure, it still tries to call maas-signal with the power params. | 16:20 |
| matsubara | smoser, roaksoax: maybe one of you know ^? | 16:20 |
| smoser | http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt | 16:21 |
| smoser | matsubara, ^ | 16:21 |
| smoser | see line 90. set DEBIAN_FRONTEND=noninteractive and for good measure set stdin from /dev/null | 16:21 |
| matsubara | smoser, ah thanks | 16:22 |
| Daviey | smoser: we *need* to silently fail, i think | 16:23 |
| matsubara | smoser, you also change the string in the seed passed to debconf? | 16:23 |
| rvba | I think that the pserv service depends on something that is installed by the region cluster. | 16:23 |
| smoser | matsubara, i dont follow | 16:23 |
| smoser | Daviey, it should not attempt to call maas-signal if the probe for ipmi fails. | 16:23 |
| smoser | so we need to handle that bettter | 16:24 |
| smoser | but we also need to not add 2 minutes to enlistment if ipmi is not present | 16:24 |
| matsubara | smoser, lines 82 to 85 | 16:24 |
| matsubara | smoser, ah no, that's just setting the seed file, correct? | 16:24 |
| smoser | matsubara, i'm setting the answer to that question | 16:26 |
| smoser | Daviey, is ipmi a device ? | 16:26 |
| smoser | that i can look for in /dev ? | 16:26 |
| matsubara | right, thanks smoser | 16:27 |
| matsubara | I'll give it a try | 16:27 |
| matsubara | rvba, tried again and pserv is down | 16:27 |
| smoser | awesome. strace on bmc-config shows that it reads /etc/freeipmi//freeipmi.conf 1 byte at a time. | 16:29 |
| rvba | matsubara: if I manually remove all the region stuff, then pserv refuses to be restarted. | 16:32 |
| roaksoax | smoser: ok I see where it dies | 16:32 |
| rvba | /usr/bin/twistd -n --uid=maas --gid=maas --pidfile=/run/maas-pserv.pid --logfile=/tmp/zz maas-pserv --config-file=/etc/maas/pserv.yaml | 16:32 |
| rvba | usr/bin/twistd: Unknown command: maas-pserv | 16:32 |
| smoser | roaksoax, do you know what devices it wants? | 16:33 |
| roaksoax | smoser: smoser FATAL: Error inserting ipmi_si (/lib/modules/3.2.0-31-generic/kernel/drivers/char/ipmi/ipmi_si.ko): No such device | 16:33 |
| smoser | roaksoax, but that doesnt mean anything in and of itself | 16:33 |
| smoser | the driver could fail to load because it was already loaded | 16:33 |
| smoser | or because it was built into a kernel | 16:33 |
| matsubara | rvba, what does the log say? I restarted my environment and got the same problem. | 16:34 |
| roaksoax | smoser: "No such device" --> this caould be 2 things 1. ipmi-locate might be erroneously detecting IPMI and continues, and bc-config gets stuck somewhere | 16:34 |
| roaksoax | or 2. that causes ipmi-locate to get stuck | 16:34 |
| smoser | from strance, it looks like it wants /dev/ipmi0 or /dev/bmc but then it goes looking in /dev/mem also before sleeping | 16:34 |
| roaksoax | smoser: but after a while, it continues | 16:34 |
| rvba | matsubara: the logs says nothing. | 16:35 |
| smoser | roaksoax, yes, it times out after like 2 minutes-ish | 16:35 |
| roaksoax | smoser: yeah.. such a PITA | 16:36 |
| smoser | if i knew what it was looking for in /dev/mem, then i'd just do a udevadm settle after module load | 16:36 |
| smoser | and hten if no /dev/ipmi* or /dev/bmc* then i would skip that. | 16:36 |
| roaksoax | Daviey: so I need to upload maas-enlist source and add a maas-commission binary package | 16:37 |
| smoser | but i'm afraid it might be looking in /dev/mem for some ipmi device that does not have a device driver but is a /dev/mem interface | 16:37 |
| matsubara | rvba, I'm building a new package and we can test allenap fix deals with the issue | 16:38 |
| roaksoax | smoser: http://paste.ubuntu.com/1269561/ | 16:43 |
| roaksoax | smoser: ok, so that will return an output in the way of {"power_address"="X", "power_user"="Y", "power_pass"="Z"} | 16:44 |
| roaksoax | smoser: but I need to pass that to maas-enlist between single quotes, how can I do that? | 16:44 |
| smoser | you actuall do not have to. | 16:45 |
| smoser | $ output=$(echo '{"power_address"="X", "power_user"="Y", "power_pass"="Z"}') | 16:46 |
| smoser | $ sh -c 'echo "1=^$1$"' -- "$output" | 16:46 |
| smoser | 1=^{"power_address"="X", "power_user"="Y", "power_pass"="Z"}$ | 16:46 |
| smoser | ie, get the output, and quote the variable with doble quotes and you're fine. | 16:46 |
| smoser | roaksoax, http://paste.ubuntu.com/1269572/ | 16:49 |
| smoser | thats in a kvm node. | 16:49 |
| smoser | so there is 10 minutes of builtin sleep by that program by default. meaning enlistment of anything without ipmi is delayed 10 minutes. | 16:49 |
| roaksoax | smoser: right... but it order for it to get there, ipmi-locate must have succeeded | 16:50 |
| smoser | unlikely. | 16:50 |
| smoser | there is no ipmi. | 16:50 |
| roaksoax | so maybe it is getting stuck in ipmi-locate | 16:50 |
| roaksoax | unles it "detects" it | 16:51 |
| smoser | https://bugs.launchpad.net/maas/+bug/1064527 | 16:52 |
| ubot5 | Ubuntu bug 1064527 in MAAS "ipmi detection takes 10 minutes if no ipmi present" [Undecided,New] | 16:52 |
| roaksoax | smoser: in my case it didn't take 10 mins | 16:53 |
| roaksoax | :) | 16:53 |
| rvba | matsubara: I think allenap and I found the problem, | 16:53 |
| smoser | roaksoax, http://paste.ubuntu.com/1269579/ | 16:53 |
| smoser | really? did you try in a kvm instance? | 16:53 |
| matsubara | rvba, what is it? | 16:53 |
| rvba | Problems* I should say. | 16:53 |
| roaksoax | smoser: yes I tried the kvm instance, it took like 1 min or so | 16:54 |
| smoser | i dont know tha ti believe you, roaksoax | 16:54 |
| smoser | 10m0.X seconds for the whole command, that I straced elsewhere and watched to 'nanosleep' repeatedly | 16:54 |
| smoser | is a very suspicious time | 16:55 |
| rvba | matsubara: 2 things: a) the cluster controller misses some of the required dependencies (txamqp at least) b) it tries to write its log to /var/log/maas which does not exist before the region is also installed. | 16:55 |
| smoser | but none the less. | 16:55 |
| rvba | It works sometimes because (I guess) the region gets installed right after the cluster. | 16:55 |
| rvba | So the dependencies are there and /var/log/maas is created. | 16:55 |
| rvba | I'm guessing the upstart script retries to start the service a few times. | 16:55 |
| rvba | I the installation of the region is quick enough, it manages to start the pserv service. | 16:56 |
| matsubara | I see | 16:56 |
| roaksoax | rvba: if you pressume is because the /var/log/maas dir is not create, please file a bug , assign it to me, and explain which package should also create the log dir | 16:56 |
| rvba | roaksoax: that's one of the 2 problems indeed. | 16:57 |
| rvba | roaksoax: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1064539 | 17:04 |
| ubot5 | Ubuntu bug 1064539 in maas (Ubuntu) "The pserv service logs to /var/log/maas/pserv.log and that directory (/var/log/maas/) is not created but the cluster controller package" [Critical,Triaged] | 17:04 |
| rvba | s/but/by/ | 17:05 |
| allenap | roaksoax: I have to go, but can I bring https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1064542 to your attention? I can't mark it critical, but I think it is. | 17:10 |
| ubot5 | Ubuntu bug 1064542 in maas (Ubuntu) "python-maas-provisioningserver is missing several dependencies" [Undecided,New] | 17:10 |
| roaksoax | allenap: ack | 17:11 |
| roaksoax | thanks | 17:11 |
| === flacoste changed the topic of #maas to: Final Freeze is today: waiting on upstream fixes for bug 978127; packaging fixes: bugs 1064542 and 1064539| Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ | ||
| roaksoax | allenap: so other packages no longer depend in those then | 17:11 |
| allenap | roaksoax: They may do, so don't change other packages yet. I'll try to check their deps later. | 17:12 |
| roaksoax | alright thanks | 17:13 |
| smoser | roaksoax, more data for you. https://bugs.launchpad.net/maas/+bug/1064527 | 17:14 |
| ubot5 | Ubuntu bug 1064527 in MAAS "detect_ipmi needs improvement. detects non-existant device in nested kvm" [Undecided,New] | 17:14 |
| rvba | matsubara: I've documented the results of our findings on bug 1064020. | 17:16 |
| ubot5 | Launchpad bug 1064437 in MAAS "duplicate for #1064020 The expectations of MAASDispatcher.dispatch_query are not tested" [High,Triaged] https://launchpad.net/bugs/1064437 | 17:16 |
| matsubara | rvba, thanks | 17:17 |
| rvba | matsubara: but basically, it all boils down to 2 packaging bugs. | 17:17 |
| rvba | Bugs that roaksoax will be fixing soon ;) | 17:18 |
| roaksoax | smoser: err passing the json format is a PITA | 17:18 |
| roaksoax | smoser: i can't get to pass the full json string needed | 17:18 |
| smoser | show me what you're doing ? | 17:18 |
| smoser | it should'nt be bad. | 17:18 |
| roaksoax | smoser: this is maas-ipmi-autodetect which returns in json format: http://paste.ubuntu.com/1269631/ | 17:19 |
| roaksoax | smoser: this is maas-enlist = http://bazaar.launchpad.net/~andreserl/maas/test/revision/32 | 17:20 |
| roaksoax | smoser: which would require to pass --power-params '{"test": "test", "test2", "test2"}' | 17:21 |
| roaksoax | smoser: but every way I do it, maas-enlist doesn't get the whole json string it just get partial lilke {"test": "test", | 17:22 |
| matsubara | rvba, so, this has nothing to do with bug 1064020? | 17:25 |
| ubot5 | Launchpad bug 1064437 in MAAS "duplicate for #1064020 The expectations of MAASDispatcher.dispatch_query are not tested" [High,Triaged] https://launchpad.net/bugs/1064437 | 17:25 |
| smoser | roaksoax, what is calling maas-enlist ? | 17:26 |
| matsubara | rvba, because I dupe 1064020 against that one | 17:26 |
| matsubara | err | 17:26 |
| roaksoax | smoser: shell script | 17:26 |
| smoser | what is taking output of maas-ipmi-autodetect and feeding it to maas-enlist | 17:26 |
| smoser | where is that. that is your issue. | 17:26 |
| roaksoax | smoser: it should go on maas enlist metadata | 17:26 |
| matsubara | oh, wait | 17:26 |
| matsubara | I got confused by the bot | 17:26 |
| rvba | matsubara: no, nothing to do with that one. | 17:26 |
| matsubara | ok, I'll undupe and close 1064020 as invalid since it's reported on the package | 17:27 |
| matsubara | rvba, question for you, when I install maas-dns, shouldn't it ask for the config information to put in /etc/bind/named.conf.options? After every install in the QA lab I have to run this: https://pastebin.canonical.com/76145/ | 17:34 |
| smoser | roaksoax, what do you have there. thats where your sissue is. | 17:35 |
| rvba | matsubara: not really sure why you had to do that. What is the 'forwarders' stuff all about? | 17:37 |
| matsubara | rvba, that's the only way I got dns to work in the lab. I got that change from Julian. | 17:38 |
| rvba | matsubara: hum, I don't know about that. Could you please file a bug? Let's see what Julian has to say about that. | 17:39 |
| matsubara | rvba, will do | 17:39 |
| roaksoax | smoser: ubuntu@node2:~$ ./ipmi.sh | 17:48 |
| roaksoax | ^{"power_address": "192.168.2.111", "power_pass": "6o9TuzEvY9fQ", "power_user": "maas-commissioning"}$ | 17:48 |
| roaksoax | Failed to parse JSON power_paramete | 17:48 |
| roaksoax | smoser: http://paste.ubuntu.com/1269688/ | 17:48 |
| smoser | what does sudo ./maas-ipmi-autodetect --enlist output | 17:49 |
| smoser | sudo ./maas-ipmi-autodetect --enlist | 17:49 |
| roaksoax | smoser: prints the json string we need {"test": "test", "test":"test"} | 17:50 |
| smoser | that'd be fine | 17:50 |
| smoser | just quote "$var" then | 17:50 |
| smoser | ./maas-enlist --serverurl localhost --power-type ipmi --power-params "${var}" | 17:50 |
| roaksoax | smoser: ahhhh that;s was it "${var}" | 17:51 |
| roaksoax | thanks | 17:51 |
| roaksoax | lol :) | 17:51 |
| roaksoax | never ocurred to me | 17:51 |
| roaksoax | smoser: i'm including maas-signal in maas-commission binary package if that's ok with you | 18:02 |
| smoser | roaksoax, well we need a fix there. | 18:04 |
| smoser | still for this oauth bit | 18:04 |
| smoser | i'm ok with that, but i'm working on that now. | 18:05 |
| roaksoax | smoser: alright! | 18:05 |
| roaksoax | smoser: ideally i think this should probably end up in maas-utils package or similar | 18:05 |
| roaksoax | smoser: within the maas source | 18:05 |
| roaksoax | Daviey: ping | 18:06 |
| roaksoax | Daviey: is it too late for me to introduce this new binary package as part of maas-enlist source? | 18:06 |
| matsubara | smoser, I set the debconf database with my seed file but when I installed the package it overrode the value. Is there anything I need to do so apt-get uses the value I supply in the seed file? | 18:24 |
| matsubara | smoser, I installed the package with sudo apt-get install -y maas maas-dhcp maas-dns | 18:24 |
| matsubara | and my seed file has: maas-region-controller maas/default-maas-url string 192.168.21.5 | 18:24 |
| smoser | probably just that maas-cluster-controller is the package that prompts you | 18:25 |
| smoser | maas-cluster-controllermaas-cluster-controller/maas-urlstringhttp://localhost/MAAS | 18:26 |
| smoser | matsubara, ^ | 18:30 |
| matsubara | smoser, I normally run sudo dpkg-reconfigure maas-region-controller to change that | 18:31 |
| matsubara | so, maas-region-controller maas-region-controller/default-maas-url string 192.168.21.5 | 18:31 |
| smoser | well that seems wrong. | 18:31 |
| matsubara | ? | 18:31 |
| matsubara | it's what the package tells me to run after the package install :-) | 18:32 |
| smoser | well, whats above works for me. | 18:40 |
| smoser | what you're using doesn't work for you. | 18:40 |
| smoser | i'm not able to spend time on why at the moment. | 18:40 |
| smoser | but i'd suggest using what works for me/ | 18:40 |
| matsubara | ok | 18:42 |
| matsubara | sounds good to me. trying that. thanks! | 18:42 |
| smoser | rbasak, https://code.launchpad.net/~smoser/maas/trunk.maas-signal-clockskew/+merge/128794 | 19:01 |
| smoser | you can give that a sniff. i'm guessing it works. | 19:01 |
| smoser | it does not ever set the hardware clock though. | 19:01 |
| rbasak | smoser: looking | 19:01 |
| smoser | it works for me. output at http://paste.ubuntu.com/1269818/ | 19:02 |
| smoser | rbasak, it works for me, testing when i apply this patch | 19:03 |
| smoser | http://paste.ubuntu.com/1269821/ | 19:03 |
| smoser | which basically breaks the clock | 19:03 |
| rbasak | smoser: looks good. https://pastebin.canonical.com/76152/ has enlistment and then commissioning | 19:11 |
| rbasak | smoser: seeing multiple corrections but I presume that's juts multiple calls to maas-signal | 19:12 |
| rbasak | smoser: RTC doesn't change during commissioning. Trying the install step now to see if that fixes it, which I think it does. | 19:12 |
| smoser | rbasak, right. since it does not ever actually set the clock, each invocation of maas-signal has to re-discover bad clock. | 19:13 |
| smoser | rbasak, do you know where install gets its clock from? | 19:14 |
| rbasak | smoser: ntp I presume | 19:14 |
| smoser | ntp.ubuntu.com | 19:14 |
| smoser | ? | 19:14 |
| rbasak | I assume so | 19:14 |
| rbasak | I don't actually know | 19:14 |
| rbasak | smoser: looks like yes - it's preseeded | 19:16 |
| rbasak | smoser: /usr/share/maas/preseeds/preseed_master | 19:16 |
| roaksoax | smoser: if in misc_bucket i define: | 19:18 |
| roaksoax | - &maas_ipmi_detect | | 19:18 |
| roaksoax | - &maas_enlist | | 19:18 |
| roaksoax | etc etc | 19:18 |
| roaksoax | each is run as a script? | 19:18 |
| smoser | rbasak, ok. for now i think we just ship this. | 19:20 |
| smoser | but for later, i think we hav a "ntp" setting in maas. and feed that to ephemeral environment. | 19:21 |
| smoser | if it was set to something other than 'disabled' then set it based on that remote clock. | 19:21 |
| smoser | roaksoax, where are you seeing that/ | 19:25 |
| roaksoax | smoser: enlist_userdata, and i'm asking if that's the case | 19:26 |
| smoser | ah. contrib/preseeds_v2/enlist_userdata | 19:26 |
| smoser | right. | 19:26 |
| smoser | see | 19:26 |
| smoser | runcmd: | 19:26 |
| smoser | - [ sh, -c, *maas_enlist ] | 19:26 |
| smoser | that references the text in maas_enlist | 19:26 |
| smoser | so just add another entry in that list for maas_ipmi_detect | 19:26 |
| rbasak | smoser: tested and I've approved the MP | 19:28 |
| rbasak | smoser: thanks! | 19:28 |
| roaksoax | smoser: ok cool thanks | 19:30 |
| roaksoax | smoser: and that's what i was doing just watned to make sure :) | 19:30 |
| flacoste | roaksoax: upstream 1241 should be good to upload | 19:34 |
| flacoste | roaksoax: unless you want your changes in as well which mean we'd ship 1242 | 19:34 |
| flacoste | roaksoax: but we have 25 minutes before the freeze happens | 19:35 |
| roaksoax | flacoste: isn't it at 21 UTC? | 19:35 |
| flacoste | indeed! | 19:36 |
| flacoste | that's 60 more minutes! | 19:36 |
| roaksoax | flacoste: indeed :) | 19:36 |
| roaksoax | flacoste: i'm half way done | 19:36 |
| flacoste | triple the time! | 19:36 |
| roaksoax | so lets cross fingers :) | 19:36 |
| smoser | https://code.launchpad.net/~smoser/maas/trunk.maas-signal-clockskew/+merge/128794 | 19:36 |
| smoser | is ready, not piced up yet | 19:36 |
| === flacoste changed the topic of #maas to: Final Freeze is today: upstream RC revision: 1241; packaging fixes: bugs 1064542 and 1064539| Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ | ||
| flacoste | smoser: i received a merged message already | 19:36 |
| smoser | really? Approved by: Scott Moser 1 minute ago | 19:37 |
| flacoste | weird | 19:38 |
| flacoste | smoser: actually, it wasn't the oauth fix, but the console fix | 19:39 |
| flacoste | 1241 | 19:39 |
| flacoste | 1242 will contain the oauth fix | 19:39 |
| === flacoste changed the topic of #maas to: Final Freeze is today: upstream RC revision: 1242; packaging fixes: bugs 1064542 and 1064539| Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ | ||
| rbasak | smoser: I understand that it might work, but it's still hard to read as it isn't obviously correct! | 19:42 |
| smoser | it is obviously correct | 19:45 |
| smoser | as the demonstrating script shows. | 19:45 |
| smoser | it may not be obvious to you. | 19:45 |
| smoser | but it is to python | 19:45 |
| smoser | and in cases where the 2 differ, i agree with python. | 19:45 |
| smoser | why would: | 19:46 |
| smoser | except Exception as X | 19:46 |
| smoser | have any different scoping rules than | 19:46 |
| smoser | Y = X | 19:46 |
| smoser | that would be confusing. | 19:46 |
| flacoste | roaksoax: 1242 is in | 19:58 |
| roaksoax | flacoste: ok, i'm almost there with the enlistment | 19:58 |
| roaksoax | flacoste: if it doesn'y work withing the next 20 mins | 19:59 |
| roaksoax | i'll give up | 19:59 |
| roaksoax | and prepare an upload | 19:59 |
| flacoste | roaksoax: perfect, am i right in that you already fixed the two packaging bugs mentioned in the topic? | 19:59 |
| roaksoax | flacoste: yep i blieve they are fixed now | 20:00 |
| Daviey | roaksoax: it is not too late to do that, no | 20:01 |
| roaksoax | Daviey: the maas-nelist thing? | 20:02 |
| Daviey | roaksoax: can we do it soon tho :) | 20:02 |
| Daviey | roaksoax: not too late to introduce a new bin deb | 20:02 |
| roaksoax | Daviey: ok cool | 20:03 |
| Daviey | roaksoax: ETA? | 20:03 |
| ppetraki | so I get this backtrace when I add a node via mac address: http://paste.ubuntu.com/1269952/ | 20:04 |
| roaksoax | Daviey: i made a maas-enlist upload fixing a bug | 20:04 |
| roaksoax | Daviey: so you could reject that and Ill upload the other thing now | 20:04 |
| Daviey | ok | 20:05 |
| roaksoax | Daviey: iuploaded | 20:11 |
| Daviey | roaksoax: so here is the thing... i don't think i rejected it | 20:12 |
| Daviey | 20:45 -queuebot:#ubuntu-release- Unapproved: accepted maas-enlist [source] (quantal-release) [0.4+bzr32-0ubuntu1] | 20:12 |
| Daviey | someone else accepted it | 20:12 |
| roaksoax | Daviey: alright, I;ll just prepare a different changelog | 20:13 |
| roaksoax | Daviey: could you please reject maas-enlist-0.4+bzr35 | 20:15 |
| roaksoax | Daviey: i'll upload a new one | 20:15 |
| Daviey | rejected | 20:16 |
| flacoste | smoser: is bug 1006966 still relevant?% | 20:16 |
| ubot5 | Launchpad bug 1006966 in cloud-init (Ubuntu) "maas mirror values are overwritten by cloud-init" [High,Triaged] https://launchpad.net/bugs/1006966 | 20:16 |
| roaksoax | Daviey: ok uploaded a new one | 20:16 |
| flacoste | ppetraki: everybody is heads down trying to hit feature freeze | 20:17 |
| flacoste | ppetraki: and that's with the MAAS version still using cobbler | 20:17 |
| Daviey | in a relaxed and orderly manner, due to our smooth planning and quality control | 20:18 |
| flacoste | ppetraki: and that's with the MAAS version still using cobbler | 20:18 |
| smoser | flacoste, its fixed. i'll update with comment how. | 20:18 |
| ppetraki | flacoste, I had duplicate cobbler entries, once I deleted them, it added correctly | 20:18 |
| flacoste | Daviey: :-) | 20:18 |
| ppetraki | flacoste, thanks | 20:18 |
| flacoste | smoser: similary, is bug 1028501 fixed? | 20:22 |
| ubot5 | Launchpad bug 1028501 in cloud-init (Ubuntu Precise) "cloud-init selects wrong mirrors for arm" [High,Triaged] https://launchpad.net/bugs/1028501 | 20:22 |
| roaksoax | smoser: http://paste.ubuntu.com/1269987/ | 20:25 |
| smoser | flacoste, i put comments in them. you put the maas in the right state. | 20:26 |
| roaksoax | flacoste: ok so I think the enlist stuff is finished... however, we still need publishing of the newer maas-enlist recently uploaded for it to work | 20:26 |
| flacoste | roaksoax: is that a problem? would it prevent a new upload? | 20:27 |
| roaksoax | flacoste: so, it could get merged, and later we file a bug saying "autodetection on enlistment is not enabled" | 20:27 |
| flacoste | and upload as part of the 0-day updates next week? | 20:28 |
| Daviey | 0-day if essential, right? | 20:29 |
| Daviey | we are not currently planning a 0-day, right? :) | 20:29 |
| flacoste | we are not | 20:29 |
| flacoste | just would be nice to send a couple bug fixes more to users :-) | 20:29 |
| flacoste | and autodetection only working during commissioning is not that interesting | 20:30 |
| flacoste | roaksoax: can you merge it and make it part of the upload, or will it be rejected because maas-enlist hasn't been published yet | 20:36 |
| roaksoax | flacoste: no it wont | 20:36 |
| flacoste | roaksoax: if it can be accepted, but really will only work once maas-enlist is published, i think it'd be fine | 20:36 |
| roaksoax | flacoste: ok, i'm running one more test | 20:37 |
| smoser | roaksoax, so we're copying that whole commissining script basically? | 20:39 |
| smoser | that sucks. :-( | 20:39 |
| smoser | (i dont have a better way, but it sucks) | 20:39 |
| roaksoax | smoser: yes, and no | 20:39 |
| roaksoax | smoser: Daviey just accepted maas-enlist | 20:39 |
| smoser | fyi, http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image | 20:39 |
| roaksoax | smoser: with the new binary package | 20:39 |
| roaksoax | smoser: but to be safe i'm copying it | 20:40 |
| smoser | that takes care of your "remove this section" | 20:40 |
| roaksoax | smoser: ok so we should be able to drop it as SRU | 20:40 |
| roaksoax | smoser: is that ok with you? | 20:40 |
| roaksoax | smoser: we temporarily merge all the copying of the script, and then we drop it, once the package hits the archive and I can test it works | 20:41 |
| flacoste | smoser: how is bug 1044503 different than bug 1045390 ? | 20:41 |
| ubot5 | Launchpad bug 1044503 in MAAS "kernel command line is not easily customizable" [High,Triaged] https://launchpad.net/bugs/1044503 | 20:41 |
| ubot5 | Launchpad bug 1045390 in MAAS "There's no way to add kernel parameters to a system read" [High,Triaged] https://launchpad.net/bugs/1045390 | 20:41 |
| smoser | flacoste, probably not. roaksoax ^ you have thoughts ? | 20:42 |
| flacoste | roaksoax: that question can wait until the upload is done :-) | 20:43 |
| smoser | roaksoax, i think your plan is fine. | 20:43 |
| smoser | just make sure you get the latest version of maas-signal | 20:43 |
| roaksoax | smoser: i did | 20:45 |
| roaksoax | ok this is almost here | 20:46 |
| flacoste | smoser: is bug 1053190 fixed? | 20:46 |
| ubot5 | Launchpad bug 1053190 in MAAS "multiple NICs could cause cloud-init nonet timeout" [High,Triaged] https://launchpad.net/bugs/1053190 | 20:46 |
| smoser | k. i'm going afk for a few hours. | 20:46 |
| roaksoax | smoser: i get this | 20:46 |
| roaksoax | }sh: 191: --power-params: not found | 20:46 |
| roaksoax | smoser: https://pastebin.canonical.com/76160/ | 20:46 |
| Daviey | matsubara: Hey, what is your QA plan from now? | 20:47 |
| matsubara | Daviey, currently I'm working on deploying with juju in the QA lab (which has 7 nodes arm and amd64) | 20:47 |
| roaksoax | smoser: any idea? | 20:48 |
| smoser | whitespace after \ | 20:50 |
| roaksoax | ok cool | 20:51 |
| roaksoax | smoser: https://code.launchpad.net/~andreserl/maas/enlistment_ipmi_autodiscovery/+merge/128819 | 20:54 |
| roaksoax | flacoste: https://code.launchpad.net/~andreserl/maas/enlistment_ipmi_autodiscovery/+merge/128819 | 20:54 |
| roaksoax | please review | 20:54 |
| flacoste | smoser: does bug 1034116 still need changes in MAAS? | 20:55 |
| ubot5 | Error: Launchpad bug 1034116 could not be found | 20:55 |
| flacoste | roaksoax: line 17: it should be commented out :-) | 20:56 |
| Daviey | matsubara: cool. Do you have plans to try a cd image? | 20:57 |
| roaksoax | flacoste: done | 20:57 |
| matsubara | Daviey, nope | 20:59 |
| roaksoax | flacoste: crap something failed in another test I just run | 21:00 |
| flacoste | roaksoax: why the all-caps variable name at line 147? | 21:00 |
| roaksoax | flacoste: "globals" | 21:01 |
| flacoste | roaksoax: but they aren't globals? | 21:01 |
| roaksoax | flacoste: I know :) I didn't have the time to update that | 21:01 |
| roaksoax | flacoste: that's why the quotes :) | 21:02 |
| flacoste | roaksoax: looks ok to me, but i'm not a shell expert | 21:03 |
| roaksoax | smoser: could you please? | 21:03 |
| roaksoax | smoser: https://code.launchpad.net/~andreserl/maas/enlistment_ipmi_autodiscovery/+merge/128819 | 21:03 |
| * roaksoax waiting for it to land | 21:07 | |
| roaksoax | to package it up | 21:07 |
| roaksoax | flacoste: so maas-lander is taking forever to land the branch | 21:19 |
| roaksoax | that's the only thing i'm waiting on to get the package read | 21:19 |
| roaksoax | Daviey: just uploaded MAAS could you please take care of it? | 21:27 |
| Daviey | yes | 21:28 |
| roaksoax | Daviey: thank you!! | 21:29 |
| flacoste | thanks roaksoax, Daviey and smoser! | 21:33 |
| * roaksoax can now rest in peace :) | 21:37 | |
| roaksoax | smoser the bug you came across in nested kvm... is this canonistack? | 22:59 |
| Daviey | roaksoax: it is | 23:00 |
| Daviey | roaksoax: As IS use ksplice to patch the running kernel... i think smoser wasn't confident it was a regression on it's own | 23:01 |
| Daviey | Maybe I miss understood | 23:01 |
| roaksoax | so that means that it could have been related to the fact that that particular hardware does have ipmi hence the instances detect it? | 23:01 |
| Daviey | roaksoax: No, i don't think that is passed through. | 23:02 |
| Daviey | It's only the cpu | 23:02 |
| Daviey | If that IS passed through, it's a massive security concern | 23:02 |
| roaksoax | indeed | 23:02 |
| roaksoax | i will look into it | 23:02 |
| Daviey | roaksoax: you see, https://launchpadlibrarian.net/96102740/qemu_1.0%2Bnoroms-0ubuntu7.debdiff .. It only exposes the VMX feature, as an addition | 23:03 |
| roaksoax | righ | 23:04 |
| Daviey | and on that note.. nn | 23:05 |
| roaksoax | Daviey: night!! | 23:05 |
| === matsubara is now known as matsubara-afk | ||
| smoser | roaksoax, no. | 23:15 |
| smoser | the issue is not t hat there actually is ipmi in play | 23:15 |
| smoser | its just the way ipmi-detect works | 23:15 |
| smoser | it looks like it randomly walks through memory | 23:15 |
| smoser | and i think is getting false positives. | 23:15 |
| smoser | it opens /dev/mem and looks for stuff. | 23:16 |
| roaksoax | smoser: right | 23:16 |
| smoser | i'm surprised that it was so bad, and i could have just been being unlucky. | 23:16 |
| smoser | as other times it did return nothing | 23:17 |
| roaksoax | heh right | 23:17 |
| smoser | i wondered if we could just limit it to the /dev/ipmi* and /dev/bmc* | 23:17 |
| smoser | and disable its searches for /dev/mem | 23:17 |
| smoser | great work on bug 1032004, roaksoax | 23:18 |
| ubot5 | Launchpad bug 1032004 in Indicator Remindor "Indicator-remindor don't start on Ubuntu 12.04" [Critical,Fix released] https://launchpad.net/bugs/1032004 | 23:18 |
| smoser | err... 1042004 | 23:18 |
| smoser | bug 1042004 | 23:18 |
| ubot5 | Launchpad bug 1042004 in MAAS "Enlistment does not do BMC discovery" [Critical,Fix released] https://launchpad.net/bugs/1042004 | 23:18 |
| roaksoax | thanks... it was pretty straightforward though :) | 23:18 |
| roaksoax | smoser: ok, I got it | 23:23 |
| roaksoax | smoser: sudo bmc-config --disable-auto-probe --checkout | 23:23 |
| smoser | ? | 23:23 |
| smoser | but is that somethign thats going to mean we do not support "in band" cards? | 23:23 |
| smoser | maybe we should make that a default and allow it to be configed overridden. | 23:24 |
| smoser | anyway. | 23:24 |
| smoser | again, good job. i'm on my way out. probably check back in. | 23:24 |
| roaksoax | smoser: i'm assuming that if it works, it means we have local access to the IPMI card right? | 23:24 |
| smoser | i dont know what it means really. | 23:24 |
| roaksoax | smoser: that it doesn't probe for several IPMI interfaces | 23:25 |
| smoser | if it means "don't crawl through /dev/mem", that sounds good at first. | 23:25 |
| smoser | but if 75% of the existing cards would be found that way, that does *not* sound good. | 23:25 |
| smoser | i really dont have enough information to make even a guess | 23:25 |
| smoser | later. | 23:26 |
| roaksoax | later | 23:26 |
| bigjools | hi guys | 23:35 |
| roaksoax | bigjools: good morning sir | 23:37 |
| bigjools | roaksoax: hey there! how are we doing? | 23:38 |
| roaksoax | bigjools: good, maas is in archives | 23:40 |
| bigjools | good news! | 23:40 |
| roaksoax | indeed | 23:41 |
| bigjools | roaksoax: I see enistment is poking things in the BMC now ... | 23:41 |
| bigjools | enlistment* | 23:41 |
| roaksoax | bigjools: it is indeed :) | 23:41 |
| bigjools | roaksoax: not sure it's a great idea to be changing parameters on enlistment :/ | 23:41 |
| roaksoax | sudo apt-get dist-upgrade | 23:41 |
| roaksoax | err | 23:42 |
| roaksoax | bigjools: you mean power parameters? | 23:42 |
| bigjools | yeah | 23:42 |
| bigjools | err no | 23:42 |
| bigjools | I mean, setting user/pass on the bmcx | 23:42 |
| roaksoax | bigjools: oh it is just a temporary one | 23:42 |
| bigjools | or does it add a new one? | 23:42 |
| roaksoax | bigjools: commissioning overrides it | 23:42 |
| bigjools | does the old one still work or does it blow that away? | 23:42 |
| bigjools | at enlistment I mean | 23:43 |
| roaksoax | bigjools: blown away | 23:43 |
| bigjools | :( | 23:43 |
| roaksoax | bigjools: so ipmi basically manages user as User3, User4, etc etc | 23:43 |
| bigjools | this means accidental pxe boots destroy BMC creds | 23:43 |
| roaksoax | bigjools: well during enlistment we create maas-commissioning, which is then replaced by 'maas' during commissioning | 23:44 |
| roaksoax | bigjools: but that's only for User3 | 23:44 |
| bigjools | roaksoax: did you see my bug about the 0.0.0.0 address? | 23:44 |
| roaksoax | bigjools: nope, bug #? | 23:45 |
| bigjools | https://bugs.launchpad.net/maas/+bug/1064224 | 23:46 |
| ubot5 | Ubuntu bug 1064224 in MAAS "IPMI detection ends up with power_address of 0.0.0.0" [Critical,Incomplete] | 23:46 |
| * bigjools brb | 23:47 | |
| roaksoax | bigjools: uhmm was it originally set to Static? if so, and the script changed it to DHCP then it might be due to it didn't wait enough time | 23:48 |
| roaksoax | otherwise, it seems to not be getting an IP address of time | 23:49 |
| bigjools | roaksoax: no it was always DHCP - it recently stopped getting an address | 23:54 |
| bigjools | and now I can't access it at all of course | 23:54 |
| bigjools | the dhcp server does a DHCPOFFER and the BMC just keeps doing DHCPDISCOVER | 23:54 |
| roaksoax | bigjools: are these the MicroServer robbie had? | 23:54 |
| bigjools | yeah | 23:55 |
| bigjools | was working fine last week :/ | 23:55 |
| roaksoax | bigjools did you delete the admin/password? | 23:55 |
| roaksoax | the user admin with password password? | 23:55 |
| bigjools | the commissioning code may have, I don't know | 23:55 |
| roaksoax | bigjools: nope, it doesn't | 23:55 |
| bigjools | well that's good :) | 23:55 |
| roaksoax | the commissioning code uses User3 while the MicroServer were configured on User2 i think | 23:56 |
| bigjools | roaksoax: how does this help me make it get an IP? :) | 23:57 |
| roaksoax | bigjools: you might wanna try doing this: sudo bmc-config --commit --key-pair "Lan_Conf:IP_Address_Source=Static" | 23:57 |
| roaksoax | and then | 23:58 |
| roaksoax | sudo bmc-config --commit --key-pair "Lan_Conf:IP_Address_Source=Use_DHCP" | 23:58 |
| roaksoax | that should reset the card and should try to DHCP again | 23:58 |
| roaksoax | bigjools: if the card is already DHCP the cscript wont mess with it | 23:58 |
| bigjools | okay, let me try | 23:58 |
| bigjools | it is dhcp for sure, I can see it discovering | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!