-
Notifications
You must be signed in to change notification settings - Fork 33
Bug 1746021: Abort Instance if no valid network #66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1746021: Abort Instance if no valid network #66
Conversation
The Machine service, upon machine creation, looks in OpenStack for networks and subnets matching the Machine Networks specificiation. Before this change, if no matching network was found, the Instance spec was sent to OpenStack with an empty Network segment. With this change, the Machine service returns an error to the caller if no matching networks are found in Openstack. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1746021
|
@pierreprinetti: This pull request references Bugzilla bug 1746021, which is invalid:
Comment 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. |
|
/bugzilla refresh |
|
@pierreprinetti: This pull request references Bugzilla bug 1746021, which is invalid:
Comment 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. |
|
The fix looks good me me. We should indeed stop sending requests that nova can't handle. One question, though. Shouldn't this go in upstream k8s CAPO too? |
To my (very limited) knowledge, there is no upstream |
|
/bugzilla refresh |
|
@pierreprinetti: This pull request references Bugzilla bug 1746021, which is invalid:
Comment 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. |
|
/assign @Fedosin |
|
/bugzilla refresh |
|
@pierreprinetti: This pull request references Bugzilla bug 1746021, which is valid. The bug has been updated to refer to the pull request using the external bug tracker. 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. |
|
/lgtm We need to push it in upstream as well :) https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/master/pkg/cloud/services/compute/instance.go#L132 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Fedosin, pierreprinetti 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:
Approvers can indicate their approval by writing |
Thanks for the link! I've been unsuccessfully looking for that |
|
@pierreprinetti: All pull requests linked via external trackers have merged. Bugzilla bug 1746021 has been moved to the MODIFIED state. 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. |
Allow for passing the machine username in the providerConfig. This is mostly needed by the `clusterctl` command and we should probably find a better way to get the kubeconfig data. Until then, let's not hardcode the username in the implementation. Closes openshift#66
Allow for passing the machine username in the providerConfig. This is mostly needed by the `clusterctl` command and we should probably find a better way to get the kubeconfig data. Until then, let's not hardcode the username in the implementation. Closes openshift#66
The Machine service, upon machine creation, looks in OpenStack for
networks and subnets matching the Machine Networks specificiation.
Before this change, if no matching network was found, the Instance spec
was sent to OpenStack with an empty Network segment.
With this change, the Machine service returns an error to the caller if
no matching networks are found in Openstack.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1746021