[00:58] smoser: btw, I might have a gsoc person do the gentoo cloud-init revamp === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy [14:32] prometheanfire, that'd be cool! [14:32] Odd_Bloke, re-thinking what i said yesterday. [14:33] this is not terribly different than what azure accomplishes in their datasource [14:33] they handle re-running the mkfs and mounts === rangerpbzzzz is now known as rangerpb [15:55] smoser, nice email response .... i was just thinking through the use of the ovf file for the hostname, remember that azure ejects the "cdrom" with that file after it completes provisioning ... do you think that is going to be problematic for reboots, etc? [15:57] no. it should be ok. it is guaranteed to be there on first boot, and we check to see if the cached instance-id is the same as the current instance id (provided in smbios) to determine if hte cached value is valid [15:57] and fwiw... they say they eject it, but i've never seen that happen. [15:58] :) [15:58] (that said, my instances done last more than 30 minutes normally) [17:00] smoser: re: the new ci stuff, is it possible to have launchpad take the merge proposal from the commit being merged in order to avoid "No commit message was specified in the merge proposal."? I am going to do a couple of copy-and-paste updates, but that seems like busy work. [17:02] larsks: it is not unfortunately. Basically setup to let you propose a new message in the event that you have many commits and assumes you want to squash them all into one with the new message, rather than the last. [17:02] Yeah, I understand the reason. I am just spoiled by github, which if there is a single commit will just adopt that commit message for the pr, and only give you an empty field if there are multiple commits. [17:03] ah that would be nice :\ [17:03] larsks, i know. its a pita. [17:03] that is what it shoudl do, like github. [17:08] smoser: I've updated those merge requests, so hopefully ci will be happy. Any chance you will have time to look at them? Fixes for #1670052 and #1669504 [17:10] just commented on https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/318800 [17:10] that looks fine other than the flake8 errors... [17:12] smoser: fixed and updated... [17:13] larsks, didi harlow mention at all where the hard 3 nameserver restriction comes form ? [17:13] smoser: I commented in the issue I think: it's referenced in the resolv.conf(5) man page. [17:13] and maybe, if it is really 3 per protocol (ipv4 or ipv6) then ideally we'd still check that ? [17:14] I don't think it's *per protocol*. [17:14] I am pretty sure it is "anything more than three will be ignored". [17:14] k [17:28] larsks, for the resolvconf, lets at least WARN which ones we're adding. or more clearly state "only the first 3 are will be used" [17:29] Aren't we doing that? It logs a warning message with the nameserver that is being ignored. [17:29] Line 25 in the review. [17:31] if you just read that message, is it clear to you waht its going to do ? or what it did ? [17:31] it somewhat makes sense if it raises an exception [17:32] I don't think it makes sense at all if it raises an exception. THat means that data in your cloud providers environment can prevent you from logging into your new instance. [17:32] That seems like a real problem. [17:32] i agree with you there. [17:32] i was saying that the *message* makes sense as an exception [17:32] but not as a warning [17:32] raise Exception("Too many nameservers") [17:32] but as a warning: [17:33] Okay. [17:33] So..."Ignoring nameserver %s because that would exceed the maximum of 3 nameservers"? [17:33] well, "using the first 3" or something like that. [17:40] smoser: that message will get logged once per nameserver (for each ns beyond 3). Does "using the first 3" make sense (i.e., will someone reading the logs know what "the first 3" are?) [17:42] How about that (update I just pushed)? [17:42] lookiong [17:47] larsks, that looks good, thanks. looking at only the mp and not enough context, i was thinking that 'ns' was the list, not an individual name server. [17:49] Okay. New question, unrelated: I am trying to resolve a dependency cycle between cloud-init and os-collect-config (on RHEL). What is the goal of having cloud-final.service run After=multi-user.target? [17:49] (I'm not entirely sure what happens during the -final step)' [17:53] larsks, that one is merged. the other https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/318800 did you think you pushed flake8 fixes ? [17:53] smoser: I thought I did, but let me double check. [17:54] i just fetched here and 'tox -e flake8' showed errors (0e5610fd08) [17:56] There. [17:56] having final run after multi-user.target ... we ended up doing that to avoid some issues witih package instaallation [17:56] commit 34a26f7f59 talks about it and references 2 bugs that we were hitting. [17:57] Thanks, I'll take a look. [17:58] if package installation worked fine prior to multi-user.target on redhat (it may well .. due to services not starting by default), then i'm not opposed to it being different there. [17:58] the goal really is for '-final' to run "as late as possible" [17:59] see the somewhat limited text description i wrote at doc/rtd/topics/boot.rst [18:01] I was guessing I would find --no-block somewhere in there, and I did :) [18:47] smoser, ive been poking around the cloud-init code ... the suggestion to set the hostname from the cdrom metadata is prob worth pursuing. Did you have a place in mind for that? At what point in the cloud-init cycle is the network set up ? [18:51] rangerpb, give me a minute, i'll take a quick poke and give you a diff that might helip you get started. [18:51] awesome [19:46] rangerpb, http://paste.ubuntu.com/24132495/ [19:46] thats what i have... there is non-trivial work there. [19:46] the setting of hostname in this manger is generally i think a good thing (tm) [19:48] The other option would be for azure to act more like DigitalOcean and in its local data search, it could dhcp, bring up the network do all the configuration and then take it down, and let the OS bring it up. In its 'get_data()' then that would run in local mode, it would have to read the ovf file, and invoke dhcp and negotiate with the metadata service for the ssh keys. I don't think this is supportable with the legacy "use walinu [19:48] xagent path". [19:48] right [19:48] getting to the ideal is not going to be trivial [19:49] generally speaking though, setting the hostname "centrally" is a win i think [19:50] yeah big time === Hazelesque_ is now known as Hazelesque [21:22] Hi, Just yesterday I got an email from Server Team CI bot about continuous integration failure. I looked into the failed log. Doesnot seem like anything to do with my change. This is my branch https://code.launchpad.net/~msaikia/cloud-init/+git/cloud-init/+merge/305427 [21:22] Any steps that I need to take to fix it? [21:26] msaikia: you are right, the issue was fixed in a later version of cloud-init that was trying to access the local maas cfg files === rangerpb is now known as rangerpbzzzz