Hostname missing in /etc/hosts file in openstack instance

[prankul88]

#436

What I felt is when any sudo commands run from master-user-data.sh, it hangs for a bit and then proceeds. If we can map loopback-ip to the hostname in /etc/hosts (can add command in master-user-data file), it would not get stuck.

[k8s-ci-robot]

Hi @prankul88. Thanks for your PR.

I'm waiting for a kubernetes-sigs or kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[jichenjc]

/ok-to-test

[sbueringer]

@prankul88 The master-user-data file moved because the v1alpha2 PR got merged on master it's now in samples/templates/user-data/ubuntu

[prankul88]

@sbueringer Thanks I will update this patch to remove the conflict.
Just one thing I saw that now we have master-user-data.sh in samples/templates/user-data/ as well. (Before it was generated by ./generate.yaml). Can you help me understand why is it there? And probably I will need to update that file as well

[sbueringer]

@sbueringer Thanks I will update this patch to remove the conflict.
Just one thing I saw that now we have master-user-data.sh in samples/templates/user-data/ as well. (Before it was generated by ./generate.yaml). Can you help me understand why is it there? And probably I will need to update that file as well

The short answer is because the first parts of the migration to v1alpha2 are merged on master. (see this PR #446)

But there is not enough documentation yet how to setup a cluster like with clusterctl before. But clusterctl itself is not fully migrated to v1alpha2 as far as I know. So depending on the branch master or release-0.1 (v1alpha1) you have to modify different files.

Might make sense to merge this PR in release-0.1 so you can test and continue. I can create a cherry-pick for master if you want.

[prankul88]

@sbueringer Sure I will move it to release-0.1 and then cherry-picking seems to be the right option. Thanks.

[k8s-ci-robot]

@prankul88: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-cluster-api-provider-openstack-check	623ce30	link	/test pull-cluster-api-provider-openstack-check

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

[prankul88]

/retest

[sbueringer]

@prankul88 There's also an Issue in CABPK (which is used in CAPI v1alpha2). Probably better to solve the issue in v1alpha2 in the other issue: https://github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm/issues/116

But the fix here for v1alpha1 makes sense

[jichenjc]

/lgtm

[sbueringer]

/approve

[sbueringer]

@jichenjc I think you have to approve because I'm not an approver yet on this branch :)

/lgtm

[jichenjc]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jichenjc, prankul88, sbueringer

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jichenjc]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment