knaccchey y'all, is it correct that I should not be editing 50-cloud-init.yaml to put in a custom nameserver list or search domains, and should instead create a /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg and then...? any help greatly appreciated04:22
knaccci'm very confused that when i set up the custom DNS servers ( etc), "systemd-resolve --status" shows that it's recognizing that for "Link 2 (enp3s0f0)", but not for "Global". and i think therefore for some reason it's ignoring my DNS settings and search domain04:26
knacccthe server has 2 eth interfaces, and only one is configured,04:26
Odd_Blokeknaccc: cloud-init will regenerate /etc/netplan/50-cloud-init.yaml on each boot, so yes, you don't want to modify that.  If you're still having the issue, please pastebin all config you have in /etc/netplan and we can try to help out. :)13:51
=== goneri_ is now known as Goneri
blackboxswrharper: lucasmoura Odd_Bloke falcojr this would be additional set of commits if we ran new-update-snapshot https://pastebin.ubuntu.com/p/qVMwsrKHKH/15:32
Odd_BlokeThat LGTM, would definitely be nice to get that Chef change in.15:33
rharperblackboxsw: yeah, +115:34
blackboxswrharper: Odd_Bloke falcojr lucasmoura https://github.com/canonical/cloud-init/pull/411  upload of new-upstream-release for groovy and SRU afterward15:53
Odd_Blokeblackboxsw: Reviewing now.16:09
blackboxswthanks Odd_Bloke focal right after it https://github.com/canonical/cloud-init/pull/41216:15
blackboxswsame changeset basically16:15
blackboxswI have to change the eoan bionic and xenial a bit more16:16
blackboxswaaand cloud-init status tim16:16
blackboxswaaand cloud-init status time16:16
Odd_Blokeblackboxsw: Cool; one note: we have a lot of stale Build-Depends now: unittest2 isn't required, six isn't required, and we've stopped using pyflakes and pep8 directly (and my local build didn't fail due to the absence of flake8, so I don't think we need to replace it).16:18
Odd_Bloke(That build was on focal, I'm just bootstrapping a groovy build env now, to test the actual correct release.)16:18
blackboxsw#startmeeting cloud-init status meeting16:21
meetingologyMeeting started Tue Jun  2 16:21:15 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.16:21
meetingologyAvailable commands: action commands idea info link nick16:21
blackboxswhi folks, time for another cloud-init upstream status meeting.16:21
blackboxswwe use this meeting to provide a venue for any cloud-init interested parties to keep up to date on current development, release-related info and expedite distributed development where possible.16:22
blackboxswthis meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point. so don't be shy :)16:22
blackboxsw#chair Odd_Bloke smoser rharper16:23
meetingologyCurrent chairs: Odd_Bloke blackboxsw rharper smoser16:23
blackboxswThe topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Office Hours (~30 mins).16:23
blackboxswprevious meeting minutes live here (and I just saw I forgot to publish last minutes so I pushed them now)16:24
blackboxsw#link https://cloud-init.github.io/16:24
blackboxsw#topic Previous Actions16:24
blackboxswnothing actionable brought up in last meeting on 05/1916:25
blackboxswOdd_Bloke: ahh we should fix devel with those pkg drops on next upload16:26
blackboxswwe did drop that for Xenial, Bionic Eoan and maybe focal too?16:26
blackboxswso an oversight for groovy16:26
blackboxswnext topic16:27
blackboxsw#topic Recent Changes16:27
blackboxswthe following are commits landed in tip of master found via git log --since 05/19/2020 : https://paste.ubuntu.com/p/QFvgWhjXY9/16:28
Odd_Blokeblackboxsw: When you say "next upload" are you referring to the upload you're about to do, or the one after that?16:28
blackboxswOdd_Bloke: if you'd like we can adjust the current upload so that devel, focal, bionic xenial eoan all drop those stale deps16:28
blackboxswI think X, B E have all dropped them16:28
blackboxswso maybe I re-do ubuntu/devel PR Odd_Bloke ?16:29
blackboxswprobably good/better/correct to keep all releases on the same footing.16:29
Odd_Blokeblackboxsw: I think it's worth doing, we've uploaded without fixing it a few times before, and we've remembered this time around.16:29
blackboxswyeah sounds good Odd_Bloke I'll re-do that devel PR (and make sure focal drops it too)16:30
blackboxswif needed16:30
Odd_BlokeAnd it should just be a case of pushing a new commit to your existing branch.16:30
blackboxswthings of note in the recent commits landed.  https://github.com/canonical/cloud-init/pull/358  Mattew Ruffell  improved cc_grub_dpkg to be more dynamic in matching disks instead of a hardcoded device list16:32
blackboxswthanks Matthew16:33
blackboxswand chef_license support https://github.com/canonical/cloud-init/commit/0919bd46bbd1b12158c369569ec1298bb000dd8a16:33
blackboxswthanks bipinbachhao  for the config extension there16:34
blackboxsw#topic  In-progress Development16:34
blackboxswa couple of new notables in flight at the moment:16:35
blackboxsw- falcojr: introduction of feature-flags for cloud-init upstream to give us a toggle to retain original behavior of #include failures on stable downstream releases. https://github.com/canonical/cloud-init/pull/367  . Upstream cloud-init will fail loudly and raise an Exception if someone tries to #include a url which fails. this differs from original cloud-init behavior which was to try our best to get a system up16:38
blackboxswand running, even amid not-critical failures16:38
blackboxswper the above, if downstreams (distributiions) would like to retain a more permissive warn on #include user-data issues, a cloudinit/feature_overrides.py file would need to be introduced in the downstream16:39
blackboxsw- Also meena and Odd_Bloke and others have been working toward a refactor of cloudinit.net modules. Dan added a doc PR to capture this approach https://github.com/canonical/cloud-init/pull/39116:40
blackboxswbeyond that, there are a number of PRs up from lucas on json schema additions for cloudinit/config/cc_* modules to get better validation of #cloud-config user-data16:41
blackboxswFor ubuntu proper, we have started the StableReleaseUpdate process for cloud-init to publish master into ubuntu/xenial, bionic, eoan and focal releases16:42
blackboxswsome of these changes will add the opportunity to enable 'new' features on platforms like Azure16:43
blackboxswand AWS16:43
blackboxswAzure (xenial) will be dropping walinuxagent support16:43
blackboxswAWS will now surface a datasource config option apply_full_imds_network_config boolean16:44
blackboxswif set true in an Ec2(aws) image network configuration from cloud-init can come completely from IMDS for every connected NIC. That config will include all secondary IPv4/IPv6 addressses configured for the machine16:45
blackboxswUpstream has  started the Ubuntu SRU process (which generally takes around 10-14 days). We plan to include every commit that has landed in tip of master as of commitish 5f7825e22241423322dbe628de1b00289cf3411416:46
blackboxswthe bug related to this SRU work is here16:46
blackboxsw#link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/188101816:46
ubot5Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-30) Xenial, Bionic, Eoan and Focal" [Undecided,New]16:46
blackboxsw#topic Community Charter16:47
blackboxswupstream has signed up to get as much of the json schema coverage as we  can for cloudinit/config/cc*py modules since invalid #cloud-config user-data formats tends to have one of the highest incidence of errors (because writing YAML is something humans shouldn't have to do :) )16:48
blackboxswso we are chopping away at defining JSON schema for as many cloud config modules as possible . there are still plenty to choose from. Anyone can feel free to grab a JSON schema bug and help us with bettering cloud-init16:49
blackboxswbugs are filed for each config module which needs schema definition:16:49
blackboxsw#link  https://bugs.launchpad.net/cloud-init/?field.tag=bitezise16:49
blackboxswa big thanks to lucasmoura for starting to grab a number of these16:50
blackboxsw#topic Office Hours (next ~30 mins)16:50
blackboxswThis 'section' of the meeting is a time where a couple of upstream devs will be available in channel for any discussions, questions, bug work or PR reviews.16:50
blackboxswIn the absence of discussions/topics here we scrub the review queue.16:51
blackboxswsince we are mid-stream on Ubuntu SRU at the moment, I'll be addressing review comments on some of the functional 'upload' branches we've put together16:51
blackboxswand, let's update the topic for next IRC meeting too while we are at it16:52
=== blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 16 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
blackboxswOdd_Bloke: just pushed ubuntu/devel dropping python3-six|unittest2|nose16:59
blackboxswand just re-pushed ubuntu/focal to drop python3-six17:01
blackboxswoops and missed you others. reworking17:04
blackboxswok re-pushed. focal and devel PRs in shape17:12
blackboxswdropped the following build-deps: python3-six, python3-unittest2, python3-pep8, python3-nose, python3-pyflakes17:13
Odd_Blokeblackboxsw: +1 on the ubuntu/devel upload.17:20
blackboxswwhew, think we got all of the dropped deps between the two of us... thanks!17:21
blackboxswOdd_Bloke: thanks focal looks good and sbuilds17:21
blackboxswjust finished eoan and building now to test17:21
meenawhat? me??17:23
blackboxswwell yes indeedy meena, just trying to keep you highlighted as participating in the cloud-init status meeting :) you've thankfully reviewed, pushed and prodded us to talk about cloudinit.net refactor and how best to address it I think :) credit due ;)17:24
blackboxswcommunity notice: upload to Ubuntu groovy of cloud-init master accepted [ubuntu/groovy-proposed] cloud-init 20.2-45-g5f7825e2-0ubuntu1 (Accepted)17:26
Odd_Blokeblackboxsw: One issue with https://github.com/canonical/cloud-init/pull/41217:30
meenablackboxsw: i'm just waiting for Odd_Bloke to provide the basic infrastructure so i can start moving code… without that, i have to bug other projects in my … 2 hours of free time per day.17:31
meenablackboxsw: yesterday, i tried to build an android app on my laptop and gave up after an hour.17:31
blackboxswnice review again Odd_Bloke, will reflect that patch to each series. as every other ubuntu/* is missing enabling various cloud datasources beyond just Rbx17:35
blackboxswOdd_Bloke: rharper so Xenial is interesting for datasource config via dpkg17:54
blackboxswWe are missing: Hetzner, IBMCloud, Oracle, and  RbxCloud17:55
blackboxswone was an oversight on previous SRUs17:55
blackboxswbut Oracle and IBMCloud, I'm trying to recall if there is a reason we didn't want to surface either of those datasources as configurable on Xenial17:55
blackboxswa little warning bell is going off in my head17:56
blackboxswHetzner I thought was 'ok'17:56
blackboxswOracle currently gets detected as OpenStack on Xenial.17:56
rharperIBMCloud and Oracle are sensitive17:57
rharpernot sure about Hetzner or RbxCloud though17:57
blackboxswupstream Oracle datasource is 'good', but I wasn't sure if there was extra baggage associated with *not* backporting that functionality17:57
rharperblackboxsw: I think you might want to check with CPC on those17:57
meenaHetzner is also detected as OpenStack on FreeBSD… but… only thru cloud-init itself, not thru ds-identify17:58
meena(i'm not sure how much of that is my fault having helped a lot with Hetzner and FreeBSD and ds-identify myself)18:03
knacccOdd_Bloke thanks for your reply. I managed to fix things in the end, but kinda by cheating. Now my /etc/netplan/50-cloud-init.yaml only contains the IP addresses configuration, and I make the nameservers and search domain apply in the "Global" scope (as reported by systemd-resolve --status) by simply modifying the /etc/resolv.conf file. All configuration survives reboot just fine, and I am no longer18:03
knacccscared that resolv.conf will be overwritten because I found a web page that said that "Note: The mode of operation of systemd-resolved is detected automatically, depending on whether /etc/resolv.conf is a symlink to the local stub DNS resolver file or contains server names." Although you said in your message that "cloud-init will regenerate /etc/netplan/50-cloud-init.yaml on each boot, so yes, you don't18:03
knacccwant to modify that", the OVH instructions directly contradict that and tell me to edit it to add all IP addresses to my interface (see Ubuntu 18.04 section here: https://docs.ovh.com/gb/en/vps/network-ipaliasing-vps/). I'm therefore very confused about why OVH seem to contradict the instructions that are in that config file, and confused as to what other location I should be editing/creating instead18:03
ddstreetknaccc why do you want to change resolved 'Global' section?18:06
blackboxswheh meena not at fault :) . Just need to make sure we move cloud-platforms to a better way of detecting the right datasource when we can.18:08
knacccddstreet if I put the nameservers and search domain into the /etc/netplan/50-cloud-init.yaml file, it gets ignored completely (i.e. although those configurations show up in systemd-resolve --status against that specific "link", the "Global" nameservers and lack of any search domain in that Global section are taking precedence). Therefore I had to configure nameservers and search domain at the resolv.conf18:08
knaccclevel so that it appeared in the Global section, and then suddenly everything worked for the first time18:08
blackboxswI should tie off our cloud-init status meeting. Thanks folks for all who've attended18:08
meetingologyMeeting ended Tue Jun  2 18:08:56 2020 UTC.18:08
meetingologyMinutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-02-16.21.moin.txt18:08
knacccoh oops, sorry i didn't realise the meeting was still in progress when I interjected18:09
blackboxswknaccc: the meeting is a welcome place for any and all discussions18:09
blackboxswall good18:09
blackboxswI was just supposed to end it about ~20 mins ago to capture logs18:09
blackboxswwe were in the "open discussion office hours"  part of the meeting18:10
ddstreetknaccc i don't know what your exact config is, but you don't need nameservers in the global section for dns to work18:10
knacccddstreet since the OVH config already specified a resolv.conf file, that seemed to be overriding my settings in the 50-cloud-init.yaml file. I should have thought to try deleting the resolv.conf file to see if that would stop the "Global" section for overriding the link settings18:11
ddstreetyeah with systemd-resolved you don't want to modify the /etc/resolv.conf file18:13
knacccddstreet do you disagree with the web page I found that says "Note: The mode of operation of systemd-resolved is detected automatically, depending on whether /etc/resolv.conf is a symlink to the local stub DNS resolver file or contains server names"?18:13
knaccc(that's a quote from here https://wiki.archlinux.org/index.php/Systemd-resolved )18:14
ddstreetknaccc no that's correct, but if you maintain your /etc/resolv.conf yourself, you need to 100% manage it18:14
knacccddstreet ah yes, that's the impression i got. since this is a dedicated server, and that resolv.conf configuration will probably never change, that should be OK, right?18:14
knacccall resolv.conf contains is the cloudflare and google dns servers, and my search domain. so those will probably never change, ever18:15
ddstreetwell that depends on what exactly you did, i.e. remove the symlink and create the file yourself, and remove the from it18:15
ddstreeti.e. you want to bypass resolved entirely18:15
ddstreetwhen you do that, it doesn't matter what systemd-resolve --status says, because you aren't using it18:16
knacccah that makes sense. yes the resolv.conf file was already put there by OVH on a fresh install. so i'm guessing they did itthat way to make things easier for people who were used to just editing resolv.conf18:17
knaccci'll try deleting resolv.conf and then seeing if 50-cloud-init.yaml nameservers and search domain suddenly get picked up18:18
ddstreetwell you need to recreate the symlink to /run/systemd/resolve/stub-resolv.conf18:18
ddstreetand make sure something has told resolved about your actual nameservers, i.e. networkd in most cases18:18
knacccddstreet ah thanks, yes i see, i'm supposed to do: ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf18:19
knaccci'll try that, when i'll be reinstalling another server in a few hours18:20
knacccalthough it seems like since i don't have some kind of liquid situation with frequently changing nameservers, maybe i should just stick to simplicity and just do things in resolv.conf18:20
knacccddstreet if i'm not supposed to be editing 50-cloud-init.yaml file, could you point me towards what I should be ediitng please?18:20
knaccci wonder if OVH are using cloud-init in a kind of "one-shot" mode, where it's useful for them to just config a dedicated server the first time using cloud-init, but then i can then just edit the 50-cloud-init.yaml file myself from then on, because neither OVH nor any kind of system thing will ever overwrite 50-cloud-init.yaml18:22
ddstreeti didn't say you shouldn't edit that file18:27
ddstreetbut in general, no you shouldn't, it's created from the cloud data18:28
ddstreetyou should edit your instance config from the cloud provider's contorls18:28
blackboxswso rharper/Odd_Bloke for this SRU, I'm thinking we hold on IBMCloud, Hetzner and Oracle datasource enablement and tackle that separately once we circle the wagons with regard to Xenial expected behavior18:34
blackboxswI'm good with adding RbxCloud as that datasource was just recently added and detecting it falls at the end of the list for ds-identify18:35
rharperblackboxsw: that sounds good to me18:37
blackboxswthis is all for xenial and bionic, only adding RbxCloud, xenial and bionic will still lack Oracle and IBMCloud support. Xenial will also lack Hetzner18:38
knacccddstreet thanks for your advice. is cloud-init attempting to connect to OVH on every reboot to see if there are new settings available? as long as i'm confident that this dedicated server will never need an automatic network setting update or any other type of updates from OVH via cloud-init, do you see any problem with me just disabling cloud-init by doing "touch /etc/cloud/cloud-init.disabled"? is that18:44
knacccthe best way to disable it? it is a bit creepy to me that OVH could just use cloud-init to mess with my dedicated server unexpectedly18:44
rharperknaccc: cloud-init generally only operates on first boot; subsequent boots runs cloud-init to determine if it is on the same instance or if it has been captured and booted on a different platform; in which case it clears data and runs like first boot again18:57
rharperknaccc: I'm not sure which Datasource OVH uses ( I think OpenStack, but not 100%s) most datasources do not generate network config on *every* boot; some platforms do (Azure for example);  if you are only worried about network config changes, you can configure cloud-init to not bother configuring networking at all;18:58
Odd_Blokeblackboxsw: To be clear, the issue is not that we're missing DSes, it's that our two lists are inconsistent.18:58
blackboxswOdd_Bloke: sorry I figured that out later. but we also have missing datasources on Bionic and Xenial18:58
rharperOdd_Bloke: do you think we miss these due to image builds for certain platforms which might include the DS automatically ?18:59
lucasmourablackboxsw, I am trying to write one of our manual tests for the next SRU. I am starting with focal, but I just want to verify something. Is it right that the cloud-init package to be tested is not on focal-proposed yet ?18:59
rharperit seems like some of them would scream if cloud-init didn't work at all on certain releases18:59
rharperlucasmoura: yeah, it's not uploaded to the pocket release yet19:00
lucasmourarharper, ack19:00
rharperlucasmoura: instead you can: add-apt-repository -y ppa:~cloud-init-dev/proposed19:00
rharperthen apt update && apt install cloud-init19:00
lucasmouraOh right, now I remember that we commented that issue on the daily. The lxc-proposed-snapshot use the pocket by default right ?19:01
Odd_Blokerharper: blackboxsw: Given the uncertainty we have over it, and the lack of bug reports, I think we should proceed with the current set of DSes.19:01
blackboxswOdd_Bloke: I've specifically added RbxCloud (because it's newly added to tip) to X, B, E and F19:01
Odd_BlokeThat seems fine to me too. :)19:01
blackboxswok, the others let's leave untouched19:01
knacccrharper yes OVH is openstack, but that's for their public cloud. I think they're just suddenly using cloud-init on their private dedicated servers too since it makes it easy for them. Just to clarify, are you saying that cloud-init is probably connecting to OVH on every reboot to ask OVH if any changes need to be made, and OVH is saying "no" each time? or is it my server that it is itself deciding not to19:01
knaccccontact OVH on subsequent boots?19:01
blackboxswand RbxCloud is last detected datasource anyway, so no impact to other datasources unless nothing else matches19:01
rharperknaccc: no; I can't say what they're doing without seeing some logs;  If they are using it on dedicated servers; it may use "offline" datasources like NoCloud which reads from a file, or ConfigDrive which reads from an iso19:02
rharperknaccc: you can see which datasource was detected  looking at /run/cloud-init/cloud.cfg , would show something like  datasource_list: [ NoCloud, None ]19:05
rharperknaccc: on platforms where there is a remote datasource (Like Openstack);  cloud-init does not reconnect to the metadata service on subsequent boots by default;  in some datasources, the only way to determine an instance's unique id is to fetch the values from the platfroms metadata server; for those platfroms, cloud-init does fetch the metadata on each boot; if the instance-id matches, no further work is done.19:07
Odd_Blokeblackboxsw: +1 on focal.19:08
blackboxswlucasmoura: here's what we typically push to a vm under test https://github.com/cloud-init/ubuntu-sru/blob/master/sru-templates/manual/ec2-sru#L35-L4019:08
blackboxswwhich does the setup cloud-init/proposed  PPA19:08
blackboxswfalcojr: too ^   so it's a good guideline on what to test until we ping the ubuntu SRU team to our my current work in progress ubuntu/* branches uploaded19:09
blackboxswthanks Odd_Bloke build-and-pushing ubuntu/focal then19:09
blackboxswjust eoan bionic and xenial to go if lucasmoura falcojr wanted to look at those too I've captured the same type of new-upstream-snapshot changesets for those that I just pushed into ubuntu/focal  (though I haven't updated the PR doc/context for the drop of debian/control build-deps and the cloud-init.templates RbxCloud addition19:11
blackboxsweoan https://github.com/canonical/cloud-init/pull/40919:11
blackboxswbionic https://github.com/canonical/cloud-init/pull/40919:11
knacccrharper this is my /etc/cloud/cloud.cfg: https://pastebin.com/raw/YwTa8Cpb I think that since there are no datasources listed in that, that that means there are no updates being checked for on every reboot?19:12
blackboxswxenial https://github.com/canonical/cloud-init/pull/40619:12
blackboxswknaccc: you can /should also check /etc/cloud/cloud.cfg.d/90_dpkg.cfg19:13
blackboxswthat is typically where the cloud image creator defaults that datasource_list19:13
lucasmourablackboxsw, thanks I will use this approach then19:13
knacccblackboxsw that has just this line, and I don't know what it means: datasource_list: [ NoCloud, ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, Bigstep, Scaleway, AliYun, Ec2, CloudStack, Hetzner, IBMCloud, Oracle, Exoscale, RbxCloud, None ]19:13
lucasmouraAnd I can help with reviews, no problem. I will start with eoan19:14
blackboxswknaccc: so that list means on initial boot, ds-itentify script will try to detect each of those datasources in that specific order. so if cloud-init hadn't already detected the datasource for your image, it'd try to go through that list to find which one matches your platform. sorry I may have muddied the water with your previous discussion, I was just responding to your latest comment19:15
blackboxswI'm reading your backlog knaccc to respond more appropriately to your underlying concern (it was about whether cloud-init would try to redetect/reconfigure your instance across boots right ?)19:16
knacccblackboxsw yes that's right19:16
knacccblackboxsw i just want to make sure that now that OVH has used cloud-init once to auto-configure the freshly reinstalled private dedicated server, that cloud-init will never mess with my config again on reboot19:17
lucasmourablackboxsw, I know we can easily extract that from the changelog, but on the steps to reproduce the package, it is missing the 2.header part19:17
knacccblackboxsw in which case, do you agree that the best way to stop cloud-init from messing with my system is to just do "touch /etc/cloud/cloud-init.disabled"?19:18
Odd_BlokeI'm looking at eoan now.19:18
blackboxswthanks Odd_Bloke, I'm uploading ubuntu/focal19:18
Odd_Blokeblackboxsw: Still working through the patches, but I've already posted a Q, FYI.19:19
rharperknaccc: no, you need to look at the /run/cloud-init/cloud.cfg ;  /etc/cloud/cloud.cfg is the default settings and it enables all of the supported datasource;  at boot time cloud-init uses a systemd generator to detect which platform (or which datasource) is configured, NoCloud looks for files in /var/lib/cloud/seed/nocloud-net/*  or a iso/filesystem label with 'cidata' for example and then if we find a datasource or platfrom, then we enable19:19
rharpercloud-init to run (otherwise we don't run at all)19:19
rharperknaccc: w.r.t disabling cloud-init, touching that file will disable cloud-init19:20
knacccrharper aha, /run/cloud-init/cloud.cfg says just: datasource_list: [ ConfigDrive, None ]19:20
blackboxswand knaccc cloud-init status --long will show you ultimately what cloud-init proper detected as the valid datasource.19:21
blackboxswso I'd expect cloud-init status --long to show ConfigDrive in the output19:21
knacccyes, that --long command only shows: DataSourceConfigDrive [net,ver=2][source=/dev/nvme0n1p4]19:21
blackboxswok so the configdrive path source in that case was from /dev/nvme0n1p419:22
knacccblackboxsw ok, now i'm really confused. my two SSD drives (as reported by parted) are /dev/nvme0n1 and /dev/nvme1n1, and i have no idea what /dev/nvme0n1p4 is19:25
blackboxsw /dev/nvme0n1p4  is just partition 4 on  /dev/nvme0n119:26
blackboxswI think19:26
knaccci guess it could be a temporary partition that existed for a while during machine setup19:28
knacccand it gets wiped out when the disk is configured19:28
knacccok, i think i'm starting to get comfortable understanding this enough to just disable cloud-init now and not worry about the consequences, you've both been a great help in enabling me to get some kind of mental model of what cloud-init is doing and where, so thank you blackboxsw rharper19:29
knaccci was terrified that cloud-init would suddenly overwrite things on reboot and brick the machine, but i'm feeling much better about how to handle this now19:30
knaccc(by brick the machine, i mean suddenly revert the network config or something else unexpectedly, and cause things to break)19:31
rharperknaccc: sure, glad we could help19:49
Odd_Blokeblackboxsw: Did you see my comments on eoan?19:52
Odd_BlokeJust realised I didn't ping you with them, now I'm done.19:52
Odd_BlokeHaha, I see in my inbox right now that you have. :p19:53
powersjFYI cloud-init + azure whitepaper: https://pages.ubuntu.com/rs/066-EOV-335/images/Cloud-init_on_Azure.pdf19:57
powersj^ AnhVoMSFT thanks for your help on that19:58
blackboxswwow excllent powersj and AnhVoMSFT !20:03
blackboxswOdd_Bloke: ok, thanks I see the issue with the quilt patch renderer-do-not-prefer-netplan.patch20:22
blackboxswlucasmoura: it'll be the same issue on bionic too. you can see Odd_Bloke's failure by running: quilt push -a; tox -e py3 tests/unittests/test_render_cloudcfg.py20:23
blackboxswjust so we know best approach for verifying future  upload checks. # apply all quilt patches and test the world  with quilt push -a; tox -p auto20:24
lucasmourablackboxsw, okay20:24
blackboxswsorry gents, I neeed about 20 mins to fix this on the 3 branches20:24
Odd_Blokeblackboxsw: I caught this by performing a build locally, should we include that as part of the process before you submit the PR?20:43
blackboxswOdd_Bloke: you think new-upstream-snapshot should run sbuild?20:44
blackboxswor is it PR review requirement20:44
Odd_BlokeI think the submitter (and soon-to-be uploader) should run it, I don't think that automation should Just Do It (because different people will have different package building setups).20:48
blackboxswOdd_Bloke: agreed. I'll add a PR to ubuntu-sru to mention that pre-requisite prior to PR.20:48
Odd_BlokeYeah, new-upstream-snapshot could just mention it in that block of commands it suggests running?20:49
blackboxswyes that works20:50
tgm4883Trying to use cloudinit on a centos 7 image in vmware, feels like I'm close, but cloud init throws a warning that it's unable to get datra from the vmware source. When I use the vmware rpctool I can see and decode the base64 data so the VM at least knows about it.21:36
tgm4883But nothing that I've told it to do actually happens, any pointers on where to look next? The logs only tell me that the data isn't found, but I can see the data when I query it21:37
rharpertgm4883:   maybe test out a newer cloud-init version?  https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/  ;   vmware issues have been a challenge for the community to work with.21:42
rharpertgm4883: there's also some use of a non-upstream datasource from vmware,  https://github.com/vmware/cloud-init-vmware-guestinfo/blob/master/DataSourceVMwareGuestInfo.py   which we don't directly support; I've seen users attempt to use this version (it works for some and not for others)21:43
tgm4883Will do21:43
tgm4883yea that's the one I'm using21:44
tgm4883My *very limited* understanding of how this all works is that these datasources are essentially plugins for cloud-init correct? So maybe if I understood how the data gets from that plugin to cloud-init (or rather, if I could somehow run and debug the plugin directly) it might help21:45
tgm4883I do see cloud-init trying to use it, but just says that getting data from that class failed21:46
rharpertgm4883: you can rerun cloud-init manually if you can access the image;  typically we modify the image with a root password and ssh keys, etc when debugging;  once on a system, you can manually run 'cloud-init init --local' and 'cloud-init init'  (those are the first two stages which exercise the datasource);21:52
blackboxsweoan finally fixed for tomorrow, or any late birds still around https://github.com/canonical/cloud-init/pull/40922:18
tgm4883rharper: thanks for the help. I didn't get a chance to try the new version of cloud-init yet, but I did notice that the datasource that is installed in vmware's RPM is older than the one installed via the install script, and the one in the install script at least returns data when running it by itself, so that gives me some more to test with22:30
rharpertgm4883: ah, ok23:33
rharpertgm4883: sure,  glad we can help23:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!