| otubo | rharper, just a quick question from last week's issue: I can't define which datasource cloud-init SHOULD NOT look for, only a data source it SHOULD look for, right? My question basically is: If I don't want cloud-init to spend so much time trying yo find network-based datasources, I should have different ds-identify configuration files for every cloud provider we (as in Red Hat) support. | 10:47 |
|---|---|---|
| otubo | rharper, Am I correct? If I deploy a vm with only openstack it shouldn't spend time looking for EC2 configuration and taking a long time to eventually timeout in the end | 10:48 |
| Odd_Bloke | otubo: Do you know about ds-identify? It's used early in boot to determine what data source applies to the current instance (without using the network), and writes out configuration so cloud-init will only run that data source. | 13:13 |
| otubo | Odd_Bloke, I know ds-identify and that's exactly what I mean by one configuration per cloud provider. For OpenStack I should have it set to search for OpenStack and nothing else, if the VM is on EC2 I should set it to search for EC2 and nothing else, right? | 13:18 |
| Odd_Bloke | otubo: Oh, I'm sorry, I skipped over the word "ds-identify" in your question. >.< | 13:18 |
| otubo | :-D | 13:19 |
| Odd_Bloke | something something monday morning something ;) | 13:19 |
| Odd_Bloke | ds-identify doesn't use the network, so you shouldn't need to configure it differently per provider. | 13:19 |
| otubo | Odd_Bloke, So basically I should just list all RHEL supported cloud providers on ds-identify.cfg and we're good? Neat :-) | 13:20 |
| otubo | Odd_Bloke, hard question now: We're on cloud-init-18.5 shall that be ok, or should I update to a newer version? | 13:21 |
| Odd_Bloke | So if you're talking _configuration_ then you might be configuring an _override_. | 13:21 |
| otubo | No specific reason to stay on cloud-init 18.5, we just do a downstream rebase on demand. | 13:22 |
| Odd_Bloke | Ah, no, you presumably mean configuring datasource_list, not the other option I was thinking of. | 13:22 |
| Odd_Bloke | otubo: I'd recommend taking the latest if you're putting in effort to move to a newer version, but obviously that's your call! | 13:24 |
| otubo | Odd_Bloke, I mean defining the 'datasource' attribute on the file /etc/cloud/ds-identify.cfg | 13:24 |
| otubo | Odd_Bloke, ok cool, I'll run some tests and check if we get it going. :-) | 13:25 |
| Odd_Bloke | otubo: OK, "datasource" _will_ override, I think. | 13:25 |
| otubo | Odd_Bloke, ok, I'll give it a try. Thanks! | 13:26 |
| Odd_Bloke | You probably want to use datasource_list. | 13:26 |
| Odd_Bloke | That way you can ship the same list on every platform, and ds-identify will work it out at first boot. | 13:27 |
| Odd_Bloke | (OTOH, if you already ship per-platform images, it doesn't necessarily hurt to hardcode the specific platform you know they're used for.) | 13:27 |
| otubo | Odd_Bloke, we don't have specific packages for specific environments, it's a single rpm for all environments. | 13:29 |
| otubo | Odd_Bloke, but 'datasource' on ds-identify.cfg also accepts a list, right? At lease that's my understanding from ds-identify | 13:30 |
| Odd_Bloke | otubo: I think it can, yes, but that will set the list of datasources that cloud-init iterates through. | 13:31 |
| Odd_Bloke | So if you put a network data source in there, cloud-init will attempt to hit the network for that data source. | 13:31 |
| otubo | oh I see | 13:31 |
| Odd_Bloke | datasource_list defines the list of datasources that _ds-identify_ iterates through. | 13:31 |
| otubo | Yes, right, right, I remember now. | 13:32 |
| Odd_Bloke | And then when it finds one, it sets that as the one DS that cloud-init will "iterate through". | 13:32 |
| otubo | Odd_Bloke, then I'm not really sure where to set datasource_list. | 13:32 |
| Odd_Bloke | otubo: It's configurable in the same location, I believe. | 13:33 |
| otubo | Odd_Bloke, ok I'll give it a try. | 13:33 |
| otubo | thanks a lot :-) | 13:34 |
| Odd_Bloke | Happy to help! | 13:36 |
| === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Aug 19 16:15 UTC | cloud-init v 19.2 (07/17) | https://bugs.launchpad.net/cloud-init/+filebug | ||
| blackboxsw | rharper: Odd_Bloke if either of you get a chance to re-review the ubuntu-drivers branch, here is the debconf based approach to latelink setup. https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371369 | 16:12 |
| blackboxsw | #startmeeting Cloud-init bi-weekly status | 16:18 |
| meetingology | Meeting started Mon Aug 19 16:18:48 2019 UTC. The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology. | 16:18 |
| meetingology | Available commands: action commands idea info link nick | 16:18 |
| blackboxsw | Hi guys and girls, welcome to cloud-init biweekly status meeting | 16:19 |
| blackboxsw | #chair rharper | 16:19 |
| meetingology | Current chairs: blackboxsw rharper | 16:19 |
| blackboxsw | #chair Odd_Bloke | 16:19 |
| meetingology | Current chairs: Odd_Bloke blackboxsw rharper | 16:19 |
| blackboxsw | cloud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development. | 16:19 |
| blackboxsw | All discussions and interjections are welcome | 16:19 |
| blackboxsw | our format is the following topics: Previous Actions, Recent Changes, In-progress Development, Office Hours | 16:19 |
| blackboxsw | last meeting's minutes are herer | 16:20 |
| blackboxsw | #link https://cloud-init.github.io/status-2019-08-05.html#status-2019-08-05 | 16:20 |
| rharper | o/ | 16:20 |
| blackboxsw | we host the meeting every two weeks at the date and time indicated in the IRC channel topic ^ | 16:20 |
| * blackboxsw changes that topic now, since we(I) forgot last time | 16:20 | |
| blackboxsw | #topic cloud-init Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Sept 2 16:15 UTC | cloud-init v 19.2 (07/17) | https://bugs.launchpad.net/cloud-init/+filebug | 16:20 |
| blackboxsw | next meeting in two weeks | 16:21 |
| blackboxsw | #topic Previous actions | 16:21 |
| blackboxsw | I see no previous actions raised during last meeting. Woo hoo! | 16:21 |
| blackboxsw | #topic Recent Changes | 16:22 |
| blackboxsw | the following are commits that | 16:22 |
| blackboxsw | have landed in tip of master for cloud-init since the last meeting: git log --since 2019-08-04 | 16:22 |
| blackboxsw | - cloudinit/distros/parsers/sys_conf: add docstring to SysConf | 16:22 |
| blackboxsw | [Daniel Watkins] | 16:22 |
| blackboxsw | - pyflakes: remove unused variable [Joshua Powers] | 16:22 |
| blackboxsw | - Azure: Record boot timestamps, system information, and diagnostic events | 16:22 |
| blackboxsw | [Anh Vo] | 16:22 |
| blackboxsw | - DataSourceOracle: configure secondary NICs on Virtual Machines | 16:22 |
| blackboxsw | [Daniel Watkins] | 16:22 |
| blackboxsw | - distros: fix confusing variable names [Daniel Watkins] | 16:22 |
| blackboxsw | - azure/net: generate_fallback_nic emits network v2 config instead of v1 | 16:22 |
| blackboxsw | [Chad Smith] | 16:22 |
| blackboxsw | - Add support for publishing host keys to GCE guest attributes | 16:22 |
| blackboxsw | [Rick Wright] | 16:22 |
| blackboxsw | - New data source for the Exoscale.com cloud platform [Chris Glass] | 16:22 |
| blackboxsw | - doc: remove intersphinx extension [Daniel Watkins] | 16:22 |
| blackboxsw | - cc_set_passwords: rewrite documentation [Daniel Watkins] (LP: #1838794) | 16:22 |
| ubot5 | Launchpad bug 1838794 in cloud-init "Set Passwords documentation describes incorrect behaviour for `password` config key" [Low,Fix committed] https://launchpad.net/bugs/1838794 | 16:22 |
| blackboxsw | We have also published commits though " - Azure: Record boot timestamps, system information, and diagnostic events" to Ubuntu Eoan (19.10) (cloud-init v.19.2-13) if folks want a glimpse of those features | 16:24 |
| blackboxsw | Many thanks to Azure and GCE folks for their commits and a hi five to tribaal for adding Exoscale | 16:24 |
| blackboxsw | #topic In-progress Development | 16:25 |
| blackboxsw | As always, we try to keep most of our work up to date in trello | 16:25 |
| blackboxsw | #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin | 16:25 |
| blackboxsw | cards in the "Reviewing" column should represent the work we expect to have up for review in the short term. | 16:26 |
| blackboxsw | rharper is mid-stream on some investigations that will likely lead to significant speed improvements for cloud-init | 16:27 |
| blackboxsw | Odd_Bloke: is working on some significant improvements for Oracle's datasource rendering network config | 16:28 |
| blackboxsw | and I'm working on getting OpenStack and Ec2 datasources to talk network config v2. | 16:29 |
| blackboxsw | beyond that work we have a pretty healther active review queue | 16:29 |
| blackboxsw | #link https://code.launchpad.net/cloud-init/+activereviews | 16:29 |
| blackboxsw | of note, some freebsd work is in flight, gce dns improvements, udev triggers and OVF handling user-defined scripts. | 16:31 |
| blackboxsw | We | 16:31 |
| blackboxsw | will spend the latter part of this meeting looking over the review queue to see that open branches are in the proper state | 16:32 |
| blackboxsw | Also, our plan for this week is to cut a Cloud-init SRU (Stable release update) for upload into xenial, bionic and disco. | 16:33 |
| blackboxsw | expectation is that those Ubuntu series will see an update for cloud-init after our ~7 days of testing and verification | 16:34 |
| blackboxsw | rharper: Odd_Bloke anything else in flight that we should note here? | 16:34 |
| rharper | that looks like everything | 16:34 |
| blackboxsw | without further ado, we can transition to office hours | 16:35 |
| blackboxsw | #topic Office Hours (next ~30 mins) | 16:35 |
| blackboxsw | We're here for any questions, bugs, discussions people would like to have around cloud-init. This block of time is available for any discussions or requests people may have. | 16:36 |
| blackboxsw | We will also spend this time grooming the active review queue to make sure developers get any needed feedback on their active branches. | 16:37 |
| blackboxsw | If there are any branches that need more eyes, please bring them up here or make sure they are in the 'Needs review' state in Launchpad | 16:37 |
| tribaal | blackboxsw: thanks! | 16:38 |
| blackboxsw | tribaal: good work. I think Odd_Bloke landed the followup work to enable exoscale datasource config to cloud-init.templates to 'enable' it. And looks like that has landed | 16:40 |
| tribaal | blackboxsw: I'm happy to help verify SRU bugs when the process is kicked - just let me know | 16:40 |
| blackboxsw | so it's 'on' in Eoan, once SRU is kicked off, it'll be in there | 16:40 |
| tribaal | yep, I need to push an Eoan template to our preprod environment tomorrow to kick the tires, but I don't expect anything funny | 16:41 |
| blackboxsw | tribaal: will do. I think the only thing we are waiting on before SRU is landing this ubuntu-drivers branch https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371369 | 16:41 |
| blackboxsw | any feedback on behavior your in Eoan from you tribaal would be helpful. | 16:42 |
| blackboxsw | let's try that in English this time: any feedback on the behavior in your Eoan environment would be helpful tribaal. | 16:43 |
| tribaal | blackboxsw: haha that's what I inferred :) | 16:43 |
| blackboxsw | :) /me hits the review queue | 16:43 |
| blackboxsw | rharper: if you get a chance: you've landed https://git.launchpad.net/cloud-init/commit/?id=b3a87fc0. Do we also still need the following branch? https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/363571 | 16:47 |
| blackboxsw | If so, I'll spend this time trying to write up unit tests for this if possible | 16:48 |
| rharper | blackboxsw: I don't think so; my branch should include all the needs of that branch | 16:48 |
| rharper | and the branch tests the wait_for_physdev as well as updates the opensuse net render paths to account for the udev rule number change | 16:49 |
| blackboxsw | that's kindof what I was thinking/hoping. I'll mark it rejected in favor of your commit, and we'll see what robjo thinks on that. We can reopen and try to address the unit test aspect of his branch if still needed. | 16:50 |
| rharper | I think we can mark that branch closed | 16:50 |
| rharper | robjo: had already looked at the branch before landing | 16:50 |
| blackboxsw | ok done | 16:52 |
| blackboxsw | thanks Florian for your first commit! https://code.launchpad.net/~florian-mueller-v/cloud-init/+git/cloud-init/+merge/371298 ... doc update approved | 16:54 |
| robjo | I don't recall having looked at https://git.launchpad.net/cloud-init/commit/?id=b3a87fc0 and there was no entry in the bug to remind me that I did. Anyway, I've done so now and yes, this obsoletes https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/363571 | 16:58 |
| blackboxsw | thank you robjo for that | 17:00 |
| rharper | robjo: https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/366667 ; yes, I should have linked to the bug in my MP | 17:04 |
| rharper | you did take a look a while back though | 17:04 |
| robjo | rharper: I believe you, just cannot remember.... | 17:06 |
| rharper | heh, it was a while back | 17:06 |
| blackboxsw | I think we should probably wrap up the meeting for this week. I've got one more review to clear. | 17:24 |
| blackboxsw | Thanks again all for joining. minutes will be posted to github | 17:24 |
| blackboxsw | #link https://cloud-init.github.io/ | 17:25 |
| blackboxsw | #endmeeting | 17:25 |
| meetingology | Meeting ended Mon Aug 19 17:25:18 2019 UTC. | 17:25 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/cloud-init/2019/cloud-init.2019-08-19-16.18.moin.txt | 17:25 |
| Odd_Bloke | rharper: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371350 <-- happy with this now? | 18:15 |
| rharper | Odd_Bloke: yes | 18:43 |
| Odd_Bloke | smoser: Do you want to change your review on https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371403 or shall I just Approved it? (Does the lander check the reviews?) | 19:55 |
| Odd_Bloke | blackboxsw: There's a typo, I'm afraid. | 19:57 |
| smoser | that wasnt the right link i think | 19:57 |
| smoser | was it ? | 19:57 |
| smoser | https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371403 | 19:59 |
| rharper | yeah | 19:59 |
| smoser | i approved therel | 19:59 |
| rharper | thx | 20:00 |
| powersj | \o/ | 20:04 |
| powersj | rharper, blackboxsw Odd_Bloke did someone take notes? | 20:04 |
| rharper | I can do a mental brain dump; and Odd_Bloke summed up the next steps at the end | 20:05 |
| blackboxsw | powersj: rharper admittedly brief notes https://pastebin.canonical.com/p/Tm3QBsvwSx/ | 20:08 |
| blackboxsw | Odd_Bloke: ^ could use second set of eyes to decode what that means in terms of followup branches | 20:09 |
| Odd_Bloke | powersj: So there are a couple of sets of decisions to be made. The | 20:09 |
| rharper | blackboxsw: thanks | 20:09 |
| Odd_Bloke | *nods sagely* I meant to press Return then. | 20:09 |
| blackboxsw | that didn't capture what pre-flight network configuration/interrogation needs to be | 20:09 |
| Odd_Bloke | powersj: So there were a couple of sets of decisions to be made. We decided that we _do_ need to parse the network config that the initramfs produces, because anything else is likely to break assumptions that other tools make about system configuration being accurate (or it will just flat out break!). We also decided that it probably makes sense for the initramfs network configuration determination to | 20:11 |
| Odd_Bloke | move to be part of the fallback network config source. | 20:11 |
| Odd_Bloke | Because the correct network configuration to fall back to on, e.g., an iSCSI root system is _not_ DHCP-on-first-interface, it's to use the network configuration the initramfs generated. | 20:12 |
| Odd_Bloke | The fact that the initramfs network config source is separate now means that we can continue along our current implementation path (i.e. land my change, and put dracut parsing into the "initramfs" network config source) and once that's done, we can address moving the initramfs network config source into the fallback network config source. | 20:13 |
| Odd_Bloke | (Some Oracle DS changes will be required at that point, but they should be minimal so we won't be throwing any significant work away.) | 20:13 |
| Odd_Bloke | rharper: blackboxsw: smoser: Does ^ represent what you think we agreed on? | 20:15 |
| blackboxsw | that is much clearer than my abbreviated notes Odd_Bloke +1. 1. your branch lands 2. dracut parsing 3. fallback config handling initramfs config on appropriate platforms | 20:23 |
| blackboxsw | I *think* | 20:23 |
| smoser | +1 | 20:23 |
| powersj | excellent :) | 20:23 |
| rharper | Odd_Bloke: +1 | 20:23 |
| blackboxsw | gah Odd_Bloke sorry about that. endswidth :) | 20:57 |
| * blackboxsw runs tox this time | 20:58 | |
| Odd_Bloke | blackboxsw: CI was +1, so we're probably missing a test. | 20:58 |
| blackboxsw | yeah I'll add that test now | 20:58 |
| blackboxsw | it's all mocked in tests | 20:58 |
| blackboxsw | Odd_Bloke: pushed a fix | 21:09 |
| blackboxsw | 8b8401cd5f99e907a944b05e2a1caf1e889ecbbf | 21:09 |
| smoser | once i saw a program (or possibly imagined) that allowed you to do: | 21:12 |
| smoser | some-long-running-command | that-program | 21:13 |
| smoser | and it would hand back a url that you could share with someone else | 21:13 |
| smoser | so they could see status or "watch" it | 21:13 |
| smoser | something like 'pastebinit' but with progress | 21:13 |
| smoser | my google is failing now | 21:13 |
| smoser | anyone's brain do better? | 21:14 |
| Odd_Bloke | blackboxsw: LGTM, Approved. | 21:14 |
| Odd_Bloke | That sounds familiar. | 21:14 |
| Odd_Bloke | smoser: https://seashells.io/ <-- this? | 21:14 |
| Odd_Bloke | (I feel like that isn't what I was remembering, but looks like it would do the trick.) | 21:15 |
| smoser | i think so | 21:15 |
| smoser | or maybe | 21:16 |
| smoser | https://github.com/anishathalye/seashells/issues/2 | 21:25 |
| smoser | provides some alternatives too. | 21:25 |
| smoser | thanks Odd_Bloke | 21:25 |
| blackboxsw | rharper: do you recall how we describe global dns in network v2? | 22:03 |
| rharper | there is no global dns | 22:04 |
| * blackboxsw thought there was a bug on this | 22:04 | |
| rharper | dns is always per interface | 22:04 |
| rharper | there is a v1 bug where we will decorate v2 with v1 's "global" values if the target interface isn't configured already | 22:04 |
| blackboxsw | rharper: network_data.json describes a global 'services' key (outside of specific network/interfaces) which can contain dns type items | 22:04 |
| rharper | yes, the easiest thing to do is repeat that on each interface | 22:04 |
| blackboxsw | what shall we do with such 'global' service definitions | 22:04 |
| blackboxsw | ok will do | 22:04 |
| rharper | https://bugs.launchpad.net/cloud-init/+bug/1750884 | 22:06 |
| ubot5 | Ubuntu bug 1750884 in cloud-init "[2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution" [Medium,Fix released] | 22:06 |
| rharper | https://git.launchpad.net/cloud-init/commit/?id=d29eeccd | 22:06 |
| blackboxsw | ah thanks! | 22:06 |
| rharper | we may want to follow that same logic | 22:06 |
| rharper | that is, devices getting DHCP are likely to get DNS from that response; | 22:07 |
| rharper | if you've got static IPs, then dns away | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!