Proposal of adding metal3host operator. #268
Conversation
|
Hi @sailorvii. Thanks for your PR. I'm waiting for a metal3-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
metal3-io-bot
added
needs-ok-to-test
|
/ok-to-test From a quick review: which component will host the new controller? |
metal3-io-bot
added
ok-to-test
I thought it's good to new a repository. This component is based on the bare-metal operator but parallels with capm3. |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
metal3-io-bot
added
the
lifecycle/stale
|
Stale issues close after 30d of inactivity. Reopen the issue with /close |
|
@metal3-io-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/reopen |
|
@Rozzii: Reopened this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@sailorvii is it still something that you would be interested to push forward? |
|
|
||
| The bare-metal host controller and the ironic are not newly developed. | ||
|
|
||
| Metal3Host is a virtual instance. Users could define it to require a bare-metal host. In the definition, the user could specify the image to install, could set the selector to choose a specific bare-metal host, and could define the boot data to automatically start their own applications. |
There was a problem hiding this comment.
I wonder if we actually want to have Metal3 in the names. The difference between Metal3Host and BareMetalHost is not going to be obvious. It's pity that the word "Deployment" has a different meaning...
There was a problem hiding this comment.
I even wonder if we need an object at all. Cannot we only use BareMetalHost's and a new BareMetalDeployment (renamed from Metal3HostDeployment)? BareMetalHosts already have all the deployment information inside of them.
There was a problem hiding this comment.
Thanks for your review.
The difference between metal3Host and baremetalHost is that metal3Host is a virtual host. When the user requires a host, a metal3Host instance will be created. The metal3Host instance has some features the user defines, such as the operating system, the user name/password, the bootup application, etc. After the instance is created, it will choose one suitable baremetalHost.
About the name, I'm not clear which is best.
Thanks & Regards,
Wei
There was a problem hiding this comment.
Another side, if one baremetalHost is down, the metal3Host could choose another baremetalHost. We also could label the baremetalHost, so users could define their requirements such as they need a strong CPU host. Then the metal3Host could choose a host by the label. The metal3Host represents the users' requirement, the baremetal3Host represents the physical machine. I think it's more flexible.
There was a problem hiding this comment.
I see so the host is handled like a workload, like a pod.
There was a problem hiding this comment.
Okay, I can agree with a new object, but I cannot agree with calling it Metal3Host. BareMetalHost is also a Metal3 host technically. Could be BareMetalInstance, ProvisionedBareMetal, BareMetalProvisioning... Having a Metal3 prefix is not terribly helpful, definitely does not solve the potential confusion.
There was a problem hiding this comment.
https://docs.google.com/document/d/1FL8oA0_WNcPdiC-0zrToinl8aol-NPQUjWe-OkcvTqA/edit has some prior art with regards to naming.
|
|
||
| #### metal3host | ||
|
|
||
| '''golang |
There was a problem hiding this comment.
Formatting is off here, should be
```go
```
without extra indentation.
|
/remove-lifecycle stale |
metal3-io-bot
removed
the
lifecycle/stale
|
|
||
| Metal3HostDeployment will define a group of metal3Hosts with the same configuration. It could define the number of replicas. It could scale up/down. We even could auto-scale by some rules after the monitor function is leveraged. | ||
|
|
||
| The data operator will set up the boot time configuration & routine. It includes three parts: the userData, the metaData, and the networkData. The userData includes some user-specified data such as installing a package, or running a command like "mkdir /test". The metaData defines some host-specific data such as hostname. The networkData includes the network configuration. The data is bound with the baremetal host. For example, the networkData defines a NIC with an IP, the NIC name is host related. So a dataTemplate should be pre-defined, it will be bound to the bare-metal host when a metal3host is defined and associated with a bare-metal host. |
There was a problem hiding this comment.
It is not clear to me why do you need a new pair of data and dataTemplate CR, wouldn't it be easier to just re-use the existing metal3Data and metal3DataTemplates?
You would also use the new data and the dataTemplate for the same config process as the existing metal3Data and metal3DataTemplate is used for.
There was a problem hiding this comment.
Yes, almost the same with metal3Data. One reason I want to create a new CR is, the metal3Data is bound to the metal3Machine, so it's not easy to modify if any change is required. Another is that the metal3Host and data could be an independent application(new a repo).
Maybe I'm wrong about this.
There was a problem hiding this comment.
What's the mechanism of linking machines to metal3Data? If it's ownerReference, we may be able to link different CR's there.
|
|
||
| The bare-metal host controller and the ironic are not newly developed. | ||
|
|
||
| Metal3Host is a virtual instance. Users could define it to require a bare-metal host. In the definition, the user could specify the image to install, could set the selector to choose a specific bare-metal host, and could define the boot data to automatically start their own applications. |
There was a problem hiding this comment.
I see so the host is handled like a workload, like a pod.
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
metal3-io-bot
added
the
lifecycle/stale
|
Stale issues close after 30d of inactivity. Reopen the issue with /close |
|
@metal3-io-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/life-cycle-frozen |
Rozzii
added
lifecycle/frozen
Thank you for your recognition. |
|
@sailorvii: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
What this PR does / why we need it:
In some scenarios, customers like to acquire an empty bare-metal host or a group of hosts.
Furthermore, users hope that host could pre-install the customized application.
It's a pure bare-metal management platform without guest Kubernetes.
Which issue(s) this PR fixes (optional, in fixes #(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #metal3-io/cluster-api-provider-metal3#649