[00:24] smoser: rharper release 18.3 branch [00:24] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254 [00:24] then I can push an MP for cosmic [00:25] will check back in a couple hours [01:08] blackboxsw: ah. ok. i had thought throw snapshot into cosmic [01:08] and then tomorrow do a release. [01:14] blackboxsw: i think if the goal is just to upload to cosmic with a 18.3, then lets wait til morning before we tag. [01:14] that will get us a nightly c-i run on trunk also. [01:24] blackboxsw: i went ahead and kicked off a 'Build Now' for each recipe [01:24] https://code.launchpad.net/~cloud-init-dev/+recipes [01:24] so we'll have daily archive up to date shortly with master (a670eb81) [01:24] with fingers crossed that there are no keyserver demons lurking [01:26] alright. landing https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily/+packages [01:26] and i'm going to take off on that note. [02:30] sounds good scott === shardy is now known as shardy_afk === shardy_afk is now known as shardy [15:05] ok... as a form of version control http://paste.ubuntu.com/p/tcj3QhSmGD/ [15:05] that is skip_by_date as a decorator, i plan to try to put it into curtin soon. [16:03] rharper: https://code.launchpad.net/~smoser/curtin/+git/curtin/+merge/348282 [16:03] oops. [16:06] hehe [16:15] smoser: so SRU and https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254 [16:15] shall I push an 18.3 tag to upstream to get CI to work there and get that landed? [16:16] and we cut a cosmic, xenial artful bionic set of merges? [16:48] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254 [17:27] hrm ok smoser rharper , I've bungled/missed something with pushing my tags and trying to push 18.3 to origin(upstream). [17:27] ok [17:27] I think I've pushed 18.3 tag to our common repo for cloud-init [17:27] git tags --list shows it when I have master checked out. yet git log --decorate doesn't decorate the proper commit with the tag name [17:28] i think a rebase happened or something.... [17:28] I do see the tag decorating my specific branch release/18.3 [17:29] probably in your merge review thing [17:29] upstream/master is differant than the tag [17:29] i can fix or you can, but essentially [17:29] git checkout master [17:29] git reset --hard 18.3 [17:29] git push upstream master --force [17:30] or probalby that is just [17:30] git push upstream 18.3:master --force [17:30] or something [17:31] ok worked. I'll sort what review-mps did/does as it merges the branch locally (giving us a different commitish I think). [17:31] right [17:31] what it could do is [17:31] git merge --ff-only [17:31] right, I think. [17:32] if there was 1 new commit and that worked, it could do that. [17:32] other wise, it woudl rebase and squash like it does. [17:32] yeah multicommits we'd have a problem as we are squashing [17:32] yeah [17:32] ok will add that to review-mps today. single commit --ff-only option [17:33] i think i'd just have it do it if it could [17:36] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348300 is up [17:38] ok. before we do that lets get the release into launchpad [17:38] blackboxsw: can you take a quick glance at changelog for highlights ? [17:38] ah. i knwo. hackmd link coming. [17:39] https://hackmd.io/lIMTEWtaSpGgrleLM0pJBQ [17:39] blackboxsw: ^ [17:52] checking [17:54] blackboxsw: just sent. [17:54] you were too slow :) [17:54] no big deal. [17:55] heh, nice. my coffee machine was too slow you mean [17:55] is it worth me scripting all bugs mentioned in changelog to the given milestone? [17:56] ? [17:56] per the "35 launchpad.net issues" fixed [17:56] oh. i did that sort of [17:56] and updated that doc [17:56] we could target them to https://launchpad.net/cloud-init/+milestone/18.3 [17:56] so they'd show there [17:56] too [17:57] we could do that. and i guess do that in lp-bugs-released.... i dont know. [17:57] as a point of reference in the future for stuff that was fixed [17:57] yeah I was thinking lp-bugs-released extension [17:57] i'm going to run the lp-bugs-released script now. [17:57] is that ok ? [17:57] +1 [17:57] k [17:57] I have a tweak for specific bug series task. I think which might help as the SRU progresses [17:58] a tweak to only target the specific bug distro-series task rather. [17:58] ? [17:59] the lp-bugs-released only does upstream [17:59] right? [17:59] right, but it could do individual series tasks too per something like https://launchpad.net/cloud-init/+milestone/18.3 [18:00] WIP patch obviously. I was just peeking at it. [18:00] oops bad paste [18:00] http://paste.ubuntu.com/p/k6tTxnzTrN/ [18:01] i just fixed the "version " [18:01] * blackboxsw gets merge proposals for xenial,artful, bionic together now (and filing an SRU bug) [18:01] smoser: you haven't filed an SRU bug yet have you? [18:03] no. [18:04] ok filing [18:05] bug mail coming in 5.... [18:05] 4, 3, 2, 1 [18:06] blackboxsw: ok. on that note, i have to run. i'll be back in later and can do uploads for sru then. [18:06] ok thanks man [18:06] i think release is all done now. [18:07] dragging the trello card === r-daneel_ is now known as r-daneel [19:16] smoser: I pushed minor changes into new-upstream-snapshot [19:17] to account for debian/changelog containing xenial-proposed instead of xenial [19:32] 3 branchs for SRU upload review tied to this card smoser https://trello.com/c/8jshO6oa/847-sru-183-to-xenial-artful-and-bionic [19:32] *branches* [19:47] * blackboxsw needs to tweak artful and xenial branches there. we need to disable OpenstackLocal.network_config by default [19:48] as it is configurable to "apply_network_config: true" in datasource config [19:48] and we don't want to change artful/xenial behavior... maybe bionic too? WDYT rharper smoser [19:49] right, I think we played some games with the names in the datasource class when we did this with AzureDatasource [19:50] rharper: the way I wrote DataSourceOpenstack.network_config property we now check if ds_cfg.get('apply_network_config') == False: return None. This renders fallback config (which is what xenial->bionic do today) [19:51] question I have is, should bionic continue to only render fallback config :/? [19:51] yes [19:51] ok will apply a patch for those releases [19:51] to adjust the default behavior to fallback for all 3 series [19:52] let me think on it a bit too; IIUC, we could run "faster" but only render fallback config [19:52] which wouldn't change functionality, just the speed, right ? [19:52] where as in cosmic, we could read network_data.json over metadata service at local and render that instead of fallback [19:54] correct on all counts. we could either patch to remove DataSourceOpenstack.network_config subclassed property altogether (to run faster and retain exact current behavior). OR - [19:54] we could patch Openstack.network_config to default to apply_network_config == False if not provided, thereby allowing someone to override that and react to network_data.json if they want (a little slower as we check a config option value before rendering fallback config) [19:55] I think we want the 2nd choice on Xenial-Bionic as it is a useful feature to turn on if someone wants it [19:55] though I think they'd have to turn it on in their images, not user-data [19:56] yes; I'm included to keep fallback rendering for OS metadata service in Xenial -> Bionic, but run at local if we can [19:56] ok good deal [19:56] that produces a speedup ( \o/ ) without a change in function [19:56] let's see if smoser agrees [19:56] yeah exactly, local timeframe == speedup [20:29] blackboxsw: I was going to take a look at lp#1733226 and thought this may not lead too far down the rabbit hole, but turns out that dhclient stuff appears to be splattered across data sources and other parts of the code [20:29] so I need some guidance and maybe this is too big of a project to start on late Wednesday afternoon and better wait for THursday morning [20:46] bug #1733226, yeah that's a not easy to start late Wedneday robjo : / [20:46] bug 1733226 in cloud-init "cloud-init-local service fails on SUSE distros" [Undecided,New] https://launchpad.net/bugs/1733226 [20:47] yeah the context hander and sandboxed environment with dhclient vs wicked is potentially a bit of a dig [20:48] OK, I'll ping you another day [20:49] hrm, so was this Openstack robjo ? [20:49] could you cloud-init collect-logs and add the tarfile? [20:49] I do not know, I can ask in the bug report I do not know the reporter [20:50] or Ec2/Azure maybe? those are the 3 major datasources that use it currently [20:51] Lets see if we get an answer [20:52] it may be as simple as just replaceing dhclient with wicked, but there is lease processing etc.. and I haven't looked at how wicked stores dhcp-related conf etc. (I'm guessing that's in my immediate future) [20:56] sounds good robjo, yeah we need to fix this for SLES it seems as this EphemeralDHCPv4 context manager is the direction most datasources are oging [20:56] *are going [20:56] Well, I'll do leg work, but the idea of having to change 3 data sources and then doing so for others potentially in the future is not very appealing, seems there should be an abstraction ;) [20:57] robjo: yeah it's all in cloudinit.net.dhcp maybe_perform_dhcp_discovery [20:57] might want to extend it to accept network_util='dhclient' default [20:57] which could be overridden with wicked I suppose [20:58] Found that file, but also saw in the azure datasource I think (via grep) what looked like hard coded info about lease info [20:59] ohh yeah, yuck right. hardcoded dhcp lease path [20:59] given the we're "special" :rolling_eyes: maybe this should not be distro independent, but I suspect major surgery is required to make this distro dependent [21:00] though that datasource already does a switch on util.is_FreeBSD to tweak expected lease_file path on different distros [21:03] hrm maybe distro could announce default network_cmd, we also have to solve this for a netplan-only world too, as dhclient is not really a mandatory command in newer ubuntu series. [21:04] so this is a type fix that is on our radar, just hadn't tried tackling it yet because we didn't need to... yet. [21:04] network_cmd would probably be a dict then if we want to support the lease monitoring part we'd need at least dhcp_client_cmd,dhcp_client_options, lease_info [21:07] and interface [21:07] could be, I'm kindof leaning toward the idea that maybe_perform_dhcp_discovery should be smart enough to detect valid dhclient commands and make a sane choice based on present of the utility so that we don't continue to bloat the Distro classes. but it'll require a bit more thought for the use-cases [21:07] *based on presence/absence of the utility* [21:08] I liked what you did w/ ifconfig vs ip stuff [21:08] it feels like it contains that logic in a single place local to where it is being used (even though it's kindof distro related) [21:10] but again, I'm not certain this EphemeralDHCPv4 solution is strictly compatible with a systemd networkd -only world. [21:10] one idea we were tossing around was to write our own tiny python dhclient which opens a socket to do the dhcp discovery [21:11] all we are attempting to do is sniff a lease on the primary nic if available. [21:11] this may be time for us to queue that work : [21:11] this may be time for us to queue that work :/ [21:12] * blackboxsw and socket programming from python. not a well used muscle. [21:12] The advantage of ifconfig/ip transition is that ip options are universal, but for the dhcp stuff distros, staring with SLES have clearly diverged and it appears there may be further drift, so having "smart" handling in one place may lead to lots of if-elif-elif code [21:13] well getting a dhcp request out in and off itself is not all that difficult, what I don't know what effect that has on subsequent requests [21:14] For example when AWS added ipv6 and wicked sent out options the dhcp server didn't understand they just didn't respond [21:15] so no lease :( [21:15] presumably a cloud-init implementation of get_dhcp_lease() would not send any option or only a minimal set [21:16] but then what does the dhcp server do when the next request comes from the same origin, does it just return what it already handed out and ignore other options that might be sent along? [21:16] I have no idea how that works [21:18] And maybe this topic is too big for IRC and e-mail and we should beat on it during the summit [21:18] correct, cloud-init's get_dhcp_lease() would be a dumb/simple dhcp-discovery packet without any custom options. It'd blindly return a dict of whatever lease options the response gave. Generally the dhcp server ends up giving out the same IPs on previous discovery if the lease time hadn't expired I believe. (as it's how it's currently working in ec2/openstack. [21:18] agreed, it's a big topic. I think you are right. [21:19] I'll add it to the list of potential topics [21:19] currently I have the following: [21:19] topic ideas: [21:19] - move SLES & openSUSE to sysconfig renderer [21:19] - hotplug network stuff (one-shot stuff) [21:19] - cloud-init as a daemon for repeatable calls, expedited boot runs [21:19] - wicked support for EphemeralDCHPv4 [21:20] as we get closer that list will probably grow into a hackmd doc we can all comment on that we will send to the mailinglist [21:21] David already had a preliminary agenda, I take it you'll coordinate with that ;) [21:23] yeah if I have to ;) [21:33] blackboxsw: another alternative that we've discussed multiple times but never dig to the bottom is replacing dhclient with cloud-init dhcp client in python itself; then Ephemeral would not have to depend on dhclient which may or maynot be present, etc [21:33] so, in the agenda, maybe replace wicked string with 'EphermalDHCP alternatives to isc-dhcp client' [21:34] we've the same issue in Artful/Bionic/Cosmic though we pull the dhclient in now; really that shouldn't be in there as networkd procides a dhcp client as well [21:42] I added a short summary to bug #1733226 [21:42] bug 1733226 in cloud-init "cloud-init-local service fails on SUSE distros" [Undecided,New] https://launchpad.net/bugs/1733226 [21:42] having a cloud-init get_dhcp_lease() is included as option 4 [22:04] blackboxsw: thanks for remembering about the datasource local in bionic. [22:04] i think we should bite the bullet there. [22:04] yeah a quick grep of RELEASE_BLOCKER [22:05] we need to retire/remove the snap modules too :/ [22:05] the old snappy etc. [22:05] but not critical [22:05] yeah, that snot a big deal. [22:05] hm... [22:05] * blackboxsw is wondering how best to cherry pick the ubuntu/xenial/debian/patch/openstack* into ubuntu/artful which has no patches dir... [22:06] was trying ./debian/cherry-pick, but it falls over because there is no existing debian/patches/series file [22:06] wondering if I manually do the work in artful and then cherry pick to bionic (which also has no patches subdir/series [22:08] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348309 [22:08] that has fail build right now [22:08] shoot. [22:09] bah have to fix unit tests too :/ [22:11] lets think. [22:12] one thing we generally want to do is update the ubuntu/ branches right after we land something like this [22:12] so that our daily builds would have been doing this sense it weent in. [22:13] * smoser shoudl have remembered that and done something then [22:20] the following would work for ubuntu/xenial I think http://paste.ubuntu.com/p/mNNQgwTPcT/ [22:20] it tweaks the unit test which will fail (after debian/patch applied) to present the right ds_config setting True [22:28] blackboxsw: i'll give this a good think tomorrow. would like to get an sru upload in, but want to think it though. [22:29] yeah I was thinking there's probably not enough time to talk through the options. [22:29] I'll fix xenial so we have a strawman on the approach, to shoot down if need be [22:29] artful/bionic are bogus, so I'll pull them, [22:32] ok pushed xenial again, will let CI run it's course [22:33] gotta take a break [22:53] ok xenial mp is at least in good enough shape for discussion about the approach for patching desired openstack behavior https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348309 [23:21] rharper: do we need to change behavior of ntp/chrony on xenial->bionic with this upcoming SRU? [23:21] per bug #1749722 [23:21] bug 1749722 in systemd (Ubuntu) "NTP: take into account systemd-timesyncd where present" [Undecided,New] https://launchpad.net/bugs/1749722 [23:22] I think not, but wanted to be sure