/srv/irclogs.ubuntu.com/2017/12/11/#cloud-init.txt

smosero/16:00
blackboxsw\016:00
smoserhey everywon16:00
powersjo/16:01
blackboxswalright time, just about time for our holiday status meeting16:02
blackboxswand time for less thinkos at the keyboard16:02
ajorghi16:02
rharpero/16:03
blackboxswexcellent16:04
blackboxswlooks like we have folks around16:05
blackboxsw#startmeeting Cloud-init 'bi-weekly' status meeting16:05
meetingologyMeeting started Mon Dec 11 16:05:16 2017 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.16:05
meetingologyAvailable commands: action commands idea info link nick16:05
smoserthanks for hosting blackboxsw16:05
blackboxswno problemo.16:05
blackboxswhappy holidays folks and thanks for joining.16:05
blackboxsw#topic In-progress Development16:07
blackboxswAs mentioned @ our 17.1 release, we're promising more frequent cloud-init releases.16:07
blackboxswsmoser has mailed the list informing cloud-init interested parties that we are targeting a 17.2 release for Thursday this week16:08
blackboxswIt's been a few weeks since we've hosted the meeting (I think we missed last meeting), so I'll post some of the development that has landed in trunk16:08
smoser#link https://lists.launchpad.net/cloud-init/msg00114.html16:08
blackboxsw* All integration tests now function with the nocloud-kvm backend16:09
blackboxsw* Fix apport for cloud-name options (LP: #1722564)16:09
blackboxsw* Improve warning message when templates aren't found (Robert Schweikert) (LP: #1730135)16:09
blackboxsw* Perform null checks for enabled/disabled Red Hat repos (Dave Mulford)16:09
blackboxsw* Fix openSUSE and SLES setup of /etc/hosts (Robert Schweikert) (LP: #1731022)16:09
blackboxsw* Catch UrlError when #include'ing URLs (Andrew Jorgensen)16:09
ubot5Launchpad bug 1722564 in Apport "apport question will not accept multi-character responses" [Undecided,Confirmed] https://launchpad.net/bugs/172256416:09
ubot5Launchpad bug 1730135 in openstack-dev-sandbox ""Too much rain in Sydney"" [Undecided,New] https://launchpad.net/bugs/173013516:09
ubot5Launchpad bug 1731022 in cloud-init "host template expansion does not work on SUSE distros" [High,Fix committed] https://launchpad.net/bugs/173102216:09
smoserajorg replied with a request for https://code.launchpad.net/~ajorgens/cloud-init/+git/cloud-init/+merge/32965716:09
smoserthat fell on deaf ears16:09
blackboxsw* Released stable release update (SRU) of 17.1-27-geb292c18 (LP: #1721847)16:09
blackboxsw* Cleanup dhclient background process after EC2 network discovery.16:09
blackboxsw* ntp: fix configuration template rendering for openSUSE and SLES (Robert Schweikert) LP: #172657216:09
blackboxsw* fix manually running cloud-init after upgrade (LP: #1732917)16:09
ubot5Launchpad bug 1721847 in cloud-init (Ubuntu Artful) "sru cloud-init 2017-10-06 (17.1-18-gd4f70470-0ubuntu1) updated to (17.1-27-geb292c18)" [Medium,Fix released] https://launchpad.net/bugs/172184716:09
ubot5Launchpad bug 1726572 in cloud-init "ntp config handling inconsistent for SLES and openSUSE" [Medium,Fix committed] https://launchpad.net/bugs/172657216:09
ubot5Launchpad bug 1732917 in cloud-init "17.1 update breaks EC2 nodes" [High,Fix committed] https://launchpad.net/bugs/173291716:09
ajorgtruth16:09
smoserajorg: i will review shortly16:09
blackboxsw* Queued upstream for merge into Bionic16:09
blackboxsw* Queued 17.1.46 SRU for Xenial, Zesty, and Artful16:09
blackboxsw* Fix EC2 race on sandboxed dhclient's pidfile during tempdir teardown (LP: #1735331)16:09
blackboxsw* Enable Bionic in Integration Tests16:09
blackboxsw* Create LXD and KVM Integration Tests in Jenkins16:09
ubot5Launchpad bug 1735331 in cloud-init "ec2: zesty tempfile sandbox dhclient.pid file can't be created" [High,Fix committed] https://launchpad.net/bugs/173533116:09
blackboxswAs of end of last week, we are trying to blitz the review queue and dust off anything that has been sitting too long16:10
blackboxswSo a couple fixes went into Amazon's initial network setup, IPv6 support is live for Ubuntu series Xenial, Zesty, Artful and Bionic16:12
ajorgcool16:13
blackboxswheh I blew that last topic. it should have been #topic Recent Changes.16:14
blackboxswanyway I'll fix it in the logs when I publish16:14
blackboxswAs always , for historical docs from this meeting check this link16:15
blackboxsw#link http://cloud-init.github.io16:15
blackboxsw#topic In-progress Development (for real)16:15
blackboxswSo we have an active queue that is pretty healthy still16:15
blackboxsw#link http://bit.ly/ci-reviews16:15
blackboxswsmoser: rharper are we still trying to get through that queue as best we can for 17.2 or when do we think the window closes there?16:16
smoseri think we can spend some more time on queue today.16:16
smoserbut that is about it really.16:16
blackboxswyeah, want some settle 'bake' time before the 17.2 cut on Thursday16:16
blackboxswWe saw a couple Azure branches come in late last week.... Are there any branches folks are really excited about landing this week (today tomorrow?)16:17
blackboxswI had hoped to get through a couple of Robert's as they don't seem very contentious.16:18
smoserthe reporter bit seems pretty reasonable16:19
smoserother than its not actually used anywhere in the mp16:19
smoserie, its non-contentious to add a reporter, but adding code that is not used is of not a lot of use :)16:19
blackboxswtrue16:19
ajorgwhich mp is being discussed?16:20
smoser(https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/334989)16:20
blackboxsw#link https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/33498916:20
ajorgthanks16:21
blackboxswWith the upcoming holidays I expect things will be pretty slow after mid-next week, so we won't likely be landing a lot before the first of the new year.16:23
robjoIf it's slow for you more time to review open merge proposals ;)16:25
blackboxswThis week we are also trying to get an SRU into ubuntu xenial, zesty and artful for some VMware/OVF datasource fixes for ds-identify and for pre-cusomization marker files courtesty (smoser & maitriyee)16:25
blackboxsw*courtesy* rather16:26
smoserajorg: you could ping matthew on https://code.launchpad.net/~yeazelm/cloud-init/+git/cloud-init/+merge/33189716:26
ajorgyup16:27
blackboxswand I know powersj is working on EC2 integration test support for cloud-init16:27
powersjyep!16:27
powersjHoping to have an initial MP up this week16:27
blackboxswit's gonna be excellent to automatically test these releases16:27
blackboxswpowersj: rharper smoser anything else in progress?16:28
rharpernothing here16:28
ajorgoh very nice.16:28
dpb1powersj: \o/16:28
smoserjust the things that are in teh review queue. i put up one this morning for tmp file leakage16:28
smoserhttps://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/33503416:28
smoseri think the yeazelm mp probably is just missing somethign simple bug haven't spent any time on it.16:29
blackboxswahh also we landed the initial /run/cloud-init/instance-data.json which we had talked about with larsks. It captures all metadata and userdata and some standardized properties which could help people script instance data.16:29
smoseryeah, that is neat.16:29
blackboxswYeah, we have yet to write up docs on using it (and we have an inprogress branch to allow using jinja templates in #cloud-config modules). But I don't expect this to land by 17.216:30
ajorgdid we? that's great!16:31
blackboxswyeah only basic standardized properties currently.  +            'local-hostname': self.get_hostname(),16:32
blackboxsw592+            'instance-id': self.get_instance_id(),16:32
blackboxsw593+            'cloud-name': self.cloud_name,16:32
blackboxsw594+            'region': self.region,16:32
blackboxsw595+            'availability-zone': self.availability_zone}}16:32
robjois that basically a re-implementation of python-ec2metadata? https://github.com/SUSE/Enceladus/tree/master/ec2utils/ec2metadata16:32
blackboxswbut it's a first pass. We expect to add more16:32
blackboxswrobjo: kindof, though generalized for all datasources16:33
rharperrobjo: long term, it's expected to be more than just ec2; rather a common baseline of instance metadata independent the actual cloud, but , IIRC, having a cloud-specific area (or at least access to the raw data)16:34
blackboxswit leaves a json-foramatted file containing any vendor data and user-data plus generalized/standardized fields extracted from that content which can be expected on all clouds16:34
robjoproblem with "all" clouds is that Azure is very different16:35
blackboxswsince each datasource has that data already, it's essentially just formating it in a consumable file that others could levereage16:35
robjoalthough one can argue that a "name" is an id it still looks weird when 'instance-id' and is a name16:35
blackboxswagreed robjo, some datasources may not provide different/less  content.16:36
smoserajorg: http://paste.ubuntu.com/26164503/16:36
ajorgIs that one of the Azure differences? name vs. instance-id?16:36
smoserthats a demo of instance-data.json16:36
robjoyes, azure has names no numbers16:36
robjoit's more about "user expectations" as a "name" is an "identifier"16:37
blackboxswI'll check that azure run now. I think I linked it to the branch originally16:37
blackboxswok I think it's probably a good to transition to open office hours now for the next 30 mins16:37
smoserwhat is 'name' versus 'instance-id' comment ?16:38
smoserajorg: ?16:38
blackboxsw#topic Office Hours (for next 30 mins)16:38
blackboxswfeel free to continue the discussion now16:38
robjoI'd just caution of making the assumption that we can stick the information from that data sources straight into another format and then call it "generic instance information"16:38
ajorgsmoser: re robjo's comment about "Azure is very different"16:38
smoseroh. yes. ok.16:39
blackboxswazure instance-data16:39
blackboxsw#link http://pastebin.ubuntu.com/26075842/16:39
dpb1smoser: standup16:39
smoseryeah, they do have a 'id'16:39
blackboxsw#link http://paste.ubuntu.com/26164503/16:40
ajorgfrom DMI?16:40
robjoWhich is useless in any any command16:40
smoserfrom the cd i think.16:40
ajorgrobjo: ah, so the ID is unique (is it?) but can't be used to call any Azure APIs?16:41
robjoin EC2 the instance-id is useful to me if I want to run "aws" commands, but the instance ID shown in the pastebin is useless for any "az" command16:41
robjoajorg: correct16:41
robjoin the "az" tools everything is a name16:41
robjoand thus to make the data cloud-init produces useful the -id should be the name of the VM16:42
robjothen I can parse that information and use it if I need to deal with the API16:42
smoserhm.16:43
robjobut providing that ID as its is basically just sticking information into the json to "fill a field" which is somewhat counter to the point I'd say16:43
ajorgrobjo: there's a uniqueness constraint on the name too? but per-account or at-a-time or what?16:43
smoseri odnt knwo. although it is insteresting thought.16:43
smoserthe issue is 'instance-id' is supposed to be an instance id16:43
smosernot a user provided name that can be provided mutliple times in a row.16:43
smoseri realize name is per-group unique, but if i16:44
smoser a.) launch16:44
smoser a.) launch 'foobar'16:44
robjoThere is a uniqueness constraint in that one cannot run a VM with the same "name" in the same resource group16:44
ajorgso the question is if that ID provides global uniqueness, or if it provides a reference to the instance to be used via APIs16:44
smoser b.) create capture16:44
smoser c.) delete foobar16:44
smoser d.) launch foobar16:44
smoserthen 'd' wont look new16:44
robjoyes, it will it just takes a long time in Azure until the backend reaches "eventual" consistency and knows "foorbar" has been deleted previously16:45
ajorgIt seems clear enough that cloud-init is looking for a unique ID16:45
ajorgBut a user might want either, and probably an ID for API use.16:45
robjoWell if we provide a format of the data that is exposed to the user via documentation and expected to be used by the user than at that point, IMHO, user needs have higher priority than what cloud-init is looking for16:47
ajorgTo decide which APIs to use, a script has to first look at which cloud it's on, so it has a chance to decide which value to use.16:47
robjothat cloud-init uses the id to make decisions about "pre-once", "per-always" is a different topic16:47
robjoWell that then kind of defeats the "generic instance information" claim, IMHO16:49
robjoyou are basically saying 1.) look for the framework and then decide if on that framework the "generic instance information" is useful or not16:49
robjo2.) If you happen to be on a platform where the "generic instance information" is not useful, go and collect your own16:50
robjoFrom a user perspective that is not very nice, IMHO16:50
ajorgoh, I was presuming we'd also include the Azure name, not that we'd include only a useless instance-id in that case.16:51
ajorgclouds that don't have a name, wouldn't include a value for it.16:51
robjothe pastebin only has the ID16:52
ajorgright, I'm saying we should add the name16:52
robjoThis is why I am pointing out that "generic instance information" is not necessarily so easy to come by16:53
blackboxswrobjo: ultimately, I'd like the generalized content surfaced in instance-data.json to be something that external user's could get value from and script against. This first pass was a stripped down approach to some of that content.16:54
smoserwe could add 'name' and have it be none yes.16:54
smoserthe not-yet-written doc will state that consumers should not be confused by new field names.16:55
blackboxswThere are some fixes that need to be proposed to all datasources to better standardize on things like  public vs private addresses, external hostnames etc. Those I expect will come in subsequent passes.16:55
robjoit might be worth considering the concept of "equivalent instance information" where the entries in the json files get names/keys that are generic across all cloud frameworks and provide the euivalent information/usefulness to the user16:55
smoserbut inside the 'v1', then content of a key will not change.16:55
ajorgrobjo: that's a fair point, imho16:55
smoserbut 'instance-id' is in fact 'instance-id'.  not 'name'.16:55
blackboxswrobjo: I think that is the intent of those 'v1' standardized fields.16:55
smosernote that lxd shares the same generic problem in this regard as azure. it uses user-provided name for instance-id. but does not provide an actual instance id of any sort.16:56
blackboxswright per name/instance-id discussion, they feel separate, and I think there is value in adding a separate 'name' as smoser mentioned16:56
robjoLets look at it from an API perspective, if I were to use the .json file wouldn't it be nice if I could just say  json.load().get{'instance_api_id')16:58
robjofor EC2 that returns the instance-id, for Azure it gives me the name16:58
robjopart of the idea of cloud-init is to keep the ugly details of the cloud framework away from the user16:59
ajorgif we were talking about the value of "region" we'd certainly want to yield the value that's useful for API calls.16:59
robjoso why would the .json data then retrieve from that idea and make the user know if I am in EC2 I need to use instance-id and if I am in Azure I need to use instance-name?17:00
robjoajorg: agreed17:01
smoserit seems somewhat non-sense that azure gives an instance a unique id, but cannot take that in as an identifier to the instance.17:01
robjoAWS, GCE, and Azure all have the concept of "region" , not certain how IBM is handling that part in their setup but that may not be of interest to us at this point17:02
smoseryour point is good though. but instance-id i really think needs to be a unique identifier (as much as possible) for this *instance*17:02
ajorgIt sounded like smoser's 'v1' comment was meant to imply we could have a 'v2' that yields data differently than 'v1'.17:02
smosersoftlayer has "datacenters"17:02
robjosmoser: I agree, but that's the way it is17:03
smoserat some point, ajorg we will of course realize that we're all idiots17:03
smoserand wonder What were we thinking!17:03
smoserand have a 'v2'17:03
blackboxsw<-- it takes some of us longer than others to realize that17:04
ajorgsmoser: you're not convinced that today is that day?17:05
smoseri try to keep acknowledgement of that fact to be more than a few days later17:05
ajorggood to let it sink in first :-)17:06
smoser(compared to when i notice it, to allow for additional occurences)17:06
ajorgI'm not going to say it has to be changed, but I do think at the very least the azure name should be available.17:06
blackboxswI think this discussion definitely sheds light on the fact that we should continue to bring these standardized instance-data discussions to this meeting for a quick feedback loop from you guys as it evolves :)17:07
ajorg:)17:07
blackboxsw#action blackboxsw bring up any updates in instance-data.json fields for discussion about common use-cases/patterns17:08
meetingologyACTION: blackboxsw bring up any updates in instance-data.json fields for discussion about common use-cases/patterns17:08
ajorgand it doesn't seem harmful to have the name only if the cloud provides one, just as if the cloud doesn't have a concept of an availability zone we'll skip that too.17:08
blackboxsw+117:09
blackboxswwell i think this about wraps up our meeting for today17:10
blackboxswany other topics for today?17:10
ajorgI pinged Matt Yeazel, but he didn't respond yet.17:11
smoseri think 'api-id' would lmake sense as a name.17:11
ajorgso nothing more from my end17:11
ajorgsmoser: or 'api-instance-id'17:11
smoserthat just seems confusing.17:12
smoserhm..17:12
smoseri see why you want the 'instance' portion there, but the thing i dont like is that implies that this is 'per instance'17:12
ajorgwell, it's an API instance identifier.17:12
smoserwhich in fact it is not.17:13
smoserhm.17:13
ajorgAh, okay, that's true, but if the cloud doesn't have a unique way to identify the instance to the API...17:13
smoseryeah17:13
ajorgsomeone should check that assumption... how do you refer to terminated instances? or how are they identified in logs?17:14
ajorgsmoser: I just worry that someone's going to say "but in my API an API ID is this other thing"17:16
blackboxswyeah before surfacing something like that we'd need to vet it17:17
ajorgIn general I think there are enough differences between clouds that it's probably a losing battle to try to come up with something that's one-size-fits-all.17:17
ajorgThe goal was to make the information available more readily than by calling out to metadata services, right?17:17
ajorgIt's much harder to implement meta-data pulling for every cloud than to implement some logic that pulls the right value out of a JSON object, so it's still a big improvement even if it can't provide a unified view.17:18
ajorganywho, I should go do other things.17:21
blackboxswajorg: yes that is the primary goal:  more easily access cloud-provided metadata17:21
blackboxswif there is low-hanging fruit we can standardize I'm +1 on the concept17:21
blackboxswthat's where the standard 'v1' key came from17:22
blackboxswbut yeah I also don't think cloud-init needs to boil the ocean and standardize all fields17:22
blackboxswwe'll capture what low-hanging fruit we can17:22
blackboxswand it'll take time17:22
blackboxswok. Thanks for the great discusssions/suggestions ajorg and robjo. keep 'em coming17:22
blackboxswthink I'll end meeting now17:22
blackboxswuntil next time...17:22
blackboxsw#endmeeting17:22
meetingologyMeeting ended Mon Dec 11 17:22:56 2017 UTC.17:22
meetingologyMinutes:        http://ubottu.com/meetingology/logs/cloud-init/2017/cloud-init.2017-12-11-16.05.moin.txt17:22
rharperblackboxsw: thanks!17:24
paulmeyoh wow... I'm sorry I missed that meeting. Sounds like my cloud was the subject for some of it... ;-)17:31
smoseryeah, you're trouble17:33
smoser:)17:33
blackboxswno cookie for you17:33
smoserthe disucssion was inteersting withregard to instance-id and name though17:33
paulmeyyeah and the use of them...17:33
paulmeyit's a nice chicken/egg discussion anyway, because the usability won't be clear until you've built the (wrong) thing...17:36
paulmeyre https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/33498917:36
paulmeyanything you need from me?17:38
blackboxswnothing at the moment, but we'll probably assign a review to you regarding instance-data when I start working instance-data standardization again.17:40
paulmeysounds good17:50
paulmeyhttps://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service#instance-metadata-data-categories has a list of the metadata that is currently there...17:50
paulmeyI assume the discussion above was about the vmId (which also comes through DMI) vs resource-group/resource-name?17:51
smoseryeah17:51
paulmeyI'm guessing *all the other clouds* just have one id that they use everywhere in the API's and then some way to look that id up in a more human-friendly way?17:52
blackboxswa bold statement :)17:54
paulmeynot a statement, I'm asking... hence the question mark... :-)17:55
blackboxswpaulmey: it's hard to say if that's the case, I would imagine not everywhere, but probably the majority of clouds. It would make using the cloud easier if there was a simple way to discover, use and operate on a single id given any API operation on that cloud.17:58
blackboxswI don't have enough context on that at the moment, I was expecting to start harvesting more instance-data.json reports from clouds as we start iterating more on instance data.17:59
robjoGCE also has ID and name separate, but I think the ID is useful for API purposes in GCE, while in Azure it is useless17:59
robjoIN AWS the ID is the one unique identifier usefull for all operations and the "naming" of an instance is just a tag18:00
smoserpaulmey: is that actually true ? there is no api way to input 'vmID'?18:00
smoseri guess you could probaly list details on everything and get name.18:00
smoserbut yuck18:00
paulmeysmoser: I think that is correct18:02
paulmeyon the first incarnations of Azure, resources could not be moved between resource group and subscriptions18:03
paulmeyat that point in time, the sub/rg/name triplet was a unique identifier18:03
paulmeybut even then, in the delete/recreate scenario, it was hard for livesite engineers to figure out if operations were done on the same instance or a new instance18:04
paulmeywhich is when this vmId was introduced...18:05
paulmeyso yes, all our API operations use user-supplied 'IDs'...18:06
paulmeyIMDS let's you retrieve those now, but pre-IMDS, you had a hard time figuring those out18:07
blackboxswgce instance-data.json just for reference http://paste.ubuntu.com/26165085/18:13
smoserpaulmey: well, one improvement is that now i think these user-supplied ids are no longer required to be globally unique18:17
smoserat least my experience initially seemed like you had to pick a name in the cloudapp.net domain18:18
smoserand if someone else had that name, or azure deemed that name not appropriate for publish, you were denied18:18
blackboxswso next status meeting schedule would be Christmas day. The next week Monday is New Year's Day,  I'm thinking  we skip it and just meeting January 8th. Anyone opposed?18:19
=== blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 1/08 16:00 UTC | cloud-init 17.1 released
smoserrharper: https://mail.google.com/mail/u/2/#inbox/16046bdf55462464 ?18:34
smoseryou mentioned that to me18:34
dpb1LOL18:37
dpb1scotts gmail link not likely to work for the general user18:38
rharpersmoser: heh , what did I mention ?18:43
smosernice18:46
smoserfunny18:46
smoserum..18:46
smoserrharper: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/33504518:48
rharperyes18:48
rharper+118:49
blkadderQuestion: I want to add add a directory to a user’s .profile, however if I write the .profile using write_files I am finding that the .bashrc that is normally created by the system is no longer being written. Known isssue?18:54
blkadderIn case it matters the .profile file is being written correctly.18:55
smoserblkadder: i'm guessing you're suggesting you want to add a driectory to PATH, right?18:58
blkadderI’m guessing that the file is being written before the user is being created and that since the system already sees a directory there it doens’t place the usual files.18:58
blkaddersmoser: Correct.18:59
smoserwrite_files occurs before users are added.18:59
smoseryou can do so with runcmd or user-scripts18:59
blkadderAlright will do that instead, thanks.18:59
smoserthere is a missing feature for a late "write_files"18:59
blkadderYes, will be glad when that exists. I think I have run into this before.18:59
blkadderBecause it also potentially creates file ownership issues (if user doesn’t exist when written…)19:01
smoserblkadder: "before" ?19:39
smoseryou also may well be able to just write a file to /etc/profile.d/19:40
smoserif it is a global-ish thing19:40
blkadderIt is not.19:40
blkadderI just sed’d it.19:40
blkadderIt’s functional but man my yaml files are getting ugly.19:40
blkadderAnd I am finding I need to place another layer of abstraction on top.19:41
blackboxswtypos aside smoser rharper do you generally agree with this ? https://code.launchpad.net/~sankaraditya/cloud-init/+git/cloud-init/+merge/331751/comments/87757120:21
rharperblackboxsw: I agree; I think it's worth asking if cc_timezone setting TZ=UTC is the same20:24
rharpernote that, etc/timezone is different than the rcS; I'm not familiar with the debian rcS file20:24
rharperso maybe some more details on why it's rcS vs. the /etc/localtime/timezone changes that the base distros stuff does20:25
smoserblackboxsw: generally agree.20:31
smoserwe can have the datasource provide information default information20:32
smoserazure does this.20:32
smoserit doesnt have to be vendor-data, if the datasource is surfacing that informationm, its fine to merge it into default config.20:32
blackboxswgood point in general that I should keep in mind. Though rcS format looks like it's a UTC=yes or UTC=no format instead of just <timezone-reference> so it's slightly different20:34
blackboxswI don't really know how we should resolve that, other than debian-specific extension to write that file if the provided timezone == UTC20:35
blackboxswnot really sure how, in this, case the datasource would provide it as set_etc_timezone if fairly specific to what it expects to write.20:36
blackboxswnot really sure how, in this case, the datasource would provide it as set_etc_timezone if fairly specific to what it expects to write.20:37
blackboxswsilly punctuation20:37
blackboxswhrm https://superuser.com/questions/476512/how-do-i-permanently-reset-the-time-zone-in-debian    is it true tzdata isn't kept across reboots?20:38
* blackboxsw checks20:38
rharperhrm, it appears that the rcS UTC is referring to what the hardware clock is set to, UTC or LOCAL; that is different than timezone;20:39
rharperstill feels like it should be a general distro setting20:39
rharperand ultimately, even if the hwclock is set to UTC or local, on next shutdown, generally the hwclock --sync-to-hw is run which takes the current time and writes that out20:39
rharperthe newer way to configure hwclock is /etc/adjtime20:40
blackboxswtimezone retained on ubuntu across reboots. just to confirm our setting TZ is ok20:45
smoseroh. utc/uts ?20:48
smoseryeah. if they're really just setting that, that is not timezone.20:48
smoserthat is different.20:48
blackboxswrobjo: I had a couple of inline questions about the pust-up handling on your branch https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904 .   Not sure about the intent or use-cases we are trying to support there20:49
blackboxswlooks like UTC only.     +    replace_with = "UTC=" + utc    # where utc== (yes|no)20:50
smoserblackboxsw: rharper hang out ofr a bit ?21:01
smosergo through review queue?21:02
robjoblackboxsw: thanks for catching the typos, fixed21:02
rharpery21:02
rharpersmoser: i'm in21:05
smoserblackboxsw: rharper i'm going to pull https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/33433821:53
smoserunless you want to comment otherwise21:53
smoseras it seems reasonably well scoped21:53
smoseroh. and if one of you could review21:54
smoser https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/33499121:54
smoseri willi pull that too21:54
smoserfairly easy recreate21:54
smoseri dont *love* adding another class to extend setup.py behavior but it other than it kind of being hacky, it is tested in centos, suse, ubuntu of recent vintage.21:55
smoser(ie, i was mostm concerned that there was not a "clean" way of extending the class to accomplish what i wanted)21:55
=== StoneTable is now known as aisrael
blackboxswsmoser: per your fix leaked tmpfile fix, would it be worth us adding the unittest name to the tmpfile prefix instead of just the Classname?21:59
blackboxswit'd ease discovery of leaked files in the future21:59
blackboxswthough ci-<Classname>-<tmpsuffix> does make it at least a bit easier21:59
blackboxswohh right n/m this is from my use of the naked mkdtemp which didn't have any prefix22:01
dojordan@blackboxsw: I've addressed your latest round of PR comments. Can you look again when you get a chance? https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/33434122:02
blackboxswsee the issue & fix. +122:02
blackboxswdojordan: your ears must have been burning.   We were talking about your branch a ajorg's a couple mins ago. Will wrap up your review shortly.22:02
dojordanthanks :)22:07
rharpersmoser: reviewed/approved the reproducible-builds branch22:09
blackboxswsame with the unit test temp leaks branch approved22:14
blackboxswdojordan: one minor nit left for me on your azure markerfile branch.22:14
blackboxswI think the content looks good. not sure if we are landing it for 17.2 today, but should land shortly thereafter if not this week.22:15
* blackboxsw still wanted to start things up with a markerfile and see what I can break22:15
smoserok. so my plan is to grab ajorgens branch for instance-identity. blackboxsw you said youd' test that on openstack and on ec2 ?22:16
smoserif we get that i'm +1 on it and will pull and upload to ubuntu too22:16
smoser(in a couple hours)22:16
blackboxswsmoser: yeah I'm installing it now on ec222:16
smoserthen i think we're done with what we would pull22:17
blackboxswthen openstack22:17
blackboxsw+1 that22:17
rharpersmoser: sounds like a plan22:18
* powersj pushed 3 integration test enhancements; not urgent for next release, but required for EC2 support22:19
dojordan@blackboxsw, i'm not seeing your NIT comment for some reason. Is it the location of the marker file should be in the cloud init directory?22:25
blackboxswhrm. dojordan maybe I didn't click submit. checking22:26
dojordancool, got it22:27
blackboxswstrange my comment landed, but the inline review comment didn't for some reason. posted again dojordan see it line 140 of visual diff?22:27
blackboxswok22:27
blackboxswgood deal22:27
blackboxswok walked through ajorg's instance-identity on ec2 and openstack. Only thing I'd like to see is that this dynamic data we query get persisted in the datasource self.metadata so we can also write that to disk in instance-data.json. Right now the callchain doesn't actually manipulate self.metadata at all and so these data are not present for other consumers.22:37
blackboxswI don't think that has to block this branch. We can add it in after the fact. But, it represents metadata that the Ec2DataSource relies on that isn't transparent in instance-data.json22:41
blackboxswapproved https://code.launchpad.net/~ajorgens/cloud-init/+git/cloud-init/+merge/32965722:50
dojordan@blackboxsw - fixed22:52
blackboxswthanks dojordan looks good to me.23:06

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!