| roaksoax | jtv: around yet? | 03:12 |
|---|---|---|
| roaksoax | smoser: ubuntu releases support works successfully :D | 03:25 |
| bigjools | roaksoax: \o/ | 04:11 |
| jtv | Hi roaksoax -- sorry I missed you | 05:15 |
| jtv | bigjools: "seeing if an object exists" in omshell will complicate our code, in that we need to send partial input, evaluate output, then decide what input to send next. My original delete-first approach looks much simpler. | 06:07 |
| bigjools | jtv: it is also racy | 06:08 |
| bigjools | it;s really not hard to check first | 06:08 |
| bigjools | two lines of omshell | 06:08 |
| jtv | The omshell part is easy. See above. | 06:08 |
| jtv | Wait, I have an idea. | 06:09 |
| jtv | But it's ugly. | 06:09 |
| bigjools | it's all easy | 06:09 |
| bigjools | I don;t understand your reticence | 06:09 |
| bigjools | but perhaps I am missing something you've seen | 06:09 |
| jtv | Well there's no conditionals in omshell. | 06:10 |
| jtv | So we can't keep sending one chunk of omshell code the way we're doing. | 06:10 |
| bigjools | you don't need to do it all in omshell | 06:10 |
| jtv | That's what I'm saying. | 06:10 |
| jtv | If we want to check first, we can't keep sending one chunk of omshell code the way we're doing. | 06:11 |
| bigjools | so what's the problem with that? | 06:11 |
| bigjools | you run it once and then possibly again | 06:11 |
| jtv | That we've been patching omshell a lot in tests. | 06:11 |
| jtv | I can give it a try. It's definitely not impossible, just breaking something we've been making assumptions about. | 06:13 |
| bigjools | I can't see why it won't work, although it will require more mocking for tests | 06:14 |
| jtv | It's definitely not impossible. | 06:15 |
| bigjools | I guess that's the best I can get out of you :) | 06:15 |
| jtv | It's something I've been noticing this week: a lot of communication has been breaking down. | 06:15 |
| jtv | All I wanted to say is: we've been making a lot of assumptions about how we run omshell, and so this change may involve a lot of test changes. That's the reason for my reticence. I can try it, but I needed to discuss alternatives first. | 06:17 |
| bigjools | ok | 06:17 |
| bigjools | let's reqind | 06:17 |
| bigjools | rewind even | 06:17 |
| jtv | rescind? | 06:17 |
| bigjools | maybe :) | 06:18 |
| jtv | remind. | 06:18 |
| bigjools | the error message that you check for, let's see if you can make it appear for other scenarios | 06:18 |
| bigjools | if it doesn't, then your original code is good IMO | 06:18 |
| bigjools | what other scenarios? comms fail, syntax error, etc | 06:18 |
| jtv | fsetpos failure in a trace file. | 06:19 |
| jtv | (Seriously! I have no idea why that generates that same error) | 06:19 |
| bigjools | whut? | 06:20 |
| jtv | Yeah. :( | 06:20 |
| bigjools | no, I mean what are you doing, I don't understand | 06:20 |
| jtv | I went through the dhcp source to find other things that might generate this same error. | 06:20 |
| jtv | And there were a few, in code paths that I _think_ we're not exercising. | 06:21 |
| bigjools | ok | 06:21 |
| jtv | I have one thing I can try. | 06:21 |
| jtv | Hi rvba! | 06:21 |
| bigjools | if that's the case we are probably safe | 06:21 |
| rvba | Hi jtv, hi bigjools. | 06:21 |
| bigjools | however, did you check what errors omshell generates itself? | 06:22 |
| bigjools | morning rvba | 06:22 |
| jtv | bigjools: yes, I did — it's all the same codebase, so I just grepped the whole thing. | 06:22 |
| bigjools | ah ok | 06:22 |
| bigjools | jtv: in that case you have convinced me that your existing change is good | 06:23 |
| bigjools | does it work in practice? | 06:23 |
| jtv | When I tried it manually in omshell, yes. | 06:23 |
| bigjools | cool | 06:23 |
| jtv | I appreciate your critical probing; I wish I could give easy absolute certainties about that codebase. :/ | 06:23 |
| bigjools | yeah I know :/ | 06:24 |
| bigjools | glad you appreciate it, not trying to be difficult, honest! | 06:24 |
| jtv | "Uh, trying?" :) | 06:24 |
| bigjools | :p | 06:24 |
| jtv | It's good code for its era, actually. Clay pots, numeric error codes... | 06:25 |
| jtv | Makes me appreciate python all the more. | 06:25 |
| === lifeless_ is now known as lifeless | ||
| jtv | roaksoax: I've got a change up for review that will manage the discussed extension to dhcpd's apparmor profile. We'll have to run that when we set up our dhcpd, and direct its output into /etc/apparmor.d/local/usr.sbin.dhcpd | 11:20 |
| jtv | roaksoax: Still have to set up the custom dhcpd instance though, with its own config file etc. | 11:37 |
| smoser | jtv, are you there? | 12:13 |
| smoser | so, thinking about apparmor | 12:14 |
| smoser | is there any reason that maas should write that ? rather than packaging? | 12:14 |
| smoser | the reason i ask is that I think it might just be easier all around if | 12:14 |
| jtv | hi smoser | 12:14 |
| smoser | a.) in precise, we add 1 line in packaging to the local/usr.sbin.dhcpd that says "include /etc/maas/apparmor.d/usr.sbin.dhcpd" or the like | 12:15 |
| smoser | b.) in quantal apparmor.d we get such a thing included. | 12:15 |
| jtv | Sure, if you can swing it, for both precise and quantal. | 12:15 |
| smoser | ie, in quantal we'll modify usr.sbin.dhcpd profile to have that include. | 12:15 |
| smoser | then maas packaging can write the file in both cases. the only difference is we have to update that local file in precise. | 12:16 |
| smoser | it just seemed strange to write it in maas source code. its really packaging that caused this pain :) | 12:16 |
| jtv | Ohhh, right, I see. | 12:16 |
| jtv | Well the maas code is only to manage the extension to the local file. | 12:17 |
| smoser | right. but even that seems wierd. | 12:17 |
| jtv | It could easily contain just the #include. | 12:17 |
| smoser | i dont want to stop this from moving forward. | 12:17 |
| smoser | but that seemed a bit less in trusive | 12:17 |
| smoser | and it really seems wierd to me to have a daemon writing apparmor config | 12:18 |
| jtv | Either way it's going to be done in packaging, of course. | 12:18 |
| smoser | interesting... | 12:18 |
| smoser | if there were an apparmor profile for maas | 12:18 |
| smoser | it probably would *not* allow it to write/modify files in /etc/maas/apparmor.d | 12:18 |
| jtv | It's not the daemon writing there — it's just a piece of python that the installation scripts can call. | 12:18 |
| smoser | because if it did... that'd be like allowing full exploit and defeat of apparmor | 12:18 |
| smoser | hm.. | 12:19 |
| smoser | oh well. | 12:19 |
| smoser | i think i'll just table my thoguhts for now. | 12:19 |
| jtv | At this point, I'd rather have them soon so I can move forward a bit more before the night is over! | 12:20 |
| jtv | Er... did that come out weird? | 12:20 |
| jtv | What I mean is, I'm hoping to get a bit more done tonight. | 12:21 |
| smoser | me too | 12:23 |
| jtv | So I'd very much like these thoughts resolved. | 12:23 |
| jtv | smoser: if you feel the approach is wrong, it's better if you say so now than to wait until we're committed. If you feel it's OK to append and #include to the local apparmor file, without managing custom settings in there, I can scuttle my branch to support the latter. | 12:29 |
| smoser | i think for precise we have to modify that file (the local) | 12:30 |
| smoser | there is no other way. | 12:30 |
| jtv | Agreed. But how do we modify it? | 12:30 |
| smoser | i think if it works, it makes sense to reduce your management of a common file | 12:30 |
| smoser | by using "#include" | 12:31 |
| smoser | right? | 12:31 |
| jtv | Right. | 12:31 |
| jtv | I just didn't want to assume that we can just append that to the file and never look back. | 12:31 |
| smoser | right | 12:31 |
| jtv | For example, we don't want to leave a broken #include around after you purge the config. | 12:31 |
| smoser | yeah, i dont know how it handles that. and packaging on removal would have to handle removal of that if missing files cause apparmor to choke | 12:32 |
| smoser | roaksoax, what do you think ? | 12:32 |
| smoser | it seems more proper to me for packaging to basically handle apparmor | 12:33 |
| jtv | FWIW with my code it'd be easy to disable that bit we add. | 12:33 |
| jtv | Packaging scripts would _call_ my code, obviously. | 12:33 |
| smoser | well, they could, yeah. | 12:36 |
| smoser | i'll wait to see what roaksoax thinks. | 12:36 |
| jtv | OK | 12:36 |
| smoser | it really does to me seem like packaing's problem. | 12:36 |
| jtv | Yes — I'm just providing a tool for it to use. | 12:36 |
| jtv | smoser: I'm going to go out for dinner now. I may be some time. | 12:51 |
| roaksoax | smoser: i'm fine with that, is the same thing done with bind | 14:03 |
| roaksoax | jtv: is the change in question make the change in the apparmor profile, or will we have to do it (in packaging)? | 14:04 |
| roaksoax | rvba: around? | 14:04 |
| roaksoax | rvba: let me know when around | 14:36 |
| rvba | roaksoax: I'm there but I'm otp | 14:45 |
| roaksoax | rvba: ok, no worries, let me know when you're done :) | 14:46 |
| smoser | ok. | 14:57 |
| smoser | i have a thoguht. | 14:58 |
| smoser | thell me how stupid this is. | 14:58 |
| smoser | in commissioning environment (and enlistment) | 14:58 |
| smoser | there is basically no way in to the image. | 14:58 |
| smoser | and when it fails, its a PITA to debug | 14:58 |
| smoser | so i'm thinking i will do: | 14:58 |
| smoser | if we take the failure case... | 14:58 |
| smoser | right now we print a message, sleep 60 seconds, poweroff | 14:59 |
| smoser | instead, we could | 14:59 |
| smoser | enable a password (possibly random), give a message, and say "if you do not login in the next X seconds, you will be powered off" | 14:59 |
| roaksoax | smoser: yeah that could work for debugging purposes | 15:01 |
| roaksoax | smoser: so, during enlistment, I waas thinking how to we chose what release to use? | 15:02 |
| smoser | http://paste.ubuntu.com/1190988/ | 15:09 |
| smoser | roaksoax, what do you mean choose? | 15:09 |
| roaksoax | smoser: so, while working on adding other ubuntu releases support | 15:13 |
| roaksoax | smoser: enlistment now requires you to tell what release to use for the enlisted system | 15:13 |
| roaksoax | smoser: so, how can we effectively chose what ubuntu releaswe to use | 15:13 |
| smoser | i'm confused. | 15:14 |
| smoser | you mean as in which ephemeral image to boot ? | 15:14 |
| roaksoax | smoser: no, it will boot in precise ephemeral image | 15:14 |
| roaksoax | smoser: but when you enlist the node itself | 15:15 |
| smoser | ok (that is a separate issue) | 15:15 |
| smoser | you're saying when i enlist a system, i have to chose the operating system that will be installd on it? | 15:15 |
| smoser | that is broken | 15:15 |
| smoser | badly broken | 15:15 |
| roaksoax | smoser: yes and no (that's one of the things I want to discuss with rvba) | 15:15 |
| roaksoax | smoser: but, as it stands now, I need to specify the ubuntu release to use | 15:16 |
| melmoth | random question of the day: if iwas to deploy a nova-compute servoce on the node running zookeeper (just for the sake of not wasting hardware), would i regret it ? | 15:56 |
| rvba | roaksoax: all right, I'm there. Sorry for the delay. | 16:02 |
| roaksoax | rvba: no worries :) | 16:02 |
| roaksoax | rvba: ok so basically, the problme is that during enlistment we don't have to specify a release, but we always want it to set one by default | 16:03 |
| roaksoax | rvba: so in modes/node.py I did this: | 16:04 |
| roaksoax | os_release = CharField( max_length=10, choices=UBUNTU_RELEASE_CHOICES, blank=False, default=UBUNTU_RELEASE.precise) | 16:04 |
| roaksoax | which means that it should never be blank basically | 16:04 |
| roaksoax | right? | 16:04 |
| roaksoax | now, in forms.py I initially had this: | 16:05 |
| rvba | right | 16:05 |
| roaksoax | os_release = forms.ChoiceField( choices=UBUNTU_RELEASE_CHOICES, required=False, initial=UBUNTU_RELEASE.precise, error_messages={'invalid_choice': INVALID_UBUNTU_RELEASE_MESSAGE}) | 16:05 |
| roaksoax | err | 16:05 |
| rvba | Note that 'blank' is purely validation-related. | 16:05 |
| roaksoax | s/False/True | 16:05 |
| roaksoax | so I had the above with s/False/True, then enlistment failed because we were not specifying the releas | 16:05 |
| roaksoax | eso I changed it to required=False, and then enlistment no longer complained about not specifying release | 16:06 |
| roaksoax | but there was this: | 16:06 |
| roaksoax | ValidationError: {'release': [u'This field cannot be blank.']} | 16:06 |
| roaksoax | which means it was related to the blank=False | 16:06 |
| rvba | yep | 16:06 |
| roaksoax | so my question is, shouldn't the initil= and/or default= have set the release? | 16:06 |
| rvba | Well, that is indeed confusing stuff in Django. | 16:08 |
| rvba | The initial=xxx stuff let's you create a form with initial values. | 16:08 |
| rvba | As in an HTML form. | 16:08 |
| rvba | but that's all it will do. | 16:08 |
| rvba | So in the API were we're simply using forms for validating stuff, that won't be taken in to account. | 16:09 |
| roaksoax | rvba: right, but what about the default= on node.py | 16:10 |
| roaksoax | rvba: or better yet, how do you think this problme should be addressed? | 16:10 |
| rvba | roaksoax: the form should be responsible for setting the default. Let me find an example. | 16:11 |
| rvba | roaksoax: if you look at WithMACAddressesMixin which is a mixin used to extend node-adding forms, you'll see that in save(), we set the default hostname if the one provided is the empty string. | 16:13 |
| rvba | roaksoax: that's in src/maasserver/forms.py | 16:13 |
| roaksoax | rvba: right, that's exactly where I ws looking | 16:14 |
| roaksoax | rvba: but then again, that's particularly for mac address isn't it? | 16:14 |
| rvba | roaksoax: yes | 16:14 |
| rvba | roaksoax: shouldn't the default come from a global config setting? | 16:14 |
| rvba | Rather than being hardcoded I mean. | 16:15 |
| roaksoax | rvba: yeah but if we do that, someone can simply set a non-supported release | 16:15 |
| roaksoax | rvba: but for now I'm just doing a first step | 16:15 |
| roaksoax | on getting this to work | 16:15 |
| roaksoax | rvba: and thinking that the default should be "precise" | 16:15 |
| rvba | The setting could be a dropdown menu with only the valid options. | 16:16 |
| roaksoax | rvba: right, that's what it is | 16:16 |
| rvba | So only supported releases would be in there right? | 16:16 |
| roaksoax | rvba: yes | 16:16 |
| roaksoax | rvba: everything seems to be working as expected but enlistment | 16:16 |
| roaksoax | rvba: so that's why I was wondering where should a default value be set | 16:17 |
| rvba | roaksoax: also, maybe you should allow Null value in there. If this field is null, then is means to use the default distrib. | 16:18 |
| rvba | s/distrib/release/ | 16:18 |
| roaksoax | rvba: os_release = CharField( | 16:18 |
| roaksoax | max_length=10, choices=UBUNTU_RELEASE_CHOICES, null=True, | 16:18 |
| roaksoax | blank=True, default=UBUNTU_RELEASE.precise) | 16:18 |
| rvba | If someone changes the default release, then all the nodes without a specific release set will use the new default transparently. | 16:18 |
| roaksoax | rvba: right, so that would technically fix it? | 16:20 |
| rvba | roaksoax: yes. | 16:20 |
| rvba | roaksoax: but I would be in favor of default=None | 16:20 |
| roaksoax | rvba: http://pastebin.ubuntu.com/1191126/ | 16:20 |
| rvba | Then if you want to change the default, change the global setting. | 16:21 |
| roaksoax | rvba: but default=None is no release being set | 16:21 |
| roaksoax | rvba: meaning the node will have os_release = None | 16:21 |
| roaksoax | rvba: each node should have a release | 16:22 |
| roaksoax | it is just as the architecture | 16:22 |
| rvba | roaksoax: yeah, and we would simply add a small get_os_release method which would return the default setting in that case. | 16:22 |
| roaksoax | IMHO | 16:22 |
| rvba | That method would be used to decide which release should be used. | 16:22 |
| roaksoax | rvba: that would be in node.py? | 16:22 |
| rvba | roaksoax: yes, soemthing like http://paste.ubuntu.com/1191129/ | 16:23 |
| rvba | s/get_or_release/get_os_release/ | 16:24 |
| roaksoax | rvba: right, ok cool, I'll first test the null change stuff and see what happens and then will look into the rest | 16:24 |
| rvba | roaksoax: ok | 16:25 |
| roaksoax | rvba: thought, default should probably be distro-info --stable | 16:25 |
| roaksoax | rvba: that's what I was thinking to do instead of UBUNTU_RELEASE.precise | 16:25 |
| roaksoax | to simply use UBUNTU_RELEASE.default = distro-info --stable | 16:26 |
| rvba | roaksoax: we can initialize it with that but then if we make it a configuration option it will be in the hands of the user. | 16:26 |
| roaksoax | rvba: right, ok so I'll first get this working | 16:26 |
| roaksoax | and then we can improve the default release | 16:26 |
| roaksoax | and setting option | 16:27 |
| rvba | Sounds like a plan. | 16:27 |
| roaksoax | rvba: btw.. preseed.py would look similar too: http://paste.ubuntu.com/1191157/ (i need to updated it first though) | 16:33 |
| rvba | roaksoax: makes sense. | 16:36 |
| roaksoax | rvba: where does the dev inst/home/roaksoax/Desktop/project/maas-whole/maas/bin/maas createsuperuser | 16:48 |
| roaksoax | sorry | 16:48 |
| roaksoax | errr | 16:48 |
| roaksoax | rvba: one more thing, when I click on "Add Node" on the WebUI I can't see the ubuntu release options, but I can when editing the node | 16:52 |
| roaksoax | rvba: where is that? | 16:52 |
| rvba | roaksoax: the js code uses ./src/maasserver/templates/maasserver/snippets.html to create that form | 16:53 |
| roaksoax | rvba: so that should also be updated then? | 16:53 |
| rvba | roaksoax: yes | 16:53 |
| roaksoax | rvba: ok good to know | 16:53 |
| roaksoax | rvba: and what about the label it will use, it shoes as "Os release" | 16:54 |
| roaksoax | and I'd like to use just "release" | 16:54 |
| rvba | roaksoax: use label="xx" on the CharField | 16:54 |
| roaksoax | rvba: ok cool thanks | 16:55 |
| rvba | np | 16:55 |
| roaksoax | rvba: so that also needs a migration? | 16:59 |
| roaksoax | or needs ot be part of the migration | 17:00 |
| rvba | roaksoax: if you're changing a model, then there is a migration. I recommend having one migration per change. | 17:00 |
| roaksoax | rvba: gotcha, thenaks | 17:01 |
| roaksoax | rvba: so do yo think it is a good idea to UBUNTU_RELEASE.default be obtained form a setting and then use that instead? | 17:43 |
| rvba | roaksoax: it allows someone to 'upgrade' the default used without having to mass-change the onfirmation stored on the nodes themselves so yeah, I think that's a good idea. | 17:48 |
| roaksoax | rvba: ok cool | 17:50 |
| tsandall | I created a VirtualBox VM and enlisted with my MAAS server. The node shows up as Declared on the MAAS 'nodes' page. When I try to boot the VM for the first time though it acquires a DHCP lease, and it looks like PXE starts before hitting an error: "Boot sector signature not found" and then dropping to a boot: prompt. | 20:27 |
| tsandall | the pxelinux.cfg filef for the VM's MAC doesn't reference any of the precise images, instead it's referencing chain.c32, is that correct? | 20:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!