The ssh key gets injected via ignition which is why it’s not present in the HOT template. You need minimum train release of Heat for this to work however. Sent from my iPhone
On 7 Apr 2021, at 21:45, Luke Camilleri <luke.camilleri@zylacomputing.com> wrote:
Hello Ammad and thanks for your assistance. I followed the guide and it has all the details and steps except for one thing, the ssh key is not being passed over to the instance, if I deploy an instance from that image and pass the ssh key it works fine but if I use the image as part of the HOT it lists the key as "-"
Did you have this issue by any chance? Never thought I would be asking this question as it is a basic thing but I find it very strange that this is not working. I tried to pass the ssh key in either the template or in the cluster creation command but for both options the Key Name metadata option for the instance remains "None" when the instance is deployed.
I then went on and checked the yaml file the resource uses that loads/gets the parameters /usr/lib/python3.6/site-packages/magnum/drivers/k8s_fedora_coreos_v1/templates/kubemaster.yaml has the below yaml configurations:
kube-master: type: OS::Nova::Server condition: image_based properties: name: {get_param: name} image: {get_param: server_image} flavor: {get_param: master_flavor} MISSING -----> key_name: {get_param: ssh_key_name} user_data_format: SOFTWARE_CONFIG software_config_transport: POLL_SERVER_HEAT user_data: {get_resource: agent_config} networks: - port: {get_resource: kube_master_eth0} scheduler_hints: { group: { get_param: nodes_server_group_id }} availability_zone: {get_param: availability_zone}
kube-master-bfv: type: OS::Nova::Server condition: volume_based properties: name: {get_param: name} flavor: {get_param: master_flavor} MISSING -----> key_name: {get_param: ssh_key_name} user_data_format: SOFTWARE_CONFIG software_config_transport: POLL_SERVER_HEAT user_data: {get_resource: agent_config} networks: - port: {get_resource: kube_master_eth0} scheduler_hints: { group: { get_param: nodes_server_group_id }} availability_zone: {get_param: availability_zone} block_device_mapping_v2: - boot_index: 0 volume_id: {get_resource: kube_node_volume}
If i add the lines which show as missing, then everything works well and the key is actually injected in the kubemaster. Did anyone had this issue?
On 07/04/2021 10:24, Ammad Syed wrote: Hi Luke,
You may refer to below guide for magnum installation and its template
https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=10
It worked pretty well for me.
- Ammad On Wed, Apr 7, 2021 at 5:02 AM Luke Camilleri <luke.camilleri@zylacomputing.com> wrote:
Thanks for your quick reply. Do you have a download link for that image as I cannot find an archive for the 32 release?
As for the image upload into openstack you still use the fedora-atomic property right to be available for coe deployments?
On 07/04/2021 00:03, feilong wrote: Hi Luke,
The Fedora Atomic driver has been deprecated a while since the Fedora Atomic has been deprecated by upstream. For now, I would suggest using Fedora CoreOS 32.20201104.3.0
The latest version of Fedora CoreOS is 33.xxx, but there are something when booting based my testing, see https://github.com/coreos/fedora-coreos-tracker/issues/735
Please feel free to let me know if you have any question about using Magnum. We're using stable/victoria on our public cloud and it works very well. I can share our public templates if you want. Cheers.
On 7/04/21 9:51 am, Luke Camilleri wrote: We have insatlled magnum following the installation guide here https://docs.openstack.org/magnum/victoria/install/install-rdo.html and the process was quite smooth but we have been having some issues with the deployment of the clusters.
The image being used as per the documentation is https://download.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20...
Our first issue was that podman was being used even if we specified the use_podman=false (since the image above did not include podman) but this was resulting in a timeout and the cluster would fail to deploy. We have then installed podman in the image and the cluster progressed a bit further
+ echo 'WARNING Attempt 60: Trying to install kubectl. Sleeping 5s' + sleep 5s + ssh -F /srv/magnum/.ssh/config root@localhost '/usr/bin/podman run --entrypoint /bin/bash --name install-kubectl --net host --privileged --rm --user root --volume /srv/magnum/bin:/host/srv/magnum/bin k8s.gcr.io/hyperkube:v1.15.7 -c '\''cp /usr/local/bin/kubectl /host/srv/magnum/bin/kubectl'\''' bash: /usr/bin/podman: No such file or directory ERROR Unable to install kubectl. Abort. + i=61 + '[' 61 -gt 60 ']' + echo 'ERROR Unable to install kubectl. Abort.' + exit 1
The cluster is now failing here at "kube_cluster_deploy" and when checking the logs on the master node we noticed the following in the log files:
Starting to run kube-apiserver-to-kubelet-role Waiting for Kubernetes API... + echo 'Waiting for Kubernetes API...' ++ curl --silent http://127.0.0.1:8080/healthz + '[' ok = '' ']' + sleep 5
This is because the kubernetes API server is not installed either. I have noticed some scripts that should handle the installation but I would like to know if anyone here has had similar issues with a clean Victoria installation.
Also should we have to install any packages in the fedora atomic image file or should the installation requirements be part of the stack?
Thanks in advance for any asistance
-- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------ -- Regards,
Syed Ammad Ali