[01:10] <smoser> blackboxsw, \o/ looks good.
[01:10] <smoser> you can have it drop the bug and the author from the comment.
[01:11] <smoser> and probably easier (or at least easy) to get log2dch  to do it.
[02:00] <smoser> blackboxsw, https://gist.github.com/smoser/813c84bc7a79efc75d3f7fc2f383f12f now has '--trello'
[02:02] <smoser> http://paste.ubuntu.com/25683387/
=== meetingology` is now known as meetingology
[02:07] <cali_boxer> hello
[02:08] <cali_boxer> we're having an issue with cloud-init on openstack
[02:08] <cali_boxer> we have a new ga image based on centos 7.3.1611
[02:09] <cali_boxer> cloud-init is grabbing the first software_config element from the heat template, but it never informs heat that it has completed the operation
[02:09] <cali_boxer> the stack-build subsequently fails
[02:10] <cali_boxer> after timing-out
[02:10] <cali_boxer> I've spent a few days on this, and can't get further on this,
[02:10] <cali_boxer> we're on openstack-liberty
[02:11] <cali_boxer> all pre-reqs are in the image
=== mgagne is now known as Guest66098
[02:35] <smoser> cali_boxer, can you give a /var/log/cloud-init.log ?
[02:35] <smoser> whatever cloud-init would be doing would be in there.
[12:26] <Junaid> hello
[12:26] <Junaid> i want to ask something
[12:53] <smoser> Junaid, whats up?
[14:25] <cali_box_web> hello
[14:25] <cali_box_web> I need support for cloud-init
[14:26] <cali_box_web> is there anyone who can assist?
[14:37] <smoser> cali_box_web, whats up?
[14:38] <cali_box_web> I have an openstack build that partially works
[14:38] <cali_box_web> the system will build the ste stacks
[14:39] <cali_box_web> but...
[14:39] <cali_box_web> cloud-init on some of the instances, does not signal the completion of the software_config section
[14:39] <cali_box_web> the section is correctly deposited onto the system (ssh keys, hosts file)
[14:40] <cali_box_web> but does not signal completion
[14:40] <cali_box_web> this does work on other members in the stack that are Centos 7.2
[14:40] <cali_box_web> the system in target is a customized version of Centos 7.3
[14:40] <cali_box_web> 1611
[14:40] <cali_box_web> cloudinit 0.7.9 is used on the new image
[14:41] <cali_box_web> 0.7/5 is used on the centos 7.3
[14:41] <cali_box_web> er 7.2
[14:41] <cali_box_web> the image in question is custom centos 7.2 linux
[14:41] <cali_box_web> it has all pre-reqs as far as i can see
[14:42] <smoser> can you pastebin a /var/log/cloud-init.log ?
[14:42] <cali_box_web> from the client?
[14:42] <cali_box_web> sure
[14:42] <cali_box_web> just a few
[14:44] <smoser> yeah
[14:51] <cali_box_web> trying to figure out how to pastebin from putty
[14:51] <cali_box_web> just a sec
[14:56] <cali_box_web> https://pastebin.com/By0CwW9q
[14:58] <cali_box_web> i can post a sanitized yaml file from the office
[15:02] <cali_box_web> this is openstack liberty btw
[15:22] <smoser> cali_box_web, the error there (search for WARN) i think is that some part of your user-data does not start with '#!'
[15:23] <cali_box_web> there is no user-data
[15:24] <smoser> i think there is..
[15:24] <cali_box_web> https://pastebin.com/QD3cqaBq
[15:25] <smoser> private paste?
[15:26] <cali_box_web> web client doesn't allow that
[15:26] <smoser> oh. i meant it tells me it is a privarte paste
[15:26] <cali_box_web> yes
[15:27] <cali_box_web> let me see if I can post as something else
[15:27] <smoser> is that a public system ? i can hop in if you'd like and poke around, but *something* made cloud-init think that you had a script to be executed (i think heat does that)
[15:27] <cali_box_web> it's not public
[15:27] <smoser> but the script did not start with a '#!' or otherwise kernel-recognizable format
[15:27] <cali_box_web> whats your email i can send you the santized template
[15:31] <smoser> can you just collect all of /var/log/cloud-init* and /var/lib/cloud/ ?
[15:31] <smoser> send to scott.moser@canonical.com .
[15:31] <cali_box_web> yes
[15:31] <cali_box_web> thanks
[15:39] <cali_box_web> sent from my work email
[15:47] <smoser> cali_box_web, i tihnk it borked the content
[16:14] <Junaid> is there anyway to trace cloud data centre?
[16:15] <Junaid> i want dataset of locations of data centres
[16:49] <Junaid> Can anyone tell me about it?
[16:49] <Junaid> Please
[16:50] <cali_boxer> @smoser, I'll resend as links
[16:52] <smoser> Junaid i'm not sure what you're after.
[16:56] <Junaid> how can i trace x,y coordinates of cloud data centres?
[16:56] <Junaid> i want to know exact locations of data centres
[16:57] <gholms> I'm pretty sure that is out of the scope of this channel.
[16:59] <Junaid> then where can i get it? can you tell me channel name where i can raise this question?
[17:06] <cali_boxer> smoser, logs have been sent
[17:07] <cali_boxer> i added the user_data section, which is getting parsed, and deposits /var/lib/cloud/instances/scripts/userdata but the system still does not complete a checkin letting heat know that it has performed the action
[17:18] <blackboxsw> hrm Junaid I think you'd have to send a request to cloud vendors specifically. and some of them may not provide that specific information due to privacy concerns
[17:19] <blackboxsw> I know my former company wanted to keep their datacenter locations confidential for one reason or another
[17:28] <blackboxsw> smoser: shall I start on SRU MP for cloud-init?
[17:30] <smoser> yeah
[17:35] <cali_boxer> smoser, were you able to see anything in the logs?
[17:35] <cali_boxer> on the second set?
[17:37] <smoser> cali_boxer, i'm not sure you sent what i wanted ?
[17:37] <smoser> i need /var/lib/cloud/ directory
[17:42] <cali_boxer> that was in the second link
[17:42] <cali_boxer> the lins from our sync.domain.com
[17:47] <smoser> cali_boxer, http://paste.ubuntu.com/25687216/
[17:47] <smoser> that is in /var/lib/cloud/<instance-id>/user-data.txt
[17:48] <smoser> whatever sent that user-data, sent an empty file that was "type" of text/x-shellscript;
[17:48] <smoser> cloud-init did what it is supposed to do (rather blindly) and put that into a file and executed it
[17:48] <smoser> and that resulted in the error you see
[17:48] <cali_boxer> ok
[17:48] <smoser> admittedly cloud-init coudl say "oh that doesnt make any sense" and fail in a nicer way.
[17:48] <cali_boxer> I modified the yaml file after your suggestion
[17:48] <smoser> but very clearly that is the "garbage in" part of "garbage in -> garbage out"
[17:49] <cali_boxer> i now send a valid user_data containing, #!/bin/sh \n echo "hello"
[17:49] <cali_boxer> which executes
[17:50] <cali_boxer> but the system still doesn't respond back to the metadata agent saying thatthe step is complete
[17:54] <smoser> well, what you sent died because of the empty user-data
[17:54] <smoser> i can't diagnose a different failure without more ifo
[17:54] <smoser> info
[17:55] <cali_boxer> fair enough.
[17:55] <cali_boxer> i'll send a new set
[17:55] <cali_boxer> stand by
[18:08] <cali_boxer> items sent
[18:10] <smoser> blackboxsw, http://paste.ubuntu.com/25687335/
[18:12] <smoser> (from #ubuntu-devel)
[18:19] <blackboxsw> thanks joining that channel now too
[18:22] <smoser> cali_boxer, well, i think i know what is wrong. i think that you didn't actually get networking up before cloud-init went to look for the metadata service (provided by openstack on 169.254.169.254)
[18:22] <smoser> i'm not sure why that would differ between the two.
[18:25] <cali_boxer> odd, since the unit file should have a want for networking
[18:25] <cali_boxer> my co-worker discovered a potential issue as well
[18:26] <smoser> so there are 2 boots in your log.
[18:26] <cali_boxer> it looks like salt-master/minion was not on the image
[18:26] <cali_boxer> there are
[18:26] <cali_boxer> i may not have cleaned the log after sealing the image
[18:26] <cali_boxer> i've added it and am uploding the image to OS now
[18:27] <smoser> i'm not reallky able to look  much deeper.
[18:27] <smoser> i'm pretty sure that networking doesnt end up coming up.
[18:28] <smoser> perhaps you have some sysconfig configuration in /etc/sysconfig/network  that is messing it up.
[18:28] <smoser> in that second log you sent there are 2 boots, one worked, one failed.
[18:28] <smoser> blackboxsw, so what that means... is that we should (I will) make a metabug
[18:29] <cali_boxer> ok, thank you for your help,
[18:29] <cali_boxer> I'll let you know if the salt thing fixes it
[18:30] <blackboxsw> so smoser as with curtin, cloud-init will link related bugs to the merge proposal, but not list them in final changelog for release. Only list the master bug
[18:31] <smoser> yeah.
[18:36] <smoser> bug 1721847
[18:36] <ubot5> bug 1721847 in cloud-init (Ubuntu Zesty) "sru cloud-init 2017-10-06 (17.1-17-g45d361cb-0ubuntu1)" [Medium,Confirmed] https://launchpad.net/bugs/1721847
[18:36] <smoser> blackboxsw, ^
[18:40] <blackboxsw> thx smoser working through https://gist.github.com/smoser/6391b854e6a80475aac473bba4ef0310 right?
[18:41] <smoser> https://gist.github.com/smoser/6391b854e6a80475aac473bba4ef0310#file-ubuntu-release-process-md
[18:41] <smoser> yes
[18:42] <smoser> i'm working on filling out that bug with more info
[18:42] <smoser> and you will drop the LP: refernces in the generated changelog
[18:49] <smoser> blackboxsw, fyi, what i did there was just
[18:49] <smoser>  git cherry-pick 833c9d6570dd2bfe695c596f744bc70c292a25e5
[18:49] <smoser> on each branch
[18:49] <smoser> and then manually update changelog
[18:49] <smoser> and git commit -m "update changelog"
[18:50] <smoser> the hash above as found on ubuntu/devel branch
[18:52] <blackboxsw> +1 on that thanks
[18:54] <smoser> blackboxsw, one thing the changelog generation doesnt do..
[18:54] <smoser> 1717477 is already fixed, but the changelog will show it
[18:54] <smoser> so we should drop that line from the commit message
[18:54] <smoser> (as it was sru'd already)
[19:13] <blackboxsw> smoser: ok I'm in the hangout to plow through Xenial
[19:16] <smoser> ok. 5 minutes
[19:16] <smoser> k ?
[19:16] <smoser> (ill be there in)
[19:16] <blackboxsw> yeah no worries
[19:16] <blackboxsw> will walk you through what I think I've done
[19:28] <smoser> blackboxsw, i'm here now.
[20:31] <blackboxsw> smoser: zesty's changelog has mix of zesty-proposed and zesty in recent changelogs
[20:31] <blackboxsw> shall I make changelog distro zesty-proposed from here on?
[20:31] <nacc> blackboxsw: it shouldn't really matter
[20:32] <nacc> blackboxsw: as uploads go to zesty-proposed anyways
[20:32] <nacc> blackboxsw: (speaking generally)
[20:32] <blackboxsw> ok nacc was just trying to figure if we needed/wanted  a  convention from here on
[20:32] <nacc> blackboxsw: yeah, i would suggest using zesty not zesty-proposed, imo
[20:32] <blackboxsw> as SRUs will go into *-proposed for real
[20:32] <nacc> (in the changelog)
[20:32] <nacc> as that is the 'release' you are targetting
[20:32] <smoser> blackboxsw, yeah, thats what i was saying. it doesnt matter. i prefer -proposed as i just think its cleaner
[20:32] <nacc> heh
[20:32] <smoser> but then somebody always messes up
[20:32] <smoser> (probably it was me)
[20:32] <smoser> :)
[20:33] <blackboxsw> don't make me git blame ;)
[20:33] <smoser> i just like the clean break from 'xenial' to 'xenial-proposed' as it is then easy to see what was GA
[20:33] <smoser> but really, no one other than me probably ever looks :)
[20:33] <nacc> smoser: oh that's a good point, xenial-updates would work just as well
[20:33] <nacc> smoser: but yeah, your point is valid
[20:33] <blackboxsw> it's good to have a line in the sand or something.  I'm all for doc breadcrumbs whereever we can leave them.
[20:33] <blackboxsw> :)
[20:34] <blackboxsw> ok I'll go zesty-proposed for this commit as that's a convention we've kinda used in xenial for cloud-init
[20:34] <blackboxsw> and attempted in zesty, when we didn't forget
[20:35] <blackboxsw> it's official, I 💗 Chris Columbus. Not working on Monday
[20:36] <smoser> blackboxsw, you were so close to the statue in Central Park.
[20:41] <blackboxsw> I should go back sometime.... like next week :)
[20:45] <blackboxsw> smoser: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/331975
[20:45] <blackboxsw> I'm testing build now
[20:50] <blackboxsw> smoser: I just saw Get:1 http://archive.ubuntu.com/ubuntu zesty/universe amd64 python3-httpretty all 0.8.14-1 [19.5 kB] from apt build-dep.... which is ok right because that's pulling build-deps from current published upstream
[20:50] <blackboxsw> which still depends on httpretty
[20:50] <blackboxsw> which we are dropping
[20:50] <smoser> right
[20:50] <smoser> s/upstream/packaged version/
[20:50] <smoser> its pulling it from apt source info
[20:51] <blackboxsw> hrm, why do I see                python3-httpretty, in debian/control on zesty
[20:51] <blackboxsw> checking the built package details now to make sure it was patched out of there
[20:54] <blackboxsw> yep safe/correct
[20:57] <dhill_> hi guys
[20:57] <smoser> blackboxsw, hey
[20:58] <smoser> wait. what ?
[20:58] <blackboxsw> why am I seeing Changelog w/ bugs linkedhmm
[20:58] <smoser> blackboxsw, i just diffed xenial (your propseod) to artful
[20:58] <smoser> and found
[20:59] <smoser>  http://paste.ubuntu.com/25688137/
[21:00] <blackboxsw> looking at the paste
[21:01] <smoser>  more useful
[21:01] <smoser>  http://paste.ubuntu.com/25688142/
[21:01] <smoser> blackboxsw, ^
[21:01] <smoser> the thing i noticed really was the apport launcher
[21:01] <smoser> think we'd want that.
[21:02] <smoser> :-(
[21:02] <blackboxsw> right we don't have apport official integration without it right?
[21:02] <blackboxsw> so xenial and zesty both need it don't they?
[21:03] <blackboxsw> I was difffing against ubuntu/xenial and didn't see the apport diff
[21:03] <blackboxsw> *I dont think*
[21:03] <blackboxsw> sure enough
[21:04] <smoser> i can account fo rhte other changes there, they make sense.
[21:04] <smoser> even that last one which looks suspiciouls (-aws) its ok.
[21:05] <blackboxsw> so I need to resubmit MPs for xenial and zesty and bring in debian/apport-launcher.py
[21:05] <smoser> but i'm tempted to cherry pick
[21:05] <smoser>  2baa6bf9c314630ec29a192e1e81f0f4530cb102
[21:05] <smoser>  fec2d4a87fcff72aa9cafbfb88fff013a17db665
[21:06] <blackboxsw> should that have been pulled in from debian/new-upstream-snapshot ?
[21:07] <blackboxsw> no because it is querying tip of master no ubuntu/devel right?
[21:07] <smoser> no. those are ubuntu/devel changes
[21:07] <smoser> we dont merge from ubuntu/devel
[21:07] <smoser> we could .
[21:07] <smoser>  we dont
[21:07] <blackboxsw> yeah ok makes sense
[21:07] <blackboxsw> so cherry pick, new MP including those cherry picks for zesty and xenial?
[21:08] <blackboxsw> you're EOW , I can hangout if you want to talk quickly through pro/cons
[21:10] <smoser> yeah, we can chat quick.
[21:40] <blackboxsw> ok zesty pushed again
[21:44] <smoser> i did a sbuild && dput && git push
[21:44] <smoser> so it might all just go
[21:45] <smoser> and since i 'git pull'ed it should mark your MP as done also
[21:45] <smoser> thanks chad!
[21:45] <blackboxsw> I'm testing the ubuntu-bug on my zesty container to be sure
[21:46] <blackboxsw> thanks again smoser. I'm scrubbing trello bugs listed now
[21:46] <blackboxsw> for the rest of the afternoon I presume
[21:47] <smoser> all done i think thanks chad.
[21:51] <sedition> hey team. fixed all my issues. all user error on my part. appreciate the patience. =)
[21:51]  * sedition is a derp sometimes
[21:52] <blackboxsw> I know the feeling sedition
[21:52] <sedition> im trying to learn terraform and cloud-init at the same time on top of my BAU job