smoser | sputnik13, i'm not opposed to having it extended to support lvm | 00:00 |
---|---|---|
sputnik13 | smoser do you think it's better to extend growpart vs having a separate module for lvm? | 00:02 |
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:03 |
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:04 |
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:05 |
harlowja | growpart --ifeellucky | 00:06 |
natorious | I'd noticed some issues w/ growpart and raid recently. Wheres the issue tracker for that project? | 03:19 |
smoser | natorious, cloud-utils | 13:34 |
smoser | https://bugs.launchpad.net/cloud-utils/+filebug | 13:34 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
smoser | natorious, i'll take a quick look at your mp and have anyone else here interested do the sam.e | 14:10 |
natorious | thnx | 14:11 |
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:18 |
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:19 |
smoser | are we delta'd on it ? | 14:21 |
* smoser swears at sillyness of <python>-<libraryname> as the source package name. | 14:21 | |
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:22 |
smoser | if its just a sync, i'm not oppsed to filing a bug and doing that in wily | 14:23 |
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:24 |
natorious | the pip2dist stuff looks cool. Would you need to follow cross platform dep changes though? | 14:32 |
smoser | natorious, cross platform dep changes ? | 15:14 |
smoser | oh. i think by nto allowing them :) | 15:14 |
smoser | ie, if we're supporting a given OS, then stuff has to run in that. or it cant be accepted. | 15:15 |
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:18 |
* natorious chuckles | 15:19 | |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
natorious | to get it working with my openstack envs etc | 15:28 |
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 | 15:29 |
sputnik13 | alo alo alo | 17:03 |
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:11 |
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:12 |
smoser | harlowja, can i have 45 minutes and ping me back? | 17:13 |
harlowja | 44.9 minutes | 17:13 |
harlowja | lol | 17:13 |
smoser | 44.6 | 17:14 |
smoser | ahh.. will that clock ever stop ticking! | 17:15 |
harlowja | :-P | 17:15 |
sputnik13 | :) | 17:20 |
sputnik13 | ohhhh, taskflow packaged in to ubuntu... harlowja's baby is moving up in the world :-D | 17:21 |
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:22 |
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 | 17:23 |
=== zz_gondoi is now known as gondoi | ||
harlowja | tiems up | 18:00 |
harlowja | lol | 18:00 |
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:18 |
gster | do you know any workaround e.g set systemd timeout maybe? | 18:22 |
harlowja | smoser come back | 18:29 |
harlowja | lol | 18:29 |
smoser | almost back. | 18:30 |
smoser | stupid security | 18:30 |
=== gondoi is now known as zz_gondoi | ||
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:37 |
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:38 |
smoser | ok. let me take alook | 18:39 |
=== shardy is now known as shardy_afk | ||
harlowja | and i thinks https://github.com/harlowja/cloud-init/tree/0.7.x-fixed-final is the latest resync from bzr | 18:43 |
harlowja | layered ontop of https://github.com/stackforge/cloud-init/tree/0.7.x | 18:47 |
gster | harlowja: is this about the systemd timeout problem I metionned earlier? | 18:57 |
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:58 |
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 | 18:59 |
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:02 |
smoser | harlowja, ok. so some symantic differences between what you're suggesting and what i've done before. | 19:12 |
harlowja | possibly | 19:13 |
harlowja | from my understanding alot of openstack stuff has the following | 19:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
harlowja | so with 'debian_string(self):' exposed, i think that will do the right sorting for u | 19:23 |
harlowja | i can propose that smoser | 19:25 |
harlowja | *pretty much same as 196191 | 19:26 |
smoser | all it does is ~ right ? | 19:26 |
smoser | in my reading ? | 19:26 |
harlowja | seems like it | 19:27 |
harlowja | https://github.com/openstack-dev/pbr/blob/master/pbr/version.py#L311 | 19:27 |
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:28 |
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:29 |
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:30 |
smoser | well thats magic | 19:31 |
smoser | git describe | 19:31 |
harlowja | magic might need better docs, not sure | 19:31 |
harlowja | other option, not use PBR, just increment the numbers ourself | 19:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
smoser | $ git log --format=oneline 0.7.6.. | wc -l | 19:40 |
smoser | 443 | 19:40 |
harlowja | ya | 19:41 |
harlowja | so i guess thats how it got that | 19:41 |
harlowja | but u want it since commits for all time right? | 19:42 |
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:43 |
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:44 |
smoser | let me work out what iw ant to do | 19:47 |
smoser | and then you can help me. k ? | 19:47 |
harlowja | k | 19:50 |
harlowja | sure boss | 19:50 |
harlowja | sputnik13 get er all done | 19:50 |
harlowja | thx | 19:50 |
harlowja | lol | 19:50 |
=== shardy_afk is now known as shardy | ||
smoser | harlowja, http://paste.ubuntu.com/12534794/ | 20:30 |
smoser | i think i'm happy with that for those tools. | 20:35 |
smoser | and seems to retain bzr support also. | 20:35 |
smoser | harlowja, http://paste.ubuntu.com/12535144/ | 21:01 |
smoser | i like that better. | 21:01 |
smoser | that is on top of your lp:~harlowja/cloud-init/cloud-init-git-tarball-make | 21:02 |
smoser | at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cloud-init/wily/view/head:/debian/README.source#L43 | 21:03 |
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:04 |
harlowja | smoser cool, works for me | 21:06 |
harlowja | i'm all good with whatever u are good with :-P | 21:06 |
bdx | smoser: how's it goin? | 21:56 |
bdx | smoser: does cloud-init using nocloud provider preform any /etc/ssh/sshd_config modifications by default in trusty cloudimg? | 21:58 |
sputnik13 | sooooo... where do I submit patches bzr or git? :) | 23:28 |
sputnik13 | smoser harlowja ^ | 23:28 |
harlowja | ummmm | 23:29 |
sputnik13 | I know your answer already | 23:29 |
sputnik13 | :) | 23:29 |
harlowja | :-P | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!