[10:55] jam: mgz Hey guys, would you mind having a look at bug #1100091 ? [10:55] bug 1100091 in MAAS 1.2 "Kernel opts tagging feature missing completely" [Undecided,New] https://launchpad.net/bugs/1100091 [11:19] rvba: indeed, we were putting it on 1.2 but you guys were trying to do a release from that so we took it off [11:20] if it's now wanted in a 1.2 release, it will need backporting [11:22] mgz: Thanks for having a look. What's weird is that the support is partially implemented (the db migration to add the new field is there for instance). [11:23] mgz: I guess we need to clarify if it's a 1.2 or not. [11:24] the db migration stuff is there because migrations only work in a linear fashion [11:24] so, you can't backport one db change, but not the parts previous to it, without messing stuff up [11:24] Right [11:39] mgz, rvba: last word I heard was that bigjools didn't want it to land in 1.2 at all. [11:41] jam: well, Julian is the one who asked me to have a look at that bug. I added a comment on it; I guess we will see what he has to say about it. [11:41] mgz, jam thanks for your input guys. [15:05] roaksoax: Hi Andres, do you manage to get nodes enlisted in your environment? Because we're having trouble doing this in the lab and we're wondering if there isn't a problem with the ephemeral images… [15:07] rvba: howdy!! yeah im enlisting just fine. is this precise you are using? [15:08] roaksoax: yes [15:08] roaksoax: the nodes end up with an empty /etc/resolve.conf and the cannot do much. [15:09] rvba: is there a screenshot of the failure? [15:10] roaksoax: not really, but I can send you a log file if you want. [15:10] rvba: adam_g reported yesterday a failure after a cloud-init update [15:10] so might be related [15:10] smoser: ^^ [15:12] ephemeral images have not changed. [15:12] and should not be affected by cloud-init in -updates [15:14] smoser: whats the bug thst adam_g reported yesterday? [15:14] rvba: logs would be helpful [15:18] roaksoax: the failure itself is simple: in the logs, I see lots of "unable to resolve archive.ubuntu.com" and then the node gets enlisted with a stupid name because of bug #1081660. [15:18] bug 1081660 in maas-enlist (Ubuntu) "If maas-enlist fails to reach a DNS server, the node will be named ";; connection timed out; no servers could be reached"" [Critical,Triaged] https://launchpad.net/bugs/1081660 [15:21] rvba: check squid-deb-proxy maybe? [15:21] Logs looks fine… [15:21] We're trying with an old ephemeral image… [15:21] Just to be sure smoser ;) [15:21] ack [15:22] rvba, ephemeral images have not been updated to my konwledge [15:22] shoot. [15:23] if you're using dailies, something could be wrong [15:24] Damnit, it worked [15:27] rvba, were you using dailies ? [15:27] We're using the daily images in the lab indeed. [15:28] yeah. ok. so there is work to fix there then. i'm not sure what :-( [15:29] The symptom was: the image was dhcp booting ok but ended up with an empty /etc/resolve.conf [15:32] rvba, are you easily able to test quantal daily ? [15:32] wait. not woth it. [15:33] all right [15:34] (but the answer would have been 'yes') [16:46] rvba: the kernel opts stuff was removed from 1.2? [16:46] rvba: as in the stuff that allows us to specify extra kernel opts? [16:46] with tags [16:46] jam: ^^ [16:47] roaksoax: it was removed from 1.2 because Julian told jam the 1.2 was supposed to contain only bugfixes and no new features. Apparently… [16:48] -_- [16:48] -_-' [16:48] roaksoax: maybe we will revise that but we're waiting for Julian to decide :) [16:48] ack! [16:49] thanks for the info [16:49] (ツ) [16:52] does this error have anything to do with the error WARNING **: mirror does not support the specified release (precise)? I am also getting that error when a node pxe boots the inital install [16:55] the console log also show INFO: mirror does not have any suite symlinks. When i run the wget command on a virtual console one the node, i get a line for both Suite and Codename [17:04] smoser: so simply said, the fastpath installer is different kernel opts with different user-data right? [17:04] are there different kernel opts ? [17:05] wait. [17:05] ok. so what it is ... [17:05] http://bazaar.launchpad.net/~smoser/+junk/xinstall.maas/view/head:/maas.changes.diff [17:07] roaksoax, it is possible that i could have changed that else on line 51 btter [17:09] roaksoax, yea... so really the only additional prameter to the ephemeral environment is 'ds=nocloud-net [17:09] ' [17:09] smoser: ack [17:09] which convinces cloud-init it should just use the stuff from cloud-config-url= and not expect a datasource. [17:10] smoser: so in this case cloud-config-url is the contents of the /etc/maas/FAST-PATH-INSTALLER file [17:10] no. [17:10] that is an empty file. that just indicates if it should be taken or not [17:11] the payload is in 'preseed_fastpath' (see first hunk) [17:11] htat file is wrtten by the command listed in http://bazaar.launchpad.net/~smoser/+junk/xinstall.maas/view/head:/README.maas [17:12] we might be able to get rid of the different kernel param [17:13] and that is probably the correct fix. [17:13] as it maas's life much simpler. [17:14] yeah i'm just trying to visualize how to do this [17:15] rvba: so we have an issue, maas doesn't support raring [17:17] rvba: and it doesn't really makes sense to hardcode stuff [17:24] "maas doesn't support raring" [17:24] a.) that needs to be fixed [17:24] b.) why does that matter here [17:24] c.) what does that mean (doesnt support installing?) [17:24] smoser: yeah [17:24] smoser: raring is not a 'supported' release within MAAS [17:25] smoser: since it is being hardcoded [17:25] it was automatically detected before but was decided to not use that and hardcode it for the time being [17:39] smoser: we will not be using this right? # this line just says to use a different url (with -root.tar.gz) [17:43] roaksoax, well, the end goal is that we'll be using a -root.tar.gz to install from. [17:43] but we only have available on maas.ubuntu.com/images partition images. [17:44] elsehwere in that doc README.maas it explains it (see line 55) [17:47] smoser: ok, so we need 1. create the -root images (i'm guessing with maas-import-pxe-files) [17:47] 2. create /usr/share/maas/preseeds/preseed_fastpath on the fly [17:47] 3. have a tag that tells a system to fastpath [17:48] 4. have a tag that tells a system extra user-data [17:48] to be integrated with 2 [17:50] 1 should happen on the server side. tthe client should not need to create those. although it is sufficiently easy, so maybe that makes sense. it does require root though :-(, so maybe not. [17:50] anyway. .. .one way or another we need to have -root.tar.gz files availble for the installer to get at. [17:51] i might generalize 3 and 4 into one thing from maas perspective. [17:51] basically: [17:52] smoser: yeah i already have the tags stuff [17:52] (r partially) [17:52] if a node has a tag (through inheritance or directly) named 'install_preseed', then use that preseed. [17:52] smoser: the -root needs to be created on server side once maas-import-pxe-files is invoked though [17:52] this can probably be done in the existing preseed manner. [17:53] ideally, maas's knowledge of "fast path" should come down to [17:53] smoser: i'f the tag is fastpath=True, then I tell that the purpose is fastpath (which could be 'commissioning', or 'install') [17:53] a.) allow tag data to affect preseed data [17:53] b.) boot ephemeral image as the installer [17:54] c.) (if we have to) allow tag data "fastpath_install_kernel_opts='ds=nocloud'" to affect kernel options to 'b' [17:54] that make sense ? [17:54] then maas really is completely unaware of "fastpath" [17:55] smoser: yeah [18:04] smoser: this is what I was thinking: http://paste.ubuntu.com/1542176/ [18:06] done use the string fast path [18:07] and decouple "preseed_input" from "should_install_use_ephemeral_environment" [18:08] smoser: so tag would be ephemeral_install [18:08] or similar [18:08] right. [18:09] and then... the preseed templates [18:09] when theyu're rendered, do they have access to the node ? and its tags ? [18:10] carp. i thought tags had values. that sucks. [18:10] a tag as "kernel_opts" [18:10] :-( [18:10] smoser: they should yes [18:11] no. i'm saying tags do not have values. its not key-value. [18:11] its just key. [18:11] which sucks. [18:11] and its limited to 256 chars [18:11] which also sucks [18:12] you'll have to ask the maas devs about this. i dont udnerstand it really. [18:12] yeah [18:13] oh.. ok. re-using the kenelopts stuff. we can just override that. here.. [18:13] we add maas awareness of one tag: [18:13] installer_ephemeral_kernel_opts [18:14] if that is set, then it uses the 'kernel_opts' for that and uses the ephemeral environment for install [18:14] err... i guess you can cut the 'kernel_opts' part off the name [18:14] hten, to allow the user to atually put useful *DATA* into the preseed path, we will need to put another field in. [18:14] into the tags, but lets just call it "value" or something. [18:15] that make sense? [18:15] why oh why does a tag not have a value *and* be limited to 256 chars [18:16] smoser: right, that's similar to what I;m doing [18:16] heh. i guess we could just use tag names like: [18:16] installer_opts=http://place.where.my.opts.are [18:16] i dont know. [18:17] uhmm [18:18] ha. funny. [18:18] we just overload 'comment' with data [18:18] base64 encoded data. [18:19] then, if the preseed templates have access the currently executing node's tags, we can base64 decode there. [18:19] yeah [18:19] that too [18:20] jtv, anyone here able to explain to me why a tag would be so limited value ? [18:20] roaksoax, the more long term fi for this would be to have maas know about some "installer_input" and actually handle that specifically [18:21] yeah [18:21] i guess i'll have to discuss this with the MAAS team [18:21] do you know if we can get at node's tags in the preseed? [18:21] smoser: if we add them to the context we can [18:22] they shoudl definitely be part of the context [18:23] yeah [18:23] so I'll first work on getting the boot stuff, kernel params, image, etc, working as expected [18:23] then will deal with the preseed that [18:23] preseed data [18:33] smoser: Hold on [18:34] smoser: so we can do this: maas-cli tag create --name=00-default-console --definition=true \ --kernel_opts=console=ttyS0 [18:34] err [18:34] maas-cli tag create --name=ephemeral_install --definition=true --ephemeral_install_data=XYZXYZXYZXYZ [18:37] mgz: ping [18:43] roaksoax, ephemeral_install_data ? [18:44] you're saying we'd have to add that. [18:47] smoser: so if I do this: http://paste.ubuntu.com/1542262/, that means that we can define a tag with *any* name [18:47] definition is not that though. defnition describes the nodes that it applies to [18:47] smoser: right, forget about definition :) [18:48] so we owuld be adding another attribubte to the tag [18:48] overload comment [18:48] :) [18:48] so the tag would have a name, definition, and ephemeral_install_data attribute [18:48] and comment [18:48] oh wait. that might not work because tag is probably unique [18:48] maybe it is id ont now. [18:49] right so we can create a tag name=ephemeral, comment='ephemeral install', definition='whatever', ephemeral_install_data='data to use at install time' [18:49] right. i get what you're saing. we could do that. but i'd say that it shouldn t be "ephemeral_install_data" [18:49] it should just be "value" [18:51] smoser: you mean this?: http://paste.ubuntu.com/1542272/ [18:51] smoser: so the 'name' would *always* have to be say 'ephemeral_install' and we would have to check for that [18:52] tags dont work here i dont think. [18:52] 'name' is unique [18:52] smoser: so if someone defines: name='ephemeral_installer' value='blob' it wouldn't work [18:52] not unique per-node, but unique. [18:52] right. [18:52] so we would have to check for the name of the tag [18:56] smoser: now the problem is how to pass the user data [18:56] say we create a tag with --value=/path/to/filename we would need to modify the cli [18:56] to open the file, convert it in a base64 blob [18:56] etc etc [19:00] --value wont work === matsubara is now known as matsubara-afk