[00:00] <blackboxsw> yeah, unfortunately, I didn't actually merge it ;)
[00:01] <blackboxsw> Permission denied (publickey).
[00:01] <blackboxsw> fatal: Could not read from remote repository.
[00:03] <powersj> O.o you are in the group
[00:03] <powersj> https://launchpad.net/~cloud-init-dev/+members#active
[00:04] <blackboxsw> yeah, git push origin master was a no go. hmm.
[00:04] <blackboxsw> I'll try a fresh clone merge push
[00:08] <blackboxsw> hrm fresh clone shows it merged.
[00:08] <blackboxsw> so when we git push origin master does launchpad automatically mark the branch merged?
[00:08] <blackboxsw> or is that manual
[00:09] <blackboxsw> I was used to LP marking my branches as merged automagically for bzr branches. not sure if that's the same for gitlp
[00:10] <powersj> blackboxsw: I think you have to mark it
[00:10] <powersj> I don't recall doing it automatically, only in bugs
[00:14] <blackboxsw> ok thx powersj yeah that was my confusion (and LP git was also showing stale data @ https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master)
[00:16] <blackboxsw> so I *think* rev b23d9d7 is in build https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-integration-y/227/ too, so ok, we should be testing what I landed
[01:13] <smoser> blackboxsw, powersj it will mark merge in one of 2 ways (which are really kind of the same)
[01:14] <smoser> a.) you 'git merge' && 'git push'
[01:14] <smoser> b.) you squash, rebase, push --force [to your repo], then merge
[01:15] <smoser> but only you can do 'b', and i prefer the squash to the merge. so really only people with commit access can end up getting that to happen unless they rebase exactly on master with no in the middle commits.
[01:16] <powersj> yeah squash should be done imo
[01:16] <smoser> so... often times i go and mark 'merged' and then hit the edit button for 'merged at revision'
[01:16] <smoser> and put in the actual commit id
[01:16] <smoser> powersj, so do we think we're happy in trunk now?
[01:19] <powersj> For trunk build yes
[01:19] <powersj> I do see a centos build failure: https://jenkins.ubuntu.com/server/job/cloud-init-copr-build/8/console
[01:19] <powersj> and integration tests failed but due to test failures, those were during the firewall reboot, so I'll let them go for now.
[01:25] <smoser> powersj, you're missing python-jinja there
[01:25] <smoser> is that in a fresh container ?
[01:26] <smoser> that error is horrific. it should fail with a sane error rather than attempting to render a template with 'basic' when the template declares it is jinja and it knows it has no jinja
[03:07] <blackboxsw> hmm build failure on 227 above http://pastebin.ubuntu.com/24861805/
[03:07] <blackboxsw> have we seen this before? " Could not resolve \'us.archive.ubuntu.com\"
[03:41] <powersj> what time was that failure at? It may have been during firewall maintenance
[03:41] <powersj> I should just disable tests when we have those planned...
=== sambetts|afk is now known as sambetts
[13:48] <niluje> anyone knows how to submit a merge request with launchpad?
[13:48] <niluje> the "propose for merging" button doens't seem to exist on https://git.launchpad.net/~jcastets/cloud-init/
[13:54] <niluje> oh ok. Only available from code.launchpad.net, not from git.
[13:55] <niluje> https://code.launchpad.net/~jcastets/cloud-init/+git/cloud-init/+merge/325740
[14:04] <smoser> niluje, thanks!
[14:04] <smoser> niluje, fyi http://cloudinit.readthedocs.io/en/latest/topics/hacking.html kind of explains it
[14:26] <blackboxsw> ok things looking a bit better on jenkins. though integration-x is failing w/ 2017-06-15 11:44:37,781 - tests.cloud_tests - ERROR - stage: collect for platform: lxd encountered error: Failed to create ZFS snapshot: cannot create snapshot 'default/images/ee1831d4efcc74310def225ec449c1b6a49cc371a744cbbb79ea5bf21b05c3b6@readonly': dataset already exists
[14:27] <blackboxsw> https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-integration-x/220/console
[14:29] <smoser> blackboxsw, well, at least that doesn'st smell like cloud-init code regression
[14:29] <blackboxsw> amen to that
[14:29] <smoser> https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-copr-build/8/console
[14:30] <blackboxsw> jinja template changes +  brpm changes
[14:30] <blackboxsw> smoser: I can take that if you haven't already
[14:31] <smoser> blackboxsw, you can. i think it needs jenkins change
[14:31] <smoser> right? it is just that wherever that is run it needs jinja
[14:32] <smoser> ideally it runs in a container. or it could use:
[14:32] <smoser>  ./tools/run-centos 6 --srpm --artifact
[14:33] <smoser> http://paste.ubuntu.com/24864792/
[14:34] <smoser> it could be useful to chagne run-centos to take a '--artifact-dir' to put artifacts (the srpm) in that directory rather than '.'
[14:35] <blackboxsw> that's a good call. I'll go that route
[14:35] <smoser> i dont think we need the '--artifact-dir' here as the build will always take place in a clean environment
[14:36] <smoser> https://git.launchpad.net/server-team-ci/tree/jenkins/cloud-init/centos.yaml is what you need to change i think
[14:37] <blackboxsw> yeah we can just switch CI to use run-centos I have a couple other jenkins changes from yesterday (to get deps installed for the integration-# builds too. so I'll fold them together
[14:38] <smoser> k
[14:40] <niluje> smoser: yep, I read the document but didn't notice it was only available on "code.laucnhpad.net" and not on "git.launchpad.net"
[14:43] <smoser> fair. i reviewed your proposal.
[14:43] <niluje> smoser: "we really, *REALLY* want a positive non-network identification" -> we already discussed about this on the previous PR (which was made longtimeeee ago), and unfortunately there no way to implement the on_scaleway method without hitting a network ressource
[14:43] <smoser> :)
[14:43] <niluje> you suggested to call dmidecode, it wouldn't work as we don't provide such info
[14:43] <smoser> yeah. feel free to link to that if you'd like.
[14:45] <niluje> smoser: just a thing about vendor-data. I added them in self.metadata['vendor-data']. Is it what is expected by cloud-init?
[14:50] <smoser> niluje, the datasource wants a
[14:50] <smoser>  self.vendordata_raw
[14:51] <niluje> is the interface documented somewhere?
[14:51] <smoser> well cloudinit/sources/__init__.py
[14:53] <niluje> oh
[14:53] <niluje> 'user-data' and 'vendor-data' are not expected to be in metadata
[14:54] <niluje> I thought so :p
[14:54] <smoser> well, cloud-init doesn't get to chose where you put information on the other end.
[14:55] <niluje> ok
[14:55] <smoser> i'm sorry if i sound like pestering...
[14:55] <smoser> are there plans (at least in the vms) to put some dmi information in ?
[14:55] <smoser> or some other way of identifying "you are on scaleway"
[14:58] <smoser> niluje, i'm really sorry if you've told me all this before. if I had a nickle for for all the things i'd forgotten...
[14:59] <blackboxsw> powersj: just put a branch for review https://code.launchpad.net/~chad.smith/server-team-ci/+git/server-team-ci/+merge/325745.
[15:02] <powersj> blackboxsw: thanks
[15:08] <niluje> smoser: we have two options
[15:08] <niluje> smoser: 1/ we can update our initrd to create the file /var/run/scaleway and check this file exists in cloud-init
[15:08] <niluje> 2/ we can add "scaleway" in the kernel cmdline and check it in cloud-init
[15:09] <niluje> this way the network check can go away
[15:09] <niluje> any preference?
[15:21] <smoser> since you already ahve a custom initrd, that seems fine.
[15:22] <smoser> in your vm images do you have a custom initrd ?
[15:23] <smoser> ie, the 'vc1s' does that have a custom initrd ?
[15:24] <smoser> either is fine. i think maybe kernel cmdline seems easier to maintain long term.
[15:24] <smoser> i'd like it if
[15:25] <smoser> a.) your vm instance types (vc1s, vc1m, vc1l) provided some dmi data . in theory that shoudl work even on arm64 vms (i dont know if you offer those), but reality differs
[15:25] <niluje> (yes we do)
[15:26] <niluje> for dmi data, it's really not an option as you have some baremetal servers and we don't want to maintain several solutions to identify the hardware
[15:26] <smoser> b.) your bare metal instance types, it seems like kernel cmdline is acceptable. at some point in the future when you started  being able to use stock images there, with a grub that loaded a kernel from inside the image... we'd have to figure someway out. maybe you'd have to modify the image to keep the kernel param on, or just touch a file or static config.
[15:26] <niluje> and we'd like to eventually get rid of the initrd (which is currently also used for vm)
[15:26] <niluje> if that's ok to you let's go for the commandline
[15:26] <smoser> in vm instances dmidata shoudl be possible
[15:27] <smoser> because at some point you want to get off maintaining your own images for vms (i'd think)
[15:27] <smoser> and having easy check of dmi platform data that says 'scaleway' is a win there.
[15:27] <smoser> even if its harder to get that same win elsewhere.
[15:28] <niluje> smoser: what about adding three checks ? dmidecode + cmdline + /var/run/scaleway?
[15:29] <niluje> this way we can just update the cmdline for now and/or update the initrd, and we have the flexibility to add dmidecode on our vm later when we'll (hopefully) allow to run custom images/kernels
[15:31] <smoser> that is fine with me.
[15:31] <niluje> awesome :)
[15:31] <niluje> last thing, what's the LP #id you want me to put in the commit message?
[15:31] <niluje> the MR id?
[15:36] <smoser> no. bug number
[15:36] <smoser> i you want to file a bug, you can.
[15:36] <smoser> that'd be nice.
[15:37] <smoser> but if you dont', then thats fine too
[15:38] <niluje> ok
[15:38] <niluje> thanks
[15:38] <niluje> I'll get back to you with improvements and unittests (and not in weeks, this time)
[15:56] <smoser> powersj, i suspect it'd be possible to get a freebsd vm into our jenkins right ?
[15:57] <smoser> in a low tech sort of way... powersj gets a vm image of freebsd or does an install, adds it to a libvirt and adds jenkins to it ?
[15:57] <smoser> then we could run freebsd c-i on that system.
[15:59] <powersj> smoser: yeah
[16:00] <powersj> assuming the jenkins client (java) runs on freebsd
[16:01] <rharper> https://docs.openstack.org/image-guide/freebsd-image.html
[16:02] <smoser> "You can specify up to 1 GB additional RAM to make the installation process run faster."
[16:02] <powersj> nice!
[16:02] <powersj> lol
[16:02] <smoser> any more than that, and its going to fail :)
[16:54] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325760
[16:54] <smoser> i'd appreciate read of that if you had some minutes
[16:56] <blackboxsw> grabbing right now
[16:56] <blackboxsw> powersj: https://jenkins.ubuntu.com/server/job/z_integration_y/1/console looks pretty good for the 2nd part of validation on https://code.launchpad.net/~chad.smith/server-team-ci/+git/server-team-ci/+merge/325745
[16:57] <blackboxsw> smoser: ci didn't like first pass. https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325760
[16:58] <blackboxsw> but reviewing code now
[16:58] <smoser> its running the second now.
[16:58] <powersj> blackboxsw: your merge looks good to me
[16:58] <smoser> i dropped the pylint ignore on platform.dist()
[16:58] <smoser> which is unfortunatlye deprecated (but so was linux_distribution())
[16:58] <smoser> :-(
[16:58] <smoser> https://bugs.python.org/issue1322
[17:02] <rharper> aw bummer
=== sambetts is now known as sambetts|afk
[17:19] <NostawRm> long shot, but I'm trying to find anyway that I can specify some network configurations because I'm not happy with Openstack's IP selection. I just saw that using user data is not an option, so I'm seeing what other options I have
[17:20] <NostawRm> I  know I could just make a script to use but that's less than ideal :/ having it done proper by cloud-init would be better imo
[17:22] <smoser> NostawRm, i'm not sure that you can do that .
[17:22] <smoser> if openstack told you what your ip is, then its quite likely not going to route traffic if you take a different one
[17:23] <NostawRm> I thought not. Surely if I could, I would have found it right now :/
[17:23] <NostawRm> well, its a single interface/port with multiple IPs
[17:23] <NostawRm> and openstack just picks the first one in the list, but if a new one is added that is then the first one in the list, then say on a rebuild, the 'main' IP would change
[17:24] <NostawRm> don't know if that explains it well heh
[17:28] <blackboxsw> smoser: minor comment about suse on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325760
=== Hazelesque_ is now known as Hazelesque
[18:52] <powersj> smoser: re: CI pipeline I have something here: https://jenkins.ubuntu.com/server/job/cloud-init-pipeline-ci/
[18:53] <powersj> I would like to keep the run times below 10 mins, so what I am going to do is work on creating parallel stages going and write a short integration test that hits as many areas as possible rather than running all the lxd-based tests.
[18:54] <powersj> Then plan would then be to replace the daily build/unit test with this and replace the per-merge CI tests with this as well, so every merge has coverage here.
[19:08] <smoser> http://doodle.com/poll/tq43i9876sw2vqca
[19:08] <smoser> larsks, ^ rharper powersj dpb1
[19:12] <blackboxsw> https://jenkins.ubuntu.com/server/view/Cloud-init/ all the green balls
[19:12] <blackboxsw> :)
[19:13] <smoser> blackboxsw, thanks for the suse . i will fix.
[19:16] <smoser> blackboxsw, actually..
[19:16] <blackboxsw> yeah was wondering what our story is with suse and templating?
[19:17] <smoser> yeah
[19:17] <smoser> see comment
[19:51] <powersj> smoser: FYI http://paste.ubuntu.com/24866805/
[19:51] <powersj> that just happened
[19:52] <powersj> centos7
[19:53] <smoser> thati sodd
[20:00] <smoser> powersj, i'll get it fixed.
[20:15] <blackboxsw> did I mention I love the cI
[20:16] <blackboxsw> did I mention I love the ci -- continuous integration for the win
[20:19] <rharper> *whew* ;  all but one integration test passing,   the mixed ipv6 mtu and device mtu case (which we have to workaround in ubuntu as well);
[20:20] <rharper> smoser: do you prefer a MR per bug/issue, or would you like a PR with all of the fixes and bugs?
[20:23] <smoser> well, i think one per issue is better.
[20:23] <rharper> ok
[20:23] <smoser> powersj, blackboxsw i can recreate that in a centos 6 container (./tools/run-centos 6)
[20:23] <smoser> but i dont understand it
[20:23] <smoser> why would this not show failure:
[20:24] <smoser> $ python -c 'from cloudinit import util; print(util.is_FreeBSD())'
[20:24] <smoser> False
[20:24] <smoser> or
[20:24] <smoser> $ python -c 'import platform; print(platform.dist())'
[20:24] <smoser> ('centos', '7.3.1611', 'Core')
[20:24] <smoser> http://paste.ubuntu.com/24867035/
[20:27] <smoser> oh. because he mocked platform.platform
[20:43] <smoser> blackboxsw, powersj https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325771
[20:51] <powersj> smoser: there will be tox failures on that
[20:54] <smoser> i think fixed
[20:55] <smoser> powersj, ^
[21:00] <smoser> blackboxsw, ^ a review would be good. or rharper
[21:00] <blackboxsw> smoser comment added
[21:00] <blackboxsw> doesn't look like _check_freebsd_cdrom returns anything
[21:01] <rharper> ?
[21:01] <rharper> true or false
[21:01] <rharper> it's just code motion for mocking
[21:02] <rharper> smoser: why don't you need the PY3 in mock anymore ?
[21:02] <smoser> blackboxsw, you reviewed an older version
[21:02] <smoser> and caught a valid concern
[21:02] <smoser> which is now fixed
[21:02] <smoser> we mock just earlier now, so dont need PY3
[21:03] <smoser> look at updated diff. you see i remove usage of it.
[21:03] <rharper> smoser: gotcha, we're mocking the function, so no need to mock open
[21:04] <smoser> yeah.
[21:11] <blackboxsw> minor assert param reorder. but +1
[21:14] <smoser> blackboxsw, ?
[21:15] <smoser> i'm running a ./tools/run-centos and tox on feature/freebsd-variant
[21:15] <smoser>  https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325760
[21:17] <smoser> bah
[21:17] <smoser> blackboxsw, you're right. it shoudl ahve been reordered
[21:17] <smoser> sorry
[21:17] <smoser> it is pushed now, and i just pushed https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325760 also
[21:18] <blackboxsw> +1
[21:18] <blackboxsw> will watch jenkins
[21:19]  * smoser goes out. i'll check back in in a few hours
[21:19] <rharper> later