[04:33] <bemis> I asked a few days back but didn't get any response; trying again - are there any centos/rhel/oel/sl users in here?
[11:58] <setner> Hi everyone. I am trying to understand the differences between ansible and cloud-init. Why do people tend to use cloud-init in conjunction with ansible? Why not just ansible or just cloud-init? Can ansible and cloud-init perform the same actions?
[13:39] <setner> Can anyone help me with this question: what can cloud-init do that ansible (for example) can't do?
[13:43] <smoser> ybaumy: if you could open a bug with details of what is not working we can take a look.
[13:44] <smoser> setner, cloud-init is often times the first thing that is used, and its in the image already.  It helps bootstrapping.  it will set up a user and import ssh keys that may then be used by ansible.
[13:46] <setner> smoser: ok, it helps on the bootstrap process. But isn't that also achievable with ansible?
[13:48] <Odd_Bloke> bemis: There are people around; if you have a specific question, it's probably best to ask it so they can respond when they are around.
[13:57] <smoser> setner: i dont know how you would do that with ansible
[13:57] <smoser> take a stock image and get your ssh keys into it
[14:41] <bemis> Odd_Bloke: :) fair enough, thanks
[14:44] <bemis> specifically i'm looking for help getting 18.1 packaged for rhel6/rhel7
[14:44] <bemis> and hoping that perhaps others have walked this path before me and can guide me around the jagged edges
[15:02] <ch007m> Does one of you know how we can disable biosdevname when we use cloud-init / user-data config file ?
[15:35] <smoser> blackboxsw: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341349
[15:35] <smoser> could you take a quick look at that ? simple-ish removal of duplicate code.
[15:36] <smoser> bemis: we have daily builds of trunk in copr
[15:36] <smoser>  at https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[15:37] <smoser> ch007m: biosdevname kind of happens too late.
[15:37] <smoser> you can build your imgaes with changes to disable it.
[15:40] <ch007m> So we can't define bootloader as we can do with kickstart then - https://goo.gl/PUjERh ?
[15:46] <ch007m> As `packages:` will install yum packages the first time the vm will start, how can we know that all the packages defined are installed ?
[16:03] <smoser> ch007m: they'll be installed when cloud-init finishes.  you can look at /run/cloud-init/result.json to see the result.
[16:03] <smoser> is that what you're asking ?
[16:03] <smoser> you can't change the bootloader in an image for the first boot, cloud-init runs after that.
[16:30] <ybaumy> smoser: its not a but .. it wont work the way it was working years ago anymore since those features you were using dont exist in the commands anymore. things changed
[16:31] <ybaumy> s/but/bug
[16:34] <smoser> ybaumy: i need more information. I'm really not sure what you're talking about. Please file a bug and explain clearly what you were expecting to work and what is not working.
[16:35] <ybaumy> smoser: doesnt really matter what the current status is. its not what we need. psyrabbit is going to try to implement a new datasource provider for vcloud
[16:35] <ybaumy> this is what we should focus on
[16:36] <smoser> blackboxsw: so on your snap branch
[16:38] <blackboxsw> yes all ears
[16:38] <blackboxsw> just got through your jsonschema branch. landing it now
[16:38] <blackboxsw> post a tox run
[16:41] <bemis> smoser: whoa, thanks!
[16:42] <smoser> blackboxsw: i just hit 'submit' there.
[16:43] <ybaumy> smoser: we hope .. we can get a little support from you guys when he is implementing the datasource for vcloud. we think we found a way to handle data transfers
[16:43] <blackboxsw> smoser: checking
[16:47] <blackboxsw> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341349 merged
[16:48] <bemis> smoser: did the project drop EL6 support at some point between 0.75 and now?
[16:51] <dpb1> ybaumy: support time will be limited over the next couple weeks
[16:51] <dpb1> ybaumy: we have a release we are pushing for end of month
[16:51] <dpb1> ybaumy: but we will do what we can
[16:52] <ybaumy> dpb1: ok this is not a "no" for an answer and thats what we need
[16:52] <dpb1> ybaumy: ok
[16:52] <dpb1> bemis: it likely still works, are you seeing something broken?
[16:53] <bemis> dpb1: i wasn't finding el6 builds in the copr link pasted - i've since found them and am doing some testing now
[16:53] <dpb1> ah ok
[16:53] <dpb1> bemis: it's not something we stay on top of that much, but would be an interesting data point
[16:53] <dpb1> (tip on el6)
[16:53] <bemis> what led to the join initially was the conditional logic around systemd was removed at some point and the service file required components that aren't in el7
[16:53] <bemis> so i thought maybe the el landscape was an afterthought
[16:54] <ybaumy> dpb1: we have no timeline set on the project so its no problem if help is 1 day apart
[16:55] <dpb1> bemis: not an afterthought, but I'm not of how widely used it is at this point in the lifecycle of 6. :)
[16:55] <dpb1> so there are likely gaps
[16:55] <bemis> dpb1: that's fair - i'll make sure to update here as my project progresses then :)
[16:55] <bemis> thank you
[16:55]  * dpb1 nods
[17:17] <blackboxsw> smoser: thanks for the snap config review comments. I'm inclined to add the error exception message as you suggested instead of just listing the failed command.  I'm also hesitant to move the instance-data.json tests into base because we run them on every test case, increasing the cost of each of our tests by another ssh roundtrip to pull down that file & validate the same content
[17:18] <dojordan> @blackboxsw, sorry to bother but can you take a look at my MP? https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/340546
[17:18] <blackboxsw> dojordan: hiya, sorry about my silence earlier, I was on vacation monday/tuesday
[17:19] <dojordan> ah no worries!
[17:19] <blackboxsw> I'm digging out of my backlog and hopefully can get to that branch soon. It'll be reviewed this week for sure
[17:20] <blackboxsw> I had one exception path I wanted to test dojordan, connection not present versus, path not present on existing service(404)
[17:20] <blackboxsw> we thought maybe there was a better way to handle things since you are dropping the timeout
[17:20] <blackboxsw> dojordan: like maybe using readurl instead of wait for url
[17:21] <blackboxsw> but I wanted to test that before giving you the suggestion
[17:21] <blackboxsw> might as well say that now so you could glance at that as a potential solution
[17:21] <dojordan> sure, thats a good idea
[17:23] <blackboxsw> yeah it just seemed clunky that we were using wait_for_url there (which calls readurl and actually has the content of the url but ignores it only to return the endpoint's URI). So your branch would effectively be calling readurl twice on success path, once in wait_for_url to see that the service is up and once to actually recapture the content
[17:24] <blackboxsw> that wait made sense when the timeout was larger, but not so much anymore :/. Ok thanks for glancing at the potential
[17:24] <dojordan> right- we were actually discussing this recently. the other option is make wait for url return both success and optionally content but read_url seems cleaner
[17:25] <dojordan> if the connection is not present we would re-DHCP anyway as it would still bubble up to a url error
[17:27] <blackboxsw> yeah I thought about the same too (augmenting wair_for_url), but it looked like we were just using the wrong tool for the job.  wait_for_url was really only meant to iterate through a list of potential metadata URLs to return the first one that responds. smoser and I had talked about the potential of dropping the wait_for_url function at some point in the future since there are only a couple of callsites that
[17:27] <blackboxsw> could be consolidated into a simpler helper. so something that uses readurl directly would make things simpler if we drop wait_for_url.
[17:27] <dojordan> cool, ill make the change
[17:27] <blackboxsw> good deal thanks dojordan
[17:31] <ch007m> when I log on the first time to the vm, some packages are still installed as the yum process is locked -> https://www.dropbox.com/s/dh0zewvgpy0o80y/Screenshot%202018-03-14%2018.31.24.png?dl=0
[17:32] <ch007m> Is there a command that I could pass or use to know what are the packages currently downloaded for installation in order to know the status of the progressions ?
[17:33] <smoser> ch007m: probalby some 'ps' or look at /var/log/cloud-init-output.log
[17:36] <ch007m> this line is recorded -> "2018-03-14 17:30:54,672 - util.py[DEBUG]: Running command ['yum', '-t', '-y', 'install', 'git', 'docker', 'openssl', 'net-tools', 'NetworkManager'] with allowed return codes [0] (shell=False, capture=False)". When that will happen, I suppose then that all the packages will be installed then ?
[17:37] <smoser> when it finishes yes. its possible that it is locked/blocked for some reason
[17:41] <ch007m> When is cloud-init executed exactly during vm bootstrapping ?
[17:45] <smoser> ch007m: fairly late.
[17:46] <smoser>  cloud-init-final.service
[17:46] <smoser> which is After=multi-user.target
[17:48] <ch007m> +1. Thanks.
[17:48] <ch007m> I suppose that OOTB, it is packaged within this image (CentOS-7-x86_64-GenericCloud-1802.qcow2c) ?
[17:57] <ch007m> My centos qcow2 includes this version `cloud-init 0.7.9` which isn't the latest. Have you discussed with Centos team to do a an upgrade ?
[18:00] <dpb1> ch007m: no, not really
[18:01] <dpb1> ch007m: you'd need to get in touch with one of the rhel disto guys to see what their plans were
[18:02] <ch007m> ok
[18:49] <smoser> blackboxsw: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341417
[18:54] <okie> good morning everyone
[18:54] <okie> actually afternoon
[18:56] <okie> i got a question if anyone can assist. I am running a centos 7 aws image and having a problem with cloud-init it looks like. I have consistant network device naming turned off but cloud init is not respecting that. I can advise it is cloud init as there are ifcfg-ens* entries with a comment in each of them advising this was automatically generated by cloud-init
[18:57] <okie> how do i get cloud init to respect that i have disabled consistent network device naming.
[18:59] <smoser> okie: cloud-init doesnt really do anything with that. what is the problem you're trying to solve ?
[19:00] <smoser> then also, blackboxsw https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341420
[19:01] <blackboxsw> heh, smoser I'm circling the unit test drain on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/339720
[19:01] <okie> so right now device names are using predictable network device naming or otherwise known as consistent network device naming... So instead of eth0 i have ens{insert number}. I want to go back to the "traditional" way which is eth0. I have followed the redhat docs on how to do this but ens entries are being generated by cloud-init
[19:03] <okie> grep ^ /etc/sysconfig/network-scripts/ifcfg-*
[19:03] <okie> #/etc/sysconfig/network-scripts/ifcfg-ens3:# Created by cloud-init on instance boot automatically, do not edit.
[19:03] <okie> #/etc/sysconfig/network-scripts/ifcfg-ens5:# Created by cloud-init on instance boot automatically, do not edit.
[19:04] <smoser> okie: you may possibly need to clean up a bit.
[19:04] <smoser> your image.. if its not pristin.
[19:04] <okie> its a base centos7 image from aws market place
[19:05] <smoser> in most cases, c loud-init reads the devices rthat it sees asa they are. and then configures networking, and ensures that the names it writes are right.
[19:06] <smoser> can you post a /var/log/cloud-init.log ?
[19:06] <okie> ya
[19:07] <smoser> https://hastebin.com/
[19:07] <smoser> is wonderful (before you went to pastebin.com)
[19:11] <okie> https://hastebin.com/onekedolod.sql
[19:12] <okie> file was too big to save in hastebin so you got part of the cloud init log
[19:14] <smoser> oh. really ? it said too big ?
[19:14] <okie> yuppers
[19:14] <smoser> well then, feel free to paste the whole thing somewehere else
[19:14] <smoser> paste.ubuntu.com is good
[19:16] <okie> way to go ubuntu pastebin.. that works
[19:16] <okie> https://paste.ubuntu.com/p/YbT9RWQ8zm/
[19:16] <smoser> yeah, but in ubuntu pastebin you have to log in to get raw
[19:18] <smoser> okie: when cloud-init ran it saw devices named 'ens3'
[19:18] <smoser> so i thii if you were expecting to get 'eth0' device, then you must have done something wrong.
[19:19] <okie> where is it looking sysconfig/network-scripts/ or where?
[19:20] <okie> that it is determining this.. as the base centos7 image is disabling the udev rule to use consistent network device names..
[19:20] <okie> i dont get where cloud-init is pulling ens3 from?
[19:26] <smoser> okie: it looks in /sys for the names.
[19:26] <smoser> and then writes config making sure that they stay with those names.
[19:26] <okie> thanks
[19:32] <dojordan> @blackboxsw, pushed the changes: https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/340546
[19:56] <blackboxsw> smoser: pushed the unit test coverage for set-hostname-early branch https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/339720. I'm done now with that and hitting your reviews
[19:59] <blackboxsw> thx dojordan\
[20:05] <okie> @smoser thanks for the help... It was helped me in the right direction
[20:06] <smoser> great!
[21:11] <blackboxsw> smoser: minor nit on your doc branch https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341420 and approved
[22:23] <blackboxsw> smoser: I think 46cb6716c27d4496ce3d2bea7684803f522f277d broke util.subp
[22:23] <blackboxsw> it treats args as a list always, which isn't true, so any pure string passed to subp will fall apart
[22:24] <blackboxsw> as it gets treated as an iterable character by character
[22:27] <dojordan> (sorry to but in) but that's what broke get_hostname on azure
[22:28] <blackboxsw> dojordan: yeah, I recall your comment on how that branch shouldn't have passed CI.  yeah, just hit it on my branch too (where I provide strings to subp instead of lists too). I figured your fix was still safe/good practice etc.
[22:29] <dojordan> One possibility is to add an assertion on the type being passed into util.subp?
[22:29] <blackboxsw> dojordan: yes, you are correct. I just looked through that subp encoding changeset in more detail to see what the intent was (instead of blazing past it).  And sure enough
[22:30] <dojordan> Also, this is me just rambling, but at some point type hints could help prevent things like this...
[22:30] <blackboxsw> true, I think thanks probably a nice feature, to catch other potential programming errors on what gets passed into subp. though subp should support both string and list
[22:30] <dojordan> true, it could just construct a 1 element tuple if need be
[22:31] <blackboxsw> rambling welcome. and preaching to the choir ;)    Yes I want generally to have strict schema validation on all user-provided content from cloudinit's config modules which would both document expected types and explicitly warn/error on invalid types.
[22:32] <dojordan> *dojordan swoons*
[22:32] <blackboxsw> it's a long road on that front, but handling that on common utility functions like subp is a good start to prevent misuse of core functions/methods
[22:32] <blackboxsw> "cloud-init devel schema --doc"
[22:32] <blackboxsw> only currently about 7 examples of schema types
[22:33] <blackboxsw> or locally in your repo directory: python3 -m cloudinit.cmd.main devel schema --doc
[22:33] <dojordan> nice, its a good start
[22:33] <blackboxsw> gotta start somewhere :)
[22:46]  * blackboxsw heads out for a bit. checking in later