| === shardy is now known as shardy_mtg | ||
| === shardy_mtg is now known as shardy | ||
| smoser | hm... https://jenkins.ubuntu.com/server/job/cloud-init-integration-a/91/ | 13:57 |
|---|---|---|
| smoser | rharper, | 14:38 |
| smoser | http://paste.ubuntu.com/25133128/ | 14:39 |
| rharper | yes | 14:39 |
| smoser | i'm going to put together a "simple" bond, vlan, and bridge config | 14:40 |
| smoser | and add tests for sysconfig rendering of them. | 14:40 |
| smoser | that bond shows stacktrace in current trunk and seems to render sanely with your | 14:40 |
| smoser | "Fix sysconfig rendering of virtual interfaces"... | 14:40 |
| rharper | yes | 14:41 |
| rharper | the last commit in my branch fixes an issue when you have a mac_address property on the bond, vlan or bridge | 14:41 |
| rharper | but that's easy enough to fix up when we merge that commit | 14:41 |
| rharper | I sent you a unittest | 14:41 |
| rharper | that covered bond and vlan | 14:42 |
| rharper | but not exhaustively | 14:42 |
| smoser | ah. i see yeah, you render the 'all' | 14:42 |
| rharper | we could add a bridge device into that config for the oen I posted, and it would cover all 3 virtual types | 14:42 |
| rharper | that's in the final commit | 14:42 |
| rharper | but something simpler for the current patch, <rharper> http://paste.ubuntu.com/25128675/ | 14:42 |
| rharper | is there | 14:42 |
| smoser | which is just a combination.. i think having individual ones would be good | 14:42 |
| rharper | sure | 14:43 |
| smoser | oh. | 14:43 |
| smoser | ididt see .. you did that pate yesterday? | 14:43 |
| smoser | thats great. | 14:43 |
| smoser | your paste there doesnt have a 'route' on the subnets... so it doesnt excercise that code that you fixed | 14:44 |
| smoser | i'm sorry i missed your patch | 14:45 |
| rharper | there are two paths | 14:45 |
| rharper | we can add one with subnets (single subnet) and one with subnets with routes | 14:45 |
| rharper | cls._render_subnets(iface_cfg, iface_subnets) is for the subnets, and cls._render_subnet_routes(iface_cfg, route_cfg, iface_subnets) for any 'routes' keys under a subnet | 14:46 |
| smoser | hm.. | 14:46 |
| rharper | we can just add a 'routes' list if you want to hit that path as well | 14:47 |
| smoser | so 'routes' can be a sibling of subnets ? | 14:47 |
| rharper | so, we have static routes (top level type) | 14:47 |
| rharper | and then we can associate a list of routes for each subnet | 14:47 |
| rharper | which is what 'routes' is, which models network_config.json from openstack | 14:47 |
| smoser | http://paste.ubuntu.com/25133177/ ? | 14:50 |
| smoser | (that doesnt seem to work) | 14:50 |
| rharper | sorry, type: routes top level | 14:51 |
| rharper | or key under a subnet | 14:51 |
| rharper | subnets: [{type: static, routes: [list of routes]}] | 14:51 |
| rharper | config: [{type: route, dest: X, gateway: y}] | 14:52 |
| rharper | you want the former | 14:52 |
| rharper | drop lines 29 to end | 14:52 |
| smoser | larsks, i have a question you probalby know the answer too | 15:13 |
| smoser | our rpms build and get a .fc25 or .el6 | 15:14 |
| smoser | on fedora do they re-build every time ? | 15:15 |
| smoser | every release... ie, if i upgrade do i get 100% new packages ? | 15:15 |
| larsks | smoser: packages are rebuilt for every release, yes. | 15:20 |
| larsks | But if there's no change in version/release, then for an *upgrade* I guess you might not get a new package. | 15:21 |
| larsks | Just a sec, let me check. | 15:21 |
| larsks | #fedora confirms that during an *upgrade* packages won't be replaced if there isn't an actual change in the package version. | 15:24 |
| larsks | But honestly, #fedora seems uncertain. Shouldn't matter in either case, though: if the package version and release are the same there should not be a difference between the two, regardless of the .dist tag. | 15:30 |
| smoser | larsks, hm. | 15:32 |
| smoser | but how does it know that they would differ or not ? | 15:32 |
| larsks | I mean, that's what the package version and release are for. | 15:32 |
| smoser | as they could differ in build-time logic | 15:32 |
| smoser | ie, our cloud-init truunk will build an rpm on copr for fc25 and el6 | 15:32 |
| smoser | and they'll differ | 15:33 |
| larsks | If you think your build environment is generating different code, you increase the package release. | 15:33 |
| smoser | but you do that by design... you look at rpm build macros and such | 15:33 |
| larsks | You'll often see exactly this in the changelog for packages: "Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild" | 15:33 |
| larsks | For example. | 15:33 |
| larsks | In that case, you increment the release on the rpm even though you're not making any changes to the rpm content itself. | 15:33 |
| smoser | ok.. so heres an explicit example. | 15:34 |
| smoser | we build the trunk rpm in copr. | 15:34 |
| smoser | it spits out a .el6 rpm and a .el7 rpm | 15:34 |
| smoser | the .el6 one has upstart files and adds upstart jobs on installation | 15:34 |
| smoser | the .el7 one has systemd and sets up systemd on installation | 15:35 |
| smoser | but they have the same version | 15:35 |
| smoser | i'm wondering how we would handle a user upgrading from 6 to 7 | 15:35 |
| smoser | it seems they'd *have* to get the .el7 version | 15:35 |
| smoser | but if they did that'd mean that an upgrade of 6 to 7 is 100% of packages even if the package *didn't* change. | 15:36 |
| larsks | I will say that for EL, major version upgrades aren't something in which I have a lot of confidence. | 15:36 |
| * smoser tweets ;) | 15:36 | |
| larsks | Well, for example, there is no "live" upgrade from 6->7. | 15:36 |
| smoser | larsks, thats fine. its quite likely i'm just thinking too much. | 15:36 |
| larsks | Whereas fedora has e.g. the "fedup" tool for that. | 15:37 |
| larsks | For the most part, we treat el6 and el7 as completely separate entities. | 15:37 |
| smoser | i just assumed one could upgrade 6 to 7 or 5 to 6 to 7 | 15:37 |
| smoser | that is helpful, thank you. | 15:37 |
| larsks | I'll see if I can set up a test just for kicks sometime this week. Not next week, though: I'll be on vacation :) | 15:38 |
| larsks | smoser: hey, take a look at https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool | 15:49 |
| larsks | "Warning: use of this tool is currently BROKEN as several system-critical packages are of a higher version number in CentOS 6.7 than they are in CentOS 7 so those do not get upgraded correctly." | 15:49 |
| larsks | :) | 15:49 |
| smoser | rharper, so on your branch | 15:49 |
| smoser | TestSysConfigRendering | 15:50 |
| rharper | y | 15:50 |
| smoser | er... how is TestSysconfigRoundTrip different from TestSysConfigRendering | 15:50 |
| rharper | it differs in input and how it's called; I think the latter used an eni file as input to convert and then render a sysconfig | 15:52 |
| smoser | ok. we lost the meaning of RoundTrip along the way | 15:54 |
| rharper | you're right | 15:54 |
| smoser | the 'round trip' of eni's test was that it started with an ENI, read that, generated a network config, and then rendered that | 15:54 |
| rharper | it's just doing it one=way | 15:54 |
| smoser | yeah | 15:54 |
| rharper | I suspect we can just remove the RoundTrip part for now | 15:54 |
| smoser | yeah. and just merge it with the previous class. | 15:55 |
| rharper | I don't think we necessarity need to attempt to parse sysconfig dir back into network config | 15:55 |
| smoser | i'll adjust stuff. | 15:55 |
| smoser | right | 15:55 |
| rharper | ok | 15:55 |
| smoser | we dont have a sysconfig parser at the moment | 15:55 |
| smoser | we *did* have a eni parser | 15:55 |
| smoser | and that was why round trip made sense | 15:55 |
| rharper | y | 16:02 |
| smoser | rharper, take alook at https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327821 | 17:36 |
| rharper | smoser: approved | 18:33 |
| smoser | rharper, i'm going to let https://jenkins.ubuntu.com/server/job/cloud-init-ci/62/console finish | 18:35 |
| smoser | before i push | 18:35 |
| rharper | ok | 18:35 |
| smoser | but then i have it ready to go | 18:35 |
| rharper | ok | 18:35 |
| blackboxsw | ok unit testing branch is up https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/327827 (part 1 of aws dhclient support in init-local stage) | 18:46 |
| blackboxsw | now rebasing the 2nd branch on this one | 18:46 |
| smoser | rharper, awesome. one of the tests i added exposed the bug you fixed in the next commit | 18:50 |
| rharper | \o/ | 18:50 |
| smoser | https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327828 | 18:53 |
| powersj | smoser: here is the latest version of kvm backend: https://git.launchpad.net/~powersj/cloud-init/commit/?id=28e84d93c193d7db41f1cba3bf5ff7a0ea364fc7 | 19:01 |
| powersj | still stuck on mount-image-callback trying to run commands via '/bin/sh -c' | 19:01 |
| powersj | http://paste.ubuntu.com/25134551/ | 19:02 |
| smoser | rharper, onboot seems "global" to a device | 19:04 |
| smoser | right ? | 19:04 |
| rharper | per interface file | 19:04 |
| rharper | it's equivalent to auto $iface | 19:04 |
| smoser | right. | 19:04 |
| smoser | i think there is a bug there. | 19:08 |
| smoser | rharper, http://paste.ubuntu.com/25134578/ | 19:08 |
| rharper | I think it's a deficiency | 19:09 |
| rharper | eni has control per stanza | 19:09 |
| rharper | sysconfig does not | 19:09 |
| rharper | hrm, but the bug that is present is that you should see IPADDR0, 1, 2 3 | 19:10 |
| rharper | for each subnet | 19:10 |
| rharper | lemme see if later commits fix that | 19:10 |
| smoser | right. thats the bug i'm pointing at | 19:10 |
| smoser | we only have one addr | 19:10 |
| smoser | and rendering eni for that breaks | 19:10 |
| smoser | is 'type': 'manual' right ? | 19:10 |
| rharper | somethings not right; I had that fixed | 19:11 |
| rharper | I think it's type manual | 19:12 |
| rharper | it should be type: static, control: manual | 19:12 |
| rharper | there we go | 19:13 |
| rharper | that works | 19:13 |
| smoser | rharper, http://paste.ubuntu.com/25134607/ ? | 19:14 |
| rharper | yes | 19:14 |
| smoser | that renders | 19:14 |
| smoser | ONBOOT=yes | 19:15 |
| rharper | right, you have one interface that's control: auto | 19:15 |
| rharper | this is just a deficiency | 19:15 |
| rharper | there's no way to support mixed control | 19:15 |
| smoser | nah. | 19:15 |
| smoser | drop the second address | 19:15 |
| smoser | same thing | 19:15 |
| rharper | no | 19:15 |
| rharper | you get IPADDR1 | 19:15 |
| rharper | and NETMASK1 | 19:15 |
| smoser | http://paste.ubuntu.com/25134616/ | 19:15 |
| smoser | renders | 19:16 |
| smoser | http://paste.ubuntu.com/25134617/ | 19:16 |
| rharper | that's a bug | 19:16 |
| rharper | but different than the first | 19:16 |
| smoser | thats what i was saying :) | 19:16 |
| smoser | that is what i was saying all along | 19:16 |
| rharper | well, you changed | 19:16 |
| smoser | well, if you put 'type: manual' | 19:16 |
| smoser | then it paid attention | 19:16 |
| smoser | so thats why i tried that | 19:17 |
| rharper | not type: manual, control: manual | 19:17 |
| rharper | you have a subnet which is type: static, but you want control: manual (define but dont' up it) | 19:17 |
| rharper | that works fine; | 19:17 |
| rharper | for single subnet, with type: static, control:manual, ONBOOT should be set to what subnet.get('control') == 'manual' is | 19:18 |
| smoser | you can try to come up with something that actually does what you want | 19:18 |
| rharper | which is't not, which is the bug you've found | 19:18 |
| smoser | but i dont thikn you'll find it. | 19:18 |
| rharper | I'm not following | 19:18 |
| smoser | take one of my yaml, and make it into somethign that you think should render ONBOOT=no | 19:18 |
| smoser | and show me. | 19:18 |
| rharper | http://paste.ubuntu.com/25134632/ | 19:18 |
| rharper | that works (no bugs) | 19:19 |
| rharper | but the one you posted (single subnet control: manual: should set ONBOOT=no) and it doesn't (which is new bug) | 19:19 |
| smoser | you get ONBOOT=yes in your example | 19:19 |
| rharper | well, you could argue the first one I posted is bug too; I say it's a known definciency | 19:19 |
| rharper | because one of the two subnets is not control: manual | 19:19 |
| rharper | so youre saying please UP this subnet | 19:19 |
| rharper | but then we say, don't up the next one | 19:20 |
| rharper | and ONBOOT is a toggle | 19:20 |
| smoser | and if you drop the address, so you only have 1 thing... then you *still* get ONBOOT=yes | 19:20 |
| rharper | ie, sysconfig does not support ONBOOT per subnet (like eni does via iface | 19:20 |
| rharper | right | 19:20 |
| rharper | if you specify control: manual, it's missing the check on what control value is | 19:20 |
| rharper | for single subnet, we can get that right | 19:21 |
| rharper | which is the bug I think you originally found | 19:21 |
| rharper | well, we could revert to aliased interface files if we really wanted to support that | 19:21 |
| rharper | eth0 (ONBOOT=yes) eth0:1 (ONBOOT=no) | 19:21 |
| rharper | I suspect, they could extend ONBOOT to ONBOOT{$index} | 19:22 |
| rharper | like they've done else where | 19:22 |
| * rharper looks a scripts to see if that's so | 19:22 | |
| rharper | doesn't look like it on el7 | 19:22 |
| smoser | rharper, you needed this | 19:25 |
| smoser | http://paste.ubuntu.com/25134666/ | 19:25 |
| smoser | your fix didn't change anything. because it was in fact checking subnet['type'] | 19:25 |
| rharper | well, it did something; so I need to find if we've a broken network config | 19:26 |
| rharper | huh, we have type: manual and control: manual | 19:26 |
| rharper | now I need to look at docs | 19:26 |
| smoser | it shoudl be control: manual | 19:28 |
| smoser | as it can be type: dhcp | 19:28 |
| smoser | control: manual | 19:28 |
| rharper | yes, it worked in eni because the it had both type: manual and control: manual | 19:29 |
| rharper | the subnet code ignored the type check, but had the control check like you have | 19:29 |
| rharper | I'll fix up the test-case in curtin to use type: static | 19:29 |
| rharper | but you're fix is still the right one for sysconfig | 19:29 |
| smoser | rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327828 | 19:39 |
| smoser | it doesnt seem to want to update, but | 19:40 |
| smoser | http://paste.ubuntu.com/25134735/ | 19:40 |
| smoser | is the diff against my just-pushed upstream/master | 19:40 |
| rharper | ok, looking | 19:41 |
| rharper | then I'll rebase my branch again | 19:41 |
| rharper | urg | 19:44 |
| rharper | the last commit collides with your extra unittests in test_net | 19:44 |
| rharper | I was hoping to avoid that =( | 19:44 |
| rharper | no, something else; me fixes rebase | 19:45 |
| rharper | looks like indentation sytle changes | 19:46 |
| smoser | sysconfig: enable mtu set per subnet right ? | 19:47 |
| rharper | no, the last MAC vs HW_ADDR | 19:48 |
| rharper | almost done; fixed up the last commit's unittests (the ipv6 /64 change, and the new unittest you had for bonds needs MACADDR instead of HWADDR (which is what the last patch fixes) | 19:56 |
| rharper | ok, force pushed mine after a rebase on master | 19:56 |
| smoser | rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327832 | 20:08 |
| smoser | that one is OK'd by c-i. you ack, i pull | 20:08 |
| rharper | ok, when will launchpad update with the correct diff | 20:09 |
| smoser | i dont know that it wil | 20:09 |
| smoser | just fetch and diff yourself :) | 20:09 |
| smoser | or click on the individual commits | 20:10 |
| smoser | i have the next one ready too | 20:11 |
| smoser | sysconfig: enable mtu set per subnet | 20:11 |
| smoser | with tests added | 20:11 |
| rharper | ok | 20:12 |
| rharper | we've a new bug in the network state: the mtu test in curtin registered a manual subnet with no address (AFAICT that's legit); we have network_state code that checks for 'address' in a subnet and blows up if 'address' key isn't present | 20:13 |
| rharper | the type: manual avoided that path since it was never looked at | 20:13 |
| rharper | http://paste.ubuntu.com/25134871/ | 20:13 |
| rharper | that's a one-liner if 'address' in subnet and ':' in subnet['address'] | 20:14 |
| smoser | currently sysconfig raises a valueerror | 20:16 |
| smoser | ValueError: No config network address keys [address] found in {'control': 'manual', 'type': 'static'} | 20:16 |
| smoser | actually, yeah. bot in my test raise a valueerror | 20:18 |
| smoser | saying its bogus | 20:18 |
| smoser | eni and sysconfig | 20:18 |
| rharper | hrm | 20:18 |
| rharper | let me try curtin.net | 20:18 |
| rharper | it's possible that I can just remove it altogether as I can't see what value it would add to the test-case at this time | 20:19 |
| smoser | http://paste.ubuntu.com/25134888/ | 20:19 |
| rharper | nope, fail in curtin.net as well; well, let's remove it and see what it looks like | 20:19 |
| rharper | yeah | 20:20 |
| rharper | oh, it was ordering iface stanzas | 20:20 |
| rharper | hrm, so how do we get an iface $name manual ? | 20:21 |
| rharper | and no ip configuration ? | 20:21 |
| smoser | rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327832 | 20:23 |
| smoser | is now pushed with my fixes on yours squashed and laucnhpad re-rendered | 20:23 |
| smoser | no diff other than commit message versus what c-i ran at | 20:24 |
| smoser | https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-ci/67/console | 20:24 |
| smoser | so i will pull if you say good. | 20:24 |
| rharper | looks good | 20:24 |
| smoser | and then i have 7 ready and i might just include 8 in with it i just straight cherry-picked it | 20:24 |
| rharper | ok | 20:24 |
| smoser | https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327836 | 20:30 |
| smoser | rharper, so. ^ has 2 more of them. | 20:32 |
| smoser | which leaves us just aaa7101790d5 | 20:32 |
| smoser | Fix style issue with unused exeception variable in DataSourceAzure | 20:33 |
| smoser | which is not related | 20:33 |
| smoser | and i'm not sure what caught it. cause that isnt new | 20:33 |
| smoser | and then | 20:33 |
| rharper | right, it's not, but i wanted make style-check to pass | 20:33 |
| smoser | sysconfig: use MACADDR on bonds/bridges to configure mac_address | 20:33 |
| rharper | it fails here (xenial laptop) | 20:33 |
| smoser | ah. well, the answer is that we dont care. | 20:35 |
| smoser | run tox -e pyflakes | 20:36 |
| rharper | tox passes | 20:36 |
| rharper | am I missing an update? | 20:36 |
| rharper | surely we run a tox flakes under xenial ? | 20:36 |
| rharper | or is it style from $dev_release only ? | 20:36 |
| smoser | coding style is checked via running | 20:37 |
| smoser | tox -e flake8 | 20:37 |
| rharper | what does 'make style-check' run ? | 20:38 |
| smoser | that pins versions of of things to what we accept as current targets | 20:38 |
| smoser | all 'make' targets use whatever things are installed on the system. | 20:38 |
| rharper | is there a reason why it doesn't use tox ? | 20:38 |
| rharper | if that's the one-true-way ? | 20:38 |
| smoser | make is bascially "use what is on the system" | 20:39 |
| smoser | we run 'make test' during the ubuntu builds | 20:39 |
| rharper | at best it passes but most likely wrong; I'll submit a patch later; | 20:39 |
| smoser | so that we verify the test runs against system versions | 20:39 |
| rharper | right, but style-check could certainly do the tox -e flake8 instead | 20:39 |
| smoser | but we do not run style checks | 20:39 |
| rharper | right, which I'm perfectly fine with | 20:39 |
| rharper | I'm just out-dated on how to check style | 20:40 |
| rharper | if we have a partually useless make target, I'd like to fix it up | 20:40 |
| rharper | that's all | 20:40 |
| smoser | because other wise we are held to the least common denominator of styles | 20:40 |
| smoser | its not completely useless. | 20:40 |
| smoser | it passes for me | 20:40 |
| rharper | but it doesn't for me | 20:40 |
| rharper | you're on artful | 20:40 |
| smoser | (as artful has the same (or similar) versions that we *do* care about) | 20:40 |
| smoser | i'm not opposed to removing it... but it doesnt run when you just type 'make' | 20:41 |
| rharper | but I've got something else that does't like it ; anyhow, we can bikeshed in the MP (if I submit it) | 20:41 |
| smoser | and that is by design | 20:41 |
| rharper | that's fine | 20:41 |
| rharper | I don't want to change style-check to run anywher else | 20:41 |
| rharper | jsut make style-check should match what we say is the right style, which is the frozen set in tox -e flake8 | 20:41 |
| smoser | nothing in 'make' depends on the internet | 20:42 |
| smoser | thats why make doesn't run tox | 20:42 |
| rharper | so, sed 's,pep8 $(pyflakes),tox -e flake8' | 20:42 |
| rharper | nothing with plain 'make' depends on the style-check by design | 20:42 |
| rharper | so why not have the style-check actually check the style with the right versions ? | 20:42 |
| * rharper tables it for later | 20:42 | |
| smoser | once https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-ci/69/ finishes i'll pull | 20:45 |
| rharper | k | 20:46 |
| rharper | just about done with rebase of the last few | 20:46 |
| rharper | ok, pushed | 20:46 |
| smoser | ok... https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327836 will pass c-i. i will pull it . that means we just have the newest commit on your branch to grab. | 20:50 |
| smoser | sysconfig: use MACADDR on bonds/bridges to configure mac_address | 20:51 |
| smoser | i'll take your tests that you added there and put them into the ones i added rather than adding the mis-named RoundTrip | 20:51 |
| rharper | you merged both mtu-per-subnet and ipv6 def-route ? | 20:53 |
| smoser | those are both in 7 | 21:02 |
| smoser | which i'll just pull now (bringing in the 2 individual commits that are there) | 21:02 |
| rharper | k | 21:03 |
| smoser | those are now there. | 21:03 |
| smoser | i'm woring on the last commit. | 21:03 |
| smoser | hora! | 21:03 |
| rharper | ack | 21:03 |
| rharper | no more rebase needed then | 21:04 |
| smoser | rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327838 | 21:10 |
| smoser | i just cherry picked yours and then | 21:10 |
| smoser | https://git.launchpad.net/~smoser/cloud-init/commit/?id=64bd6b52a57cc0a7cc3a4c689958d0c7b2f4add6 | 21:10 |
| rharper | ack | 21:12 |
| rharper | approved | 21:12 |
| rharper | thanks! | 21:12 |
| * rharper ends smoser some beer | 21:12 | |
| smoser | yeah, ... | 21:12 |
| smoser | so you dont need this in ubuntu | 21:12 |
| smoser | you just needed it in trunk for the moment | 21:12 |
| smoser | but i think i might just upload to ubuntu too | 21:12 |
| blackboxsw | minor comment on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327838 | 21:13 |
| smoser | blackboxsw, ack. i'll grab that change. | 21:13 |
| rharper | there was at least one commit needed for eni rendering | 21:13 |
| blackboxsw | +1 thx | 21:13 |
| * rharper looks for the list | 21:13 | |
| smoser | i dont like using the .get() twice | 21:14 |
| smoser | (but we were doing it anwyay) | 21:14 |
| smoser | ie, i dont like: | 21:14 |
| smoser | if mydict.get('key'): | 21:14 |
| smoser | x = mydict.get('key') | 21:14 |
| rharper | smoser: https://bugs.launchpad.net/cloud-init/+bug/1701097 ,is needed back to Xenial | 21:14 |
| ubot5 | Ubuntu bug 1701097 in cloud-init (Ubuntu Artful) "eni rendering of ipv6 gateways fails" [Medium,Confirmed] | 21:14 |
| smoser | but oh well. | 21:14 |
| rharper | but only once we release (and sru) an curtin with passthrough enabled | 21:15 |
| rharper | we should see about getting those scheduled/started soon given our timeline and desire for MAAS testing | 21:16 |
| smoser | blackboxsw, https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/327827 looks very clean. thank you | 21:20 |
| smoser | nice commit messages. | 21:20 |
| blackboxsw | good deal smoser, thanks | 21:21 |
| blackboxsw | I'll get out from under this aws ipv6 in short order I hope | 21:21 |
| blackboxsw | smoser: to confirm, how a datasource is determined to run in local mode is by the absense of <DatasourceModule>.datasources sources.DEP_NETWORK in the deps listing? | 21:23 |
| smoser | right | 21:25 |
| smoser | ok. so https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-ci/72/ should finish in 12 minute and then i can pull | 21:43 |
| smoser | i might get to that later tonight. | 21:43 |
| blackboxsw | have a good one smoser | 21:43 |
| rharper | later | 21:45 |
| blackboxsw | smoser: /me is wondering why we'd want to try searching/get_data for DataSourceEc2 in the network stage if we can run DataSourceEc2 in local | 22:04 |
| blackboxsw | smoser: /me is wondering why we'd want to try searching/get_data for DataSourceEc2 in the network stage if we can run DataSourceEc2 in init-local | 22:04 |
| blackboxsw | n/m I think I recall now. The reason attempting the datasource in both init-local and init-network stages would be to keep non-aws Ec2 clones running in the init-network stage so we don't impact their initialization w/ this changeset. | 22:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!