Migrate to metal-apiserver - #61
Conversation
16c0fe7 to
2c10566
Compare
|
Not sure if it would accelerate things if we reconsider the idea of supporting both incoming tokens (metal-api and metal-apiserver, distinguished by passing a separate environment variable). This would not break existing clients at all and we would not need a lot of deployment changes. I think the code base of this repository is simple enough to realize this. For bigger clients this might be the wrong choice but here I would say it would make the migration way easier. |
| resp, err := cs.client.Machine().FindMachine(machine.NewFindMachineParams().WithID(machineID), nil) | ||
| if err != nil || resp == nil || resp.Payload == nil { | ||
| // we must use adminv2 because otherwise project must be passed which is not known here | ||
| resp, err := cs.apiv2client.Adminv2().Machine().Get(s.Context(), &adminv2.MachineServiceGetRequest{ |
There was a problem hiding this comment.
I am still a bit hesitant to use an admin endpoint in the service, which is initially why we added an infra API. Introducing another endpoint for the metal-console in infra feels a bit cleaner to me. It can also request all machines but only gets back the information it really needs (SSH pub keys?).
There was a problem hiding this comment.
SSH Publickeys and Machine Type (machine/firewall) and if the allocation changed to terminate existing console session in such a case.
|
replaced by #66 |
Description
Next part of MEP-4
TODO:
Closes: #62
Required Actions