[02:55] <redcavalier> blackboxsw, good evening. I was wondering if you guys had managed to look into that bug I submitted last month.
[09:41] <cetex> smoser: Not sure if i said thanks for everything earlier: Thanks :)
=== shardy is now known as shardy_lunch
[15:59] <rharper> blackboxsw: urg, the c-i meeting is on top of our standup
[16:01] <blackboxsw> urg
[16:01] <smoser> o/
[16:01] <blackboxsw> \o
[16:01] <blackboxsw> it
[16:01] <rharper> o/
[16:01] <blackboxsw> it's that time again
[16:03] <blackboxsw> #startmeeting Cloud-init bi-weekly  status
[16:03] <meetingology> Meeting started Mon Nov 13 16:03:13 2017 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:03] <meetingology> Available commands: action commands idea info link nick
[16:03] <powersj> o/
[16:03] <blackboxsw> time change got to us
[16:04] <blackboxsw> #meetingtopic Recent Changes
[16:05] <blackboxsw> hey folks. thanks for joining just pulling together the content for the last couple weeks of work for the cloud-init project
[16:06] <smoser> http://paste.ubuntu.com/25954862/
[16:06] <smoser> $ git log a90a8b1cb3104ee3250ac79d6e25a9ff4f527baa.. | log2dch | sed 's,^    ,,' | pastebinit
[16:06] <blackboxsw> most of the ubuntu-side of the house was involved in handling the SRU of 17.1 into ubuntu and handling any discovered regressions
[16:06] <blackboxsw> Published cloud-init packages to Bionic Beaver release
[16:06] <blackboxsw> Update Gentoo Linux support to "rc-service" scripts as "service" is deprecated, thanks to ckonstanski!
[16:06] <blackboxsw> Detected and fixed a pre-release regression of resizefs when root path is specified by UUID on the kernel cmdline (LP: #1725067)
[16:06] <ubot5> Launchpad bug 1725067 in cloud-init (Ubuntu Zesty) "cloud-init resizefs fails when booting with root=PARTUUID=" [Medium,Fix committed] https://launchpad.net/bugs/1725067
[16:06] <blackboxsw> #link http://paste.ubuntu.com/25954862/
[16:07] <blackboxsw> #info SRU queued for release today
[16:07] <blackboxsw> Here's the cloud-init content we published for the last two weeks:
[16:07] <blackboxsw> #link https://github.com/canonical-server/dev-summary/blob/master/doc/2017-10-31.md
[16:07] <blackboxsw> #link https://github.com/canonical-server/dev-summary/blob/master/doc/2017-11-07.md
[16:09] <blackboxsw> last week we handled an EC2 behavior regression for xenial, whereby we didn't want to change cloud-init to configure all nics based on ec2 metadata, we will only configure the primary nice
[16:09] <blackboxsw> last week we handled an EC2 behavior regression for xenial, whereby we didn't want to change cloud-init to configure all nics based on ec2 metadata, we will only configure the primary NIC
[16:09] <blackboxsw> with those SRU regresssions fixed and published to master, we expect cloud-init 17.1 updated in Xenial,Zesty and Artful today
[16:10] <blackboxsw> #meetingtopic In-progress development
[16:10] <blackboxsw> smoser: rharper anything here?
[16:10] <smoser> #link http://bit.ly/ci-reviews
[16:11] <smoser> robjo has done a couple fixes for SuSE and i've pulled a few of them.
[16:11] <smoser> he has one up i saw yestderday for ntpSuSE
[16:11] <smoser> others ther.e we've been delinquent due to some distractions recently.
[16:11] <rharper> blackboxsw: nothing new for me at the moment
[16:12] <smoser> and chad had one up for clean and status
[16:12] <blackboxsw> btw thx robjo ckonstanski and Dave Mulford for the fixes over the last iteration. We also expect that a couple VMware branches for the OVF datasource will last this week or next
[16:12] <smoser> which is nice.
[16:13] <robjo> moving the meeting an hour foward while we are on Standard time or is this a one time occurance, did I miss an announcement?
[16:13] <blackboxsw> #meetingtopic Office Hours (next 30 minutes)
[16:14] <robjo> lp#1731619, chrony support, should that also be driven through ntp config or should there be a new config option?
[16:14] <blackboxsw> so we'll hang out with eyes on this channel for any burning questions/bugs/questions
[16:14] <smoser> robjo: well, the meeting is listed in UTC time
[16:14] <smoser> that pays no attention to US legislation to change clocks at random points in the year :)
[16:15] <robjo> oK, my fault when I added it to my calendar, eay enough to fix ;)
[16:15] <smoser> but the humans here were also affected :)
[16:15] <blackboxsw> heh, anyone opposed to shifting this meeting time +30 from now during the next few months?
[16:15] <blackboxsw> as the meeting now collides w/ another meeting for us
[16:15] <blackboxsw> :/
[16:16] <blackboxsw> officially 16:30 UTC?
[16:17] <robjo> Well, I'd prefer to either follow the "randomness" clock manipulation or not follow it
[16:19] <robjo> meaning don't change the meeting time because there exists a conflict when standard time switches to daylight savings or vice versa, becaus if you do that you might as well follow the silliness of the government to begin with
[16:19] <blackboxsw> fair point. ok let's keep the new time as is.
[16:20] <blackboxsw> we've discussed side-channel, we can shift our meetings out of the way of this
[16:20] <blackboxsw> so robjo +1
[16:20] <blackboxsw> 16:00 UTC
[16:24] <blackboxsw> also related to CI side, powersj and rharper spent quite a bit of time w/ our continuous integration infrastructure fixing/addressing memory & storage pressure issues to make sure we avoid intermittent false test failures due to timeouts or system resource contention
[16:24] <blackboxsw> #link https://jenkins.ubuntu.com/server/view/cloud-init/
[16:28] <via> is there a way to use metadata in the cloud-init file? specifically, if i want to use the aws-provided instance id in an attribute
[16:28] <robjo> OK, back to my question about chrony:  lp#1731619, chrony support, should that also be driven through ntp config or should there be a new config option?
[16:28] <via> like configuring the chef node name to have my instance id in it
[16:32] <blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bug/1731619
[16:32] <ubot5> Launchpad bug 1731619 in cloud-init "Support chrony as a client for ntp" [Undecided,New]
[16:33] <blackboxsw> it's a good bug, we've had a couple of discussions about ntpd versus timesyncd for different system environments
[16:34] <blackboxsw> current implementation of cc_ntp module is to return False ('ntp' not installable) on certain known environments where we know we want systemd timesyncd to run instead by default
[16:34] <smoser> via: i think what your asking is (i htink) covered in https://trello.com/c/AYaCdQyT
[16:35] <via> well, i'm trying to do it in a yaml cloud-config file
[16:35] <smoser> right. as it is right now, via you cann't reference anything from the metadata.
[16:35] <via> does that mean i need to use #jinja and if so how does that play with #cloud-config ?
[16:35] <via> oh
[16:35] <via> bummer
[16:36] <via> should i just switch to a shell script?
[16:36] <smoser> but we'd hope to implement that.
[16:36] <smoser> via: thats really the only way right now. and then in the shell scripty you'd have to query the metadata service yourself.
[16:36] <via> okay, damn
[16:36] <via> thanks
[16:36] <blackboxsw> robjo: we think that's a good approach/feature suggestion. We could add chrony template files etc like the ntp templates, and we might be able to have the distro report what time sync daemon it wants to run
[16:36] <smoser> basically... we realize what you're asking is quite helpful and reasonable but dont have a way to do it right now
[16:36] <smoser> but we do plan on implementing it.
[16:37] <via> no worries, i'm stuck on an ancient version anyway
[16:38] <robjo> blackboxsw: That was my thinking, move the "service_name" setting to the distro as "time_service_name" and then drive cc_ntp based on that
[16:39] <robjo> since with a third option the black/white decision being made today will no longer work
[16:39] <blackboxsw> +1 robjo yeah. rharper was chatting about this potential approach as well
[16:39] <robjo> look there is also grey ;)
[16:39] <blackboxsw> heh yeah
[16:40] <robjo> Next question.... network config.
[16:40] <blackboxsw> yeah might have to 'grow' an override option in cc_ntp module eventually
[16:41] <blackboxsw> as those grey use-cases come up (per bugs/requests ;) )
[16:41] <robjo> A long timi ago the RHEL implementation was re-written to use sysconfig renderer, but RHEL sysconfig and SLE sysconfig are different, why wouldn't they be
[16:42] <robjo> that also implies that the openSUSE/SLES implementation for network config rendering still uses the "old" implementation and thus produces a warning in the log file
[16:43]  * blackboxsw is looking for the warning generated
[16:43] <robjo> this would imply some refactoring is in order if we want to move openSUSE/SLES to using the newer API to render the network config
[16:44] <robjo> blackboxsw: "apply_network_config is not currently implemented "
[16:44] <robjo>                     "for distribution '%s'.  Attempting to use apply_network"
[16:45] <blackboxsw> ahh. right-o
[16:45] <robjo> the question from my point would be is, when I want to implement the SUSE bits am I also on the hook for the refactoring part or can I get some help with that? which of course will make my life easier ;)
[16:47] <robjo> And yes, I realize a bug will need to be filed, but I haven't figured out how to formulate this nicely
[16:47] <blackboxsw> robjo: I think we should be able to help out a bit with that refactor to make sure it's cleaner and easier to maintain.
[16:47] <robjo> OK :)
[16:50] <blackboxsw> there are a couplengeneric distro fixes which need to get designed (just like in the datasources) to make the common distro classes a bit easier to maintain as well as making classes a bit more modular and more easily tested.
[16:51] <blackboxsw> we still haven't landed some of the common datasource changes we had talked about during the Summit because we've been avoiding risk during the 17.1 release. But, similar/minor architecture changes should start taking shape here for datasources and distros now that we see a light at the end of the tunnel on the release.
[16:52] <blackboxsw> we'll keep our eyes open for discussions/suggestions from folks
[16:54] <robjo> Speaking of data sources, for the SUSE Container As A Service Platform, we implemented a data source to read from local disk, is that something that would be of interest upstream? Yes, this might seem silly but in our use case it makes perfect sense ;)
[16:56] <blackboxsw> robjo: I'm curious how different that datasource would be from nocloud datasource
[16:56] <blackboxsw> http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html?highlight=nocloud
[16:56] <blackboxsw> #link http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html?highlight=nocloud
[16:56] <blackboxsw> which allows for providing local data instead of dealing with metadata
[16:56] <blackboxsw> well network metadata
[16:57] <robjo> I wasn't really involved, just accepted the patch to the package and have not done a comparison to nocloud, but I'll take a look
[17:00] <blackboxsw> good deal.... think we are at the top of the hour... so I'll probably end meeting now
[17:01] <blackboxsw> thanks via robjo rharper powersj & smoser. next meeting 2 weeks same early time
[17:01] <blackboxsw> #endmeeting
[17:01] <meetingology> Meeting ended Mon Nov 13 17:01:43 2017 UTC.
[17:01] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2017/cloud-init.2017-11-13-16.03.moin.txt
[17:01] <powersj> thanks blackboxsw for running
=== 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 11/13 16:00 UTC | cloud-init 17.1 released
[17:02] <blackboxsw> np
[17:04] <via> smoser: will $(cloud-init query instance-id) work in said shell? it doesn't seem to evaluate
[17:05] <smoser> via: no. cloud-init query doesn't really exist.
[17:05] <smoser> :-(
[17:05] <smoser> the goal is to have a good solution for you
[17:05] <smoser> but there is not one at the time :-(
[17:05] <via> so wait, there is actually no way to use cloud-init at all to get my instance id?
[17:06] <via> i have to query the aws 169 address with curl or whatever?
[17:08] <ajorg> via: if you don't mind hackiness you could resolve the /var/lib/cloud/instance symlink
[17:08] <via> ok
[17:08] <ajorg> instance_id=$(basename $(readlink -f /var/lib/cloud/instance))
[17:09] <ajorg> (assuming 0.7+)
[17:09] <ajorg> you mentioned you might be using something much older
[17:09] <via> looks like ec2metadata is installed by default
[17:10] <blackboxsw> via theres something in progress that will help    https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115
[17:10] <blackboxsw> I'm hoping we can land this soon. it'll put a /run/cloud-init/instance-data.json blob thatt will report that for you
[17:11] <via> well, tbf, if ec2metadata is installed, i dunno why i'd use anything but it
[17:11] <via> i didn't realizeit was
[17:11] <blackboxsw> and we'd support it as a public interface that folks can consume
[17:13] <blackboxsw> that branch referenced is the precursor to cloud-init query subcommand
[17:13] <blackboxsw> precursor/prerequisite
[17:21]  * ajorg changes his calendar entry for the meeting to UTC...
[17:23] <blackboxsw> thanks ajorg. then it can surprise us again in spring
[17:23] <ajorg> haha
[17:25] <ajorg> smoser: https://code.launchpad.net/~ajorgens/cloud-init/+git/cloud-init/+merge/331660 < this is okay to merge? or did you have other concerns?
[17:27] <smoser> ajorg: i'll look now.
[17:27] <ajorg> thanks
[17:27] <ajorg> I blame Ben Franklin for the meetings I've missed.
[17:28] <blackboxsw> you should stop hanging out with that guy ajorg, he's a bad influence
[17:28] <ajorg> totally. the guy likes to fly kites in the rain
[17:28] <blackboxsw> ... ok I'm back, wrapping up review comments on the cloud-init clean/status branch
[17:29] <blackboxsw> thx smoser for the review, yeah I had pulled out cloud-init status disabled as I had wanted to chat w/ you about all the ways it could be 'disabled'
[17:30] <blackboxsw> rharper: smoser if ds-identify 'disables' cloud-init, we just expect /etc/cloud/cloud.cfg.d/90_dpkg.cfg to have an empty datasource list?
[17:33] <blackboxsw> rharper: per your inotify comment, I tried not depending on python inotify libs as they aren't currently pulled in by cloud-init as a dependency. Shall we add that as a pkg dependency?
[17:34] <rharper> no, /run/cloud-init/cloud.cfg will be empty
[17:34] <blackboxsw> ahh ok rharper thx
[17:34] <rharper> cloud-init reads the cloud.cfg that ds-identify writes
[17:35] <smoser> blackboxsw: no. ds-identify exits wihtout putting the target in systemd's goals
[17:37] <rharper> blackboxsw: bummer on not having inotify tools;
[17:41] <blackboxsw> yeah even the base-pkg inotify-tools !present yet.
[17:48] <rharper> I saw a python syscall binding "inotify-basic" package
[17:48] <rharper> but it would be nice to just have that built-in
[18:12] <smoser> rharper: blackboxsw fyi there are cloud-images for bionic now
[18:26] <smoser> rharper: do you know why we get an ipv6 address in lxc on artful ?
[18:26] <smoser> that seems wrong
[18:40] <rharper> your lxd config enabled ipv6 dhcp
[18:41] <rharper> --dhcp-range fd42:3cd1:a543:bb7::2,fd42:3cd1:a543:bb7:ffff:ffff:ffff:ffff,1h
[18:41] <rharper> smoser: ^^
[18:47] <smoser> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732002
[18:47] <ubot5> Launchpad bug 1732002 in systemd (Ubuntu) "cloud images in lxc get ipv6 address" [Undecided,New]
[18:47] <smoser> rharper: its a bug. they should not. they did not request it.
[18:47] <rharper> doesnt ipv6 ra get you that ?
[18:48] <smoser> xenial doesnt get it
[18:48] <rharper> doesn't run networkd
[18:48] <rharper> networkd does ipv6 ra by default
[18:48] <smoser> that is a bug
[18:48] <rharper> https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1717404
[18:48] <ubot5> Launchpad bug 1717404 in nplan (Ubuntu Zesty) "IPv6 support regresses with nplan transition" [Undecided,Fix committed]
[18:49] <rharper> https://bugs.launchpad.net/maas/+bug/1655440
[18:49] <rharper> all seem related
[18:49] <ubot5> Error: Could not gather data from Launchpad for bug #1655440 (https://launchpad.net/bugs/1655440). The error has been logged
[18:50] <smoser> rharper: so 1655440 may imply that cloud-init needs to write 'accept-ra: no'
[18:50] <smoser> ?
[18:51] <rharper> I think 1) they do request it, the kernel has ipv6 enabled, which means it does RA  2) dnsmasq for lxd, can be configured to disable ipv6; your host does not have it disabled ;  if there is a bug it's related to dhclient6 not running by default in xenial
[18:51] <smoser> no.
[18:51] <rharper> it's hard to say where it should be written
[18:51] <smoser> lxd and cloud-init config specifically say (via omission) not to have ipv6
[18:52] <rharper> that's unclear
[18:52] <smoser> so behavior that just enablels an ipv6 is wrong.
[18:52] <rharper> look at the lxd bug that stgraber filed
[18:52] <rharper> if you don't want ipv6, you have to pass kernel config
[18:52] <rharper> it's certainly a change in behavior from xenial; I think that needs some discussion w.r.t what that means for artful/bionic
[18:54] <smoser> stgraber's comment does not hmake sense.
[18:54] <smoser> "ever since the switch to nplan by default in Ubuntu, we're not getting an IPv6 address anymore when a RA reaches the container.
[18:54] <smoser> "
[18:54] <smoser> as if we *were* getting ipv6 address by default previously
[18:54] <smoser> but we are not
[18:55] <rharper> IPv6AcceptRA=no
[18:55] <rharper> nplan was disabling IPV6RA by default
[18:55] <rharper> it's no longer doing that
[18:55] <rharper> and you have ipv6 enabled on dnsmasq
[18:55] <rharper> so you're now getting ipv6 addrs in your containers
[18:56] <rharper> https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1717404/comments/3 ;  m-h-d suggests a 3 way switch in the config; but someone is going to be unhappy;  this needs discussion AFAICT
[18:56] <ubot5> Launchpad bug 1717404 in nplan (Ubuntu Zesty) "IPv6 support regresses with nplan transition" [Undecided,Fix committed]
[19:02] <smoser> rharper: im' missing something
[19:02] <smoser> but i just made cloud-init render
[19:03] <rharper> I suspect that we likely didn't have a dnsmasq that was ipv6 enabled, which means there were not IPV6 RAs going to our containers;
[19:03] <smoser> http://paste.ubuntu.com/25955872/
[19:03] <smoser> and rebooted
[19:03] <smoser> and i still have the ipv6
[19:03] <rharper> look at /etc/default/lxd-bridge.upgraded which shows we've got ipv6 enabled
[19:03] <smoser> rharper: no. i had in the past explicilty enabled dnsmasq for ipv6
[19:03] <smoser> (and i think lxc did that by default)
[19:03] <rharper> it does by default
[19:04] <smoser> i dnot follow.
[19:04] <rharper> what does your /run/systemd/network-* files look like ?
[19:04] <rharper> netplan *used* to disable ipv6
[19:04] <rharper> so even if you had ipv6 for lxd enabled, it never worked
[19:04] <rharper> ifyou used netplan
[19:04] <rharper> they filed a bug to get netplan to not disable RA by default
[19:04] <smoser> that is bad.
[19:05] <smoser> its worse to open people to attack that were not expecting it
[19:05] <rharper> it's complicated depending on who wants what "default" behavior
[19:05] <rharper> you mean having your kernel enable ipv6 by default ?
[19:07] <cyphermox> you have an accept-ra option in netplan if you really want avoid getting RAs.
[19:07] <smoser> ok. so maybe that is "complicated" and i somehat agree with m-h-d =.
[19:07] <smoser> but in my newly updated cloud-init i just rendered
[19:08] <rharper> please check the run dir to see what got generated
[19:08] <smoser> http://paste.ubuntu.com/25955901/
[19:09] <rharper> no
[19:09] <cyphermox> accept-ra is per-interface.
[19:09] <smoser> http://paste.ubuntu.com/25955908/
[19:09] <rharper> in any case, cat /run/systemd/network/10-netplan*
[19:09] <smoser> ok. let me try
[19:09] <rharper> cyphermox: should it fail to parse on that  ?
[19:10] <rharper> configs present under tree that doesnt' parse them ?
[19:10] <cyphermox> rharper: I fail to parse your question
[19:10] <rharper> you said he put it in the wrong spot
[19:10] <rharper> should be under eth0:
[19:10] <rharper> and I'm saying should that fail to parse with the value in the wrong spot
[19:10] <cyphermox> yep
[19:11] <cyphermox> if it didn't fail, that's a bug
[19:11] <rharper> yes
[19:11] <rharper> agreed
[19:11] <smoser> it did not complain.
[19:11] <smoser> so you can consider that a bug.
[19:11] <cyphermox> but I'm a little surprised, netplan usually is failing to parse pretty aggressively
[19:11] <rharper> indeed
[19:11] <smoser> and putting it in the right place does get the behavior i expected.
[19:12] <smoser> so my feeling is that cloud-init should render 'accept-ra': no unless there is a dhcp6 stanza
[19:12] <smoser> but this still imo seems broken
[19:13] <rharper> s/cloud-init/netplan; and that's one of the discussion points;  I'm not sure we've reached consensus w.r.t the "right default";
[19:13] <rharper> so in your lxd case were it has a dhcp6 enabled subnet; then should lxd emit DHCP6 config in addition to the v4 dhcp ?
[19:13] <smoser> lxd should, yes.
[19:14] <rharper> I suspect stragber has an opinion to that
[19:14] <rharper> which is counter to what you're suggesting; hence the bug
[19:14] <cyphermox> rharper: smoser: if I put your config on my system and run 'netplan generate', it does fail to parse
[19:15] <smoser> network config should be deterministic
[19:15] <rharper> what version of netplan is in your image ?
[19:15] <rharper> smoser: ^
[19:15] <cyphermox> smoser: except you may really want to no do DHCP for an IPv6 network and do SLAAC, which needs the RAs.
[19:15] <smoser> not "well, you'll get config if someon (nefarious or not) was sending packets on your network)
[19:15] <rharper> smoser: you're arguing with the wrong person; I suggest a comment in the lxd/nplan bug if you want to strike up a discussion
[19:15] <smoser> netplan is bionic image today
[19:16] <cyphermox> smoser: ergo, disabling RAs in MAAS might be what you want, since MAAS does DHCPv6 and is supposed to manage all, but it's very not the right default elsewhere.
[19:17] <smoser> an oracle (lxd or maas) should declare.
[19:18] <rharper> I think 0.30 doesn't have the accept-ra parsing
[19:19] <cyphermox> rharper: it does, it's added in 0.28
[19:19] <rharper> huh
[19:20] <rharper> I see an error when I run generate as well; smoser do you have the cloud-init.log ?
[19:20] <smoser> rharper: bionic does work if we make cloud-init interpret no 'dhcp6' as 'accept-ra: no'
[19:20] <smoser> which i think we should
[19:20] <smoser> oh. yes. we do get a 'generate' error
[19:21] <rharper> wonder how network came up ?
[19:21] <rharper> or did it ?
[19:21] <rharper> the /run/systemd/network/ file shouldn't have been written
[19:21] <smoser> no it didnt
[19:21] <rharper> which means no networking
[19:21] <smoser> yeah.
[19:21] <rharper> oh, ok
[19:21] <smoser> fail.
[19:21] <smoser>  just looked at the ipv6
[19:21] <smoser> and saw nothing
[19:21] <smoser> so that seemeed right
[19:21] <rharper> hehe
[19:21] <rharper> ok
[19:26] <smoser> http://paste.ubuntu.com/25955976/
[19:26] <smoser> cyphermox: ^ that is what you were saying should work right ?
[19:27] <cyphermox> no
[19:27] <smoser> hows this for confusing
[19:27] <smoser> $ python3 -c 'import yaml; print(yaml.load("false") is yaml.load("no"))'
[19:27] <cyphermox> accept-ra is per-interface, it should be under eth0
[19:27] <smoser> True
[19:27] <cyphermox> how is that confusing?
[19:28] <cyphermox> you're asking python if a boolean is X for a language with a pretty loose grammar, not unlike javascript
[19:29] <smoser> javascript has a much more strict gramar.
[19:30] <smoser> its confusing that 'no' is interperted as a boolean.
[19:30] <smoser> the lack of quoting requirements in yaml makes it wierd
[19:49] <rharper> the netplan parser does some additional string -> boolean conversion IIRC
[19:51] <rharper> true == on == yes == y;  false == off == no == n ; for fields which are designated boolean : accept-ra uses the handle_netdef_bool which does the conversion
=== natorious_ is now known as natorious
=== boxrick_ is now known as boxrick
[22:46] <blackboxsw> rharper: smoser addressed most comments on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333513. I
[22:48] <rharper> blackboxsw: cool
[22:48] <blackboxsw> am not quite sure what we should do about standardizing config paths etc. Right now, it feels a bit painful the way content is organized in /etc/cloud/cloud.cfg.d/05_logging.cfg and cloudinit.helpers.Paths and various cmd files. I think we may need to look over a way to centralize more of these config defitinitions in an official config file that can be sourced by other modules
[22:49] <blackboxsw> s/defitinitions/definitions
[22:50] <dpb1> blackboxsw: is that to help with schema?
[22:50] <blackboxsw> dpb1: nope just to help with cloudinit modules knowing where the proper log_file_path or run_dir is etc.
[22:50] <dpb1> k
[22:51] <blackboxsw> there's a bit of  hardcoding of strings and some duplication that I've introduced that'd be nice to bring together in one place
[22:51] <blackboxsw> hardcoding paths
[22:51] <dpb1> I was just looking over your branch, makes sense now
[22:52] <rharper> well, there is the confg paths; which consumes the system config into an object
[22:52] <rharper> so I suspect we'll need to use the stage wrappers to ask for path to various keys
[22:52] <rharper> which allows the system config to override
[22:53] <blackboxsw> yeah, it feels like the Init() -> Init.read_cfg() -> cfg object is almost the right place. it just doesn't feel 'accessible' or parameterized quite enough
[22:54] <blackboxsw> it feels like it's still a beast of an object to tear apart into the component you want to look at (as it still contains unparsed  yaml strings as the attributes)
[22:54] <blackboxsw> or maybe I've just dug into the wrong hole on it
[22:57] <rharper> oh, that's completely fair
[22:58] <rharper> blackboxsw: I think you want the init object paths properties
[22:59] <rharper> which gives you the cloudinit/helpers.py:Paths() object
[22:59] <rharper> that has alot of the methods that combine the system config with "standard" paths (like instance_link,  run_dir, etc)
[23:25] <blackboxsw> yeah, though it doesn't seem to surface log paths.
[23:25] <blackboxsw> maybe we need to extend Paths to be our source of truth... no quite sure
[23:26] <rharper> that sounds reasonable (extending paths)