| mruffell | Hi cloud-init team, I opened https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1842562 | 05:36 |
|---|---|---|
| ubot5 | Launchpad bug 1842562 in cloud-init (Ubuntu Eoan) "AWS: Add udev rule to set Instance Store device IO timeouts" [Medium,In progress] | 05:36 |
| mruffell | You can ping me, or ddstreet if you have any questions. I hope cloud-init is the right place for it | 05:36 |
| mruffell | Theres still some debate going on in the SF case, but I think cloud-init is the best place | 05:37 |
| Mechanismus | ok idgi, I'm trying to use {{ v1.local-hostname }} within my cloud-config.txt | 13:16 |
| Mechanismus | but when I do I get unicode rendering errors | 13:17 |
| Odd_Bloke | Mechanismus: What version of cloud-init are you using? Where do you see the errors? | 13:28 |
| Mechanismus | version: /usr/bin/cloud-init 19.1-1-gbaa47854-0ubuntu1~18.04.1 | 13:31 |
| Mechanismus | errors when I run `cloud-init query --list-keys` | 13:31 |
| Mechanismus | UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte | 13:31 |
| Odd_Bloke | Mechanismus: Oh, that's not good! Could you file a bug at https://bugs.launchpad.net/cloud-init/+filebug and attach the tarball that `cloud-init collect-logs` generates, please? | 13:33 |
| Mechanismus | eh... I'll have to desensitize the file | 13:36 |
| Mechanismus | ...after I find it | 13:36 |
| Mechanismus | it's being generated via terraform and supplied to an azure vm in user data | 13:36 |
| Odd_Bloke | Find it? `cloud-init collect-logs` gathers all the data we would need, so you shouldn't need to go find anything. :) | 13:37 |
| Mechanismus | oh | 13:39 |
| Mechanismus | I thought you meant the gzip that was provided to the vm at launch | 13:39 |
| Odd_Bloke | :) | 13:39 |
| Mechanismus | actually I have to redeploy the VM to get logs with specifically this situation | 13:42 |
| Mechanismus | that'll take a minute | 13:42 |
| Odd_Bloke | rharper: blackboxsw: We don't have a template for Oracle yet; which other template would you suggest basing it on? | 14:16 |
| rharper | Odd_Bloke: the openstack one ? | 14:16 |
| rharper | at least for now, it's mostly Openstack API right ? | 14:16 |
| rharper | until we switch datasources ? | 14:16 |
| rharper | it's been a while since I use the cli | 14:17 |
| rharper | something else might fit better | 14:17 |
| Odd_Bloke | I think I'll just launch instances using the web interface. (I don't believe Oracle's user-facing API is OpenStack-compatible.) | 14:18 |
| Odd_Bloke | So I guess I was really asking which one is most recently updated? | 14:19 |
| Odd_Bloke | Looks like Openstack probably is the best one. | 14:20 |
| blackboxsw | morning, yeah I | 15:12 |
| blackboxsw | morning, yeah I'd agree on basing the manual verification script on openstack or azure since you'll probably be calling oracle's api instead of a launch-oracle.py script as we don't have that yet | 15:14 |
| Mechanismus | Odd_Bloke: ok so it looks like Azure's part of the cloud config is running, but my custom bits fail to merge in and I still get the error with cloud-init query | 15:36 |
| Mechanismus | Is there anything I can look at in the logs for something I might be doing wrong before I actually open a bug? | 15:37 |
| Odd_Bloke | Mechanismus: It's hard to know, because I don't really understand the problem you're seeing. Honestly, a bug would make this a lot easier to work through. Is there a particular reason you don't want to file one? | 15:39 |
| Mechanismus | Odd_Bloke: not really except that if it's a bug then the turnaround time to get this working is arbitrary and I'm trying to get this working today | 15:40 |
| Mechanismus | I'm about to try an alternative approach in generating my cloud config in terraform though which would let me work around this for now | 15:40 |
| Odd_Bloke | I mean, the same people who would help you in IRC are telling you to file a bug, so I'm not sure why you think the turnaround would be any different. ;) | 15:41 |
| Odd_Bloke | blackboxsw: I'm actually not going to document exactly how to launch an Oracle instance; the UI makes it fairly easy to work out, and I don't want us to have out-of-date docs when they change things. I _will_ document the one thing that caught me out (remembering to add your SSH key). | 15:42 |
| Mechanismus | I mean that if it's a matter of I'm trying to do something unsupported then I can fix that. If the fact that the UnicodeDecodeError shouldn't happen even when I'm being dumb constitutes a bug then I get that, but getting the _machine_ working is kind of my top priority right now | 15:42 |
| blackboxsw | Odd_Bloke: thanks, makes sense | 15:43 |
| blackboxsw | that's all I was really hoping, was if it was a complicated instance launch in any manner | 15:43 |
| Odd_Bloke | Mechanismus: Well, we can always close out a bug Invalid if it turns out that you are doing something unsupported, but we would never expect to see a traceback. | 15:44 |
| Odd_Bloke | So I expect there is a valid bug, even if it's "we should message better when we see bad input" or whatever. | 15:44 |
| Odd_Bloke | And a bug gives us a place to attach logs etc. and have discussion to that won't get lost in IRC backlog. | 15:44 |
| blackboxsw | we can reflect the bug lnk in channel here too to improve response time on resolution | 15:45 |
| blackboxsw | UnicodeDecodeError rings a bell when handling some of the cloud metadata in the past. but we probably can/should address that in cloud-init proper if it's causing your general cloud-init query --all to fail. | 15:46 |
| Mechanismus | Odd_Bloke: I fully agree with you and will be happy to look into it once I fix the issue I was working on when I ran into this | 15:46 |
| * blackboxsw just realized I'm waay out of date on this discussion. I'll read the origin of this conversation to catch up | 15:47 | |
| blackboxsw | Mechanismus: couple things you can/should try to test whether your given jinja query syntax is valid, on a booted vm you can run: cloud-init query --format "{{ v1.local-hostname }}" to see if it's an accessible template variable. | 15:52 |
| blackboxsw | Mechanismus: specifically for our v1 standardized metadata, I *think* you needed {{v1.local_hostname }} instead of {{ v1.local-hostname}} as the hyphen gets interpreted as subtraction | 15:53 |
| blackboxsw | on my system: cloud-init query --format "{{v1.local-hostname}}" | 15:53 |
| blackboxsw | WARNING: Ignoring jinja template for query commandline: Undefined jinja variable: "local-hostname". Jinja tried subtraction. Perhaps you meant "local_hostname" | 15:53 |
| Mechanismus | blackboxsw: Good point, v1.local-hostname is in instance-data.json but doesn't work with the query. However, v1.local_hostname works, though that's exactly what I have in cloud-config on this machine with the errors | 15:54 |
| blackboxsw | also Mechanismus inside the template, you can use python as a workaround... so if you could do something like {{ v1.local_hostname.decode('utf-8') }} | 15:55 |
| blackboxsw | or {{ v1.keys() }} to see available subkeys under v1 | 15:55 |
| blackboxsw | Mechanismus: you could also check cloud-init query userdata (which would provide your cloud-config yaml) and you'd be able to process that content for your hostname: <myhost> or fqdn: declarations | 15:59 |
| blackboxsw | but that's a bigger lift :/ | 15:59 |
| smoser | if i had to guess.. | 16:00 |
| smoser | 0dc3a77f41f4544e4cb5a41637af7693410d4cdf | 16:00 |
| smoser | would fix Mechanismus | 16:01 |
| smoser | although that should not occur with pyhon 3 | 16:01 |
| blackboxsw | hrm, though I thought he was on v. 19.1.1 and that commitish was in ~18.5 | 16:03 |
| smoser | oh. you're right. i just loked at the date | 16:04 |
| smoser | and assumed the april commit didnt get into 19.1 | 16:05 |
| blackboxsw | yeah true initially. | 16:05 |
| blackboxsw | I mean, yes I thought so too initially | 16:05 |
| blackboxsw | heh interesting on Azure for my SRU test | 16:06 |
| smoser | https://bugs.launchpad.net/cloud-init/+bug/1801364 is related, but not really. | 16:06 |
| ubot5 | Launchpad bug 1801364 in cloud-init "persisting OpenStack metadata fails" [Undecided,Confirmed] | 16:06 |
| blackboxsw | ubuntu@my-e1:~$ sudo cloud-init query userdata | 16:06 |
| blackboxsw | ../sethostname.yaml | 16:06 |
| smoser | i'm assuming he is not python 2 | 16:06 |
| blackboxsw | I expected the metadata service to actually report the user-data, not the file name I used when launching the instance | 16:06 |
| smoser | are you sure you have userdata ? | 16:06 |
| smoser | and not just the name of a file ? | 16:07 |
| blackboxsw | checking my azcli launch command | 16:07 |
| smoser | to my knowledge 'az' takes only a custom-data blob in --custom-data | 16:08 |
| smoser | not a reference to a file | 16:08 |
| blackboxsw | ahh interesting, I specified a nonexistent file on --custom-data | 16:08 |
| blackboxsw | if file does exist I think it gets populated properly.. .checking our latest SRU run | 16:09 |
| Odd_Bloke | Yeah, my shell history strongly suggests you can pass a file to --custom-data. | 16:09 |
| blackboxsw | smoser: https://github.com/cloud-init/ubuntu-sru/blob/master/manual/azure-sru-19.2.21.txt | 16:09 |
| blackboxsw | yeah if the file does exist (sethostname.yaml in that example ^) it works and sets SRU-worked-<cloud> | 16:10 |
| blackboxsw | but if file doesn't exist, azure just provides the string to the vm | 16:10 |
| blackboxsw | and doesn't error (because it's 'flexible' in allowing blob or file) | 16:10 |
| Odd_Bloke | gcloud has --metadata-from-file distinct from --metadata, which I prefer, I think. | 16:11 |
| blackboxsw | +1 Odd_Bloke, yeah explicit intent/failures | 16:11 |
| smoser | the other better path is @filename | 16:12 |
| smoser | like curl does | 16:12 |
| blackboxsw | true | 16:12 |
| * blackboxsw tries that @<file> w/ azcli to see if it'll fail on file absent | 16:13 | |
| blackboxsw | or even succeed on file presence | 16:13 |
| blackboxsw | ok failure when providing --custom-data @<file> | 16:14 |
| blackboxsw | Deployment failed. Correlation ID: 91ddbf3f-e296-4ea4-aab7-2189c314fe66. { | 16:14 |
| blackboxsw | "error": { | 16:14 |
| blackboxsw | "code": "PropertyChangeNotAllowed", | 16:14 |
| blackboxsw | "message": "Changing property 'customData' is not allowed.", | 16:14 |
| blackboxsw | "target": "customData" | 16:14 |
| blackboxsw | } | 16:14 |
| blackboxsw | } | 16:14 |
| blackboxsw | :) | 16:14 |
| blackboxsw | well, we missed cloud-init status meeting Monday due to US holiday. We'll shift it to next Monday, and I'll send an email to the list | 16:16 |
| === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Sept 9 16:15 UTC | cloud-init v 19.2 (07/17) | https://bugs.launchpad.net/cloud-init/+filebug | ||
| * Odd_Bloke is going to look at SRU verification for https://bugs.launchpad.net/cloud-init/+bug/1812857 | 16:33 | |
| ubot5 | Launchpad bug 1812857 in cloud-init "RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'" [Medium,Fix released] | 16:33 |
| blackboxsw | Odd_Bloke: good deal, reviewing oracle run now. I just pushed https://github.com/cloud-init/ubuntu-sru/pull/44 with correct mtu v1 and v2 inputs (which fixed the diffs of v2 output so it is now limited to just dict ordering diffs) | 16:41 |
| blackboxsw | Odd_Bloke: I can't remember w/ Oracle. Upon reboot upgraded cloud-init changed from detecting DataSourceOpenStackLocal to detecting DataSourceOpenStack (net). I realize it's the same datasource, but was a bit surprised that it switched to !Local detection | 16:46 |
| * blackboxsw tries to see if we have that same transition for Ec2Local -> Ec2 | 16:47 | |
| blackboxsw | it may be worth peeking at 'Crawl of metadata service" in cloud-init.log post the clean reboot to see why we cloud-init balks on OpenStackLocal post upgrade | 16:50 |
| blackboxsw | maybe there was an ephemeral dhcp response issue there? | 16:50 |
| Odd_Bloke | Looking. | 17:28 |
| rharper | blackboxsw: on your pull request with the netplan v2 bits; shouldn't you pull the mtu values from the devices in the verification ? | 17:31 |
| blackboxsw | rharper: btw, you were right that netplan raises a warning about missing definitions for the bond_interfaces | 17:32 |
| rharper | yeah | 17:32 |
| rharper | so for verification there, I'd read the MTU values on the bond and member interfaces pre-upgrade (v1) and post-upgrade (v2) | 17:33 |
| rharper | it's fine to hard code the paths in the test since we're constructing the config (and interface names); | 17:33 |
| blackboxsw | sure rharper agreed, I can grep -B 2 -i mtu and we'll see the interfaces in most cases | 17:33 |
| rharper | I'm grabbing, bug #1806701 | 17:33 |
| ubot5 | bug 1806701 in cloud-init "cloud-init may hang OS boot process due to grep for the entire ISO file when it is attached" [Medium,Fix released] https://launchpad.net/bugs/1806701 | 17:33 |
| rharper | blackboxsw: you can read /sys/class/net/<iface>/mtu | 17:34 |
| rharper | if you're not playing with ipv6 mtu | 17:34 |
| blackboxsw | rharper: that would be if a created a vm with that config and applied. I didn't do that, I was just running net-convert in the test | 17:34 |
| rharper | ah | 17:34 |
| rharper | ok | 17:34 |
| rharper | I saw NoCloud | 17:34 |
| rharper | so was thinking you were doing a VM | 17:34 |
| blackboxsw | right, only because I did check on an lxc with -proposed enabled | 17:35 |
| blackboxsw | to make sure our -proposed bits had the logic | 17:35 |
| blackboxsw | instead of just testing ti | 17:35 |
| blackboxsw | tip | 17:35 |
| rharper | pok | 17:35 |
| rharper | that's fine actually since it's about the netconfig generated | 17:35 |
| Odd_Bloke | OK, so there is a change in behaviour, and I think it's to do with network configuration; digging in more now. | 17:48 |
| Odd_Bloke | (When I said there weren't new tracebacks at stand-up, I was mistaken.) | 17:49 |
| Odd_Bloke | OK, I think the issue is coming from the classless static route support we now have for ephemeral DHCP. | 17:55 |
| Odd_Bloke | And if the interface already has an address, we handle failing to set it gracefully, but we will still attempt to apply the routes to it. | 17:56 |
| Odd_Bloke | And that fails, causing the DS to not be considered. | 17:56 |
| Odd_Bloke | Good catch, Chad. | 17:58 |
| Odd_Bloke | OK, I've got a fairly small patch which seems correct to me. I'll propose it and we can discuss it. | 18:05 |
| rharper | Odd_Bloke: ah, yes, we really should have a net_is_up check in the oracle/openstack ds | 18:23 |
| rharper | in that, if networking is up, no need to bring up ephemeral DHCP | 18:23 |
| rharper | that said, it can't hurt to be more defensive in Ephemeral DHCP as well | 18:23 |
| Odd_Bloke | rharper: blackboxsw: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/372289 <-- what do you think of that? | 18:26 |
| blackboxsw | Odd_Bloke: ahh good deal. hrm. ok, so we caught a potential regression then. Sure, let's review what you've got when available and we'll get that in | 18:27 |
| blackboxsw | reading now. | 18:28 |
| rharper | Odd_Bloke: left a comment, not quite sure what to do; to me, if we called EphemeralDHCP, then I really expect it to do a DHCP not skip the dhcp + setup if the interface already has an IP ... ; should we raise and exception instead? and for Oracle/OpenStack, (or any user of EphemeralDHCP) we should check net.is_up(self.fallback_interface) before using the EphemeralDHCP | 18:32 |
| Odd_Bloke | Having to check net.is_up before using it leads to slightly awkward code like get_metadata_from_imds in DataSourceAzure.py; if net.is_up(): do_thing() else: with EphemeralDHCP: do_thing() | 18:41 |
| Odd_Bloke | But I agree that there's no point getting the lease when we're going to throw it away immediately without using any of it. | 18:41 |
| blackboxsw | rharper: Odd_Bloke, probably fair to think about things that way, though existing behavior is to bail on all other setup if the interfaces already has an IP, regardless of Odd_Bloke's fix | 18:41 |
| blackboxsw | and Odd_Bloke agree it is awkward to have every call side is_net_up() or EphemeralDCHP. it'd be nice to have that failsafe logic within EphermeralDCHP contextmgr.. maybe we could have a EphemeralDHCP(force=True) if we really want to force a dhclient run on an interface even if it already has config | 18:43 |
| Odd_Bloke | In fact, I think get_metadata_from_imds is wrong because of this; it will report errors differently depending on whether or not an ephemeral lease was needed. | 18:46 |
| Odd_Bloke | (Not a big deal, but this is why avoiding having to spell out do_thing() twice is good.) | 18:47 |
| blackboxsw | Odd_Bloke: do we have the traceback you saw on Oracle somewhere | 18:47 |
| Odd_Bloke | You mean you can't see it in my terminal? | 18:47 |
| blackboxsw | Odd_Bloke: no, I'm just sniffing your browser traffic to your banks | 18:47 |
| rharper | lol | 18:47 |
| Odd_Bloke | There we go: https://paste.ubuntu.com/p/jt8hNMJjKb/ | 18:47 |
| blackboxsw | thanks man | 18:47 |
| Odd_Bloke | Oh, OK, you could just have sniffed that URL then. | 18:48 |
| Odd_Bloke | But I'll make it easier for you. | 18:48 |
| Odd_Bloke | Yeah, so I think my fix is probably too far down the stack. | 18:48 |
| * blackboxsw wonders really if we should be checking the same failure condition we already are for ['ip', '-family', 'inet', 'addr', 'add', cidr, 'broadcast', | 18:48 | |
| * blackboxsw self.broadcast, 'dev', self.interface], | 18:48 | |
| * blackboxsw The 'File exists' in stderr | 18:48 | |
| blackboxsw | as in we can try all setup commands and only queue cleanup for the commands which succeed | 18:49 |
| Odd_Bloke | We should perhaps do that, but I don't think that's the root of the problem here. | 18:49 |
| blackboxsw | and ignore the setup commands for routes or addrs that already exist | 18:49 |
| Odd_Bloke | We should be able to know that we don't need to do DHCP at all here. | 18:49 |
| blackboxsw | Odd_Bloke: agreed there too | 18:50 |
| Odd_Bloke | FWIW, we already do have support for not-DHCP'ing in the context manager, if we pass in a connectivity_url. | 18:50 |
| Odd_Bloke | So the context manager already doesn't _always_ DHCP. | 18:50 |
| blackboxsw | hrm, as in we could pass connectivity_url=self.metadata_address to EphemeralDHCPv4 maybe? | 18:53 |
| blackboxsw | hrm no that wouldn't work, doesn't get setuntil you _crawl_metadata | 18:54 |
| Odd_Bloke | We could refactor that though, I think. Regardless, connectivity_url is broken because it doesn't consider 403s to be an indication that you have connectivity. | 18:59 |
| Odd_Bloke | (Which you obviously do, to get any sort of response!) | 18:59 |
| rharper | do IMDS return 403s ? would you want your connitivity url to do that ? | 18:59 |
| Odd_Bloke | 403 indicates connectivity. | 19:00 |
| Odd_Bloke | (Perhaps the argument is named incorrectly. :p) | 19:00 |
| Odd_Bloke | And yes, on Oracle, `curl http://169.254.169.254` gives a 403. | 19:01 |
| rharper | *sigh* | 19:02 |
| rharper | =) | 19:02 |
| Odd_Bloke | The same thing would happen on Google, too, at least; they expect a specific header in their requests. | 19:02 |
| Odd_Bloke | And connectivity_url doesn't allow specifying anything other than the URL string, obvs. | 19:02 |
| Odd_Bloke | Looks like nothing has ever used connectivity_url, so it wouldn't be super-surprising for there to be wrinkles with it, actually. | 19:09 |
| Odd_Bloke | I guess, to step back for a minute, is it worth fixing the OpenStack DS for Oracle when we're about to switch over to their dedicated DS? | 19:13 |
| blackboxsw | Odd_Bloke: I guess I'm still trying to understand why the network is up and configured already in local timeframe after a reboot | 19:18 |
| rharper | blackboxsw: iscsi | 19:20 |
| blackboxsw | ahh ahh | 19:20 |
| blackboxsw | Odd_Bloke: rharper. I *think* it probably makes sense for this to go with Odd_Bloke's branch to avoid the time cost of !detecting OpenstackLocal. As that issue could potentially affect other private openstack clouds using iscsci root or providing network config on the kernel cmdline wouldn't it? | 19:26 |
| Odd_Bloke | Well, my branch is really too far down the stack. | 19:26 |
| Odd_Bloke | There, if we've been given routes then we should be applying them regardless. | 19:27 |
| Odd_Bloke | The change should be at least one frame further up, so that we don't even DHCP if we already have networking. | 19:28 |
| rharper | first, is this a regression on Oracle, or has it been this way ? ie, do we need to apply fix and respin the SRU ? | 19:28 |
| Odd_Bloke | This is a regression | 19:28 |
| rharper | related to the rfc3442 stuff ? | 19:28 |
| Odd_Bloke | Yep. | 19:28 |
| rharper | I guess I don't understand why if we never when down this path before | 19:29 |
| Odd_Bloke | Because we try to apply routes that already exist and don't handle that erroring. | 19:29 |
| rharper | but previously we didnt ? are we really DHCP'ing again on top of iscsi root ? | 19:29 |
| rharper | how does that even work ? | 19:29 |
| rharper | where did the lease response come from ? | 19:29 |
| Odd_Bloke | We ephemerally DHCP, and then in EphemeralIPv4Network._bringup_device the first util.subp call fails. That failure is handled gracefully and, before, was the last thing that __enter__ did. | 19:31 |
| Odd_Bloke | However, __enter__ now unconditionally continues on to apply the routes that the DHCP response included, and that's what fails. | 19:31 |
| rharper | I see | 19:32 |
| Odd_Bloke | And that failure means that DataSourceOpenStackLocal doesn't find metadata, so we fall through to DataSourceOpenStack later on. | 19:32 |
| Odd_Bloke | (Which just uses the networking that the system already has, of course.) | 19:32 |
| rharper | well, we set try dhcp to false for non-local | 19:33 |
| rharper | in the datasource | 19:33 |
| Odd_Bloke | Right. | 19:33 |
| rharper | we really shouldn't DHCP if network is up | 19:33 |
| Odd_Bloke | Yeah, agreed. | 19:33 |
| rharper | so we have new errors in local ,but I don't think anything functional fails; | 19:34 |
| blackboxsw | rharper: right, we still ultimately detect ini-network DataSourceOpenstack, just a time cost of failing @ init-local timeframe | 19:35 |
| blackboxsw | and seeing more traces | 19:35 |
| rharper | well, I wonder if non-iscsi we'd see a network-config failure | 19:35 |
| rharper | in the iscsi case, we already use iscsi network-config instead of ds network-config | 19:36 |
| rharper | if local failed to render network-config, then we write out fallback I think, then at net time, we can crawl, all is well; | 19:36 |
| Odd_Bloke | blackboxsw: What's the time cost in your view, OOI? | 19:40 |
| Odd_Bloke | AFAICT, the time taken by the network traffic dominates, and we have to pay that cost in either route. | 19:40 |
| Odd_Bloke | But I may be missing another consequence. | 19:40 |
| Odd_Bloke | (I didn't notice the two different data sources, so I'm clearly not on my top game today, lol) | 19:41 |
| blackboxsw | Odd_Bloke: not big, certainly subsecond cost. lemme it looked like it as +00.09700s | 19:44 |
| Odd_Bloke | OK, cool, just making sure I wasn't missing something else. | 19:45 |
| Odd_Bloke | https://bugs.launchpad.net/cloud-init/+bug/1842752 <-- the bug we just discussed me filing | 20:18 |
| ubot5 | Launchpad bug 1842752 in cloud-init "Additional traceback in logs when using DataSourceOpenStackLocal on Oracle" [Low,Triaged] | 20:18 |
| blackboxsw | thanks Odd_Bloke | 20:19 |
| Odd_Bloke | The traceback does appear on upgrade. | 20:40 |
| rharper | what do we want to do about verifying https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1833192 | 20:55 |
| ubot5 | Launchpad bug 1833192 in cloud-init (Ubuntu) "VMware: post custom script isn't run correctly" [Undecided,Fix released] | 20:55 |
| Odd_Bloke | rharper: Could we just comment on the bug asking for help? | 20:59 |
| Odd_Bloke | And maybe reach out to what VMWare contacts we do have? | 20:59 |
| rharper | we can ping them directly | 21:00 |
| rharper | I'll send an email | 21:00 |
| blackboxsw | rharper: Odd_Bloke so I can validate that cloud-init behaves as expected, for bug #1840080 in the SRU | 21:45 |
| ubot5 | bug 1840080 in cloud-init (Ubuntu) "cloud-init cc_ubuntu_drivers does not set up /etc/default/linux-modules-nvidia" [High,Fix released] https://launchpad.net/bugs/1840080 | 21:45 |
| rharper | \o/ | 21:45 |
| blackboxsw | it emits proper debconf-set-selections, yet ubuntu-drivers-common doesn't actually install linux-modules-nvidia packages | 21:45 |
| blackboxsw | so, not really sure what we should do on this front. I *think* that behavior of cloud-init is correct, but we have yet to see the plumbing from ubuntu-drivers-common | 21:49 |
| powersj | blackboxsw, hit him up early tomorrow and ask; for now move on | 21:51 |
| blackboxsw | yeah nothing else remains to move on to, waiting on CDO QA review, validation of ubuntu-drivers behavior, on aws GPU eoan instance, and I think Odd_Bloke is working the last remaining bug: #1812857 | 21:54 |
| ubot5 | bug 1812857 in cloud-init "RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'" [Medium,Fix released] https://launchpad.net/bugs/1812857 | 21:54 |
| blackboxsw | powersj: I'll publish to copr el-testing. But, I think the rest of validation is grabbed/blocked or done. | 21:55 |
| blackboxsw | so, we can touch base tomorrow to see if there is anything else of note that would require SRU-regen | 21:56 |
| powersj | sounds good | 21:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!