| Kupo24z | There a way to edit tags without maas-cli? | 01:20 |
|---|---|---|
| Kupo24z | maas-cli maas tag update-nodes juju add="node-3004a5ec-bf71-11e3-9d94-52540051bc11" results in "Not Found" | 01:21 |
| jtv | Kupo24z: looks like the wrong command line. I haven't done much with tags, so give me a moment to check | 01:23 |
| Kupo24z | Got it from https://maas.ubuntu.com/docs/tags.html | 01:24 |
| Kupo24z | ah, i think its 'tags new' first | 01:24 |
| Kupo24z | yup that did it | 01:25 |
| jtv | Yeah, we have this pattern where the plural acts more or less like a class, and the singular is for addressing objects. | 01:26 |
| jtv | Creating an object is something you do on the class, basically. | 01:26 |
| Kupo24z | Can you add multiple tags in one line? | 01:26 |
| jtv | No. | 01:27 |
| Kupo24z | jtv: is it possible to add a tag to a node by hostname or is it only system id? | 01:29 |
| jtv | Only by system ID. It's basically a node's identifying key. | 01:30 |
| jtv | Hostnames can be changed, so you see the can of worms there... | 01:30 |
| Kupo24z | hmm okay | 01:30 |
| Kupo24z | trying to make this somewhat automated in a script | 01:30 |
| jtv1 | bigjools: got time for a pre-implementation chat? | 04:23 |
| === jtv1 is now known as jtv | ||
| === vladk|offline is now known as vladk | ||
| bigjools | jtv: yes | 04:45 |
| jtv | talky? | 04:45 |
| bigjools | yarp | 04:46 |
| bigjools | jtv: fuxache | 04:47 |
| bigjools | jtv: there's no option in talky to select which camera/mic I need to use | 04:49 |
| bigjools | plus, trusty has broken my usb devices | 04:49 |
| jtv | Ah. | 04:50 |
| jtv | Well, maybe just here on IRC then? | 04:53 |
| jtv | Providing your keyboard works? | 04:53 |
| jtv | Branch up for review: https://code.launchpad.net/~jtv/maas-test/copy-file/+merge/214879 | 06:20 |
| bigjools | jtv: looking | 06:21 |
| jtv | Thanks. | 06:22 |
| bigjools | jtv: how can you have two symbols both called make_file in test_maasfixture.py? | 06:23 |
| === CyberJacob|Away is now known as CyberJacob | ||
| jtv | bigjools: one is just a convenience wrapper for the other. | 06:54 |
| jtv | They mean the same thing. | 06:54 |
| jtv | It's just that one is self.make_file() and the other is make_file(self). | 06:54 |
| jtv | I can remove the wrapper, but it was easier to leave it. | 06:54 |
| bigjools | yeah get rid of it :) | 06:54 |
| jtv | It's easier now anyway — doing it before the review would just have polluted the diff. | 06:55 |
| bigjools | kk | 07:00 |
| rvba | jtv: Actually, I diagnose the first problem before running things with your change :) | 07:13 |
| rvba | diagnosed* | 07:13 |
| jtv | :( | 07:13 |
| rvba | jtv: It was, indeed, a validation error. | 07:13 |
| === vladk is now known as vladk|offline | ||
| rvba | jtv: trying to debug the second maas-test problem now. | 07:24 |
| jtv | The only thing in the logs that struck me as particularly suspicious was the login failure. | 07:25 |
| jtv | I'm going out for a bit. | 07:25 |
| === BjornT_ is now known as BjornT | ||
| rvba | bigjools: btw, when will we change 'daily' into 'release' for the Trusty image label in etc/maas/bootresources.yaml. It's a bit of a chicken and egg problem unless the 'release' images get published a bit before the release. | 07:35 |
| === CyberJacob is now known as CyberJacob|Away | ||
| bigjools | rvba: we have to do it for the last upload | 07:35 |
| bigjools | ie probably tomorrow | 07:35 |
| bigjools | check with andres | 07:35 |
| rvba | Okay. | 07:36 |
| bigjools | it's not chicken and egg :) | 07:36 |
| rvba | Depends when the images are published really. | 07:36 |
| === vladk|offline is now known as vladk | ||
| rvba | jtv: btw, there is no reason why we should run maas-import-pxe-files manually in maas-test, as opposed to using the API. | 09:02 |
| jtv | Maybe one: | 09:02 |
| rvba | I might fix that as a drive-by if I manage to fix my pb quickly. | 09:02 |
| jtv | Running the script manually makes it slightly easier to write the bootresources.yaml. | 09:03 |
| jtv | Because we can just pass it on the command line. | 09:03 |
| jtv | Please don't change that while I'm working on this bug. | 09:03 |
| jtv | We can look at it again later, but it's not urgent. | 09:03 |
| rvba | Right. But we could also simply overwrite the config file in /etc/maas/ | 09:03 |
| jtv | Slightly harder. | 09:03 |
| jtv | We can, but then we need a sudo et.c | 09:04 |
| jtv | Instead of a plain scp. | 09:04 |
| rvba | Definitely not urgent. But this is actually related to my problem: the problem I'm dealing with now is that the boot images are not reported in time *because* we're calling the script manually. | 09:04 |
| jtv | Ahhh | 09:04 |
| rvba | i.e. with the API, the images would have been reported at the end of the import phase. | 09:05 |
| jtv | I Right. | 09:05 |
| jtv | Right. | 09:05 |
| rvba | But since this is all asynchronous, I have to poll for the boot images anyway. | 09:05 |
| jtv | We _could_ just jack up the frequency of that celery job... It's not going to be very costly, and 5 minutes was completely arbitrary as I recall. | 09:06 |
| rvba | I do think 5 minutes is too long indeed… but to avoid a race condition, we have to wait until the boot images are there anyway… | 09:06 |
| jtv | Yup. | 09:07 |
| rvba | Because we can't predict how long it will take for the import script to run. | 09:07 |
| jtv | How did we deal with that previously? I forget. | 09:07 |
| rvba | We didn't have to deal with it really, because the reporting was just a nice-to-have, not a crucial part of the infrastructure. | 09:08 |
| jtv | Oh, but as long as we're running the script manually, it won't complete until the import is done anyway, right? | 09:08 |
| rvba | Yes | 09:08 |
| jtv | If we jack up the frequency to twice per minute, then waiting for a minute after the script completes would solve the CI problem to all intents and purposes, right? | 09:09 |
| rvba | Before all the bootresources work, the images being there was the only requirement. Now we need them on the cluster and we need them reported back to the region. | 09:09 |
| rvba | Yes, that would solve the pb. | 09:09 |
| jtv | Just as a quick hack of course — as you say, in the end we must poll on BootImage. | 09:09 |
| rvba | The branch I'm testing now wait 5 minutes after the import script. (It's just a test to confirm my hypothesis) | 09:10 |
| rvba | waits* | 09:10 |
| jtv | Five minutes plus overhead, I guess. For those corner cases. | 09:10 |
| rvba | Like I said, it's just a test. | 09:10 |
| jtv | Sure. | 09:10 |
| rvba | Node is being powered up… let's see what happens. | 09:12 |
| rvba | jtv: gmb: btw, the decision to return 'no-such-image' as part of the pxe url when MAAS can't find a suitable image is one of those little things that make debugging so much easier. Thanks for that! | 09:13 |
| jtv | It was him. | 09:13 |
| * rvba thanks him. | 09:13 | |
| rvba | Node enlisted okay this time. | 09:14 |
| rvba | Okay, working on the polling stuff now. | 09:14 |
| rvba | jtv: success! (with sleep(5*60) after the import script has run) | 09:17 |
| jtv | Phew. | 09:17 |
| jtv | Something else maas-test may need: subarch! It doesn't do that yet, does it? | 09:17 |
| jtv | Oh wait, it does, it does. | 09:18 |
| rvba | Phew. | 09:18 |
| jtv | It's just still hidden inside the arch string. | 09:22 |
| jtv | There is some yuckiness going on with the additional i386 import, too. | 09:22 |
| rvba | jtv: I have trouble running the tests for maas-test http://paste.ubuntu.com/7225462/ The failure looks familiar but I can't remember what the pb was… can you? | 09:33 |
| jtv | rvba: could tox be one of those packages that maas-test needs installed but maas needs un-installed? | 09:34 |
| rvba | jtv: arg, that was it (but it wasn't tox, just python-api-client) | 09:35 |
| rvba | Thanks. | 09:35 |
| rvba | Any reviewer available for a fix to a critical issue? https://code.launchpad.net/~rvb/maas-test/import-images-api/+merge/214913 | 10:34 |
| jtv | rvba: if it's short, I can do it — but then you'll have to review and Q/A https://code.launchpad.net/~jtv/maas-test/bootresources-config/+merge/214916 :) | 10:43 |
| rvba | jtv: deal :) | 10:43 |
| jtv | Reviewing... | 10:45 |
| rvba | jtv: as far as I can tell, the change you're proposing won't allow us to configure the boot resources to get, say, the 'daily' images for a release. Wouldn't be simpler to let the user pass the entire bootresources.yaml file to maas-test? | 10:47 |
| jtv | Simpler for us, yes. But the UX was vetoed. I figured it's easy to add label to this later. | 10:47 |
| rvba | jtv: "But the UX was vetoed." what do you mean by that? | 10:48 |
| jtv | I mean that Julian immediately and resolutely said "no" when I listed it among the options. | 11:04 |
| jtv | Your branch has been reviewed. | 11:04 |
| rvba | All right. | 11:07 |
| rvba | Ta. | 11:07 |
| rvba | I think it goes a bit against maas-test being just a simple tool to drive MAAS itself… but okay. | 11:08 |
| rvba | jtv: I'm fixing my branch (as per your review). Then I'd like you to merge trunk into your branch so that I can actually QA it. | 11:09 |
| jtv | There goes my plan to leave on time... | 11:10 |
| rvba | jtv: I can create another branch from your branch and merge trunk myself. No worries. | 11:11 |
| jtv | Thanks! | 11:13 |
| jtv | Although I probably have myself to blame for being such a picky reviewer... | 11:13 |
| rvba | heh | 11:13 |
| jtv | Good night everyone! | 11:14 |
| === matsubara_ is now known as matsubara | ||
| rvba | allenap: I'd welcome your opinion on [1] in https://code.launchpad.net/~jtv/maas-test/bootresources-config/+merge/214916 | 12:20 |
| allenap | rvba: Okay, I’ll take a look. | 12:34 |
| allenap | rvba: I think bootresources.yaml is different to power parameters. The latter have a number of schemas associated with them. Trying to flatten that into a command-line is nearly impossible. | 12:44 |
| rvba | allenap: my suggestion is to pass the entire file content to maas-test. | 12:44 |
| rvba | All at once. | 12:44 |
| allenap | rvba: bootresources.yaml will be transient, but we can use capabilities to detect when we should use its successor. | 12:44 |
| rvba | allenap: maas-test --bootresources <file> | 12:45 |
| allenap | rvba: Would that be optional? | 12:45 |
| rvba | allenap: yes, of course | 12:45 |
| allenap | rvba: What’s the purpose? | 12:45 |
| rvba | allenap: customize the boot image import: use a different label, use a different path, etc | 12:45 |
| allenap | rvba: I imagine we still need the code in this branch when it’s not supplied? | 12:47 |
| rvba | allenap: no, we can use the default one. | 12:47 |
| allenap | rvba: Does that import everything? Using the default one makes sense - we’re trying to test how hardware works with MAAS out-of-the-box - but if it’s really slow then folk are going to tire of it. | 12:48 |
| allenap | rvba: This is pertinent w.r.t. the “directive” we had about default-to-everything. | 12:49 |
| rvba | allenap: It imports [i386,amd64]/release/precise [i386/amd64]/daily/trusty by default. | 12:50 |
| allenap | rvba: Is that MAAS’s default, or maas-test’s? | 12:50 |
| rvba | MAAS's default | 12:50 |
| allenap | biab | 12:51 |
| allenap | rvba: When we transition away from bootresources.yaml, what will we do with maas-test then? | 12:54 |
| allenap | gah, biab. | 12:55 |
| rvba | allenap: maybe we won't transition away from bootresources.yaml. Maybe the region will simply generate an ad-hoc bootresources.yaml every time the import script it run. | 12:55 |
| rvba | allenap: and if we do get away with it, then that's one more reason no to spend time getting maas-test capable of writing that file. | 12:56 |
| allenap | rvba: Either way, bootresources.yaml is an implementation detail, temporarily exposed to users while we scurry to provide API+UI for it. Jeroen has written the code to generate it. I think we should use it for now. I suspect we’ll have to change maas-test again in any case. | 13:23 |
| rvba | allenap: well, I don't agree but I guess I'm outnumbered :) | 13:24 |
| rvba | allenap: bootresources.yaml being an implementation detail should be yet another reason not to spend time working on code to generate it. We should expose it to user temporarily to give them maximum control over what gets imported. And change that when MAAS itself changes. | 13:27 |
| allenap | rvba: I think we can revisit this at some point. In the meantime I think jtv’s branch is an improvement, and is okay to land. | 13:27 |
| rvba | allenap: we won't be able to offer a unified interface in maas-test anyway. | 13:27 |
| rvba | allenap: well, apart from the fact that it doesn't work at all. | 13:27 |
| allenap | rvba: Doesn’t it? | 13:28 |
| rvba | allenap: see my point [0] | 13:28 |
| allenap | rvba: Oh yes :) | 13:28 |
| rvba | allenap: yet another reason why fiddling with bootresources.yaml is, I think, a bit pointless. Oh well | 13:29 |
| allenap | rvba: Given that the work has been done already I don’t think we can argue anymore to not do the work ;) | 13:30 |
| rvba | allenap: if it was working, I'd say you're right. | 13:30 |
| allenap | rvba: I don’t feel passionately about this, so maybe I’m missing something. | 13:30 |
| allenap | rvba: I don’t think this code is incompatible with adding a —boot-resources-config flag later on. | 13:32 |
| rvba | allenap: it is not, but why duplicate the work? That's all I'm asking. | 13:32 |
| allenap | rvba: We can’t unduplicate the work now. This is an improvement regardless, and it’s done (I’m assuming fixing it is a small thing). I also think this makes the out-of-the-box experience of maas-test better. | 13:33 |
| rvba | allenap: gmb: It's been a long battle, but I'm happy to report that the CI job for maas-test is now green. | 13:33 |
| allenap | \o/ | 13:34 |
| rvba | allenap: I agree. But adding the --bootresources would solve the bug this work is fixing and much more with ~10x less code. | 13:34 |
| allenap | rvba: It wouldn’t make the `apt-get install maas-test; maas-test …` experience better though. It’s not a massive amount of code either. | 13:36 |
| rvba | allenap: it would definitely make it better, because using your own bootresources.yaml file, you could do exactly what you want, and for instance limit the number of images much better. | 13:38 |
| gmb | rvba: Sweet! | 13:39 |
| allenap | rvba: How many people who want to test hardware compatibility with Ubuntu and/or MAAS (remember that MAAS compatibility is important to general Ubuntu Server compatibility now) are going to have a bootresources.yaml lying around? Afaict, this makes the experience better without having to think. | 13:40 |
| rvba | allenap: my point is simply that I don't think it's worth it. Use the default bootresources.yaml in most case, otherwise, let the user do as he pleases by providing his own bootresources.yaml. This solution is something is the middle that is, I think, wasted effort. | 13:42 |
| smoser | bladernr_, ping | 13:43 |
| bladernr_ | smoser: hello | 13:43 |
| smoser | so fast path install doc is bad. agreed. | 13:43 |
| smoser | :) | 13:43 |
| smoser | one question as to why you're wanting to use it. | 13:43 |
| allenap | rvba: It will save something now, and even more if/when (when most likely) we default to downloading everything. | 13:43 |
| smoser | rather than user-data. | 13:43 |
| bladernr_ | heh I've patched together about 1/3 of the solution sof ar | 13:43 |
| smoser | i suspect i can probably help you through the rest. | 13:44 |
| allenap | rvba: Even if this is wasted effort (I don’t think it is, fwiw), it can’t be unwasted now. | 13:44 |
| bladernr_ | truth be told, I don't know exactly WHERE to put this stuff, I was putting it in the install late_command just because that's where it is in d-i and what the limited docs I could find indicated | 13:44 |
| smoser | so how do you deploy nodes? | 13:44 |
| smoser | via juju ? | 13:44 |
| bladernr_ | no, purely via maas | 13:44 |
| smoser | perfect | 13:44 |
| smoser | then just use user-data | 13:45 |
| smoser | and cloud-init/cloud-config syntax there. | 13:45 |
| bladernr_ | either d-i or FPI if I can get FPI to install the test tools automatically | 13:45 |
| smoser | only do in the install environment what you need. | 13:45 |
| bladernr_ | where's user-data? | 13:45 |
| smoser | then your user-data stuff is install-path agnostic | 13:45 |
| smoser | and will also work on ec2 or wherever else you can talk to cloud-init. | 13:45 |
| smoser | (getting user-data info) | 13:45 |
| smoser | bladernr_, http://bazaar.launchpad.net/~virtual-maasers/+junk/maas-libvirt-utils/view/head:/maas-deploy-node | 13:46 |
| rvba | allenap: can't be unwasted. Let's see how much time it takes to fix this branch and QA it. | 13:46 |
| smoser | thats my 'deploy-node'. which takes a ubuntu release and user-data. | 13:46 |
| smoser | but it shoudl tell you what you need to do on the api. | 13:46 |
| smoser | essentially, you just pass 'user_data=BASE_64_DATA_HERE' on your 'start' call | 13:47 |
| smoser | that user-data can be anything that cloud-init understands. | 13:48 |
| smoser | which is described partially at | 13:48 |
| smoser | https://help.ubuntu.com/community/CloudInit | 13:48 |
| smoser | and then examples and doc of cloud-config options are at | 13:48 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt | 13:48 |
| allenap | rvba: Heh, yes, that’s a fair point. | 13:48 |
| smoser | but the dead simplist thing to do is just give a '#!' script to it, and it will be executed on first boot at rc.local-like time frame. | 13:49 |
| bladernr_ | Ahhh... yeah, I was wondering about that. and you can pass the script in via user_data= ?? (like user_data=`base64 myscript`) | 13:50 |
| bladernr_ | or is that more encoding the actual keypairs instead? | 13:51 |
| allenap | rvba: Okay, as this is not likely to make it into Trusty anyway, and we’re busy enough as it is, let’s put it on hold and discuss it in Austin? | 13:52 |
| rvba | allenap: well, my main point being that is was a wasted effort, like you said, if Jeroen can get it done quickly, then fine. But I suspect we will have to do the bootresources thing anyway. | 13:53 |
| rvba | allenap: Julian apparently explicitly said he was against adding a --bootresources option. That's what I'm fighting against. | 13:54 |
| smoser | bladernr_, like you said there. user_data=`base64 myscrtip` | 13:56 |
| allenap | rvba: I don’t know what Julian said, but I’m not thrilled about adding it either. It depends somewhat on how you see maas-test. I see it as a front-end for non-MAAS users to test hardware with MAAS. As such, I don’t think asking them to provide config files is good UI. | 13:57 |
| bladernr_ | smoser: awesome. thanks! | 13:57 |
| rvba | allenap: I guess it depends the kind of polish we want to apply to maas-test. | 13:57 |
| allenap | rvba: I think this is ripe for discussion face-to-face in Austin though. If nothing else it takes the heat off right now. | 13:59 |
| rvba | allenap: yeah, agreed. | 13:59 |
| rvba | allenap: any idea about https://bugs.launchpad.net/maas/+bug/1305061 ? Looks related to the RPC stuff but it's not clean why 'power_type' isn't there at all. | 14:35 |
| ubot5 | Ubuntu bug 1305061 in MAAS "maas crashes because of a missing power_type, even though I provided one" [Undecided,New] | 14:35 |
| rvba | tych0: do you have shell access to the machine where you saw https://bugs.launchpad.net/maas/+bug/1305061 ? | 14:36 |
| allenap | rvba: tych0 figured it out; reload the bug report. | 14:36 |
| allenap | rvba: It’s because pserv wasn’t running; it had crashed because of another bug :) | 14:37 |
| allenap | However, the error was not helpful. | 14:37 |
| rvba | allenap: ah right, I didn't reload the page. | 14:37 |
| allenap | rvba: It should probably have said “I can’t contact any clusters to validate this” or something like that. | 14:38 |
| rvba | allenap: definitely | 14:38 |
| jtv | rvba: I think I've found the reason for the problem with my maas-test branch... It's that the default simplestreams path (as encoded in provisioningserver/config.py) never got the v2 data! | 14:41 |
| allenap | jtv: Is this an “oh s**t” moment? | 14:41 |
| jtv | I would say so, yes. | 14:41 |
| jtv | But nothing that a small, simple patch won't solve. | 14:41 |
| rvba | jtv: right, the default value of the 'path'. | 14:42 |
| jtv | It doesn't have the -v2 bit in it... | 14:42 |
| rvba | indeed | 14:42 |
| rvba | jtv: that would explain why the import script failed with a KeyError on 'subarches' :). | 14:43 |
| jtv | Of course it also raises the question of whether the repo path should be a command-line option to maas-test. But one thing at a time. | 14:43 |
| jtv | Yeah, it's nothing whatsoever to do with the subarches in my code. | 14:43 |
| jtv | It's a field in the simplestreams data — v2, but not regular. | 14:43 |
| rvba | Yep | 14:43 |
| rvba | roaksoax: https://code.launchpad.net/~andreserl/maas-test/release_bzr126/+merge/204040 is obsolete now right? | 14:59 |
| jtv | rvba: https://code.launchpad.net/~jtv/maas/bug-1305118/+merge/214966 | 15:03 |
| jtv | Of course we'll also want either a configurable path, or dailies by default, in maas-test. But that's a separate issue. | 15:03 |
| rvba | Right. | 15:03 |
| rvba | Looks good. | 15:04 |
| rvba | jtv: that's precisely with I'm advocating for a general-purpose --boot-resources option. | 15:04 |
| jtv | I know, I know... but bear in mind we're aiming to replace that config altogether. | 15:05 |
| jtv | Thanks for the very quick review btw. :) | 15:05 |
| rvba | Quick fix → quick review :) | 15:05 |
| jtv | I'll also backport to 1.5. | 15:05 |
| roaksoax | rvba: that should have been emrged :) | 15:05 |
| rvba | roaksoax: I know, but gmb's changes make this obsolete now… correct? | 15:06 |
| roaksoax | rvba:hcecking | 15:06 |
| roaksoax | rvba: yes! | 15:06 |
| vladk | rvba: https://codereview.appspot.com/86070043 - gomaasapi TestServer extensions required for juju-core testing | 15:08 |
| rvba | vladk: looking | 15:10 |
| vladk | rvba: thanks | 15:52 |
| fader | Hey folks, is there any documentation anywhere on authenticating against the REST API? | 16:56 |
| fader | I can use it properly from a web browser if I have logged into MAAS interactively already, but if I haven't logged in or try from a script I get something like "Unrecognised signature: GET list" | 16:56 |
| fader | Seems to be similar to: http://askubuntu.com/questions/402691/handling-ubuntu-maas-restful-api-login (and not covered that I see in the API docs) | 16:56 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === vladk is now known as vladk|offline | ||
| Kupo24z | hey all, getting this error when booting via PXE: exceptions.AssertionError: No PXE template found in u'/etc/maas/templates/pxe'! | 18:20 |
| Kupo24z | odd because it worked yesterday | 18:21 |
| Kupo24z | and the dir is populated: http://paste.ubuntu.com/7227453/ | 18:22 |
| Kupo24z | hmm, reran pxe import script and it fixed it somehow | 18:35 |
| === CyberJacob|Away is now known as CyberJacob | ||
| tych0 | hi rvba, allenap: what is the DJANGO_SETTINGS_MODULE for maas? | 19:10 |
| tych0 | ah ha, maas.settings | 19:12 |
| === mwhudson- is now known as mwhudson | ||
| bladernr_ | hey, can someone catch me up on the state of uEFI support in MAAS? | 20:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!