[13:57] <smoser> hm... https://jenkins.ubuntu.com/server/job/cloud-init-integration-a/91/
[14:38] <smoser> rharper,
[14:39] <smoser> http://paste.ubuntu.com/25133128/
[14:39] <rharper> yes
[14:40] <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:41] <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:42] <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:43] <rharper> sure
[14:43] <smoser> oh.
[14:43] <smoser> ididt see .. you did that pate yesterday?
[14:43] <smoser> thats great.
[14:44] <smoser> your paste there doesnt have a 'route' on the subnets... so it doesnt excercise that code that you fixed
[14:45] <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:46] <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:47] <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:50] <smoser> http://paste.ubuntu.com/25133177/ ?
[14:50] <smoser> (that doesnt seem to work)
[14:51] <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:52] <rharper> config: [{type: route, dest: X, gateway: y}]
[14:52] <rharper> you want the former
[14:52] <rharper> drop lines 29 to end
[15:13] <smoser> larsks, i have a question you probalby know the answer too
[15:14] <smoser> our rpms build and get a .fc25 or .el6
[15:15] <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:20] <larsks> smoser: packages are rebuilt for every release, yes.
[15:21] <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:24] <larsks> #fedora confirms that during an *upgrade* packages won't be replaced if there isn't an actual change in the package version.
[15:30] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:49] <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:50] <smoser>  TestSysConfigRendering
[15:50] <rharper> y
[15:50] <smoser> er... how is TestSysconfigRoundTrip different from TestSysConfigRendering
[15:52] <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:54] <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:55] <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
[16:02] <rharper> y
[17:36] <smoser> rharper, take alook at https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327821
[18:33] <rharper> smoser: approved
[18:35] <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:46] <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:50] <smoser> rharper, awesome. one of the tests i added exposed the bug you fixed in the next commit
[18:50] <rharper> \o/
[18:53] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327828
[19:01] <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:02] <powersj> http://paste.ubuntu.com/25134551/
[19:04] <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:08] <smoser> i think there is a bug there.
[19:08] <smoser> rharper, http://paste.ubuntu.com/25134578/
[19:09] <rharper> I think it's a deficiency
[19:09] <rharper> eni has control per stanza
[19:09] <rharper> sysconfig does not
[19:10] <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:11] <rharper> somethings not right; I had that fixed
[19:12] <rharper> I think it's type manual
[19:12] <rharper> it should be type: static, control: manual
[19:13] <rharper> there we go
[19:13] <rharper> that works
[19:14] <smoser> rharper, http://paste.ubuntu.com/25134607/ ?
[19:14] <rharper> yes
[19:14] <smoser> that renders
[19:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:25] <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:26] <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:28] <smoser> it shoudl be control: manual
[19:28] <smoser> as it can be type: dhcp
[19:28] <smoser> control: manual
[19:29] <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:39] <smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327828
[19:40] <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:41] <rharper> ok, looking
[19:41] <rharper> then I'll rebase my branch again
[19:44] <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:45] <rharper> no, something else; me fixes rebase
[19:46] <rharper> looks like indentation sytle changes
[19:47] <smoser> sysconfig: enable mtu set per subnet right ?
[19:48] <rharper> no, the last MAC vs HW_ADDR
[19:56] <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
[20:08] <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:09] <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:10] <smoser> or click on the individual commits
[20:11] <smoser> i have the next one ready too
[20:11] <smoser>  sysconfig: enable mtu set per subnet
[20:11] <smoser> with tests added
[20:12] <rharper> ok
[20:13] <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:14] <rharper> that's a one-liner if 'address' in subnet and ':' in subnet['address']
[20:16] <smoser> currently sysconfig raises a valueerror
[20:16] <smoser> ValueError: No config network address keys [address] found in {'control': 'manual', 'type': 'static'}
[20:18] <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:19] <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:20] <rharper> yeah
[20:20] <rharper> oh, it was ordering iface stanzas
[20:21] <rharper> hrm, so how do we get an iface $name manual ?
[20:21] <rharper> and no ip configuration ?
[20:23] <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:24] <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:30] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327836
[20:32] <smoser> rharper, so. ^ has 2 more of them.
[20:32] <smoser> which leaves us just aaa7101790d5
[20:33] <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:35] <smoser> ah. well, the answer is that we dont care.
[20:36] <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:37] <smoser> coding style is checked via running
[20:37] <smoser>  tox -e flake8
[20:38] <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:39] <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:40] <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:41] <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:42] <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:45] <smoser> once https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-ci/69/ finishes i'll pull
[20:46] <rharper> k
[20:46] <rharper> just about done with rebase of the last few
[20:46] <rharper> ok, pushed
[20:50] <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:51] <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:53] <rharper> you merged both mtu-per-subnet and ipv6 def-route ?
[21:02] <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:03] <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:04] <rharper> no more rebase needed then
[21:10] <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:12] <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:13] <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:14] <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] <smoser> but oh well.
[21:15] <rharper> but only once we release (and sru) an curtin with passthrough enabled
[21:16] <rharper> we should see about getting those scheduled/started soon given our timeline and desire for MAAS testing
[21:20] <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:21] <blackboxsw> good deal smoser, thanks
[21:21] <blackboxsw> I'll get out from under this aws ipv6 in short order I hope
[21:23] <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:25] <smoser> right
[21:43] <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:45] <rharper> later
[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 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:12] <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.