Open Stack

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 
> <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 at zylacomputing.com 
> <mailto:luke.camilleri at 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
>>     <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
>>>     <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-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64
>>>     <https://download.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64>
>>>
>>>     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 at 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
>>>     <http://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
>>>     <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 at catalyst.net.nz  <mailto:flwang at catalyst.net.nz>
>>     Catalyst IT Limited
>>     Level 6, Catalyst House,150 Willis Street, Wellington  <https://www.google.com/maps/search/150+Willis+Street,+Wellington?entry=gmail&source=g>
>>     ------------------------------------------------------
>
> -- 
> Regards,
>
>
> Syed Ammad Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210407/9f94d00d/attachment-0001.html>