[07:42] rharper thanks! I totally forgot the instance-specific cloud places [08:31] o/ anyone listening [08:31] I am trying to clone cloud-init, but nothing seems to be 'cloning' [08:32] my local directory gets made, then quiet. While with github - works fine. [08:33] I am using: git clone myrealuid@git.launchpad.net:cloud-init to clone. [08:34] and in case noone has noticed http(s)://cloudinit.readthedocs.io no longer seems to exist. [08:52] afk but hope to read a hint later :) [10:12] awake anyone? [10:13] after forever, my git clone .... command ended with (excerpt) [10:13] ]Read from socket failed: Connection reset by peer [10:14] fatal: Could not read from remote repository. [10:16] 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] git clone YOUR_USERNAME@git.launchpad.net:cloud-init - shouldn't that just be [10:17] git clone git.launchpad.net:cloud-init ? trying it anyway... [10:18] ok, that fails with: Launchpad user 'michael' doesn't have a registered SSH key [10:19] 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] 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] NerdyBiker, i ddont really think you can. it'd be nice, but there is no template on write file content. [13:23] what you'd have to do is use boothook to execute data that read that and wrote your file. [13:24] aixtools, well, you can only use git+ssh if you have a launchpad user and registered keys. [13:24] but you can read-only clone with git://git.launchpad.net/cloud-init [13:25] or http://git.launchpad.net/cloud-init (or https) [14:40] thank you @smoser - using the git:// for the copy - er clone - as I do not expect to have write perms :) [14:41] aixtools, well, with git+ssh:// you can push back to launchpad for your branch. [14:41] (independent of having commit access to master) [14:42] s/branch/repo/ ; s/master/cloud-init official repo/ [14:44] well, i thought that was what the next line was for... "git remote add USERID USERID@git.launchpad.net:~USERID/cloud-init [14:45] -- trying to follow your documentation. [14:47] 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] however, if d) happens (IBM finishes first AND it is in the official branch - I shall just sit back and relax :) [14:52] @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] aixtools, sorry. sed syntax an aixer should know that ;) [14:53] but not clear on what you mean. It is "whatever works" for collaboration with the intent to introduce a new platform. [14:53] so you can always clone from git://git.launchpad.net/cloud-init [14:53] that will work, and then you can commit locally and be happy [14:53] but if you want to push to a remote git repo, then you can push to: [14:54] i know sed - used to use it years ago to automate some of my assembly code on the PDP-11. [14:54] git+ssh://aixtools@git.launchpad.net/cloud-init [14:54] shoot... sorry. you can push to [14:54] but it is knowing what 'branch', 'repo', etc. mean. Still grasping with those :) [14:55] git+ssh://aixtools@git.launchpad.net/~aixtools/cloud-init [14:55] a git "repo" (repository) contains multiple branches. [14:56] 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] 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] (with making a branch directly after cloning the fork, and pushing to the branch) [15:01] 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] aixtools: a remote is just a definition of a repository (typically one you care to track) [15:01] aixtools: you should always be able to read a defined remote (fetch) and you can sometimes write (push) [15:02] aixtools: so often you have at least one remote, 'origin' e.g., if you use git-clone [15:03] reading and thinking... thanks... [15:03] 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] 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] jgrimm: ack, that should probably be updated to the lp git tree? [15:05] e.g., the one line that should be two lines, or at least have ";" before cd cloud-init. [15:05] bah, that' s the wrong one indeed! [15:05] google got me, sorry [15:05] well, I found a pdf, labeled ...0.7.8 as the cloudinit.readthedocs.io URL seems to be gone [15:06] http://cloudinit.readthedocs.io/en/latest/ [15:06] https://git.launchpad.net/cloud-init/tree/HACKING.rst [15:06] it is back! yes, http://cloudinit.readthedocs.io/en/latest/topics/hacking.html [15:06] there we go, that's better [15:06] git clone YOUR_USERNAME@git.launchpad.net:cloud-init cd cloud-init [15:07] same content as the PDF I found [15:07] yeah that's just mal-formated markdown [15:07] FYI, not meaning to be fussy [15:07] the hacking.rst has it has newline separated [15:08] or - I take being a noob seriously ;) [15:11] 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] 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] git for sure takes time to become comfortable with. [15:14] yeah, that HACKING.rst is just wrong i think [15:16] @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] well, I am willing to be a guinea-pig, if it helps to get it right. [15:17] NerdyBiker, i'm not really sure. you can file a bug against cloud-init. [15:18] i'd be interestedi in knowing if 16.04 works for you [15:18] and if it works for you with packages rather than omnibus [15:18] omnibus really amounts to a moving target [15:18] basically wget | sudo sh [15:19] (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] @smoser we're using centos so ubuntu isn't a useful test case unfortunately :( I'll see with packages and test that [15:22] NerdyBiker, i knew you were centos. you can try packages on centos too [15:22] i just didn't know if that path works at all, or if omnibus is all that works there. [15:25] @smoser was referring to the 16.04 comment, unless that wasn't to me :D [15:25] yeahm, i know. [15:26] i dont know if use-packaging path works on centos [15:26] it *should* work on ubuntu [15:26] i have more confidence in that :) [15:53] still having issues, will come back when I have more time. [15:53] thx for assistence. [15:53] afk [16:55] @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] :q [18:36] Could use some help sorting out an issue [18:37] 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] 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] I also tried to add it to the multi-user target instead of cloud-init target but to no avail [18:39] I am about out of answers and somewhat tired of banging my head against the wall [18:42] 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] robjo, suse ? [18:43] i suspect,as you do that its not getting run. [18:43] smoser: yes, I am still trying to get 0.7.8 to work properly :( [18:44] so i'd backdoor the image in some way so you can get in even if it does not run [18:44] and then look around at journalctl for some help [18:44] so what is the reason behind using DefaultDependencies=no in the unit files? [18:46] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1611074 [18:46] i really do hope that 'git log systemd/' will tell you such things or at very least point you to bugs. [18:47] and we've had some annoying fallout also, wrt systemd-resolved [18:58] 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] that probably wasnt causing issue, robjo [19:02] unless you were using dns in the cloud-init.service and you're running systemd-resolvd. but anway. [19:02] 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] i suspect something is getting dropped or fails [19:06] well the messages file has Cloud-init v. 0.7.8 running 'init-local' [19:06] Starting Cloud-config [19:07] cloud-init[7479]: Cloud-init v. 0.7.8 running 'modules:config' [19:07] cloud-init[7492]: Cloud-init v. 0.7.8 running 'modules:final' [19:07] and also: [19:07] cloud-init[7492]: ci-info: no authorized ssh keys fingerprints found for user root. [19:08] this last one is a bit curious [19:19] hmm. [19:19] you dont get cloud-init to run [19:19] because networkign isnt coming up [19:19] i think or is failing. [19:22] Yes, that's the conclusion I came to, and looking at the service file again it has: Before=network-online.target [19:22] right. [19:22] that is by design. [19:22] that is a target that other things would wait on [19:22] and cloud-init wants to run after networking is up, but before that [19:23] 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] so that other things waiting on networking will have cloud-init.service run before them. [19:23] what brings up your networking on suse ? [19:24] well the network is up after ifup, but it's not useful until wicked does it's magic [19:24] ok.. [19:24] so how do we know that wicked is finished doing its magic [19:25] After=wicked-did-magic.service [19:25] but that should be equivalent to After=network-onlie [19:26] clearly I am not understanding one of the concepts here :( [19:26] sure. thats true. [19:26] what we *want* is: [19:26] a.) something brings networking fully up [19:27] b.) cloud-init.service runs [19:27] c.) network-online.target is reached [19:27] that way, cloud-init gets a bottleneck point as early in boot as it can [19:28] 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] and if the user had provided some user-data to modify behavior of those things, then they'd be racey [19:30] OK, so I'll try Before: network-online.service and After: wicked.service [19:31] wicked.service is in network-online.target.wants [19:31] so that should give us what we are after, fingers crossed [19:32] you'd think that wicked.service should be Required by network-onlknie.target [19:32] other wise, network-online.target would possibly fire when there was no network on line [19:34] wicked.service runs Before=network-online.target network.target [19:34] so I think the order is going to turn out to be correct [19:35] and here we alsways thought sysvinit ordering was hell [19:36] robjo, i have a soft spot in my heart for sysvinit. [19:39] I was never a big fan simply because I am not a fan of shell scripts, but it did have its positives [19:40] 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] systemd at least resolved that issue [19:40] with the exception that in ubuntu it appears to be networking.service instead of network.service :( [19:41] now lets see what this next round of builds produces..... [20:00] they're different. [20:00] networking.service is like your wiked [20:00] wicked [20:00] its what brings up the networking. [20:10] OK, so I need to sed -i s/networking/wicked/ and not sed -i s/networking/network/ [20:11] alright I'll fiddle with the patch again..... my changelog is getting really ugly [20:11] someone will love me for it one day ;)