| Odd_Bloke | smoser: I'm looking at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1381776; how do you feel about adding python-serial to cloud-init's dependencies? | 10:51 |
|---|---|---|
| Odd_Bloke | smoser: (On precise) | 10:51 |
| Odd_Bloke | And probably trusty, as it's missing there as well. | 10:52 |
| Odd_Bloke | smoser: It's already installed on our normal Ubuntu images because of Landscape (via twisted), which is why we haven't seen this bug more. | 10:52 |
| Odd_Bloke | smoser: https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp1475215/+merge/264967 is a nice, easy review if you have a minute. | 12:51 |
| Odd_Bloke | smoser: (I'm currently assuming that we're code reviewing everything that goes in to 0.7.x) | 12:52 |
| smoser | Odd_Bloke, merged thanks. | 13:15 |
| smoser | i'm surprised. about 1381775. | 13:16 |
| smoser | i'm surprised. about bug 1381776 | 13:16 |
| Odd_Bloke | smoser: Thanks. :) | 13:16 |
| Odd_Bloke | smoser: So you only need it installed if you include a DS that requires it in your list of DSes. | 13:17 |
| smoser | i tihnk its robably just an oversite | 13:17 |
| smoser | at very least it should be Recommends | 13:17 |
| Odd_Bloke | But by default, you will have such a DS. | 13:17 |
| Odd_Bloke | It's in Depends in vivid. | 13:17 |
| smoser | ah. ok. | 13:17 |
| Odd_Bloke | So, I agree, I think it's just an oversight. | 13:17 |
| smoser | well then. | 13:17 |
| smoser | fix if you want. | 13:18 |
| smoser | i'd like to not hvae python-serial, as i think it is not pure python. | 13:18 |
| smoser | and not really sure why you can't just open up /dev/ttyS1 and write to it. | 13:19 |
| smoser | Odd_Bloke, https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp1411582/+merge/264831 | 13:32 |
| smoser | why azure_resource-part1 and azure/resouce-part1 ? | 13:32 |
| Odd_Bloke | smoser: The first is what we put in place with the cloud-init udev rules. | 13:33 |
| Odd_Bloke | smoser: The second is what walinuxagent puts in place with its udev rules. | 13:34 |
| smoser | do i care about the second ? | 13:34 |
| smoser | i'm not really opposed to this, but just wondering. | 13:34 |
| smoser | and maybe lets at least explain/comment to that effect | 13:34 |
| Odd_Bloke | smoser: If the packaging for cloud-init is done badly, but the packaging for walinuxagent is alright, this will still work. | 13:34 |
| Odd_Bloke | smoser: (So really more of a consideration for non-Ubuntu systems) | 13:35 |
| smoser | if the packaging for cloud-init is done badly, then we should fix that :) | 13:35 |
| smoser | i'm ok with it. but can you add a comment to why we're searching some seemingly non-existent path ? | 13:35 |
| Odd_Bloke | smoser: Yep, good shout. | 13:36 |
| smatzek | on the topic of adding dependencies to the cloud-init package for individual datasources, I'd rather not have them as hard dependencies. Some of those dependencies are sometimes not available for some Linux distros on non-x86 architectures. | 13:38 |
| smatzek | that being said I see the point of view of including them as depndencies and distros should adapt the rpm requirements list appropriately when they build the RPMs. I just know I had trouble with this with dmidecode which was not available for ppc64 in either RHEL or SLES or both, I can't remember which. | 13:39 |
| smoser | yeah, its hard though. | 13:39 |
| smoser | because many people will not have need of many of these things. | 13:39 |
| smoser | if they're building an image, they dont necessarily need all datasources functional. | 13:39 |
| Odd_Bloke | Yeah. | 13:40 |
| Odd_Bloke | Maybe it should be a Recommends. | 13:41 |
| smatzek | in v2 this could be solved by packaging each datasource or groups of related datasources together in their own package which updates cloud.cfg to add themselves in. Then image builders could would install datasource packages they want available. This seems like a lot of extra overhead to solve this issue though. It could be solved by Recommends and then documentation on which datasources require which extra packages above and beyond the baseline | 13:42 |
| smatzek | requirements. | 13:42 |
| Odd_Bloke | Yeah. | 13:43 |
| smoser | we do have a goal of datasources being more stand alone | 13:43 |
| Odd_Bloke | There are only a few use cases where you would actually care about having the extra handful of Python libraries. | 13:44 |
| Odd_Bloke | So Recommends is probably the way to go, then people who care can uninstall/not install requires. | 13:44 |
| Odd_Bloke | s/requires/recommends/ | 13:44 |
| smoser | for ubuntu i think recommends makes sense for stuff that could be annoying. and i'm not opposed to packaging datasources seperately uon ubuntu either. | 13:45 |
| smatzek | if we go the route of recommends, the datasources that have requirements above the baseline like dmidecode which has native code (AltCloud, SmartOS), Sigma, etc should try-except around their imports to handle it gracefully and put a nice message out that says "we require package xyz for datasource abc" | 13:50 |
| smoser | yeah | 13:51 |
| Odd_Bloke | True. | 13:51 |
| Odd_Bloke | So for python-serial in precise and trusty should I: (a) Depends, (b) Recommends, or (c) Recommends and code changes as per smatzek's comment? | 13:52 |
| Odd_Bloke | (c) is a bit of PITA to do in maintenance. | 13:52 |
| smoser | make same change as in vivid | 13:54 |
| Odd_Bloke | Cool. | 13:54 |
| smoser | Odd_Bloke, for 2.0, how can i render README.rst easily ? to test see if my change is sane? | 13:55 |
| smoser | this seems to work: | 13:58 |
| smoser | tox-venv docs rst2html README.rst > /tmp/out.html | 13:58 |
| Odd_Bloke | That seems reasonable. | 13:58 |
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: README.rst: mention bugs are tracked in launchpad https://review.openstack.org/202576 | 13:59 |
| Odd_Bloke | smoser: Do we want to track bugs in the same place as 0.7.x? | 14:06 |
| Odd_Bloke | I worry it might become confusing. | 14:06 |
| smoser | Odd_Bloke, i dont know. i dont want two separate projects in launchpad. | 14:11 |
| smoser | i did make a 2.0 series, but i've not played much | 14:11 |
| Odd_Bloke | Why not separate projects? | 14:11 |
| smoser | Odd_Bloke, i think separate projects is more confusing than single project. | 14:27 |
| smoser | and in 3 years, you'll say "why is this one named cloud-init 2.0" | 14:27 |
| Odd_Bloke | Provided we can clearly delineate between 2.0 bugs and 0.x bugs, that's not a problem. | 14:28 |
| Odd_Bloke | But if we have the same bug in each cloud-init, a single commit won't fix it. | 14:28 |
| Odd_Bloke | And so it might be a bit harder for people looking at bugs to understand whether they should be fixed or not etc. | 14:29 |
| smoser | https://launchpad.net/cloud-init/2.0 | 14:30 |
| smoser | i'm not really sure what all you can do with 'series' | 14:30 |
| smoser | but i think essentially 'wily' is a series | 14:31 |
| smoser | i thikn launchpad intends to model what we need. | 14:31 |
| Odd_Bloke | Cool. :) | 14:31 |
| smoser | yeah, https://launchpad.net/ubuntu/+series | 14:36 |
| smoser | thats heavier use then i surely would hope to have. | 14:36 |
| pankaj2934 | what is the diffrence user for /var/lib/cloud/scripts/* folder and /etc/cloud/cloud.cfg.d/ folders | 15:02 |
| pankaj2934 | use for * | 15:02 |
| pankaj2934 | once the instance is booted up i want to have cloud-init make a REST call to a service . what would be best place to place the code . | 15:06 |
| pankaj2934 | once the instance is booted up i want to have cloud-init make a REST call to a service . what would be best place to place the code . | 15:09 |
| smoser | pankaj2934, /var/lib/cloud/scripts/* are executables | 15:41 |
| smoser | /etc/cloud/cloud.cfg.d/ is configuration | 15:41 |
| smoser | you might be able to just use 'phone_home' | 15:43 |
| smoser | http://cloudinit.readthedocs.org/en/latest/topics/examples.html | 15:43 |
| pankaj2934 | @Smoser so if i write a abc.cfg file with phone_home code in it (as from the example ) and put the file in /etc/cloud/cloud.cfg.d/ of the image anytime a new instance is created phone_home call will be made. ? can we haev multiple phone home in multiple cfg file ? | 15:57 |
| smoser | all config files get merged into a single config | 15:58 |
| smoser | so "last one wins" that defines the phone_home url | 15:58 |
| Odd_Bloke | smoser: It looks like you didn't push to Launchpad when you did the last Vivid SRU; would you be able to push that up? | 16:41 |
| smoser | probably, let me check | 16:41 |
| smoser | done | 16:42 |
| Odd_Bloke | Danke. | 16:42 |
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add cloud-init main https://review.openstack.org/202743 | 18:50 |
| smoser | Odd_Bloke, ^ | 18:50 |
| smoser | harlowja_, we need some test coverage on logging and url_helper bad. | 19:00 |
| harlowja_ | more test coverage? | 19:00 |
| harlowja_ | on logging :-/ | 19:00 |
| smoser | http://paste.ubuntu.com/11889248/ | 19:00 |
| harlowja_ | i thought it was 200% | 19:00 |
| harlowja_ | 200% covered all the things | 19:00 |
| harlowja_ | ah, the mysticism of coverage numbers :-P | 19:01 |
| smoser | harlowja_, yu're not looking at writing test 'right nwo' are you? cause if not, i'm gonna spend next 30 minutes or so. | 19:45 |
| harlowja_ | i'm not | 19:46 |
| harlowja_ | u can :-P | 19:46 |
| smoser | k. thank you kind sir. | 19:47 |
| harlowja_ | np | 19:48 |
| harlowja_ | lol | 19:48 |
| harlowja_ | np sir | 19:48 |
| pankaj2934 | scenario: user puta hostname:mywebserver in openstack horizon and server gets named mywebserver. but our admin team has a naming standard. is it possible to restrict usrs to pass only certain user-data and not all | 20:54 |
| smoser | you' dhave to enforce that on openstack side. | 21:00 |
| pankaj2934 | how can that be done. i could not find any option in nova so i thought there might be somethign in cloud-init | 21:00 |
| smoser | no. cloud-init doesnt have anythign like it. | 21:01 |
| smoser | youd have to change openstack to just load the user-data on the way in. | 21:01 |
| smoser | inspect it. | 21:01 |
| smoser | you probably dont want to do that. | 21:01 |
| pankaj2934 | yes : biggest problem we have developers have learnt cloud-init and they haev started putting user-data whcih runs as root and deviates the build from standard | 21:03 |
| pankaj2934 | can we have cloud-init not process user-data but still process everything in cloud.cfg.d and scripts folder ? | 21:04 |
| === zz_natorious is now known as natorious | ||
| === natorious is now known as zz_natorious | ||
| === zz_natorious is now known as natorious | ||
| === natorious is now known as zz_natorious | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!