| === vrubiolo1 is now known as vrubiolo | ||
| 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:40 |
| rharper | blackboxsw: excellent, I'll review | 17:45 |
| blackboxsw | ok addressed thx rharper | 19:18 |
| 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:00 |
| 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:01 |
| 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:04 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| fredlef1 | The impact of falling back to DataSourceNone is that cloud-init concludes it's dealing with a new instance | 22:11 |
| rharper | Yes, it does do that; | 22:12 |
| 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:13 |
| rharper | fredlef1: except if you're capturing and deploying again | 22:14 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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) | 22:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!