| === matsubara-afk is now known as matsubara | ||
| czajkowski | rvba: morning | 09:20 |
|---|---|---|
| rvba | \o czajkowski | 09:20 |
| czajkowski | rvba: I have one more Q in for you. I suspect more will come in over the next 2 days and the others will get another one each. https://answers.launchpad.net/maas/+question/202282 | 09:21 |
| rvba | czajkowski: k. | 09:23 |
| rbasak | I got a failure on "make test": http://paste.ubuntu.com/1076131/ - fixed by installing libpq-dev as specified by the error. This needs to be added to HACKING.txt I presume? | 09:40 |
| rbasak | BTW, the detail in HACKING.txt is awesome and just saved me tons of time. I really appreciate it being there. Every upstream should have something so detailed. | 09:40 |
| rvba | rbasak: thanks for reporting that. I'll fix HACKING.txt. | 09:55 |
| rbasak | np | 09:55 |
| === matsubara is now known as matsubara-afk | ||
| jtv | Daviey: can you help us out with a dev question? We're dealing with approaches to updating DNS zone files for changing node IPs, and we're just not sure what the uses and requirements are. | 11:46 |
| jtv | roaksoax or smoser maybe? | 11:47 |
| Daviey | jtv: ok | 11:48 |
| Daviey | jtv: Can you state the problem? | 11:49 |
| jtv | The problem is that we're trying to implement the “update DNS based on the latest IP address information for the nodes” story but we don't know what those DNS updates are needed for. | 11:49 |
| jtv | Which leaves us without criteria for evaluating solutions. | 11:49 |
| jtv | The particular point we're stuck on is the latency/robustness/throughput tradeoff: how soon do we need DNS to be updated, and how important is that? | 11:52 |
| Daviey | jtv: Hmm | 11:54 |
| jtv | And of course if we don't know why we need this at all, then things suddenly become very easy indeed. :) | 11:55 |
| Daviey | well, it's actually not super-quick-urgent stuff. The metadata service provides the hostname, which overrides the local hostname.. which would normally be set at install time | 11:55 |
| Daviey | The issue arises mostly when one node tries to talk to another node. | 11:55 |
| Daviey | jtv: Writing out a base A record zone file, loading it into bind, go home. | 11:56 |
| Daviey | also-notifying the slaves might be a little too much.. | 11:57 |
| jtv | You mean notifying the DNS slaves? | 11:57 |
| Daviey | yeah | 11:58 |
| Daviey | in the named.local you can put, also-notify X.X.X.X, X.X.X.X, X.X.X.X; for each zone, and it will ping the slaves for an update | 11:58 |
| Daviey | but that can be cron'd from the slaves to just update regulary | 11:58 |
| jtv | Daviey: so this is half-a-minute stuff rather than half-a-second stuff? | 12:01 |
| Daviey | jtv: oh, most certainly | 12:03 |
| jtv | Wow, that certainly puts things in a different light. Thanks! | 12:03 |
| Daviey | jtv: it's not uncommon for this to take 15 mins. | 12:03 |
| jtv | Well crucially, you're saying that's not a big problem? :-) | 12:03 |
| Daviey | when people talk about 'DNS propagation' they either mean the TTL to expire on clients OR the time it takes to push out to the slave DNS servers | 12:04 |
| jtv | Yes, we figured that bit out — the missing bit was what kind of service was actually required. | 12:06 |
| jtv | I'm writing it up now, before they kick me out of this coffee shop. Thanks again! | 12:07 |
| Daviey | jtv: Yeah, crucially the node knows about it's self via meta-data service | 12:08 |
| Daviey | It's other nodes contacting that node at speed, which could be problematic | 12:08 |
| jtv | That's the bit we need to know about though. | 12:08 |
| Daviey | but i can't imagine going from dns name change -> production service in under 60s | 12:08 |
| jtv | Putting a number on it is good. Thanks. | 12:09 |
| jtv | Really have to stop here! | 12:09 |
| Daviey | o/ | 12:10 |
| rbasak | For faster stuff, there are dynamic DNS updates. Perhaps cloud-init could do them? | 12:10 |
| jtv | nn people! | 12:11 |
| jtv | rbasak: too late. :-P The question wasn't how we can do this cleverly. Clever is often bad! The question was what was required. | 12:12 |
| * jtv really is off now. | 12:12 | |
| rbasak | I generally see "avoid race conditions" as an automatic requirement, because they almost always come back to bite. | 12:13 |
| allenap | rbasak: +1 ... if you want to comment, I've CC'd jtv's follow-on from this discussion to private-canonical-maas, with my response. | 13:58 |
| * rbasak looks | 13:58 | |
| rbasak | allenap: thanks. I don't think I have anything more to add. Speed of deployment with juju was my concern also. | 14:01 |
| allenap | rbasak: Cool. | 14:02 |
| rbasak | anyway I'm just a bystander :) | 14:02 |
| pmatulis | is there a non-devel m/l for maas? | 14:02 |
| allenap | rbasak: No you're not! A lot of this we're building for your ARM stuff :) | 14:03 |
| rbasak | :) | 14:03 |
| rbasak | Yes for ARM, but not for DNS! | 14:04 |
| allenap | Ah, fair enough. | 14:04 |
| * allenap writes "ARM does not need DNS" in feature document. | 14:04 | |
| rbasak | BTW, you'll be pleased to hear the the test suite almost completely smoothly on ARM. | 14:04 |
| allenap | \o/ | 14:04 |
| rbasak | Oh, you mean I didn't tell you about how ARM servers do DNS differently? :-P | 14:05 |
| allenap | rbasak: It'll be QA that breaks hard on ARM. | 14:05 |
| allenap | rbasak: With Yellow Pages, right? | 14:06 |
| rbasak | I was kidding. It's exactly the same | 14:06 |
| rbasak | You can use yp if you want | 14:06 |
| allenap | Do not want. | 14:06 |
| rbasak | Userland is pretty much all the same on ARM. Just minor porting issues. And Java issues. | 14:07 |
| roaksoax | Daviey: the DNS *is* important | 14:27 |
| roaksoax | Daviey: juju accesses the nodes based on hostnames | 14:28 |
| roaksoax | if juju can't resolve to a hostanem, then uju doesn't work | 14:28 |
| Daviey | roaksoax: right, i'm saying that if it doesn't happen within the first 60 seconds of a node being commissioned.. it's pretty safe. | 14:30 |
| Daviey | it won't make the world fall apart if i add a node, and it's not resolvable within the first 60 seconds. | 14:30 |
| Daviey | I can't imagine juju will be usable within that time. | 14:30 |
| roaksoax | Daviey: right, as long as juju can handle it we should be fine | 14:31 |
| roaksoax | Daviey: anyways, did you see the missing file if I remove the sphinx-issue tracker dep? | 14:31 |
| roaksoax | smoser: where's your bug about the oauth issues? | 14:31 |
| Daviey | roaksoax: i didn't see it no.. is it all good and gone? | 14:32 |
| roaksoax | Daviey: if I remove the build-dep, then this file is missing for python-celery-doc: /usr/share/doc/python-celery-doc/html/_static/issuetracker.css | 14:33 |
| Daviey | roaksoax: I think that is safe.. | 14:34 |
| roaksoax | Daviey: alright then, I'll ditch the Dep then | 14:35 |
| Daviey | roaksoax: wait 2 | 14:35 |
| roaksoax | Daviey: sure:) | 14:36 |
| Daviey | roaksoax: did you check that issuetracker.css isn't referenced in the new docs? | 14:40 |
| Daviey | I think that is added to the html files at build time, but haven't confirmed | 14:40 |
| roaksoax | Daviey: i'm rebuilding the packages to confirm. | 14:40 |
| * roaksoax hates having a crappy network | 14:41 | |
| roaksoax | Daviey: ye it seems it doesn't get referenced | 14:52 |
| roaksoax | Daviey: so we should be good to remove it | 14:53 |
| roaksoax | Daviey: so I'll go ahead with it | 15:07 |
| === matsubara-afk is now known as matsubara | ||
| roaksoax | Daviey: do you agree? http://paste.ubuntu.com/1076635/ | 15:57 |
| Daviey | roaksoax: yep | 16:27 |
| Daviey | roaksoax: you checked the generated docs don't include the issuetracker.css? | 16:27 |
| roaksoax | Daviey: yep: (a) Current one: http://paste.ubuntu.com/1076673/ (b) patched one: http://pastebin.ubuntu.com/1076676/ | 16:29 |
| Daviey | roaksoax: cool! | 16:36 |
| Daviey | go go go | 16:36 |
| roaksoax | Daviey: lol, haven't heard the gogogo! since I last played Counter Strike few years back lol | 16:36 |
| Daviey | roaksoax: Contact Front, Wait out. | 16:38 |
| roaksoax | lol | 16:38 |
| Daviey | roaksoax / smoser: Can you work out what changes need to be done to use the ephemeral environment for enlistment. I'm expecting little more than adding a few entries to the kernel cmd line for cloud-init to do the enlistment. | 18:01 |
| Daviey | (still maintaining seperate cd based enlistment) | 18:01 |
| roaksoax | Daviey: it would be similar to the boot image really | 18:02 |
| roaksoax | Daviey: run a script on boot to try to enlist | 18:02 |
| Daviey | roaksoax: right, but the key is making cloud-init be the handler | 18:03 |
| Daviey | roaksoax: so cloud-init invokes maas-enlist | 18:03 |
| roaksoax | Daviey: yeah so should be even simpler then | 18:03 |
| roaksoax | Daviey: cloud-init should simply invoke maas-enlist with the arguments needed and that's it | 18:03 |
| Daviey | roaksoax: Then MAAS just needs the default preseed change, should be trivial | 18:03 |
| Daviey | roaksoax: right.. i can't imagineit's super complicated | 18:04 |
| roaksoax | Daviey: shouldn' | 18:04 |
| roaksoax | Daviey: shouldn't be. I guess it would just need to be different meta-data | 18:04 |
| Daviey | roaksoax: well, the meta-data cpuld be provided from the kernel cmd line | 18:05 |
| roaksoax | Daviey: yeah, but we either provide a different URL for where to get the meta-data, or we modify the meta-data in the process | 18:07 |
| roaksoax | Daviey: err, I think we would just need to ,provide enlistment meta-data | 18:07 |
| roaksoax | Daviey: has it being thought of making enlistment+comissioning one single step? | 18:08 |
| Daviey | roaksoax: That is the next thing :) | 18:13 |
| Daviey | roaksoax: so.. a kernel cmd line 'metadata service' is just as valid as a http one | 18:13 |
| roaksoax | Daviey: right, so that means you want to send the metadata in the kernel command line then? | 18:20 |
| Daviey | roaksoax: yep | 18:23 |
| roaksoax | Daviey: wouldn't it be easier to have the metadata in the MAAS server and just send a URL where to be obtained from? | 18:24 |
| Daviey | roaksoax: Added complexity IMO. | 18:25 |
| Daviey | The metadata currently detects what metadata data to supply based on oauth credentials | 18:25 |
| Daviey | As this is a new node, there are no creds | 18:25 |
| Daviey | So... That requires additional upstream work | 18:25 |
| Daviey | Note, that the metadata url still have to be provided via kernel cmd line.. So it's an extra leap for no sound reason IMO | 18:26 |
| roaksoax | Daviey: right, but it is simpler to provide a URL than metadata through the kernel command line. Either way, we only need to pass MAAS server IP address basically | 18:28 |
| roaksoax | Daviey: and the hostname that the image obtains | 18:31 |
| roaksoax | Daviey: from the DNS server | 18:31 |
| roaksoax | if there's one | 18:31 |
| roaksoax | from DNS or DHCP | 18:31 |
| Daviey | roaksoax: hmm yeah | 18:33 |
| ahasenack | hi, is there a way to release a node back into the pool via the maas UI? | 19:33 |
| ahasenack | I see only "delete" which might be relevant, but it's greyed/disabled | 19:34 |
| dpb___ | Hi all -- how do I release a maas node? | 19:40 |
| roaksoax | ahasenack: there's none, that's done via juju | 20:47 |
| ahasenack | roaksoax: you mean it's done via the api | 20:50 |
| roaksoax | ahasenack: or the api | 20:50 |
| ahasenack | ok | 20:50 |
| ahasenack | roaksoax: if I do a "cobbler system remove", maas might crash? | 20:50 |
| ahasenack | that is the equivalent of "delete" probably, which is grayed out for a reason | 20:51 |
| roaksoax | ahasenack: removing from cobbler is deleting a system in maas, deleting it in cobbler might be harmful to maas | 20:51 |
| ahasenack | roaksoax: ok | 20:51 |
| ahasenack | roaksoax: there is no command-line api tool for maaas, right? | 20:51 |
| roaksoax | ahasenack: that's in progress | 20:52 |
| ahasenack | ok | 20:52 |
| roaksoax | ahasenack: you want to set back to ready a node that's been allocated? | 20:52 |
| ahasenack | roaksoax: yes | 20:52 |
| roaksoax | ahasenack: how was it allocated in the first place? | 20:52 |
| ahasenack | roaksoax: just booting and accepting it in the maas ui | 20:52 |
| roaksoax | ahasenack: that leaves the node in Ready state | 20:52 |
| roaksoax | 1. first boot -> enlist | 20:52 |
| roaksoax | 2. 2nd boot -> commission | 20:52 |
| roaksoax | that leaves the node in Ready state | 20:53 |
| ahasenack | hm, it said it was allocated to "ubuntu", my user | 20:53 |
| roaksoax | allocated state means that you used juju deploy/juju bootstrap, | 20:53 |
| ahasenack | no juju involved | 20:53 |
| roaksoax | uhmmm | 20:53 |
| * roaksoax checks | 20:53 | |
| ahasenack | I could have done some weird things the first time, just poking around | 20:53 |
| roaksoax | IIRC ready state is the state when it has been commissioned | 20:54 |
| ahasenack | but that wasn't the point anyway, just wanted to know how to put it back in the pool | 20:54 |
| ahasenack | and the answer is "using the same tool that allocated it in the first place" | 20:54 |
| ahasenack | roaksoax: thanks | 20:55 |
| roaksoax | yw | 20:56 |
| === matsubara is now known as matsubara-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!