prefer to add accessIP in machine list

[hchenxa]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Prefer to add machine accessIP in machine list so that I can easy find the access IP and use my crential to login the cluster.

below was the current behavior:

[root@hchenxa1 ~]# kubectl  get machine -o wide
NAME                    AGE
hchenxa1-master-qkcvs   1d

from the output, I only can see my machine list, so if I want to connect the machine, I need to get the accessIP from the detail of machine info, so prefer the machine list can have the accessIP like, and it also be good if the list can container the machine type like OS(centos, coreos, ubuntu)

[root@hchenxa1 ~]# kubectl  get machine -o wide
NAME                    AGE      floatingIP     image 
hchenxa1-master-qkcvs   1d     9.20.204.143   KVM-Ubt18.04-Srv-x64

Comments? @gyliu513

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

[gyliu513]

This is a limitation of CR as CR can only show NAME and AGE now, let me check more for this.

FYI @jichenjc @chrigl

[jichenjc]

similar to this one?
#274
I am working on this now, it's postponed due to cluster-api v0.1.0 adoption

https://github.com/kubernetes-sigs/cluster-api/pull/851/commits

[chrigl]

This thing is... Since we are not the owner of the Machine custom resource, there is no way to configure provider specific fields.
Especially when it comes to the use case of allowing a "management cluster" being able to control child clusters at multiple providers. See kubernetes-sigs/cluster-api#903

There is currently a whole lot going on in the cluster-api project. https://docs.google.com/document/d/1Ys-DOR5UsgbMEeciuG0HOgDQc8kZsaWIWJeKJ1-UfbY/

[jichenjc]

yeah, a lot going on.. we need catch up with them

and even the resource doesn't owned by us (such as floating ip), maybe we can generalize the thing we want to show to end user (floatingip --> provider ip ?) then set the value in provider side?

[jichenjc]

@hchenxa @chrigl if you don't have objection, I think
https://github.com/kubernetes-sigs/cluster-api/blob/master/pkg/apis/cluster/v1alpha1/machine_types.go#L181
might be some place to handle, I can add a PR to set those info in our reconcile logic and
create PR in cluster-api to make it showable to end user
please let me know any concern then I can go ahead and assign myself to work on it

[chrigl]

@jichenjc lgtm.

[jichenjc]

kubernetes-sigs/cluster-api#951

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.