[14:28] <smoser> Odd_Bloke, hm..
[14:28] <smoser> about to merge this, but one question
[14:28] <smoser> is data from dmi == data in shareconfig ?
[14:28] <smoser> or will an updated instance think that it is now a new instance because it loks in a different place
[14:30] <Odd_Bloke> Oh, that's an interesting point.
[14:32] <Odd_Bloke> smoser: Just bringing up a fresh instance to test. :)
[14:37] <Odd_Bloke> smoser: Oh, bah, no they aren't the same ID.
[14:39] <Odd_Bloke> Blah, and that means we can't even get away with it in xenial, because older instances might be upgraded to xenial and get the new code.
[14:40] <smoser> well, we can handle it in package upgrade
[14:41] <Odd_Bloke> Ah, true.
[14:41] <Odd_Bloke> It would be good to not have to maintain the old code paths in trunk.
[14:42] <smoser> ideally we do something that doesn't require package upgrade
[14:43] <smoser> erl... doesn't require package upgrade to fix the problem for us.
[14:43] <smoser> ie, best if e can somehow dtrt.
[14:44] <smoser> i absolutely want to be able to ditch the old code though.
[17:28] <Odd_Bloke> smoser: I don't know that we can do anything without keeping the old code.
[17:30] <Odd_Bloke> smoser: Do you have a specific case where package upgrade won't work?
[17:30] <smoser> just as upstream
[17:30] <smoser> would be better for upstream to handle it
[17:36] <smoser> Odd_Bloke, but if you can do a good job in packaging, i think i'm ok to take it.
[20:56] <cbolt> does runcmd happen before scripts-user?