0018: Propose Instance object #25
Conversation
|
Reading the proposal I had an intuition:
Instance to me looks a bit too generic. An instance of what? Obviously, it is the concretization of hardware at some specific point in time (provision to provision) I get that, but I am wondering if there is a more specific term. Other than that the proposal looks good to me. |
|
Yeah the name is very much up for options. Installation? Just OS...? |
|
|
||
| Should we do bitflags in Instance.OperatingSystem.IP.flags (Path 2A) or break them out to bool `public` and `management` like currently done in [protos/packet][packet] (Path 2B)? | ||
|
|
||
| I don't particularly like "exploding" flags into fields, but that could just be my once-upon-a-time embedded developer thinking leaking. |
There was a problem hiding this comment.
My personal opinion here is that we should start with fields and only optimize into bitflags if/when it's needed.
| // fork in the road! choose a path | ||
| // path 1Left | ||
| message CustomIPXE { | ||
| string url = 1; |
There was a problem hiding this comment.
Should this also have a field for an ipxe script as well and not just a URL?
| } | ||
| oneof OS { | ||
| CustomIPXE custom_ipxe = 4; | ||
| OperatingSystem operating_system = 5; |
There was a problem hiding this comment.
Should there also be a third option to specify kernel/initrd images directly?
| enum Flags { | ||
| NONE = 0; | ||
| PUBLIC = 1; | ||
| MANAGEMENT = 2; | ||
| }; | ||
| uint32 flags = 5; // bitwise-or of Flags |
There was a problem hiding this comment.
I'm wondering if this should be something that is defined separately and not hardcoded. I can potentially see users wanting to have more granular network segregation than just public and management networks.
| } | ||
| repeated IP ips = 6; | ||
|
|
||
| string userdata = 7; |
There was a problem hiding this comment.
Forgive my lack of understanding here, but is userdata here meant as a way to provide automated injection into Hegel for it later to be consumed by the instance at boot time?
If so, it might also be good to provide an extra abstraction around userdata so that we could eventually provide higher levels of granularity around permissions to access userdata compared to standard instance data. This is something that has consistently been a challenge across all cloud providers (and other api-driven infastructure, such as vSphere), we have the potential to avoid perpetuating it here.
| string crypted_root_password = 8; | ||
|
|
||
| repeated string tags = 9; | ||
| repeated string ssh_keys = 10; |
There was a problem hiding this comment.
Is there any need to worry about potential conflicts between this field and userdata?
| #### Extensions? | ||
|
|
||
| I can already think of a couple of extensions that we'd need for EquinixMetal: | ||
| * Licensing fields for some OSes |
There was a problem hiding this comment.
Could this be handled through composition?
message OperatingSystem {
string distro = 1;
string version = 2;
string tag = 3; // snapshot? revision? ...?
}
message LicensedOperatingSystem {
OperatingSystem os = 1;
string license = 2;
}| string version = 2; | ||
| string tag = 3; // snapshot? revision? ...? |
There was a problem hiding this comment.
Are these two fields going to be sufficient to enumerate the different types of versioning practices for various OSes? Or will it lead to trying to shoehorn everything into the model we provide?
| * Spot Market related fields | ||
| * IQN, used for block storage | ||
|
|
||
| And the 2 ways I can think of to handle the extensions: |
There was a problem hiding this comment.
I think it really depends on how the extensions are expected to be used/consumed.
If the goal is to only enable the ability to specify extra configuration for external (not a part of Tinkerbell) services, then I think the approaches mentioned below make sense. However, if we expect internal services to make use of the various extensions, then I think it might be better to encode them in through protobuf composition or make use of compatible types to provide a hacky approach to inheritance.
| ## Content | ||
|
|
||
| This proposal is about adding a storage concept for data that is not as permanent as Hardware, and that can persist across multiple Workloads. | ||
| This would mimic the EquinixMetal life-cycle of a machine, provisioned and thus occupied until the customer deletes and the machine is deprovisioned. |
There was a problem hiding this comment.
I think having more information about the expected lifecycle of the proposed "instance" type would help.
A few questions that I have:
- Is the Instance expected to be user-created, created through a workflow, or other automated means?
- How is the Instance linked to underlying hardware?
- How is appropriate hardware chosen for an instance?
## Description Change the handling the /metadata endpoint so the data returned is of the same content as the /meta-data EC2 style endpoint. ## Why is this needed Hegel is meant as a replacement for what is used in EM Production today (Kant). The response from /metadata and /meta-data Kant returns is the same content. Its also arguably confusing to have 2 similarly named endpoints return very different data. This confusion is in part due to not having an Instance object yet expecting instance data _somewhere_. This should be cleaned up/made to make sense by tinkerbell/proposals#25. ## How Has This Been Tested? Unit tests still pass. ## How are existing users impacted? What migration steps/scripts do we need? This is a bc-break. If any users were using the /metadata endpoint in its default configuration their workflow would be broken. I'd like to wait and see if thats the case before prematurely having any workarounds.
Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
|
This one too @gianarb, thanks. |
Description
Propose an Instance object (name up for consideration)
View rendered proposals/0018/README.md