=== cpaelzer__ is now known as cpaelzer
=== hjensas is now known as hjensas|PTO
=== vrubiolo1 is now known as vrubiolo
[13:48] <smoser> i'm not sure what this ailure is... but i dont think related to the pull request it came from
[13:48] <smoser>  https://travis-ci.com/github/canonical/cloud-init/jobs/421338811
[13:48] <smoser> (#640 https://github.com/canonical/cloud-init/pull/640/checks?check_run_id=1331314409)
[13:48] <AscII> yeah, I don't get it either
[13:58] <smoser> integration test failed. in colect_test_data
[13:58] <smoser> 2020-10-30 10:07:15,081 - /home/travis/build/canonical/cloud-init/tests/cloud_tests/stage.py:run_stage:102 [ERROR]: stage: collect test data for xenial encountered error: Create instance from copy: The container is already frozen
[13:58] <smoser> i hit 're-run' , but i dont know if it did anything
[14:00] <AscII> does not look like it
[14:08] <smoser> Odd_Bloke: help? ^ or blackboxsw or falcojr ?
[14:09] <Odd_Bloke> Huh, I've never seen that before.
[14:10] <Odd_Bloke> Looks like a new LXD snap did land today, so it could be an issue with that, I'll test locally.
[14:11] <smoser> hooray for "dude on the internet broke my c-i"
[14:11] <falcojr> that's why we have CI, right? ;)
[14:12] <otubo> blackboxsw: thanks for the feedback! According to https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html Fedora 23 will branch from Rawhide on 2021-02-09. So I guess that's time enough for at least one cloud-init release :-)
[14:12] <otubo> *Fedora 34, missclicked sorry :-)
[14:24] <Odd_Bloke> (https://github.com/lxc/lxd/commit/1cb7475c22a02f5317641c746c87430b0d561551 landed 4 days ago, seems unlikely to be a coincidence.)
[14:56] <Odd_Bloke> OK, I can reproduce it locally; I'll submit a PR to pin our `snap install lxd` at an older known-working version and then file a bug with lxd.
[14:56] <Odd_Bloke> (I expect the response will be roughly "lol pylxd" but nevertheless. :p)
[14:59] <Odd_Bloke> smoser: https://github.com/canonical/cloud-init/pull/642 <-- it's not a linter by any means, but this should at least guide people in a clearer direction?
[15:14] <smoser> Odd_Bloke: its a good idea. commented there.
[15:20] <danzarov> hello guys, does anybody know if there is a way I can perform a for loop to add users instead of specifying multiple user blocks like showed here https://cloudinit.readthedocs.io/en/20.3/topics/examples.html#including-users-and-groups
[15:21] <danzarov> i know i can use a variable type string and do something like: - name: ${username} ...and so on
[15:21] <danzarov> but still i would need to create multiple variables and multiple user blocks
[15:34] <smoser> danzarov: i think maybe if you start it with ## template: jinja you can use jinja.
[15:34] <smoser> but a simple "another layer of indirection" solves the problem too.
[15:34] <smoser> just have a program write the user-data that you provide.
[15:46] <meena> i used pylxd while developing against the go API, because go has no REPL
[16:07] <rharper> falcojr: https://github.com/canonical/cloud-init/pull/598  I approved this; it needs a rebase;  I don't see the rebase and merge button; not sure if you can do that;
[16:12] <danzarov> smoser, nice, im going to try jinja, thanks (:
[16:23] <Odd_Bloke> rharper: There should be an "Update branch" button (which would then mean you could use the "Squash and merge" button once it was up-to-date), but the submitter must have disabled the option that allows maintainers to push to their branch.  That means we're reliant on them updating the branch for landing.
[16:23] <rharper> ah
[16:23] <Odd_Bloke> (Same issue as with A'scII y'day.)
[16:26] <Odd_Bloke> rharper: If we don't hear anything from them for a while, then we can work around it by opening a PR with their commits rebased; they wouldn't receive credit as the committer of the squash commit in that case, however.
=== Odd_Bloke changed the topic of #cloud-init to: Known CI Issue: https://github.com/canonical/cloud-init/pull/643 | pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next Office Hours: Oct 20 16:15 UTC | 20.3 (Aug 25) | https://bugs.launchpad.net/cloud-init/+filebug
[16:29] <Odd_Bloke> smoser: rharper: blackboxsw: If I could get a review of https://github.com/canonical/cloud-init/pull/643, we can unblock CI while I dig into the specifics of the LXD failure.
[16:30] <blackboxsw> grabbing that now thanks Odd_Bloke
[16:33] <smoser> oh, falcojr doesnt count
[16:33] <smoser> i saw his and left it
[16:34] <falcojr> haha, all my reviews are still pretend
[16:35] <blackboxsw> working towards it https://discourse.ubuntu.com/t/submitting-for-commit-rights-to-cloud-init/18770 :)
[16:36] <rharper> "latest lxd 4.7 snap causes failures"  when has lxd update not broken users?
[16:39] <smoser> ugh.
[16:39] <smoser>  https://github.com/canonical/cloud-init/pull/640
[16:39] <smoser> why dont' i see a "update branch" button
[16:39] <smoser> maybe AscII did not say "allow maintainers to update" or somethign ?
[16:39] <smoser> AscII: can you fetch && rebase ?
[16:39] <smoser> and push
[18:03] <AscII> smoser: i simply don't have that setting. Odd_Bloke guessed this might be because it's an organization repo
[18:04] <AscII> it might really be simpler if I delete the fork on the org repo and set up a new one in my own namespace
[18:07] <smoser> AscII: well i dont care too much either way
[18:07] <smoser> and really this should not be a problem.
[18:08] <AscII> anyway, it's rebased and you could merge it
[18:08] <blackboxsw> AscII: I think that might make sense, for future PRs, I see the mismatch between hetzneronline vs
[18:08] <blackboxsw> asciiprod. So pushes to your own remote may give you the permission to check the box that says "allow maintainer changes"  for this one off the rebase will/should work
[18:08] <blackboxsw> n/m too late
[18:09] <blackboxsw> n/m too late. as in, you already solved it.
[18:09] <meena> glad we solved that mystery
[18:10] <AscII> The PR is too embarrasing anyway. I should have doubled checked that before blindly adding the check
[18:10] <AscII> and voila, travis is happy too
=== Odd_Bloke changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next Office Hours: Oct 20 16:15 UTC | 20.3 (Aug 25) | https://bugs.launchpad.net/cloud-init/+filebug
[18:14] <smoser> AscII: landed.
[18:14] <Odd_Bloke> stgraber is fixing our lxd issue: https://github.com/lxc/lxd/pull/8102
[18:14] <smoser> AscII: well, to be fair to me (who requested the check) you would have just added a more subtle bug
[18:14] <smoser> which was sometimes metadata['instance-id'] would have been a integer, and sometimes a string.
[18:15] <blackboxsw> Woot! Odd_Bloke thanks!
[18:15] <AscII> you are right, that would have been an even bigger pain.
[18:16] <blackboxsw> smoser: rharper do either of you use https://github.com/cloud-init/qa-scripts/ repo anymore. We'd like to consolidate unused repos  (moving anything applicable into uss-tableflip.
[18:16] <blackboxsw> https://github.com/cloud-init/qa-scripts/issues/19
[18:18] <smoser> things that are there that i have used in the past 6 months:
[18:18] <blackboxsw> both public repos (we'll make sure no internal  jobs etc are using it), just didn't want to find out later about other consumers
[18:18] <smoser>  * get-propposed-cloudimg
[18:18] <smoser>  * lxc-proposed-snapshot
[18:18] <smoser>  - lxc-pstart
[18:19] <smoser> update-root
[18:19] <smoser> and those depend on psuedo-init i think
[18:22] <blackboxsw> thanks smoser, we'll tease out those dependencies and make sure to wrap up missing script dependencies. goal is to get applicable scripts/tools into  uss-tableflip/scrits
[18:22] <blackboxsw> *scripts
[18:22] <smoser> yeah. thats fine.
[18:24] <rharper> blackboxsw: same as smoser;  I think paride 's plan of merging bits into tableflip is fine
[18:24] <blackboxsw> good deal. thanks rharper
[19:13] <meena> https://github.com/canonical/cloud-init/pull/637 is ready to go
[20:57] <meena> (now)
[21:00] <meena> and so is https://github.com/canonical/cloud-init/pull/625 ( @ smoser )
[21:30] <danzarov> smoser, i tried a bunch of different ways but it didn't work :( maybe because i'm trying to use the ##template: jinja inside the AWS::EC2::LaunchTemplate UserData
[21:30] <danzarov> it doesnt seem to be interpreting the code
[21:32] <powersj> danzarov, are you base64 encoding your data?
[21:32] <danzarov> @powersj, yup :/
[21:32] <danzarov> it works, just the jinja code that doesn't
[21:33] <danzarov> https://stackoverflow.com/questions/42269785/error-when-parsing-yaml-file-found-character-that-cannot-start-any-token
[21:33] <danzarov> i did a very similar approach to the accepted answer here /\
[21:34] <danzarov> but seems that using # {% for x in anything %} is just interpreted as a comment, im not sure
[21:35] <powersj> yeah based on our docs I don't think you want to comment them: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html?highlight=jinja#using-instance-data
[21:35] <danzarov> i saw that one, im not using inside the runcmd: directive though
[21:35] <meena> (https://github.com/canonical/cloud-init/pull/622 also looks ready but needs another rebase)
[21:36] <danzarov> let me show you how im trying to do that @powersj, just a sec
[21:40] <danzarov> https://pastebin.com/TMsKWR69
[21:40] <danzarov> something like that
[21:40] <danzarov> but i dont think this is possible
[21:46] <powersj> blackboxsw, is it possible to use custom variables with cloud-init's jinja parsing? or is it limited to only variables exposed in /run/cloud-init/instance-data.json?
[22:01] <powersj> danzarov, fwiw I did get https://pastebin.ubuntu.com/p/KXhrDyC7w9/ to create alice and bob
[22:04] <powersj> the set line didn't seem to work when commented out as I got "Format for 'users' key must be a comma separated string or a dictionary or a list and not NoneType"
[22:04] <powersj> so it appeared to not resolve the list name
[22:05] <blackboxsw> powersj: no custom vars permitted by cloud-init proper jinja handling per the simplistic rendering of vars we do here https://github.com/canonical/cloud-init/blob/master/cloudinit/handlers/jinja_template.py#L81
[22:05] <powersj> and when uncommented I got Could not render jinja template variables
[22:05] <blackboxsw> extending that to add customized support would not be a "hard" if we have a feature bug etc
[22:06] <meena> a feature bug…
[22:06] <powersj> it's the featured bug of the week :P
[22:08] <powersj> danzarov, btw the way I was testing this was using lxd per https://cloudinit.readthedocs.io/en/latest/topics/faq.html#lxd
[22:08] <powersj> lol @ "btw the way"... maybe I should call it a week
[22:08] <meena> powersj  https://twitter.com/musha68k/status/1322299136167841796
[22:09] <powersj> hahaha
[22:09] <danzarov> @powersj, that's interesting, gonna test it on my environment
[22:10] <danzarov> did the alice and bob example worked?
[22:14] <powersj> danzarov, https://pastebin.ubuntu.com/p/xcfCJNpJNF/
[22:14] <danzarov> woah
[22:14] <danzarov> nice!
[22:15] <danzarov> im spinning up a cluster here, gonna test inside the UserData
[22:15] <danzarov> lets see how it goes
[22:21] <blackboxsw> danzarov: powersj if something goes awry and you instance doesn't look like it got setup properly, you can quickly inspect the rendered userdata on the instance with `sudo cloud-init query --format="$(cloud-init query userdata)"`
[22:21] <blackboxsw> what the above cmd does is `cloud-init query userdata` report the raw userdata template you provided to the instance at launch.
[22:21] <danzarov> thats good, will be very useful
[22:21] <danzarov> thanks
[22:22] <powersj> that is a good one blackboxsw we should add that to the docs page for jinja
[22:22] <blackboxsw> the `cloud-init query --format` wrapper will render the jinja template content and try performing your loop to see ultimately how the final  #cloud-config looked with vars rendered loops iterated
[22:22] <blackboxsw> yeah will add that now
[22:22] <blackboxsw> just came up with it as I hadn't thought of a non-lxd way to iterate quickly on this
[22:23] <blackboxsw> danzarov: feature-wise you were looking initially to support rendering,reacting to the host underlying environment variables in jinja templates?
[22:24] <blackboxsw> like whether an image or environement could expose an environment variable that cloud-init's jinja template could react to?
[22:24] <blackboxsw> I ask as powersj alluded to "custom variables with cloud-init's jinja parsing"
[22:24] <powersj> blackboxsw, https://pastebin.com/TMsKWR69 that was what danzarov was trying to do
[22:25] <blackboxsw> I like the idea of augmenting the stock vars that are available to cloud-init's jinja templates,
[22:25] <blackboxsw> right where names were hardcoded in the user-data though  {% set list1 = ['name1', 'name2'] %}
[22:25] <danzarov> hrmm got this
[22:25] <danzarov> Oct 30 22:20:58 cloud-init[3577]: util.py[WARNING]: Failed loading yaml blob. Invalid format at line 8 column 4: "while scanning for the next token
[22:25] <danzarov> found character '%' that cannot start any token
[22:25] <danzarov>   in "<string>", line 8, column 4:
[22:25] <danzarov>       {% for name in ["alice", "bob"] - ...
[22:25] <danzarov>        ^"
[22:26] <danzarov> ops, sorry multiple lines
[22:26] <blackboxsw> I was wondering about whether there were a need to have a {% set userlist = env['CUSTOM_USERS'] %} type facility
[22:26] <blackboxsw> as right now we limit cloud-init template vars to just instance-data.json
[22:27] <blackboxsw> it would be a nice facility to allow augmenting those template vars
[22:27] <danzarov> @blackboxsw, actually i did that just to illustrate, what im doing in reallity is seting the userlist variable with a list comming from terraform cloudformation stack parameters
[22:27] <danzarov> so i basically assigned userlist with this list of usernames comming from terraform
[22:28] <danzarov> and i want to loop like @powersj did
[22:28] <danzarov> but i got this error, i wonder if this is specific to UserData in aws launchtemplate UserData
[22:28] <danzarov> weird
[22:28] <blackboxsw> as a note, any variables exposed by the metadata service gets cached in cloud-init's instance data and a `cloud-init query --all` can list any available keys/data from that datasource under the 'ds' key
[22:29] <blackboxsw> so if there are ways for you to expose terraform stack params via the datasource,then cloud-init jinja templates pick up on that
[22:29] <danzarov> humm i saw something interesting using the command you mentioned above
[22:29] <danzarov> sudo cloud-init query --format="$(cloud-init query userdata)"
[22:29] <danzarov> WARNING: Ignoring jinja template for query commandline: 'tuple object' has no attribute 'split'
[22:30] <danzarov> got this
[22:30] <danzarov> oh i didnt know about the ds key
[22:30] <blackboxsw> ok so back out to `sudo cloud-init query userdata`
[22:31] <blackboxsw> you'll need to be running as root user for all query commands using userdata. so the call should actually be `cloud-init query --format="$(sudo cloud-init query userdata)"
[22:31] <danzarov> oh wait, i left a mistake on my code that can be causing the problem
[22:31] <danzarov>   # {% set list1 = var.split(',') %}
[22:31]  * powersj disappers 
[22:32] <danzarov> lmao
[22:32] <danzarov> let me remove this and try again
[22:35] <danzarov> btw i was doing this split because i had to pass a string like username = 'user1,user2,user3'. because cloudformation stack resource doesnt support passing a list
[22:35] <danzarov> :|
[22:43] <danzarov> hmm weird, same error as above
[22:43] <danzarov> found character '%' that cannot start any token
[23:10] <blackboxsw> drive by doc pr  https://github.com/canonical/cloud-init/pull/645/files
[23:10] <blackboxsw> <- dinner run. have a good one folks
[23:10] <danzarov> cya
[23:10] <danzarov> thanks for the help
[23:32] <danzarov> blackboxsw, powersj you guys rock! it worked (((:
[23:33] <danzarov> i had some indentation problem after that code, sorry didnt notice at first