[00:00] <smoser> sputnik13, i'm not opposed to having it extended to support lvm
[00:02] <sputnik13> smoser do you think it's better to extend growpart vs having a separate module for lvm?
[00:03] <smoser> i think it is most  useful if a signle executable can "do the right thing" personally.
[00:03] <smoser> with minimal depends.
[00:03] <harlowja> would it just be called 'part' instead of 'growpart'?
[00:03] <smoser> right now going forward, growpart works for gpt or mbr with just a dependency on sfdisk
[00:03] <harlowja> or better name
[00:03] <smoser> which is like everyone
[00:03] <smoser> and i'd like "growpart --any"
[00:03] <smoser> or something
[00:04] <harlowja> miraclegrowpart
[00:04] <smoser> it is kind of silly that you ahve to tell it which partition it needs to grow.
[00:04] <smoser> it looks and could quite easily know which partitions have space between them
[00:04] <harlowja> growpart --miracle
[00:04] <harlowja> lol
[00:05] <smoser> i have to run. sputnik13 i can look tomorrow at what is going wrong ther.
[00:05] <sputnik13> k, ttyl
[00:05] <sputnik13> growpart --magic
[00:06] <harlowja> growpart --ifeellucky
[03:19] <natorious> I'd noticed some issues w/ growpart and raid recently.  Wheres the issue tracker for that project?
[13:34] <smoser> natorious, cloud-utils
[13:34] <smoser> https://bugs.launchpad.net/cloud-utils/+filebug
[14:00] <natorious> aw sweet, thnx
[14:00] <natorious> https://bugs.launchpad.net/cloud-utils/+bug/1498930
[14:00] <natorious> who uses raid in the cloud lol
[14:01] <smoser> hm.
[14:01] <smoser> i'd think you  might have this same problem without growpart
[14:01] <smoser> if the md device was on an un-partitioned disk
[14:02] <smoser> and then you grew that disk
[14:02] <smoser> you'd still have "lost" that metadata.
[14:02] <smoser> right?
[14:02] <natorious> so if your to grow the raid volume say md126 or whatnot, it doesn't corrupt it
[14:03] <natorious> but if you grow say sda1 which is in raid 1 or 0 ex on md126, it would
[14:03] <smoser> right.
[14:03] <smoser> but if sda was not partitioned
[14:04] <smoser> and you "grew" that "physical volume"
[14:04] <smoser> in the host.
[14:04] <smoser> so there were zeros at the end
[14:04] <smoser> you'd then have busted that md device
[14:04] <smoser> right? ie, you cant just add zeros to a disk that has been used as a md
[14:04] <natorious> the physical volume or the raid volume
[14:04] <smoser> "physical"
[14:05] <smoser> /dev/vda
[14:05] <smoser> ie, its common in cloud/virt to just make a disk bigger.
[14:05] <smoser> shutdown. add zeros at the end. start up.
[14:05] <smoser> that would bust a md that was on an un-partitioned disk.
[14:06] <smoser> we're supposed to be having the cloud-inti 2.0 dev interlock right now.
[14:06] <natorious> if the disk isn't part of a raid volume w/ a filesystem, it shouldn't be an issue
[14:06] <smoser> so lets go do that right now.
[14:06] <natorious> if there is a filesystem and its raid 1, that same fs would show on sda
[14:06] <natorious> not raid 0 though
[14:06] <natorious> or most the others
[14:07] <natorious> k
[14:07] <smoser> k.  i think i'm right, but just not explaining well,. but maybe im' wrong.
[14:07] <natorious> np
[14:07] <smoser> http://bit.ly/cloudinit-reviews-public
[14:07] <smoser> cloud-inti 2.0 meeting time.
[14:07] <smoser> lets run through those really quick, and then smoser will actually look at them.
[14:08] <smoser> and maybe have some other work today on cloud-init.
[14:08] <smoser> ok. i just started reading claudiopopa's https://review.openstack.org/#/c/220095/
[14:08] <smoser> i will post some thoughts on it after this meeting.
[14:09] <smoser> then we have the task flow thing (which is much larger a python2.6 discussion really as Odd_Bloke is now a taskflow fanboy)
[14:10] <smoser> natorious, i'll take a quick look at your mp and have anyone else here interested do the sam.e
[14:11] <natorious> thnx
[14:18] <Odd_Bloke> o/
[14:18] <Odd_Bloke> I don't have anything new at the moment, I'm afraid.
[14:18] <Odd_Bloke> I'm heads down on some stuff that needs to happen for the next Ubuntu release.
[14:19] <Odd_Bloke> smoser: The Debian maintainer for taskflow has it building for Python 3 now, so that's another blocker gone.
[14:19] <Odd_Bloke> Well, a sync/merge away.
[14:21] <smoser> are we delta'd on it ?
[14:21]  * smoser swears at sillyness of <python>-<libraryname> as the source package name.
[14:22] <smoser> https://launchpad.net/ubuntu/+source/python-taskflow
[14:22] <smoser> we do have a delta.
[14:22] <Odd_Bloke> That looks like a fairly trivial delta.
[14:22] <smoser> ok. i'm goign to read over claudiopopa's review above, and will be around.
[14:22] <smoser> right, easy enough sync, i was just wondering if it was *no* sync
[14:23] <smoser> if its just a sync, i'm not oppsed to filing a bug and doing that in wily
[14:24] <smoser> above, the sillyness of python-libraryname is made abundently clear when <libraryname> drops python support and only works on python3.  meaning that the source packagek "python-libraryname" then only has binaries of "python3-libraryname".
[14:24] <smoser> anwyay... </rant>
[14:32] <natorious> the pip2dist stuff looks cool.  Would you need to follow cross platform dep changes though?
[15:14] <smoser> natorious, cross platform dep changes ?
[15:14] <smoser> oh. i think by nto allowing them :)
[15:15] <smoser> ie, if we're supporting a given OS, then stuff has to run in that. or it cant be accepted.
[15:18] <natorious> ah, nice catch on the misspelling btw.  I should remember to double check everythings when working late on weekends
[15:18] <smoser> i never make typos
[15:18] <smoser> (do not read 2 lines above where i spelled 'not' wrong)
[15:19]  * natorious chuckles
[15:20] <natorious> there was another bit with that buffer regarding behavior change that was glanced over in review
[15:20] <natorious> so as previously written the base's meta_data.json returned a buffer obj
[15:21] <natorious> and w/ the refactor bc it always has json suffix, it would be processed and returned as dict
[15:21] <natorious> and so http ds wouldn't be able to return the buffer attr from that
[15:21] <natorious> not sure if the dict or buffer would be preferred w/ something explicitly json
[15:22] <smoser> i think we want to rid of '.buffer' early rather than late.
[15:22] <natorious> k, cool.  Was trying not to change behavior for existing and had noticed that after the fact
[15:23] <smoser> so this is sort of wheere 0.7.x has userdata_raw and userdata (and vendordata_raw too)
[15:23] <smoser> its handled differently there, with  user-data and vendorddata , but maybe we want these unified.
[15:24] <natorious> vendordata and meta_data makes sense.  Userdata can be anything though right?
[15:24] <smoser> the difference being that cloud-init 0.7.x datasource puts in the vendordata the stuff that is meant for it.
[15:24] <smoser> versus *everything*
[15:24] <smoser> ie, in that json dict, it will only take out 'cloud-init' stuff  if there is such a thing there.
[15:25] <smoser> you are correct, yeah.
[15:25] <smoser> userdata is a binary blob
[15:25] <smoser> but user-data does have a similar behavior to vendor-data
[15:25] <natorious> so buffering for http would still be sufficient or were you saying axe it?
[15:25] <smoser> in that cloud-init might find some things intended for it
[15:25] <smoser> and some things not.
[15:26] <smoser> and kind of this is inconsistent in 0.7 . the way it handles.
[15:26] <smoser> i know i'm being confusing . sorry.
[15:26] <natorious> more so than usual but ok
[15:26] <smoser> :)
[15:26] <smoser> let me think.
[15:26] <natorious> the buffer was really the part that needed to go for the configdrive module to inherit from base
[15:27] <natorious> that was the primary reason for this
[15:27] <natorious> the refactoring and adding network json support in base would be needed for my test cases
[15:28] <natorious> to get it working with my openstack envs etc
[15:29] <smoser> so i dont think it makes sense for the user of userdata() to do .buffer
[15:29] <smoser> that seems silly.
[15:29] <natorious> I was thinking that was a req for http ds
[15:29] <natorious> but maybe no
[17:03] <sputnik13> alo alo alo
[17:11] <harlowja> smoser did i hear https://launchpad.net/ubuntu/+source/python-taskflow
[17:11] <harlowja> lol
[17:11] <harlowja> ding ding
[17:11] <harlowja> lol
[17:12] <harlowja> smoser hey, soooo about turning off bzr,,,,,,
[17:12] <harlowja> sputnik13 i think was wondering where to submit a 0.7.x patch
[17:12] <harlowja> annnnnddddd
[17:13] <smoser> harlowja, can i have 45 minutes and ping me back?
[17:13] <harlowja> 44.9 minutes
[17:13] <harlowja> lol
[17:14] <smoser> 44.6
[17:15] <smoser> ahh.. will that clock ever stop ticking!
[17:15] <harlowja> :-P
[17:20] <sputnik13> :)
[17:21] <sputnik13> ohhhh, taskflow packaged in to ubuntu...  harlowja's baby is moving up in the world :-D
[17:22] <harlowja> lol
[17:22] <harlowja> sputnik13 our baby
[17:22] <harlowja> haha
[17:22] <harlowja> errr
[17:22] <sputnik13> I'm just the step parent that's helping out and trying to win its affection, it was already birthed by the time I came around
[17:22] <sputnik13> :-D
[17:23] <sputnik13> this is spinning off in a weird direction, I'm going to stop now
[17:23] <sputnik13> :)
[17:23] <harlowja> lol
[17:23] <harlowja> def
[17:23] <harlowja> ubuntulog2 stop logging all this
[18:00] <harlowja> tiems up
[18:00] <harlowja> lol
[18:18] <gster> hi all, I am hitting this old bug here https://bugzilla.redhat.com/show_bug.cgi?id=836269 on cloud-init v 0.7.5 release 10.el7.centos
[18:22] <gster> do you know any workaround e.g set systemd timeout maybe?
[18:29] <harlowja> smoser come back
[18:29] <harlowja> lol
[18:30] <smoser> almost back.
[18:30] <smoser> stupid security
[18:37] <smoser> harlowja, ok.
[18:37] <smoser> focus-on-git time.
[18:37] <harlowja> lol
[18:37] <smoser> what do you have
[18:37] <harlowja> i have whatever u need man
[18:37] <harlowja> lol
[18:38] <harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-git-tarball-make might help
[18:38] <harlowja> but i guess we can further fix things that pop up
[18:39] <smoser> ok. let me take alook
[18:43] <harlowja> and i thinks https://github.com/harlowja/cloud-init/tree/0.7.x-fixed-final is the latest resync from bzr
[18:47] <harlowja> layered ontop of https://github.com/stackforge/cloud-init/tree/0.7.x
[18:57] <gster> harlowja: is this about the systemd timeout problem I  metionned earlier?
[18:58] <harlowja> gster nope, for that one not sure who is the best to respond (not me)
[18:58] <harlowja> some redhat person?
[18:58] <smoser> harlowja,
[18:58] <smoser> $ python setup.py --version
[18:58] <smoser> 0.7.7
[18:59] <smoser> (sorry to ignore you gster, but dont have time right now to look)
[18:59] <harlowja> smoser ?
[18:59] <smoser> it always shows that.
[18:59] <smoser> but i need a REVPOSTFIX
[18:59] <harlowja> no postfix for u
[18:59] <harlowja> lol
[19:02] <harlowja> smoser so integration of pbr will let u have a REVPOSTFIX because it makes one
[19:02] <harlowja> but for 0.7.x maybe in git-mode REVPOSTFIX can just be an env variable ?
[19:02] <gster> No problem smoser. I also found it in here https://github.com/sdake/heat-jeos/issues/1 on Fedora.. Quite a old bug though (2012)...
[19:12] <smoser> harlowja, ok. so some symantic differences between what you're suggesting and what i've done before.
[19:13] <harlowja> possibly
[19:13] <harlowja> from my understanding alot of openstack stuff has the following
[19:14] <smoser> right. reading from http://docs.openstack.org/developer/pbr/semver.html
[19:14] <smoser> which is what pbr says it does
[19:14] <harlowja> https://github.com/openstack/nova/blob/master/nova/version.py#L21
[19:14] <harlowja> others also have a 'NOVA_PACKAGE = None # OS distro package version suffix'
[19:14] <harlowja> or equivalent
[19:14] <harlowja> right, so semver + a prefix that is plugged into that (or equivalent) file
[19:15] <harlowja> https://github.com/openstack/taskflow/blob/master/taskflow/version.py
[19:15] <harlowja> and others
[19:15] <smoser> so i think theres 2 things i'm struggling with
[19:15] <smoser> a.) cloudinit, i would behvae like:
[19:15] <smoser>  release 0.7.X
[19:15] <smoser>  h... call taht : release 0.7.2
[19:16] <smoser>  then "open 0.7.3"
[19:16] <harlowja> right
[19:16] <harlowja> we can keep more of the status quo without pbr for that 0.7.x branch and tags (0.7.2)
[19:16] <smoser>  so at this point, python setup.py --version shows '0.7.3'
[19:17] <harlowja> right
[19:17] <smoser>  but then i'd do a REVPOSTFIX with a '~bzrXXX'' where XXX was the trunk
[19:17] <smoser> so that '~' means to dpkg "this is *less* than 0.7.3"
[19:17] <smoser> but on 2.0 branch right now:
[19:17] <smoser> $ python setup.py --version
[19:17] <smoser> 1.9.0.dev158
[19:17] <smoser> where:
[19:17] <harlowja> ya, the 2.0 branch is all weird right now with respect to version
[19:18] <harlowja> pbr is trying to calculate that, not sure why it picked 1.9
[19:18] <smoser> $ dpkg --compare-versions 1.0.0.dev1 gt 1.0.0 && echo dev is greater than tag || echo dev is less than tag
[19:18] <smoser> dev is greater than tag
[19:18] <smoser> well, it picked 1.9 because its in setup.cfg
[19:18] <harlowja> ah
[19:18] <harlowja> k
[19:19] <smoser> so the issue rigth now is that if i were to use the pbr symantics exactly as the are, my released versions would be versioned smaller than my development versions leading up to the release.
[19:19] <harlowja> right
[19:20] <harlowja> i think we just need to make sure pbr has its deb version command exposed
[19:20] <harlowja> like https://review.openstack.org/#/c/196191/
[19:20] <harlowja> pretty sure it knows how to generate a deb version correctly
[19:20] <harlowja> just might need to be exposed as --deb-version command or something
[19:21] <harlowja> if not, we need to bug pbr authors
[19:21] <harlowja> https://github.com/openstack-dev/pbr/blob/master/pbr/version.py#L231 exists
[19:21] <harlowja> likely just needs to be expoed
[19:21] <harlowja> *just like the rpm one that i exposed
[19:22] <harlowja> lifeless is also trying/working on getting pbr adopted by pip, so it will probably be everywhere soon
[19:22] <harlowja> * https://review.openstack.org/#/c/219468/
[19:23] <harlowja> so with 'debian_string(self):' exposed, i think that will do the right sorting for u
[19:25] <harlowja> i can propose that smoser
[19:26] <harlowja> *pretty much same as 196191
[19:26] <smoser> all it does is ~ right ?
[19:26] <smoser> in my reading ?
[19:27] <harlowja> seems like it
[19:27] <harlowja> https://github.com/openstack-dev/pbr/blob/master/pbr/version.py#L311
[19:28] <harlowja> if its busted and/or not working, can just tweak pbr
[19:28] <smoser> k. i can work somethign together.
[19:28] <harlowja> okie
[19:28] <smoser> so then i wonder..
[19:28] <smoser> how does it count "commits since last tag" or whatevre it does to get 'devX'
[19:29] <harlowja> ya, that logic i'm not sure of
[19:29] <smoser> i just dont know how to figure which tag to go from
[19:29] <harlowja> https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L636
[19:30] <harlowja> https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L516
[19:30] <harlowja> but some pbr folks can probably better describe that (vs reading code)
[19:31] <smoser> well thats magic
[19:31] <smoser> git describe
[19:31] <harlowja> magic might need better docs, not sure
[19:33] <harlowja> other option, not use PBR, just increment the numbers ourself
[19:34] <smoser> i'm ok to use pbr on 2.0 and maybe use 'git-describe' which seems mostly functional on 0.7.X
[19:34] <harlowja> k
[19:34] <smoser> from git-describe:
[19:35] <harlowja> git describe
[19:35] <harlowja> 0.7.6-443-g23d4282
[19:35] <harlowja> interesting
[19:35] <smoser> Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object and he abbreviated object name of the most recent commit.
[19:35] <smoser> right
[19:35] <harlowja> thats https://github.com/harlowja/cloud-init/tree/0.7.x-fixed-final
[19:35] <smoser> but what is that g23d ?
[19:36] <harlowja> commit 23d4282b1fd8aee9ecf372435b10185dfb59731d
[19:36] <smoser> as 'git show' doesnt show it. how can i turn that into something useful if i was curious
[19:36] <harlowja> last commit
[19:36] <harlowja> g(commit)
[19:36] <smoser> a. g
[19:36] <smoser> right.
[19:36] <smoser> duh.
[19:36] <harlowja> maybe leave off g23d4282
[19:36] <harlowja> :-/
[19:36] <smoser> it doesnt hurt.
[19:36] <harlowja> k
[19:37] <smoser> her. i'll get something .thanks for patience. let me poke
[19:37] <harlowja> cool beans
[19:37] <smoser> we're even lucky
[19:37] <harlowja> ??
[19:38] <harlowja> we're always lucky
[19:38] <harlowja> lol
[19:38] <smoser> oh shoot. its not.
[19:38] <smoser> i thought the 443 was lucky enough to be > trunk's revno
[19:38] <harlowja> its ssl port
[19:38] <harlowja> lol
[19:38] <smoser> right
[19:39] <smoser> as a tribute to sabdfl
[19:39] <harlowja> distance to 0.7.6?
[19:39] <harlowja> but 443 changes seems like alot
[19:39] <smoser> well, my thought was that i could just grab that (0.7.6-443) and turn it into 0.7.7~dev443
[19:40] <smoser> $ git log --format=oneline 0.7.6.. | wc -l
[19:40] <smoser> 443
[19:41] <harlowja> ya
[19:41] <harlowja> so i guess thats how it got that
[19:42] <harlowja> but u want it since commits for all time right?
[19:43] <smoser> well, that would work . but this is easy enough.
[19:43] <harlowja> ya
[19:43] <harlowja> tell it to use first commit
[19:43] <harlowja> *tell git describe
[19:43] <smoser> so here is plan
[19:43] <smoser> i'll git a shell snippet
[19:44] <harlowja> after/before https://github.com/harlowja/cloud-init/tree/0.7.x-fixed-final is resynced -> stackforge?
[19:44] <harlowja> *or other repo that openstack-infra needs to sync
[19:44] <harlowja> to replace https://github.com/stackforge/cloud-init/tree/0.7.x
[19:44] <harlowja> ^ which is missing commits...
[19:47] <smoser> let me work out what iw ant to do
[19:47] <smoser> and then you can help me. k ?
[19:50] <harlowja> k
[19:50] <harlowja> sure boss
[19:50] <harlowja> sputnik13 get er all done
[19:50] <harlowja> thx
[19:50] <harlowja> lol
[20:30] <smoser> harlowja, http://paste.ubuntu.com/12534794/
[20:35] <smoser> i think i'm happy with that for those tools.
[20:35] <smoser> and seems to retain bzr support also.
[21:01] <smoser> harlowja, http://paste.ubuntu.com/12535144/
[21:01] <smoser> i like that better.
[21:02] <smoser> that is on top of your lp:~harlowja/cloud-init/cloud-init-git-tarball-make
[21:03] <smoser> at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cloud-init/wily/view/head:/debian/README.source#L43
[21:04] <smoser> the 'improt a new snapshot' i'll have to adjust to work with git.
[21:04] <smoser> but the tools/read-version --dev will be useful.
[21:06] <harlowja> smoser cool, works for me
[21:06] <harlowja> i'm all good with whatever u are good with :-P
[21:56] <bdx> smoser: how's it goin?
[21:58] <bdx> smoser: does cloud-init using nocloud provider preform any /etc/ssh/sshd_config modifications by default in trusty cloudimg?
[23:28] <sputnik13> sooooo...  where do I submit patches bzr or git? :)
[23:28] <sputnik13> smoser harlowja ^
[23:29] <harlowja> ummmm
[23:29] <sputnik13> I know your answer already
[23:29] <sputnik13> :)
[23:29] <harlowja> :-P