| bigjools | lifeless: did you see rvb's email about dns? | 01:05 |
|---|---|---|
| lifeless | probably not, I've been fighting the 'flu | 01:45 |
| lifeless | running at something like 50% efficiency | 01:45 |
| smoser | roaksoax, are you around? | 01:59 |
| bigjools | hey smoser | 02:01 |
| smoser | hey. | 02:01 |
| bigjools | smoser: did you see rvb's email about dns? | 02:01 |
| bigjools | classless networks | 02:02 |
| smoser | where? | 02:05 |
| bigjools | on maas-devel | 02:05 |
| lifeless | I see it now | 02:06 |
| === jtv1 is now known as jtv | ||
| smoser | bigjools, this is all really only in regard to provisioning networks, right? | 02:13 |
| bigjools | smoser: yes | 02:14 |
| bigjools | but we're only running one dns server on the maas server side | 02:14 |
| smoser | in which case i don't think the /8, /16, or /24 is an issue. | 02:14 |
| bigjools | the problem is the reverse zone authority overlap | 02:15 |
| bigjools | for masks not on /8 boundaries | 02:15 |
| smoser | i'm missing something. | 02:17 |
| bigjools | read http://www.indelible.org/ink/classless/ | 02:17 |
| smoser | i dont think it would help | 02:18 |
| bigjools | if we don't do something then the reverse zone authority will overlap. | 02:18 |
| bigjools | if that's not a problem then we can continue with no change | 02:18 |
| smoser | for a real maas environment, i think that maas will control the "provisioning network", and the dns on it. | 02:19 |
| bigjools | yes | 02:19 |
| bigjools | but if there is an adjacent network with its own dns then there may be problems | 02:19 |
| lifeless | I've replied | 02:20 |
| lifeless | there is a very simple solution, and I'm sure there is a good reason we aren't doing it :) | 02:20 |
| lifeless | so my reply was basically a question | 02:20 |
| bigjools | we don't do that because the hostnames can be set separately in maas | 02:21 |
| lifeless | why do we support that ? | 02:21 |
| bigjools | I'd prefer to use nsupdate here | 02:21 |
| bigjools | but this was all done while I was away | 02:22 |
| lifeless | Somewhere along the way we got this hostname setting complexity. | 02:22 |
| bigjools | because it was in the mockups? :) | 02:22 |
| lifeless | But we're aiming at hyperscale deployments. | 02:22 |
| bigjools | right | 02:22 |
| lifeless | Manually setting hostnames there is, shall we say, pointlless. | 02:22 |
| bigjools | well it's not manual as such but maas does generate a hostname | 02:22 |
| lifeless | do we expect / permit nodes to change IP address on reboots ? | 02:23 |
| bigjools | I went through all this on Monday with the guys... let me try and recall the conversation because twins make me forget stuff | 02:24 |
| lifeless | Sure;) | 02:24 |
| lifeless | So I'll put one more note out and then wait for your ack :>. | 02:24 |
| lifeless | juju will break if the ip address of the bootstrap node changes. | 02:24 |
| lifeless | So if we do permit unintentional node ip changes, we probably should stop it. | 02:25 |
| bigjools | I was all for doing a static-ish map | 02:25 |
| bigjools | but everyone complained that it makes it harder to recover when decommissioning nodes | 02:25 |
| lifeless | recover what ? | 02:25 |
| bigjools | reclaim the IP | 02:26 |
| bigjools | I wanted to use DHCP's mechanism to update a ddns when a lease was allocatewd | 02:26 |
| lifeless | so I'm saying - can we totally eliminate that overhead | 02:27 |
| lifeless | don't reclaim the ip, keep it for maas. | 02:27 |
| lifeless | make the dns name totally static | 02:27 |
| bigjools | it is kept - but we were talking about re-using it for a different node | 02:27 |
| bigjools | if a new node enlists | 02:27 |
| lifeless | sok | 02:27 |
| lifeless | ok | 02:27 |
| lifeless | so, when someone says 'delete it' that would mean 'remove it from dhcp static allocation' | 02:28 |
| lifeless | fin | 02:28 |
| lifeless | no DNS change at all | 02:28 |
| lifeless | (in my happy happy little world :P) | 02:28 |
| bigjools | lifeless: it's an interesting point that we could just keep the dns static but the hardware might change underneath that ip/host | 02:30 |
| lifeless | right | 02:30 |
| lifeless | changing hardware is a decommission+commission | 02:31 |
| bigjools | jtv: ^ | 02:31 |
| lifeless | in a cloud world | 02:31 |
| lifeless | you don't replace the motherboard and claim its the same machine, you migrate the workload off and kill the box | 02:31 |
| lifeless | or you can have a special 'I'm replacing the MB' feature if needed | 02:31 |
| bigjools | lifeless: actually I am not sure any of this changes anything | 02:32 |
| bigjools | we still need to work out new IPs being allocated and stick them in the DNS | 02:33 |
| bigjools | we can do that systematically of course | 02:33 |
| lifeless | yes, but you can have one zone for all your nodegroups | 02:33 |
| lifeless | and just replicate the entire thing | 02:33 |
| bigjools | ew | 02:33 |
| lifeless | seriously | 02:34 |
| lifeless | how much data is needed to configure 1M forward nodes and 1M reverse for the ec2 DNS approach | 02:34 |
| bigjools | that would be crazy imo, reloading a zone file would take a long time with 1m nodes! | 02:34 |
| lifeless | well | 02:34 |
| lifeless | two things, a) it would be very rare - DC reconfiguration rare | 02:35 |
| bigjools | I disagree | 02:35 |
| bigjools | it'd happen every time you added new hardware | 02:35 |
| lifeless | and b) I didn't mean exactly one zone, I meant that you can split on IP classes rather than on nodegroup boundaries. | 02:35 |
| lifeless | so you don't need the rfc2317 dance around | 02:35 |
| lifeless | so each zone would be at most 256 rows. | 02:35 |
| lifeless | (on the reverse side) | 02:36 |
| bigjools | we want one zone per rack/group because it keeps the model sane | 02:36 |
| lifeless | on the forward side, I'd expect one zone per nodegroup (matching the compute-1 in the ec2 example. | 02:36 |
| bigjools | right | 02:37 |
| bigjools | lifeless: I think that rvb was wanting to keep reverse zones in step with forward zones, it keeps things nice and simple | 02:40 |
| lifeless | yes, I can see that | 02:40 |
| lifeless | I don't see that its worth the complexity if we can make it entire static | 02:40 |
| lifeless | thats a huge win | 02:40 |
| bigjools | "static" :) | 02:40 |
| lifeless | yeah, static | 02:40 |
| lifeless | how often will you bring up a new nodegroup ? | 02:41 |
| bigjools | it'll change every time new hardware is added | 02:41 |
| lifeless | why? Surely it only changes when you allocate *room* for new hardware | 02:41 |
| bigjools | unless we get cute and write the zone files out when setting the IP ranges on the nodegroup | 02:41 |
| lifeless | that was my point | 02:42 |
| lifeless | that DNS is entirely decouplable from commissioning/decommissioning | 02:42 |
| bigjools | jtv: are you reading this? | 02:42 |
| jtv | Yes, but I'm not familiar with reverse DNS so some of it is magic to me. | 02:42 |
| bigjools | jtv: it's basically a "trick" to make a forward lookup work with a special domain | 02:43 |
| jtv | Ah. I had indeed missed that completely. | 02:43 |
| bigjools | 4.3.2.1.in-addr.arpa is the forward domain for the reverse lookup | 02:43 |
| jtv | Forward domain for reverse lookup? | 02:43 |
| lifeless | bigjools: ITYM 3.2.1.in-addr.arpa | 02:44 |
| * jtv despairs | 02:44 | |
| lifeless | bigjools: 4.3.2.1.in-addr.arpa is the record :) | 02:44 |
| bigjools | yes -the zone is only notionally a reverse. | 02:44 |
| bigjools | lifeless: right :) | 02:44 |
| lifeless | jtv: its a normal lookup, but the client knows to switch things around | 02:44 |
| lifeless | for the purpose of this discussion anyhow. | 02:44 |
| jtv | What things? The octets? | 02:44 |
| bigjools | jtv: it gets complicated when the netmask is classless (ie doesn't sit on /8 octet boudaries) | 02:45 |
| lifeless | jtv: yes, octets | 02:45 |
| lifeless | the query to make to find the official hostname for the ip address 1.2.3.4 is 4.3.2.1.in-addr.arpa | 02:45 |
| bigjools | so the reverse zone is just a special forward zone | 02:46 |
| bigjools | anyway | 02:47 |
| bigjools | jtv: we're talking about writing out static dns zones based on the declaration of IP ranges in the nodegroups | 02:47 |
| bigjools | it would *vastly* simplify things | 02:48 |
| bigjools | we'd still use the lease parser to set the hostname in the MAAS | 02:48 |
| bigjools | but hostnames would now be something like 192-168-1-1.my.domain | 02:49 |
| bigjools | lifeless: anyway the original question is not answered - do we care about the reverse zone being overly authoritative when there's a non-octet netmask boundary? | 02:51 |
| lifeless | yes, because otherwise it won't work for adjacent nodegroups | 02:52 |
| lifeless | you need to do rfc2317 if you have that sort of split. | 02:53 |
| bigjools | right, this is what I expected | 02:58 |
| jtv | So… does this mean we won't bother with the hostnames any more? | 03:02 |
| bigjools | jtv: we'd use the lease parsing script to set them | 03:02 |
| jtv | And they wouldn't be user-definable any more? | 03:02 |
| bigjools | right | 03:03 |
| bigjools | not sure it helps at hyperscale | 03:03 |
| lifeless | hosts moving ip address will confuse and break various things | 03:04 |
| lifeless | in particular juju, which we care a lot about | 03:04 |
| jtv | At scale, I see no point whatsoever to those user-definable hostnames. I think they're really only useful for the seed cloud. | 03:04 |
| lifeless | All the seed cloud discussion i've seen have had juju in the mix | 03:04 |
| lifeless | and there, the hostnames aren't needed with | 03:04 |
| bigjools | it may not even be worth worrying about for seeds | 03:04 |
| lifeless | as juju handles all the resolving from service unit -> what to ssh to | 03:04 |
| bigjools | the lease parsing script can just do a dns lookup to get the host name | 03:05 |
| bigjools | and poke it in | 03:05 |
| jtv | By the way, this lease-parsing script you're talking about, where will that sit? | 03:06 |
| bigjools | the one that you wrote you mean? | 03:07 |
| jtv | Well there's no script as such. | 03:07 |
| bigjools | it's a Task, yeah | 03:07 |
| lifeless | fwiw it might be a good idea to translate dynamic leases to static ones, when we're running dns | 03:07 |
| bigjools | so s/script/Task/ everywhere | 03:08 |
| lifeless | bah | 03:08 |
| lifeless | dhcp | 03:08 |
| bigjools | lifeless: we discussed that | 03:08 |
| lifeless | that would avoid any chance of accidental ip changes | 03:08 |
| bigjools | I think it's fine as-is, because the ip can be re-requested when the lease expires | 03:09 |
| bigjools | hmmm although if there's a lot of dhcp traffic I'm not sure if that holds | 03:09 |
| lifeless | what if a machine is off for maintenance and a sysadmin plugs into the lan temporarilty | 03:09 |
| lifeless | how do you make sure they aren't holding that machines ip when the machine comes up | 03:10 |
| bigjools | why does it matter if it changes when the machine is down? | 03:10 |
| bigjools | it just gets a new one when it comes up | 03:10 |
| lifeless | right | 03:10 |
| bigjools | cloud, remember? :) | 03:10 |
| lifeless | and all the charm associations that have memoised the ip address break. | 03:10 |
| bigjools | if it's down it's not allocated | 03:11 |
| lifeless | we may have terminology issues | 03:11 |
| lifeless | I mean 'commissioned but powered off' | 03:11 |
| bigjools | then it's still not allocated | 03:11 |
| lifeless | e.g. by someone running 'sudo poweroff' before they plug more disk in. | 03:11 |
| lifeless | really? | 03:11 |
| jtv | Actually an allocated machine may also be off for longer periods. | 03:11 |
| jtv | That's up to whoever allocated it. | 03:11 |
| lifeless | I thought we had a more ec2 like model, where power on/off is orthogonal to allocate/deallocate. | 03:12 |
| bigjools | I am assuming that if it's allocated it's on | 03:12 |
| jtv | I'm not sure that's a safe assumption. | 03:12 |
| lifeless | I expect that to be the general case. | 03:12 |
| lifeless | but not the contra positive. | 03:12 |
| lifeless | er | 03:12 |
| lifeless | I mean, but not the entire story. | 03:12 |
| bigjools | is that the negative? :) | 03:12 |
| lifeless | the contrapositive is entirely different :) | 03:12 |
| lifeless | <- sick dammit! | 03:13 |
| bigjools | hehe | 03:13 |
| bigjools | jtv: right, someone could conceivably reboot their allocated hardware | 03:13 |
| lifeless | they will | 03:13 |
| lifeless | for kernel upgrades | 03:13 |
| lifeless | folk do this in ec2 as well | 03:13 |
| lifeless | having the leases be dynamic post enrollment really unnerves me. | 03:14 |
| bigjools | so we really do need to write static lease maps, or make the lease 100000000 years | 03:14 |
| jtv | And at smaller scales where people have access to the hardware they allocated, and the hardware has identity. | 03:14 |
| lifeless | of course if you're using non-managed dhcp | 03:14 |
| lifeless | its a different story | 03:14 |
| lifeless | but production -> maas to the wall | 03:14 |
| bigjools | actually a long lease is also problematic | 03:16 |
| bigjools | because it's harder to revoke | 03:17 |
| bigjools | jtv: I am desperate for food, but can we have a call in a short while? | 03:18 |
| jtv | Sure | 03:18 |
| bigjools | let's chat about this with a little more bandwidth :) | 03:18 |
| bigjools | I'll grab you in about 15-30m | 03:19 |
| jtv | ok | 03:23 |
| smoser | anyone want to review https://code.launchpad.net/~smoser/maas/vdenv-updates/+merge/115645 | 03:31 |
| smoser | shouldn't be anythign controversial there. | 03:31 |
| bigjools | smoser: I'll rubber stamp it | 03:34 |
| bigjools | can you set a commit message | 03:34 |
| bigjools | we need to rip the cobbler stuff out of it soon, will any of it work still or does it now need special magic? | 03:35 |
| smoser | it doesnt do anything cobbler specific now. | 03:37 |
| smoser | assuming the interfaces of 'maas-import-isos' and 'dpkg-reconfigure maas' stay the same. it should continue to work. | 03:37 |
| bigjools | cool | 03:38 |
| jtv | smoser: maas-import-isos is to be replaced by maas-import-pxe-files, which is cobblerless, but for now it still uses the same config file and variables (where applicable) | 03:39 |
| smoser | it really should retain the same name if at all possible | 03:41 |
| smoser | or warn "legacy name, calling maas-import-pxe-files, update your scripts" | 03:41 |
| jtv | The latter should be easy enough. | 03:42 |
| smoser | ok. i just pushed one more change to that branch | 03:46 |
| smoser | http://bazaar.launchpad.net/~smoser/maas/vdenv-updates/revision/764 | 03:46 |
| bigjools | gah I wish people would spell "existent" properly | 03:48 |
| bigjools | it's even in the cmd line opts | 03:48 |
| smoser | bigjools, i suppose i was wrong above. the zimmer build (which i've been recently working on) is not dependent on cobbler. | 03:51 |
| smoser | i'll have to move some of the cobbler api stuff to just use the maas api | 03:51 |
| bigjools | ok | 03:52 |
| bigjools | we have a card on the kanban board to fix it | 03:52 |
| bigjools | but if you do it, even better :) | 03:52 |
| smoser | there is a client library now? | 03:59 |
| smoser | or cmdline client i thought? | 03:59 |
| smoser | hm.. | 04:09 |
| smoser | have to bother roaksoax tomorrow. | 04:09 |
| smoser | in my vdenv, i boot a new node, it seems to be going trhough enlistment, shuts itself off, but maas doesn't know about it. | 04:10 |
| bigjools | sorry smoser, was OTP | 04:31 |
| bigjools | there's no command line client yet | 04:31 |
| bigjools | but it's on the cards | 04:32 |
| === matsubara is now known as matsubara-afk | ||
| smoser | roaksoax, awake? | 12:57 |
| roaksoax | smoser here! | 13:00 |
| roaksoax | lifeless: scrolling back and hafl understanding the conversation :) , one of the issues we had with juju from the beginning was the fact that it used hostnames to address to nodes , which in our terms means having a DNS server | 13:20 |
| rvba | Hey smoser. FYI we are currently working on getting MAAS to work from the tree (we're doing this in the QA lab). I'm sorry if I was too blunt the other day (saying it was unsupported, etc.) but it will indeed requires us to fix quite a few things to get it working. 2 reasons for that: a) the cobbler-removal work has changed things a bit (everything is unit tested but we need to test that everything works well | 13:20 |
| rvba | together) b) like I said, we've always tested MAAS "for real" (i.e. with real nodes) from the package so this will require adjusting paths and stuff like that. | 13:20 |
| roaksoax | lifeless: we don't care so much about what IP address it had, or if it changed it, as long as we can address a node via its hostname | 13:20 |
| smoser | rvba, glad that you're getting it to work from tree. | 13:21 |
| smoser | my feelings weren't hurt too bad. i stopped crying in a couple hours ;) | 13:21 |
| roaksoax | rvba: indeed, but I wonder why aren't we doing it on packaging too | 13:21 |
| rvba | smoser: cool :) | 13:21 |
| smoser | roaksoax, http://paste.ubuntu.com/1100038/ | 13:21 |
| smoser | any ideas there? | 13:22 |
| smoser | i get that when a node tries to register. | 13:22 |
| smoser | maas is quantal | 13:22 |
| rvba | roaksoax: mostly because once we have that, it will allow us to iterate more quickly. Basically we will find some of the bugs more quickly. | 13:23 |
| roaksoax | smoser: ah yeah, known issue, waiting for a SRU: 1024010 | 13:23 |
| roaksoax | smoser: ah yeah, known issue, waiting for a SRU: bug @1024010 | 13:23 |
| roaksoax | err | 13:23 |
| roaksoax | bug #1024010 | 13:23 |
| ubot5 | Launchpad bug 1024010 in maas-enlist (Ubuntu Precise) "[SRU] After Commission Action 2 no longer exists" [Critical,Fix committed] https://launchpad.net/bugs/1024010 | 13:23 |
| roaksoax | rvba: ok | 13:23 |
| rvba | roaksoax: known issue indeed :) | 13:23 |
| roaksoax | rvba: but if the removal is in place, by running stuff from trunk, then i think we probably need to start taking care of releasing it that way in packaging too | 13:25 |
| rvba | roaksoax: we're in the process of getting it to work from the tree in the QA lab. But we're not there yet. | 13:26 |
| roaksoax | smoser: it is in proposed btw | 13:26 |
| smoser | roaksoax, so how do i fix this? | 13:27 |
| roaksoax | smoser: either install maas-enlist from precise-proposed, or you can patch maas temporarily | 13:28 |
| smoser | how would i install maas-enlist from precise-proposed ? | 13:30 |
| roaksoax | smoser: give me a sec i'm writing a patch | 13:31 |
| smoser | any idea on why we we wouldn't have maas server just allow '2' ? | 13:31 |
| smoser | and change it to '0' | 13:31 |
| roaksoax | smoser: because they removed the after_commissioning_actions it used to exist, that was 2, because it didn't do anything but we were defaulting to that | 13:32 |
| roaksoax | smoser: and after a conversation with rvba we agreed it made no sense to re-enable it, if we just needed to fix it as an sru | 13:32 |
| roaksoax | smoser: but now that you mention it, the install cd does not get the updated package right? | 13:33 |
| smoser | i dont know. i think that it would have been worth just allowing 2 as a synonym for 0 | 13:33 |
| smoser | and warning in logs. | 13:33 |
| roaksoax | rvba: ^^ | 13:33 |
| smoser | well, roaksoax over time, there will be a new -updates install cd made | 13:33 |
| smoser | but that package is coming from the rchive anyway | 13:33 |
| smoser | so you'd get the neewer one (i think its being apt-get installed, right?) | 13:34 |
| roaksoax | smoser: yeah | 13:34 |
| rvba | Given how the code is structured, that would have been awkward to keep the value '2' (which corresponds to something that is unsupported yet). | 13:34 |
| roaksoax | smoser: http://paste.ubuntu.com/1100061/ | 13:34 |
| roaksoax | rvba: so I have a patch for powering off machines with celery, it acutally works but i'm having a bit of trouble figuring out the tests (modifying them to not fail): http://paste.ubuntu.com/1100058/ | 13:35 |
| roaksoax | rvba: so if you have some input, it would be great | 13:36 |
| smoser | if roaksoax's patch to maas listed there fixes the problem, then rvba and i have a different definition of "awkward" | 13:36 |
| rvba | smoser: it seems more logical to fix the place which uses a value ('2') which doesn't exist anymore in the vocabulary rather that to patch how the vocabulary itself to have it store '0' when it is told to store '2'. | 13:38 |
| rvba | roaksoax: looking. | 13:39 |
| smoser | i think it seems like an unnecessary grasp at perfection resulting breaking of existing things. | 13:39 |
| smoser | 2 is not even an int there. | 13:39 |
| smoser | roaksoax, do i have the abilityto hack at the netbooted image at all to add -proposed there? | 13:40 |
| smoser | that would give us an actual test of -proposed | 13:40 |
| roaksoax | smoser: I don't know to be hones, but was thinking that maybe we can tell it to use -proposed thourhg the preseed | 13:41 |
| smoser | roaksoax, https://lists.ubuntu.com/archives/ubuntu-installer/2009-August/000466.html maybe | 13:42 |
| smoser | apt-mirror-setupapt-setup/proposedbooleanfalse | 13:42 |
| roaksoax | smoser: yeah looks about right | 13:44 |
| smoser | rvba, i admit i'm probably a little grumpy. | 13:44 |
| roaksoax | setting it to true should do | 13:44 |
| smoser | but i do think i'd rather live with a small wart than break some existing user, even if its only for a short time. | 13:44 |
| rvba | smoser: I understand the concern (and feel the grumpiness). | 13:45 |
| rvba | smoser: But I'm not sure I understand the problem: why don't we change the client (which uses '2' instead of '0') first, and then the server? | 13:46 |
| rvba | I'm sure this is a stupid question. | 13:46 |
| smoser | right. if the client does not get the update, but the server does, then you are broken. | 13:48 |
| rvba | Right. | 13:49 |
| smoser | other than this window right now, i dont think of a place where this issue should occur. | 13:49 |
| rvba | roaksoax: I see why the tests are failing. It is because you now skip the nodes for which power_type is WOL. | 13:52 |
| rvba | roaksoax: and the API returns an error if the number of returned nodes (when calling 'stop') is 0. | 13:52 |
| roaksoax | rvba: yeah i changed to not skip, and they still skipped :)., But the tests need to be changed in order to test celery outputs too | 13:52 |
| smoser | roaksoax, can you confirm... the default of the 'default' option gives me a menu | 13:53 |
| smoser | and that menu (i think) defaults to "maas enlist" after 20 seconds | 13:53 |
| smoser | but its strange that "local boot" is highlighted | 13:53 |
| roaksoax | smoser: yep, that's the behavior | 13:54 |
| roaksoax | rvba: for instance, test_stop_nodes_stops_nodes needs ot be change dto be celery compatible right? | 13:55 |
| rvba | roaksoax: definitely. | 13:55 |
| rvba | roaksoax: that's the only test which fails with this: http://paste.ubuntu.com/1100106/ | 13:56 |
| roaksoax | rvba: alright, cool | 13:56 |
| rvba | roaksoax: let me give you an example code to check celery's output. | 13:57 |
| rvba | roaksoax: actually, the celery fixture is activated by default so you simply need to check the content of self.celery.tasks. | 14:00 |
| smoser | roaksoax, http://paste.ubuntu.com/1100114/ | 14:00 |
| smoser | i modified the kickstart so i get the above preseed change. and verify that i now get the maas-enlist deb from -prposed | 14:01 |
| smoser | (which is good) | 14:01 |
| smoser | but then see the end of tha tlog | 14:01 |
| smoser | did something die? | 14:01 |
| roaksoax | smoser: check if maas-pserv is running | 14:01 |
| roaksoax | smoser: there seems to be a rare race condition there | 14:02 |
| roaksoax | smoser: thath causes maas-pserv no to start | 14:02 |
| smoser | maas-pserv says its running (status maas-pserv) | 14:02 |
| roaksoax | smoser: then check cobbler is running, and has the same IP address as maas server | 14:03 |
| smoser | sudo cobbler list works. | 14:05 |
| roaksoax | smoser: interesting, because the error log shows an xmlrpc error | 14:06 |
| roaksoax | or, cannot create connectio | 14:06 |
| smoser | roaksoax, well, i did dpkg-reconfigure maas | 14:12 |
| smoser | watched it restart everything | 14:12 |
| smoser | restarted apache2 too just for grins | 14:12 |
| smoser | still see the issue. | 14:12 |
| roaksoax | smoser: that's weird indeed. I can't see any other reason why cobbler wouldn't be responding to the xmlrpc | 14:16 |
| roaksoax | rvba if I have "print" statements within the tests, how can I effectively see them without them failing because the print is there | 14:18 |
| rvba | roaksoax: hum, I confess I never tried to put print statement inside tests (not sure how nose will react to that). I always use the debugger: put a breakpoint and the run an individual test: ./bin/maas test src/maasserver/tests/test_node.py:NodeManagerTest.test_stop_nodes_stops_nodes -s | 14:20 |
| roaksoax | rvba: what debugger do you use? | 14:21 |
| rvba | roaksoax: pdb. Put a line like 'import pdb;pdb.set_trace' in the code. | 14:22 |
| smoser | roaksoax, it would seem to me that maas-pserv is busted. | 14:26 |
| smoser | status is lying. | 14:26 |
| smoser | the pid is not present. | 14:26 |
| roaksoax | smoser: yeah so it didn't really start then | 14:26 |
| roaksoax | smoser: there is a race there | 14:26 |
| smoser | i dont think its a race | 14:26 |
| smoser | its not going to start | 14:26 |
| roaksoax | smoser: there are situations on which it starts and on which it doens't | 14:27 |
| roaksoax | smoser: i have been trying to troubleshoot that yesterday with allenap | 14:27 |
| smoser | i dont think this is that | 14:28 |
| smoser | http://paste.ubuntu.com/1100158/ | 14:28 |
| roaksoax | smoser: that it is | 14:28 |
| smoser | thats not a race | 14:28 |
| roaksoax | smoser: run this manually : sudo twistd -n --uid=maas --gid=maas --pidfile=/run/maas-pserv.pid --logfile=/dev/null maas-pserv --config-file=/etc/maas/pserv.yaml | 14:28 |
| smoser | thats what i did | 14:29 |
| roaksoax | smoser: does it run? | 14:29 |
| smoser | http://paste.ubuntu.com/1100160/ | 14:29 |
| smoser | (same thing i just pasted you) | 14:29 |
| roaksoax | ah lol | 14:29 |
| roaksoax | smoser: ok, go to /usr/share/pyshared/twisted/plugins/maasps.py | 14:30 |
| roaksoax | smoser: and add a "raise" before the "paas" | 14:30 |
| roaksoax | and try to run again manually | 14:30 |
| roaksoax | it should run normally | 14:30 |
| roaksoax | it is a race somewhere were it is failing to import something. | 14:30 |
| roaksoax | that appeared after allenap added the ftp stuff | 14:30 |
| roaksoax | rvba: so I've never used pdb before. SO you insert the break point, how do you run the code with pdb? | 14:34 |
| smoser | roaksoax, well, now its running (as in it doesnt crash immediately) but it connections to localhost:5243 still get connection refused. | 14:34 |
| roaksoax | smoser: kill it, remove the pid in /run/maas.pid | 14:34 |
| smoser | it removes that | 14:35 |
| roaksoax | smoser: and start maas-pserv again | 14:35 |
| rvba | roaksoax: you just run the test(s) normally but with the option '-s', for instance with "./bin/maas test src/maasserver/tests/test_node.py:NodeManagerTest.test_stop_nodes_stops_nodes -s" | 14:35 |
| rvba | Or "./bin/maas test src/maasserver/tests/test_node.py" | 14:35 |
| roaksoax | right i add the -s but it still finishes without giving me a console to debug it | 14:36 |
| rvba | roaksoax: are you sure you put your breakpoint in the code that gets executed? "./bin/maas test src/maasserver/tests/test_node.py" executes only the tests in test_node.py. | 14:37 |
| rvba | And that should be "./bin/maas test src/maasserver/tests/test_node.py -s" | 14:38 |
| roaksoax | rvba: yeah I put the breakpoint in the code, not the tests | 14:39 |
| rvba | roaksoax: that's all right, as long as the code gets executed, you should get pdb prompt. | 14:39 |
| rvba | roaksoax: care to share the diff? | 14:39 |
| roaksoax | rvba: ah never mind, i had () missing after set_trace :) | 14:40 |
| rvba | roaksoax: I see :) | 14:40 |
| rvba | roaksoax: My fault, 'import pdb;pdb.set_trace()' | 14:41 |
| smoser | roaksoax, so... how can i get past this? | 14:42 |
| roaksoax | smoser: now after manually running it, you should be able to run it with upstarts (maas-pserv that is) and eveyrthing should e running normally | 14:42 |
| roaksoax | smoser: i've been trying to figure what is wrong without success | 14:42 |
| smoser | roaksoax, no | 14:43 |
| smoser | after i run it, no 5243 is open on localhost | 14:43 |
| roaksoax | smoser: i'm waiting for allenap's to finihs writing a branch to see if that got this fixed | 14:43 |
| roaksoax | smoser: try to do a reboot mabe? | 14:46 |
| roaksoax | rvba: but anyways, other than that, I'm changing the test in such a way that it no longer uses WOl, but virsh, http://pastebin.ubuntu.com/1100178/ but it requires the binary | 14:48 |
| roaksoax | rvba: but the other wol tests, don't require the ether_wake binary | 14:48 |
| rvba | roaksoax: you can patch PowerAction.run_shell to make it do nothing. This way, you still tests that the task has been fired but you don't have to deal with the real consequences. | 14:50 |
| rvba | roaksoax: see how it's done in test_get_effective_power_parameters_provides_usable_defaults (src/maasserver/tests/test_node.py): self.patch(PowerAction, 'run_shell', lambda *args, **kwargs: ('', '')) | 14:52 |
| roaksoax | yep :) | 14:52 |
| roaksoax | thanks | 14:52 |
| realnorth_ | I was wondering if anyone could help me out with this problem: http://askubuntu.com/questions/165545/maas-install-64-bit-client-nodes-doesnt-work | 14:52 |
| realnorth_ | basically I can't get 64 bit precise installed on client nodes | 14:53 |
| realnorth_ | the network boot only boots 32 bit | 14:53 |
| roaksoax | realnorth_: hi! | 14:54 |
| realnorth_ | hey | 14:55 |
| roaksoax | realnorth_: so the machines 1. enlist. 2. commission. 3. deploy? | 14:55 |
| roaksoax | realnorth_: when you have MAAS installed, and you start enlisting machines, it will actually autodetect the architecture | 14:55 |
| roaksoax | but for enlistment it will run the Ubuntu installer on i386 | 14:55 |
| roaksoax | once enlisted, you "Accept & Commission" | 14:56 |
| roaksoax | they will commissioning using an ephemeral image | 14:56 |
| roaksoax | is that the process you are following? | 14:56 |
| realnorth_ | I have the parent node all set up | 14:56 |
| realnorth_ | and then I network boot the other machines | 14:56 |
| realnorth_ | pxe boot | 14:56 |
| realnorth_ | they are bare with no OS on them | 14:56 |
| realnorth_ | it boots over the network | 14:57 |
| realnorth_ | and gives me like 6 options | 14:57 |
| realnorth_ | with a 20 second timer | 14:57 |
| realnorth_ | If I let the timer go out it'll install i386 | 14:57 |
| realnorth_ | if I choose any other option it doesn't register with the parent node | 14:57 |
| realnorth_ | there is maas-precise-i386, maas-precise-i386-commisioning, maas-precise-x86_64, maas-precise-x86_64, ubuntu-precise-i386, ubuntu-precise-x86_64 | 14:58 |
| realnorth_ | and I think there is a maas-enlist option | 14:58 |
| realnorth_ | the one that is default is local | 14:59 |
| realnorth_ | I don't think I tried the maas-enlist option | 14:59 |
| realnorth_ | but I mean there is like no documentation on what any of those options are or where they come from | 14:59 |
| realnorth_ | https://wiki.ubuntu.com/ServerTeam/MAAS/AddNodes#Installing_via_PXE_then_accepting_into_MAAS_dashboard | 15:00 |
| realnorth_ | I followed those directions and it did the i386 version | 15:00 |
| realnorth_ | not the x86_64 | 15:00 |
| roaksoax | realnorth_: the default is not local, it is maas-nelist, but in the UI it shows 'local' | 15:01 |
| roaksoax | but it actually selects maas-enlist | 15:01 |
| roaksoax | in order to deploy | 15:01 |
| roaksoax | but anyways, you need to let the timer finsih by itsel | 15:02 |
| roaksoax | and let that node register itself in MAAS | 15:02 |
| realnorth_ | yeah but at that time it selects the i386 | 15:02 |
| realnorth_ | not the x86_64 | 15:02 |
| roaksoax | realnorth_: it doesn't matter | 15:02 |
| roaksoax | realnorth_: it is not deploying ubuntu | 15:02 |
| roaksoax | it is just enlisting | 15:02 |
| realnorth_ | okay | 15:02 |
| realnorth_ | when is anything installed on it | 15:02 |
| roaksoax | realnorth_: once the machien enlists into 'MAAS', then you go to the MAAS WebUI, and clic on 'Accept & Commission' | 15:03 |
| realnorth_ | uhu | 15:03 |
| roaksoax | that will (or should) start the machine again tfor the commissioning process | 15:03 |
| roaksoax | realnorth_: once that process is done, then the machine will be in 'Ready' starte | 15:03 |
| roaksoax | state* and you will be able to deploy Ubuntu | 15:03 |
| roaksoax | when you deploy, it will install 64bit version | 15:04 |
| realnorth_ | ahhh | 15:04 |
| roaksoax | realnorth_: are you looking into using juju | 15:04 |
| roaksoax | ? | 15:04 |
| realnorth_ | yeah | 15:04 |
| realnorth_ | that's what I was planning on doing | 15:04 |
| realnorth_ | so I just boot them normally let it time out | 15:06 |
| realnorth_ | and then juju will handle installing the real OS right? | 15:06 |
| realnorth_ | after it has been commissioned and everything | 15:06 |
| roaksoax | realnorth_: yeah, so 1. boot, let them time out for enlistment. 2. 'Accept&Commission' on WebUI, make sure it boots up again and let it commission (you'll need to configure the power management features correctly). 3. When machines are in 'Ready' state, you can use juju to deploy them | 15:07 |
| realnorth_ | okay | 15:08 |
| realnorth_ | what power management settings are you talking about? | 15:08 |
| roaksoax | realnorth_: from the MAAS webui, you'll need to configure PowerManagement | 15:08 |
| realnorth_ | oh | 15:08 |
| roaksoax | realnorth_: though in precise there are only few supported | 15:08 |
| realnorth_ | alright I know what you are saying now | 15:08 |
| realnorth_ | one last question | 15:09 |
| realnorth_ | to do the WOL do you need to open a port for every MAC on the MAAS parent? | 15:09 |
| roaksoax | realnorth_: nope. The network cards should already be configured torespond to WoL requests | 15:10 |
| roaksoax | realnorth_: MAAS simply sends a WoL packet to the node | 15:10 |
| realnorth_ | okay | 15:10 |
| realnorth_ | thanks you have been a real help | 15:10 |
| realnorth_ | I wish the Ubuntu docs had a bit better explanation of things | 15:11 |
| roaksoax | realnorth_: yeah we are also looking to have better docs sometime in the near future :) | 15:11 |
| realnorth_ | thanks | 15:12 |
| smoser | roaksoax, so i reboot | 15:12 |
| smoser | no dice | 15:12 |
| smoser | do you want to come in and poke around? | 15:12 |
| roaksoax | smoser: sure | 15:12 |
| roaksoax | rvba: finally it got it. Thanks for the help! Was cracking my head last night trying to get this test to work | 15:14 |
| rvba | roaksoax: do you remember why we generate a default hostname if none is provided? (I'm asking you because it turns out you introduced that method: node.set_mac_based_hostname). Now that we're going to change the hostname to be IP based I'm wondering if we can ditch that. The only difference is that before the node will be assigned an IP, the hostname will be ''. Would that be a problem? | 15:16 |
| roaksoax | rvba: wait, are you pre-assigning an IP address to the enlisted nodes? | 15:17 |
| rvba | roaksoax: no, the plan is to parse the DHCP lease file to get the IP address. Then a node will always get the same IP from the DHCP server. | 15:17 |
| roaksoax | rvba: right, is there an email thread where this is being discussed to address this | 15:18 |
| rvba | roaksoax: the hostname will be ip-based, à la amazon 192.168.3.2-maas.domain. | 15:18 |
| rvba | roaksoax: yes, I'm implementing that precisely :) | 15:18 |
| roaksoax | rvba: is this being discussed in an email thread? | 15:19 |
| roaksoax | rvba: cause there might not be a need to parse the leases file | 15:19 |
| rvba | roaksoax: my question is about that method: node.set_mac_based_hostname. I'd like to remember why this was introduced, to assess if I can ditch it now that we're changing the hostnames to be IP-based. | 15:19 |
| rvba | roaksoax: that's actually another question. I'm working on changing the usage of node.hostname at the moment. | 15:20 |
| rvba | roaksoax: see the discussion on the maas-dev list. | 15:20 |
| rvba | roaksoax: more specifically, the threads with 'DNS' in the title. | 15:21 |
| roaksoax | rvba: yeahc being the one having worked on Orchestra/Juju stuff at first, I think DNS was an issue | 15:21 |
| roaksoax | but anyways | 15:21 |
| roaksoax | to answer your question | 15:21 |
| roaksoax | rvba: that method was added because during the enlistment process, we do not sent a hostname that we'd like the machine to be registered with | 15:23 |
| roaksoax | rvba: however, we needed a hostname to be automatically determined | 15:23 |
| roaksoax | rvba: at the moment, we decided it was simple enough to use a MAC address and generate the hostname based on that | 15:23 |
| rvba | roaksoax: do you remember why exactly? Is this only to have something to show in the UI? | 15:24 |
| rvba | Because we didn't want to show the system-id? | 15:24 |
| roaksoax | rvba: no because we needed the hostname to make it addresseable to juju | 15:24 |
| roaksoax | rvba: juju *needs* hostnames | 15:24 |
| rvba | roaksoax: indeed, so what I'm doing is going to replace that then. | 15:24 |
| roaksoax | rvba: we cannot have a machine without a hostname, can we? | 15:24 |
| rvba | Well, it will be without a hostname right after it's been added. | 15:25 |
| roaksoax | rvba: well i think a hostname should be assigned on enlistment | 15:25 |
| rvba | But as soon as the node will get an IP address, it's hostname will be set. | 15:25 |
| rvba | its* | 15:25 |
| rvba | So juju will be happy. | 15:25 |
| roaksoax | rvba: right | 15:25 |
| roaksoax | rvba: but you are giving the node a IP address on enlistment, commissioning, and deployment | 15:26 |
| roaksoax | rvba: why complicate the process when nit should be kept simple | 15:26 |
| roaksoax | rvba: IMHO, on enlistment, you should set the hostname. Simple as that | 15:26 |
| roaksoax | rvba: whether it is based on IP, MAC or randomness, it should be set | 15:26 |
| rvba | The plan is to have very long lease times so the same IP will be assigned to a node everytime it boots. | 15:26 |
| rvba | time* | 15:26 |
| roaksoax | rvba: right, so why determine a hostname only in the last boot, when it can be determined on enlistment | 15:27 |
| roaksoax | cause as you mention, the idea is to keep | 15:27 |
| roaksoax | a long time lease | 15:27 |
| rvba | roaksoax: the DHCP server is in charge of assigning the IPs. So we won't know why IP has been chosen until the node is booted up. | 15:28 |
| rvba | s/why/which/ | 15:28 |
| roaksoax | rvba: exactly, and that is either on 1. enlistment, 2. commissioning. 3. deploying | 15:28 |
| rvba | roaksoax: not sure I follow, 'enlisment' is simply about registering the node inside MAAS. 'commissioning' will be the when the node boots up for the first time so that's where the IP will be determined, once and for all. | 15:30 |
| roaksoax | rvba: well, you already give an IP on enlistment, why would I need to do that on commissioning if you can get it early enough from enlistment | 15:34 |
| roaksoax | rvba: i can't really recall whether ytou needed a hostname when adding a machine to maas as a requirement, whether it was enlisted or not | 15:34 |
| roaksoax | I think if you didn't send one it would fail to enlist/add | 15:34 |
| roaksoax | rvba: eitherway, the enlistment process should be able to tell MAAS the IP address that the client got | 15:35 |
| roaksoax | enlistment already knows its IP, and should probably feed that back to MAAS to generate a hostname | 15:35 |
| rvba | No the hostname has always been optional, precisely because we could generate a MAC-based hostname. | 15:35 |
| roaksoax | IMHO | 15:35 |
| rvba | roaksoax: I'm sorry but I don't see when the IP is given to MAAS during enlistment. | 15:36 |
| rvba | s/when/where/ | 15:36 |
| roaksoax | rvba: we don't, we could | 15:36 |
| roaksoax | rvba: either way there was thoughts of making enlistment/commissioning 1 step | 15:36 |
| roaksoax | rvba: give me a sec and I'll give a better explanation of this | 15:38 |
| rvba | roaksoax: we've got 2 types of enlistment, the one you're talking about where we have the IP and the manual enlistment where a user adds a node in the UI. I'm not sure we want to ask the user the IP in this case, the mac address should be enough for MAAS to get going. And in this case we will need to get the IP from the lease when the machine will be booted up. | 15:39 |
| roaksoax | rvba: when you add a node from the UI, you can automatically select an IP for that | 15:40 |
| rvba | roaksoax: how? | 15:40 |
| roaksoax | rvba: give me a sec please | 15:40 |
| rvba | sure | 15:41 |
| roaksoax | rvba: btw.. from now on, are we going to enforce our own DHCP/DNS in mass without the possibility of using an external one? | 15:44 |
| rvba | roaksoax: now, that's still going to be an option. | 15:44 |
| rvba | s/now/no/ | 15:44 |
| roaksoax | rvba: ok so lets addres External DNS/DHCP server first | 15:48 |
| roaksoax | rvba: So, during nelistment, the machine boots up and recieves a IP and a hostname from the external DHCP server. it uses both of those to enlist itself in MAAS | 15:50 |
| roaksoax | then the hostname is set in MAAS for the enlistment | 15:50 |
| roaksoax | which is required as it is the one given to juju | 15:50 |
| roaksoax | and later on, juju uses the hostname in MAAS nodes to conectat the deployed nodes | 15:51 |
| rvba | roaksoax: why do we need the IP in this case? | 15:53 |
| roaksoax | rvba: we don't. juju doesn't really care what IP the server has | 15:54 |
| roaksoax | rvba: it cares about the hostname | 15:54 |
| rvba | roaksoax: so MAAS only needs to get the hostname then, not the IP. | 15:54 |
| roaksoax | rvba: yes, that's in the case of running external DNS/DHCP | 15:55 |
| rvba | Right. | 15:55 |
| === matsubara-afk is now known as matsubara | ||
| roaksoax | in the case of running one within, we need to make sure the node gets a hostname. We don't care what IP address is given to the node, because juju doesn';t care | 15:55 |
| rvba | But since we need to write the DNS zone file, we have to get the IP. | 15:56 |
| roaksoax | however, the issue being experienced by you guys is "How do I do DDNS"? | 15:56 |
| rvba | files* even, forward and reverse. | 15:56 |
| roaksoax | right, that's DDNS | 15:56 |
| roaksoax | so your recommendation, instead of doing DDNS, is "let's parse the lease file" | 15:57 |
| rvba | No. | 15:57 |
| rvba | Robert's recommendation is: write a zone for each nodegroup with the full range of possible IPs, then use hostname derived from the IP addresses. Just like amazon does. | 15:57 |
| roaksoax | ok | 15:58 |
| roaksoax | that;s fine | 15:58 |
| roaksoax | rvba: but, does that mean admins won't be manually able to set their own hostname? | 15:58 |
| rvba | roaksoax: indeed, they won't be able to do that. | 15:58 |
| roaksoax | rvba: that's something I personally don't agree with | 16:00 |
| roaksoax | rvba: if you have an external DNS/DHCP, you are allowing them to do that | 16:00 |
| roaksoax | rvba: if you have an internal, you are giving them the option | 16:00 |
| roaksoax | rvba: from my point of view, administrators will want to know what machine is what machine, and the only way to do that is by hostname | 16:00 |
| roaksoax | that's me though | 16:00 |
| roaksoax | my personal perception | 16:01 |
| rvba | roaksoax: the main goal for maas is to be a provider for juju so I really think that's fine also. Also, once you are playing with more than a handful of nodes, you won't want to customize the nodes' hostnames. | 16:01 |
| roaksoax | maybe you do, maybe you dont | 16:01 |
| roaksoax | but that's why there are 'name' constraints in juju | 16:01 |
| roaksoax | yto allow us to select a particular node | 16:01 |
| roaksoax | rvba: and that was very helpful in the ODS | 16:02 |
| roaksoax | rvba: but anyways, these thouhgs of mine should go on the email response | 16:03 |
| rvba | roaksoax: I'm not really sure we have a choice here, unless we want to manually rewrite the zone files each and every time a hostname changes. | 16:03 |
| roaksoax | rvba: we don't really, once a node is enlisted we have a hostname and a zone written for it | 16:04 |
| roaksoax | rvba: we should not be able to simply edit the hostname | 16:04 |
| roaksoax | rvba: but anyways, the thing is that if in enlistment with external DNS/DHCP I already know the hostname | 16:04 |
| roaksoax | rvba: I could determine the hostname in the enlistment process and send it back to MAAS | 16:04 |
| roaksoax | rvba: that's what I wanted to do at first, but was decided to do it on the maas side | 16:05 |
| roaksoax | so during enlist, we already know the IP address, and can simply say "This is my IP" and maas server can say "Enlistment, thanks, your IP will always the one you just got" | 16:05 |
| rvba | And MAAS will have to write the zone files. | 16:06 |
| roaksoax | rvba: or you can parse the leases file by MAC and add the IP, as in: DHCP gave 1.1.1.1 to MAC aa:bb:cc:dd:ee:ff , so on enlistment on the maas side "I got your enlistment request Aaa:bb:cc:dd:ee:ff", "the IP dhcp gave you is 1.1.1.1" | 16:06 |
| roaksoax | rvba: if we are trying to avoid writing zones, then have no possibility of naming our own nodes | 16:07 |
| roaksoax | which means we lose functionality | 16:07 |
| roaksoax | IMHO | 16:07 |
| rvba | I'm not trying to avoid writing zones files. I've just added the ability to write zone files in MAAS yesterday :). | 16:08 |
| rvba | But we're trying to keep it simple :). | 16:08 |
| roaksoax | I personally think allowing us to set our own hostnames, is a good thing. In the hyperscale where we need things on depand and we are gonna run thoundsands of servers, that will be used on deman based on, lets say, usage needs, then we don't really care about hostnames | 16:08 |
| roaksoax | rvba: but I personally think others will want to know the hostnames and what they have there and deploy accordingly | 16:09 |
| realnorth_ | not to interrupt your conversation but I have a really quick question | 16:09 |
| realnorth_ | can you have maas boot a specific iso not just ubuntu precise? | 16:10 |
| realnorth_ | cobbler can but I was hoping for something simple through maas | 16:10 |
| rvba | roaksoax: I understand your concerns but I think you should send an email to the list. I'd like Robert to be part of the discussion. | 16:10 |
| roaksoax | rvba: so, let me go through the emails, and give my thouhgs. | 16:11 |
| roaksoax | rvba: heh yeah :) | 16:11 |
| roaksoax | rvba: but to keep things simple, I think the hostname generation should be kept as simple as possible, and if you wanna change from MAC to IP "If MAAS is DHCP/DNS", then you would need to check that in the lease file for now | 16:11 |
| roaksoax | rvba: because DHCP will already know what IP it gave to what MAC, so on enlistment, you already have the MAC then you just obtain the IP from that lease file | 16:12 |
| roaksoax | and voala | 16:12 |
| roaksoax | voila | 16:12 |
| roaksoax | :) | 16:12 |
| rvba | Well, that's the plan. We will fetch the IP as soon as possible but if someone registers a new MAC which does not correspond to an assigned IP (because the machine hasn't been booted yet), then we will need for that machine to boot to get its IP. | 16:14 |
| roaksoax | rvba: right, but when it comes to maas, we only need the first mac for the internal/deployment network | 16:22 |
| roaksoax | rvba: which would be the "maas-management" network | 16:22 |
| rvba | That's right but my point above is still valid. That MAC might not be in the lease table. | 16:23 |
| roaksoax | rvba: if I enlist into maas with X ethernet card, then the mac will be in the lease table | 16:27 |
| roaksoax | rvba: that same X card will be the same used in commissioning and deployment, wouldn't it? | 16:27 |
| rvba | roaksoax: yes, but maybe at enlistment time, that card is completely unknown, that's my point. | 16:28 |
| roaksoax | rvba: right, it is uknown, but, does DHCP go: "I received a request from aa:bb:cc. I selecte ip 1.1.1.1 and granted it to aa:bb:cc" | 16:30 |
| roaksoax | doesn't it do that? | 16:30 |
| rvba | roaksoax: it does that when the machine boots up. If the machine has never booted up yet, then the dhcp lease file does not contain that information. | 16:32 |
| roaksoax | rvba: exatly, so on enlistment, the machine boots up, requests IP, DHCP server knows about it, then whne it sends the enlistment requirest, it grants it a hostname | 16:38 |
| rvba | roaksoax: we're going in circles here. I completely agree. But when a user manually enlists a node by providing only its MAC, then, if the node was never booted up, we can't get its IP address. We will need to wait for the node to be booted up (during commissioning) to get its IP. | 16:39 |
| roaksoax | rvba: when you manually enlist, you can simply select one IP address from the pool and grant it automatically | 16:40 |
| roaksoax | rvba: you manually nelist, you already know the MAC address, then you simply autoselect an IP address | 16:40 |
| roaksoax | you already know the range, you already know which ones are in use, and which ones are free | 16:41 |
| rvba | But you don't know which one the DHCP server will pick. | 16:41 |
| roaksoax | rvba: we do not care which one it picks | 16:43 |
| roaksoax | we just need one | 16:43 |
| roaksoax | rvba: so its like "Hi I'm aa:bb:cc and I need an IP addres", "Hi aa:bb:cc, i have IP 1.1.1.1 free and i'm gonna give it to you" "thanks DHCP< now my hostname is blablabl.1.1.1.1-bablabal" | 16:45 |
| rvba | roaksoax: Ok, so you want to do the DHCP request manually in MAAS. Now I get it :) | 16:48 |
| roaksoax | rvba: yeah just check what IP addresses are free and select one from the pool and tell the DHCP "the ip for MAC aa:bb:cc will be 1.1.1.1" | 16:49 |
| rvba | roaksoax: ok | 16:51 |
| rvba | roaksoax: I need to run, thanks a lot for your insights; please reply to the thread 'Strategy regarding DNS and static DHCP leases' on the maas-devel MP. I'd like this to be discussed by everyone. | 16:53 |
| roaksoax | rvba: will do, but will do it internally only as I might mention private stuff | 16:53 |
| rvba | roaksoax: ok | 16:54 |
| smoser | http://paste.ubuntu.com/1100429/ | 17:01 |
| smoser | roaksoax, does that make any sense? | 17:01 |
| roaksoax | smoser: i don;t recall seeing something like that | 17:03 |
| roaksoax | smoser: but rvba did make some changes in the wsgi file that changed the behaviour of the avahi stuff | 17:03 |
| roaksoax | which in fact might be the cause of this | 17:03 |
| smoser | i'm running from ubuntu package | 17:03 |
| roaksoax | smoser: /usr/share/maas/wsgi.py is the cause of that error | 17:12 |
| smoser | roaksoax, ok. so i now have my ssystem that does not show the issue | 17:13 |
| roaksoax | heh... | 17:14 |
| smoser | the thing i did was disable the rc.local script | 17:16 |
| smoser | maas-set-ip: http://paste.ubuntu.com/1100460/ | 17:16 |
| smoser | rc.local script: http://paste.ubuntu.com/1100461/ | 17:16 |
| smoser | so there is a race there. | 17:17 |
| smoser | roaksoax, can you look at maas-set-ip and tell what i've done wrong there? | 17:19 |
| smoser | or what i should not do ? | 17:19 |
| roaksoax | smoser: i get this error when I run it : awk: line 1: regular expression compile failed (missing operand) | 17:23 |
| roaksoax | * | 17:23 |
| roaksoax | smoser: but other than that, nothing seems wrong | 17:24 |
| smoser | really? | 17:28 |
| smoser | roaksoax, can you explain that? it deost make sense. to me. | 17:30 |
| smoser | i dont knwo what regular expression could be bad | 17:31 |
| smoser | can you run it with 'sh -x' ? | 17:31 |
| roaksoax | smoser: http://paste.ubuntu.com/1100500/ | 17:44 |
| smoser | so if you just run | 17:48 |
| smoser | awk '{gsub("*","");} $1 == key { print $2 }' key=maas/default-maas /etc/passwd | 17:48 |
| smoser | does that give that error? | 17:48 |
| smoser | roaksoax, ^ | 17:50 |
| roaksoax | yes | 17:50 |
| roaksoax | smoser: oh your problem might be that then, it cannot connect to xmlrpc because you are using the worng password for it | 17:51 |
| smoser | roaksoax, are you running bsd? | 17:52 |
| smoser | or some form of aix? | 17:52 |
| smoser | hm.. | 17:52 |
| roaksoax | lol it is a quantal image | 17:52 |
| smoser | no its not quantal | 17:52 |
| roaksoax | ubuntu@server-13819:~$ awk '{gsub("*","");} $1 == key { print $2 }' key=maas/default-maas /etc/passwd | 17:52 |
| smoser | i call foul there. | 17:52 |
| smoser | its 12.04 | 17:52 |
| roaksoax | awk: line 1: regular expression compile failed (missing operand) | 17:52 |
| roaksoax | * | 17:52 |
| roaksoax | smoser: http://pastebin.ubuntu.com/1100516/ | 17:53 |
| roaksoax | smoser: in my machine the error is not sohwn though | 17:53 |
| smoser | dpkg -S `which awk` | 17:54 |
| smoser | er.. i guess | 17:54 |
| smoser | update-alternatives --display awk | 17:55 |
| smoser | you have mawk. | 17:55 |
| smoser | but ok. i'll fix anywy. its just a matter of putting '[*]' i think | 17:55 |
| smoser | roaksoax, so i definitely think its a race condition based on running that maas-set-ip in rc.local | 17:58 |
| roaksoax | may be indeed | 18:04 |
| === dpb_ is now known as Guest78961 | ||
| adam_g | https://bugs.launchpad.net/juju/+bug/1021861 | 18:25 |
| ubot5 | Ubuntu bug 1021861 in MAAS "Transient error /w MAAS provider: Unknown operation: 'list_allocated'." [Undecided,New] | 18:25 |
| adam_g | am i the only one hitting this? seems 25% of juju's commands are failing because of it | 18:26 |
| realnorth_ | anyone know of a way to boot an iso other than ubuntu? | 18:32 |
| realnorth_ | like for booting up a node | 18:35 |
| roaksoax | realnorth_: While it is not supported, nor recommended, you could hack your way around it | 18:39 |
| realnorth_ | how? | 18:40 |
| roaksoax | realnorth_: you'd have to import an iso and replace the profiles within cobbler | 18:40 |
| realnorth_ | for ubuntu? | 18:40 |
| realnorth_ | I would have to replace the ubuntu profile with the one I want booted? | 18:41 |
| roaksoax | realnorth_: you would have to point the profiles to a different distro | 18:41 |
| realnorth_ | okay | 18:41 |
| realnorth_ | understood | 18:42 |
| realnorth_ | thanks | 18:42 |
| lifeless | roaksoax: juju uses the address the provider supplies | 20:29 |
| lifeless | roaksoax: maas provider can supply ip addresses | 20:29 |
| lifeless | roaksoax: I was thinking about this overnight and there is no need for dns integration at all for the juju hyperscale story AFAICT | 20:30 |
| roaksoax | lifeless: TBH, I do not know how things have changed from back when I did the initial orchestra/juju work, but at the time, juju (ensemble at the time) did not support the use of IP address and it was made very clear to me that it will never do that | 20:31 |
| lifeless | roaksoax: the openstack provider shoves the ip address into the host fields. | 20:33 |
| lifeless | roaksoax: and I have a patch I run here that uses ip addresses for ec2 to make devstack installs work properly. | 20:34 |
| lifeless | roaksoax: so, there may be political issues. But concretely speaking, it works, and well, to just use IP. | 20:34 |
| lifeless | roaksoax: in case you're thinking 'but using DNS protects from ip changes in ec2' or whatever - it doesn't: ec2 dns names are 1:1 with IP, if IP changes, DNS name changes too. | 20:35 |
| lifeless | the only reliable mapping is instance id -> public,private hostname. | 20:35 |
| roaksoax | lifeless: I see, well I don't have anything against juju addressing to the machines via ip rather than hostna,me, as I was pushing for that back then. | 20:35 |
| lifeless | yah | 20:36 |
| lifeless | so as an experiment you could try changing the maas provider locally to use the ip address | 20:36 |
| roaksoax | lifeless: the only thing though, is the maas juju provider name constraints (as detailed on the email) | 20:36 |
| roaksoax | use hostnames | 20:36 |
| lifeless | I think we need to reevaluate some of the stack here | 20:36 |
| lifeless | e.g. | 20:36 |
| lifeless | is that sensible for a 10K install | 20:37 |
| lifeless | if not, ok, so how do we do it for a 5 node install | 20:37 |
| roaksoax | but I think that's merely knowing the name whithin maas and then communication can be done through IP | 20:37 |
| lifeless | for a 5 node, I can imagine labelling the node in the MAAS UI, and letting the API say 'this named node', and yeah - after that, IP all the way. | 20:37 |
| roaksoax | lifeless: yeah in the email I detailed my position about defining a ip based hostname works for hyperscale but not for small deployments where admins might want to set names to identify their machines | 20:38 |
| roaksoax | lifeless: an yeah I agree, as the email mentioned, at ODS we used the named constraints to install certain components on certain machines and I think that's a feature that hsould be kept | 20:38 |
| roaksoax | but the apprach can be changed to use IP address as communication and the hostname as simple labelling | 20:39 |
| lifeless | roaksoax: you realise you went off-list ? | 20:53 |
| roaksoax | lifeless: yes | 20:54 |
| lifeless | robbiew: Hey, I'm around anytime | 20:56 |
| robbiew | lifeless: cool...in an hour work for you? | 20:56 |
| lifeless | sure | 20:57 |
| realnorth_ | is there a link for all the environment variables I can use? | 21:25 |
| realnorth_ | there doesn't seem to be a whole lot of information on what I can use or change | 21:26 |
| realnorth_ | or add | 21:26 |
| lifeless | hi | 21:43 |
| lifeless | its all meant to be via the UI | 21:43 |
| lifeless | as MAAS runs as a daemon | 21:43 |
| lifeless | is there something in particular you are looking for? | 21:43 |
| lifeless | robbiew: just putting cynthia to bed; may be a little late as a result | 21:52 |
| lifeless | robbiew: ok, so am ready when you are | 21:56 |
| robbiew | lifeless: coolio | 21:59 |
| robbiew | g+? | 22:00 |
| lifeless | sure | 22:00 |
| lifeless | invite winging its way to you now | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!