| SmokedCheese | hello! it's possible to set hostname with variables? | 07:47 |
|---|---|---|
| SmokedCheese | or should i use something like bootcmd: - hostnamectl set-hostname "hostname-$(http://169.254.169.254/2009-04-04/meta-data/instance-id)" ? | 07:58 |
| smoser | SmokedCheese: its not possible right now. we have a card to do something like that. | 12:53 |
| smoser | so yeah, your only option is what you have there. | 12:53 |
| SmokedCheese | okay, thanks! | 12:53 |
| smoser | SmokedCheese: https://trello.com/c/AYaCdQyT | 14:15 |
| smoser | that is the card that describes what we'd be looking to do. | 14:15 |
| smoser | and i just added a section for what i think you were asking for. | 14:17 |
| SmokedCheese | sweet | 14:30 |
| smoser | powersj: so... https://code.launchpad.net/~ajorgens/cloud-init/+git/cloud-init/+merge/331660 | 16:14 |
| smoser | ci didnt run. but didnt complaon | 16:14 |
| smoser | and /me didn't see it cry | 16:14 |
| smoser | because ajorgens isnt in happy list | 16:14 |
| smoser | probably need some solution for that | 16:14 |
| powersj | aah | 16:14 |
| powersj | let me add him to the white list | 16:15 |
| blackboxsw | +1 powersj can you make sure robjo is on that too | 16:15 |
| blackboxsw | he might already be | 16:15 |
| powersj | blackboxsw: robojo is rjschwei? | 16:16 |
| blackboxsw | powersj: yep | 16:16 |
| smoser | powersj: where is that list ? | 16:16 |
| powersj | smoser: torkoal:~/.jlp/jlp.config | 16:17 |
| powersj | and done | 16:18 |
| robjo | my lp userid is rjschwei | 16:26 |
| robjo | powersj: ^^^^ | 16:26 |
| powersj | robjo: thx | 16:27 |
| blackboxsw | welcome to the wide world of automated CI votes on your branches robjo | 17:35 |
| robjo | blackboxsw: thanks, something new to figure out ;) | 17:36 |
| robjo | on that note, anyone have any time to provide some feedback on the chrony integration on the ML? | 17:37 |
| smoser | blackboxsw: hm.. | 17:39 |
| smoser | hm.. | 17:40 |
| blackboxsw | hm.. | 17:40 |
| blackboxsw | ok cloud-init status systemctl checks is pushed | 18:18 |
| blackboxsw | sorry smoser yeah that last paragraph of the blog post was WIP. will ping when done | 18:19 |
| blackboxsw | ok done. | 18:36 |
| robjo | smoser: blackboxsw was there a network rendering fix after 17.1 was released? | 19:18 |
| robjo | reference is https://bugzilla.opensuse.org/show_bug.cgi?id=1064854 | 19:18 |
| ubot5 | bugzilla.opensuse.org bug 1064854 in OpenStack "cloud-init ignores network settings from config-drive in external network" [Normal,New] | 19:18 |
| robjo | it looks to me as if a V1 config is not properly transformed | 19:18 |
| blackboxsw | robjo approve https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333575 with comments | 19:19 |
| blackboxsw | approved rather. nothing for you to fix that I can see. | 19:19 |
| blackboxsw | probably will merge later today | 19:19 |
| blackboxsw | checking the bug | 19:19 |
| robjo | this appears to be tested in test_apply_network_config_eni_ub in test_netconfig | 19:19 |
| robjo | and I fail to see where this transformation would be distro implementation dependent | 19:20 |
| robjo | The way I see it the transformation should be as follows from V1 config to the debian/ubuntu network specification, which should then end up in the distro implementation which for openSUSE is still _write_network | 19:22 |
| blackboxsw | robjo: looks there is a distro-dependent component for network renders. I see renderer_configs defined in cloudinit/distros/debian.py which direct what renders to use for debian/ubntu | 19:30 |
| blackboxsw | checking how that's used | 19:31 |
| robjo | I am not using the renderer concept yet, because the sysconfig renderer has the path hard coded and the paths between RH and SUSE do not match, that's where the refactoring comes into play that I mentioned in the meeting the other day | 19:32 |
| robjo | for now I end up in network_state.parse_net_config_data | 19:33 |
| robjo | In "regular" code flow somewhere would be a call to distro,apply_network_config(), which fails for openSUSE/SLES the exception is then caught and we end up in _apply_network_from_network_config | 19:34 |
| robjo | in this method the information is supposed to be transformed to the "standard" debian/ubuntu interface configuration, i.e. it should look something like V1_NET_CFG_OUTPUT in the test | 19:35 |
| robjo | is there a test that covers that specific transformation? | 19:36 |
| rharper | robjo: so, network_data.json -> v1 config happens, then, since you're not yet using the sysconfig renderer, you're getting an already rendered eni config, but the opensuse write_network is re-reading it to convert it to sysconfig; it appears | 19:42 |
| blackboxsw | generally there is ./tools/net-convert in our repository we use to validate rendering types given a provided network config and specifying whether your are rendering ['eni', 'netplan', 'sysconfig'] output files. | 19:42 |
| rharper | I don't think we have a v1 -> net_util.translate_network() path | 19:42 |
| rharper | which is what's happening here | 19:42 |
| rharper | robjo: and there are no unit tests for net_util | 19:44 |
| robjo | :( | 19:44 |
| blackboxsw | meh the problem with 63% unittest coverage, is the other 37% | 19:45 |
| rharper | whats the delta in rhel sysconfig paths and suse ones? | 19:47 |
| rharper | that seems like a shorter path (using sysconfig renderer in the suse distro class) | 19:47 |
| robjo | 'network' (SUSE) vs. 'network-scripts' (RHEL) , yes I also roll my eyes over stuff like this ;) | 19:48 |
| rharper | man, that wants some temporary symlinking | 19:48 |
| rharper | if that's it | 19:48 |
| robjo | well "two ugly" do not really make "one pretty" | 19:49 |
| rharper | nope | 19:49 |
| rharper | but the instance boots with networking | 19:49 |
| rharper | too bad we can't ask sysconfig what paths it's using | 19:50 |
| robjo | but I suppose I could force the symlink in the cloud-init package, although I I remember correctly I tried to patch the path for 0.7.9 and that failed | 19:51 |
| rharper | robjo: where duse SUSE put the /etc/sysconfig/network (global settings) file ? | 19:51 |
| robjo | of course when 17.1 came around I had forgotten all of that and just moved forward since a good chunk of my out of tree code was now included | 19:52 |
| rharper | on RH, that has NETWORKING=yes and NETWORKING_IPV6=yes ; | 19:52 |
| robjo | the global settings file is /etc/sysconfig/network/config | 19:52 |
| rharper | urg | 19:53 |
| rharper | so both those paths | 19:53 |
| robjo | I suppose in the rendered we could test the and then switch between 'network' and 'network-scripts' but that's not very pretty either | 19:53 |
| robjo | s/rendered/renderer/ | 19:54 |
| rharper | well, I was thinking about that as well but; I think there may be other issues | 19:54 |
| rharper | in that config file, it uses NETCONFIG_* namespace for some variables | 19:54 |
| rharper | I suspect you'd need a subclass of sysconfig for some things, but others would be fine | 19:55 |
| rharper | bbiab | 19:56 |
| robjo | yes, there are NETCONFIG_* settings in that file | 19:56 |
| robjo | I agree that the proper route is subclassing i.e. refactoring, hence my question during the meeting | 19:57 |
| robjo | I think the shorter path for now may be to figure out a v1 -> net_util.translate_network() | 19:58 |
| robjo | unfortunately I am getting lost in network_state.py in parse_config_v1, cannot quite wrap my head around what's happening there | 19:58 |
| robjo | BTW at least in the code the path from v1 -> net_util.translate_network() at the high level is not too convoluted | 20:04 |
| robjo | If I put he puzzle together properly it would go along these lines: | 20:05 |
| robjo | apply_network_config -> this raises an exception which is caught and gets me to _apply_network_from_network_config here the config gets transformed vi network_state.parse_net_config_data() and eni.network_state_to_eni() then we end up in apply_network which finally calls _write_network() and the last method is implemented in the distro subclass and for openSUSE/SLES we end up caling net_util.translate_network() | 20:08 |
| robjo | my thinking is that either in network_state.parse_net_config_data() or eni.network_state_to_eni() something goes wrong | 20:09 |
| smoser | blackboxsw: were you looking at centos fail ? | 20:29 |
| smoser | i verified it does fail here locally | 20:31 |
| smoser | ./tools/run-centos --unittest 7 --keep | 20:31 |
| blackboxsw | smoser: yeah I had forgotten while fixing up disable and the blogpost. but reproduced on 6 and I'm working now | 20:33 |
| blackboxsw | looks like the URLError text raised is different in centos than ubuntu: 403 Client Error: Forbidden for url: %s versus just "403 Client Error: Forbidden" | 20:41 |
| ubot5 | Error: Ubuntu bug 403 could not be found | 20:41 |
| blackboxsw | thx ubot5 | 20:41 |
| blackboxsw | I'll update a patch to provide the bad_url if not present in the error message | 20:42 |
| smoser | nacc: i think you told me of somethign that is like | 20:43 |
| smoser | git commit-tree && HEAD | 20:43 |
| smoser | ie, head after commit-tree | 20:43 |
| smoser | ? | 20:43 |
| nacc | smoser: sorry, not followinng | 20:45 |
| smoser | if i have changes in my working directory | 20:46 |
| smoser | i wanted to refer to HEAD + changes-to-tracked files | 20:46 |
| smoser | ithink like this https://stackoverflow.com/questions/2766600/git-archive-of-repository-with-uncommitted-changes | 20:47 |
| nacc | smoser: you can write-tree | 20:47 |
| nacc | smoser: and that gives you a treeish | 20:47 |
| nacc | and git-archive can archive a treeish | 20:47 |
| nacc | smoser: it depends on what you want to do ... HEAD points to a commit, so it can't point to an uncommited state | 20:47 |
| smoser | and the yes | 20:47 |
| nacc | smoser: is there any reason you ca't just do a wip commit? | 20:48 |
| nacc | (which you might discard later) | 20:48 |
| smoser | how do you you reset to state before the commit ? | 20:49 |
| smoser | including 'git add' or other things. | 20:50 |
| smoser | ie, if i | 20:51 |
| smoser | touch foo | 20:51 |
| smoser | git add foo | 20:51 |
| smoser | git commit -a -m "that wip commit" | 20:52 |
| smoser | git reset HEAD^ | 20:52 |
| nacc | smoser: you can alwasy reset --hard to a commit | 20:52 |
| smoser | then i've lost the fact that 'foo' was added | 20:52 |
| nacc | smoser: and potentially do a `git clean -fxd` | 20:52 |
| nacc | smoser: no, it's still inn the commit you created | 20:52 |
| smoser | yeah, but the state of having been added is lost | 20:52 |
| nacc | smoser: i mean, i'm not sure i understand the use case, exactly | 20:52 |
| smoser | except for in that commit | 20:52 |
| nacc | smoser: oh you want to go back to an index state? | 20:55 |
| smoser | yeah, that was the goal. | 20:57 |
| smoser | basically i wanted to collect the tree up as it is right now. | 20:57 |
| smoser | wierd, i looked at 'git stash create' | 20:57 |
| smoser | this seems wrong: | 20:57 |
| smoser | echo "hi mom" > foo.txt | 20:57 |
| smoser | git add foo.txt | 20:57 |
| smoser | git stash create | 20:57 |
| smoser | the stash does not contain the new 'foo.txt' | 20:57 |
| smoser | oh wait. it does | 20:58 |
| blackboxsw | powersj: smoser https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333845 for the ci nightly errors | 21:00 |
| rharper | robjo: re v1 -> translate; I think at least for the immediate concern, matching the post-up "default gw" -> gateway: <value> ought to get that working | 21:01 |
| nacc | smoser: i'm still trying to understad why you want the tree up to now? for a git-archive call? | 21:01 |
| robjo | rharper: ? | 21:02 |
| rharper | robjo: by my reading it goes config-drive -> openstack helper convert_network_data_json to v1 config -> v1 config gets rendered to eni, then the eni content get's passed to your class which calls net_util.translate() | 21:02 |
| robjo | OK, then I am on a wild goose chase | 21:03 |
| rharper | yes, the https://bugzilla.opensuse.org/attachment.cgi?id=749026 | 21:04 |
| rharper | shows the 2017-11-16 15:26:39,868 - opensuse.py[DEBUG]: Translated ubuntu style network settings # Converted from network_config for distro <class 'cloudinit.distros.opensuse.Distro' | 21:04 |
| rharper | and then prints out the eni that got converted from v1 config | 21:04 |
| rharper | in distro base-class, it emits the Warning, thand then does a ns = network_state_parse_config(which is fed the v1 which was converted from the network-data json, you can see the v1 config earlyer in the log) | 21:05 |
| rharper | then in base distro, it does content = eni.network_state_to_eni() which makes an eni file; and passes that to the distro specify layer (self.apply_network() -> self._write_network()) | 21:06 |
| robjo | I am confused about where the openstack helper comes into play | 21:06 |
| rharper | converting the config drive network_data.json | 21:06 |
| rharper | when the Datasource is parsing it's input | 21:06 |
| rharper | robjo: cloud-init local runs to find the datasource, detects config-drive and runs the ConfigDrive datasource; in it, if there is a file network_data.json, it calls the helper to convert the json into v1 config and storages it in DataSource class property (network-config); then as cloud-init local continues, if the datasource has a 'network-config' property; it it's read and "rendered" | 21:10 |
| rharper | 2017-11-16 15:26:39,825 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'subnets': [{u'routes': [{u'netmask': u'0.0.0.0', u'network': u'0.0.0.0', u'gateway': u'192.168.168.1'}], u'netmask': u'255.255.255.0', u'type': 'static', 'ipv4': True, 'address': u'192.168.168.30'}], 'mac_address': u'fa:16:3e:ee:2b:97', u'type': 'physical', 'name': 'eth0', u'mtu': 1500}]} | 21:10 |
| rharper | there you can see stages applying the v1 config that it got from the configdrive data source (after the network_data.json conversion) | 21:10 |
| robjo | yes, that very early part I ignored and I started with that data and where I think it would end up in the code | 21:11 |
| nacc | smoser: sorry for being dense if i'm missing something obvious | 21:11 |
| robjo | and as I noted in comment #32 in the bug gateway information is missing from the renedered intermediate format | 21:12 |
| rharper | right, that;s due to hoe the eni is rendered | 21:14 |
| rharper | the gateway is inside the post-up route add default gw <gatewayip> | 21:14 |
| rharper | the net_util.translate does not know how to (yet) extract the gateway value from the eni contents | 21:14 |
| rharper | so, I believe in that net_util.translate, you can check if line has 'post-up' and 'default gw' strings | 21:15 |
| rharper | and extract out the ip addr in there and use that as the GATEWAY= value in sysconfig | 21:15 |
| rharper | you can see the v1 dictionary has 'gateway': 192.168.168.1 which matches the post-up line; post-up route add default gw 192.168.168.1 || true | 21:16 |
| robjo | OK I think I think I get how that part of the puzzle fits together | 21:18 |
| rharper | the network_data.json file may have other routes that are not default gateway ones, so there may be additional {pre,post}-{up,down} routes added which will also need converting to the sysconfig syntax; depending on how far you want to take the translator | 21:23 |
| robjo | well everything that is not "default gw" shoud really go into ifroute-IFACE | 21:26 |
| rharper | yes, I think so | 21:28 |
| rharper | we generally only had special handling for default gw, vs. route add -net | 21:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!