| roaksoax | bigjools: howdy!! quickly on the squashfs. 1. THere are no precise squashfs images | 03:06 |
|---|---|---|
| roaksoax | bigjools: 2. I don't mind changing to a different path, though the current start of maas-provision wouldn't; allow to install them in the correct path | 03:07 |
| roaksoax | bigjools: i wanted to serve these through tftp, but there's a bug in the tftp server that doesn't allow to download more than 32mbs | 03:07 |
| roaksoax | bigjools: but allenap said it was decided that it wasn't something important to address for 12.10 | 03:08 |
| * roaksoax gone | 03:08 | |
| === bigjools-afk is now known as bigjools_ | ||
| Daviey | bigjools_: did you see roaksoax's comment? | 06:02 |
| Daviey | (before you pinged out?) | 06:02 |
| bigjools_ | Daviey: I didn't ping out but I did start using a different machine. And no I didn't see it. | 06:03 |
| bigjools_ | good morning BTW | 06:03 |
| Daviey | morning' | 06:03 |
| Daviey | bigjools_: as yes, sorry.. misread | 06:03 |
| Daviey | 04:06 < roaksoax> bigjools: howdy!! quickly on the squashfs. 1. THere are no precise squashfs images | 06:03 |
| Daviey | 04:07 < roaksoax> bigjools: 2. I don't mind changing to a different path, though the current start of maas-provision wouldn't; allow to install them in the correct path | 06:03 |
| Daviey | 04:07 < roaksoax> bigjools: i wanted to serve these through tftp, but there's a bug in the tftp server that doesn't allow to download more than 32mbs | 06:03 |
| Daviey | 04:08 < roaksoax> bigjools: but allenap said it was decided that it wasn't something important to address for 12.10 | 06:04 |
| Daviey | 04:08 * roaksoax gone | 06:04 |
| Daviey | 05:44 -!- bigjools-afk [~quassel@60-241-216-21.static.tpgi.com.au] has joined #maas | 06:04 |
| Daviey | (i prodded the tftp issue myself, and seemed a pain.) | 06:04 |
| bigjools_ | Daviey: I feel quite strongly that we should not expose the whole TFTP tree over HTTP | 06:04 |
| Daviey | i didn't realise we were.. | 06:05 |
| bigjools_ | we aren't, but roaksoax's branch makes it so | 06:05 |
| Daviey | bigjools_: does it actually expose it, or make everything 'work' over http? Ie, does it include directory listings ? | 06:06 |
| Daviey | being able to wget, seems desirable.. directory listings seems not so nice | 06:06 |
| bigjools_ | the tftp stuff is currently nicely isolated | 06:07 |
| bigjools_ | it needs to stay that we so we can change it if we want in the future | 06:08 |
| bigjools_ | mixing in unrelated images into the TFTP tree that are not being served over TFTP is pretty nasty | 06:08 |
| bigjools_ | Daviey: what are you thinking? | 06:11 |
| Daviey | bigjools_: Well, we would be serving it purely under tftp, but the tftp server craps out at >32MB files | 06:12 |
| Daviey | so, using http as an alternative. | 06:12 |
| bigjools_ | Daviey: I know :/ | 06:12 |
| Daviey | I mean,http could go away, when tftp is fixed. | 06:13 |
| Daviey | but it does seem quite desirable to support http.. or certainly ftp. | 06:13 |
| Daviey | unrelated, pxe-kexec supports ftp as a alliterative to tftp | 06:14 |
| Daviey | alternative* | 06:14 |
| Daviey | I agree that directory listings, should probably not be exposed in either case. | 06:14 |
| bigjools_ | ok | 06:15 |
| bigjools_ | I'll compromise then, if we remove directory listings | 06:15 |
| Daviey | sounds good | 06:16 |
| bigjools_ | I am nothing if not flexible | 06:17 |
| Daviey | I've seen the videos. | 06:17 |
| bigjools_ | =o= | 06:19 |
| rbasak | allenap: do we keep HTTP response code constants in a convenient module somewhere? | 11:18 |
| bigjools | rbasak: httplib | 11:19 |
| mgz | rbasak: there all in htt... bigjools wins | 11:19 |
| bigjools | \o/ | 11:20 |
| rbasak | bigjools, mgz: thanks! | 11:20 |
| allenap | rbasak: They're all in... ug. | 11:28 |
| Daviey | rbasak: Yeah, you can find them in.. Oh. | 11:32 |
| Daviey | (felt left out) | 11:32 |
| rbasak | rbasak: they're in httplib you muppet! | 11:32 |
| bigjools | :) | 11:55 |
| roaksoax | bigjools: around? | 12:59 |
| bigjools | rbasak: I am | 13:00 |
| bigjools | argh | 13:00 |
| bigjools | roaksoax: I am | 13:00 |
| roaksoax | bigjools: howdy! hehe | 13:00 |
| bigjools | roaksoax: loads of bugs! | 13:00 |
| bigjools | see email to -devel list | 13:01 |
| roaksoax | bigjools: so I saw the sqaushfs comments, how is that directory listing should be hidden? | 13:02 |
| roaksoax | bigjools: as in, you cannot http://MAAS_server/MAAS/images/amd64 | 13:02 |
| bigjools | roaksoax: turn off the apache option to show directory listings | 13:02 |
| bigjools | requires direct navigation then | 13:02 |
| roaksoax | bigjools: as in, you cannot http://MAAS_server/MAAS/images/amd64 ->> you cannot access anything, but it shows page doesn't exist | 13:03 |
| bigjools | roaksoax: sorry I am not following you | 13:03 |
| roaksoax | bigjools: i mean, if you browse "http://MAAS_server/MAAS/images/amd64" for example, no directory listing is provided | 13:06 |
| roaksoax | bigjools: which is why i was asking, is that what you meant about disabling directory listings? | 13:06 |
| bigjools | roaksoax: It was, yes | 13:06 |
| roaksoax | bigjools: right, so instead, MAAS shows a message that page doesn't exist | 13:07 |
| roaksoax | bigjools: but no directory listing is provided | 13:07 |
| roaksoax | bigjools: btw.. did you confirm that a rogue celery is running? on package uninstallation maas-celery.upstart will remain *but* it will be stopped before the package gets removed | 13:08 |
| bigjools | roaksoax: when I reboot there is a rogue celery | 13:09 |
| bigjools | and the config file lives on | 13:09 |
| roaksoax | bigjools: the config file lives because the package, on upgrade, is removed, not purged | 13:10 |
| bigjools | right :/ | 13:10 |
| bigjools | so we need some custom stuff? | 13:10 |
| roaksoax | bigjools: No, we shouldn't need custom stuff. Upstart should not start the package as the init script should be disabled | 13:11 |
| roaksoax | bigjools: oh btw... we need to change the approach how we handle config files | 13:11 |
| bigjools | roaksoax: how does it get disabled? | 13:11 |
| jam | bigjools: when I do 'make run' and ^C I have a maas-provisioner left running, I wonder if that is related to some of the issues you saw | 13:11 |
| roaksoax | bigjools: packaging should do that automatically | 13:12 |
| bigjools | roaksoax: it didn't happen though :( | 13:12 |
| bigjools | jam: no that's a separate bug | 13:13 |
| bigjools | but thanks for pointing it out :) | 13:13 |
| jam | bigjools: ah k. | 13:13 |
| jam | I ran into it as 'cannot make run' because it hangs if the old process doesn't shutdown. | 13:14 |
| bigjools | darn - perhaps one of my guys can fix that | 13:14 |
| roaksoax | bigjools: I think adding Conflicts/Replaces <= maas XYZ would fix the issue | 13:20 |
| roaksoax | bigjools: for maas package itself | 13:20 |
| roaksoax | bigjools: so it forces the removal of 'maas' binary before installing the new one | 13:20 |
| bigjools | roaksoax: right | 13:21 |
| roaksoax | bigjools: so, i need to discuss this with you | 13:21 |
| roaksoax | bigjools: we need to change the approach how config files are being handle | 13:21 |
| bigjools | ok | 13:21 |
| roaksoax | bigjools: as per policy, we shouldn't not be modifying conffiles | 13:21 |
| roaksoax | bigjools: even though we did that in precise, we need to stop doing that for quantal | 13:22 |
| roaksoax | bigjools: there's a few alternatives | 13:22 |
| roaksoax | bigjools: 1. is to stop treating config files as conffiles for packaging purposes. Say, we for example can ship files under /usr/share/maas/confs and then copy the packaging over /etc/maas/ and make the modifications | 13:23 |
| roaksoax | bigjools: that way, on upgrade, the file will be automatically overwritteng and new custom configs will be generated | 13:23 |
| roaksoax | bigjools: that causes that, if the user makes a modification, then they won't be preserved | 13:23 |
| bigjools | that's not nice :( | 13:24 |
| roaksoax | 2. the second option is to ship the config files in a different location, make the package modify those new files, and add new config files in /etc/maas that are *only* meant to be modified by the user | 13:24 |
| roaksoax | this would be similar to what we do with maas_local_settings.py and settings.py | 13:25 |
| roaksoax | however, instead of modifying automatically maas_local_settings.py we would need to modify settings.py, and leave maas_local_settings.py to be modified by the user only | 13:25 |
| roaksoax | in the event they modify the file, on upgrade it will be asked whether they want to isntall the new config file or not, if they decide not to, we hsould still make the customizations in the initial settings.py | 13:26 |
| roaksoax | (that's an example of course) | 13:26 |
| roaksoax | this however, does not cover *.yaml files for the daemons | 13:26 |
| roaksoax | 3. add support for .d/ to the config files, so we ship a base conffile, and the modifications we do are placed under a .d/ | 13:27 |
| roaksoax | 4. (which could go with any of the options above), would be to put the passwords in a different file, such as etc/maas/passwds, and source those files that need them | 13:28 |
| bigjools | what is the reason for this policy? | 13:29 |
| roaksoax | bigjools: the only big blocker i see here is the *yaml files for the daemons, since we manually specify what config file to use | 13:29 |
| roaksoax | bigjools: basically, it can leave you with a broken system. So only users should modify conffiles, rather than package | 13:30 |
| bigjools | so basically no "sed -i" ? | 13:30 |
| roaksoax | bigjools: Note that a package should not modify a dpkg-handled conffile in its maintainer scripts. Doing this will lead to dpkg giving the user confusing and possibly dangerous options for conffile update when the package is upgraded. | 13:30 |
| roaksoax | that's what policy says | 13:30 |
| bigjools | what about removing the files from dpkg's list of installed files? | 13:31 |
| roaksoax | bigjools: 10.7 expalins this: http://www.debian.org/doc/debian-policy/ch-files.html | 13:35 |
| roaksoax | bigjools: we can do that, which is what option 1 or 2 try to achieve partly | 13:35 |
| roaksoax | bigjools: when you install in etc/ they are treated by conffiles, if you install them elsewhere, they are not, and if modified, they will be overwritten in an upgrade | 13:36 |
| bigjools | ok | 13:36 |
| roaksoax | bigjools: so we remove them form dpkg's list of conffiles | 13:36 |
| roaksoax | bigjools: we can simply do that, but then we would have to overwrite the config file each time we upgrade | 13:36 |
| roaksoax | bigjools: and user will lose any custom settings | 13:37 |
| roaksoax | bigjools: we can display a message an say that the file was overwritten in let the user know that they should merge their changes if any | 13:37 |
| roaksoax | bigjools: and preverse a copy | 13:37 |
| bigjools | so many options at 23:38 at night | 13:39 |
| roaksoax | bigjools: indeed, we need to digest them and start working on them | 13:41 |
| roaksoax | so we can do that tomorrow | 13:41 |
| roaksoax | bigjools: for for the .py, we can simply install them in /usr/share/maas/ and symlink to etc/maas/, and packaging would modify files directly in /usr/share/maas | 13:44 |
| jam | mgz: I just chatted with Francis, essentially rather than trying to do migration via South, just having a simple 'here is a script that will migrate the data' is reasonable for 12.10. And I think that script is essentially 1 line of SQL. So it isn't the first thing we want to do, but when we get to it, it should be pretty straightforward. | 13:44 |
| jam | mgz, jelmer: the first priority is to get async building of the node_tags table working (that allows much better scaling stories) | 13:45 |
| jam | and then search | 13:45 |
| jam | which I'll talk to huw tomorrow about. | 13:45 |
| jelmer | jam: okay | 13:45 |
| mgz | ...it would be nice is south actually worked though... | 13:46 |
| bigjools | roaksoax: ok I'm dead beat here, it might be useful if you summarise in an email and we can look at it later | 13:47 |
| mgz | this is at least quite amienable to just being done as a short update script | 13:47 |
| roaksoax | bigjools: i will be around tongight so we can discuss it then | 13:48 |
| bigjools | ok | 13:48 |
| smoser | ok. just a hint for anyone watching rsyslog logs on the maas server | 14:00 |
| smoser | (which are sent during install of a node) | 14:00 |
| smoser | pid=$(pidof rsyslogd); while date -R && sleep 5; do sudo kill -HUP $pid || break; done | 14:01 |
| smoser | basically, rsyslog buffers log files | 14:01 |
| smoser | so if you dont tell it to flush the logs, your 'sudo tail -f /var/log/maas/rsyslog/192.168.77.58/2012/10/01/messages' is going to look like its not doing anything. | 14:02 |
| jam | mgz: it would be nice if it 'just worked' but if you have to pass special flags to the upgrade, it is going to be a bit hard to just do it in the packaging. So having a separate script should be really straightforward in comparison. | 14:05 |
| roaksoax | allenap: howdy | 15:07 |
| rbasak | smoser: hey, is there a plan for BOOTIF_DEFAULT at the moment? | 15:07 |
| allenap | roaksoax: Hello. | 15:07 |
| rbasak | roaksoax: what's the current schedule for the maas-enlist SRU, please? | 15:07 |
| smoser | rbasak, it shoudl be there now. in the dialy images (not sure about the released) | 15:08 |
| rbasak | smoser: awesome! | 15:08 |
| smoser | i just have to start passing it in maas | 15:08 |
| rbasak | smoser: so BOOTIF_DEFAULT=eth0 (case sensitive)? | 15:08 |
| roaksoax | allenap: so I wanted to talk about the comments on the proposed branch | 15:08 |
| smoser | rbasak, yes, case matters in unix | 15:08 |
| roaksoax | allenap: what do you mean by [1] symlinking | 15:08 |
| smoser | :) | 15:08 |
| roaksoax | rbasak: i'll upload today | 15:08 |
| rbasak | :) | 15:08 |
| rbasak | roaksoax: thanks! | 15:08 |
| rbasak | smoser: I'll give it a go - thanks! | 15:08 |
| rbasak | smoser: I was going to add for ARM only | 15:09 |
| smoser | right | 15:09 |
| rbasak | smoser: but thinking about it we could just add it universally without a problem | 15:09 |
| roaksoax | allenap: you actually want to symlink the preseed files? | 15:09 |
| rbasak | smoser: do you have any preference? | 15:09 |
| allenap | roaksoax: You want the same template for both i386 and amd64, so you could call it x86_... and create symlinks from i386_... and amd64_... to it. | 15:10 |
| smoser | rbasak, it would seem like we could add it globally, yes. | 15:10 |
| smoser | http://paste.ubuntu.com/1254041/ is the script | 15:10 |
| roaksoax | allenap: right, but why would you wanna do that? where do you expect that to happen? | 15:10 |
| roaksoax | allenap: i personally don't tink it would be a good idea to symlink. Maybe inherit, but not symlink | 15:10 |
| allenap | roaksoax: Okay, inherit is good too. | 15:11 |
| smoser | in theory the BOOTIF_DEFAULT is only read if BOOTIF is not provided. | 15:11 |
| roaksoax | allenap: allenap but TBH that adds complexity. | 15:12 |
| roaksoax | allenap: [2]., if squashfs_image is not defined in a template then it shouldn't really affect would it? | 15:13 |
| rbasak | smoser: and there are no plans to lose IPAPPEND at all on Intel, so I think universal would be fine. We could always move it later if necessary | 15:13 |
| rbasak | smoser: I'm just wondering if there's any conflict with biosdevname but I can't see a problem | 15:13 |
| smoser | rbasak, the way its being done now, i'm almost certain biosdevname would not affect it at all | 15:14 |
| smoser | unless the biosdevname implementation moved to early in initramfs potentially. | 15:14 |
| smoser | as it is now, the devices are left up and network/interfaces says they're "manual", meaning they dont get bounced on boot. | 15:14 |
| smoser | meaning biosdevname couldn't change their name if it wanted to | 15:15 |
| smoser | as that requires taking them down. | 15:15 |
| rbasak | ah yes of course | 15:15 |
| rbasak | We went over this. Sorry. | 15:15 |
| roaksoax | allenap: allenap hold on, back to [1], I think having a 3 level inheritance (or symlinking for that matter) adds lots of complexity. | 15:16 |
| roaksoax | allenap: on [2], the definition of self.squashfs_image is the same as what it is with self.proxy and so on, so there's shouldn't be any issues | 15:16 |
| roaksoax | allenap: now tests, you can help me with that :) | 15:17 |
| roaksoax | rbasak: btw.. now maas node.architecture is "amd64/generic" "i386/generic" and so on? | 15:17 |
| roaksoax | rbasak: or =is there a node.subarchitecture | 15:17 |
| rbasak | roaksoax: it's "amd64/generic" or "armhf/highbank" for example | 15:17 |
| rbasak | roaksoax: we wanted to do it better but django had a few limitations with derived fields | 15:18 |
| roaksoax | rbasak: right, but just wondering.... wasn't it better to simply add a node.subarchitecture attribute? | 15:18 |
| rbasak | roaksoax: it's a pain to pass it round everywhere then | 15:19 |
| rbasak | roaksoax: ideally it'd be a 2-tuple, and django would translate, but it can't do that even though sqlalchemy can | 15:19 |
| allenap | roaksoax: Re. undefined self.squashfs_image not being a problem: that's what we'd want a test for, to assert that that's the case. | 15:21 |
| roaksoax | rbasak: right. now, are we looking to have an squashfs image for arm? | 15:21 |
| rbasak | roaksoax: I have no idea. I only learnt about the squashfs thing yesterday | 15:21 |
| rbasak | roaksoax: if it doesn't go in with already with support, I don't think I'll have time to add it | 15:22 |
| allenap | roaksoax: You're right about the complexity, because Tempita's inheritance is weird. OTOH, putting too much logic in a single template gets confusing too, and prevents on-site customisation (well, at least customisation that we can upgrade gracefully with). | 15:22 |
| roaksoax | rbasak: right, so i don't mind changing the appracoh of using a subarch, however, it makes no sense doing it if we are not gonna be supporting squaqshfs for arm | 15:23 |
| allenap | roaksoax: I may not have time to help with tests until this evening, after 2000 UTC. I assume you'll still be around then? | 15:23 |
| rbasak | roaksoax: I've just spent the last few weeks removing all hardcodings of "generic". I'd really prefer not to have to do that again if we have to add support later. Can we not have code go in that understands the arch/subarch correctly even if armhf/highbank doens't work? | 15:24 |
| rbasak | roaksoax: that is, read the subarch properly instead of assuming "generic" - that's all. | 15:25 |
| roaksoax | rbasak: yeah I don't mind adapting it that way, though it will require many modifications if we ship arm squashfs root filesystems | 15:25 |
| rbasak | roaksoax: what modifications would be required? | 15:25 |
| rbasak | flacoste: it is ok to skip squashfs support on ARM? | 15:25 |
| roaksoax | rbasak: because i'm guessing that eh squashfs image would be provided in different archives, naming convention and stuff | 15:26 |
| roaksoax | rbasak: currently for quantal it might even be a temporary naming convention, etc | 15:26 |
| roaksoax | rbasak: but i'll adequate the script accordingly | 15:26 |
| roaksoax | allenap: no worries i won't work on it till later today | 15:26 |
| roaksoax | probably you'll be gone by then | 15:27 |
| rbasak | roaksoax: that makes sense and that's OK - I've had to do the same for various other ARM things | 15:27 |
| roaksoax | rbasak: so, things like this in the preseeds would need to be changed: {{if node.architecture in {'i386', 'amd64'} }} | 15:27 |
| rbasak | roaksoax: the pain is when the full arch and subarch isn't passed around internally so selectively doing the right thing becomes very hard because the predicate isn't available and I have to change how entire sections of code understand arch/subarch | 15:27 |
| rbasak | roaksoax: that needs to be in {'i386/generic', 'amd64/generic'} already | 15:28 |
| rbasak | roaksoax: or node.architecture.split('/')[0] in {'i386', 'amd64'} - I don't mind which | 15:28 |
| rbasak | roaksoax: the important thing is that the full arch/subarch detail is available at that point, so that if statement can change later without having to re-architect the call stack that led to that point | 15:29 |
| roaksoax | rbasak: ack. I';ll update my stff accordingly. Though that part is on the proxy stuff for ports.ubuntu.com | 15:29 |
| rbasak | roaksoax: ah. That'll be a bug. I need to fix that - thanks | 15:29 |
| roaksoax | rbasak: alrigh then :) thanks for the input | 15:30 |
| roaksoax | smoser: howdy!! were you able to look at sending the power_type stuff at ipmi | 15:31 |
| roaksoax | err | 15:31 |
| roaksoax | at the commissioning process/ | 15:31 |
| roaksoax | in* | 15:31 |
| smoser | roaksoax, no. i have not. | 15:31 |
| smoser | :-( | 15:31 |
| roaksoax | smoser: hehe, alright I think we can get that done by the end ofthe week | 15:32 |
| smoser | yes. | 15:33 |
| smoser | this epheemeal stuff is a PITA | 15:33 |
| smoser | and has been sucking time from me | 15:33 |
| smoser | we're *almost* there. | 15:33 |
| smoser | i was testing my fix for oauth time sync, but it appears to be broken :-( | 15:33 |
| roaksoax | boomer :( | 15:33 |
| flacoste | rbasak: the trick is that squadfs makes a big performance difference for provisioning time, so would be really good to have decent provisioning time on ARM | 15:38 |
| flacoste | rbasak: i'm fine to doing it last though | 15:39 |
| flacoste | rbasak: better to have working but slow arm support, than half-working fast one | 15:39 |
| rbasak | roaksoax: do squashfs images exist for ARM at the moment? What would be involved in getting them produced? | 15:40 |
| roaksoax | rbasak: no they dont. Daviey was the one who worked on them | 15:41 |
| smoser | flacoste, are you making statements above based on experience ? or on conjecture ? | 15:54 |
| smoser | "big performance difference" in particular | 15:54 |
| flacoste | smoser: conjecture | 15:55 |
| flacoste | smoser: we are still awaiting that "one number" from Daviey ;-) | 15:55 |
| smoser | when i pressed cjwatson for it, he said "maybe 1 minute" | 15:55 |
| smoser | that being part of a 10+ minute install | 15:56 |
| flacoste | smoser: only one minute difference between squashfs and d-i? | 15:56 |
| smoser | yes | 15:56 |
| flacoste | is that experience or conjecture? | 15:56 |
| smoser | that was in cjwatson's head when he initially enabled this. | 15:56 |
| smoser | err... from his memory of testing it when he enabled it. | 15:56 |
| smoser | so its not a hard result either | 15:57 |
| flacoste | right, but come from a least some tests | 15:57 |
| flacoste | that's disappointing | 15:57 |
| smoser | but it seems to me that if your definition of "big" is > 10% you will likely be disappointed. | 15:57 |
| flacoste | but still worth a real test | 15:57 |
| flacoste | indeed :-) | 15:57 |
| smoser | roaksoax, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/678 | 15:58 |
| smoser | i've actually tested the oauth time sync issue now. and the url there shows the additional fix needed. | 15:59 |
| roaksoax | cool | 16:00 |
| smoser | rbasak, did you test BOOTIF_DEFAULT ? | 16:27 |
| smoser | if so, i'm gonna do an upload to archive with that. | 16:27 |
| rbasak | smoser: not yet, sorry | 16:28 |
| rbasak | smoser: got a few things in my queue to test :-/ | 16:29 |
| smoser | yeah. | 16:29 |
| smoser | i'll test it here. i really already have, bug you are the *actual* target. | 16:29 |
| jtv | smoser: can I just ask you something about the hostname/domain kernel options? | 16:50 |
| smoser | sure | 16:52 |
| smoser | domain is gone afaik | 16:52 |
| jtv | Gone? | 16:52 |
| jtv | *Please* don't tell me that it's meant to be included in hostname now... | 16:52 |
| smoser | i dont really recall. | 16:56 |
| smoser | well, i guess its not gone. | 16:58 |
| smoser | its an option to the debian installer. | 16:58 |
| smoser | it probably uses it to determine the fqdn | 16:58 |
| jtv | smoser: well my question was: if no domain is given, do I need to provide "local" or somesuch, or can I just leave it out? | 16:58 |
| jtv | Hmm... it wouldn't be used to set the search domain, would it? | 16:58 |
| jtv | For dns resolution? | 16:58 |
| smoser | i dont know. | 17:00 |
| smoser | http://hands.com/d-i/ | 17:00 |
| smoser | see 'domain' there. tells us that it is an alias for 'netcfg/get_domain' | 17:00 |
| jtv | Very helpful. | 17:01 |
| jtv | This here seems to say that we should pass a default domain if none is given: http://www.hps.com/~tpg/notebook/autoinstall.php | 17:03 |
| jtv | (I'm taking a very limited view of the information because my question is exactly that) | 17:03 |
| smoser | it would seem that you should pass something, yes. | 17:04 |
| jtv | And then the next question is what that would be: "local" or "local.lan" or the enlistment domain... | 17:07 |
| smoser | what is "enlistment domain" ? | 17:08 |
| jtv | The default domain that nodes go into on enlistment. | 17:08 |
| smoser | (i'm looking at netcfg source, and to me it seem slike it would get along without this variable, but then the domain portion of a hostname will not be written to e/tc/hosts) | 17:08 |
| jtv | Well the hostname and domain are separate variables. | 17:09 |
| jtv | And our Node.hostname includes the domain. | 17:09 |
| smoser | which ends up meaning that things that do 'hostname --fqdn' will do dns resolution to figure that out, which is indeerminable. | 17:09 |
| smoser | are you thinking of some reason that you'd want it to differe from the enlisted nodes? | 17:10 |
| jtv | Yes: the fact that the hostname is initialized to include that domain by default. | 17:13 |
| jtv | From which it follows that if the hostname does not include a domain, it is the result of a deliberate action by an admin. | 17:14 |
| smoser | jtv, i'm sorry. i cna't come up with a really good suggestion. i think in general you do not want that empty. | 17:16 |
| smoser | but i dont know. | 17:16 |
| smoser | i know that every time i muck with hostname in cloud-init it breaks something | 17:17 |
| jtv | Not very encouraging. | 17:18 |
| jtv | I think, given that enlistment domain has a reasonable well-defined goal and this is not it, and given that we only end up with a domain if people have chosen not to accept the one that was set there, the only option we have left is to default to "local." | 17:19 |
| smoser | its not entirely un-reasonable to specify none there. really. | 17:20 |
| smoser | but your argument seems reasonable to me. | 17:20 |
| jtv | The code I had prepared leaves it out if no domain was given, but it sounds as if that's really really undesirable. | 17:22 |
| jtv | We can't have any questions on an automated remote install! | 17:22 |
| jtv | smoser: is there any meaningful distinction between local and local.lan? | 17:26 |
| smoser | http://en.wikipedia.org/wiki/.local | 17:28 |
| smoser | it seems maybe inappropriate then for us to use 'local' there | 17:29 |
| smoser | jtv, just to be forthcoming, i'm not at all a dns expert. i'm googling same as you | 17:29 |
| smoser | http://superuser.com/questions/117056/how-to-choose-a-sensible-local-domain-name-for-a-home-network | 17:30 |
| jtv | smoser: I don't see why it would make "local" inappropriate. The wikipedia article makes it sound like a sensible, reasonably standardized choice if you can't get an actual proper domain. | 17:34 |
| smoser | lots of things specifically say not to use .local | 17:35 |
| smoser | because that is basically taken by avahi/mdns and you are explicitly *not* mdns or avahi | 17:36 |
| Daviey | smoser: erm, we actually DO want local | 17:36 |
| jtv | "Taken" in what way? | 17:36 |
| jtv | We're publishing these names on mdns, right? | 17:36 |
| smoser | i'm not sure. i dont understand why we'd want .local | 17:37 |
| smoser | we're using real dns. and real domain names. | 17:37 |
| smoser | err... real dns. | 17:38 |
| jtv | We don't want it, but we have to pick something if humans have chosen not to leave the domain name in there. | 17:38 |
| jtv | Daviey: you seem to know more about this... please speak! | 17:38 |
| Daviey | jtv: No, i'm just a daft manager. :) | 17:41 |
| jtv | and allenap, you say a node's domain name should always be taken from its nodegroup... that's not going to be quite the same thing as its zone name, is it? | 17:41 |
| Daviey | mDNS and maas-controlled-dns is mutually exclusive, right? | 17:42 |
| allenap | jtv: A node/nodegroup doesn't really have a zone name. A nodegroup has a domain name and it has a network. Every node in its network is in its domain, but it's not necessarily true that every node in its domain is in its network, because more than one nodegroup can have the same domain (well, once I land my wretched branch they will). | 17:46 |
| jtv | I think I was confused with ddns there for a moment. | 17:46 |
| jtv | allenap: "name" was supposed to be its zone name, not its domain name (not that I really know the difference) | 17:46 |
| Daviey | jtv: Yeah, so mDNS (.local) and DDNS should also not be used together | 17:47 |
| jtv | Daviey: so you're saying that at least it's guaranteed that mdns won't interfere with whatever we do? | 17:47 |
| Daviey | no, i'm saying it musn't ;) | 17:47 |
| Daviey | I have NFI if it does. | 17:47 |
| Daviey | <-- helpful | 17:48 |
| jtv | Ahem :) | 17:48 |
| allenap | jtv: Yeah, that's what I thought until the weekend. The "zone name" for a node in a node group might be "example.com." or "168.192.in-addr.arpa.", depending on what context you're thinking of a node in. | 17:49 |
| jtv | Hnyargh. | 17:49 |
| jtv | That doesn't sound helpful in excessive measures either. | 17:49 |
| allenap | Daviey: Where DDNS equals Dynamic DNS (updates)? | 17:50 |
| Daviey | jah! | 17:50 |
| jtv | allenap: if the zone name can be multiple things depending on how we happen to be thinking at the moment, what is it we're storing in NodeGroup.name? | 17:57 |
| allenap | jtv: The domain name, so "maas.canonical.com" for example. | 17:57 |
| jtv | Why didn't we know this? | 17:57 |
| allenap | jtv: Don't know. Last week was the first time I'd worked on this code, I think. | 18:02 |
| jtv | allenap: so... NodeGroup.domain _is_ the domain name then? And the domain name that is included in the hostname should be ignored? Any idea why we have the latter? | 18:11 |
| allenap | jtv: What? Where did NodeGroup.domain come from? | 18:14 |
| jtv | Sorry, NodeGroup.name | 18:14 |
| allenap | jtv: Yeah, that sounds right, and I have no idea why the latter has been getting in. Left hand / right hand probably. | 18:15 |
| jtv | Urgh. And we show that to users and invite them to edit it. | 18:15 |
| allenap | jtv: We should validate that it's a valid hostname. I wonder if Django has such a form field? | 18:18 |
| jtv | Our code inserts the domain name. | 18:18 |
| jtv | So I doubt form validation is going to resolve this particular matter. | 18:18 |
| allenap | Gah. | 18:20 |
| jtv | However at least one thing now becomes clear: | 18:21 |
| allenap | It's a prophylactic for next time. | 18:21 |
| jtv | an enlisting node (which has no nodegroup) can use the enlistment domain, and an installing one (which does) can use the nodegroup's. | 18:21 |
| jtv | I guess a commissioning node (for which there is some special-casing) would naturally fall on the enlistment side. | 18:22 |
| allenap | jtv: We ought to be able to figure out which nodegroup any node belongs to by virtue of which network its in... assuming we're managing the network. | 18:23 |
| allenap | If not, then what you said makes sense. | 18:23 |
| allenap | s/its/it's/ ETIRED | 18:24 |
| allenap | jtv: I have to go now, but I'll be back later. | 18:24 |
| jtv | It's not quite as easy as it seems to figure out which nodegroup is in. | 18:24 |
| jtv | I can't be here when you get back: it's the wee hours. | 18:24 |
| allenap | jtv: Okay, get some sleep, see you tomorrow! | 18:25 |
| jtv | Can't wait that long -- it'll be after lunch for me when you get back. :( | 18:25 |
| jtv | I think my only viable route right now, given what you said, is to go with what I just described. | 18:26 |
| allenap | jtv: If you're still there we can discuss some more. (I had to put Robin in the bath and then bed.) | 19:42 |
| jtv | allenap: I'm still sort of here! | 19:42 |
| jtv | Updated my branch. | 19:42 |
| allenap | jtv: I'll review. | 19:42 |
| jtv | Thanks. | 19:42 |
| jtv | Changes aren't too big. | 19:42 |
| jtv | I think enlistment_domain makes a lot more sense this way. | 19:43 |
| jtv | But we need to address the weirdness between those two domains. | 19:43 |
| wkharold | Bug #1028448 (service try to contact zookeeper based on adress no ip) is there a work around? | 19:52 |
| ubot5 | Launchpad bug 1028448 in juju "service try to contact zookeeper based on adress not ip" [Undecided,New] https://launchpad.net/bugs/1028448 | 19:52 |
| wkharold | we are trying to bring up a private cloud and this is blocking us | 19:54 |
| mgz | wkharold: is that maas related? in general the solution is to use the openstack provider against openstack, rather than the ec2 one. | 19:55 |
| mgz | ...also posting the same question in multiple channels simultaniously is annoying >_< | 19:56 |
| mgz | #juju is probably the better place | 19:56 |
| wkharold | sorry, wasn't sure ... should've asked. this is a private cloud on raw hardware. trying to do a simple test to see if things are working before doing the openstack dance | 19:57 |
| mgz | so, it's not that bug then? just the same symptom? | 19:57 |
| wkharold | it appears to be that bug ... gettting the same machine-agent stack trace on the blade chosen for the mysql deploy | 19:59 |
| mgz | but is juju on raw hardware using the maas provider? | 19:59 |
| wkharold | yes | 19:59 |
| mgz | does dns work otherwise? | 20:01 |
| wkharold | yes ... I'll verify w/my sys admin | 20:01 |
| wkharold | tnx | 20:02 |
| mgz | if you can't raise anyone else in here, post full details with for conf etc to the maas list, when people are awake they'll respond | 20:03 |
| allenap | jtv: +1 | 20:06 |
| jtv | Thanks allenap | 20:07 |
| mercsniper | anyone available to offer assistance? | 20:26 |
| roaksoax | allenap: i don't think you are still around are you? | 23:40 |
| === matsubara is now known as matsubara-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!