| otubo | blackboxsw: tribaal well, we don't have a specific plan right now, but we're in terms of having one pretty soon. I'm working together with the Fedora maintainer so we can have a better policy for updating the package, so that could be extended to CentOS as well. | 10:09 |
|---|---|---|
| otubo | I'll send an email to the group once we have a plan. Thanks for asking about that :-) And sorry for the delay on the replay, I was on vacation :-) | 10:10 |
| tribaal | otubo: oh, that's good to hear! in the mean time, what would you suggest to be the best course of action? For context, we're a cloud provider maintaining several OS base images - CentOS beingone of them - and we recently (in 19.3) have our own cloud-init datasource that we'd like to use instead of the more generic former one | 10:59 |
| tribaal | so, ubuntu images have their cloud-init version SRU'd, and for debian 10 we will inject a deb from testing and do our own QA pass over it, but I'm not too sure what the best course of action is here for CentOS/Fedora (having personally had less exposure to those ecosystems) | 11:00 |
| tribaal | otubo: also - "an email to the group" -> I'd be very interested to be part of that group if I'm not there already via e.g. the cloud-init mailing list :) | 11:06 |
| otubo | tribaal: https://launchpad.net/~cloud-init there's a mailing list section at the bottom :) | 11:26 |
| otubo | tribaal: if I understand you correctly, all you need is more or less an updated package version for CentOS so you can use your DataSource? | 11:27 |
| tribaal | otubo: yes, correct. We could build a new package ourselves (of course) but would rather help test/contribute if appropriate | 11:46 |
| tribaal | we don't (currently) maintain public archives for rpms either, so skipping the cost of setting that up would be welcome. But again, if needed, we can. | 11:47 |
| otubo | tribaal: what are the issues when using your DS with current available packages? | 11:48 |
| tribaal | otubo: so, in 18.5 (or generally, before 19.3) the datasource we use is racy in specific conditions, resulting in a portion of cloud-init runs to fail to bring up networking. Note: that's specific to our platform. | 11:51 |
| tribaal | since we want to have the liberty to diverge from our previously-used datasource (cloudstack), we created an Exoscale specific one, the first fix being that specific race condition | 11:53 |
| otubo | tribaal: I understand. Well I can't promise you any dates, but I'm positive we're going to update at least Fedora in February. | 12:13 |
| otubo | tribaal: I still need to work on CentOS | 12:13 |
| tribaal | otubo: understood - let me know if/how we can help | 12:16 |
| otubo | tribaal: what about a small vps on your infrastructure for running tests? :-) | 13:11 |
| robjo | rharper: ping | 14:53 |
| rharper | robjo: here | 15:23 |
| robjo | rharper: received a bug w.r.t. mixing "static" and DHCP IP addresses, i.e. IPv4 may be static and IPv6 dynamic or vice versa | 15:24 |
| robjo | I think we have reached the breaking point of trying a non-differentiated write of ifcfg-eth* | 15:25 |
| robjo | OK with introducing a "flavor" into the sysconfig dict that configures the renderer? | 15:25 |
| robjo | BOOTPROTO setting needs to be handled differently between SLES and RHEL? | 15:26 |
| rharper | reading | 15:33 |
| robjo | https://bugs.launchpad.net/cloud-init/+bug/1858808 | 15:33 |
| ubot5 | Ubuntu bug 1858808 in cloud-init "On SUSE mixed static and dhcp setups are no properly configured" [Undecided,New] | 15:33 |
| robjo | RHEL will complain about BOOTPROTO setting of dhcp4 and dhcp6, I think | 15:34 |
| rharper | yes | 15:34 |
| rharper | I'm updating bug with doc details | 15:34 |
| robjo | I'll add the SLES doc | 15:35 |
| rharper | Ive done that | 15:35 |
| robjo | lol | 15:36 |
| rharper | currently looking for why we set BOOTPROTO="static" | 15:36 |
| rharper | as that doesn't seem to have any affect; I suspect none is the right setting instead | 15:36 |
| robjo | In newer versions, per comment in the code we do not set static | 15:36 |
| rharper | ok | 15:36 |
| robjo | Well "none" is implied "static", I am not a fan of this being implicit | 15:37 |
| rharper | sure; but I suspect it's better to follow documentation of the distro | 15:37 |
| robjo | Well, "none" if we write that actually has a meaning: | 15:40 |
| robjo | none | 15:40 |
| robjo | For bonding slaves, to .....Note: Do not use to just skip the IP setup -- use | 15:40 |
| robjo | BOOTPROTO="static" without any addresses in the IPADDR | 15:40 |
| robjo | variables (or routes) instead. | 15:40 |
| rharper | hrm | 15:40 |
| rharper | that's troublesome; I don't see any code that checks the static value | 15:40 |
| robjo | we really do want "static" when that's what we get from the config ;) | 15:41 |
| rharper | nm, I totally missed the first line | 15:43 |
| ananke | so this is a fun error. running '/usr/bin/cloud-init status --wait' on amazon linux 2 results in a 'NameError: global name 'PermissionError' is not defined' | 16:16 |
| ananke | full error: http://dpaste.com/3NEB0AS | 16:17 |
| rharper | https://bugs.launchpad.net/cloud-init/+bug/1831146 | 16:25 |
| ubot5 | Ubuntu bug 1831146 in cloud-init "PermissionError undefined on python 2.7" [Medium,Triaged] | 16:25 |
| blackboxsw | ananke: what distro again CentOS 7? | 16:34 |
| Odd_Bloke | blackboxsw: "on amazon linux 2" | 16:35 |
| blackboxsw | which is python3 ? | 16:36 |
| Odd_Bloke | Is it? | 16:36 |
| blackboxsw | I thought it wasn't as we heard in cloud-init summit I think? | 16:36 |
| blackboxsw | heh, and right (I was oblivious to the "on amazon linux 2" and jumped straight to the error | 16:37 |
| blackboxsw | https://forums.aws.amazon.com/message.jspa?messageID=870220 | 16:37 |
| blackboxsw | AL2 default looks to be py2 per that thread and the faq for core packages maintained https://aws.amazon.com/amazon-linux-2/faqs/ | 16:38 |
| blackboxsw | sooo Odd_Bloke with us dropping py2.7 in trunk, where does that leave AL2 and it's python2 default | 16:39 |
| blackboxsw | s/trunk/tip | 16:39 |
| Odd_Bloke | It leaves Amazon needing to get into this^Wlast decade. :3 | 16:40 |
| blackboxsw | maintaining their own cloud-init py2 compat support I suppose | 16:40 |
| blackboxsw | yeppers, unfortunately | 16:40 |
| ananke | figures that I'd dig up another issue :) | 16:40 |
| Odd_Bloke | For a non-sarcastic answer, I'm not entirely sure. | 16:40 |
| blackboxsw | yeah and not one this time that upstream would be likely to address ananke :/ it's still worth a bug https://bugs.launchpad.net/cloud-init/+filebug | 16:41 |
| Odd_Bloke | Well, the bug is in 18.5, right? | 16:41 |
| ananke | /bin/cloud-init 18.5-2.amzn2 | 16:41 |
| Odd_Bloke | Which was advertised as supporting 2.7. | 16:41 |
| ananke | yep | 16:41 |
| blackboxsw | Odd_Bloke: ahh right. :/ | 16:41 |
| blackboxsw | so that'd be us patching the last py2 support branch | 16:42 |
| ananke | this is whatever the latest amazon linux 2 btw | 16:42 |
| Odd_Bloke | Yeah, though there's not much benefit to doing that if Amazon aren't going to use that branch. | 16:42 |
| blackboxsw | minor changeset to fix that for python2 :/ | 16:42 |
| Odd_Bloke | So we probably need to reach out to Amazon and talk to them about how they want to handle this sort of issue, as they're one of the last places that has Python 2 in their most recent release. | 16:43 |
| ananke | with amazon pushing cloud-init, I imagine they'd be receptive | 16:47 |
| Odd_Bloke | blackboxsw: rharper: BTW, realised I hadn't actually done the thing: https://github.com/canonical/cloud-init/pull/159 | 17:04 |
| blackboxsw | haha Odd_Bloke | 17:04 |
| blackboxsw | man | 17:04 |
| blackboxsw | oops broke protocol | 17:04 |
| blackboxsw | btw rharper https://github.com/canonical/cloud-init/pull/77 has a nit if you'd like to add it to the comment | 17:05 |
| blackboxsw | we can land that then ^ | 17:05 |
| Odd_Bloke | Haha, was just about to point that out. | 17:05 |
| Odd_Bloke | blackboxsw: If you want it fixed, should it be Approved? | 17:05 |
| blackboxsw | since you are making the rules Odd_Bloke you can break them :) | 17:05 |
| blackboxsw | Odd_Bloke: I guess that falls into "Aprrove (with nits)" | 17:06 |
| blackboxsw | I can make the change then :) | 17:06 |
| rharper | blackboxsw: I think so, I have allow edits enabled | 17:06 |
| blackboxsw | will try that out now | 17:06 |
| blackboxsw | hrm so should I be able to git push ryan's github repo fix/network-static6-rendering | 17:10 |
| * blackboxsw reads the docs | 17:11 | |
| blackboxsw | as I don't think I can add a comment to a file that wasn't touched by the original PR via the github PR web UI | 17:11 |
| blackboxsw | got it | 17:17 |
| blackboxsw | git checkout <rh-remote>/<pr_branch_name> -b <local_branch>; add nits; git commit -am 'nits' ; git push <rh-remote> <local_branch>:<pr_branch_name> | 17:19 |
| blackboxsw | oops, clicked the merge button before fully scrubbing the squashed commit message. Odd_Bloke rharper when we have Co-authored-by references in a squash merge commit, should we be using our @canonical or personal emails? | 17:33 |
| blackboxsw | it seems Dan and I have a default email set as personal | 17:34 |
| blackboxsw | not sure it matters much as our merge markers are all authored as @canonical | 17:35 |
| blackboxsw | I've switched my primary email address in my github profile to chad.smith@canonical.com, but then I need to remember to change/override that for any external opensource projects I would touch. | 17:36 |
| blackboxsw | meena: I think the only thing blocking one of your PRs is dropped the integration test test_boottime from the PR (and maybe addressing an integration testt as a separate PR) https://github.com/canonical/cloud-init/pull/53/files#r360061164 | 18:14 |
| Odd_Bloke | blackboxsw: I don't think it particularly matters, TBH. | 18:38 |
| blackboxsw | Odd_Bloke: as in we can land as is, or maybe add a comment #TODO(move to cloud_tests) for that test? | 18:40 |
| Odd_Bloke | blackboxsw: No, I meant the thing you pinged me about. :) | 18:40 |
| blackboxsw | ahh email | 18:41 |
| blackboxsw | right | 18:41 |
| meena | friends, it's late here( 20:38)so I'm in bed already and very sleepy | 19:39 |
| meena | I'll clean this up tomorrow | 19:40 |
| wyoung | nn | 19:40 |
| ananke | is there a recommended solution for running 'runcmd' items as a specific user? | 21:31 |
| ananke | say I have just a few commands, so not worth creating a discrete script. I could prepend each one with sudo, but it would seem there would be an easier way | 21:36 |
| Odd_Bloke | runcmd doesn't have support for it, from looking at the code. | 21:39 |
| Odd_Bloke | We could consider adding such support, though we would need to think about the security/correctness implications of not using sudo (or, I suppose, we could just call sudo). | 21:41 |
| Odd_Bloke | ananke: You could do `sudo sh -c "...; ..."`, which simplifies things a little. | 21:41 |
| ananke | Odd_Bloke: thanks for the suggestions! | 21:54 |
| Odd_Bloke | :) | 22:15 |
| smoser | ananke: yaml anchors are useful | 22:52 |
| smoser | http://paste.ubuntu.com/p/35DFhjsGYP/ | 22:52 |
| smoser | thats the kind of stuff that smoser wastes time on. | 22:53 |
| robjo | smoser: What does this mean in Ubuntu? in a netplan | 23:01 |
| robjo | eth1: | 23:01 |
| robjo | match: | 23:01 |
| robjo | macaddress: cf:d6:af:48:e8:80 | 23:01 |
| robjo | set-name: eth1 | 23:01 |
| robjo | does the interface get brought up but get no IP address? | 23:02 |
| robjo | or does dhcp magically run? | 23:02 |
| powersj | hmm I thought you had to have a dhcp4: true or a addresses: | 23:14 |
| blackboxsw | yowsa smoser that is a hefty bit of cloud-config. me saves it to grok a bit later | 23:26 |
| blackboxsw | I don't use anchors nearly enough (and probably need to check it out via the cloud-init devel schema annotation stuff to make sure we can annotate properly) | 23:27 |
| blackboxsw | s/nearly enough/at all/ | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!