| holman | cfp256: yeah this could potentially be a change in gc behavior or something like that | 00:10 |
|---|---|---|
| holman | And we really should be reusing the actual session context not just the session object, which is another thing we should revisit. Otherwise the session object doesn't buy us anything afaict | 00:12 |
| holman | But that change will touch a lot more parts of the codebase so not something to deal with now | 00:12 |
| holman | Since that involves passing in a session object that has already entered its context, which will allow us to actually reuse the tcp connection, which is the whole point of a Session | 00:15 |
| holman | Which will make cloud-init a little faster (and would be another way to not leak tcp connections) | 00:16 |
| holman | I didn't realize until I was stepping through your code changes that cloud-init doesn't currently benefit from tcp connection reuse | 00:26 |
| meena | wondering if i can make cloud-init uninstall itself… | 10:07 |
| minimal | meena: yupe, I've done that for bare metal machines that I just want to configure once on 1st boot, used write_files to create a init.d script to delete the cloud-init (and related) packages that is run on next boot | 13:30 |
| meena | minimal: yeah, I reckon an init Script would be easier to handle than a bootcmd | 14:17 |
| minimal | meena: well I assumed that neither bootcmd/runcmd could be used by cloud-init itself to remove itself (properly) and that the removal would need to happen *after* cloud-init had run | 14:20 |
| meena | yeah, it'd get messy | 14:35 |
| meena | holman: falcojr: something's off with the cloud-init tags. git describe --tags HEAD on main gives 23.4-315-gda9b22296 ; why not 24.1? did you change something about the release process? | 19:40 |
| sam_ | it's funny how a week ago I might say that was being anal and now.. :) | 19:42 |
| meena | hah | 19:43 |
| * meena used to be a release manager for a C++ project that produced the same kind of `make dist` tar balls as xz | 19:47 | |
| meena | yeah, looks like a change in the release process. | 19:53 |
| blackboxsw | hrm looks like that signed tag was only present on the upstream/24.1.x branch and not pulled originally from a changeset made to main. I actually don't see that commit sync'd in main git history as is typically the case. | 19:57 |
| meena | was wondering which branch it went on | 19:58 |
| meena | but, yeah, that's a change in the release process | 19:58 |
| holman | That was an unintentional change in the process but we try not to overwrite main history | 20:02 |
| blackboxsw | yes that was an error in the target of the original branch in this case. I don't believe it was intentional https://github.com/canonical/cloud-init/pull/4988 | 20:02 |
| -ubottu:#cloud-init- Pull 4988 in canonical/cloud-init "Release 24.1" [Merged] | 20:02 | |
| meena | what was the target supposed to be? | 20:05 |
| blackboxsw | The branch target of that PR was supposed to be main to preserve that history of tags in main. But, another commit landed in main before that issue could be corrected. The commit in main that 24.1 was generated from was 5c15e7997da1e3de3c8f3322f56a397c4079ca68. What would be missing if one released from 5c15e7997da1e3de3c8f3322f56a397c4079ca68 in main is the change to cloudinit/version.py that bumped the version.py to 24.1. | 20:26 |
| blackboxsw | As brett mentioned, because we have downstream consumers of main at any given point in time for development, we didn't want to break them with a force push correcting this history as that could break automation and testing that downstreams are performing. | 20:33 |
| meena | no need to do that, jrm and i were just working on a net/cloud-init and net/cloud-init-devel release, and he noticed an oddity in the net/cloud-init-devel version number | 20:34 |
| meena | (which we cut from main) | 20:41 |
| blackboxsw | makes sense. apologies for the confusion there. we should have a persistent history of upstream releases originating from main. Only hotfix release tags will not be visible in main as they are created in the specific hotfix release branches upstream/24.1.x upstream/24.2.x and only represent cherry-picks of high priority bug fixes applicable to a given upstream release. | 20:46 |
| blackboxsw | So meena, if you happened to want to release from 24.1.4 hotfix release, which has the BSD-specific run_dir fix, then you'd be grabbing that tag/release from upstream/24.1.x branch. FWIW | 20:49 |
| meena | oh? | 20:50 |
| meena | I don't need to patch that in | 20:50 |
| blackboxsw | nope should be able to pull that from the hotfix branch and... let me get that hotfix release upload pushed to github. We just validated and created a hotfix release for this. Looks like I hadn't pushed to github yet to close out the release and make it official. will do that in about 30 mins. | 20:54 |
| meena | blackboxsw: i didn't notice that patch because it's in releases | 20:55 |
| meena | also, is the homedir patch in there? | 20:55 |
| meena | not according to github https://github.com/canonical/cloud-init/commit/82a5fb3588102b088c84def3a263d4c2d61fcb0f | 20:56 |
| -ubottu:#cloud-init- Commit 82a5fb3 in canonical/cloud-init "distro(freebsd): add_user: respect homedir (#5061)" | 20:56 | |
| meena | but still one patch better than two | 20:56 |
| meena | bugzilla slow | 20:57 |
| blackboxsw | I was referring to https://github.com/canonical/cloud-init/pull/4820 not thie homedir sry | 20:57 |
| -ubottu:#cloud-init- Pull 4820 in canonical/cloud-init "Respect runtime file locations" [Merged] | 20:57 | |
| meena | https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249671&action=diff ← still means i can drop one, and look more official | 20:58 |
| blackboxsw | baby steps. :) | 20:58 |
| meena | next release | 21:00 |
| meena | otoh: when i did release management, i was always said: version numbers are cheap | 21:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!