[00:43] claudiupopa https://review.openstack.org/#/c/170242/ updated :-P [07:51] Howdi are there still static network bugs in cloud-init related to Ubuntu? https://bugs.launchpad.net/cloud-init/+bug/1225922 [08:05] never mind user error [10:34] claudiupopa: Do you know how the gate Jenkins jobs are configured? [10:35] claudiupopa: Specifically, I'm wondering if we can enable coverage testing. [10:37] Through openstack-infra/project-config. [10:37] See this for example https://review.openstack.org/#/c/169293/ [10:37] Never tried it though, so I'm not sure. [10:40] claudiupopa: Cool, thanks for the pointer. [10:40] It looks like none of the coverage jobs in Jenkins have ever run, so I'm probably chasing up the wrong tree. :p [11:00] but nevertheless we should have coverage enabled. :P [11:01] claudiupopa: Yeah, see https://review.openstack.org/188739 [11:02] I'm happy to bike-shed on the number (probably with input from smoser and harlowja). [11:05] nice. [11:05] 90% seems sufficient for the moment. [11:05] Yeah, for me it's more of a statement that we care about it. === rangerpbzzzz is now known as rangerpb [15:06] Is it possible to merge user_data from multiple datasources? [15:07] I'm trying to create an AMI that has a static cloud-config in a file and I want that to be bundled with the normal EC2 datasource processing, but can't seem to figure out how to do it [15:11] The standard behavior does merge /etc/cloud/cloud.cfg along with any cloud-config data provided via the metadata service. [15:12] But user_data can only come from one source, I think. [15:12] so I can just specify a user-data section in /etc/cloud/cloud.cfg and it will be merged? [15:22] I don't believe there is a way to put user-data into a cloud-config file, no. [15:22] But you can do other things, like write files, run shell scripts, etc. [15:36] harlowja: Hmm, let me look at that doc thing. [15:36] harlowja: It Works On My Machine (TM). ;) [15:39] harlowja: Aha, got it; I was using environment variables in tox rather than doing it properly in setup.cfg; good catch. [15:43] Ah, so it's not clear for the documentation that you can put files in /etc/cloud/cloud.cfg.d and there formats are just the same as what you would be put in user-data [15:43] but that works [16:07] harlowja: http://docs-draft.openstack.org/75/188775/2/check/gate-cloud-init-docs/c600b34//doc/build/html/contents.html HAPPY NOW? [16:10] harlowja: So after you approve a change, do I still need another core dev to +2 it for it to get merged? [16:10] * Odd_Bloke hasn't used the OpenStack CI stuff before. [16:12] isn't autodoc importing modules? [16:12] claudiupopa: It does; we can exclude modules from it though. [16:13] what will happen when it will include windows specific stuff? [17:10] Odd_Bloke cool, 90% ya, hmmm [17:10] i like 125% [17:10] lol [17:13] Odd_Bloke there is also some ci coverage job that afaik the openstack CI stuff runs [17:13] perhaps we should also just use that? [17:14] harlowja: https://jenkins.openstack.org/job/cloud-init-coverage/ ? [17:14] something like that ya, ha [17:14] * harlowja never remebers what it runs [17:14] harlowja: If you can work out how to actually use that, be my guest. :p [17:14] Odd_Bloke how about jumping on the #openstack-infra channel and asking [17:15] So demanding. [17:15] those folks know, ha [17:15] i asked once upon a time, but i forgot, lol [17:16] because if u search for 'coverage' in https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml u'll see many [17:16] https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L5223 maybe just needs something to be added? [17:16] *the cloud-init section [17:21] You've done it now, harlowja, I'm having to clone project-config. [17:21] woot [17:21] ha [17:35] harlowja: So I'm not 100% sure that using that job makes sense; it will run a single tox environment, so we won't be able to easily get coverage for each Python version. [17:35] can that be fixed? [17:36] * harlowja doesn't know the answer to that [17:36] fixed/changed/soemting [17:37] harlowja: My tox-fu is possibly lacking, but I don't think so. [17:37] would infra be willing to change something? [17:37] *would that help? [17:39] if not i guess we do what we have to do then [17:41] harlowja: So I _think_ -infra would need to move to a model similar to the different versions of Python (i.e. separate coverage27, coverage34 jobs). [17:41] is that possible? [17:41] Note the timestamps, I said that before fungi did. ;) [17:45] maybe some small change to https://github.com/openstack-infra/system-config/ or project-config will make this possible [17:45] and then everyone will be jolly and happy [17:47] harlowja: Perhaps, but for now I think the solution in that code review is the best we have. [17:48] sure, for now == forever ? ;) [17:48] If someone else implements the infra changes, I will happily take care of transitioning us to use them. ;) [17:49] we gotta be BFF with the infra folks, if we want automated cloud-init jobs (with real-images) [17:49] someone needs to be better BFF than i am, ha [17:53] aka, probably just needs some way to connect a coverage script into https://github.com/openstack-infra/project-config/tree/master/jenkins/scripts [17:53] instead of just using tox -ecoverage or whatever [17:54] harlowja: Looking at how things are done elsewhere, I think it would definitely need to go through tox. [17:54] That's how projects get to customise things. [17:55] And that could be problematic. [17:55] right [17:55] Because tox knows what py27 and py34 mean, so sets things up properly before executing testenv. [17:55] but https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/run-tox.sh is already existing, maybe it can be used [17:55] afaik that thing is running all the other tox stuff already [17:55] https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/run-tox.sh#L122 ... [17:55] * harlowja doesn't get what that couldn't be used to run different coverage venvs or something [17:57] harlowja: If you want to run coverage on 3.4, you'd need to do something like "tox -e coverage-py34". [17:57] right [17:57] harlowja: But tox doesn't know what that is, so you have to define it in your tox.ini. [17:58] sure, and then we need the infra team to have that job run that triggers that venv [17:58] But you'd _also_ have to define coverage-py27. [17:58] There isn't a way to get them to share their definition. [17:58] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/projects.yaml#L18 [17:58] add that job to cloud-nit [17:58] then have envlist beee [17:58] (Whereas py26, py27, py34 et al are defined to use testenv) [17:58] - coverage-py27 [17:58] - coverage-py34 [17:59] - coverage-py26 [17:59] ? [17:59] afaik that is a custom tox env that gets used [17:59] and could just be one we use to [17:59] harlowja: Right, I'm saying that we'll have to define each of those separately in our tox.ini. [17:59] put that under https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/projects.yaml#L3457 and profit? [17:59] sure [17:59] but at least infra will run it for us [18:00] And all this really gains us is waiting for two extra Jenkins jobs. :p [18:00] ya, meh [18:00] they run in parallel [18:00] * https://review.openstack.org/#/c/187750/ (already used to waiting, ha) [18:01] we'll likely need more soon anyway (if we can get real cloud-init from the commit into some image job that also gets basic tests) [18:01] ^ therefore ensures the cloud-init from that commit functions to some level [18:01] * ie a windows image could be part of that (or linux, or freebsd...) [18:08] harlowja: It occurs to me that we also have this problem with pep8; we'll only be running that for either 27 or 34. [18:09] more tox envs [18:09] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/projects.yaml#L1545 (another project i'm a core of) [18:09] probably should just start adding ones we want into that... [18:09] *into something similar for cloud-init [18:09] Odd_Bloke want to submit those ;) [18:09] harlowja: Yeah, will do. [18:10] Seeing if I can do some tox magic to reduce repetition. [18:10] k [18:10] I really want "[testenv:coverage-{env}]" to DWIM. [18:10] https://github.com/openstack/taskflow/blob/master/tox.ini#L41 [18:10] u can refer to other envs from other envs [18:10] ^ from another project i'm a core on, lol [18:10] maybe something similar [18:10] but idk, thats all my tox-fu i got, ha [18:12] ok back to url_helper stuff [18:14] project-config stuff (and infra reviews in general) seem to take a while btw, like a week(ish) [18:14] just fyi [18:14] That's fine, I only have about a day a week on cloud-init 2.0 stuff. :p [18:15] thats 24hours [18:15] use it or lose it [18:15] lol [18:15] i expect 24 hours worth of work done [18:15] or else [18:15] chop chop [18:15] I didn't mean one of your Earth days. [18:16] :-/ [18:16] where u at [18:16] lol [18:17] harlowja: Eris sounds about right: http://www.bobthealien.co.uk/table.htm :p [18:17] your message sure do come quickly [18:17] how are u bypassing light-speed limit? [18:17] Erisians have precognition. [18:17] please tell me how so i can get nobel prize, lol [18:17] harlowja: You didn't answer my earlier question: do I need to bug another cloud-init core dev to review the things that you've +2'd? [18:18] likely, if we want to be 'official' about all this [18:18] Cool. [18:18] The green tick is confusing. :p [18:18] needs a +2 +a (approve) [18:19] so ya, 2 usually is how it goes [18:19] although meh, sometimes the officalness is a waste of life/time [18:19] and a +1 from jenkins [18:23] is their any man pages for cloud-init? [19:24] harlowja: With this tox config: http://paste.ubuntu.com/11593770/ and http://paste.ubuntu.com/11593770/, I think we'll be good. [19:24] harlowja: Thoughts? [19:24] seems ok to me, not sure how 'coverage-{py27,py34}' works in envlist [19:28] but if it works, okie dokie [19:28] harlowja: It works fine. :) [19:28] k [19:28] i've usually just seen them individually listed [19:28] but if it works, thats cool [19:37] harlowja: Bah, it apparently does not work fine. [19:37] :-P [19:41] harlowja: I suspect that I'm getting screwed by an old version of tox. [19:42] possibly, ha [19:42] just individually list them? [19:42] That isn't even the bit that errors. ;.; [19:44] ah [19:44] ha [19:45] And I get a different error if I use tox 1.6 (which is what's in trusty). [19:46] :-/ [19:46] AHA [19:46] ok i updated https://review.openstack.org/#/c/170242/ [19:46] They're using 2.0. [19:48] harlowja: I still don't like UrlResponse; but if we are going to keep it, could we change its names to be consistent with the requests object that it's a wrapper for? [19:49] RequestsResponse ? [19:51] harlowja: Like having OurNIHThing.contents wrap Response.content; that's actively developer hostile. [19:51] lol [19:51] And .code wrap .status_code. [19:52] k [19:52] Also having .ok be a method when requests.Response.ok is a bool. [19:54] thats cause ours is super-better [19:54] ha [19:55] * Odd_Bloke grins and nods while backing away slowly. :p [19:55] ha [19:56] * harlowja runs towards u [19:56] *fastly [19:58] let's see if we can get https://review.openstack.org/#/c/188901/ to work also [19:59] should work, not sure if that bot needs permissions or something on the channel [19:59] makes it somewhat easier tosee what to review [20:00] Odd_Bloke ChangeLog is generated by the doc build? [20:00] i guess pbr is building it [20:01] harlowja: Yeah, pbr is building it. [20:01] harlowja: Happy to stop it doing that instead, if that's what we want. [20:19] Odd_Bloke, would you say that cloud-init requires gdisk ? [20:19] sgdisk [20:19] cloudinit/config/cc_disk_setup.py [20:19] seems to use it. [20:21] smoser: Yeah, I think we need it for dealing with GPT partitioning. [20:21] so cloud-init never depended on it before. [20:21] and cloud-initramfs-utils dropped the dependency on it as it does not need it any more (it can just use sfdisk) [20:22] Ah. [20:22] Oops. [20:22] noticed this on failure to deploy wily/ppc64el as we dont have sgdisk in the image any more but we are using it for uefi/gpt partitioning [21:20] operator granted, woot [21:21] ;) [21:27] smoser operatorship granted [21:27] this allows us to get a gerritbot in here for reviews [21:37] harlowja, please grant it to me too [21:37] * harlowja will let smoser grant the rest, isn't really sure who should/shouldn't be, lol [21:38] i defer, ha === rangerpb is now known as rangerpbzzzz