[07:17] <meena> ebal[m]: i have to look at that code  again, because i don't remember if we correctly handle the complete failure of fallocate
[07:25] <meena>     else:
[07:25] <meena>         try:
[07:25] <meena>             create_swap(fname, size, "fallocate")
[07:25] <meena>         except subp.ProcessExecutionError as e:
[07:25] <meena>             LOG.warning(errmsg, fname, size, "dd", e)
[07:25] <meena>             LOG.warning("Will attempt with dd.")
[07:25] <meena>             create_swap(fname, size, "dd")
[07:25] <meena> it should fallback to dd
[09:14] <ebal[m]> meena:
[09:14] <ebal[m]>  * meena: do you feel this is a bug ?
[09:17] <meena> ebal[m]: sooo, somebody was saying this is a bug in Linux… which, i guess we can agree on, buuuuuutttt, we have enough workarounds for other software's bugs, so, i dunno…
[09:18] <meena> ebal[m]: is this ⬆️the code you have too on your system?
[09:21]  * ebal[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/aJtMUKQOJyBmujmecvNJECUy/message.txt >
[09:22] <meena> so, the code looks the same, and it should fallback to `dd`
[09:26] <meena> ebal[m]: can you post again the log?
[09:27] <ebal[m]> <meena "ebal: can you post again the log"> https://pastebin.com/Wu7cdBCC
[09:29] <meena> so, Unexpected error is not subp.ProcessExecutionError
[09:37] <meena> https://github.com/canonical/cloud-init/blob/master/cloudinit/subp.py#L82 ← at the end it throws IOError
[09:37] <meena> oh, that's from ProcessExecutionError
[11:38] <otubo> Can't believe I missed the first day! My mind really tricked me that it would be today and tomorrow. AHHH
[11:39] <otubo> lucasmoura: Good to see more BR joining the project! :-) Bem vindo!
[11:40] <otubo> I'm recaping the slides from yesterday, looks like I need to bother rick_h now instead of Odd_Bloke :-)
[11:42] <otubo> Oh just saw the emails correcting the dates, so I'm no completely crazy, not yet.
[12:44] <lucasmoura> thanks otubo :)
[12:58] <rick_h> otubo:  apologies, they're all updated now
[12:58] <ananke> hmm, trying to wedge repo key on debian is becoming a challenge. I can't simply drop a gpg key in /etc/apt/trusted.gpg.d/, because those need to be in a keyring format
[12:59] <ananke> the proper format can be obtained by piping the gpg key via 'apt-key add', but that fails on lack of gnupg
[13:00] <rick_h> otubo:  there were a couple of questions to the community for input, especially on commit-bits and new user ramp up that if you get time to think about would be great to get your input.
[13:00] <rick_h> you can see where we got in the running open notes document link
[13:01] <otubo> rick_h: I'll definitely check on that! I believe I already got access to all docs listed on the post.
[13:06] <rick_h> ok cool
[13:17] <ananke> hah, I may have to resort to using AllowUnauthenticated
[13:31] <Odd_Bloke> ananke: What version of apt are you using?  Even oldstable should support ASCII-armored keys in /etc/apt/trusted.gpg.d/, per https://manpages.debian.org/testing/apt/apt-key.8.en.html#SUPPORTED_KEYRING_FILES
[13:37] <Odd_Bloke> meena: ebal[m]: So I don't think that we should be working around what should be a short-term kernel bug in a permanent way in cloud-init, but there _is_ a bug: `create_swap` (the function defined within `create_swapfile`) catches ProcessExecutionError but doesn't re-raise it.  This means that the `create_swap(fname, size, "fallocate")` call will never raise a ProcessExceptionError and so we will never
[13:37] <Odd_Bloke> fallback from failed fallocate swap creation to dd swap creation.
[13:38] <ebal[m]> <Odd_Bloke "meena: ebal: So I don't think th"> Do you need me to file a proper bug report for this ?
[13:40] <Odd_Bloke> ebal[m]: Yes, please!
[13:41] <ebal[m]> I also was thinking if it is of value something like this (just a draft - I am sure this does not work) regarding the swap method
[13:41] <ebal[m]> https://github.com/ebal/cloud-init/commit/58f1819a2c8b880a325ddce9119032d38a0f1603
[13:45] <ananke> Odd_Bloke: I'm doing this on Debian 10.5 AMI, so I imagine it's fairly up to date
[13:45] <ebal[m]> .... so .... to file a bug , should canonical hire me first ?  what's up with this ubuntu one account ? do I need to pledge my loyally to Mark as my lord and savior ?
[13:47] <ananke> Odd_Bloke: the gpg key I have is in ' PGP public key block Public-Key (old)' format, while the existing keys in trusted.gpg.d are in 'PGP/GPG key public ring (v4) created Sun Apr 14 07:48:55 2019 RSA (Encrypt or Sign) 4096 bits MPI=0xb15c6294ca2e5d16'
[13:49] <ananke> but I may need to try that gpg --armor --export format
[14:00] <Odd_Bloke> ananke: Yeah, I would _expect_ exporting like that to work.
[14:00] <Odd_Bloke> ebal[m]: Not to sign up for an Ubuntu One account; there is a CLA you'd need to sign to contribute code, if that would be a blocker for you.
[14:01] <ebal[m]> it's too late now, all my personal data belongs to canonical !
[14:02] <Odd_Bloke> ebal[m]: In terms of that proposed change, I think we need to think about that interface a little more: as that patch is currently written, specifying "fallocate" would mean "fallocate unless it fails then dd" whereas "dd" would just mean "dd".
[14:09] <ananke> Odd_Bloke: so after testing it, it appears that this won't work, and I'm now guessing that apt-key's manual refers to _input_ files when adding new keys via apt-key
[14:13] <ebal[m]> Done, hopefully provides all the necessary info to everybody
[14:13] <ebal[m]> https://bugs.launchpad.net/cloud-init/+bug/1897099
[14:13] <ebal[m]> thanks
[14:13] <ubot5> Ubuntu bug 1897099 in cloud-init "create_swap do not fallback to dd when fallocate fails" [Undecided,New]
[14:16] <ebal[m]> <Odd_Bloke "ebal: In terms of that proposed "> I totally agree with you on that, this was written at around 01.30 in the night - just a rough idea to get some initial feedback - if it make sense. It does for me to have an option to use the swap method - but it may not be important or useful for anybody else.  So instead of spending time there - I could spend time to work on a workaround for personal use.
[14:23] <ananke> argh, so for the gpg file to be valid in /etc/apt/trusted.gpg.d/, you have to do something like:
[14:23] <ananke> wget -q -O - https://deb.parrotsec.org/parrot/misc/parrotsec.gpg | gpg --no-default-keyring --keyring ./tempfile.gpg --import
[14:24] <ananke> gpg --no-default-keyring --keyring ./tempfile.gpg --export > valid_keybox_file.gpg
[14:24] <ananke> the problem is, the resulting file is a binary
[14:25] <ananke> ahh, write_files supports base64! I may do it that way then
[14:32] <Odd_Bloke> ananke: Aha, that makes sense; apologies for the misdirection!
[14:32] <Odd_Bloke> Yeah, base64 is probably the way to go.
[14:38] <ananke> no worries. It's a bit big, close to 10k after base64 encoding, but we'll see if that works
[14:39] <ananke> 9665 bytes base64 encoded, 9457 bytes gzipped + base64
[15:02] <ananke> well I'll be damned, this is also not possible:  ==> amazon-ebs: Error creating launch template for spot instance: InvalidUserData.Malformed: User data is limited to 16384 bytes.
=== tds9 is now known as tds
[15:08] <ananke> going to trim my cloud-init yaml as much as possible, see if I can fit under that limit
[15:21] <otubo> ebal[m]: Odd_Bloke  Does raising an exception from inside create_swap() make sense? https://pastebin.com/2Qv4Npwe
[15:48] <otubo> Odd_Bloke: just saw your PR which is basically the same thing but better.
[15:49] <Odd_Bloke> otubo: Yep, apologies, was "just" testing it before I dropped the link here (and then I went into a meeting), hope you didn't duplicate too much work!
[15:49] <otubo> Odd_Bloke: nah :)
[16:31] <blackboxsw> community notice: hey folks "day 2" of cloud-init virtual summit is today in +30 mins. If you are interested in participating, feel free to drop in for any time you have available https://meet.google.com/rup-mbis-kyr
[16:32] <blackboxsw> virtual cloud-init summit detailed schedule/intent is here: https://discourse.ubuntu.com/t/cloud-init-online-summit-sept-23-24/17867
[17:01] <blackboxsw> community notice: Just about to kick off day 2 virtual cloud-init summit: https://meet.google.com/rup-mbis-kyr  see you there
=== ijohnson is now known as ijohnson|lunch
[17:30] <smoser> falcojr: this is probably a personal rant. but personally, 'client.exec("your command here")' is way inferior to client.exec("your", "command", "here")
[17:30] <smoser> in that you forced shell escaping on the user (and you have not identified what the shell is or should be)
=== ijohnson|lunch is now known as ijohnson
[17:52] <meena> Odd_Bloke: oy. from reading the code i didn't catch that (ha ha ha)
[17:53] <Odd_Bloke> meena: I was happy to raise it, I won't take exception.
[17:54] <Odd_Bloke> meena: Do you happen to know if netifaces works on BSD?
[17:55] <meena> gimme a sec
[17:56] <Odd_Bloke> It works on OS X, that's basically the same thing, right?
[17:56] <meena> Odd_Bloke: meena@fbsd12-1 /u/h/meena> pkg search netifaces
[17:56] <meena> py27-netifaces-0.10.9          Getting network addresses from Python 3
[17:56] <meena> py37-netifaces-0.10.9          Getting network addresses from Python 3
[17:56] <meena> soon to be only py37- ;)
[17:56] <Odd_Bloke> Well that's an encouraging sign, at least.
[17:57] <meena> lemme boot up netbsd or openbsd
[17:58] <Odd_Bloke> rharper: Have you looked at netifaces at all?  If so, do you know how it compares/relates to cloudinit.net?
[17:58] <meena> or, i could look here: https://pkgsrc.se/search.php?so=netifaces
[18:00] <meena> blackboxsw: what's the libpcap library we looked into?
[18:00] <rharper> Odd_Bloke: yeah, i've used in the past; and originally wrote the net layer in that; but we wanted to avoid the depedency
[18:01] <blackboxsw> meena: https://github.com/vmware/cloud-init-vmware-guestinfo   which uses python3-netifaces
[18:01] <rharper> and generally, the output shown doesn't show us anything we can't already discover in the net layer now;
[18:01] <blackboxsw> so Andrew Kutz is looking at how best to upstream that new datasource and discovery mechanisms
[18:03] <meena> blackboxsw: i meant scapy
[18:03] <meena> i did look into netifaces previously, btw… for… something
[18:03] <meena> libioc
[18:22] <akutz> Hi all!
[18:22] <smoser> o/
[18:22] <smoser> very happy to have a vmware representative here.
[18:23] <smoser> so , wrt cloud-init-vmware-guestinfo
[18:23] <smoser> i think it fits fine as a local datasource.
[18:24] <smoser> the datasource declared (in network config format) that "you should dhcp on all the things".
[18:24] <smoser> cloud-init should do that as it does ephemeral network on other providers.
[18:24] <smoser> then read the data that is there
[18:24] <smoser> and declare that that was the metadata config.
[18:25] <smoser> err... declare that that was the network config.
[18:25] <smoser> the only difference from what you have, is that you are calling the network data that is in your 'metadata.yaml' file network config.
[18:25] <smoser> it is not. it is pre-network config.
[18:27] <otubo> akutz: also, how are the plans to merge it into cloud-init main tree?
[18:28] <akutz> @otubo - Um, I do not know. That is why I am here, to ask y'all :)
[18:30] <akutz> @smoser - re: pre-network config -- interesting. Did I misunderstand https://cloudinit.readthedocs.io/en/latest/topics/network-config.html?
[18:30] <smoser> akutz: you did not misunderstand.
[18:30] <smoser> there is no such thing, really.
[18:31] <otubo> akutz: I'm very interested in having that on RHEL :) Since the current OVF DataSource is kinda bogus, changing the instance-id and stuff
[18:31] <smoser> but i'm saying that what you are providing is *not* network config.
[18:31] <smoser> but that cloud-init needs to utilize the information you are providing to tell it how to get the network config.
[18:31] <smoser> and then when it has it, it would exit local datasource, let the OS bring up the networking, and move on.
[18:32] <akutz> Hmm, but the cloud-init docs explicitly refer to what is being provided as the network configuration...
[18:32] <akutz> It's the intended config, and it brings up the actual network, with the observed config. But that's more of an issue with the way the cloud-init docs are written IMO.
[18:32] <smoser> alternatively... i dont see any problem with providing current network information through the same general mechanism as instance-data is being provided.
[18:34] <blackboxsw> community notice: reconvening for live community discussion for  virtual cloud-init summit: https://meet.google.com/rup-mbis-kyr
[19:24] <ananke> this is very peculiar. enabling an additional apt-repo via cloud-init causes apt to fail to resolve DNS entries. it does not make sense at all
[19:25] <blackboxsw> hrm, depends on what deb package is being installed? Something upgrading network utils?
[19:29] <ananke> ahh, wonder if it has something to do with resolvconf
[19:30] <ananke> good idea, thank you
[19:31] <ananke> looking at cloud-init-output.log it appears that the 'update' ran just fine, but then 'upgrade' module is what starts to fail
[19:34] <blackboxsw> Thanks folks for the attendance on cloud-init virtual summit. we are dropping into separate hacking/discussion channels for the remainder. We'll post links to available google meet breakout sessions if interested
[19:35] <akutz> I am taking a bio break and will look for the link to the break out for vSphere cloud-init
[19:35] <falcojr> akutz: I'll post the link soon...also taking a short break
[19:35] <blackboxsw> topic 1: (bug discussions, primary AWS support regions without IMDSv2 support https://bugs.launchpad.net/cloud-init/+bug/1896532):  meet room: vhttps://meet.google.com/zqb-tewn-qpx
[19:35] <ubot5> Ubuntu bug 1896532 in cloud-init "Ec2Datasource fails in environments without IMDSv2" [Undecided,New]
[19:37] <blackboxsw>  topic2: was I believe ongoing network refactor discussion https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#ongoing-refactors
[19:37] <akutz> falcojr: ack
[19:40] <falcojr> vSphere discussion: https://meet.google.com/acr-vrnr-rab
[20:33] <ananke> yep, /etc/resolv.conf was being obliterated, due to apt-get --upgrade's pulling of resolv.conf
[20:34] <ananke> I mean pulling of resolvconf
[21:05] <Odd_Bloke> rharper: I just put a bottle of the 2017 release of https://www.beeradvocate.com/beer/profile/32763/322625/ in the fridge, so I'm at least replicating part of the in-person summit experience we'd have had. :p
[21:08] <rharper> oooo
[21:09] <rharper> Odd_Bloke: nice!
[21:39] <meena> mock me, why don't you https://github.com/canonical-web-and-design/cloud-init.io/pull/145#issuecomment-698538416
[21:45] <blackboxsw> haha "not yet" :) just you wait webteam-app I'll show you who is a collaborator
[21:47] <blackboxsw> will ping the internal web team tomorrow if they have questions on the PR meena thanks for filing