[07:42] <NerdyBiker> rharper thanks! I totally forgot the instance-specific cloud places
[08:31] <aixtools> o/ anyone listening
[08:31] <aixtools> I am trying to clone cloud-init, but nothing seems to be 'cloning'
[08:32] <aixtools> my local directory gets made, then quiet. While with github - works fine.
[08:33] <aixtools> I am using: git clone myrealuid@git.launchpad.net:cloud-init to clone.
[08:34] <aixtools> and in case noone has noticed http(s)://cloudinit.readthedocs.io no longer seems to exist.
[08:52] <aixtools> afk but hope to read a hint later :)
[10:12] <aixtools> awake anyone?
[10:13] <aixtools> after forever, my git clone .... command ended with (excerpt)
[10:13] <aixtools> ]Read from socket failed: Connection reset by peer
[10:14] <aixtools> fatal: Could not read from remote repository.
[10:16] <aixtools> it never asked for a password, and actually I am wondering how USERNAME is supposed to work here, if I have nothing to clone from
[10:16] <aixtools> git clone YOUR_USERNAME@git.launchpad.net:cloud-init - shouldn't that just be
[10:17] <aixtools> git clone git.launchpad.net:cloud-init ? trying it anyway...
[10:18] <aixtools> ok, that fails with: Launchpad user 'michael' doesn't have a registered SSH key
[10:19] <aixtools> so, since I do not get that message with I prefix my launchpad userid - how can I test that my ssh key is owrking properly?
[10:40] <NerdyBiker> Anyone have an example as to how to input an ec2 instance ID into a write_file cloud-config? I can't seem to make it work at all. I know it can be found in the /var/lib/cloud/data/instance-id file, but need a way to put that value into a write_file content string.
[13:23] <smoser> NerdyBiker, i ddont really think you can. it'd be nice, but there is no template on write file content.
[13:23] <smoser> what you'd have to do is use boothook to execute data that read that and wrote your file.
[13:24] <smoser> aixtools, well, you can only use git+ssh if you have a launchpad user and registered keys.
[13:24] <smoser> but you can read-only clone with git://git.launchpad.net/cloud-init
[13:25] <smoser> or http://git.launchpad.net/cloud-init (or https)
[14:40] <aixtools> thank you @smoser - using the git:// for the copy - er clone - as I do not expect to have write perms :)
[14:41] <smoser> aixtools, well, with git+ssh:// you can push back to launchpad for your branch.
[14:41] <smoser> (independent of having commit access to master)
[14:42] <smoser> s/branch/repo/ ; s/master/cloud-init official repo/
[14:44] <aixtools> well, i thought that was what the next line was for... "git remote add USERID USERID@git.launchpad.net:~USERID/cloud-init
[14:45] <aixtools> -- trying to follow your documentation.
[14:47] <aixtools> thus - as I am only getting started - which procedure do you recommend. My goal is to a) remake the patch (or hack) someone made for AIX, and b) remade in such a way that it might be accepted for mainstream because c) do nopt want to wait for IBM to get around to it.
[14:48] <aixtools> however, if d) happens (IBM finishes first AND it is in the official branch - I shall just sit back and relax :)
[14:52] <aixtools> @smoser - I am still trying to get the "feeling" for how git works - so while I do read re not able to place your "s" command, aka I am almost comfortable with the principle of a pull request.
[14:53] <smoser> aixtools, sorry. sed syntax an aixer should know that ;)
[14:53] <aixtools> but not clear on what you mean. It is "whatever works" for collaboration with the intent to introduce a new platform.
[14:53] <smoser> so you can always clone from git://git.launchpad.net/cloud-init
[14:53] <smoser> that will work, and then you can commit locally and be happy
[14:53] <smoser> but if you want to push to a remote git repo, then you can push to:
[14:54] <aixtools> i know sed - used to use it years ago to automate some of my assembly code on the PDP-11.
[14:54] <smoser>   git+ssh://aixtools@git.launchpad.net/cloud-init
[14:54] <smoser> shoot... sorry. you can push to
[14:54] <aixtools> but it is knowing what 'branch', 'repo', etc. mean. Still grasping with those :)
[14:55] <smoser>   git+ssh://aixtools@git.launchpad.net/~aixtools/cloud-init
[14:55] <smoser> a git "repo" (repository) contains multiple branches.
[14:56] <aixtools> nods: does the "add remote" do anything remote, or is that to set one of the 'references' (I keep forgetting the git idiom)
[14:57] <aixtools> i am trying to compare this to the process I have followed twice on github: a) fork on github; clone the fork made; commit to fork, and then pull-request.
[14:59] <aixtools> (with making a branch directly after cloning the fork, and pushing to the branch)
[15:01] <aixtools> i would guess that git+ssh://aixtools@git.launchpad.net/~aixtools/cloud-init is air atm - my actual id is currently something else though. I should probably try to 'get' aixtools.
[15:01] <nacc> aixtools: a remote is just a definition of a repository (typically one you care to track)
[15:01] <nacc> aixtools: you should always be able to read a defined remote (fetch) and you can sometimes write (push)
[15:02] <nacc> aixtools: so often you have at least one remote, 'origin' e.g., if you use git-clone
[15:03] <aixtools> reading and thinking... thanks...
[15:03] <nacc> aixtools: you can have multiple, though, e.g., in launchpad, you might have one for origin (git://) (which I often call upstream) for the main cloud-init repository, then you'd have one for your lp user's repository itself (git+ssh://) (which you'd be able to right to)
[15:03] <jgrimm> nacc, for context, i believe aixtools is reading this and trying to grok ->https://github.com/openstack/cloud-init/blob/master/HACKING.rst
[15:04] <nacc> jgrimm: ack, that should probably be updated to the lp git tree?
[15:05] <aixtools> e.g., the one line that should be two lines, or at least have ";" before cd cloud-init.
[15:05] <jgrimm> bah, that' s the wrong one indeed!
[15:05] <jgrimm> google got me, sorry
[15:05] <aixtools> well, I found a pdf, labeled ...0.7.8 as the cloudinit.readthedocs.io URL seems to be gone
[15:06] <rharper> http://cloudinit.readthedocs.io/en/latest/
[15:06] <jgrimm> https://git.launchpad.net/cloud-init/tree/HACKING.rst
[15:06] <aixtools> it is back! yes, http://cloudinit.readthedocs.io/en/latest/topics/hacking.html
[15:06] <jgrimm> there we go, that's better
[15:06] <rharper> git clone YOUR_USERNAME@git.launchpad.net:cloud-init cd cloud-init
[15:07] <aixtools> same content as the PDF I found
[15:07] <rharper> yeah that's just mal-formated markdown
[15:07] <aixtools> FYI, not meaning to be fussy
[15:07] <nacc> the hacking.rst has it has newline separated
[15:08] <aixtools> or - I take being a noob seriously ;)
[15:11] <aixtools> a bit serious - git is still a bit of 'magic' to me. I have been speaking with people who have been using it for 7+ years and there are, I expect many things that seem natural and logical. For me, atm, they are just key-strokes. There is probably one or more excellent books - I just have not found them yet.
[15:12] <aixtools> Since we are, more or less on the same page - you know what I am reading - is now a good time to have a noob attempt something else?
[15:13] <smoser> git for sure takes time to become comfortable with.
[15:14] <smoser> yeah, that HACKING.rst is just wrong i think
[15:16] <NerdyBiker> @smoser ah okay :( getting a bit tricky now. also, that previous issue with omnibus, si that an issue for someone to take a loko at? is it trackable?
[15:17] <aixtools> well, I am willing to be a guinea-pig, if it helps to get it right.
[15:17] <smoser> NerdyBiker, i'm not really sure. you can file a bug against cloud-init.
[15:18] <smoser> i'd be interestedi in knowing if 16.04 works for you
[15:18] <smoser> and if it works for you with packages rather than omnibus
[15:18] <smoser> omnibus really amounts to a moving target
[15:18] <smoser> basically wget <url> | sudo sh
[15:19] <smoser> (i realize they're managing the thing that gets executed, and that its probably more secure than that , but the point is it can change at any point and i've not ever really looked at how it works)
[15:21] <NerdyBiker> @smoser we're using centos so ubuntu isn't a useful test case unfortunately :( I'll see with packages and test that
[15:22] <smoser> NerdyBiker, i knew you were centos.  you can try packages on centos too
[15:22] <smoser> i just didn't know if that path works at all, or if omnibus is all that works there.
[15:25] <NerdyBiker> @smoser was referring to the 16.04 comment, unless that wasn't to me :D
[15:25] <smoser> yeahm, i know.
[15:26] <smoser> i dont know if use-packaging path works on centos
[15:26] <smoser> it *should* work on ubuntu
[15:26] <smoser> i have more confidence in that :)
[15:53] <aixtools> still having issues, will come back when I have more time.
[15:53] <aixtools> thx for assistence.
[15:53] <aixtools> afk
[16:55] <NerdyBiker> @smoser haha okay :D finding a work around for now then will dedicate soem time to checking it out and filing an issue
[18:35] <robjo> :q
[18:36] <robjo> Could use some help sorting out an issue
[18:37] <robjo> in order to break the systemd cycle that was present in the 0.7.8 release I patched my package with the cloud-init.service file from master
[18:38] <robjo> problem is I cannot get that phase, i.e. cloud-init to run thus there is no ssh key added to the image
[18:39] <robjo> I also tried to add it to the multi-user target instead of cloud-init target but to no avail
[18:39] <robjo> I am about out of answers and somewhat tired of banging my head against the wall
[18:42] <robjo> when I create a volume from the failed system and then attache it to a working system, chroot to the volume and then run cloud-init init the ssh key gets added, thus I think it is a problem with getting the code executed
[18:43] <smoser> robjo, suse ?
[18:43] <smoser> i suspect,as you do that its not getting run.
[18:43] <robjo> smoser: yes, I am still trying to get 0.7.8 to work properly :(
[18:44] <smoser> so i'd backdoor the image in some way so you can get in even if it does not run
[18:44] <smoser> and then look around at journalctl for some help
[18:44] <robjo> so what is the reason behind using DefaultDependencies=no in the unit files?
[18:46] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1611074
[18:46] <smoser> i really do hope that 'git log systemd/' will tell you such things or at very least point you to bugs.
[18:47] <smoser> and we've had some annoying fallout also, wrt systemd-resolved
[18:58] <robjo> smoser: my cloud-init.service file already looks like this patch, with the exception that I still had a Before-dbus.socket entry
[19:02] <smoser> that probably wasnt causing issue, robjo
[19:02] <smoser> unless you were using dns in the cloud-init.service and you're running systemd-resolvd. but anway.
[19:02] <smoser> what i'd do is make sure you can get intot he image either via ssh or local log in and then collect journalctl and hope to find some help there.
[19:03] <smoser> i suspect something is getting dropped or fails
[19:06] <robjo> well the messages file has Cloud-init v. 0.7.8 running 'init-local'
[19:06] <robjo> Starting Cloud-config
[19:07] <robjo> cloud-init[7479]: Cloud-init v. 0.7.8 running 'modules:config'
[19:07] <robjo> cloud-init[7492]: Cloud-init v. 0.7.8 running 'modules:final'
[19:07] <robjo> and also:
[19:07] <robjo> cloud-init[7492]: ci-info: no authorized ssh keys fingerprints found for user root.
[19:08] <robjo> this last one is a bit curious
[19:19] <smoser> hmm.
[19:19] <smoser> you dont get cloud-init to run
[19:19] <smoser> because networkign isnt coming up
[19:19] <smoser> i think or is failing.
[19:22] <robjo> Yes, that's the conclusion I came to, and looking at the service file again it has: Before=network-online.target
[19:22] <smoser> right.
[19:22] <smoser> that is by design.
[19:22] <smoser> that is a target that other things would wait on
[19:22] <smoser> and cloud-init wants to run after networking is up, but before that
[19:23] <robjo> but according to https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ that is the target the means the newtork is up and running, thus we can reach out and get the ssh key
[19:23] <smoser> so that other things waiting on networking will have cloud-init.service run before them.
[19:23] <smoser> what brings up your networking on suse ?
[19:24] <robjo> well the network is up after ifup, but it's not useful until wicked does it's magic
[19:24] <smoser> ok..
[19:24] <smoser> so how do we know that wicked is finished doing its magic
[19:25] <smoser> After=wicked-did-magic.service
[19:25] <robjo> but that should be equivalent to After=network-onlie
[19:26] <robjo> clearly I am not understanding one of the concepts here :(
[19:26] <smoser> sure. thats true.
[19:26] <smoser> what we *want* is:
[19:26] <smoser>  a.) something brings networking fully up
[19:27] <smoser>  b.) cloud-init.service runs
[19:27] <smoser>  c.) network-online.target is reached
[19:27] <smoser> that way, cloud-init gets a bottleneck point as early in boot as it can
[19:28] <smoser> if cloud-init.service ran 'After=network-online.target' then anything else that ran at that point would be racing with cloud-init.
[19:28] <smoser> and if the user had provided some user-data to modify behavior of those things, then they'd be racey
[19:30] <robjo> OK, so I'll try Before: network-online.service and After: wicked.service
[19:31] <robjo> wicked.service is in network-online.target.wants
[19:31] <robjo> so that should give us what we are after, fingers crossed
[19:32] <smoser> you'd think that wicked.service should be Required by network-onlknie.target
[19:32] <smoser> other wise, network-online.target would possibly fire when there was no network on line
[19:34] <robjo> wicked.service runs Before=network-online.target network.target
[19:34] <robjo> so I think the order is going to turn out to be correct
[19:35] <robjo> and here we alsways thought sysvinit ordering was hell
[19:36] <smoser> robjo, i have a soft spot in my heart for sysvinit.
[19:39] <robjo> I was never a big fan simply because I am not a fan of shell scripts, but it did have its positives
[19:40] <robjo> we the exception of course that we on the distribution end made a mess of it and all had little tweaks that were slightly diferent and annoying to deal with
[19:40] <robjo> systemd at least resolved that issue
[19:40] <robjo> with the exception that in ubuntu it appears to be networking.service instead of network.service :(
[19:41] <robjo> now lets see what this next round of builds produces.....
[20:00] <smoser> they're different.
[20:00] <smoser> networking.service is like your wiked
[20:00] <smoser> wicked
[20:00] <smoser> its what brings up the networking.
[20:10] <robjo> OK, so I need to sed -i s/networking/wicked/ and not sed -i s/networking/network/
[20:11] <robjo> alright I'll fiddle with the patch again..... my changelog is getting really ugly
[20:11] <robjo> someone will love me for it one day ;)