| === vrubiolo1 is now known as vrubiolo | ||
| === hggdh is now known as hggdh-msft | ||
| smoser1 | hey. if someone other than me wanted to look at | 14:01 |
|---|---|---|
| smoser1 | https://github.com/canonical/cloud-init/pull/413#pullrequestreview-425327276 | 14:01 |
| smoser1 | i'd appreciate it. i dont like giving people the runaround . if someone else is happy withthe existing PR then i'm fine too. | 14:02 |
| === smoser1 is now known as smoser | ||
| AnhVoMSFT | ugh I hate the github UI when posting comments - @Odd_Bloke I was trying to respond to your comment and somehow did cancel review by mistake and all my comments wiped | 14:38 |
| Odd_Bloke | AnhVoMSFT: UGH, bummer. | 14:41 |
| AnhVoMSFT | i posted my comment, happy to discuss further here if you would like | 14:44 |
| AnhVoMSFT | PR: https://github.com/canonical/cloud-init/pull/369 | 14:44 |
| AnhVoMSFT | @OddBloke What we have been seeing from some of our investigation into some of the latency issue during boot is slow DHCP response from DHCP server. The output of dhclient's stderr was the one that helped nailed it. In particular, we could see multiple DHCPREQUEST from dhclient (due to DHCP server being overloaded and not responded timely to the first DHCPREQUEST). In addition, we also | 14:44 |
| AnhVoMSFT | saw cases where DHCPOFFER was posted, but then DHCPACK arrived too late, which triggered dhclient to re-send DHCPREQUEST, etc... | 14:44 |
| AnhVoMSFT | So yes, even in the successful case, you could tell how many attempts it took for dhclient to actually negotiate the dhcp leases successfully. Ideally we would want to see a timestamp PER message of dhclient, but this is only available through journalctl (unless we stream the stderr pipe to cloud-init.log, which is going to be not trivial how the current code is setup) | 14:44 |
| AnhVoMSFT | I do agree we should log both success and failed path - I left a comment there about it as well. | 14:44 |
| smoser | Odd_Bloke: thanks for comment on #413 | 14:56 |
| smoser | we really ought to make subp return a named tuple | 14:57 |
| smoser | with exit_code, out, err | 14:57 |
| smoser | or otherwise at least return exit code. because if you pass rcs= then it gets lost | 14:57 |
| falcojr | do we have something like "lxc-proposed-snapshot" but lets you pass in an arbitrary deb? I'm wanting to run cloud init in a VM based off a particular commit | 16:47 |
| falcojr | s/VM/container | 16:50 |
| smoser | it feels like i've done that before... | 16:52 |
| smoser | for sure you can point it at a ppa and it wil do the right thing | 16:52 |
| smoser | slower for sure | 16:52 |
| smoser | falcojr: https://git.launchpad.net/ubuntu/+source/open-iscsi/tree/debian/tests/patch-image | 16:54 |
| smoser | thats where i've done it before... | 16:54 |
| smoser | you shoudl add that to patch-image (which lxc-proposed-snapshot calls). and then it'd be functional in either lxc-proposed-snapshot or get-proposed-cloudimg | 16:56 |
| smoser | sorry. above, s/patch-image/uipdate-root/ | 16:56 |
| falcojr | interesting, I'll have to play with that | 16:57 |
| falcojr | thanks | 16:57 |
| smoser | yeah.. so it looks like you'd have to add the "copy debs" stuff in lxc-propsoed-snapshot and get-proposed-cloudimg | 16:57 |
| smoser | and then add some '--install-debs' or '--install-debs-dir' to update-root | 16:57 |
| smoser | thanks for your work on cloud-init. from this point of view it looks like you're doing great. | 16:58 |
| pleusmann | HI. I am trying to use cloud-init with CentOS 7. I need to use it for network-config: I need to get the ip for an interface by DHCP, but I need to manually set the nameservers. | 18:38 |
| pleusmann | I added a network-config in /etc/cloud/cloud.cfg.d/ but it seems to get ignored. In the logfile I see it being written to the ifcfg-script but there are no nameservers set :( | 18:40 |
| pleusmann | Sorry, I cannot paste the exact config easily as I am on a vmware console. I used networks v2, with ethernets, dhcp: true and addresses for two nameservers | 18:42 |
| pleusmann | Is there anything I have to care about? | 18:44 |
| pleusmann | It would also be fine for me to not have managed network by cloud-init, but disable-networking also doesn't have a noticeable effect. | 18:44 |
| Odd_Bloke | rharper: Updated https://github.com/canonical/cloud-init/pull/391/ to address your comments _except_ for the pass to see if we can use any existing libraries instead of our own homegrown code, I'll do that now. | 19:00 |
| rharper | Odd_Bloke: ok, cool | 19:05 |
| rharper | pleusmann: can you share your v2 config you'd like to deploy with (or something similar) ? | 19:06 |
| pleusmann | Odd_Bloke: I have to share a screenshot: https://ibb.co/SXDpnSS | 19:09 |
| rharper | pleusmann: looking | 19:13 |
| rharper | good enough | 19:13 |
| lucasmoura | blackboxsw, I am working on the nic manual testing for ec2 instances and I fought that having at least 3 nic would make the test better. However, it seems that the t2.micro does not support more than 2 network interfaces | 19:13 |
| powersj | yaml and spaces... | 19:14 |
| lucasmoura | An error occurred (AttachmentLimitExceeded) when calling the AttachNetworkInterface operation: Interface count 3 exceeds the limit for t2.micro | 19:14 |
| lucasmoura | Should we choose another machine or testing with only 2 network interfaces is enough ? | 19:14 |
| powersj | lucasmoura, fwiw here are the limits: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html | 19:15 |
| powersj | rharper, does that yaml look valid? or should ens160 be one more space in? | 19:15 |
| rharper | powersj: I think it's valid; | 19:16 |
| blackboxsw | lucasmoura: for testing if you'd like to test 3 nics I think you can do t2.small for your test | 19:16 |
| lucasmoura | powersj, thanks for the info =) | 19:17 |
| lucasmoura | blackboxsw, ack | 19:17 |
| blackboxsw | and lucasmoura bringing up a bigger instance temporarily to validate specific tests is ok as far as costs, we just don't want to leave bigger instances running long | 19:18 |
| rharper | pleusmann: ah, that's right; since you have DHCP configured, cloud-init does not render DNS entries ;;; the expectation is that DNS info will be provided by DHCP response | 19:18 |
| pleusmann | rharper: It provides the wrong ones :( | 19:19 |
| rharper | can you use static ip instead ? | 19:19 |
| pleusmann | nope | 19:19 |
| rharper | ok, so netplan does allow for dhcp-overrides section , I don't think cloud-init net rendering checks for dhcp-overrides when rendering different outputs though; | 19:21 |
| rharper | you would want: to add a dhcp4-overrides: {'use-dns': 'false'} | 19:21 |
| rharper | but cloud-init isn't yet looking at dhcp overrides so that it would properly emit the dns entries that are being ignored | 19:22 |
| pleusmann | Ok, I understand I am on an edge case and hopefully will get that dhcp-server fixed. Nevertheless I guess the usecase is valid. Hope you can put it on the backlog | 19:23 |
| rharper | pleusmann: please do file a bug if you have time | 19:23 |
| pleusmann | rharper: Where is your bug database? | 19:28 |
| meena | pleusmann: in the topic | 19:30 |
| rharper | https://bugs.launchpad.net/cloud-init/+filebug | 19:30 |
| pleusmann | found it. thx | 19:32 |
| blackboxsw | lucasmoura: review on your chef schema for monday https://github.com/canonical/cloud-init/pull/375#pullrequestreview-425558648 | 19:37 |
| lucasmoura | blackboxsw, ack | 19:37 |
| * blackboxsw goes down the active review queue for cloud-init the rest of the day (checking SRU PRs too) | 19:37 | |
| lucasmoura | blackboxsw, is it xenial that we should check the network config on a different path than /etc/netplan/50-cloud-init.yaml ? | 19:58 |
| blackboxsw | falcojr: did you see that rharper already had a pr up for this https://trello.com/c/Jk4enIi0/43-09fea85fhttps-gitlaunchpadnet-cloud-init-commit-id09fea85f-1870421http-padlv-1870421-net-ignore-renderer-key-in-netplan-config-3 | 20:01 |
| blackboxsw | was that what you referred to in standup? | 20:01 |
| blackboxsw | I just landed PR https://github.com/cloud-init/ubuntu-sru/pull/100 | 20:02 |
| blackboxsw | which I think mapped to that test | 20:02 |
| falcojr | yeah, that's what I mentioned this morning | 20:03 |
| blackboxsw | lucasmoura: yes xenial should be /etc/network/interfaces.d/50-cloud-init.cfg | 20:03 |
| blackboxsw | falcojr: ok I'll put that rharper guy on that card and mark it done. | 20:03 |
| blackboxsw | :/ | 20:03 |
| blackboxsw | :) | 20:03 |
| rharper | blackboxsw: =) | 20:03 |
| rharper | I need to grab another one, but I can't see the board | 20:03 |
| blackboxsw | rharper: yeah I mentioned that in standup, we might want to open up that board and make it public given that we have an amazing cloud-init community helping with SRUs ;) | 20:04 |
| rharper | blackboxsw: hehe | 20:04 |
| blackboxsw | not sure how to go about that at the moment. | 20:04 |
| rharper | yeah, no worries about the board; if you tag me in here with the bug, I can work through a few at a time | 20:05 |
| blackboxsw | will take it up w/ rick_h and team on Monday to see what folks think. in the meantime, some that look good for rharper: | 20:08 |
| blackboxsw | sru verification requests: https://git.launchpad.net/cloud-init/commit/?id=46cf23c2 and https://git.launchpad.net/cloud-init/commit/?id=723e2bc1 | 20:09 |
| blackboxsw | figured storagey would be good ? | 20:09 |
| rharper | ack | 20:10 |
| pleusmann | rharper: https://bugs.launchpad.net/cloud-init/+bug/1882300 | 20:11 |
| ubot5 | Ubuntu bug 1882300 in cloud-init "not possible to override dns servers when using dhcp" [Undecided,New] | 20:11 |
| rharper | pleusmann: cool, thanks | 20:12 |
| pleusmann | will cloud.cfg somehow be rewritten on first boot after installation of cloud-init? I added disable-network-config directives to the end of the file, but they are gone after first boot. on subsequent boot they seem to persist | 20:27 |
| pleusmann | "network-config=disabled" kernel parameter doesn't seems to be respected, BTW | 20:28 |
| rharper | pleusmann: cloud.cfg files are not removed/overwritten; it's a permanent config; | 20:34 |
| rharper | pleusmann: typically, network-config is provided by platforms on a per-instance basis; so on OpenStack or Ec2 or Azure, cloud-init queries the metadata service for a network-config that describes the config for this instance | 20:34 |
| rharper | more static datasources, like NoCloud or ConfigDrive, include a network-config in their meta-data; but statically; it has to be available locally (as a file, part of the datasource attached to the instance) | 20:35 |
| rharper | pleusmann: there was a recent bug w.r.t the kernel cmdline disable, you have to base64 encode it on older versions of cloud-init (not sure what you're running right now) | 20:36 |
| rharper | if you're on centos7, you might try out our daily rpm builds to see if things are working better there, https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ | 20:36 |
| pleusmann | I am preparing a vsphere template. later they a running "nocloud", but I experience this behavior when running the initial container. no non-local datasources attached | 20:37 |
| rharper | well, nothing in cloud-init itself deletes files in /etc | 20:37 |
| rharper | so not sure what you're seeing | 20:37 |
| rharper | https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1862702 | 20:38 |
| ubot5 | Ubuntu bug 1862702 in cloud-init (Ubuntu) "cannot disable cloud-init networking despite trying hard" [Medium,Fix released] | 20:38 |
| pleusmann | rharper: Do I get it right, that "network-config=disabled" only works in quite recent builds, but base64-encoding the yaml-equivalent works in older releases? | 20:42 |
| rharper | pleusmann: for kernel command line, yes | 20:43 |
| pleusmann | Ok. Thanks. Probably I'll just get that damn DHCP-Server fixed ;) | 20:44 |
| pleusmann | Thanks for your help, anyway | 20:44 |
| lucasmoura | blackboxsw, should we terminate the instance after performing the test ? Currently, the ec2-sru template does not do that, but is there is a reason for not terminating ? | 20:45 |
| falcojr | blackboxsw: where did you get those issues you just gave to rharper ? | 20:46 |
| falcojr | I'm not seeing them on our board and I thought our board had everything we had accounted for after being scrubbed | 20:46 |
| blackboxsw | falcojr: I grabbed them from https://github.com/cloud-init/ubuntu-sru/pull/100https://trello.com/c/Jk4enIi0/43-09fea85fhttps-gitlaunchpadnet-cloud-init-commit-id09fea85f-1870421http-padlv-1870421-net-ignore-renderer-key-in-netplan-config-3 and I put rharper's head on them, but I was going to chat with you lucasmoura and Odd_Bloke to see if we want to keep spinning out separate cards for each item in that | 20:49 |
| blackboxsw | verification list or just assign each item from that verification checklist and "check" the checkbox once a PR lands related to it? | 20:49 |
| blackboxsw | falcojr: Odd_Bloke lucasmoura what would you prefer, ejecting each item to separate cards in the SRU Verification lane, or separate cards we can mark as closed | 20:51 |
| blackboxsw | sorry my cut-n-paste leaves a lot to be desired: if you open up the card https://trello.com/c/g8Wf4n6c/9-create-trello-cards-for-each-commit-that-could-represent-a-functional-change-to-ubuntu you can see rharper's avatar on 2 checklist items | 20:52 |
| falcojr | yeah, I just found the card cause that was a fun link :D | 20:53 |
| blackboxsw | do you prefer this approach to allocating ownership, or "convert to card" to kick that item out of the list | 20:53 |
| blackboxsw | I want to cut down on pointy clicky work related to this, so whatever's easier. And we'll talk post SRU with rick about the biggest pain points with this SRU (as it's a big one) to see how we can make this process easier/simpler | 20:54 |
| falcojr | since we can put our heads on checklists, I'm fine with just the checklist, but don't have strong opinions either way | 20:54 |
| Odd_Bloke | I'm happy to follow what you folks decide. | 20:54 |
| lucasmoura | I am fine with the checklist as well | 20:54 |
| blackboxsw | yeah the heads on checklists is a newer trello feature. ok let's do that, and when the PR is merged, we'll just tick the checklist item | 20:54 |
| blackboxsw | then the lane stays smaller | 20:55 |
| * falcojr thumbs up | 20:55 | |
| blackboxsw | and we have less copying | 20:55 |
| blackboxsw | thx | 20:55 |
| falcojr | and you pruned this list already, correct? | 20:55 |
| falcojr | geez, I thought we were almost done with the manual tasks | 20:55 |
| rharper | two paths, manual platform tests, and then *per bug fix* verification | 20:56 |
| rharper | the latter is the long pole since the previous SRU was a while back | 20:57 |
| blackboxsw | lucasmoura: review on https://github.com/cloud-init/ubuntu-sru/pull/99/files#diff-92de51f24fc6c44bb6d06af7734d8e34R34-R45 for monday | 21:08 |
| blackboxsw | falcojr: I did, but you have plenty of room to question whether something sounds like it may not need a verification test. | 21:08 |
| blackboxsw | I'm thinking we can punt anything that generally should be execised by typical cloud-init successfully completing without WARNING/traceback in normal boot logs. | 21:09 |
| blackboxsw | falcojr: as soon as I'm through SRU reviews I'll re-prune that list from top to bottom to see if I can eject any more from our SRU process | 21:10 |
| blackboxsw | falcojr: lucasmoura biggest/most critcal for SRU verification are the big cloud manual verification test runs | 21:11 |
| blackboxsw | above and beyond the individual verification | 21:11 |
| blackboxsw | because failure to succeed on cloud boot/upgrade/verification affect all VMs not just ancillary features (and would result in us blocking the current SRU and respinning the upload with a fix) | 21:12 |
| blackboxsw | Whereas, with these individual feature verifications, if we find a bug in the feature during SRU validation, we have been known to categorize that as something which doesn't have to block the SRU and we can work it after the SRU is completes. | 21:15 |
| blackboxsw | also I'm going to start grabbing items from this queue today too. | 21:23 |
| blackboxsw | falcojr: minor change request for https://github.com/cloud-init/ubuntu-sru/pull/101#pullrequestreview-425635894 | 21:29 |
| blackboxsw | just to link all extra verification work to that SRU top-level readme | 21:29 |
| blackboxsw | and we'll land it | 21:29 |
| blackboxsw | lucasmoura: were you working on [70dbccbb](https://git.launchpad.net/cloud-init/commit/?id=70dbccbb) [#1876312](http://pad.lv/#1876312) DataSourceEc2: use metadata's NIC ordering to determine route-metrics (#342) ? | 21:30 |
| blackboxsw | or something slightly different | 21:30 |
| lucasmoura | I am, but not on the individual SRU test | 21:30 |
| lucasmoura | both on the ec2 instance directly | 21:31 |
| lucasmoura | using the ec2-sru template for testing it | 21:32 |
| blackboxsw | sorry I don't follow? | 21:32 |
| blackboxsw | ahh you are doing that as part of extending the ec2 manual cloud test template? | 21:32 |
| lucasmoura | yes | 21:32 |
| blackboxsw | ok then, I'll take my face off that card, since it sounds like you are going to tackle part of that in the manual Ec2 test. | 21:33 |
| blackboxsw | and I'll grab a different item | 21:33 |
| lucasmoura | Okay | 21:33 |
| === Odd_Bloke changed the topic of #cloud-init to: Migration to travis-ci.com in progress, PR merges blocked until Monday | pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 16 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug | ||
| Odd_Bloke | powersj: If you're around, you might have the permissions on the repo to change the status check which blocks PRs from the old Travis CI one to the new Travis CI one; that would fix the issue I just updated the topic with. | 22:06 |
| powersj | Odd_Bloke, any idea where I would go to do that? | 22:07 |
| powersj | I see a webhook for travis-ci.org | 22:07 |
| smoser | https://github.com/canonical/cloud-init/pull/416 | 22:18 |
| smoser | it passes tox -e py3 | 22:18 |
| smoser | but dont know more than that at the moment. | 22:18 |
| blackboxsw | holy moly. smoser going for karma :) | 22:20 |
| === hggdh-msft is now known as hggdh | ||
| blackboxsw | falcojr: landed https://github.com/cloud-init/ubuntu-sru/pull/101 thx | 23:05 |
| powersj | Odd_Bloke, I changed the status check, but I see 2x Travis CI builds on my PR | 23:21 |
| powersj | Odd_Bloke, actually this looks right now: https://github.com/canonical/cloud-init/pull/418 so we'll need to re-check old merge requests | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!