| niluje | smoser: do you think my updates are okay? | 09:01 |
|---|---|---|
| Wulf | Hi, is there any way to rename network interface in ubuntu 16.04 on AWS back to eth0? | 10:30 |
| ragechin | Wulf: cloud-init 0.7.9? | 13:04 |
| ragechin | Wulf: PM me plz. I don't think it's a cloud-init issue | 13:04 |
| smoser | niluje, i'll take a look now. i'm sorry. | 15:11 |
| niluje | sorry to be oppressive :x | 15:12 |
| smoser | niluje, no worries. | 15:14 |
| smoser | blackboxsw, can you confirm that | 15:14 |
| smoser | 4d9f24f5c385cb7fa21d87a097ccd9a297613a75 | 15:14 |
| smoser | is broken in the same way as | 15:14 |
| smoser | https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/327325 | 15:14 |
| smoser | was ? that path is just plain wrong? | 15:14 |
| smoser | Wulf, https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | 15:15 |
| smoser | see | 15:15 |
| smoser | I don't like this, how do I disable this? | 15:15 |
| smoser | niluje, you kind of have 3 unit tests in one | 15:18 |
| blackboxsw | smoser: checking | 15:18 |
| niluje | smoser: I can split them, but usually I prefer to test a feature in a single test rather than split it into smaller tests | 15:19 |
| smoser | well, but you're really testing 3 different things. | 15:21 |
| niluje | because split means having more tests, which take more time to run, and 99.9% of the time it doesn't make sense to test only a function when it works (for instance) and not when it fails | 15:21 |
| smoser | a.) valid API / expected working case. | 15:21 |
| smoser | b.) no user-data and vendor-data | 15:21 |
| smoser | c.) local port retry | 15:21 |
| smoser | blackboxsw, i'd also like your opninon on the use of HTTPConnection (via requests.packages.urllib3.connection) in niluje's MP | 15:22 |
| smoser | https://code.launchpad.net/%7Ejcastets/cloud-init/+git/cloud-init/+merge/325740/+index | 15:22 |
| niluje | smoser: so you want me to split the unittests then? | 15:22 |
| niluje | (won't do before monday) | 15:22 |
| smoser | blackboxsw, . your thoughts on ^ too ? i think generally we do want them to be more granular | 15:23 |
| larsks | smoser: possible 0.7.6 to 0.7.9 regression when using a config drive with a static network config; curious about your opinion: if after initial boot a config drive goes away, it looks like 0.7.6 will retain the network config while 0.7.9 will panic and replace the static network config with a dhcp config from the fallback data source. | 15:24 |
| smoser | larsks, the config drive metadata service's check_instance_id() should end up saying that the cached object in /var/lib/cloud/instance/obj.pkl is still valid. | 15:27 |
| niluje | │ logan- | 15:27 |
| niluje | oops | 15:27 |
| larsks | smoser: Looks like not, but I will check. It looks like with 0.7.6, cloud-init.service simply fails when there is no data source, so -config and -final never run. | 15:28 |
| larsks | Let me take a closer look at my 0.7.9 setup. | 15:28 |
| smoser | larsks, is this opssibly related to ovirt ? | 15:28 |
| smoser | or is it really openstack | 15:28 |
| larsks | Not openstack. Right now, I'm testing locally with libvirt + config drive. | 15:29 |
| smoser | (ovirt uses config drive, and i think doesn't set the dmi data to the instance id, which woudl make that fail) | 15:29 |
| larsks | But I think the original problem is in RHEV, which I think means ovirt. | 15:29 |
| niluje | i think generally we do want them to be more granular -> again I'll follow your recommendations, but for my personal projects I really feel being granular is cleaner, but it's often a pain to do (you need to do the test setup more than once) and doesn't actually help to test the code better | 15:29 |
| niluje | but let me know :) | 15:29 |
| blackboxsw | niluje: smoser yes please on the separation/simplification of unit tests to simply assert 1 or 2 things instead of compound set of assertions. We want each unit test to be representative of a single "thing" that it is testing, which makes for easier error tracking/resolution when the test fails in the future | 15:29 |
| smoser | right. i think that is quite likely broken, but i'm not really sure how it would work previously. | 15:30 |
| niluje | okay | 15:30 |
| smoser | larsks, and i'm not sure how to make it work. | 15:30 |
| niluje | blackboxsw: will do, thanks :) | 15:30 |
| blackboxsw | I think we (cloud-init) should pull together a doc on unit test writing just to capture general intent/approach/style etc. | 15:30 |
| smoser | hm.. | 15:30 |
| blackboxsw | thanks niluje, sorry if it feels a bit pedantic | 15:30 |
| larsks | smoser: the bahvior in 0.7.6 seems fine (fail if no data source). Why does 0.7.9 try to continue in that case? Is there a way to disable the fallback datasource? | 15:31 |
| blackboxsw | probably need a little addendum to the HACKING doc on cloudinit.readthedocs.io | 15:31 |
| larsks | If not, should there be an option to do that? | 15:31 |
| smoser | this path where it correctly identifies its the same instance id will only work on intel (as it uses dmi data, and although arm64 in theory could do dmi practice and kvm are different) | 15:31 |
| niluje | if there's something else I'll fix it on monday morning, hoping we can merge the MR soon :) | 15:31 |
| blackboxsw | +1 niluje I'll put some eyes on the branch too today to see if I can make more concise comments | 15:32 |
| smoser | larsks, it re-writes netowrk data on 0.7.9 as it doesn't know that it is not a new instance, so it goes the path of "do a dhcp on eth0 so the network datasources can find network metadata" | 15:32 |
| niluje | blackboxsw: if you are interested in having a node to do some testing, I can give you access to one | 15:33 |
| niluje | smoser: same | 15:33 |
| larsks | Right, I understand that. But is there any way to disable that behavior if so desired? | 15:33 |
| larsks | The problem is not just that it does a dhcp, but that it is actually writing a new network configuration to disk. | 15:33 |
| smoser | larsks, right. but at the point where there is no config drive it can only really think that this is a new instance, or it has been snapshotted and moved to another cloud.... | 15:38 |
| smoser | its looking for a metadata source. | 15:38 |
| larsks | No, I get that. I am just arguing that it shouldn't be writing configs if ultimately it doesn't find a valid datasource. | 15:39 |
| larsks | But I understand what you're saying. I am trying to figure out if this whole "config drive goes away" thing is standard RHEV behavior... | 15:40 |
| larsks | ...because if it's not, "don't do that" seems like the quickest fix. | 15:40 |
| smoser | you can configure "manual_cache_clean" to true | 15:40 |
| smoser | yeah.. | 15:40 |
| smoser | larsks, so right now blackboxsw is working on moving the ec2 datasource to run at "local" time. | 15:41 |
| smoser | if we replaced all network-time datasources to run at local, then we could essentially decide failure at the local time frame. | 15:42 |
| smoser | and leave the networking in place | 15:42 |
| smoser | the path would still result in cloud-init considering that a failure though | 15:42 |
| smoser | as it would not have found a datasource (as there is none, and the previous one is not found to be valid) | 15:42 |
| larsks | smoser: I wish that there was a shorter term fix when no network datasources are enabled (e.g., when datasource_list is [ConfigDrive, NoCloud]). | 15:45 |
| smoser | larsks, well, 2 fixes to the platform | 15:52 |
| smoser | a.) match the dmi data to the instance id | 15:52 |
| smoser | b.) do not detach the drive ever | 15:52 |
| smoser | both of these things qualify as "act more like the platform that you're imitating" | 15:53 |
| smoser | larsks, i do agree it sucks. several months ago someone had pointed this out to me, and that was when i asked you what you knew of ovirt | 15:54 |
| smoser | i considered raising an issue there. | 15:54 |
| smoser | just kind of ran out of time/motivation | 15:54 |
| smoser | :-( | 15:54 |
| smoser | larsks, if there is other unice id in dmi information on that platform, we could adjust the check_instance_id() to have stored that bit too and ccompare that it is not new | 15:56 |
| larsks | smoser: which dmi field are we checking? | 15:57 |
| smoser | and another option that might make sense would be to allow vendor_data to declare manual_cache_clean | 15:58 |
| smoser | if the cached obj.plk had manual_cache_clean=True, then we could trust it | 15:58 |
| smoser | (rather than requiring that to come from system config) | 15:58 |
| smoser | the field looked at is system-uuid | 15:58 |
| smoser | i do recall that they had a unique id somewhere in their dmi data | 15:59 |
| larsks | Thanks. Let me look into that a bit. | 16:00 |
| blackboxsw | smoser: that 4d9f24f5c385cb7fa21d87a097ccd9a297613a75 is a completely different failure on my end than what was fixes in my gce mock branch. I'm seeing a magic number traceback in 4d9f24f5c385cb7fa21d87a097ccd9a297613a75. Will peek at that (as well as getting my gce-mock-fix branch pushed) | 16:02 |
| blackboxsw | hmm PEBKAC. issue was on my side with a stale pyc file. checking now. | 16:03 |
| smoser | :) | 16:09 |
| blackboxsw | smoser: same failure mode which the branch I have fixes. | 16:09 |
| smoser | you see failure ? | 16:10 |
| smoser | because i do not | 16:10 |
| smoser | (and neither does c-i) | 16:10 |
| blackboxsw | smoser: not a failure, I add a pdb here | 16:10 |
| blackboxsw | https://www.irccloud.com/pastebin/pP1aE6ZT/ | 16:10 |
| blackboxsw | .tox/py3/bin/python3 -m nose --tests tests/unittests/test_datasource/test_gce.py:TestDataSourceGCE.test_get_data_returns_false_if_not_on_gce -x -s | 16:10 |
| blackboxsw | and this tox line gets to that pdb which it shouldn't | 16:10 |
| blackboxsw | because platform_reports_gce should be mocked to return False in that case | 16:11 |
| smoser | (fwiw, i dont think its valid to call python3 like that... you wont get the virtualenv installed things) | 16:11 |
| smoser | (that is what ./tools/tox-venv does. ./tools/tox-venv py3 python3 -m nose --tests ...) | 16:12 |
| blackboxsw | smoser: here too :) tox -e py3 -- --tests tests/unittests/test_datasource/test_gce.py:TestDataSourceGCE.test_get_data_returns_false_if_not_on_gce -s | 16:13 |
| smoser | (and you can run that way by just tox -e py3 tests/unittests/test_datasource/test_gce.py:TestDataSourceGCE.test_get_data_returns_false_if_not_on_gce) | 16:14 |
| smoser | but ok. let me look. | 16:14 |
| blackboxsw | ahhh good good, I was getting tired of all the extra typing on those -- | 16:14 |
| smoser | but tox-venv is faster | 16:15 |
| smoser | as it doesn't do the setup.py | 16:15 |
| blackboxsw | smoser: today I'm testing dhclient in init-local for aws with centos | 16:23 |
| blackboxsw | then freebsd (so I'm adapting that WIP branch and starting to make it actually work properly) | 16:24 |
| blackboxsw | niluje: forgot to respond earlier about your offer to setup access to a test system for us. I think that is a good offer, we are trying to increase our test matrix coverage and this may assist in upcoming SRUs. While I don't think we have the bandwidth to integrate testing w/ your system, if it doesn't cost anything to allow us to access it. It would certainly assist us as we get a chance to login and validate | 16:51 |
| blackboxsw | upcoming cloud-init changes. | 16:51 |
| blackboxsw | let me try typing that with proper grammar and punctuation. niluje: If you can setup system access for us and it doesn't cost anything it might help us in the future when we look at expanding out test matrix. | 16:53 |
| smoser | niluje, i do have a scaleway account | 17:01 |
| smoser | registered under smoser@brickies.net | 17:02 |
| smoser | blackboxsw, | 17:03 |
| smoser | https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/bug/fix-gce-test | 17:03 |
| smoser | that fixes the openstack metadata service to patch / use-mock correctly | 17:03 |
| blackboxsw | smoser: correct and it's merged | 17:09 |
| blackboxsw | oops | 17:09 |
| blackboxsw | jussec | 17:09 |
| blackboxsw | hrm smoser I landed that branch you approved in master a few mins ago | 17:10 |
| blackboxsw | and your change is a rewrite. ok, checking it out now | 17:10 |
| blackboxsw | smoser: ahh I see what you did to fix it. right the start method returns the actual mocked object so subsequent changes to return_value get honored | 17:14 |
| blackboxsw | smoser: +1 on that change to avoid the additional decorators | 17:14 |
| blackboxsw | you'll have a minor conflict w/ master I presume | 17:15 |
| blackboxsw | as I landed that other fix | 17:15 |
| smoser | blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327388 | 19:01 |
| smoser | you want to review that quick ? | 19:01 |
| smoser | and ack and then i'll pul it | 19:02 |
| blackboxsw | reading it smoser | 19:03 |
| blackboxsw | smoser: approved https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327388 | 19:10 |
| smoser | blackboxsw, thanks | 19:17 |
| smoser | blackboxsw, | 19:48 |
| smoser | =False) | 19:48 |
| smoser | smoser@milhouse:/home/smoser-public/src/cloud-init/cloud-init$ tox-venv py3 python3 -m nose tests/unittests/test_runs/test_simple_run.py tests/unittests/test_distros/test_create_users.py | 19:48 |
| smoser | that works. | 19:48 |
| smoser | but dropping the test_simple_run before test_create_users will fail | 19:49 |
| smoser | ie, its leaving some mocks or something in place making test_create_users not fail | 19:49 |
| smoser | powersj, that is the only other non-jsonpatch failure in py36 | 19:54 |
| smoser | ie, it should be a failure in 3.5 but it was just hidden | 19:54 |
| powersj | yeah | 19:56 |
| powersj | test_create_users | 19:56 |
| powersj | smoser: working on kvm backend for testing. I am trying to generate SSH keys on the image, which works, but then run into ssh_deletekeys, which deletes those keys. Have a best practice for doing this? | 20:00 |
| powersj | should I generate and inject the key we want to use by hijacking the user_data/cloud-config and put the key in that way? | 20:00 |
| smoser | so we can ssh into the system and know the keys, right? | 20:04 |
| smoser | its kind of invasive and system ddpendent | 20:09 |
| smoser | but maybe | 20:09 |
| smoser | https://gist.github.com/smoser/b32bb1c33564d1d46971cd9ded2e8477 | 20:10 |
| smoser | we run our own ssh on port 9999 that reads its own keys and such | 20:10 |
| powersj | smoser: hmm I was hoping to stick to port 22, so that when we extend to this to cloud providers I don't have to deal with firewall related issues | 20:17 |
| smoser | powersj, well, that means that you can't really test any of the system ssh | 20:50 |
| powersj | :\ | 20:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!