=== vrubiolo1 is now known as vrubiolo
[17:40] <blackboxsw> rharper: I think https://github.com/canonical/cloud-init/pull/232 is good to go
[17:40] <blackboxsw> I believe I addressed all comments
[17:45] <rharper> blackboxsw: excellent, I'll review
[19:18] <blackboxsw> ok addressed thx rharper
[22:00] <fredlef1> rharper: What purpose does DataSourceNone serve?
[22:00] <rharper> it's a fallback datasource that allows cloud-init to run without a datasource
[22:01] <rharper> basically if we could not find any datasource at all, try to do something reasonable (we still generate host keys, and other bits);
[22:04] <rharper> we've recently had a discussion that DataSourceNone really ought to look more like NoCloud ;  https://github.com/canonical/cloud-init/pull/203
[22:04] <fredlef1> Is there any scenario where it would leave an instance in a state where it is accessible to the user? Other than cloud-init running in a non-cloud scenatio
[22:07] <rharper> fredlef1: I think it depends on the image;  if there is included cloud-config , None will return user-data/metadata from the datasource;
[22:08] <rharper> a default user is normally created, host keys are generated;   however, without a password or an imported ssh key, I don't see how a user would have access
[22:08] <rharper> this only happens if cloud-init detected a potential datasource, otherwise, cloud-init won't run at all
[22:09] <rharper> so, in your IMDS is down scenario; we'd detect ec2 via host UUID value, and then when we called _get_data() if that failed, we'd fall through to None, which would continue to run modules/final but a stock image won't include any user-data/metadata nor fetch it from remote URLs, etc
[22:10] <fredlef1> Yes. I have seen that.  My latest builds I have been testing for our AMIs have the None datasource removed from the list of candidate datasources for that reason.
[22:11] <fredlef1> The impact of falling back to DataSourceNone is that cloud-init concludes it's dealing with a new instance
[22:12] <rharper> Yes, it does do that;
[22:13] <fredlef1> DataSourceNone doesn't seem like something we should ever use after first boot
[22:13] <rharper> the general idea of falling back to the previous DS is new;
[22:14] <rharper> fredlef1: except if you're capturing and deploying again
[22:16] <rharper> if we end up falling back to the previous ds if the current ds is not viable;  None is not very useful.
[22:16] <fredlef1> rharper: Yes, I agree. But, on the other side, the list of things that can go awfully wrong if you capture/snapshot and re-deploy without properly cleaning up various states on your instance is very long already.
[22:16] <rharper> it's harder now than it used to be;  but none-the-less, it is very common workflow
[22:18] <fredlef1> I agree. We see it everyday (both the right way and the wrong way).  Clearing up cloud-init states is what people do wrong the least often (does that sentence even make any sense?).
[22:18] <fredlef1> I'll think about it some more and update my PR later this week.
[22:19] <fredlef1> There is a way to get this right
[22:19] <rharper> =)
[22:19] <rharper> fredlef1: I'm happy with the direction you're going here
[22:20] <rharper> I've asked the vmware folks to look at your changes as well, as they have a similar scenario where they need to restore the previous instance-id on subsequent boots even if they don't have any new data (which is different than IMDS being down)