| harlowja | smoser https://review.openstack.org/#/c/166201/ fyi | 00:26 |
|---|---|---|
| harlowja | useful to look at/over | 00:26 |
| === harlowja is now known as harlowja_away | ||
| Odd_Bloke | smoser: Is there any reason for having documentation in /doc that isn't in /doc/rtd/... (and therefore rendered on ReadTheDocs)? | 10:54 |
| Odd_Bloke | smoser: Does http://bazaar.launchpad.net/~daniel-thewatkins/cloud-init/openstack-vendor-data-doc/revision/1089 look sensible to you? | 11:48 |
| Odd_Bloke | smoser: (I'm waiting for confirmation from the partner that triggered this investigation that we've solved their problem before opening a MP) | 11:49 |
| smoser | Odd_Bloke, i think i'd like to have something like: | 12:59 |
| smoser | http://bazaar.launchpad.net/~daniel-thewatkins/cloud-init/openstack-vendor-data-doc/revision/1089 | 12:59 |
| smoser | for all vendor-data consumption | 12:59 |
| smoser | i tihnk we can do this in a backwards compatible mode to if we do it right. | 12:59 |
| smoser | hm.. well i tihnk we want to do this well. | 13:00 |
| smoser | sorry. | 13:02 |
| smoser | bad link above. | 13:02 |
| smoser | whic his confusing | 13:02 |
| smoser | https://etherpad.openstack.org/p/cloud-init-vendor-data | 13:02 |
| smoser | i' dlike to hvae that basic policy in place for all vendor data consumption i think. | 13:02 |
| ktdreyer | hi folks, I'm wondering about the "#cloud-config" text that I see at the top of cloud-init YAML files. Isn't that a comment in YAML syntax? But cloud-init relies upon its presence? | 13:50 |
| Odd_Bloke | smoser: OpenStack falls over if vendor-data is just a string; I didn't try with a list. | 13:52 |
| Odd_Bloke | smoser: But I wouldn't be surprised if OpenStack requires a JSON object. | 13:52 |
| smoser | Odd_Bloke, well, it does. | 13:52 |
| smoser | but a string is valid json | 13:52 |
| smoser | watch: | 13:53 |
| smoser | $ python -c 'import sys, json; print(json.dumps(sys.argv[1], indent=1))' "Hi Odd_Bloke" | 13:53 |
| Odd_Bloke | A string is valid JSON; it's not a valid JSON object. | 13:53 |
| smoser | watch | 13:54 |
| Odd_Bloke | (As a JSON object is defined as a mapping) | 13:54 |
| smoser | http://paste.ubuntu.com/10718416/ | 13:56 |
| smoser | you can argue if you want that python's json module is behaving incorrectly | 13:56 |
| smoser | but that same 'loads' is how openstack is going to check if its valid json | 13:57 |
| smoser | $ python /tmp/go.py | 13:57 |
| smoser | contents: "Hi Mom" | 13:57 |
| smoser | data: Hi Mom | 13:57 |
| smoser | ktdreyer, yes. cloud-init depends on it in some contexts. | 13:58 |
| Odd_Bloke | smoser: "foo" is valid JSON, but it's not a JSON object. A JSON object is a mapping ({"foo": "bar", ...}), and is one of the valid root objects in valid JSON. | 13:58 |
| Odd_Bloke | As are strings. | 13:58 |
| smoser | in /etc/cloud/cloud.cfg.d , it probably assumes a default of cloud-config (which is sane). | 13:58 |
| Odd_Bloke | So I think we're talking past one another here. :) | 13:58 |
| smoser | ktdreyer, but in other cases, it doens't know what the content of the file is... how to interpret it. so it relies on either data provided to it about the content (such as mime-type) or the content starting with a string. | 13:59 |
| smoser | well, kyou said openstack will fail if vendor-data is just a string | 14:00 |
| smoser | but i dont think it would | 14:00 |
| Odd_Bloke | If it assumes that it will get a mapping and looks for specific keys it might; I'm trying to get back on to that OpenStack cloud to try again. | 14:00 |
| smoser | i wrote it. | 14:01 |
| smoser | its a blob | 14:01 |
| smoser | it makes sense. | 14:01 |
| smoser | its a contract / data from "vendor" to "guest" | 14:01 |
| smoser | openstack is not involved. | 14:02 |
| Odd_Bloke | Ack; I'll try and work out what I was doing wrong. | 14:02 |
| smoser | Odd_Bloke, i'm not saying that we should use a string. | 14:03 |
| smoser | i think the dict or list makes more sense. | 14:03 |
| smoser | and cloud-inti shoudl take the 'cloud-init' entry in that. | 14:03 |
| smoser | that is what we should make work, and what we should recommend to vendors. | 14:04 |
| Odd_Bloke | Yeah; that does work. | 14:04 |
| smoser | Odd_Bloke, fwiw, this whole "string as an object" conversation, I had almost identically with JayF when i first wrote that etherpad. | 14:07 |
| smoser | :) | 14:08 |
| Odd_Bloke | smoser: http://json.org/ says that strings categorically are not JSON objects. But JSON objects are not the only valid JSON root type. | 14:10 |
| Odd_Bloke | So we're just in violent agreement here. :p | 14:10 |
| smoser | well, just to be snarky, and add more violent agreement | 14:12 |
| smoser | $ python -c 'import json, sys; print(isinstance(json.loads(sys.argv[1]), object))' '"foo"' | 14:12 |
| smoser | True | 14:12 |
| smoser | :) | 14:12 |
| Odd_Bloke | :D | 14:12 |
| smoser | openstack expects the VendorData class (which defaults to that thing that reads data from a json file) | 14:13 |
| smoser | to return data | 14:13 |
| smoser | it then 'json.dumps()' that to a file-like thing that it shows in the metadata service. | 14:13 |
| smoser | the VendorData class could return anything, but openstack is going to force that thing to be 'json.dumps'-able. | 14:14 |
| smoser | which seems sane. as it labels it 'vendordata.json' | 14:14 |
| Odd_Bloke | Yeah; I think the problem might have been that I just put a regular cloud-config file in there, rather than a JSON document with a string as the root object. | 14:23 |
| smoser | right. | 14:28 |
| smoser | err.. | 14:28 |
| smoser | "right." | 14:28 |
| Odd_Bloke | Yeah. | 14:31 |
| Odd_Bloke | And JSON strings can't have literal newlines. | 14:32 |
| Odd_Bloke | So it looks like "#cloud-config\npackages:\n- htop\n". | 14:33 |
| Odd_Bloke | Uh, plus a space in there. | 14:33 |
| smoser | so what you want is this: | 14:36 |
| smoser | cloud_init_data = {'packages': ['htop']} | 14:36 |
| smoser | with open("file.json", "wb") as fp | 14:37 |
| smoser | fp.write('\n'.join("#cloud-init", json.dumps(cloud_init_data)) | 14:38 |
| smoser | somthehign like that. | 14:38 |
| smoser | bsaically, let tools write it for you | 14:38 |
| Odd_Bloke | smoser: So have something like http://paste.ubuntu.com/10718633/ as the vendor-data OpenStack reads? | 14:42 |
| smoser | hm.. wait no. sorry . here. | 14:43 |
| smoser | http://paste.ubuntu.com/10718667/ | 14:48 |
| smoser | Odd_Bloke, ^ | 14:48 |
| smoser | either of those output formats (list or string) should work for cloud-init in vivid. and are in line with https://etherpad.openstack.org/p/cloud-init-vendor-data | 14:49 |
| smoser | and i'm saying we should make trusty act like vivid. | 14:49 |
| Odd_Bloke | smoser: http://paste.ubuntu.com/10718677/ worked on trusty and vivid. | 14:50 |
| smoser | Odd_Bloke, oh. | 14:54 |
| smoser | that is odd. | 14:54 |
| smoser | i dont know whow that works on trusty | 14:54 |
| smoser | ididn't think it looked in cloud-init | 14:54 |
| Odd_Bloke | smoser: Yep, it does; line 150 of DataSourceOpenStack.py. | 15:00 |
| JayF | smoser: Very happy to see cloud-init v2 hit stackforge | 15:05 |
| smoser | i pointed out, specifically... it is not a openstack project. | 15:08 |
| smoser | we just want free infrastructure :) | 15:08 |
| smoser | utlemming, i updated the lp:ubuntu/trusty branch | 15:09 |
| smoser | by 'dget <link-to-dsc>' (from https://launchpad.net/ubuntu/+source/cloud-init) | 15:09 |
| utlemming | smoser: ack | 15:09 |
| smoser | and then 'bzr import-dsc' from that dsc | 15:09 |
| smoser | and bzr push | 15:09 |
| smoser | please make sure you update that when you upload | 15:09 |
| utlemming | smoser: sure, sorry about that | 15:11 |
| smoser | precise-proposed, trusty, and utopic are now all up to date with archive. | 15:16 |
| === [1]claudiupopa is now known as claudiupopa | ||
| === harlowja_away is now known as harlowja | ||
| === tennis_ is now known as gamename | ||
| harmw | what would be a fairly decent architecture for a small cloud deployment having compute nodes on multiple locations, each having their own ISP link for connecting with $world and using an ipsec tunnel with $home where keystone lives? | 17:12 |
| harlowja | claudiupopa whats your openstack email; https://review.openstack.org/#/admin/groups/665,members is up | 17:30 |
| harlowja | smoser ^ | 17:30 |
| harlowja | u are now cloud-init core | 17:30 |
| harlowja | feel free to add others | 17:30 |
| harlowja | also https://review.openstack.org/#/admin/groups/666,members | 17:31 |
| harlowja | 666 omg | 17:31 |
| harlowja | lol | 17:31 |
| smoser | ok thanks. | 17:32 |
| harlowja | np | 17:32 |
| claudiupopa | cpopa@cloudbasesolutions.com | 17:32 |
| claudiupopa | So it's finally up. | 17:33 |
| JayF | 666 the number of the cloud | 17:36 |
| harlowja | JayF ha | 17:43 |
| harlowja | alexpilotti whats your email on gerrit? | 17:43 |
| harlowja | autofill-in not working | 17:43 |
| alexpilotti | harlowja: apilotti@cloudbasesolutions.com | 17:44 |
| harlowja | k | 17:44 |
| alexpilotti | autofill has some strange logic | 17:44 |
| harlowja | k, u are now coreeeee | 17:45 |
| harlowja | lol | 17:45 |
| alexpilotti | yeiiii tx :-) | 17:45 |
| alexpilotti | I found myself swearing a bit about the way it accepts naming ordering and spelling | 17:46 |
| harlowja | ok first review | 17:46 |
| harlowja | lol | 17:46 |
| harlowja | https://review.openstack.org/169854 | 17:46 |
| alexpilotti | d’oh! | 17:46 |
| harlowja | use all your magic core powers on that one, lol | 17:46 |
| harlowja | guess we can see if the automated-ci works with that review also | 17:47 |
| harlowja | or if its broken (or something else) | 17:47 |
| alexpilotti | quick double check w the format we have in cloudbase-init’s .gitreview | 17:47 |
| harlowja | thx | 17:48 |
| * harlowja copied it from taskflow one, ha | 17:48 | |
| alexpilotti | should I +2a or do we leave to smoser the pleasure of his first +a? :-) | 17:49 |
| harlowja | let's see if the CI breaks first | 17:49 |
| harlowja | it might be somewhat busted; not sure, ha | 17:49 |
| harlowja | first commits usually expose that :-P | 17:50 |
| alexpilotti | yep, we learned it the hard way | 17:50 |
| alexpilotti | as the first 2-3 post-stackforge patches in cbs-init can testify | 17:50 |
| harlowja | ya; looks like its busted, lol | 17:50 |
| harlowja | https://jenkins04.openstack.org/job/gate-cloud-init-pep8/1/ | 17:50 |
| harlowja | ... | 17:51 |
| harlowja | i'll get all that stuff fixed | 17:51 |
| harlowja | maybe should turn off the docs build | 17:51 |
| harlowja | *for now* | 17:51 |
| alexpilotti | oh… well time to bring the joys of pep8 to cloud-init | 17:51 |
| JayF | I never start a new project with CI | 17:52 |
| harlowja | :) | 17:52 |
| JayF | set it up with noop jobs, then setup things one at a time | 17:52 |
| JayF | you are braver than me :P | 17:52 |
| kwadronaut | s/pep8/pdp11/g | 17:52 |
| harlowja | JayF ha | 17:53 |
| harlowja | JayF ya; it usually just causes these first commits to be busted | 17:53 |
| harlowja | then it all goes ok | 17:53 |
| alexpilotti | docs: https://github.com/stackforge/cloudbase-init/commit/23ddd33fa4a35040f9ab2f84efb54d7244232b8b | 17:54 |
| alexpilotti | an empty doc/source/conf.py should do | 17:54 |
| harlowja | kk | 17:54 |
| harlowja | cool | 17:54 |
| alexpilotti | and setup.cfg | 17:54 |
| harlowja | cools | 17:55 |
| harlowja | thx | 17:55 |
| alexpilotti | [build_sphinx] | 17:55 |
| alexpilotti | source-dir = doc/source | 17:55 |
| alexpilotti | do we have a .testr.conf? | 17:56 |
| harlowja | will get all that going | 17:56 |
| claudiub_ | I would also suggest updating HACKING.md, since the new method of contributing will be through gerrit. That would mean going a git review instead, when the commit is ready. | 17:58 |
| harlowja | alexpilotti although seems like we are just gonna stick to nose for a little so i guess no testr.conf needed | 17:58 |
| harlowja | nose imho is just simpler :-P | 17:58 |
| harlowja | testr meh | 17:58 |
| JayF | harlowja: so existing cloud-init stays locked up in bzr? How long until this becomes the "new" cloud-init? | 17:59 |
| harlowja | i defer to others on that one JayF :-P | 17:59 |
| harlowja | i just work here, haha | 17:59 |
| harlowja | *when its ready? | 18:00 |
| harlowja | :) | 18:00 |
| JayF | when it's ready is code for never :P | 18:00 |
| harlowja | only if u are the type that doesn't commit to shit | 18:00 |
| harlowja | lol | 18:00 |
| harlowja | i don't think we are :-P | 18:00 |
| JayF | russell_h: ^ Doesn't look like it's close though. | 18:00 |
| smoser | ugh... whats the mP ? | 18:01 |
| harlowja | smoser i got it under control boss | 18:02 |
| harlowja | lol | 18:02 |
| smoser | good job. | 18:03 |
| alexpilotti | claudiub_: +1 | 18:03 |
| alexpilotti | harlowja: k! | 18:03 |
| smoser | oh yeah | 18:03 |
| smoser | i had that locally :) | 18:03 |
| jetole | Hey guys. I have a question about cloudbase-init and this is the closest room I could find so I will ask here hoping either someone can help or someone can direct me to the right room... | 18:10 |
| jetole | When I start a instance, neither the hard drive is being extended nor is the instance being activated (it has a valid MAK key). The logs say very little. 6 lines regarding attempts to get meta data via 169.254.169.254 but I have not added any metadata line to cloudbase-init.conf. Can anyone help me figure out why the plugins I specified aren't running and the meta data lines are being queried when they are not included in the conf? | 18:11 |
| alexpilotti | jetole: best place for this question is ask.cloudbase.it | 18:17 |
| alexpilotti | jetole: can you please post also a copy of your cloudbase-init.log and cloudbase-init-unattend.log? | 18:17 |
| alexpilotti | jetole: also: which Windows version are you using? | 18:18 |
| jetole | alexpilotti: 2k8r2 standard | 18:18 |
| jetole | alexpilotti: should I have configured cloudbase-init-unattend.conf as well as cloudbase-init.conf ? | 18:18 |
| alexpilotti | jetole: if you used the installer, they come preconfigured | 18:18 |
| jetole | I'm thinking maybe I should have since I'm going the generalize OOB sysprep | 18:19 |
| alexpilotti | jetole: also a copy of your config files will help in troubleshooting | 18:19 |
| jetole | some is but not nessicerely how I prefer, for example I don't want to add a user or query the meta servers but I do want to activate windows which can manually be done since the correct MAK key is there and the hard drive doesn't grow to fill the instance size | 18:19 |
| jetole | OK | 18:20 |
| jetole | Will do | 18:20 |
| jetole | thanks | 18:20 |
| harlowja | ok i think https://review.openstack.org/#/c/169854/ should fix all of it | 18:23 |
| harlowja | maybe not the pep8 ones though | 18:23 |
| harlowja | let's see how far that gets | 18:24 |
| alexpilotti | harlowja: requirements might need sphinx>=1.1.2,<1.1.999 | 18:24 |
| harlowja | kk | 18:24 |
| claudiub_ | harlowja: I have left you a comment on that patchset regarding pep8 | 18:24 |
| harlowja | claudiub_ thx | 18:24 |
| harlowja | looking | 18:24 |
| harlowja | alexpilotti i put sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3 into test-requirements | 18:24 |
| harlowja | it seemed to work in a venv | 18:24 |
| alexpilotti | pep8: we should do our homework and clean up the entire project | 18:25 |
| harlowja | when i ran tox -edocs | 18:25 |
| harlowja | alexpilotti ya | 18:25 |
| harlowja | ok, updated | 18:26 |
| harlowja | let's see | 18:26 |
| * harlowja prefers rst vs markdown also :-P | 18:26 | |
| harlowja | since all that damn sphinx stuff is in rst (might as well just use it all the places) | 18:27 |
| JayF | harlowja: I have a very recent patchset enabling doc builds on a project if you wanted a template | 18:28 |
| harlowja | JayF i think this should work; tox -edoc worked for me, let's see if it gets farther | 18:29 |
| harlowja | then we can make it better | 18:29 |
| JayF | That's fine, was just offering :) | 18:29 |
| harlowja | cools | 18:29 |
| harlowja | thx | 18:29 |
| alexpilotti | harlowja: tests dont seem to run | 18:32 |
| harlowja | hmmm | 18:32 |
| harlowja | Ran 0 tests in 0.006s | 18:32 |
| harlowja | OK | 18:32 |
| harlowja | seems to run something :-P | 18:32 |
| harlowja | although 0 of something | 18:33 |
| harlowja | ha | 18:33 |
| harlowja | $ tox -epy27 | 18:33 |
| harlowja | likely cause there aren't any? | 18:33 |
| alexpilotti | harlowja: https://github.com/stackforge/cloudbase-init/blob/23ddd33fa4a35040f9ab2f84efb54d7244232b8b/.testr.conf | 18:33 |
| alexpilotti | and testrepository in requirements.txt | 18:34 |
| harlowja | ya; i think we are sticking with nose + nosetests though for the time being | 18:34 |
| alexpilotti | not sure if we can get nsoe to do this | 18:34 |
| harlowja | we can swithc later if we care | 18:34 |
| alexpilotti | in theory it should be transparent | 18:34 |
| harlowja | ya; so thats why later switch i think is ok | 18:34 |
| harlowja | u can commit that one :-P | 18:34 |
| harlowja | once this goes in | 18:34 |
| alexpilotti | the fact that we dont have tests is also a good reason why tests dont run :-D | 18:35 |
| alexpilotti | as in: https://github.com/stackforge/cloud-init/tree/master/cloudinit/tests | 18:35 |
| harlowja | ;) | 18:35 |
| harlowja | yup | 18:35 |
| alexpilotti | I was quite surprise by seeing a green Python 3.4 jenkins run at the first run :-) | 18:38 |
| harlowja | woot | 18:40 |
| harlowja | ha | 18:40 |
| alexpilotti | added https://review.openstack.org/#/c/169880/ | 18:45 |
| alexpilotti | harlowja: hey docs are happy | 18:46 |
| harlowja | ya; nearly there alexpilotti | 18:46 |
| harlowja | just a few hacking tweaks/exclusions | 18:46 |
| alexpilotti | we “only” have pep8 left | 18:46 |
| harlowja | ok, think latests update should do it | 18:47 |
| harlowja | let's see | 18:47 |
| alexpilotti | hacking.rst: what about removing the names and adding a reference to: https://review.openstack.org/#/admin/groups/665,members | 18:49 |
| harlowja | sureee | 18:49 |
| alexpilotti | this way we dont have to change the file anytime somedy gets added/removed from the core group :-) | 18:49 |
| harlowja | ya | 18:53 |
| harlowja | alexpilotti updated | 18:54 |
| alexpilotti | merci | 18:54 |
| harlowja | hopefully that makes it all happy and good to go | 18:55 |
| alexpilotti | does it makes sense to keep: | 18:55 |
| alexpilotti | .. _Scott Moser: https://launchpad.net/~smoser | 18:55 |
| alexpilotti | .. _Joshua Harlow: https://launchpad.net/~harlowja | 18:55 |
| alexpilotti | in the references sicne they are not accessed? | 18:56 |
| alexpilotti | I mean they are not referenced | 18:56 |
| smoser | referenced ? | 18:56 |
| alexpilotti | https://review.openstack.org/#/c/169854/9/HACKING.rst | 18:57 |
| alexpilotti | instead of the name list we have: * `Core reviewers/maintainers`_ | 18:58 |
| alexpilotti | and at the bottom we have: | 18:58 |
| alexpilotti | .. _Core reviewers/maintainers: https://review.openstack.org/#/admin/groups/665,members 38 | 18:58 |
| alexpilotti | .. _Scott Moser: https://launchpad.net/~smoser 39 | 18:58 |
| alexpilotti | .. _Joshua Harlow: https://launchpad.net/~harlowja 40 | 18:58 |
| alexpilotti | .. _IRC: irc://chat.freenode.net/cloud-init 41 | 18:58 |
| alexpilotti | .. _freenode: http://freenode.net/ | 18:58 |
| alexpilotti | I mea, we can add everybody’s launchpad profile there, but I dont see it particularly useful in a dynamic group | 18:59 |
| smoser | sure. drop that. | 18:59 |
| alexpilotti | tx. developer’s anti data-duplication professional bias :-) | 19:00 |
| harlowja | alexpilotti i already dropped it :-P | 19:03 |
| harlowja | refresh to patch 10 | 19:03 |
| harlowja | ;) | 19:03 |
| harlowja | to slow, haha | 19:03 |
| alexpilotti | :-) | 19:04 |
| jetole | alexpilotti: http://ask.cloudbase.it/question/401/issues-with-meta-activate-serial-and-hdd-extend/ :-) | 19:08 |
| alexpilotti | jetole: ok tx! | 19:08 |
| alexpilotti | me or one of my colleagues will look at it asap | 19:08 |
| jetole | I think I should have used a different blockquote method but I don't post to stackexchange often enough and couldn't recall the syntax | 19:09 |
| alexpilotti | for logs and long text I usually paste on paste.openstack.org and paste the link in the post | 19:10 |
| alexpilotti | but yours are not very long so it works inline as well :-) | 19:10 |
| jetole | I can do the same and add a ref link under the block quote | 19:10 |
| jetole | ... or nevermind | 19:11 |
| jetole | ;-) | 19:11 |
| alexpilotti | jetole: on what cloud are you running this instance? | 19:12 |
| alexpilotti | plugins are meant to be executed when metadata is present | 19:13 |
| jetole | alexpilotti: I'm testing on a local qemu-kvm on workstation but I had also uploaded it to openstack and had the same results. I don't need any data from the meta servers at all so I feel it should be fine locally | 19:13 |
| jetole | well on openstack icehouse, I have the same results | 19:13 |
| alexpilotti | you can surely reduce the list of plugins | 19:13 |
| alexpilotti | on icehouse it should definitely pick up metadata from 169.254.169.254 or configdrive | 19:14 |
| jetole | I just updated the post | 19:16 |
| jetole | from the line @ Update near the bottom | 19:17 |
| alexpilotti | the unattend part is used only to save one reboot when you set the hostname | 19:19 |
| jetole | OK. I don't have the logs from icehouse and it will take me a while to get them since I removed the test image and would have to re-upload. I'm using ceph for the stack so uploading raw images only which take a while | 19:20 |
| jetole | should I do that and get the logs | 19:20 |
| jetole | ? | 19:20 |
| alexpilotti | yeah, that would be best | 19:20 |
| jetole | Ok. It's only the logs though. I know the results are the same | 19:20 |
| alexpilotti | we can add a “Nil” metadata provider for your Qemu case | 19:20 |
| jetole | sorry, can you clarify what unattend is used for? I didn't find a good ref on the difference between what the two config files are used for online | 19:21 |
| alexpilotti | when the image is sysprepped, it uses a file called unattend.xml (rough equivalent of a linux preseed.cfg / ks.cfg) | 19:22 |
| alexpilotti | thsi contains steps executed during the early first boot during a phase called “specialize” | 19:22 |
| jetole | I'm familiar with that | 19:23 |
| alexpilotti | we do a first execution of cloudbase-init at this stage | 19:23 |
| alexpilotti | to run only a limited set of plugins: NTP, MTU and hostname | 19:23 |
| jetole | I've used unattend, preseed and occasionally kickstart before but the cloudbase-init-unattend. What does that do differently | 19:23 |
| jetole | er, I mean that file specifically | 19:23 |
| alexpilotti | the hostname one requires a reboot | 19:23 |
| jetole | so the stuff that has to be done prior to the reboot goes into cloudbase-init-unattend? | 19:24 |
| alexpilotti | yep! | 19:24 |
| alexpilotti | in short, it’s just the anme of the configuration file used by cloudbase-init when executed during specialize | 19:24 |
| alexpilotti | there are quite some limitations on what can be executed during that phase, in particular WMI is not available | 19:25 |
| alexpilotti | in your case, given the requirements you posted, it can be skipped | 19:25 |
| jetole | ok | 19:26 |
| jetole | waiting on the upload now. It's at 90% (gbit between wkstn and stack) but than it's theirs the save from local host to ce | 19:27 |
| jetole | - to ceph (I think via glance) | 19:27 |
| harlowja | alexpilotti smoser claudiupopa https://review.openstack.org/#/c/169854/ | 19:41 |
| harlowja | we are good to go | 19:41 |
| harlowja | approve at will | 19:41 |
| smoser | hooray. tests pass. | 19:41 |
| smoser | :) | 19:41 |
| alexpilotti | yeii | 19:41 |
| harlowja | smoser yaaaa; 0 tests pass 0 times, lol | 19:42 |
| alexpilotti | smoser: would you fancy +2a it this patch? :-) | 19:43 |
| smoser | on the above ? | 19:44 |
| alexpilotti | https://review.openstack.org/#/c/169854/ | 19:44 |
| alexpilotti | yep | 19:44 |
| smoser | reviewing | 19:45 |
| harlowja | slacking again apparently, lol | 19:45 |
| smoser | why is it HACKING.rst ? | 19:46 |
| harlowja | idk | 19:47 |
| harlowja | lol | 19:47 |
| harlowja | seems common to what i've seen | 19:47 |
| harlowja | https://github.com/openstack/nova/ (HACKIGN.rst) | 19:47 |
| harlowja | ... | 19:47 |
| smoser | oh. ok. i didnt'r ealize github would render .rst | 19:48 |
| smoser | thought .md only | 19:48 |
| harlowja | ya | 19:48 |
| harlowja | it handles both | 19:48 |
| harlowja | and since rst is what sphinx also uses; i like just 1 format | 19:48 |
| jetole | Something else I wanted to ask, is there a (relatively) easy way for me to create a local metadata server for qemu/kvm for testing images when building them? | 19:49 |
| jetole | doesn't have to be on the same machine, etc since the KVM images share the LAN adapter of the host | 19:49 |
| smoser | so the reason i had testenv:docs is so tha tyou could build docs without the rest of the stuff | 19:49 |
| smoser | due to my general hatred of pypi | 19:49 |
| harlowja | maybe just get used to running `python setup.py build_sphinx` then :-P | 19:50 |
| harlowja | its a few more characters, lol | 19:50 |
| harlowja | but u can do it | 19:50 |
| harlowja | lol | 19:50 |
| harlowja | i believe in u | 19:50 |
| harlowja | we can switch it back; i think its ok if u really want smoser | 19:54 |
| harlowja | https://github.com/openstack/glance/blob/master/tox.ini#L40 seems to be the common practice | 19:54 |
| harlowja | although deps = {[testenv]deps} i think is fine either way | 19:54 |
| harlowja | so not sure it matters | 19:54 |
| harlowja | u sorta need the deps to run that comand anyway | 19:55 |
| smoser | so you switched it just to have less tox env ? | 19:55 |
| smoser | ie, less stuff in .tox/ | 19:55 |
| smoser | right? | 19:55 |
| harlowja | well to install the right dependencies | 19:55 |
| harlowja | sphinx will crap out if u start including code from cloud-init into docs... | 19:55 |
| smoser | no.. i had it i thought in its own testenv. | 19:56 |
| harlowja | ya, well [testenv:docs] will do that | 19:56 |
| harlowja | afaik that will make a .docs venv | 19:56 |
| smoser | ah. but the .docs will have all of the requirements in it. | 19:57 |
| harlowja | smoser the openstack folks mirror pypi afaik so the mirror issues should be less of an issue | 19:57 |
| harlowja | smoser right | 19:57 |
| harlowja | and if we have docs that include code snippets; thats probably what we want | 19:57 |
| harlowja | so those code snippers can be tested as well (which can be done) | 19:57 |
| harlowja | *snippets | 19:57 |
| smoser | stop making rational arguments for your side | 19:57 |
| smoser | its annoying | 19:58 |
| smoser | :) | 19:58 |
| smoser | so the code snippets is godo point. and i'm fine with that. | 19:58 |
| smoser | harlowja, and we officially dropped 2.6 ? | 19:58 |
| harlowja | ha | 19:59 |
| smoser | did you mean to remove that ? | 19:59 |
| harlowja | well it seems like the openstack CI isn't testing it | 19:59 |
| harlowja | sooo | 19:59 |
| harlowja | i'm ok with that for now | 19:59 |
| harlowja | we'll see :) | 19:59 |
| smoser | istn't that rhel 6 ? didn't you tell me that ? | 19:59 |
| harlowja | ya | 19:59 |
| harlowja | it is | 19:59 |
| harlowja | i can add back later | 19:59 |
| harlowja | will see | 19:59 |
| smoser | and they dont have a python3 either. | 19:59 |
| harlowja | gate-cloud-init-python34 | 20:00 |
| harlowja | ? | 20:00 |
| harlowja | thats running 34 | 20:00 |
| smoser | ok. | 20:00 |
| harlowja | but gate-cloud-init-python26 not there right now | 20:00 |
| smoser | k. good enouh | 20:00 |
| harlowja | so just chopped 26 from the rest of it for now | 20:00 |
| harlowja | someone at yahoo will notice that and probably say, whats up | 20:01 |
| harlowja | but hasn't happened yet :-P | 20:01 |
| harlowja | also removed 'Environment :: OpenStack' | 20:01 |
| harlowja | since cloud-init isn't really 'openstack' | 20:01 |
| harlowja | ... | 20:01 |
| harlowja | its just cloud... | 20:01 |
| smoser | yeah, i'm godo wth that. | 20:03 |
| harlowja | cools | 20:04 |
| harlowja | merging it then (+a) | 20:04 |
| harlowja | and merged | 20:04 |
| harlowja | alexpilotti guess u'll have to rebase | 20:04 |
| harlowja | https://github.com/stackforge/cloud-init should be all good to code on now :-P | 20:04 |
| harlowja | world peace to come later, lol | 20:04 |
| alexpilotti | heh | 20:05 |
| harlowja | smoser do we want to drop https://github.com/cloud-init/cloud-init ? | 20:06 |
| harlowja | or link it or mirror it or something? | 20:06 |
| harlowja | https://review.openstack.org/169904 for those that are bored, ha | 20:07 |
| smoser | is there any infrastructure to magically keep those in sync ? | 20:07 |
| harlowja | smoser unsure | 20:07 |
| harlowja | probably :-/ | 20:07 |
| jetole | alexpilotti: I just posted the updates you asked for via http://ask.cloudbase.it/question/401/issues-with-meta-activate-serial-and-hdd-extend/ - It looks to me like python is not finding the hostname module. I've never done python on Windows and wouldn't know where to look for that plus you may know if it's more than it appears from experience :-) | 20:11 |
| claudiupopa | jetole: plugins=cloudbaseinit.plugins.windows.sethostname.SetHostNamePlugin, | 20:20 |
| claudiupopa | That's actually plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin, | 20:20 |
| claudiupopa | s/windows/common/ ;-) | 20:20 |
| claudiupopa | The unattend conf had it right though. | 20:21 |
| jetole | OK. I actually copied the plugins lines from the stackforge readme | 20:22 |
| jetole | Is there a more current one? | 20:22 |
| claudiupopa | Yep. | 20:23 |
| claudiupopa | Just updated it today. | 20:23 |
| jetole | on stackforge? | 20:23 |
| claudiupopa | Yeah. | 20:23 |
| claudiupopa | In fact, ups, sethostname is still wrong. | 20:23 |
| jetole | ok... | 20:24 |
| jetole | s/windows/common/ <- is that for all plugins? | 20:24 |
| claudiupopa | No, some of them are windows specific. | 20:24 |
| claudiupopa | The rest are nicely abstracted so that they work on any platform. | 20:25 |
| jetole | claudiupopa: can you check my whole plugins line there and let me know which other ones I should adjust, please? | 20:25 |
| claudiupopa | Sure. | 20:25 |
| jetole | thank you | 20:25 |
| claudiupopa | networkconfig is common, as well as mtu. | 20:27 |
| claudiupopa | As well as sethostname. | 20:27 |
| jetole | claudiupopa: extendvolumes and activate windows still use "windows"? | 20:28 |
| claudiupopa | Yes, they windows specific. | 20:29 |
| claudiupopa | Except extendvolumes, which is somewhat a leaky abstraction right now. | 20:29 |
| claudiupopa | https://github.com/stackforge/cloudbase-init/blob/master/cloudbaseinit/plugins/common/factory.py#L23 | 20:29 |
| claudiupopa | This should give you a fair idea of what is what. | 20:29 |
| jetole | If I just reboot this instance on the stack, will that test the changes I made to cloudbase-init.conf or do I have to re-sysprep? | 20:29 |
| claudiupopa | You'll have to resysprep. Or delete a key from the registry. | 20:30 |
| claudiupopa | There's a key where cloudbaseinit logs the status of the executed plugins. | 20:30 |
| jetole | do you have the path? | 20:30 |
| jetole | quicker to test and than I can re-sysprep on my workstation and re-upload once I know I have a working config | 20:31 |
| claudiupopa | Should be under 'SOFTWARE\\Cloudbase Solutions\\Cloudbase-Init\\' | 20:32 |
| claudiupopa | HKLM. | 20:32 |
| harlowja | windows registry | 20:33 |
| harlowja | eck | 20:33 |
| harlowja | runs away | 20:33 |
| jetole | harlowja: I don't have a \\HKLM\SOFTWARE\Cloudbase Solution\ | 20:34 |
| harlowja | i defer to others here | 20:34 |
| jetole | Do you think the import error may have caused an exit before it was written | 20:34 |
| harlowja | really will run away ha | 20:34 |
| * harlowja running to food | 20:34 | |
| harlowja | lol | 20:34 |
| jetole | ;-/ | 20:34 |
| jetole | :-/ | 20:35 |
| * jetole does the reboot | 20:35 | |
| claudiupopa | jetole: if you don't have any, that's good, no plugin was executed then, so doing a reboot should do it. | 20:36 |
| jetole | Something else I wanted to ask about. I use a app which provides the initial password, in plain text, in json ['meta']['initialpass'] via http://169.254.169.254/openstack/2012-08-10/meta_data.json. Can I set a user password via this data? | 20:36 |
| jetole | I had to write some python code to use this in Linux as I could not find a way to do it natively via cloud-init and a few members of this room (weeks ago) confirmed it could not be done natively | 20:37 |
| claudiupopa | jetole: in cloudbaseinit it needs to be in ['meta']['admin_pass']. | 20:40 |
| jetole | so that's a no | 20:41 |
| claudiupopa | Yes, basically. | 20:41 |
| jetole | it's ok | 20:42 |
| jetole | I am getting a terminal prompt for a password via sysprep now and will port the python later | 20:42 |
| jetole | claudiupopa: Here's the updated console output: http://paste.openstack.org/show/Jf99AeXArfzL3INP4QRi/ | 20:43 |
| jetole | I am seeing the hostname is set but the volumes are not extending and windows is not being activated. It has a valid MAK key and if I click on activate windows than it activates just fine but cloudbase-init isn't extending hdd or activating | 20:44 |
| jetole | whoa | 20:45 |
| jetole | wait a second | 20:45 |
| jetole | the hdd now appears to be extended | 20:45 |
| jetole | and windows is activated | 20:46 |
| * jetole does a happy dance | 20:46 | |
| === [1]claudiupopa is now known as claudiupopa | ||
| jetole | claudiupopa: If I test this on a local kvm-qemu without the 169.254.169.254 meta data, will this run or fail @ hdd-extend and activate? | 21:05 |
| claudiupopa | jetole: you mean without any metadata service? | 21:08 |
| jetole | right. This is just for testing on local workstation before uploading to the stack | 21:09 |
| claudiupopa | Then it will definitely fail. cloudbase-init tries to load the metadata before starting any plugin. | 21:09 |
| claudiupopa | If it finds no available metadata service, it fails. | 21:10 |
| jetole | OK | 21:10 |
| jetole | any recommendation for how I could run a easy to deploy testing meta server on my local net | 21:10 |
| claudiupopa | Probably we could add some sort of local for-testing service. | 21:11 |
| jetole | actually I have hit the meta server wall on linux / cloud-init too | 21:11 |
| jetole | would be better if there is a for testing meta framework | 21:11 |
| claudiupopa | In the mean time, I guess you could "mock" a metadata service, by starting a local Python / Ruby / Perl server which exports the expected api. | 21:14 |
| claudiupopa | And then just setting metadata_base_url to point to your mocked service. | 21:14 |
| claudiupopa | metadata_base_url in config file I mean. | 21:14 |
| alexpilotti | claudiupopa: we could also just provide a DummyMetadata class | 21:19 |
| alexpilotti | which implements the base class w/o doing anything else | 21:20 |
| jetole | claudiupopa, do you want to add a answer to my issue @ http://ask.cloudbase.it/question/401/issues-with-meta-activate-serial-and-hdd-extend/ regarding s/windows/common/ ? I was about to but I wanted to reference you for credit and don't know how since I hardly ever use this service | 22:05 |
| jetole | alexpilotti and claudiupopa: How do you guys deal with building images? Do you upload every test image to the stack? Isn't that time consuming? | 22:28 |
| alexpilotti | jetole: it’s ok, it’d be great if you could answer and mark it as an answer :-) | 22:30 |
| alexpilotti | about images: they get cached on compute nodes, so after the first boot it’s fast even if they are relatively big | 22:31 |
| jetole | alexpilotti: no I know but I mean when you're building images like, for example, right now I'm building the redeployable win2kr2 image for our stack and I need the meta data to run it which I don't have locally so right now I am doing a lot of dev, upload, test, debug, upload, test, Q&A with you guys (would have been lost without it), upload, test and for me it's pretty time consuming | 22:33 |
| jetole | I mean if there is no dummy meta server than there still has to be a better way than this | 22:33 |
| alexpilotti | we use these Powershell cmdlets to automate the process: https://github.com/cloudbase/windows-openstack-imaging-tools | 22:34 |
| alexpilotti | it’s fully automated, but it takes 1-2 hours per image | 22:34 |
| alexpilotti | the Windows updates are the time consuming part | 22:35 |
| alexpilotti | if you dont care about updates, it can be fully done offline | 22:35 |
| jetole | not bad. I'm on Linux workstation but I could always rdp. There's a bunch of Linux options too for automated builds but for build and test, with the whole upload thing, it just seemed to me like there would have been a less time consuming way. For example, I mean if it wasn't for the meta-data, I could just poweroff the system after a sysprep, qemu-img a backing file for qcow2, boot it up and test in a matter of minutes | 22:36 |
| jetole | yeah I did the updates on the pre-rollout but that was a one-off task | 22:36 |
| jetole | for dev & QA, I'm having to re-deploy for every test but oh well | 22:37 |
| jetole | just hoped the pros had a better path | 22:37 |
| jetole | Forgot to mention I'm using qcow2 locally for snapshots and backing_files to expedite dev but the stack is using ceph and qcow2 on ceph isn't a good idea so I also have the qemu-img convert time before each upload | 22:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!