You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way the etcd.target service is bootstrapped is done at the incorrect time when building master.project. It's actually happening as part of the "master-bootstrap" environment when provisioning the template with salt-masterless at build-time, when really it should be happening at deploy-time. If issue #8 gets solved, then it would be significantly better to somehow do this as part of the process of provisioning with the "master" environment.
If at all possible, the "master" environment could detect other members of the cluster and use that to identify whether it's responsible for bootstrapping the instance of etcd. If this ends up being a valid solution, then we can also use the same logic to automatically deploy a distributed MinIO cluster with the store state, as well as one for Kafka too with the queue state. If absolutely all of this works properly, then we could even deploy k8s by default and simplify our container management too. However, this might still be clumsy, because we definitely _need_ the etcd instance to be running in order to manage job results returned by the "master" environment.
At the moment the usage of Terraform allows us to hack around this, but Terraform is not yet completely integrated into this project because of the immaturity of the terraform-provider-vsphere plugin.
The text was updated successfully, but these errors were encountered:
The way the etcd.target service is bootstrapped is done at the incorrect time when building master.project. It's actually happening as part of the "master-bootstrap" environment when provisioning the template with salt-masterless at build-time, when really it should be happening at deploy-time. If issue #8 gets solved, then it would be significantly better to somehow do this as part of the process of provisioning with the "master" environment.
If at all possible, the "master" environment could detect other members of the cluster and use that to identify whether it's responsible for bootstrapping the instance of etcd. If this ends up being a valid solution, then we can also use the same logic to automatically deploy a distributed MinIO cluster with the
store
state, as well as one for Kafka too with thequeue
state. If absolutely all of this works properly, then we could even deploy k8s by default and simplify our container management too. However, this might still be clumsy, because we definitely _need_ the etcd instance to be running in order to manage job results returned by the "master" environment.At the moment the usage of Terraform allows us to hack around this, but Terraform is not yet completely integrated into this project because of the immaturity of the
terraform-provider-vsphere
plugin.The text was updated successfully, but these errors were encountered: