[17:14] <blackboxsw> powersj: just got together an automated git-publisher tool which hopefully jenkins/CI can use. I ran the scrIpt against your https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/335051 and sorted the commit message content
[17:14]  * blackboxsw needs to setup the LP user for the bot to not be me :)
[17:15] <powersj> blackboxsw: nice! I wondered how you sent me a message about my commit message
[17:25] <powersj> blackboxsw: would be nice if the subject line had something to do with cloud-init btw
[17:26] <blackboxsw> powersj teaking it now. yeah was wondering where that "subject" field showed up as I don't see it anywhere on the comment  in the UI
[17:26] <blackboxsw> tweaking rather
[17:26] <blackboxsw> powersj: sorry couple more passes/comments on your branch as I test. please ignore them
[17:26] <powersj> :)
[17:26] <blackboxsw> actually, I'll just fake-approve my own branch
[17:27] <rharper> blackboxsw: btw, that's a pretty neat tool; effecitively a lander for git on launchpad, yeah ?
[17:27] <blackboxsw> rharper: yeah, that's where we are going with it. agreed. (and we don't really have to re-write tarmac
[17:27] <powersj> blackboxsw: what are you using?
[17:28] <blackboxsw> powersj: the magic of cloudinit.subp(['git', *]) and python3-launchpadlib
[17:28] <powersj> lol
[17:29] <blackboxsw> 110 line script. not too bad
[17:29] <blackboxsw> powersj: some of your ci tools already use laucnhpad lib or were they jenkins plugins?
[17:30] <powersj> blackboxsw: various tools do use it to query for example package uploads or bug triage
[17:30] <powersj> jenkins-launchpad-plugin of course uses it as the main interface
[17:35] <rharper> smoser: on the maas check_instance_id;  it wasn't clear to me if you had validated the 'restart cloud-init after upgrade but before reboot' w.r.t to a pickled object which doesn't have the 'hash_id' class member ... , the check_instance_id references self.hash_id in the 'if self.hash_id is None' but; I think we need a if hasattr('hash_id', self), right?
[17:46] <smoser> rharper: look at the paste there.
[17:46] <rharper> I did
[17:47] <rharper> but I didn't see how that mapped to code using an undefined class member via pickle
[17:47] <smoser> the python program basically does what we do and shows you can just use the attribute that is in the class.
[17:47] <rharper> but how is it different than the previous ec2 and azure case ?
[17:47] <smoser> http://paste.ubuntu.com/26177197/
[17:47] <smoser> i'm not really sur what problem we *did* see there.
[17:47] <smoser> but look at that paste
[17:48] <smoser> MyClass version 2 directly accesses self.newattr
[17:48] <smoser> which would *not* have been in the pickle
[17:48] <smoser> but is in the class definition
[17:48] <smoser> i think possibly before when we errored we did not add an attribute to the class
[17:49] <rharper> hrm
[17:49] <rharper> what I recall is stages asking got get_data() which referenced a self.<var>  which was not defined in the restored class
[17:50] <smoser> i think make we did not add it to the class in an attribute
[17:51] <rharper> it was a class attr
[17:51] <rharper> git show 281a82181716183d526e76f4e0415e0a6f680cbe
[17:52] <rharper> ok;  the new attr is present (and is None) but that was a bogus value
[17:52] <rharper> so, yes, I think you're right here; we don't expect a non-none value, if it is none (which it will be on a restore) we go and set the value (like we did with the property in that above commit)
[17:54] <rharper> hrm, now I don't see us setting self.hash_id in get_data()
[17:54] <rharper> shouldn't we set the value in the class ?
[17:57] <smoser> rharper: you're right. i dropped taht code i think on accident.
[17:57] <rharper> k
[17:59] <smoser> http://paste.ubuntu.com/26178030/
[18:00] <smoser> i had it, then i moved the thing to a function, and dleted the one occurence.
[18:00] <rharper> y
[18:29] <blackboxsw> smoser: rharper powersj : here are a couple of bot example messages  when voting 'Needs Fixing' and setting 'Work in progress'
[18:30] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335094/comments/877912
[18:30] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335094/comments/877913
=== r-daneel_ is now known as r-daneel
[18:31] <blackboxsw> WDYT? might need some wordsmithing/bike-shedding but I can put something up as an  MP for the ability for us to at least manually run git-publish to quickly merge branches. We can then build it into a CI-bot
[18:51] <powersj> blackboxsw: the needs-fixing message looks a bit weird due to odd line breaks. Content wise I think the issue that needs fixing should be first, not buried in the message.
[18:52] <powersj> I do think that maybe your bot should be added to the CI process, so the end user is not getting hit by both a CI bot and some other commit log bot
[19:01] <dpb1> powersj: +1
[19:01] <dpb1> powersj: and we should change the bot to have a different email address so it doesn't have powersj face on my screen all the time
[19:01] <powersj> haha
[19:01] <dpb1> :), but still, we should
[19:02] <powersj> yeah not sure how that is done
[19:03] <dpb1> wdym
[19:03] <powersj> well the address for the bot is josh.powers+server-team-bot@canonical.com
[19:03] <dpb1> powersj: let's use an alias for the bot
[19:04] <dpb1> powersj: server-crew-qa?
[19:04] <powersj> that's not a bad idea
[19:04] <powersj> as long as it doesn't create a whole bunch of extra mail to that list
[19:05] <powersj> I already get plenty of mail :)
[19:05] <powersj> getting rid of the bot would be nice
[19:05] <powersj> every merge request email is annoying x cloud-init, curtin, simplestreams, and git-ubuntu
[19:05] <dpb1> heh
[19:05] <dpb1> ya
[19:06] <dpb1> we can change notification prefs for that account
[19:06] <dpb1> I'm more wanting to fix the 'from' address
[19:07] <rharper> blackboxsw: interesting, note that the Launchpad wrap is like70  chars; which would make it easier to read
[19:07] <rharper> blackboxsw: also grammar/wordsmitthing
[19:07] <rharper> blackboxsw: but the real question is whose lp account gets that tasty bot karma ?
[19:08] <dpb1> good point
[19:08] <dpb1> think of what we could do... endless posibilities
[19:12]  * blackboxsw runs rharper I was thinking it'd ultimately be https://launchpad.net/~server-team-bot
[19:12] <blackboxsw> dunno where that '/me runs' came from.
[19:12] <rharper> karma bot gets karma
[19:12] <rharper> hehe
[19:13] <blackboxsw> yep, or rotating bot karma. to make sure we all get 5 digit karma so we can purchase that magazine subscription from the karma catalog
=== r-daneel_ is now known as r-daneel
=== ilianaw is now known as Guest79783
[22:28] <blackboxsw> whoops smoser, I totally misunderstood how cloud-init should work w.r.t. module config 'stages'
[22:28] <blackboxsw> thanks for the review
[22:29] <blackboxsw> will reject that branch (and all bot-voting comments) was worth the git-publish script test anyway
[22:40] <blackboxsw> smoser: oops right, so ok bootcmd, write_files,ssh, resizefs etc. should be run by in modules-init stage. Will peek at behavior running on the CLI cloud-init modules --mode init to confirm
[22:41] <blackboxsw> ... though, since the modules piggyback on init stage, why would we want to surface cloud-init modules --mode init?
[22:41] <blackboxsw> instead of just allowing "sudo cloud-init init" to take care of it
[22:44] <blackboxsw> or cloud-init --local
[22:45] <blackboxsw> given that we don't call it at all during system startup, should we even surface that particular option via CLI?
[22:45] <blackboxsw> ExecStart=/usr/bin/cloud-init modules --mode=config
[22:45] <blackboxsw> ExecStart=/usr/bin/cloud-init modules --mode=final
[22:45] <blackboxsw> ExecStart=/usr/bin/cloud-init init --local
[22:45] <blackboxsw> ExecStart=/bin/touch /run/cloud-init/network-config-ready
[22:45] <blackboxsw> ExecStart=/usr/bin/cloud-init init
[22:45] <blackboxsw> ^ list of what we call from systemd
[22:51] <powersj> smoser: thanks for review, I'm going to incorporate comments into ec2 merge proposal