| stl_ | Hi all, does anyone know why cloud-init in Ubuntu 16 makes static network interface configuration instead of dhcp like in Ubuntu 14? Thanks | 11:35 |
|---|---|---|
| stl_ | Hi all, does anyone know why cloud-init in Ubuntu 16 makes static network interface configuration instead of dhcp like in Ubuntu 14? Thanks | 12:48 |
| telling | I have both package_update and package_upgrade set to true in my cloud-config, now I expect it to update before it upgrades. But thats not the behaviour i'm seeing..Is this right? | 12:49 |
| smoser | stl_, in 16.04, it will render network configuration that came from the cloud provider | 13:06 |
| smoser | in 14.04, most likely you just got "dhcp on the first network device". | 13:06 |
| smoser | telling, package_upgrade implies package_update at least on ubuntu. can you share a config and where you're running this ? | 13:07 |
| smoser | also /var/log/cloud-init.log would be useful if you can paste that. | 13:07 |
| smoser | powersj, sorry, responding to your last night comment. | 13:08 |
| smoser | tox in my mind is somewhat broken for c-i due to lxd having c (and just the pain in building that way) | 13:08 |
| smoser | wrt simplestreams, we can i think fix that. i have to check. | 13:09 |
| stl_ | @smoser yes, that's correct. I figure it out from interfaces.d/50-cloud-init.cfg that whole configuration is created. I would like to have it like in Ubuntu 14 -> dhcp on interfaces. I have tried to specify dhcp for network interfaces (version 1 and also version 2) http://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration-sources | 13:18 |
| stl_ | @smoser i have upstream ubuntu images. Running OpenStack Ocata in our company | 13:19 |
| stl_ | smoser: and my main problem with cloud-init in Ubuntu 16 is that I have two interfaces (two diferent subnet) and I am getting two default routes configured ny cloud-init. With dhcp OS will install only one default route (that's correct) | 13:24 |
| smoser | well, its impossible to install 2 default routes. | 13:33 |
| smoser | so in 14.04, cloud-init woudl pick a interface via the hard coded name 'eth0' | 13:33 |
| smoser | actually, cloud-init didn't do that. | 13:33 |
| smoser | your image had to already be configured to do that. cloud-init didn't do any networking. | 13:33 |
| smoser | so cloud-init in 14.04 completely ignored any information your provider gave it. | 13:34 |
| smoser | in 16.04, it listens to the provider's desired network configuration and tries to apply it. | 13:34 |
| smoser | it is able to do that on OpenStack with ConfigDrive | 13:34 |
| smoser | it will fall back to "dhcp on eth0" like behavior on OpenStack if there is no config drive. | 13:35 |
| smoser | so, lets try to identify the problem with the routes | 13:35 |
| smoser | then we can fix that and cloud-init will be working for you again (i think) in 16.04 | 13:35 |
| smoser | that make sense ? | 13:36 |
| stl_ | i will share ip r and 50-cloud-init.cfg in a few minutes. | 13:36 |
| smoser | can you pastebin /var/log/cloud-init.log ? pastebinit /var/log/cloud-init.log | 13:36 |
| stl_ | smoser: cloud-init.log https://pastebin.com/yBx8Nq14 ; ip r output after boot https://ibb.co/k0E7g5 ; /etc/network/interfaces.d/50-cloud-init.cfg https://ibb.co/h2v2EQ As you can see two defaults defined by cloud-init. Both networks are usual OpenStack virtual networks. First network advertise route 172.16.20.0/24. Thank you a lot! | 13:48 |
| smoser | stl_, you could have used 'pastebinit' | 13:53 |
| smoser | :) | 13:53 |
| smoser | literally type: pastebinit /var/log/cloud-init.log :) | 13:53 |
| stl_ | if i flush interfaces and run dhclient, then i get https://pastebin.com/Gh9kPdLx which is what i would expect. I have tried following cloud configs, but without success https://pastebin.com/7zb3tb1B | 13:54 |
| stl_ | ok :) i will type | 13:54 |
| stl_ | cloud-init.log http://paste.ubuntu.com/25592505/ :) sorry i didnt know about pastebinit | 13:55 |
| smoser | its a very useful command. it can paste to other pastebins, but uses ubuntu by default. ubuntu is ad-free which is nice, but requires you to log in to get "raw" download (to avoid abuse) | 14:00 |
| smoser | anyway... after that advertisement for pastebinit, i'm reading your pastes :) | 14:00 |
| smoser | stl_, would you be able to get me the network_data.json file that is on the attached config drive ? | 14:01 |
| smoser | cloud-inti doesnt log it, just what it converted it to. | 14:01 |
| stl_ | smoser: sure, could you please navigate me where it is stored? | 14:02 |
| smoser | stl_, wow. i actuall thought that kernel/ip would fail if you tried to write two default routes (as in 'route exists') | 14:03 |
| smoser | hm.. | 14:03 |
| smoser | hm... so there is a disk attached. | 14:03 |
| smoser | run | 14:03 |
| smoser | mount /dev/disk/by-label/config-v2 /mnt | 14:03 |
| smoser | maybe.. | 14:03 |
| rharper | smoser: while it's not in json format, looking at the v1 is easy enough to see: http://paste.ubuntu.com/25592551/ | 14:04 |
| smoser | rharper, yeah, but i wanted to get the real thing | 14:04 |
| rharper | there are two nics, each one has a cateway, both are set as "Default" | 14:04 |
| rharper | gateway | 14:04 |
| smoser | in case we did a bad job converting | 14:04 |
| rharper | that's fair | 14:04 |
| smoser | i really thought you coudl'nt do 'ip route add default' more than once | 14:05 |
| smoser | so https://ibb.co/k0E7g5 confused me :) | 14:05 |
| rharper | we render eni here, though | 14:05 |
| rharper | we have |: in those post-ups to deal with the artibrary order of the hook scripts | 14:05 |
| rharper | interesting | 14:06 |
| smoser | rharper, yeah, but his 'ip r' shows them | 14:06 |
| rharper | well, maybe ip let's you shoot your self in the foot | 14:06 |
| smoser | i didnt think the kernel would let you | 14:06 |
| smoser | ie, i thought 'route exists' | 14:06 |
| rharper | it's just a table | 14:06 |
| rharper | that's not the kernel, that's the tool saying that | 14:07 |
| smoser | i thought ip tried to add a route to table and got error | 14:07 |
| smoser | thus "kernel" | 14:07 |
| smoser | anyway. | 14:07 |
| smoser | stl_, we really need the original network_data.json | 14:07 |
| rharper | I think we can get it from the obj.pkl; lemme see on an openstack instance | 14:08 |
| smoser | and if it says that both of those nics should contain the "default" route, then .... we're doing as close to what we we were told to do, and we'll probably need to file a bug in openstack. | 14:08 |
| smoser | well, it shoudl be easily mountable too though. stl_ my 'mount' command above work ? | 14:08 |
| rharper | y | 14:08 |
| smoser | rharper, in your pasted config.. | 14:09 |
| smoser | we could have make a hueristic decision there | 14:09 |
| smoser | as the first had a default route *and* a netmak'd route | 14:09 |
| stl_ | smoser: here's paste http://paste.ubuntu.com/25592580/ it's from configdrive openstack/latest/network_data.json | 14:09 |
| smoser | oh wierd. but that .20 | 14:10 |
| smoser | wierd | 14:10 |
| smoser | stl_, tyats what we needed. thanks | 14:10 |
| stl_ | smoser: great! thank you | 14:10 |
| rharper | smoser: heh | 14:12 |
| rharper | we just copy in the routes provided | 14:12 |
| smoser | http://paste.ubuntu.com/25592599/ | 14:13 |
| smoser | ^ is just prettier formated of stl's paste. | 14:13 |
| rharper | I'm not sure at conversion time we can make a choice; I suspect the second network/nic need not have a gateway, but we don't know how the subnet in neutron was configured | 14:13 |
| smoser | yeah. it is buggy. | 14:14 |
| smoser | openstack is. | 14:14 |
| smoser | they tell us there are two networks and give a default route on both. there isnt really a way to pick. | 14:15 |
| smoser | hm.. | 14:15 |
| smoser | stl_, do you have access to the hypervisor ? | 14:15 |
| stl_ | smoser: yes I have | 14:16 |
| smoser | it'd be good for you to file a bug with 'ubuntu-bug nova-compute' | 14:16 |
| smoser | and then i can fill in some othoer info | 14:16 |
| smoser | you open it, and then i'll fill in the rest. | 14:16 |
| smoser | but basically they're giving us incomplete information | 14:16 |
| smoser | cloud-init is doing what they said to do :) | 14:17 |
| smoser | stl_, interstingly i think that if you ran dhclient on boht of those interfaces, you'd probably only get one route as default | 14:17 |
| smoser | and that would be random based on which got done first | 14:17 |
| stl_ | actualy our hypervisors don't have access to Internet if 'ubuntu-bug nova-compute' is Ubuntu command | 14:17 |
| smoser | unless they have that path somehow fixed and one of the dhcp servers would *not* give you that default route | 14:18 |
| smoser | stl_, it is a command. it'd just collect some info on versions and things. | 14:18 |
| stl_ | smoser: yes, if i run dhclient i will get default only from second interfaces (that's what i want) | 14:18 |
| smoser | "second" | 14:18 |
| smoser | as in "second that your run" ? or as in "always network1" | 14:19 |
| smoser | stl_, i'm kind of curious to see that. if you ran 'dhclient eth0' and 'dhclient eth1' and got the leases and the output of each. i'd be interested to see. | 14:20 |
| stl_ | smoser: I was always runing just "sudo dhclient" | 14:21 |
| stl_ | but i can try dhclient ens3 and then dhclient ens4 | 14:21 |
| smoser | stl_, you have a launchpad id ? | 14:21 |
| smoser | i'll copy you on the bug. | 14:21 |
| smoser | stl_, if you wanted... dhclient -v | 14:22 |
| smoser | woudl be sufficient | 14:22 |
| smoser | the grab the /var/lib/dhcp/dhclient.leases file | 14:22 |
| stl_ | smoser: https://ibb.co/bWHA15 got same default. Looks like if no route is advertised then default is installed. | 14:25 |
| stl_ | smoser: I have launchpad account | 14:25 |
| smoser | stl_, i suspect that one of the two dhcp servers advertised a default route | 14:30 |
| smoser | could you | 14:30 |
| smoser | dhclient -r | 14:30 |
| smoser | then | 14:30 |
| smoser | dhclient -v | 14:31 |
| smoser | and then get /var/lib/dhcp/dhclient.leases ? | 14:31 |
| stl_ | sure | 14:31 |
| stl_ | console, dhclient -r, dhclient -v https://ibb.co/mZYTok here's dhclient.leases http://paste.ubuntu.com/25592685/ | 14:34 |
| frickler | there is a bug against neutron that wants to allow not having a default route for networks: https://bugs.launchpad.net/neutron/+bug/1717560 | 14:40 |
| ubot5 | Ubuntu bug 1717560 in neutron "allow to have no default route in DHCP host routes" [Undecided,New] | 14:40 |
| rharper | interesting | 14:40 |
| frickler | stl_: not sure if I missed that in the scrollback, could you also pastebin the output of "openstack network/subnet show" for your (sub)networks? | 14:41 |
| stl_ | frickler: will do | 14:42 |
| rharper | smoser: looking at the leases, only ens4 has 'routers' option; and there is 'classless-static-routes' for both; I'm not sure how those relate to setting routes on the system, but I wouldn't expose those to become a default route | 14:42 |
| smoser | frickler, ! welcome . i was trying to think of who i knew that had some openstack networking chops | 14:42 |
| smoser | and he stepped right into the room! | 14:42 |
| * rharper is awed by the summoning powers of smoser | 14:43 | |
| frickler | smoser: been lurking here for long :D | 14:43 |
| frickler | just took a view after seeing stl_'s question over in #openstack ;) | 14:44 |
| smoser | oh. ok. i'm opening a bug. | 14:44 |
| frickler | also about to leave for the weekend, but I hope I can take another look later | 14:44 |
| smoser | it does appear from his dhclient leases that the servers "know" | 14:44 |
| smoser | frickler, you leave work to early (and i'm not accepting any excuse that includes the word 'timezone') | 14:45 |
| smoser | :) | 14:45 |
| stl_ | here's openstack network and subnet pastes http://paste.ubuntu.com/25592742/ | 14:46 |
| stl_ | smoser: if you need i can open bug on launchpad | 14:48 |
| smoser | https://bugs.launchpad.net/nova/+bug/1718954 | 14:51 |
| ubot5 | Ubuntu bug 1718954 in OpenStack Compute (nova) "network_data.json contains default routes for 2 interfaces" [Undecided,New] | 14:51 |
| stl_ | thanks! | 14:51 |
| smoser | stl_, who are you there? | 14:56 |
| smoser | Lukas or Dr. Jens ? | 14:56 |
| stl_ | smoser: Lukas :) | 14:57 |
| smoser | stl_, if you're looking for a hack / workaround | 14:57 |
| smoser | the easiest thing is probably to just delete the route | 14:57 |
| smoser | ip route delete ... | 14:58 |
| smoser | of the bad one | 14:58 |
| stl_ | smoser: yes, that's something i have came up also. I was hoping that cloud-config will work (set interfaces to dhcp), but no success from my side. | 14:59 |
| smoser | stl_, well, you can't really affect networking confguration in user-data | 15:01 |
| smoser | its just kind of "too late" | 15:01 |
| stl_ | :) | 15:02 |
| smoser | stl_, you could provide some script to run that would re-write it, so it'd be fixed on reboot | 15:04 |
| smoser | but you could just as well add a post ifup.d | 15:04 |
| smoser | that took out that default route | 15:04 |
| stl_ | thanks for help and that bug report! Have a nice weekend. | 15:08 |
| kszarlej | hi guys. I have that configuration for NoCloud drive. It is used for my LibVirt KVM VMs. The mount (vdb) is not mounted. The device is available at /dev/sdb and in /etc/cloud/cloud.cfg the mounts module is listed in init modules. There is no error in logs. Any suggestions? | 15:09 |
| kszarlej | oh the configuration is here, forgot the link http://paste.ubuntu.com/25592915/ | 15:09 |
| kszarlej | the /data directory actually doesnt exist when booting but I assume that cloud-init should create it? (Creating it using runcmd is pointless as it runs after the mounts module) | 15:12 |
| powersj | kszarlej: can you please look the two lcoud-init logs under: /var/log/cloud-init* | 15:44 |
| powersj | smoser: rharper: https://bugs.launchpad.net/cloud-init/+bug/1718959 looks like this guy ran into an odd unicode character. Is there a good suggestion to help him debug his user-config? | 15:44 |
| ubot5 | Ubuntu bug 1718959 in cloud-init "user-data ignored in DataSourceNoCloud" [Undecided,New] | 15:44 |
| kszarlej | powersj: found that | 15:46 |
| kszarlej | http://paste.ubuntu.com/25593105/ | 15:46 |
| kszarlej | in cloud-init.log | 15:46 |
| kszarlej | looks like the ci cant see the mount I have in config | 15:47 |
| kszarlej | btw I use centos and a daily build from cloud init devel repo (because the upstream from centos repos is broken :P) | 15:49 |
| kszarlej | rest of the stuff specified in meta-data was configured fine | 15:54 |
| powersj | kszarlej: was the daily build from: https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ | 15:58 |
| kszarlej | yes | 16:00 |
| kszarlej | the one that is in centos 7 repos | 16:00 |
| kszarlej | was unable to set the networking | 16:00 |
| kszarlej | been consulting that yesterday evening here :P | 16:00 |
| powersj | kszarlej: If you could, can you file a bug please. | 16:01 |
| blackboxsw | I can't wait for us to get 17.1 into xenial so we can have "ubuntu file-bug cloud-init". | 16:10 |
| blackboxsw | it works currently on artful | 16:11 |
| blackboxsw | I mean ubunt-bug cloud-init | 16:11 |
| blackboxsw | I mean ubuntu-bug cloud-init | 16:11 |
| blackboxsw | third time's the charm | 16:11 |
| === blackboxsw changed the topic of #cloud-init to: is Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 10/2 14:00 UTC | cloud-init 17.1 released (artful) | ||
| === blackboxsw changed the topic of #cloud-init to: is Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 10/2 14:00 UTC | cloud-init 17.1 released | ||
| blackboxsw | I know that won't help us on centos, but it's a fun improvement for ubuntu | 16:13 |
| blackboxsw | kszarlej: you can run cloud-init collect-logs to collect a tarfile of logs that can be attached to the bug | 16:14 |
| blackboxsw | or even 'cloud-init collect-logs --include-userdata | 16:16 |
| smoser | blackboxsw, well, kszarlej is using trunk | 16:28 |
| smoser | so he can | 16:28 |
| blackboxsw | trunk centos right? | 16:28 |
| smoser | trunk on centos | 16:28 |
| smoser | (copr build) | 16:28 |
| blackboxsw | he can "collect-logs --include-userdata" :) | 16:28 |
| smoser | right | 16:29 |
| smoser | ah. ubuntu-bug . i see . you were saying that wont work there. | 16:29 |
| smoser | which is treu | 16:29 |
| smoser | true even | 16:29 |
| blackboxsw | glad someone has has a case of typos this morning | 16:29 |
| smoser | kszarlej, is that you -> https://bugs.launchpad.net/cloud-init/+bug/1718959 ? | 16:32 |
| ubot5 | Ubuntu bug 1718959 in cloud-init "user-data ignored in DataSourceNoCloud" [Undecided,New] | 16:32 |
| powersj | smoser: if you make a request of someone can you mark the bug incomplete? | 16:33 |
| dpb1 | yes | 16:35 |
| dpb1 | absolutely | 16:35 |
| kszarlej | smoser: no | 16:35 |
| kszarlej | I didnt create the bug yet | 16:35 |
| kszarlej | trying to make a workaround first | 16:35 |
| kszarlej | need to have that working today | 16:35 |
| dpb1 | powersj: there is room for judgement if the request isn't material to the working on the bug, but normally, you don't want to action a bug with incomplete information. | 16:36 |
| powersj | dpb1: agreed: I just like to see new bugs that we respond to either moved to incomplete, invalid, or confirmed. | 16:37 |
| kszarlej | ok now I lost my mind | 16:37 |
| smoser | done | 16:38 |
| dpb1 | powersj: yes, it's a sane policy that we should try to stick to. (or wont fix) | 16:38 |
| kszarlej | http://paste.ubuntu.com/25593417/ and in log: 2017-09-22 16:32:00,901 - cc_runcmd.py[DEBUG]: Skipping module named runcmd, no 'runcmd' key in configuration | 16:38 |
| === robjo is now known as robjo_away | ||
| ajorg | gah. why haven't I prepared https://git.launchpad.net/~ajorgens/cloud-init/commit/?id=aaa626dd8aecc078210d3a48ff39faf3fd30cbdc for merging yet. It seemed pretty important when I wrote it! | 16:44 |
| blackboxsw | it's that "day job" thing... it just keeps getting in the way of good fun | 16:46 |
| ajorg | seriously | 16:46 |
| cesarjorge_ | Hi | 16:54 |
| cesarjorge_ | I need help with cloud-init in an OS image of Centos 7.4 that I build | 16:56 |
| ajorg | cesarjorge_: best to cut right to the chase and describe the problem you ran into | 16:57 |
| cesarjorge_ | I need to create this image to working without extra changes in the cloud or not cloud environments: | 16:58 |
| cesarjorge_ | I need that my image instantiate correctly if I launch it, for example, inside OpenStack, or, as a simple instance in local, I have virtualbox | 17:00 |
| cesarjorge_ | Then, if I launch the image in OpenStack, works correctly. But if launch the image in virtualbox (as a simple instance), the cloud-init does: | 17:01 |
| cesarjorge_ | Break my configured specific user with password, and takes many time to start | 17:02 |
| cesarjorge_ | And does other things | 17:03 |
| cesarjorge_ | Then, I need create a image that, if not launched in cloud, then do nothing and not interfere. If launch in a cloud, then execute as normal | 17:04 |
| cesarjorge_ | How can I do it? | 17:16 |
| blackboxsw | ok schema suggestion for https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 added robjo_away | 17:17 |
| ajorg | cesarjorge_: you've tried, and it doesn't work? Or you're assuming it won't work? | 17:18 |
| ajorg | IIRC for VirtualBox cloud-init will try to use the NoCloud data source: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html | 17:20 |
| smoser | cesarjorge_, ajorg is right. cloud-init goes looking for a "datasource". and if it doesnt find one can be kind of annoying. you can provide it one in virtualbox. | 17:20 |
| smoser | you can configure the datasource_list in the image to only consider OpenStack (or ConfigDrive) and NoCloud | 17:22 |
| smoser | then it wont end up polling for the ec2 metadata service | 17:22 |
| cesarjorge_ | I have try, but dont work. Using datasources will work? | 17:22 |
| smoser | and will fallback to the None datasource faster. | 17:22 |
| smoser | well, "don't work" isnt much information. | 17:23 |
| smoser | NoCloud will work in virtualbox for sure. | 17:23 |
| smoser | https://asciinema.org/a/132013 | 17:23 |
| smoser | theres a ubuntu cloud image demo of doing this in qemu-system-x86_64 but the same basic thing will work on virtualbox. | 17:24 |
| ajorg | "Break my configured specific user with password" you can probably configure it not to do, with a NoCloud source. "takes many time to start" sounds mysterious | 17:24 |
| ajorg | https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups | 17:25 |
| cesarjorge_ | Then, I configure datasource_list: [ NoCloud ] ? | 17:25 |
| cesarjorge_ | In file cloud.cfg? | 17:25 |
| ajorg | oh, you probably mean it take *much* time to start. That's fixed by limiting it to the data sources you know it might use, as smoser said. | 17:25 |
| smoser | well, if you want it to work on penstack you'll need to put either ConfigDrive or OpenStack in there. | 17:26 |
| smoser | (ajorg, i assume he's polling for the ec2 metadata service is what takes long) | 17:26 |
| ajorg | smoser: I thought that was fixed by checking the system uuid? | 17:27 |
| smoser | hm...... yeah. | 17:27 |
| ajorg | but if he's on CentOS he's got an older version, probably. CentOS and RHEL are not aligned for cloud-init last I checked. | 17:27 |
| smoser | you're right. | 17:27 |
| smoser | yeah | 17:28 |
| cesarjorge_ | Version 0.7.9 for centos 7.4 | 17:28 |
| ajorg | Oh, maybe they fixed that. They used to be on 0.7.5. | 17:29 |
| ajorg | I assume it checks for lots of other clouds though, and any of those takes time? | 17:30 |
| cesarjorge_ | I just tried using a image with line datasource_list: [ OpenStack ]. Inside virtualbox works good. But inside OpenStack fail | 17:31 |
| cesarjorge_ | Only if I boot the image without using no cloud task. Simply starting VM | 17:32 |
| cesarjorge_ | Question: What tasks does the None datasource do? | 17:37 |
| cesarjorge_ | This datasource is executed if no find any? | 17:38 |
| ajorg | https://cloudinit.readthedocs.io/en/latest/topics/datasources/fallback.html | 17:41 |
| smoser | none datasource doesnt do much. yes. basically generates ssh keys. will probably add the default user. and might lock its password (you could change that in config) | 17:43 |
| smoser | frickler, just for your later reference | 17:45 |
| smoser | https://bugs.launchpad.net/nova/+bug/1718954 | 17:45 |
| ubot5 | Ubuntu bug 1718954 in OpenStack Compute (nova) "network_data.json contains default routes for 2 interfaces" [Undecided,New] | 17:45 |
| cesarjorge_ | If I lock password, in config, then when I launch in openstack not work with ssh keys | 17:46 |
| smoser | ? | 17:46 |
| smoser | if you want a user that is already in the image and will always be accessible, just create one. you can put ssh keys in it or not and set a password or not. cloud-init will not make any changes to that user. | 17:47 |
| smoser | name it 'superdude' or something. | 17:48 |
| cesarjorge_ | If I launck in openstack, cloud-init modify the file /etc/ssh/sshd_config removing all passwordauthetication yes | 17:51 |
| cesarjorge_ | For all users | 17:52 |
| cesarjorge_ | If insert a specific line Match ssh user passwordauthentication no, then, does same thing, remove this line | 17:53 |
| smoser | i'm going to go through fix-commnitted bugs now and mark fix-released for all in 17.1 | 17:58 |
| smoser | cesarjorge_, you can set that. | 17:59 |
| smoser | i am not aware of ssh user passwordauthentication. you're saying that is a sshd_config setting that you can set per-user stuff ? i didnt know and tis quite possible that cloud-init gets confused by that. | 17:59 |
| smoser | you can tell cloud-init to either always enable password auth or not mess with it. | 18:00 |
| smoser | ssh_pwauth: <yes/no/unchanged> | 18:00 |
| cesarjorge_ | In summary: I try to use same image for a cloud environment or isolate environment. In cloud environment I use cloud-init with ssh keys. In my isolate environment, i use one user with password, dont need the work for configurate extra things. Then, when the image works in cloud, dont work in isolate environment, and backwards | 18:00 |
| cesarjorge_ | The result in isolate env when I do ssh: no authentication method available, because cloud-init change this passwordauthentication in sshd config | 18:04 |
| cesarjorge_ | But, for openstack, I need this variable to do ssh public key for all users | 18:05 |
| cesarjorge_ | I can configure virtualbox for use ssh public key, but complicate the configuration for users than only need work with an isolate VM, using passwords, without extra configuration | 18:09 |
| smoser | cesarjorge_, so you'd like for it to leave password authentication unchanged when running on a cloud | 18:15 |
| smoser | but turn it off when running local | 18:15 |
| smoser | er.. leave unchanged (off) when running on a cloud. but when run locally enable it. | 18:16 |
| smoser | you can kind of do this i think if you backed config for NoCloud into the image that had its own config there. | 18:17 |
| cesarjorge_ | Passwordauthentication no, when cloud, passwordauthentication unchanged when no cloud | 18:17 |
| smoser | wait. | 18:17 |
| smoser | right | 18:17 |
| cesarjorge_ | Or, better, not execute nothing nothing if no cloud | 18:17 |
| smoser | yeah. so you could do this by provding inside the image NoCloud config that would end up getting always found (in the event that it was not on a cloud) | 18:17 |
| cesarjorge_ | Better write: not change nothing in the instance if no cloud | 18:18 |
| smoser | i think what you want is mostly how Ubuntu in 17.04 and later is set to work | 18:19 |
| smoser | if cloud-init finds its not in a cloud, it disables itself entirely. | 18:19 |
| smoser | so it should be acheivable with centos too. but i'm not sure how well the systemd-generator stuff is integrated tehre. | 18:20 |
| smoser | cesarjorge_, i'm sorry, i can't spend any more time on this now. i think what you're after is either doable or not far off. | 18:21 |
| cesarjorge_ | Workaround for centos? The RH/centos take a lot of tima in upgrade official versions | 18:21 |
| smoser | cesarjorge_, you definitely need newer cloud-init. from trunk-ish | 18:22 |
| smoser | we have copr builds | 18:23 |
| smoser | https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ | 18:23 |
| smoser | those are of trunk | 18:23 |
| cesarjorge_ | Thanks, I will try this trunk version. If you encounter a workaround for 0.7.9,, i would be grateful | 18:25 |
| === robjo_away is now known as robjo | ||
| robjo | blackboxsw: thanks | 18:51 |
| blackboxsw | np robjo | 18:52 |
| robjo | on the schema, I guess the basic question would be do we want to validate everything | 18:52 |
| robjo | that would imply that yes we'd have to document everything at https://en.opensuse.org/openSUSE:Standards_RepoInfo | 18:53 |
| robjo | but that appears overkill to me | 18:53 |
| robjo | and of course total duplication | 18:53 |
| robjo | blackboxsw: ^^^^^ | 18:55 |
| blackboxsw | robjo: yeah it also forces you into a high-maintenance world where cloud-init was out of date as format moves on | 18:55 |
| robjo | yes, thus it would be much nicer if the validation can somehow throw up it's hands and say "Ok, I know you need "baseurl" for everything else I don't care" | 18:56 |
| robjo | is that an option? | 18:57 |
| blackboxsw | as you saw with the config example, the permissive approach would be the following: 'config': { | 18:57 |
| blackboxsw | 'type': 'object', | 18:57 |
| blackboxsw | 'description': 'Any supported zypo.conf key is written to /etc/zypp/zypp.conf' | 18:57 |
| blackboxsw | } | 18:57 |
| blackboxsw | yeah per the repos structure it could be the following if all you care about is baseurl | 18:57 |
| blackboxsw | one sec, will paste | 18:57 |
| robjo | And then the "id" is required becauase we cannot validate "any_random_name:" right? | 18:59 |
| blackboxsw | http://pastebin.ubuntu.com/25594124/ | 18:59 |
| blackboxsw | yeah like this robjo | 18:59 |
| blackboxsw | yeah otherwise jsonschema can't describe the subschema under <any_random_name>: {...} | 19:00 |
| blackboxsw | I will take an action as I keep adding more schema though to see if there is a sensible way to describe that in jsonschema | 19:01 |
| blackboxsw | and if so, to send a patch and ping you... admitedly I'm still a newbie at jsonschema | 19:01 |
| robjo | Well we need multiple ids though such that a user can add as many repos as they want | 19:02 |
| robjo | so repos is really repos :{ [id, baseurl,....],[id baseurl,...],[id, baseurl,....]} | 19:03 |
| robjo | I am OK with calling it id, as this is an incompatible change we just need to nail it down and then leave it, whatever it is | 19:04 |
| robjo | So how do we express the list behavior? | 19:05 |
| blackboxsw | robjo: oops type in the schema.. one fixing the paste | 19:06 |
| blackboxsw | will account for that | 19:06 |
| robjo | and what does it look like in yaml? | 19:06 |
| ajorg | robjo: I'm missing some context (sorry for jumping in here). What are you working on? | 19:10 |
| robjo | Trying to figure out what the repo definition shoud look like, https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 | 19:11 |
| blackboxsw | http://paste.ubuntu.com/25594201/ | 19:13 |
| blackboxsw | ok I'm looking over the following ^ as a potential it defines repos as a list w/ min items 1 | 19:13 |
| blackboxsw | and declares that each item must have baseurl and id in it. | 19:13 |
| blackboxsw | other attributes are allowed | 19:13 |
| ajorg | robjo: interesting. I thought the spec was identical for zypp and for yum? | 19:15 |
| ajorg | just the file location was different? | 19:15 |
| robjo | blackboxsw: that works for the schema I don't think this can be expresed in yaml | 19:16 |
| robjo | ajorg: the repo description is different, and there is the desire to change things, i.e. th ecurrent implementation for RHEl is not what we want to do | 19:17 |
| ajorg | okay, cool | 19:17 |
| robjo | blackboxsw: That works for schema validation, but cannot be expressed in YAML, I think | 19:18 |
| ajorg | reminds me i have a patch that helps make sure yum config is correct, but it's currently buried in another patch, need to tease that out | 19:18 |
| blackboxsw | robjo: drawing up an example and testing w/ your branch | 19:18 |
| robjo | The point of the <arbitrary_name>: is to give yaml a separator and each is unique thus the result is a dict with {arbitrary_name1:{....], arbitrary_name2:{....}} | 19:20 |
| robjo | but if we say items: then there's no way to differentiate for the yaml parser and the result is undetermined | 19:21 |
| blackboxsw | robjo: like this? http://pastebin.ubuntu.com/25594260/ | 19:22 |
| blackboxsw | can't your module validate 'id' on each object is unique? | 19:23 |
| blackboxsw | or this http://pastebin.ubuntu.com/25594275/ | 19:25 |
| robjo | yaml bitches at that, looking at the error | 19:25 |
| blackboxsw | hmm here's on my side http://pastebin.ubuntu.com/25594296/ | 19:28 |
| robjo | yes, without the {} I got it to work as well | 19:29 |
| blackboxsw | ahh checking the {} again to see if I can get that working | 19:29 |
| robjo | But that works, so I'll run with that | 19:30 |
| blackboxsw | robjo: yeah less characters than the other way | 19:32 |
| blackboxsw | here's the other http://pastebin.ubuntu.com/25594320/ | 19:32 |
| blackboxsw | had to fix a bunch | 19:32 |
| robjo | Thanks, I like the - better I'll use that as example ;) | 19:34 |
| blackboxsw | I'm still trying to get the suggestion for your schema to work... I iterate w/ python3 -m 'cloudinit.cmd.main devel schema --doc' and ... devel schema -c <sample-cloud-config> | 19:34 |
| blackboxsw | and initial patch for schema http://paste.ubuntu.com/25594361/ | 19:40 |
| blackboxsw | robjo: ^ | 19:41 |
| blackboxsw | you'll also need to git fetch; and get rebase origin master as we put in a docs fix related to schema yesterday | 19:41 |
| blackboxsw | that helps rendering | 19:41 |
| robjo | blackboxsw: great thanks, I'll get that included and hopefully will get the test written yet his afternoon, for another full review | 19:42 |
| blackboxsw | +1 | 19:42 |
| robjo | next week is SUSECon I'll have little to no time.... | 19:42 |
| blackboxsw | I'd imagine, we're heading for a sprint next week too so response times may be slow | 19:43 |
| smoser | blackboxsw, welll.. comments on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115 | 19:44 |
| smoser | robjo, i think my invitation to SUSECon got lost in the mail. | 19:44 |
| robjo | smoser: and Prague is such a nice place | 19:45 |
| smoser | yeah. | 19:45 |
| smoser | blackboxsw, i commented on your json file stuff | 19:47 |
| blackboxsw | thanks smoser will look at what we think should be done there | 19:48 |
| blackboxsw | smoser: good points, yeah I stopped work on this when we were trying to get 17.1 stuff in. Forgot that I didn't get back to work out the standardized top-level keys vs datasource blobs | 20:01 |
| blackboxsw | I had debated about iterating on standard/nornmalized metadata keys in instance-data.json on a followup branch. But, I guess we can implement low-hanging fruit in this branch. The problem with normalized/general keys is that we may have to have a ds.normalized_metadata function that each datasource may have to implement to surface the common named keys if they don't already have it in meta/user-data | 20:06 |
| smoser | agreed | 20:09 |
| robjo | how do I run just one test? while I am working on the tests for zypper_add_repo I do not really want to run the whole test suite over and over again | 20:19 |
| robjo | and next question how do I populate the tmp location with a file that can be read by a test? | 20:20 |
| smoser | robjo, fastest thing is to use ./tools/tox-venv | 20:25 |
| smoser | $ ./tools/tox-venv py3 python3 -m nose tests/unittests/test_util.py | 20:25 |
| smoser | if you just want to run your tests and dont want to use tox-venv or it didnt work for you | 20:25 |
| smoser | $ tox -e py3 tests/unittests/test_util.py | 20:25 |
| smoser | tox-venv skips the "install" phase which is slow. | 20:26 |
| smoser | to populate a tmp location... | 20:26 |
| smoser | probably easiest is, if youre subclass of CiTestCase | 20:26 |
| smoser | tmp = self.tmp_dir() | 20:26 |
| robjo | right now, i.e. in the pending MR it is: class TestConfig(helpers.FilesystemMockingTestCase): | 20:27 |
| smoser | helpers.populate_dir(tmp, {'etc/passwd': content_for_that, 'usr/file1': more_stuff}) | 20:27 |
| robjo | great, thanks | 20:28 |
| smoser | you want to do the populating before you patchUtils() | 20:28 |
| smoser | or it gets in the way | 20:28 |
| smoser | err... rather than patchUtils | 20:29 |
| smoser | probably patch.reRoot() is what youw ant | 20:29 |
| smoser | but do your pouplation of things *before* that | 20:29 |
| blackboxsw | meh all systemd dhcp lease parsing content/handlers are defined in internal header files. | 20:46 |
| blackboxsw | private dhcp options are parsed and added to internal lease objects | 20:47 |
| blackboxsw | but I don't yet see a path to expose that content | 20:47 |
| blackboxsw | FilesystemMockingTestCase subclasses from CiTestCase so self.tmp_dir() tmp_path are available there too | 20:49 |
| blackboxsw | hrm per systemd: sd_dhcp_client_get_lease might be what I want | 20:51 |
| robjo | smoser: is there already a utility function in the test infrastructure to confirm that warning messages get written or do I need to do that via @patch? | 21:17 |
| blackboxsw | smoser: rharper :) http://pastebin.ubuntu.com/25594875/ | 21:25 |
| blackboxsw | I think we can get to systemd custom dhcp options | 21:25 |
| blackboxsw | busctl FTW | 21:25 |
| blackboxsw | checking other instance types | 21:26 |
| rharper | blackboxsw: whoa | 21:26 |
| rharper | busctl needs a --json *so* bad | 21:27 |
| rharper | I've not looked at it yet, but there is python systemd module | 21:27 |
| rharper | maybe there's some easy access to the systemd dbus | 21:28 |
| blackboxsw | yeah it's nasty | 21:28 |
| blackboxsw | with custom types etc | 21:28 |
| rharper | oh, that's NetworkManager | 21:29 |
| rharper | org.freedesktop.systemd1 | 21:30 |
| blackboxsw | yeah unfortunately /org/freedesktop/network1 gives us nothing of use. it describes the systemd network files used, but nothing as far as dhcp or network related config settings | 21:59 |
| smoser | blackboxsw, but that comes from networkmanager | 22:46 |
| smoser | not systemd | 22:47 |
| smoser | systemd-netwokrd | 22:47 |
| blackboxsw | yeah, looking at extending systemd-networkd to expose options | 22:47 |
| blackboxsw | yeah, looking at extending systemd-networkd to expose dhcp-options | 22:47 |
| blackboxsw | just like NetworkManager does. it's a bit of a lift.... and my C is rusty | 22:47 |
| smoser | horay for change for the sake of change! | 22:47 |
| blackboxsw | heh | 22:47 |
| smoser | we'd all be out of work otherwise. | 22:47 |
| smoser | what would i have accomplished from 14.04 to 16.04 if not for systemd. | 22:48 |
| smoser | nothing | 22:48 |
| blackboxsw | heh | 22:48 |
| blackboxsw | gotta stir up some dinner | 22:48 |
| blackboxsw | have a good weekend folks | 22:48 |
| robjo | smoser: https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 ready for another review. | 22:54 |
| robjo | Have a nice weekend everyone | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!