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