| blackboxsw | tribaal: for tomorrow, can you add some background on the need for the set-passwords override in the merge proposal https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371823 . I wasn't sure if there was a limitation in the platform that disallowed changing the instance-id in your metadata after a console operation to update passwords | 02:46 |
|---|---|---|
| === cpaelzer_ is now known as cpaelzer | ||
| tribaal | hi blackboxsw - so regardig your question (I'll discuss it here and then add a comment on the PR): | 15:24 |
| tribaal | indeed, we currently only set an instance-id per, well, instance. That is - each time a user decides "give me a new VM", our code sets this VM's id as instance-id. While it would be possible to change the instance id between an instance creation and its end of life, it feels weird to me - the user password is not a defining characteristic of the instance, I don't think resetting the password should | 15:26 |
| tribaal | regenerate an instance id | 15:26 |
| tribaal | however, resetting the user password (whatever the appropriate user is for that particular os - ubuntu, root, etc...) is a feature we offer our users and so would like to keep. The current flow is something like "press this button in the UI and we regenerate a password for you, then you reboot your instance and voila, new password" | 15:28 |
| tribaal | but this requires the cloud-init module to be run "always" unless I'm mistaken. It's the same instance - but the password might have changed. | 15:29 |
| tribaal | resetting the instance id would trigger other modules to re-run as well when resetting the password - for instance, I guess per-instance runs of cloud-config's "runcmd" would run again if we changed the instance id? | 15:30 |
| blackboxsw | sounds good tribaal we were talking about this in standup at the same time as your ping here | 15:33 |
| tribaal | ah :) | 15:33 |
| tribaal | blackboxsw: if you want to hop in a call I can do a live demo of the feature, if that would help | 15:33 |
| blackboxsw | sure tribaal. join if you'd like https://meet.google.com/bxm-azib-mtj | 15:49 |
| blackboxsw | your ears are probably burning :) | 15:50 |
| blackboxsw | as we are talking about you | 15:50 |
| tribaal | haha | 15:50 |
| blackboxsw | tribaal: I have a fix, but I'm still working on unit test fixe s | 16:54 |
| blackboxsw | will unfortunately be > 1 hr as I have an errand | 16:54 |
| blackboxsw | pushing what I have if you want to look | 16:55 |
| blackboxsw | deb won't build because of unit test failure | 16:55 |
| tribaal | blackboxsw: ack | 17:30 |
| tribaal | blackboxsw: rharper: the only thing I thought about in between is that the semaphore-nuking approach will be a little be strange from a logs perspective - the logs will show something along the lines of "set-passwords ran with frequency once-per-instance" yet it will run more than once per instance. | 17:32 |
| rharper | tribaal: yes | 17:32 |
| rharper | I think if we also log in the datasource what we're doing it's explainable | 17:32 |
| tribaal | yes, that is probably enough | 17:33 |
| blackboxsw | <- back | 18:20 |
| blackboxsw | working on the unittest fixup now | 18:20 |
| blackboxsw | and adding a log message about set-password frequency override | 18:21 |
| blackboxsw | tribaal: rharper just force pushed the exoscale branch | 18:51 |
| blackboxsw | unit tests fixed | 18:51 |
| blackboxsw | testing now on my exoscale branch | 18:51 |
| blackboxsw | s/branch/vm | 18:52 |
| blackboxsw | bah get_ipath not available at that spot in the datasource. fixing | 18:58 |
| tribaal | blackboxsw: thanks - I kicked off a test, but unfortunately it hit a bump in the road (nothing tragic as far as I can see though) | 19:52 |
| tribaal | blackboxsw: I imported your keys in "ssh ubuntu@159.100.241.241" if you want to poke around (similar setup as the prvious machine - an Eoan snapshot on our preprod infra) | 19:53 |
| blackboxsw | thanks tribaal | 19:59 |
| blackboxsw | tribaal: that's stale :/ | 20:00 |
| blackboxsw | ahh tribaal I forgot to push my fix will have that up in about ~20 | 20:00 |
| blackboxsw | tribaal: I fixed for your tomorrow. testing again now on a live instance | 20:21 |
| blackboxsw | rharper: tribaal I just tested current 576531c33b7c5bf215b5bc59dbff84eb9feaf981 of https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371823 with success | 20:36 |
| * blackboxsw runs to an errand | 20:37 | |
| rharper | blackboxsw: thanks, I'll review | 20:42 |
| * tribaal tries again | 21:13 | |
| blackboxsw | rharper: per using sem_path = self.paths.get_ipath_cur('sem') that was coming up None on Exoscale datasource, in my earlier pass on this, the datasource wasn't attached to self.paths for some reason | 21:37 |
| rharper | it should be it's in the base class | 21:37 |
| rharper | right ? | 21:37 |
| blackboxsw | ahh wait I was using get_ipath() not get_ipath_cur. will try it now | 21:37 |
| rharper | yes | 21:37 |
| rharper | I saw the same thing with get_ipath vs cur | 21:37 |
| rharper | smells like a bug, but I've not studied the Paths() object enough to know why | 21:38 |
| blackboxsw | thanks rharper. I'll make a note to file a bug about that behavior. Ok I can flip back to my previous unittests then which make use of get_ipath_cur then. | 21:40 |
| rharper | cool | 21:41 |
| blackboxsw | and I owe you a review | 21:41 |
| blackboxsw | rharper: I reworked https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371823 | 21:55 |
| blackboxsw | taking your suggestions thanks | 21:55 |
| blackboxsw | pushing it now. and testing live | 21:55 |
| * blackboxsw is reviewing https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/371906 now | 21:59 | |
| rharper | blackboxsw: ok | 22:00 |
| blackboxsw | tribaal: validated latest on the vm you gave me. I've shut down that vm now so I have no more access. | 22:06 |
| blackboxsw | rharper: per secondary vnic v1 or v2, why are we emitting netmask and gateway in v1, but not providing either a /<prefix> in addresses or routes? | 22:12 |
| blackboxsw | rharper: also a followup unrelated question, would you expect that the global DNS defined in this sample should show up as sysconfig rendered config for eth0 as DNS1=172.19.0.12 https://paste.ubuntu.com/p/ZMVk5mNGNm/ | 22:25 |
| blackboxsw | that question is part of the openstack v2 network config outstanding unit test failures I have. I'm reflecting global DNS service entries onto every device that doesn't have dhcp or it's own DNS defined | 22:26 |
| blackboxsw | .tox/py3/bin/nosetests tests/unittests/test_net.py on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/feature/openstack-network-v2-multi-nic | 22:28 |
| blackboxsw | ahh so rharper v2 is lossy w.r.t. 'global dns'. Since v2 defines top top-level dns service values, (and we reflect dns values to each interface) sysconfig renderer doesn't know if it needs to setup /etc/resolv.conf | 23:09 |
| blackboxsw | *Since network v2 defines *no* top-level dns service values* | 23:10 |
| blackboxsw | I wonder if we need sysconfig renderer to be 'smarter' and check v2 config to see if nameservers config on each interface is the same and if identical, reflect that dns information up to top-level /etc/resolv.conf | 23:11 |
| blackboxsw | or if not sysconfig renderer, maybe network_state needs to be smarted about it's dns_nameservers property | 23:11 |
| blackboxsw | smarter rather | 23:12 |
| rharper | blackboxsw: re: global dns, it's only interfaces that _have_ an IP, but not dns (and we skip subnets with dhcp) | 23:39 |
| rharper | blackboxsw: so the goal with a global dns is to just ensure that it shows up on any interface that won't already get dns from somewhere else (like dhcp) | 23:41 |
| rharper | blackboxsw: so, yes, in your paste, I would expect a DNS entry in ifcfg-eth0 | 23:41 |
| rharper | b2 does not define top-level dns, rather it's per interface under the type: so ethernets: eth0: {nameservers: [], search: []}, eth1: {nameservers: [], search: []}, vlans: eth0.23: {nameservers: [], search: []}}} | 23:42 |
| rharper | s/b2/v2 | 23:42 |
| blackboxsw | rharper: only that it is a slight difference in behavior now, instead of emitting an /etc/resolv.conf, we now append DNS1 on each etc/sysconfig/network-scripts/ifcfg-eth0 | 23:43 |
| rharper | which will end up in resolv.conf | 23:43 |
| rharper | per distro networking | 23:43 |
| rharper | otherwise, what's the point of DNS value in sysconfig ? | 23:43 |
| blackboxsw | ahh right: dunno if we need to shore up that difference and have network_state.dns_servers track nameservers under each v1 'ethernets' object | 23:44 |
| blackboxsw | good pt | 23:44 |
| rharper | hrm, so looking at sysconfig | 23:44 |
| rharper | we pick up dns_nameservers from the network_state iface subnet config | 23:44 |
| rharper | that really shoud end up in resolv.conf | 23:45 |
| rharper | blackboxsw: can you paste out a dump of your network_state dict after openstack -> v2 -> network_state ? | 23:46 |
| rharper | I think we print the object in the unittest in a few places | 23:46 |
| rharper | and do you have a branch up that I can see your converter ? | 23:46 |
| rharper | blackboxsw: if we wanted to stay the same, then I think in network_state parsing v2, as we read in per-interface dns data, we could also append to the network_state.dns_nameservers (if the value isn't already present); | 23:49 |
| blackboxsw | rharper: that last statement is what I was questioning. we could do something just like that to retain top-level DNS references, though if we had distinct DNS-per interface, just leave it hanging under the interface | 23:51 |
| rharper | blackboxsw: some quick experiements in centos7, shows that nameserver values already in /etc/resolv.conf get overriden by DNS values from ifcfg files | 23:55 |
| rharper | so I really think that per-interface DNS really is the right way since global isn't really a thing | 23:56 |
| blackboxsw | rharper: so we could promote common dns values up to top-level via network_state.dns_servers settings. and allow unique dns to continue to live on the interface | 23:56 |
| blackboxsw | rharper: that works. I can leave it per interface then | 23:56 |
| rharper | blackboxsw: so, the only case I can think of that we should verify is that if we have a global dns in the source config, ala openstack, but no interface to put it on | 23:56 |
| blackboxsw | rharper: we'll have global dns in network_data.json :/ | 23:56 |
| rharper | no, I mean ,no where to put it | 23:57 |
| rharper | network_data.json either gives us a static ip | 23:57 |
| rharper | or they dhcp | 23:57 |
| blackboxsw | hrm right. | 23:57 |
| rharper | so we always have a place to put the dns value | 23:57 |
| rharper | it's not really *global* | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!