=== matsubara is now known as matsubara-afk [06:47] jtv: I updated Martin's branch here: https://code.launchpad.net/~jameinel/maas/cpu_mem_tag_constraints/+merge/126863 [06:47] can you look at it? [06:47] I'd like to get it landed today, so that we can set up the rules for diogo to test it. [06:48] OK [06:49] bbiab, grocery run. [06:55] jam: thanks for clarifying that mapping... The InvalidConstraint error looks a bit confusing in that it doesn't distinguish between "unknown tag" and "unusable value for tag." [06:56] Imagine you're using this and you get an error: "Invalid 'architecture' constraint: armhf/nintendo" [06:56] You'd be driving yourself mad figuring out what the problem is with Nintendo ARM support. [06:57] But the error might actually be trying to tell you that you mis-spelled "arch" in the first place. [06:58] Maybe this would work best with separate error classes: UnknownConstraint and BadConstraintValue. [08:30] mgz: morning [08:31] where's w7z ? [08:57] rvba: so, I can do a make run and see where I end up. I know I was missing 'maas-provision' at one point. [08:57] I don't quite see how that would be related, but it was something I installed. [08:58] jam: shouldn't be needed, the dev instance should use bin/maas-provision. [08:58] rvba: k, it is listed in HACKING as something you need to install. [08:58] I'm getting a failure for 'rndc' [08:59] connect failed: 127.0.0.1#9154 [08:59] and now it runs... [08:59] rvba: Failing tasks should not be a problem really. Let me see what If I can get everything to work with trunk… [09:00] I see a lot of failures in the celery log, but those *aren't* IOError unhandled exceptions trying to read a file. [09:00] The dns server takes a few seconds to come up so some of the tasks fail, then are retried, then they work. [09:00] so I have a feeling 'captured exception' vs 'unhandled exception' was what was killing the celery working and breaking the startup. [09:01] So I still have failures, but it fails in a way that I can use it. [09:02] rvba: so thank you for scaring my machine into working [09:03] jam: does the web interface work now? (http://0.0.0.0:5240) [09:04] rvba: localhost:5240 works now, yes [09:11] allenap: is there a way to figure out what is generating "bin/maascli: error: u'name'" ? [09:12] (I wonder if the issue is something is meant to be sent as 'name' but it is labeled 'tag_name' somewhere else) [09:12] jam: In src/maascli/__init__.py, raise instead where it catches StandardError, might help. otp right now. [09:15] allenap: essentially, things seem broken when trying to access Node or Tag apis, because the URL has a sub-component. For example, I would expect to do: bin/maascli api maas tag tag-name read rather than bin/maascli tag read tag-name. Because the URL is GET api/1.0/tags/tag-name/ [09:16] okay, am back now [09:16] hi mgz, mumble? [09:21] jam: lets [09:36] jtv: so you didn't actually vote on my MP, we can just put your code in there and do it, is that enough to land it? [09:37] jam: not enough, no. Wanted to hear your answers first! [09:37] If it's a problem to address them today, we can negotiate a more lenient sentence. [09:37] jtv: well, the immediate thing is getting something that can be QA'd [09:38] which needs something to land [09:38] I don't particularly mind module vs class [09:40] The class thing is a valid technique, but since it contains nasty bits that are out of the ordinary it does need to be made clear. In this case, it doesn't provide any convenience at all, so the cleverness seems out of place. [09:42] If you want to keep it the way it is, please document how those private methods fit in. [09:46] mgz: https://code.launchpad.net/~jameinel/maas/tag-name-api/+merge/126897 [10:18] juju.errors.ConstraintError: Bad 'maas-tags' constraint 'speedy': tag 'speedy' does not exist [10:31] mgz: as in it now works? [10:35] jam: indeed [10:36] mgz: I seem to have broken whatever code you had that turned InvalidConstraint into a NOT_FOUND (though we really want BAD_REQUEST, right?) [10:38] you probably just want to flip the expectation in the test [10:54] mgz: yep, that was enough, I was just confused by the traceback it showed for context. [10:55] jtv: care to look at https://code.launchpad.net/~jameinel/maas/cpu_mem_tag_constraints/+merge/126863 again? [10:57] Coming [10:57] I have one more quick patch to line up the constraint name with the db field name [10:57] but that should be small. [11:07] jam: done [12:12] allenap: forgive me for what I am about to do [12:13] * allenap dons ceremonial robes [12:17] it's not that I don't respect your reviews, it's just the easiest way of landing the finished branch :) [12:27] mgz: I was just going through the queue, tidying up; I don't have any objection whatsoever to you landing that branch :) [12:28] Morning ahasenack :) [12:28] hi allenap === matsubara-afk is now known as matsubara [13:33] allenap: howdy [13:33] allenap: any luck with the tftp stuff? [13:33] roaksoax: Hi three. [13:34] roaksoax: We talked about it this morning. The answer is: use http :) We don't have time to address that problem. I'm sorry about that. [13:34] roaksoax: We can revisit it after 12.10 if it's important. [13:35] allenap: no worries :) HTTP was my approach too :) [13:35] roaksoax: Cool. Let me know if you need someone for fisticuffs with Daviey :) [13:37] allenap: thanks but I think he will understand :) [13:41] fisticuffs ?! [13:41] I'm not that kinda man! [13:41] at least buy me dinner first. [13:46] I think you misunderstood. Not /those/ kinds of cuffs Daviey. Keep those for the weekends. [13:49] how do i configure maas-cli ? [13:50] allenap, ^ [13:52] smoser: Do you mean, how do you get started? maascli api login local http://localhost:5240/MAAS/api/1.0/ $CREDS [13:53] smoser: Then: maasapi api local --help [13:53] smoser: If you omit $CREDS, you'll be prompted for them. You can also specify them as an empty string for anon access only, or pipe them in. [13:54] right. [13:54] smoser: Sorry, specify them as - in order to pipe in. [13:54] $ maas-cli api list [13:54] maaslocal http://localhost/MAAS/api/1.0/ 8mnmG6X3Erxmw5SzGV:KFmZYJYsewXxD5RSjR:WKbZWmrt63hNQVXG7JzyjRtTRjkj3esK [13:55] probably didn't want it to print my creds there. [13:55] smoser: I'm guessing that machine isn't accessible from here :) [13:55] try them! [13:55] i suggest rooting the machine 'localhost' and destroying it! [13:55] :) [13:55] Haha :) [13:58] allenap, so the first thing i wanted to do with my shiney new api client... [13:58] was to upload some ssh keys [13:58] as i have to do that in the web ui , and that sucks. [13:58] ... doesn't work? [13:58] can i do that? [13:58] I don't think so; matsubara filed a bug about it. [13:59] ah. k. [13:59] next question [13:59] using 'maas' (not 'maas-cli') how can i get a user's creds ? [13:59] (again to avoid going to web ui) [13:59] This is the first proper client of the API, so not everything that's in the web is available in the API yet :-/ [13:59] rvba: ^? [14:00] allenap, thats fine. [14:00] i'm just trying to work through a path that would be able to actually do something useful [14:00] without a human clicking buttons [14:01] (as much as i enjoy clicking buttons, i enjoy complaining more) [14:01] smoser: there is the create_authorisation_token API method. [14:01] rvba: I guess that's a chicken and egg scenario. [14:01] rvba, i think you're missing my goal. [14:01] i added the user with 'maas createadmin' [14:01] allenap: right :) [14:02] (or i suppose i can add a user somehow with 'maas' cli) [14:02] i want to then get (or create) credentials for that user [14:02] Right, chicken and egg, as allenap said. [14:02] smoser: You might be able to do: echo "SELECT ..." | maas dbshell [14:02] its not really chicken and egg. [14:02] i'm using hte 'maas' executable. so i have a suitable chicken. [14:03] i'll poke around in the db [14:03] Indeed. From the right angle, it looks like a chicken. [14:04] allenap, http://paste.ubuntu.com/1247554/ [14:04] maas lay_eggs_dammit [14:04] maas dbshell stacktrace [14:04] Ahh. [14:05] We don't ship the test code in packages. [14:06] https://bugs.launchpad.net/maas/+bug/1058126 [14:06] Ubuntu bug 1058126 in MAAS "maas dhshell stacktraces in package" [Undecided,New] [14:06] i'll open a bug for "please give me some creds!" [14:10] smoser: we could create a command for that but to give you a workaround, you can pipe http://paste.ubuntu.com/1247565/ in ./bin/maas shell. [14:10] gracias. [14:10] can a user change their password via api? [14:11] web login password [14:11] No. [14:12] But there is a *changepassword* command. [14:12] But no API method yet, sorry. [14:12] So it can't be done remotely. [14:13] No. it cannot be done remotely. [14:19] allenap: do you mind, think is correct that I install the squashfs image at the same place where the tftp image are available, and then make it available through tftp? [14:19] err [14:19] s/tftp/HTTP? [14:20] is there a way to make maas shell not interactive ? [14:23] smoser: I've been trying that... and it seems not :-/ [14:23] roaksoax: Erm, for expediency, okay. Otherwise I'd say it's not the right place. [14:24] allenap: so I guess i'd have to modify maas-provision install-pxe-image to support a --image="squashfs" method then? [14:26] why is it that we're not going over http with this ? [14:26] roaksoax: That command is for a kernel and initrd image, rather than a root filesystem, but for 12.10 I think it's okay to piggyback on it without change, and just serve the whole tftp tree over http too. [14:26] smoser: we are going through http [14:26] ah. ok. [14:26] allenap: ok [14:26] then can we make a different command instead? [14:27] a generic one, that just says "make this file avialable at this path" [14:27] yes I think that would be better instead [14:27] i'm not sure what i think about it really. [14:28] smoser: Yeah, we could. install-pxe-image is basically that command, except in name, so I think it's okay for 12.10, unless you think it's just storing up pain? [14:28] hm.. [14:28] well i reallythink you should not put the stuff int eh same path as tftp [14:28] What's downloading the squashfs image from the archive? [14:29] smoser: I agree, perhaps I don't feel as strongly, but if we can avoid extra work that would be good too :) [14:29] and i thikn that install-pxe-image's arcane behavior of deleting data is generally unsuitable [14:30] ok there's an issue with maas-import-pxe-files [14:30] its not *terrible* as an internal tool, but its *not* an internal tool [14:30] (/usr/sbin) [14:31] errr... wait . ignore that last comment. [14:31] when we call maas-import-pxe-files with RELEASES="precise quantal", then maas-import-ephemerals dies in quantal, causing maas-import-pxe-files to die as well [14:32] smoser: ^^ [14:33] allenap: ^ [14:34] roaksoax: How does it die? [14:35] allenap: so maas-import-ephemerals exits becuase there's no quantal image right? so if you put something to be done after that, it won't be executed [14:36] allenap: so if i enable RELEASE="precise quantal" for import_pxe_files config file [14:36] allenap: when it runs maas-import-ephemerals it dies with: failed to get https://maas.ubuntu.com/images/query/quantal/ephemeral/released-dl.current.txt [14:36] remote query of https://maas.ubuntu.com/images failed [14:36] and then maas-import-pxe-files stops there and does not continue [14:37] so if I add the maas-import-squashfs execution, then it wont be executed due to maas-import-ephemerals failed making maas-import-pxe-files terminate [14:37] rvba: in the templating system, can we test for the existance of files in particular locations? [14:37] roaksoax, known issue [14:38] echo "STREAM=daily" | sudo tee -a /etc/maas/import_ephemerals [14:38] there are no released quantal ephemerals [14:38] rvba: what I wanna do is test whether the squashfs image exists in the directory, if it doesn't then don't make the intsaller try to use it [14:39] smoser: yeah I know, but my point being is that maas-import-pxe-files should not stop when maas-import-ephemerals has stopped [14:39] smoser: so maas-import-pxe-files should continue to do everything else that it was supposed to do [14:39] but it doesn't [14:39] roaksoax: The call out to maas-import-ephemerals (in the import_ephemeral_images function) could be || echo "Importing ephemerals from ... failed" >&2 so that it doesn't cause everything to stop. Is that reasonable? [14:40] roaksoax, i consider that arguable. [14:40] it should most definitely error if something errored. [14:40] going down a sour path and pretending life is fine is notuseful [14:41] smoser: indeed. but for example, if I were to add the function for maas-import-squashfs after the maas-import-ephemerals, then becuase the latter failed, maas-import-squashfs function won't be executed [14:41] if the package installation fails that will also not happen [14:41] should we make dpkg just ignore failure? [14:41] allenap: i think so yes, it should error as smoser mentioned [14:42] i think the behavior is correct right now. if something fails, generally, it should exit. [14:42] smoser: i'm not saying that we should ignore that error, I'm saying that because commissioning image is not available in the release we want, it means that we will fail to download the squashfs image that we know exists [14:43] roaksoax: I think it would be better to create a variable that will be True or False depending on the existence of the files and pass that to the template. [14:43] this is a development release issue only, roaksoax [14:43] and it is easily fixable [14:43] i can make a quantal daily based on the beta-2, test it, and call it "released" [14:43] rvba: where do we do that? [14:43] in fact, i probably *should* do that. [14:45] roaksoax: src/maasserver/preseed.py:get_preseed_context. Simply create a utility method like "def is_squashfs_image_present" (or something) and then add that to the context in get_preseed_context. [14:46] roaksoax: also, please don't forget to review Julian's branch (https://code.launchpad.net/~julian-edwards/maas/add-maas-cluster-packaging/+merge/125427). It's fairly critical for us to get this landed asap. [14:47] smoser: so the thing is that we can't globally say "import release X,Y,Z" and fail because scriptX doesn't make use of release Y. [14:47] smoser: as in, the maas-import-squashfs only supports quantal and up [14:47] smoser: and maas-import-ephemerals only supports precise for now [14:48] roaksoax, well, a.) you can actually configure that seperatly (as shown above in /etc/maas/import_ephemerals) [14:48] b.) i'm not sure that i agree with that statement anyway. [14:48] if something is busted, it shoudl fail [14:48] rvba: i'm aware [14:48] if config says "import squashfs for precise" then it should fial trying to do that. [14:49] roaksoax: All right :). Thanks. [14:49] rvba: there's things to test such as precise upgrades, quantal upgrades after the split is in place, etc etc [14:49] Yep, lots of testing and fixing. [14:49] roaksoax: smoser's right; we shouldn't ignore errors too broadly. I'd say, if the query_remote in maas-import-ephemerals returns HTTP 404, then (and only then) can we continue. [14:49] smoser: right, exactly, should fail to import precise, but should not fail to import quantal [14:50] smoser: so it should say: "failed to import precise, not existant\n successfully imported quantal" [14:50] it should exit non-zero [14:50] which is probably going to cause any automation based on it to fail [14:50] in which case the problem has to be fixed *right now* [14:50] so you might as well fix it. [14:50] smoser: the problem is not on maas-import-ephemerals [14:50] smoser: the problem is in maas-import-pxe-files [14:51] fix the problem. do not ignore the errors. [14:51] i realize you're basically arguing that you want 'make -i' (just go as far as you can) [14:51] which is not entirely unreasonable. [14:51] but i dont think it *really* buys you anything here. [14:53] rvba: when I try doing a schemamigration --auto, I get a bunch of extra changes. I take it this is a problem? http://paste.ubuntu.com/1247643/ [14:53] smoser: ok so for example, lets consider this case. import_pxe_files says RELEASES="precise quantal". So currently, we are making the assumption that there's Ephemerals and Squashfs images available because all scripts source import_pxe_files [14:53] rbasak: these are the changes from migration 29 and 30. they should not be there. [14:54] rbasak: make sure you distclean your env and create the migrations again. [14:54] rvba: will do, thanks [14:54] smoser: however, the problme is that squashfs only supports quantal and Up, and ephemerals only has precise available. [14:54] so [14:54] a.) change /etc/maas/import_ephemerals to have RELEASES="precise" [14:55] b.) add some configuration explicitly for SQUASHFS and turn it off by default for < quantal [14:55] but if the user configures that on, then you need to fail [14:55] smoser: so as a user, comes an runs maas-import-pxe-files and finds itself with a failing import [14:55] ie, if they say "oh look i'll install squashfs for precise by adding that line here" [14:55] then you should fail when it does that. [14:55] not ignore and go on [14:56] i'm saying the user will not find a failing import [14:56] unless they change something, explicitly asking for a configuration that does not work. [14:56] alright [14:56] i give up [14:57] i really dont care all that much. [14:57] but ignoring the errors is wrong [14:57] the default shoudl be to work correctly. [14:57] we need to fix the defaults (or release a 'released' of ephemeral for quantal. i will do that now) [14:57] again, i'm NOT ignoring errors === hazmat` is now known as hazmat [14:58] i'm NOT suggesting to ignore errors [14:59] you said: "we are making the assumption that there's Ephemerals and Squashfs images available because all scripts source import_pxe_files" [14:59] maas-import-pxe-files calls maas-import-ephemerals, if the latter failed, good, it failed, that shouldn't stop maas-import-pxe-files from continuing because the fail is not in maas-import-pxe-files, it is in maas-import-epehemrals [14:59] i'm saying "that assumption is your problem" [15:00] rvba: so after distclean, schemamigration --auto says that nothing has changed, presumably because my code was already post-schema-change [15:00] rvba: I'm a bit worried about screwing this up. Do I need to revert the schema change, run syncdb, reapply the schema change and then run schemamigration --auto? [15:00] rvba: or is there another way? [15:01] maas-import-ephemerals is part of maas-import-pxe-files . [15:01] its no less part of that than adding tftp files [15:01] rbasak: South should compare the state it has in the last migration file, compare it with the state of the model, and identify the migrations to be done. [15:01] $ grep EPHEM /etc/maas/import_pxe_files [15:01] #IMPORT_EPHEMERALS=1 [15:01] rbasak: let me have a look at that branch. [15:01] rvba: there was a merge conflict merging trunk. Shall I push the dropping of the migration files and the trunk merge? [15:02] rbasak: yes please. [15:02] smoser: oyu are the expert, you know best [15:02] i give up [15:02] rvba: done [15:11] rbasak: migration seems all right to me: http://paste.ubuntu.com/1247675/ [15:18] rbasak: it was created simply by running: './bin/maas schemamigration maasserver --auto change'. Then you need to create the other migration by hand of course since it's not a schema change. === matsubara is now known as matsubara-lunch [15:23] rvba: I'm running make distclean, then make, then bin/maas schemamigration maasserver --auto change, and I get "Nothing seems to have changed." [15:23] rvba: never mind [15:24] rvba: I think distclean was missing something [15:24] rvba: I ran rsync -a --delete from a different checkout of the branch, and using that it worked [15:24] rbasak: it would be good to know what is was missing so that I could fix this. [15:25] rvba: it's gone now :-/ [15:47] rvba: would you mind checking if https://code.launchpad.net/~racb/maas/subarch-model/+merge/126712 looks good to you now please? [15:47] rbasak: sure [15:52] rvba: so like this: http://paste.ubuntu.com/1247761/ [15:53] rbasak: the migrations looks fine to me… but I get 2 failures when I run the test suite: http://paste.ubuntu.com/1247762/ [15:54] rvba: ah. That'll be caused by me merging trunk. I should have ran tests again after that, sorry. [15:54] rbasak: no problem. [15:56] roaksoax: looks ok but: a) you can return directly os.path.exists(..) (no need for the "if" statement) and b) "TFTPROOT/node.architecture/generic/node.distro_series/install/filesystem.squashfs" will need to be fixed of course :). [15:57] roaksoax: do we need a precise task for bug 1056816? [15:57] Launchpad bug 1056816 in maas-enlist (Ubuntu) "maas-enlist does not post subarch" [Undecided,Fix released] https://launchpad.net/bugs/1056816 [15:57] rvba: yeah! alright I will have a MP for monday cause I have yet to test that. [15:57] rbasak: yes we do [15:58] roaksoax: cool. [15:58] roaksoax: could you create one for me please? I can only nominate. [15:58] rbasak: sure [16:12] rvba: I've pushed a fix to those two tests. I get one other error. Did you see this too? http://paste.ubuntu.com/1247800/ [16:13] rbasak: looks like it's a warning, not an error. jtv ^, I think you've seen that problem already right? [16:13] Huh what? [16:13] jtv: Exception socket.error: (107, 'Transport endpoint is not connected') in > ignored [16:13] Test noise. [16:14] Yeah, I had that at one point but I killed it. [16:14] OK [16:14] rvba: I'll merge my branch in then [16:14] It happened when I ran the full test suite, but not when I ran _any_ individual test. [16:14] rvba: unless you object... [16:14] Well wait a moment... [16:14] * rbasak hopes he hasn't missed anything [16:14] We don't want that test noise in trunk. [16:14] This is probably the riskiest thing I've landed so far, but I'm not sure what else I can check [16:14] Let me see if I can remember what happened. [16:15] * rbasak waits [16:15] looks like a shutdown race [16:15] rbasak: I think that branch is fine now. Let's see if jtv can help with the test noise. [16:15] __del__ methods are fun, just print rather than propogate exceptions [16:15] My hypothesis was that I caused something like a celery connection to be set up that exited immediately, after which the cleanup failed. [16:17] So the problem may be that you're touching a real-world resource in testing. [16:17] Celery/rabbit-related resource. [16:18] Does it happen somewhere during shutdown of one chapter of the test suite, or setup of the other? [16:22] jtv: it's in http://paste.ubuntu.com/1247800/ [16:23] jtv: branch approved but with comments. [16:23] Thanks. [16:24] rbasak: yes, that's very similar [16:26] I'd look for places where you may have brought tests in contact with celery, e.g. by introducing a celery task invocation. [16:27] The error will happen, most of the time, if you run the maasserver tests plus any portion of our test suite right after it. [16:27] I think that you may need a celery fixture on any test case that may end up triggering a task.delay call. [16:30] rvba: btw... how do I get the tftp root. Config.objects.get_ etc etc? [16:34] roaksoax: no, the config in pserv is managed differently, see src/provisioningserver/boot_images.py but basically, you can do from provisioningserver.config import Config / Config.load_from_cache()['tftp']['root']. [16:34] I'd like allenap to confirm that if possible? (^) [16:34] allenap: ^^ [16:35] roaksoax: That looks about right. [16:35] awesome thanks :) [16:36] jtv: I don't understand what I could have changed that caused this. All the tests I've touched haven't changed in what they do [16:36] rbasak: it may not be the tests [16:37] Did you change any code in maasserver? [16:37] Yes, but only in pure python stuff. Nothing that should hit any libraries any differently [16:38] string changes, a data migration, a schema migration, and creating a new QueryDict [16:39] That's it as far as I can see [16:39] * rbasak has a hard stop in 20 minutes :-/ [16:39] Yet I can't reproduce the problem in trunk but it is present in my branch AFAICT [16:43] Just failed to reproduce on another run [16:43] on my branch [16:43] I'm going to assume that it's not an issue in my branch unless anyone objects [16:43] I can't fathom how I could have introduced it [16:44] I guess you'll have to land it. :/ [16:46] rbasak: got an MP I could have a look at? [16:47] jtv: https://code.launchpad.net/~racb/maas/subarch-model/+merge/126712 [16:47] Thanks. No promises. [16:47] (Nearly midnight) [16:51] rbasak: conflicts in the branch? :( [16:53] jtv: rev 1108? [16:53] Not showing a revision for some reason, but it's in the MP. [16:54] jtv: aargh. I only merged trunk about an hour ago! [16:54] Welcome to the Agile world! [16:54] I introduced a new model in a similar time and was told that you had _two_ database migrations landing that had to go before mine. :) [16:56] ...and I'd already had to redo those two migrations because a constraints related one had landed during my review === matsubara-lunch is now known as matsubara [17:00] Welcome to Saturday. [17:00] * rbasak is waiting for tests to finish [17:00] matsubara: is there anything else you need from us before you can try the tagging and constraint testing? jam sent an email with some general instructions to the list. [17:01] mgz, I'll take a look later on today. I need to finish some other stuff [17:01] jtv: merged trunk and pushed. Now on 1109 [17:02] \o/ [17:02] jtv: I need to go shortly. If you decide it's OK to land, could you please mark it approved please, so I don't come back on Monday to redo it all over again? [17:02] matsubara: no problem, I'm just nearing EOD [17:02] I will. [17:02] Thank you! [17:04] nn [17:05] released quantal ephemeral images at https://maas.ubuntu.com/images/query/quantal/ephemeral/ [17:06] i'm working on right now testing the daily images of precise [17:06] so that we could mark them as released [17:09] thanks jtv! [17:09] It's landing. [17:10] Enjoy your weekend. [17:10] rvba: still around? https://pastebin.canonical.com/75579/ [17:11] roaksoax: looking [17:11] rvba: that's the latest package julian made available on experimental [17:11] roaksoax: right, this has been fixed upstream this morning. [17:11] rvba: alroight coo. [17:11] alright cool [17:11] thanks [17:12] roaksoax: revision 1098 [17:12] rvba: alright, awesome thanks [17:12] np [17:17] roaksoax, this /var/lib/dpkg/info/maas-cluster-controller.postinst: 25: local: not in a function is fixed by your recent fixes? [17:17] matsubara: yes, I'm gonna upload something now [17:17] cool [17:22] matsubara: ok so I've uploaded, should build and yadah yadah in the next few mins :) [17:23] thanks roaksoax [17:23] roaksoax, are you dputting this directly into the ppa? [17:24] matsubara: yeah [17:24] ok [17:35] random comment. [17:36] maas in quantal is a lot nicer than maas in precise. [17:36] so good work on that. [17:36] i was just trying to test ephemeral images that they're good for 12.04 and realizing it is much nicer over all [17:38] Glad to hear that, in the middle of the current rush to get anything working at all. :) [17:45] roaksoax, is the maas-dhcp working on that ppa? [17:45] any known issues, I mean [17:46] looks like it didn't write /etc/maas/dhcpd.conf [17:47] matsubara: maas-dhcp is only a virutal package that installs isc-dhcp-server [17:47] and required files [17:47] you have to enable dhcp stuff differently now [17:50] roaksoax, how? through the web-ui? [17:50] matsubara: maas-provision I believe [17:50] hmm the web-ui doesn't have a option anymore [17:50] i can't see the options on the webUI anymore [17:51] jtv: ^^ [17:51] are we really making it extra hard to install MAAs [17:51] ? [17:52] You should still be able to configure dhcp through the UI. [17:52] jtv, there's no option anymore in the web ui [17:52] rvba would be the person to ask -- he's had to make some changes tonight [17:53] Those IP fields are of a different type now, inside Django. [17:53] Because the regular IPAddress field didn't support nulls. [17:53] matsubara, it worked for me earlier today from ppa [17:54] jtv, which IP fields? [17:54] jtv, the only IP fields I had to configure through the web ui before was the IPMI addresses [17:54] jtv: there's no UI option for DNS nor DHCP [17:54]