[02:58] Hey guys, listen, when I enable "virtio-scsi, in my OpenStack environment, it speeds up a lot my storage! However, it breaks cloud-init! Both SWAP and Ephemeral are failing. Maybe that's because the devices changed from /dev/vdX to /dev/sdX ? [02:58] How to make cloud-init work with virtio-scsi? [03:21] I mean, by default, without tricks via "user_data"... === shardy is now known as shardy_afk === shardy_afk is now known as shardy [14:20] tmartins, need more information on what is failing [14:20] file a bug? collect the info requested there. [14:44] Right, I'll fill a bug report with the logs! =) [15:09] tmartins, please just give me apointer here. [15:09] (also) [15:40] Sure! [16:10] rharper: \o/ xkvm is awesome [16:10] powersj: thank smoser too [16:11] smoser: thanks for suggesting this as well [16:12] rharper: thoughts on how to include it with cloud-init? [16:12] i think copy to tools/ [16:12] put it in tools [16:12] k [16:18] powersj, http://paste.ubuntu.com/25126584/ [16:18] that is what i recall having done for mount image callback. [16:19] that partuclarly lets me run mount-image-callback lxd: with sudo without a password [16:21] smoser: what is the "lxd:" part do? My ignorance of mount-image-callback is showing... [16:21] lxd: means lxd do the same sorts of things to a container that you'd do to an image [16:21] so i can [16:22] $ lxc init ubuntu-daily:xenial xsmtest [16:22] $ sudo mount-image-callback xsmtest mchroot [16:22] er... [16:22] $ sudo mount-image-callback lxd:xsmtest mchroot [16:25] ok so for my use-case I need to specify a similar command string for the Cmnd_Alias in sudoers [16:32] maybe something like [16:32] http://paste.ubuntu.com/25126653/ [16:32] and remember that files in /etc/sudoers.d have to be 440 (or more restricive) or they're ignored. [16:33] ok [16:33] thanks [16:33] basically that is going to protect you from accidental mis-use [16:33] yeah [16:33] as if you wanted to exploit it, you could just put any file in /citest-images/ [16:34] and 'mchroot' is just the equivalent (available in newer 'mount-image-callback') of [16:34] chroot _MOUNTPOINT_ [16:42] smoser: I just push a rebase of curtin-centos on master [16:42] ok [16:58] packages are pita [17:26] rharper, just noticed... i tried fedora25 lxd instance. [17:27] our copr repo builds python2 there [17:27] and there is no python2 in their install.. ie, we should be python3 there. [17:37] yeah, we've not been testing the fedora path =( [17:38] I suspect we'll have more "fun" with systemd-units under fedora as well [17:41] smoser: thanks for the sudoers file. no more typing password all day long [17:41] smoser: did you have any suggestions on http://paste.ubuntu.com/25126921/ [17:47] wow [17:47] so .. the rpm version available in fedora25 for cloud-init from the daily is [17:47] 0.7.9+211.gd1e8eb7-1.fc25 [17:47] that .fc25 i think is what handles something i'd wonderd about. [17:48] if you have build-time logic then you'd get 2 different binary rpms for centos6 and centos7 [17:48] (and i think we do) [17:49] whats interesting there is that means (i *think*) that a upgrade from centos6 to centos7 will get 100% new packages. [17:49] oh.. or only stuff that got re-built. maybe they can binary copy also [17:49] i geuss that ends up being the same as ubuntu [17:49] yeah [18:35] rharper, around ? [18:43] rharper: smoser powersj: so createing a tmpdir and running a copy of dhclient from there on both ubuntu and centos results in success. No apparmor/SELinux conifinement constraints hit us on either ubuntu or centos 6. Checking cent7 on aws now [18:44] cent6 images in aws have selinux enforcing (as opposed to our lxc environments when don't) [18:44] *which don't [18:49] you'd hope they do :) [18:49] lxc is not enforcing just because it doesn't play well with the container [18:55] ok rebasing this branch against master and fixing up unit tests. [18:56] smoser: actually I'll wait to rebase until you land this one https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327534 [18:57] since those unit test changes will have merge conflicts w/ my branch [18:57] this month will be interesting to see what my aws bill is [18:58] blackboxsw, you're welcome to grab that to trunk yourself [18:58] if it makes it easier for you [18:59] assertFalse might be valid in python2.6. [19:00] it's easy enough as you are adding unit tests. yeah just wanted to closeout on my minor review comments there. please do land it with whatever review comments you accept. it'll make my branch easier(smaller) when I put mine up. [19:00] smoser ^ [19:09] smoser: back [19:19] rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327739 [19:21] rharper, ^ you can see your commit (that i cherry-picked) and then some cleanups of mine. [19:22] yes [19:22] one question, we can already rely on 'prefix' even if we get the odd 'netmask: ffffffffffffffffffff' ? [19:22] smoser: ^ [19:23] that's my one question in dropping the 'netmask' in subnet part and only using prefix [19:23] have to test. where would we get that ? [19:23] commit d00da2d5b0d45 [19:23] says [19:23] I think I saw that in the json network from rackspace [19:23] * prefix will always include an integer value that is the [19:23] network_prefix for the address. [19:23] * netmask will be present only if the address is ipv4, and its [19:23] value will always correlate to the 'prefix'. [19:25] in curtin, network_alias, network_mtu, and vlan_network_ipv6 all use v6 with netmask set to ff* [19:25] so you can net-convert those and make sure it doesn't blow up [19:25] * rharper tries out the change locally [19:26] i think it should [19:26] because we do [19:26] in _normalize_net_keys [19:26] we use mask_to_net_prefix [19:26] although 'ffffffffffffff' that is just wrong [19:26] no : ? [19:27] it's /64 [19:27] and it's a thing [19:27] without a : ? [19:27] oh, no [19:27] sorry [19:27] i was just being lazy [19:27] then it should be fine. [19:30] rharper, [19:30] $ python3 -c 'import sys; from cloudinit.net.network_state import mask_to_net_prefix; print(mask_to_net_prefix(sys.argv[1]))' "ffff:ffff:ffff:ffff::" [19:30] 64 [19:36] smoser: looks good [19:39] rharper, IPV6ADDR=2001:DB8::10/64 [19:39] that is ok ? [19:39] it seems that it must work for SECONDARIES [19:39] AFAIK, yes [19:39] it's passed to iproute2 (/sbin/ip) [19:39] which takes prefix in v6 format [19:40] k [19:40] rharper, so. .. on your templatifying of the systmed unit files... [19:41] none of those *should* be necessary [19:41] go on [19:41] those changes were taken from the upstream cloud-init in el today [19:41] After and Before don't do anything [19:41] oh. [19:41] right [19:42] larsks, just wanted to take them out [19:42] there is something else besides ordering [19:42] I think 'network' versus 'networking' [19:42] is at lease one change [19:42] there is no 'networking' service in el [19:42] only 'network' [19:42] but I can put 'After the-third-sunday-of-the-new-millenium.service' [19:42] and it doesnt do anything unless that service will be run [19:43] same is true of networking.service and network.service [19:43] the one that is present will get run Before and others ignored [19:43] you're suggestion thens is to include all of the names it might be [19:43] thats what we have right now [19:44] well, no [19:44] because trunk doesn't work under el7 [19:44] it might be the default deps then [19:44] but I know for sure, the unit file in trunk doesn't run networking early enough for vmtest to pass [19:45] so I pulled in the changes from downstream el cloud-init [19:45] I'm fine with tweaking it [19:45] but I do know for sure it won't work as it is [19:45] and then you are [19:45] dropping [19:45] DefaultDependencies=no [19:45] yes [19:45] for el [19:45] I am too distracted to follow right now, but note that the defaultdeps stuff was causing us all sorts of issues. Yeah. [19:45] on centos [19:45] did you ahve a reason for that ? [19:46] we almost certainly need that in order to accomplish some of the things that -local does [19:46] smoser: we kept hitting dependency loops without dropping that. [19:46] I dropped it due to el having the change, they're network service and other things like dbus are ordered differently [19:46] larsks: ack, I saw that as well [19:46] we'd have to drive in dbus early changes which aren't present [19:46] and not just on core stuff: cloud-init got into a fight with os-collect-config, also, which only crops up on openstack deployments. [19:47] that said, I;ve not tested el7 on GCE which does DNS resolution early [19:47] but they likely don't have both a libnss and systemd-resolved combo like we did on Xenial [19:48] we're ultimately going to need it. [19:48] other wise you run really late [19:50] well, we're not running late now [19:51] you're running after all local mounts are done [19:51] which is too late to accomplish some things like re-formatting an ephemeral disk [19:51] we know that DefaultDeps in el are after local mounts? [19:51] or is that ubuntu systemd [19:51] yes [19:52] Service units, unless they set DefaultDependencies=no, automatically get a dependency on sysinit.target [19:53] i'm fine to deal with it later. [19:54] bleh [19:54] * rharper feels unit rage [19:55] rharper, in that commit you also mixed in redhat.spec file changes [19:55] which i'm kind of confused on [19:56] it was needed due to how unit files were copied [19:56] a.) you have a comment that indicates .service files are installed by setup but .target are not [19:56] but i dont see how that is possible [19:56] b.) i dont understand how it could have worked before. [19:57] it copied systemd/* [19:57] we have template files in there now [19:57] so only copy in the *rendered* unit files [19:57] setup.py installs the .target and the rendered .service files [19:57] we have .target and .service files; the spec file copied *everything*, and setup.py also copied in some [19:58] for install [19:58] it does now [19:58] "now" ? [19:58] I added render_systemd_unit [19:58] to setup.py [19:58] right. [19:58] but it does that for both .service and .target [19:58] but your comment in the spec file acts as if it does that only for .service [19:59] we only pass in the files that are templated [19:59] all .service files are templated [19:59] but the .target files still need to be installed [19:59] so we manually copy this in [19:59] those in [19:59] they get installed the same way that .service files do [19:59] in your branch [19:59] the setup.py install [19:59] will install them [19:59] how? [19:59] where in the setup.py does it specify .target files ? [20:00] oh, maybe it does work [20:00] we pass back non template files as-is; [20:01] right [20:01] I suspect one changes was made after the spec change [20:01] why '$' ? [20:01] err.. \$ [20:01] pre jinja [20:01] there's a commit later that should ahve been squashed [20:01] which drops the \$ [20:02] I wrote these before we switched to jinja in the specfile [20:06] rharper, so i think the only change we need to spec file then [20:06] is to drop the 'cp -p systemd/*' line [20:06] yes [20:06] that looks right [20:06] and I'll drop the \$ commit in the series since you will skip that here [20:07] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327739 is merged [20:07] i have to go afk. [20:09] rharper, so on top of yours [20:09] i had http://paste.ubuntu.com/25127837/ [20:10] can you see if that works ? that'd be my next MP. your 'Templatize systemd service files' [20:10] plus http://paste.ubuntu.com/25127837/ [20:16] checking that now with centos7. centos6 didn't have any of the systemd files and i worried [20:16] k [20:16] but i guess that is by design [20:17] right, no systemd in el6 [20:17] upstart files only [20:21] rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327743 [20:22] is that supposed to be both the sysconfig prefix change *and* the template change ? [20:22] the diff on the MP looks like it has two commits [20:23] it does [20:23] yours, then my cleanup [20:23] my cleanup dropped all the $ changes from the .spec.in [20:24] mine shows 3 commits [20:24] and removed the mkdir and copying of .target [20:24] reload [20:24] k [20:24] huh [20:24] i'd not pushed trunk [20:24] what's up with the delay ? [20:24] ah [20:24] o [20:24] hrm , two commits, diff still wrong [20:24] launchpad doesnt render the moves well [20:24] renames [20:24] :-( [20:24] bah [20:25] I'll look at the commit [20:25] yeah, and please write a commit message too [20:25] if you ACK that then i'll pull when i get back [20:25] ok [20:25] and we'll be in like 3/12 :) [20:25] 3/11 (we get to drop one) [20:48] smoser, here is the bug report! https://bugs.launchpad.net/cloud-init/+bug/1705346 [20:48] Ubuntu bug 1705346 in cloud-init "Cloud-Init fails to deal with SWAP and Ephemeral if virtio-scsi is enabled" [Undecided,New] [21:55] rharper, next one .. [21:55] Fix sysconfig rendering of virtual interfaces with network configurations [21:55] needs unit tests [21:55] * rharper accepts this [21:55] I believe they're added near the end [21:55] 095f7585b57d35e9de68ee99c77a500ad644c293 [21:57] smoser: what would you like? I can see about adding a separate singular test ; try to avoid conflicting with the one coming at the end [21:58] hm.. [21:59] well, as a standaone commit we shoudl be able to get some unit test that shows the changes. [21:59] k [21:59] I'll do that [22:04] rharper, in 97a25a75143a [22:04] use is is_ipv6_addr [22:04] and a test would be good. [22:05] i can work on getting some of those together too [22:05] ok, I'm doing the virtual interface one now [22:05] if you want to tackle 97a [22:06] so far, no regression, I've rebuilt the curtin-centos cloud-init package and re-ran the curtin branch (with your passthrough reviews applied) and all tests still passing [22:06] will repeat tonight with a rebase from trunk [22:25] smoser: do you want a paste with the unittest for 095 ? [22:27] http://paste.ubuntu.com/25128675/ [22:27] that should do; and won't collide with the test in the last commit [22:27] I'm going to step out for a bit, will check back later [23:24] smoser, I've updated the bug report with the config drive! ;-)