[02:37] roaksoax: https://code.launchpad.net/~julian-edwards/maas/missing-import-bug-1065055/+merge/129080 [02:39] bigjools: can't approave it [02:39] bigjools: it will conflict with maas-region-controller [02:41] bigjools: i guess it will have to end up being shipping in maas-common and will have to add conflicts/replaces [02:42] s/shipping/shipped [02:52] ./win 8 [04:12] roaksoax: grar [04:17] roaksoax: fixed, take a look if you are still there? [07:57] roaksoax, smoser: sorry had to go [08:16] allenap: maas-cli is certainly less than user friendly [08:17] http://pb.daviey.com/QdsM/ [08:19] Daviey: you want "maas-cli login" to act as "maas-cli login -h" ? [08:20] jtv: i'd say so... I worked it out tho [08:21] jtv: mind you, http://pb.daviey.com/jIU4/ [08:21] still not that clear WTF i am supposed to do. [08:21] Daviey: well what you have there shows the API commands you can issue directly. [08:22] Try "maas-cli maas node-group -h", for instance. [08:23] jtv: right, but do you see how it feels like i'm using a dev tool like ipython? [08:23] Absolutely. It's tough to get going with. [08:25] jtv: so, deleting a node [08:26] jtv: so, deleting a node [08:26] I need to find the node first.. how? [08:26] davewalker@maas:~$ maas-cli maas node-group list-nodes uuid [08:26] Not Found [08:27] What's the uuid for? [08:28] http://pb.daviey.com/cqtV/ [08:28] ah [08:29] maas-cli maas node delete $system-id [08:29] maas-cli maas nodes list | grep system_id [08:31] Looks like we have some underdocumented methods in the API. :( [08:53] jam: I was wrong, the memory was reported ok on my microservers. [08:58] jam: in reply to your xpath comments, [08:59] you're right, it's much more painful until postgres 9.2 because of the must-return-nodeset limitation [08:59] mgz: care to mumble? [08:59] be a little careful comparing things to nodesets though [08:59] occasionally the result is suprising [09:39] Daviey: I've been thinking about that. maas-cli is a thin wrapper around the API, but there's an impedance mismatch there. [09:39] allenap: there doesn't need to be, does there? [09:39] Cousin Cletus (aka the shell) just can't deal with the richness of the API. [09:40] allenap: bash tab-complete? NEVER mentioning: usage: /usr/lib/python2.7/dist-packages/maascli/__main__.py maas [09:40] [-h] COMMAND ... [09:40] defaulting to providing -h if params are missing? [09:40] Daviey: Perhaps for 13.04 we need to come up a more task-orientated command-line tool, and leave the API tinkering in a library. [09:41] Daviey: Yeah, those are things we ought to have, but they're polish. [09:41] I think there's a fundamental problem with trying to manipulate highly structured data from the shell. [09:41] jtv: could you please review: https://code.launchpad.net/~rvb/maas/bug-1065406/+merge/1291 [09:41] allenap: polish or DESIGN? :) [09:43] Daviey: Polish. We want to do tab completion. Changing the error behaviour is something that has come out in practice. [09:43] The need to change it I mean. [09:44] Also, I mean: we have always wanted to do tab completion. [09:44] It's not a new thing. [09:44] right [09:44] Is longpoll still busted? [09:44] not seeing the dash dynamically update? [09:45] This should have been fixed by now. [09:46] Daviey: Frankly I think shell is the wrong place to do anything other than start something else. What can you do when you ask for a listing of allocated nodes? bash can't grok that structure; we immediately need to go out to awk or something, which leads to scripts that are held together by dog lick. [09:47] allenap: which is exactly what i have done.. [09:47] Yeah :-( [09:47] Daviey: fixed in r127 of the packaging branch. [09:47] but actually, as a application driven api.. it could be worse. [09:47] rvba: I wonder if it's because i am using SOCKS [09:48] Should be ok. Apache is acting a proxy to the longpoll server. [09:49] Daviey: could you try to access the longpoll url? (if you get a Django 404 there is a problem because Django should not be serving that url) [09:49] Django bug 404 in Metasystem "MySQL order_by=['?'] throws ProgrammingError" [Normal,Closed] http://code.djangoproject.com/ticket/404 [09:50] haha :) [09:50] rvba: linky for the lazy [09:50] ? [09:51] longpoll url [09:51] Just one sec. [09:57] Daviey: http://localhost:8080/MAAS/longpoll/?uuid=blah [09:57] ta [09:57] You should get "Invalid request" (because the uuid is bogus) and not a reply from Django. [09:58] rvba: 404, The requested URL /MAAS/longpoll/ was not found on this server. [09:58] http://192.168.9.1/MAAS/longpoll/?uuid .. right? [09:58] Daviey: looks like the fix from r127 is not there. [09:58] Yes. [09:58] Daviey: sudo a2enmod proxy_http && sudo service apache2 restart [09:59] Installed: 0.1+bzr1243+dfsg-0+1252+129~ppa0~quantal1 [09:59] Now i get, "Async frontend for None" [10:00] Daviey: can you try loading proxy_http? [10:00] rvba: your line worked, no? [10:00] Yeah, but that is exactly what the fix in r127 should have done. [10:01] http://pb.daviey.com/pVKb/ [10:02] Daviey: right, so proxy_http was not enabled. [10:03] Daviey: can you please double check wit: cat /var/lib/dpkg/info/maas-region-controller.postinst | grep proxy_html [10:03] (yes, I know, the cat/grep combination is a bit stupid) [10:04] rvba: I think it's covered here, http://partmaps.org/era/unix/award.html [10:05] heh [10:05] confirmed, not in there [10:05] WTF [10:06] the good news is IPMI discovery is working REALLLLLLY well. [10:06] \o/ [10:07] Daviey: I don't understand, "a2enmod proxy_http" is in debian/maas-region-controller.postinst revision 129. [10:08] No idea :/ [10:11] Maybe roaksoax will have an idea. Smells fishy to me. Packaging fishy. [10:16] stinks! [10:21] rvba: not finding that review you linked to [10:22] jtv: https://code.launchpad.net/~rvb/maas/bug-1065406/+merge/129131 [10:22] That works. [10:26] STOP EATING MY SHOES! [10:27] They make sneakers much too light nowadays. Cats can drag them out of the shoe rack. [10:28] Just tried highbank on quantal and ipmi setting has completely disappeared. Nothing on enlistment and nothing on commissioning. Is this expected? [10:29] http://paste.ubuntu.com/1272933/ [10:30] smoser, Daviey: ^^ [10:33] jtv: clearly you need to walk around the house in clogs only, cats would struggle to make an impression on those [10:33] Good idea. [10:33] Thing is, where do I put my sneakers in the mean time? You don't wear shoes in the house here. [10:33] I'm inside, the cats are outside. [10:33] Eating my sneakers. [10:34] They're new, too. The old ones were at least a year beyond their best-by date, and as soon as I get myself a new pair, I have to visit a house that has cats prowling around. [10:34] Looking for shoes to pounce on. [10:37] maybe you could buy a very tall shoe tree. like a hat stand, but to hang shoes off [10:37] then the cats would at least have to climb for their prize [10:38] You haven't seen what these cats do. [10:39] I've seen them walk up bug screens like Spider-man. [10:39] ehehe [10:39] Walk, I tell you. Two meters up, then jump up on the curtain rails. [10:43] rvba: the regular celeryconfig does not have the import_settings problem, just the cluster celeryconfig? [10:44] jtv: right: debian/maas-region-controller.maas-region-celery.upstart contains env PYTHONPATH="/usr/share/maas/" so the region celery process has access to the utility method. [10:45] Oh, that's used only from the upstart job [11:03] jelmer: how's memory stuff going? [11:08] jam: I was about to get lunch; I'm close to being able to push a branch up, was working on tests. [11:08] jelmer: enjoy your lunch, just checking in to see how it was going. [11:10] allenap: 'timeit' disagrees with you. indent=4 was only slightly slower, enforce_ascii was a huge hit. [11:11] allenap: I think generally having pretty printing of json isn't too bad, as most api results are small and with cli get dumped straight onto the console [11:11] 10ms for dumps, 12ms for dumps with indent=4 [11:11] it would be easy enough to reformat client side, but just setting a few internal calls to bypass prettiness seems okay [11:12] ensure_ascii=False => 114ms. [11:17] roaksoax: I've unlinked the upstream project from bug 1065080. I've talked to Julian about it and after some discussion, we think it would be more clean to have it fixed in the packaging (see my comment on the bug). [11:17] Launchpad bug 1065080 in maas (Ubuntu Quantal) "The BROKER_URL sent to a cluster controller has its hostname set 'localhost'." [Medium,Triaged] https://launchpad.net/bugs/1065080 [11:31] jtv: yeah, the cats in our yard jump from the ground about 2 meters up to get up on the wall. I think they push off the wall a bit on the way up, but it is pretty impressive. [11:32] mgz, allenap: I think the ensure_ascii difference is because with it set to True (default) you get back an 8-bit str that escapse all the non-ascii bytes. Vs getting back a Unicode string. [11:32] Love 'em. [11:33] The only thing I can think of, is that simplejson internally ends up using a unicode string, and appends chars to it (or some other silly thing), vs using a proper buffer. [11:35] allenap: I think I found it. "encode_basestring_ascii" has a C level accellerator, but 'encode_basestring' does not. [11:38] So in this case, we have 1 24kb string, so it doesn't matter as much if the *encoder* object is C, it matters more if the function called to encode that string is in C. [11:44] rbasak: maybe you can land lp:~racb/maas/comissioning… Looks very low-risk to me ;) [11:51] rvba: thanks. Had forgotten about that! [12:00] Hmm [12:00] If you destroy-enviroment and juju boostrap, is it expected that it loses it's DDNS? [12:24] ...how do I see an oops so I know what I broke? [12:24] the traceback doesn't seem to get logged... [12:25] ..disregard that, looking in the wrong dir [12:31] rbasak, you still busted on that ? [12:31] smoser: yes [12:32] smoser: precise ephemeral works. Quantal does not. [12:32] hmm.. i thought that was fixed last night? [12:32] I installed from quantal this morning [12:32] this is commissioning? [12:33] yes [12:33] maas 0.1+bzr1243+dfsg-0ubuntu3 [12:33] rbasak, can i see? [12:34] smoser: sure. Same machine as last time. [12:34] smoser: which bits do you need? [12:36] seems like bzr importer failed on maas-enlist [12:36] suck [12:42] smoser: I'm using released quantal. [12:42] smoser: just realised [12:42] smoser: do I need daily quantal? [12:42] Or shouldn't it matter? I don't see why it would [12:43] rbasak, at that point you're pulling from the archive. [12:43] the ephemeral fixes have primarily landed in the earlier sstages of boot and cloud-init [12:43] but you're getting past that. [12:46] amusing but non-fatal: http://pastebin.ubuntu.com/1273139/ [12:49] wip, needs tests: lp:~gz/maas/paginate_nodes_page_1064672/ [12:53] rvba: is there a good place to look up documentation about how to set up maas with a bunch of clusters? [12:53] I'm going to be doing some stress testing of the hardware constraints stuff, trying to set up a very large system (100,000 nodes). [12:53] And I figure I need a DB server, N_small appservers, N_large (~25) cluster workers. [12:54] jam: I don't think there is documentation for that but that's precisely what I'm testing atm. [12:54] I'm not doing stress testing, just setting up a cluster controller on a separate machine. [12:54] rvba: hints/docs/notes/access or whatever would be appreciated. [12:55] jam: we need the fix that jtv is currently landing. [12:55] Which one? [12:55] jtv: import_* [12:55] Because one has already landed [12:55] I believe [12:55] Ah [12:55] That's waiting for the cron job. [12:55] The fix for bug 1065055. [12:55] Launchpad bug 1065055 in MAAS "celeryconfig_cluster.py imports utility method from maas (import_settings)" [Critical,In progress] https://launchpad.net/bugs/1065055 [12:56] smoser: I've filed bug 1065499 [12:56] Launchpad bug 1065499 in MAAS "Power parameters fail to get set when using Quantal ephemerals" [Undecided,New] https://launchpad.net/bugs/1065499 [12:56] jam: I'll build a package in my ppa once this will be landed. [12:56] Then you only need to do 2 things: [12:57] Manually change the BROKER_URL setting on the region cluster celery config (s/localhost/ip.address/). [12:57] When you install a cluster, dpgk-reconfigure maas-cluster-controller => give the URL of the region [12:58] jam: that should be all. [12:58] rvba: so the 'region' is the master? [13:01] jam: not sure what you mean by that. There is a 'master' cluster controller installed with the region yes. [13:02] so region to me sounds like a subgroup of something larger. [13:02] but I don't think a region talks to anything else [13:02] so it seems to be the largest unit. [13:03] The region controller is the MAAS server. [13:03] All the cluster controllers talk to the region controller. [13:03] right. [13:04] but if you had 'multiple regions' they wouldn't talk to eachother. correct? [13:04] No, not right now. [13:05] k [13:06] rvba: so I saw in the design that you're supposed to be able to have multiple 'appserver' processes (I'm guessing that is the 'maas' process). Is that something that has been tested? [13:06] jam: no, this has not been tested. The goal was to use juju to scale horizontally like that. [13:07] rvba: so theoretically you could use juju to configure maas appservers as well as cluster controllers? [13:07] jam, rvba: the import branch just landed. Are you going to test it? [13:07] theoretically yes [13:07] jtv: I'll see if I can build a package. [13:08] Great. Basically all we need to know is that installing a cluster without a region controller on the same machine doesn't break, right? [13:08] yes [13:09] Hunk #1 FAILED at 182. [13:09] 1 out of 1 hunk FAILED -- rejects in file contrib/preseeds_v2/enlist_userdata [13:09] Patch 04-fix-ipmi-enlistment.patch does not apply (enforce with -f) [13:09] arg [13:09] Looks like that change has made it upstrea. [13:09] upstream* [13:14] jtv: jam any idea how to fix this, I've removed the patch, removed the reference to it in debian/patches/series but now I'm getting: "No such file or directory: ..04-fix-ipmi-enlistment.patch". I've no idea where it's referenced. [13:14] It's only mentioned in the changelog file. [13:14] rvba: in the patch queue? [13:14] (.pc) [13:15] jam: where is that? find . -name "*.pc" => nothing [13:15] rvba: it would be in the root directory, named '.pc/' [13:16] Leftovers in the build directory maybe? [13:16] quilt was the name I was looking for. [13:16] but rvba, jelmer is someone who knows deb packaging quite well. [13:17] jam: the root directory of the packaging branch? [13:17] rvba: yes [13:17] rvba: are you using bzr builddeb? [13:17] bzr bd -S -- -kemail [13:17] rvba: you might have to run "bzr rm" (no arguments) [13:18] otherwise bzr doesn't pick up that that file is removed, and bzr-builddeb will try to look for it while exporting the source tree [13:18] Thanks jelmer, that did the trick indeed. [13:19] Uploading to ppa. [13:22] jam: the ppa package will be ready soon (ppa:rvb/maas) all the packages are in http://people.canonical.com/~rvb/maas/. [13:43] ho hum hum. [13:44] rvba: note that you can avoid the -k bit by putting something like this in ~/.devscripts: [13:44] DEBSIGN_KEYID=1EEF5276 [13:45] jelmer: I didn't know that, thanks for the tip. [14:06] jtv: your fix to the celeryconfig_cluster worked fine. [14:06] Load off my mind, thanks [14:09] So it txlongpoll is fine too. [14:09] Daviey: ^ [14:10] super [14:16] jtv: the dhcp_key generation thingy fixed the dhcp restart problem. [14:22] rvba: ack [14:24] roaksoax: the fixes for bugs 1065055 and 1065406 as in as of r1261. I had to remove debian/patches/04-fix-ipmi-enlistment.patch to build the package (looks like the fixes in that patch are now upstream). [14:24] Launchpad bug 1065055 in MAAS "celeryconfig_cluster.py imports utility method from maas (import_settings)" [Critical,Fix committed] https://launchpad.net/bugs/1065055 [14:25] Launchpad bug 1065406 in MAAS "Nodegroup object is created with an empty dhcp_key." [Critical,Fix committed] https://launchpad.net/bugs/1065406 [14:25] rvba: yep [14:25] rvba: i'm aware :) [14:25] All right :) [14:26] rvba: btw... maas-dns is only meant to be installed in the region? [14:26] roaksoax: yes [14:26] rvba: so that means that maas-dhcp too [14:26] No, the dhcp can be installed on the cluster side too. [14:31] rvba: ok cool [14:31] thanks [14:35] rvba: so maas-dns should not depend on maas-dhcp [14:35] should it? [14:37] roaksoax: no, I don't think it's required. [14:38] roaksoax: but I'm not sure we've tested that very well, maybe you can keep it for now. [14:39] roaksoax: the maas-dhcp package can be installed next to any cluster controller. And there is one next to the region (it's a dependency). [14:41] smoser: your branch https://code.launchpad.net/~smoser/maas/ipmi-locate-fallback/+merge/129202 also fixes bug #1064527 [14:41] Launchpad bug 1064527 in MAAS "detect_ipmi needs improvement. detects non-existant device in nested kvm" [High,Triaged] https://launchpad.net/bugs/1064527 [14:41] right? [14:41] rvba: ok [14:42] no. [14:42] it doesn't [14:42] the issue in the nested kvm was it just took forever [14:42] as it got a false positive and then bmc-config.... [14:42] rvba: cause the maas-dns package does maas set_up_dns on postinst, but IDK whether we want that [14:42] and that was haning [14:42] this increases that chance actually [14:43] smoser: right but your branch is a fallback method for IPMI detection, so in nested KVM it won't detect ipmi, would it? [14:43] roaksoax: yes, we want that, if you install maas-dns, you want maas to register its config in the running bind instance and that is what set_up_dns does. [14:43] rvba: ok cool [14:46] roaksoax, mine only increases the likelyhood of finding something [14:46] (but is very unlikely to false-positive) [14:47] smoser: ok [14:47] smoser: btw.. maas-enlist is in archives now so it should work [14:54] right. [14:54] we need to get the sru back [14:55] smoser: i already uploaded it [14:55] rbasak: could you please verify SRU bug #1056816 [14:55] Launchpad bug 1056816 in maas-enlist (Ubuntu Precise) "maas-enlist does not post subarch" [Undecided,Fix committed] https://launchpad.net/bugs/1056816 [14:56] roaksoax, we need this bug fix in maas-enlist though. with the mac addrs. [14:56] we dont have that yet [14:56] do we? [14:56] smoser: for precise? [14:56] smoser: any tips on testing from precise-proposed? Shall I just add all of it in sources.list? Or is there any pinning functionality I should be using? [14:56] smoser: it is uploaded to -proposed but needs to be accepted first [14:57] smoser: so I think the previous upload we can mark verification-done and then the new one will address the third bug [14:57] rbasak: yes just add -proposed and install and test [14:57] roaksoax, just ask that the -proposed be rejected [14:57] i think [14:57] and upload a new one [14:57] smoser: i asked that [14:58] smoser: they said it won't [14:58] smoser: ScottK told me to make a new upload with higher revision with everything of the previous, plus the new stuff [14:58] smoser: so I did [14:59] smoser: but SpamapS told me to make a new upload with a new revision that adds, or removes anything from the previous upload [15:01] ok. thats fine. [15:02] roaksoax, so you uploaded? [15:02] smoser: ye [15:02] i will then copy that version to maas-ephemeral images ppa [15:02] smoser: yes [15:02] and we'llget new precise dailies [15:03] cool [15:04] roaksoax: what scottk said, and what I said, is basically the same thing, isn't it? [15:05] roaksoax: I see 2 uploads. Which one should be reviewed? [15:06] SpamapS: The way I understood it is: 1. Make an upload which contains the previous fixes (in -proposed) + the new fix and increase the revision (ScottK). 2. (yours) Make a new upload with only the *new* patch because the other 2 are already in -proposed [15:09] SpamapS: so I guess 2. is the correct approach, right? So please accept the latest one uploaded, and reject the older one :) Thank you [15:10] roaksoax: use understanding #1. ScottK definitely put it more clearly than I did. [15:11] SpamapS: yeah so the latest upload is the correct one [15:11] roaksoax: lets back up. What you need to do is take the current -proposed package, modify it with a new revision, and upload that. [15:12] SpamapS: so the latest upload I've made has both ubuntu1.2 + ubuntu1.3 [15:12] roaksoax: latest one does indeed look correct [15:12] http://launchpadlibrarian.net/119496240/maas-enlist_0.4-0ubuntu1.2_0.4-0ubuntu1.3.diff.gz [15:12] SpamapS: yes, that one :). Thanks for taking care of it :) [15:13] So do I still need to verify current precise-proposed or wait for the new one? [15:13] rbasak: you can verify what's with current [15:13] roaksoax: ? [15:14] rbasak: verify with what's in -proposed [15:14] and build debdiff versus last accepted. [15:14] rbasak: you don'yt need to wait [15:14] ok [15:14] I'm accepting but.. [15:14] ++ args="${args} --data-urlencode mac_addresses=${i}" [15:14] ++ #mac_address="$mac_address""&mac_addresses=""${i}"; [15:14] commenting out?! [15:14] bad form ;) [15:15] roaksoax, ^ i told you to get rid of that comment before uploading :) [15:16] smoser: arg... I did... but after so many links I guess I got confused an applied the wrong patch :) [15:16] it works though [15:16] so i'm good with that. [15:17] all good [15:18] I've got a maas client that simply will not budge, precise repo, HP proliant, WOL/PXE enabled eth0, use existing dhcp. http://pastebin.ubuntu.com/1273410/ [15:18] I click start node and it does nothing [15:28] ppetraki: i wouldn't be relying on precise's MAAS to work properly in what WoL is concerned [15:29] roaksoax, :(, to the ppa then [15:30] roaksoax, thanks [15:31] ppetraki: welcome :) [15:31] flacoste: so today is the last day we can upload new upstream release before a SRU.. until what rev do you want to get in? [15:31] Daviey: until when can we make the upload? [15:32] roaksoax, so maas-enlist ? expecting in a sru somewhere? [15:33] smoser: we just need to wait for it to be available for verification [15:33] i see. [15:33] smoser: its already accepted [15:33] https://launchpad.net/ubuntu/+source/maas-enlist/0.4-0ubuntu1.3 [15:33] right [15:33] smoser: after verification, we wait 7 days [15:34] roaksoax: so I'd like smoser fix for ipmi-locate to be in [15:34] i just approved it [15:34] so that would be 1264 [15:34] rvba, allenap: anything other fixes in-flight that could be landed shortly? [15:34] jelmer: how's your memory constraint fix going? can we upload that today? [15:35] flacoste: all the fixes we (the red squad) wanted to check in have been landed as of r1261. [15:36] flacoste: Not sure if jtv will have time to finish the improvements he wanted to make to the cli. [15:36] Help message improvements. [15:36] roaksoax: verification failed. MAC address problem. I assume this was your other fix? [15:36] rbasak: yes [15:37] flacoste: Yeah, I think I can propose it for review before EOD [15:37] roaksoax: it stops me verifying 0.4-0ubuntu1.2 since all highbanks have two NICs [15:37] rbasak: you can just veirfy with 1 MAC address [15:37] flacoste: but all our (known ;)) critical bugs have been fixed. I tested a package I made (ppa:rvb/maas) 0.1+bzr1261+dfsg-0ubuntu4~ppa1 a few hours ago. [15:37] rbasak: maas-enlist --serverurl XYZ -i eth0 etc etc [15:37] rbasak: if you specify the interface it will only use 1 MAC [15:38] roaksoax: I'm verifying by actually using MAAS to enlist. And that doesn't work. [15:38] jelmer: well, it would needed to be _landed_ before EOD, so should we wait for it, or not? [15:39] roaksoax: landing this in -updates will cause a regression. [15:39] roaksoax: thus it should be verification-failed, no? [15:39] rbasak: that's why .3 is for [15:39] OK, so I'll verify .3 then [15:39] When it lands in -proposed [15:39] rbasak: cool [15:39] flacoste: that should be doable too; when is the upload happening? [15:41] roaksoax: what's the limit? [15:41] flacoste: Daviey's EOD [15:41] roaksoax: he has one? [15:41] apparently so :) [15:43] rvba: i'll make available a new package for you to test with your fixes and some minor changes :) [15:44] roaksoax: all right. I'll test the connection between the region and the cluster. [15:51] roaksoax, hey, did you see the package build failure because of the ipmi-enlistment patch? [15:51] roaksoax, so should I just pin quantal working from precise or pick one of the pockets from here? http://ppa.launchpad.net/maas-maintainers [15:52] matsubara: yes: https://code.launchpad.net/~andreserl/maas/packaging_updates_bzr1263/+merge/129221 [15:53] roaksoax, cool. thanks! [15:53] ppetraki: the latest quantal is not yet available for precise, but you should be able to test ppa:maas-maintainers/testing [15:53] with newer maas for precise [15:53] without cobbler [15:53] roaksoax, thanks [16:07] rbasak: hi? [16:08] roaksoax: so prepare an upload for 1264, if jelmer lands his fix before Daviey's EOD, let's include it, otherwise 1264 is a good fallback [16:10] flacoste: ack [16:10] rvba: http://paste.ubuntu.com/1273523/ [16:10] jelmer: ? [16:10] rvba: i'm not particularly thrilled with that fix... but it seems the only way to do it easily [16:11] rbasak: I was curious if you had some example lshw -xml output from an ARM machine [16:11] jelmer: yes, one moment [16:12] jelmer: https://bugs.launchpad.net/maas/+bug/1064638/comments/5 [16:12] Ubuntu bug 1064638 in MAAS "Commissioning is failing to set node memory attribute" [Critical,Triaged] [16:12] rvba: i'd much rather just set the url independently [16:13] roaksoax: looks like a good enough fix to me. What do you mean independently? [16:14] rvba: see how configure_maas_default_url or configure_maas_squid_deb_proxy work [16:14] rvba: I'd much rather do it that way [16:14]