[09:28] <openstackgerrit> Merged stackforge/cloud-init: Change the API of wait_any_url to return a tuple of url and response  https://review.openstack.org/191100
[09:56] <Odd_Bloke> claudiupopa: Review of https://review.openstack.org/#/c/191137/ is blocking the other two things you reviewed from landing. :)
[09:56] <Odd_Bloke> (Apologies if you were already getting to it)
[09:56] <claudiupopa> ah, missed it.
[09:56] <claudiupopa> thanks
[09:57] <claudiupopa> This means that the documentation for windows specific modules will not be created by autodoc?
[09:59] <Odd_Bloke> claudiupopa: It does; but that's unavoidable unless we make the things we want to document importable on the doc-building host.
[09:59] <claudiupopa> can it be done manually at least?
[10:00] <Odd_Bloke> claudiupopa: I don't know, let me have a play.
[10:01] <Odd_Bloke> claudiupopa: (If you could approve that, I'll submit any progress I make as a separate change)
[10:02] <claudiupopa> ok, no need to block this. We'll write them by hand.
[10:02] <Odd_Bloke> smoser: I've updated https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp1464253/+merge/261849 with full parameter names and no use of shell=True.
[10:04] <openstackgerrit> Merged stackforge/cloud-init: Don't try to generate autodoc for Windows modules.  https://review.openstack.org/191137
[10:05] <openstackgerrit> Merged stackforge/cloud-init: Fail the doc build if we have any warnings.  https://review.openstack.org/191149
[10:06] <openstackgerrit> Merged stackforge/cloud-init: Add doc8 checks to docs tox target.  https://review.openstack.org/191162
[10:07] <Odd_Bloke> claudiupopa: Thanks for the reviews. :)
[10:07] <claudiupopa> No problem. ;-)
[10:25] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Clean up stale auto-generated autodoc files.  https://review.openstack.org/191139
[11:04] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Clean up stale auto-generated autodoc files.  https://review.openstack.org/191139
[11:36] <Odd_Bloke> claudiupopa: http://paste.ubuntu.com/11718962/ lets us autodoc more of the Windows code, but does make the Windows code uglier as a result.
[11:37] <claudiupopa> that's quite ugly.
[11:38] <Odd_Bloke> Well, you chose an ugly platform. ;)
[11:38] <Odd_Bloke> If we bike-shed for long enough, Windows will probably be UNIX-based, right? :p
[11:39] <Odd_Bloke> claudiupopa: Yeah, it's totally ugly; but I don't think we'll do any better with autodoc.
[11:39] <Odd_Bloke> I'll have a look and see if there are any tools that can do autodoc-style stuff, but with static analysis.
[11:39] <Odd_Bloke> Those should work OK.
[11:39] <claudiupopa> That would be cool.
[11:39] <claudiupopa> We could write one if not.
[11:40] <Odd_Bloke> claudiupopa: Yeah, though Sphinx plugins are fairly painful to write.
[11:41] <claudiupopa> can't we hook autodoc instead?
[11:42] <Odd_Bloke> claudiupopa: Having a quick look through autodoc's source, it's pretty tied up with having a Python object that it can examine.
[11:43] <Odd_Bloke> Preprocessing the files to remove everything except for docstrings _might_ work...
[11:44] <Odd_Bloke> But I suspect that having some scripting which does this will be a lot less painful than trying to integrate it in to the Sphinx run itself.
[11:45] <claudiupopa> Yeah, I mean it doesn't need to be an autodoc extension, as long as it builds .rst files from .py, all should be good.
[11:47] <Odd_Bloke> Yeah.
[11:48] <claudiupopa> Let's see if Joshua doesn't already have something like this. ;-)
[11:48] <Odd_Bloke> :D
[11:49] <Odd_Bloke> harlowja: ^^  ^_^
[12:20] <Odd_Bloke> claudiupopa: harlowja: Thinking about it, I'm not sure that our use case (for reporting) really needs a library.
[12:20] <Odd_Bloke> claudiupopa: harlowja: If there was a library that would give us _handlers_ for free, that would be more interesting.
[12:21] <Odd_Bloke> But the pub-sub sort of a model is overkill; we'll only have one publisher, and a constrained number of subscribers (which will all be configured in the same place at the the same time, from configuration).
[12:21] <Odd_Bloke> If we want to use pub-sub more generally within cloud-init, then it would obviously make sense for the reporting framework to use that.
[12:21] <Odd_Bloke> But I don't think it justifies it in and of itself.
[12:22] <claudiupopa> yeah, makes sense, it's a little overkill for our use case.
[14:05] <claudiupopa> Odd_Bloke: harlowja: do we actually need something heavy weight as this https://github.com/stackforge/cloud-init/blob/master/cloudinit/version.py#L9?
[14:05] <claudiupopa> in certain conditions, it looks for a git repo and tries to run a git command.
[14:09] <Odd_Bloke> claudiupopa: Are you hitting problems with it?
[14:10] <claudiupopa> yeah.
[14:10] <claudiupopa> http://paste.openstack.org/show/294140/
[14:10] <claudiupopa> Not related per se (I think), but I can't stop noticing the git calls.
[14:11] <claudiupopa> It's executed from a local editable installation.
[14:12] <Odd_Bloke> Yeah, it doesn't look directly related.
[14:12] <Odd_Bloke> But that isn't ideal.
[14:14] <Odd_Bloke> On the other hand, we shouldn't hit that in a proper installation.
[14:14] <Odd_Bloke> harlowja: Thoughts?
[17:30] <harlowja> sup
[17:31] <harlowja> just got in
[17:31] <harlowja> claudiupopa i there another claudiu in your work place?
[17:31]  * harlowja gets confused when i see another claudiu 
[17:31] <harlowja> lol
[17:32] <harlowja> Odd_Bloke u no want my pub/sub thingy, lol
[17:33] <harlowja> as far as https://github.com/stackforge/cloud-init/blob/master/cloudinit/version.py#L9 up to u guys
[17:34] <harlowja> i'm fine with the second way, or just a static string (that someone remembers to update)
[17:35] <smoser> harlowja, there are 2 claudiu in cloudbase
[17:35] <harlowja> i knew its!
[17:35] <smoser> and it is very confusing
[17:35] <harlowja> :-P
[17:35] <smoser> i had a conversation at ODS with someone who said 'hi, i'm claudio from cloudbase'
[17:35] <harlowja> ya, i had to double-check on https://review.openstack.org/#/c/191168/
[17:35] <smoser> and i said... um i don't think you are
[17:35] <harlowja> lol
[17:36] <harlowja> did u ask for ID then?
[17:36] <harlowja> lol
[17:37] <smoser> i sent him a gpg encrypted email with a password that was required before i would continue the conversation
[17:37] <smoser> my social skills are l33t
[17:37] <harlowja> lol
[17:37] <harlowja> ha
[17:37] <harlowja> def
[18:18] <awkwords> l
[19:04] <jaksi> hi!
[19:05] <jaksi> I'm playing around with cloud-init. I don't really need a "cloud", I'm using the nocloud data source with QEMU, which works great as I can attach files as disk devices on the VM
[19:05] <jaksi> is there a way to do something similar with conainers?
[19:07] <smoser> jaksi, yeah.
[19:08] <smoser> http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html
[19:08] <smoser> essentially you just write the same files that go on that disk into /var/lib/cloud/seed/nocloud-net/d
[19:09] <ByPasS> smoser : quick question, I cannot seem to get linux vms to get the random generated password by nova injected by cloud-init
[19:09] <jaksi> ah, great, thanks a lot!
[19:09] <ByPasS> smoser : curl 169.254.169.254/openstack/latest/password is just plain empty
[19:11] <ByPasS> smoser : I've been trying alot different configs but I guess that until the nova metadata is empty it will never succeed, any idea what is wrong or a direction to verify look for ?
[19:11] <smoser> ByPasS, cloud-init doesn't pay attention to that.
[19:11] <smoser> use ssh keys.
[19:15] <smoser> ByPasS, but that said, i really haven't ever looked at it.
[19:15] <smoser> i can verify that on my cloud
[19:15] <smoser> 'password' is present in curl http://169.254.169.254/openstack/latest/
[19:15] <smoser> but empty at curl http://169.254.169.254/openstack/latest/password
[19:21] <ByPasS> smoser : oh let me check
[19:24] <ByPasS> yea thats basicly my issue, I do agree to use ssh keys but it seems the project manager wants password injection for some obsucre reasons
[19:28] <smoser> echo "root:$(curl http://169.254.169.254/openstack/latest/password)" | sudo chpasswd
[19:28] <smoser> ^ ByPasS something to that affect might work.
[19:28] <smoser> ByPasS, i wonder, is that a one time read thing ?
[19:30] <ByPasS> smoser : runcmd on first boot you mean ?
[19:31] <ByPasS> smoser : could be I will test it but as far as I know, with cloudbase-init for windows the metadata is still present upon reboots etc
[19:31] <smoser> yeah.
[19:31] <smoser> then, yeah, its porbably not read-once
[19:31] <smoser> (which you might want it to be :)
[19:32] <smoser> alexpilotti, probably knows how it works. i'd have to look at code.
[19:47] <ByPasS> smoser : thatd be great I will still try it just in case :) who knows