=== CyberJacob|Away is now known as CyberJacob === freeflying_away is now known as freeflying === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob [12:46] maas in ubuntu is still using old import_ephemerals ? [12:46] :-( [12:47] roaksoax, jtv thats correct, right? [12:48] we *really* need to get that fixed, as we want to be delivering updated fast path installer images and the old import_ephemerals does not delete content, meaning guaranteed filesystem full over time. [12:48] smoser: yup... they told me it was not ready [12:50] imo that has to land. [12:52] jtv, allenap ? is there a bug that explicitly addresses this? if not I'll open one. [12:53] smoser: i dont disagree but if BBBthe tools is not ready we cant uae it [12:53] smoser: jtv will need to answer that one. [12:53] smoser: and there are merge proposals already so it is being taken care od [12:53] smoser: I think it falls under the s-cloud-maas-maintainability blueprint. [12:56] it also falls under grave-security-issue if you want me to push that route. [12:56] how far are we from that being functional? i really had thought that this landed. sorry for not raising earlier. [12:56] smoser: the tool has landed not the use of it [12:57] What roaksoax said. [12:57] jtv: whats the status on the user configurable settibgs? [12:57] What settings specifically? [12:57] i raised to rvba that imho disnt seem like a good idea to put everuthibg on pserv.yalm [12:57] jtv: maas-import-ephenrals? [12:57] No, we're ditching that. [12:58] Yes, we're talking aboutg maas-import-ephemerals. [12:58] jtv: so....? [12:58] jtv how will a user select what releases wants to import and so on? [12:58] There's three ways: [12:58] 1. Command-line option. [12:59] 2. yaml config — but we didn't like the way the script rewrote pserv.yaml, so we're moving that to a separate file. [12:59] 3. The existing shell-style config still works. The script converts it to yaml config. [12:59] ok [13:00] i guess 2/3 is what i meant [13:00] I guess. [13:00] jtv: so if 3 currently works... why add yaml? [13:00] jtv: and... what is now preventing its usage? [13:01] The fact that we have changes we want to make to the config. [13:01] roaksoax, consuming shell from python is non ideal. i'd support moving away from that. [13:01] Right now, if you run the script (even with --help!) it writes its new config. After that it gets harder to move things around the way we intend to. [13:01] What smoser said. [13:01] smoser: roght i agree in the meantime it wouldnt hurt would it? [13:01] We've already moved away from that, but we've got some changes we want to make to how we migrate away from it. [13:02] jtv: ok [13:02] jtv: ETA? [13:03] and how is this planning to be run? [13:04] previously the user could run 'maas-import-ephemerals' and when it returned they knew that the system was ready for use. while that may not be an ideal interface, it does allow you to actually determine when maas was usable. [13:04] after installation, there needs to be a way to basically block until usable. [13:04] Hoping to be done with the config changes by Wednesday. But hard to predict, given the state of documentation etc. [13:05] smoser: it's still run in the same way — whether from the CLI or the UI. [13:06] jtv, so in packaged version is this runnable now? [13:06] is that what you're saying ? [13:07] The packaged version still uses the old script. [13:07] But you run it in the same way: CLI or web UI [13:07] smoser: the new version is not being installed [13:22] well, i opened bug 1236361. [13:22] bug 1236361 in maas (Ubuntu) "need new simple streams based maas-import-ephemerals" [Critical,Confirmed] https://launchpad.net/bugs/1236361 [13:23] i consider this critical to release of 13.10. [13:25] smoser: by the way, I noticed that the old ephemerals script only seems to download the oldest versions of images. [13:25] ? [13:25] i dont think thats the case. [13:26] It was downloading only beta versions of precise & quantal. [13:26] as i'm running it right now against dailies and its dowlnoading saucy 20131007 [13:27] Could you check your precise & quantal versions? [13:27] the *new* ehpemerals script was broken (due to server data being broken) [13:27] in that way [13:27] server data is now fixed. [13:27] server data had 'beta' as the "serial" version which C locale sorts to > YYYYMMDD, so simplestremas code was correctly considering those to be the latest [13:29] jtv, i certainly do not want to delay anything, but if you're consuming shell code as 'config' with python, https://gist.github.com/smoser/6466708 does that safely. [13:34] smoser: if you see any specific problem that it would help with, by all means do. [13:35] We do have some advantages that generic code doesn't have though: a statically known set of variables, and an existing relationship between the application and the config file. [13:37] jtv, you dnot actually have a know set of variables. [13:38] you exposed a shell program as a config mechanism. [13:38] which then, users could quite reasonably use however they wanted. [13:38] We have a known set of variables we are interested in. [13:38] but you dont know how they're set. [13:39] (note, you can pass in the list of variables you're interested in to that method, and it will correctly get their values) [13:40] anyway. i'm fine if you dont use it. but it is as close to "correct" a way as I can come up with to solve the "shell was used as config" problem. [13:40] That's nice. By all means, once you have the tests done, propose a branch that uses this in MAAS! === kentb-out is now known as kentb === freeflying is now known as freeflying_away [14:58] will python-curtin be backported to raring, quantal, and precise? [15:01] stokachu: AIUI it's destined to go into the cloud-tools pocket of the cloud archive [15:04] rbasak: ok thanks [15:12] stokachu, no. [15:13] not necessary [15:13] so funny story if you run make install-dependencies in the maas code tree it removes all network-manager related packages [15:13] leaving you without internet [15:13] good times. [15:13] you didn't need that interweb stuff anyway [15:13] lol [15:15] stokachu, you dont need to port python-curtin to raring/quantal or precise. [15:15] because pytho-curtin is installed on the maas server [15:16] it is packed up into a self extracting tarball, and shoved across to the installing node. [15:16] and then invoked over there. [15:16] in the control file it depends on python-curtin [15:16] thats right. [15:16] maas does depend on that. [15:17] you will not get maas with curtin support on Q or R. [15:17] you get it on P through cloud-archive tools [15:17] so are all maas developers running saucy at this point? [15:17] or will buildout handle getting a maas development instance up locally [15:18] oh. i see. [15:18] i dont know the answer to that question. [15:18] i tried following the hacking.txt file but it left me without network connectivity [15:20] stokachu, my response to any software package that says "hey, run this as root" is "run this in a lxc container or new cloud instance". [15:21] which makes running saucy or precise easy, and alleviates the network manager hardship. [15:21] i'm not saying thats a good thing, but its a general purpose solution to the problem. [15:21] ok [15:51] roaksoax, https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1236433 [15:51] Ubuntu bug 1236433 in maas (Ubuntu) "maas-cluster-celery did not survive upgrade" [Undecided,New] [15:55] smoser: did you only upgrade maas or rabbitmq or something else too? [15:55] smoser: you are also upgrading upstart: upstart:amd64 (1.10-0ubuntu3, 1.10-0ubuntu6) [15:55] smoser: might be related? [15:56] see bug. [15:56] roaksoax, fwiw, it still seems unable to power on nodes for me :-( [15:57] (even after starting the daemon) [15:58] smoser: weird, I have been running a server myself without issues [15:58] smoser: i'll check in a bit [16:17] so user provided preseed files are only available for enlist and commissioning? is there a way to override generic preseed during install? [16:19] stokachu: you can modify the preseed as you wish [16:20] roaksoax: directly modifying the generic preseed or through a user supplied preseed? [16:20] stokachu: directly modifying the preseed. you can create your own preseeds there and they will be added to the path, and you will have to add what you want to be added to the generic preseed from those user supplied ones [16:21] stokachu: for example, preseed_master imports from generic, so you could techniclally create another preseed similar to generic, and in preseed_master you would need to "call" what's in your preseed [16:23] so generic inherits preseed_master so wouldnt i need to create a generic_custom? [16:23] or is this the problem with Tempita [16:24] the documentation states Tempita's inheritence is 'weird' [16:27] hey guys. i just switched my toy maas server from 12.04 to 13.04 and met very strange issue. when i accept the node (either using dashboard or maas-cli) system doesn't create anything in pxelinux.cfg (in fact this folder is not created) and my nodes can't start commissioning. any ideas on how to fix that? thanks [16:27] so if i wanted to reconfigure the network on the node during installation do i edit generic or preseed_master [16:29] so creating amd64_generic_saucy will override generic, but i would still need to modify preseed_master to accept new network defintions, is that correct? [16:31] roaksoax: ah i see now what you meant by calling whats in my preseed [16:32] stokachu: :) [16:33] roaksoax: so in the web ui when a preseed is created for a node it'll pick up amd64_generic_precise if the commissioning is set to that os image? [16:33] os image being precise [16:38] stokachu: huh? [16:40] roaksoax: when commissioning a node will it pickup amd64_generic_precise if it exists? [16:42] well, i figured out that maas from 13.04 uses python/twisted-based tftp server instead of original tftpd. it mean that it can handle requests w/o pxelinux.cfg folder. but my nodes are stopped trying to pull pxelinux.cfg/ which means that this tftp server doesn't work well. [16:44] stokachu: you added a preseed from the webui? [16:44] stokachu: for commissioning/enlistment you can only add scripts that will do different taskls, not preseeds [16:45] roaksoax: where does the installer pick up amd64_generic_precise from if it exists? [16:45] preseed_master hardcodes the network, i need to override that [16:45] stokachu: what's amd64_generic_precise? [16:46] roaksoax: that is my user-provided preseed [16:46] from the doc: As you can see this mechanism is also used to calculate the base preseeds for [16:46] all of installation, enlistment and commissioning. It allows end users to [16:46] add, for example, a file named ``amd64_generic_saucy`` that would be used [16:46] instead of the ``generic`` template at installation time. [16:47] stokachu: idk how will affect curint installation method which uses the style of enlistment/commissioning, but if you are using d-i [16:47] commissioning/enlistment are completely different from installation preseeds [16:47] roaksoax: that i understand, i am more concerned with how to override the preseed during installation [16:48] stokachu: ok, so have you added your preseed to /etc/maas/preseeds? [16:48] before the actuall install procedure [16:48] stokachu: and defined a section [16:48] and called it in preseed_master? [16:48] so thats my question do i create a amd64_generic_precise and inherit preseed_master [16:49] stokachu: if you'd show me a diff of what you are trying to do maybe I could understand better :) [16:49] ok one sec [16:51] roaksoax: http://paste.ubuntu.com/6205699/ [16:52] preseed_master call self.network_conf, but that only exists in amd64_generic_precise [16:52] is this the correct way to override the installation for a amd64 precise install via maas? [16:52] stokachu: yeah that should work, but if network_conf is only for mad64 [16:53] then you would need to do stuff like: {{if node.architecture in {'i386/generic', 'amd64/generic'} }} [16:53] put that in the preseed_master right? [16:54] stokachu: http://pastebin.ubuntu.com/6205703/ [16:54] ah ok [16:55] roaksoax: thanks this clears up some stuff for me to work on [16:56] roaksoax: because i named it amd64_generic_precise this will only be read during a precise install correct? [16:56] everything else uses generic [16:59] stokachu: i don't know if the naming convention works that way [16:59] stokachu: better ask Ruetobas [16:59] err [16:59] rvba: [16:59] sorry [16:59] :) [17:00] roaksoax: im referencing the preseeds.rst documentation [17:00] stokachu: I have not tested that, but if that what the documentation says then I would give it a try [17:00] there also doesn't seem to be a way to just create a install preseed for a series without defining the architecture [17:01] ok ill do some more testing on this [17:17] strikov, i think likely the tftp server is not listening on the right interface [17:22] smoser: i had pretty the same thought first, but my node can pull pxelinux.0 w/o any problems [17:22] smose: i assume it pulls this file through tftp as well [17:24] strikov, its od.. [17:24] i've seen this before. [17:24] is your node virtual ? [17:24] yes, the whole environment is vbox based [17:24] https://bugs.launchpad.net/maas/+bug/1051626 [17:24] Ubuntu bug 1051626 in MAAS "PXE boot not working in virtual environment" [High,Expired] [17:25] smoser: interesting, but it looks like guys in the bug can't pull pxelinux.0 as well [17:26] smoser: we may observe different sides of the same issue though [17:26] strikov, no. se my coments in line 13. [17:26] comment 13 [17:26] and even 7. [17:27] ah, i see [17:27] maas from 12.04 worked fine for me in the same environment [17:28] i need to check if pxe binary changed a lot [17:28] strikov, its not the pxe binary [17:28] see my other comments there. . i basically tested everything hardy -> 12.04 [17:31] aha, well it looks like the issue began when maas switched to its own tftp server, right? [17:31] because 12.04 was the last maas with original tftp [17:32] did you try gavin's solution with restarting pserv? [17:35] strikov, i have tried many things. and i'm not sure if i hit this or not any more. [17:35] okay, i'll give it a try now. thanks for pointing to the bug. [17:35] strikov, could you try adding 'next-server' entry in /etc/maas/dhcpd.conf [17:35] and setting it correctly [17:35] i'm just curious. [17:36] okay, my virtual machine is reinstalling now, i'll check when it is ready [18:14] smoser: restaring pserv doesn't help [18:15] smoser: what did you mean by next-serv, do you want me to put my original server ip there or to setup external tftpd and put it there? [18:17] add an entry in /etc/maas/dhcpd.conf for 'next-server YOUR.SERVER.IP.HERE' [18:17] right underneith the 'filename' entry [18:19] smoser: i see and actually i found tons of errors in /var/log/maas/pserv.log while doing pxe boot [18:19] smoser: it can't find some images, trying to understand what's happening [18:22] smoser: actually it can't find i386 images because i disabled pulling them [18:23] strikov, yeah... so that sucks. [18:23] i think this is basically unavoidable. [18:23] smoser, next-server doesn't help [18:23] that you have to have the i386 [18:23] for enlistment at least [18:24] as maas doesn't know the arch at tha tpoint. [18:24] i did enlistment [18:24] with the bootable cd [18:24] at this point maas should know my arch i think [18:26] smoser: eod for me. i'll keep trying tomorrow and let you know if i find the solution [18:26] smoser: thanks for helping, ttyl [18:28] strikov, i agree, it shoudl know [18:51] roaksoax, [18:51] smoser, [Mon Oct 07 18:50:06 2013] [crit] [client 127.0.0.1] configuration error: couldn't perform authentication. AuthType not set!: /MAAS/static/images/amd64/generic/precise/xinstall/root.tar.gz <- any hint? [18:59] smoser: that's apache? [19:01] dropping 'Require all granted' from maas-cluster-http.conf helps [19:01] roaksoax, yea [19:03] smoser, curtin worked fine otherwise \o/ [19:04] adam_g: weird, before that required all granted was needed otherwise it wouldn't work [19:04] adam_g: hold done, is this precise? [19:05] adam_g: is this precise? [19:05] roaksoax, it is 1.4+bzr1656+dfsg-0ubuntu2~ctools0 on precise [19:05] adam_g: that's the problem them, for saucy the http ocnfig is different [19:05] which is why it fails in precise [19:05] due to different apache [19:06] oh hum [19:06] that stinks [19:06] gah. [19:06] that does stink. [19:06] smoser: i guess we could try fix that in postinst [19:06] well, you probably shouldnt edit a conffile postinst [19:07] though, right? [19:07] smoser: yeah but that is a config file being shipped by maas btw [19:07] right. [19:07] bugger [19:08] yup [19:08] some good pointers in https://wiki.debian.org/Apache/PackagingFor24 for supporting both apaches [19:09] ok i think i know how to fix it [19:10] oh nice. [19:10] IfVersion [19:10] yup [19:11] roaksoax, i'll file a bug [19:11] smoser: ok [19:17] roaksoax, https://bugs.launchpad.net/cloud-archive/+bug/1236544 [19:17] Ubuntu bug 1236544 in MAAS "canot access static images over http with apache 2.2 (precise)" [Critical,Confirmed] [19:19] smoser: thank you [19:22] I'm unable to bootstrap the juju environment on my raring maas server. Best I can tell from searching, it's because all my nodes are "allocated to root", and not "ready". How can I return them to ready status [19:24] sconklin, maas-cli $MAASNAME node release "$nodeid" [19:25] smoser: makes sense? http://paste.ubuntu.com/6206324/ [19:25] adam_g: could you pelase test: http://paste.ubuntu.com/6206324/ [19:26] smoser: what is $MAASNAME? [19:26] sconklin, however you use maas-cli [19:27] if you've not used maas-cli you need to set that up. [19:27] never used it [19:28] http://paste.ubuntu.com/6206336/ [19:29] you can do the same stuff in the web ui, click 'release' for each of the nodes. [19:29] I don't see 'release' in the UI [19:29] or 'stop node' i guess. [19:29] or stop node [19:30] for the node? [19:30] you have to go to the node' spage. [19:32] smoser: proposed fix... just need someone to test it: https://code.launchpad.net/~andreserl/maas/lp1236544/+merge/189692 [19:32] roaksoax, works but two things: should be closed with , not and you need to enable the 'version' module for that tag to work [19:33] adam_g, you have a funny definiton of "works" [19:36] doing a clean upgrade from maas 1.2 to maas 1.4 in cloud-tools shows this error http://paste.ubuntu.com/6206361/ [19:36] any way around that other than removing and installing maas 1.4? [19:44] hmm i did a clean install of maas and get that same error during the migration [19:47] wow. [19:47] stokachu, please file a bug. [19:48] did anybody see my report about http://maas.ubuntu.com/docs/install.html ? [19:48] adam_g, did you test roaksoax config change at https://code.launchpad.net/~andreserl/maas/lp1236544/+merge/189692 [19:49] Can MAAS install non-ubuntu operating system | http://askubuntu.com/q/354996 [19:50] smoser, i tested the equiv manually, but only works when the version module is enabled. there's a corresponding packaging change that needs to happen [19:51] smoser: figured it out, maas build depends on python-django and doesn't set a min version requirement as maas 1.4 needs at least django 1.4 [19:51] ill file a bug with a patch [19:51] roaksoax, ^ [19:52] adam_g: yeah typo :) [19:52] or i can just do a MP [19:52] adam_g: is the module called 'version'? (a2enmode version) [19:52] roaksoax, yeah [19:52] stokachu, we need a bug. [19:52] adam_g: k thanks [19:52] then you can do a MP [19:53] smoser: i think we can drop the build-dep in python-django [19:53] but we have to have a bug at this point in the ubuntu cycle [19:53] roaksoax, id ont follow. stokachu is explicitly stating we need runtime depends (i think) [19:53] smoser: ok ill create it too [19:53] bug that is [19:54] 15:54 < stokachu> smoser: figured it out, maas build depends on python-django and doesn't set a min version requirement as maas 1.4 needs at least django 1.4 [19:54] GenericIPAddressField was introduced in django 1.4 [19:54] roaksoax, yeah, how would we drop the build-dep ? i'm confused. [19:55] smoser: we don't really build anything (binaries and such) [19:55] you could remove a 'Build-Depends' possibly, but who cares. the problem is that we are missing a 'Depends' [19:56] well, roaksoax generally speaking i think the "best practice" is to build-depends on everything you Depends on and run 'make test' and use dh-python magic to determine your runtime depends wherever you can. [19:56] smoser: we are missing versioning, not a depends [19:56] right. [19:56] so how would dropping a build-depends change anything. [19:57] smoser: http://paste.ubuntu.com/6206456/ [19:57] makes sense? [19:57] roaksoax: yea that works [19:59] roaksoax, is it 'maas-region-controller' that depends on it? or is it python-django-maas. [19:59] i suspect the first, but just checking. [19:59] smoser: the first one [19:59] k. then that change sems to make sense to me. [20:04] smoser: https://code.launchpad.net/~andreserl/maas/packaging_lp1236544/+merge/189694 [20:04] https://code.launchpad.net/~andreserl/maas/lp1236544/+merge/189692 [20:04] all yours [20:05] roaksoax, you need the packaging change alos [20:05] right? [20:05] to enable the config mod [20:05] smoser: i did that already, check both MP's [20:05] oh i see. [20:05] :) [20:05] sorry [20:05] :) [20:05] no worries [20:05] but you need sconklin's bug number for your debian/control change [20:05] release team will want the bug number [20:06] smoser: ?? [20:06] oh. sorry. [20:06] stokachu: what's the bug number [20:06] stokachu's bug [20:06] adam_g: what did you install to get the version module: [20:06] roaksoax@pursue:/etc/openvpn$ sudo a2enmod version [20:06] ERROR: Module version does not exist! [20:06] i need to create the bug [20:07] lemme do that right now [20:09] roaksoax: 1236572 [20:10] stokachu: thank you sir! [20:10] roaksoax: np :D [20:11] guys I can understand that you don't want to deal with apparent errors in the documentaion - in the meantime I filed a bug report - but it would have been nice if someone had said so :-) [20:12] guntbert: did you associate an MP with it? [20:13] stokachu: MP? [20:13] guntbert: a merge proposal with the documentation changes [20:13] guntbert, i personally don't agree with bigjools' statement there. [20:13] stokachu: yep [20:14] roaksoax, i didn't install anything to have that module available [20:15] adam_g: weird... I don't seem to have it [20:16] no, I didn't have any proposal yet, atm I am just trying to follow some guide and stumbled over that discrepancy - anyway the bug I filed is #1236571 [20:17] guntbert: cliking import boot images really just shells out to maas-import-pxe-files [20:18] afaics [20:19] stokachu: I see, so the instructions still apply - and it was only a misunderstanding [20:19] guntbert: i think you have a valid bug [20:19] guntbert: just needs some better wording on the docs is all [20:20] adam_g: ok that module seems to be available in precise but not in suacy [20:20] smoser: ^^ [20:21] stokachu: well there are always the same problems with docs for a fast moving project :-) [20:21] guntbert: agreed -- i recently fixed a few just a few days ago [20:21] roaksoax, really? [20:21] y [20:21] what is the module name ? [20:21] smoser: version [20:21] smoser: you give it a try to see im not crazy [20:22] package ? [20:22] the package has to a2enmod version if 2.2 is installed. For 2.4, we will compile mod_version in statically. [20:23] have a nice time - bed time here :-) [20:29] roaksoax, so you ahve a fix? [20:29] who is "we" ? [20:29] i'm confused [20:31] smoser: i read that somewhere [20:32] smoser: i don't have a fix yet [20:32] smoser: we should probably be carrying a delta otherwise [20:32] smoser: https://wiki.debian.org/Apache2Transition#Should_we_support_a_transitional_fallback_configuration_which_allows_web_apps_to_work_with_both_2.2_and_2.4_packages [20:33] roaksoax, you should only need to 'a2enmod version' from postinst if running apache2.2 [20:34] https://wiki.debian.org/Apache/PackagingFor24 has a good example for detecing that from postinst [20:38] adam_g: ok so this should be it: http://paste.ubuntu.com/6206625/ [20:38] smoser: http://paste.ubuntu.com/6206625/ [20:41] roaksoax, looks reasonable [20:42] smoser: https://code.launchpad.net/~andreserl/maas/packaging_lp1236544/+merge/189694 [20:43] adam_g: ty [20:45] roaksoax, alternatively you just dont care if the a2enmod fails [20:45] right? [20:47] smoser: better? http://paste.ubuntu.com/6206668/ [20:47] well, thats not really waht i was saying. [20:47] yours is fin ei thikn [20:48] i was saying you can just only 'a2enmod version || true' [20:48] on apache2 it runs fine. [20:48] errr on 2.2 tha tworks [20:48] on 2.4 it will fail, but you dont care [20:53] smoser: right [20:53] smoser: either way works i guess [20:57] smoser: do you want me to change it? [20:59] yours is fine. i think. [20:59] if you've tested it. [21:06] smoser: i haven't [21:07] alright. i have to run for a couple hours. ill be in later. [21:09] smoser: k enjoy! [21:09] roaksoax, thanks for your work on this. [21:09] smoser: np === CyberJacob is now known as CyberJacob|Away [22:43] smoser: i think maas-signal or maas are broken :/ [22:43] o/ roaksoax [22:43] bigjools: howdy [22:44]