carlosedp's profile - activity

I have a brand new Mirantis Openstack 9.2 deployment and I'm trying to launch some CentOS 7 images with no success.

I downloaded CentOS-7-x86_64-GenericCloud.qcow2 and converted to VMDK since my Openstack deployment is over a VMware cluster. After this, I load the image into Glance and deployed it but when the instance is launched I get no network. Here the commands I used:

qemu-img convert -f qcow2 -O vmdk CentOS-7-x86_64-GenericCloud.qcow2 CentOS-7-x86_64-GenericCloud.vmdk

glance image-create --name CentOS-7-x86_64-GenericCloud.vmdk --container-format bare --disk-format vmdk --min-disk 0 --min-ram 0 --progress --property
vmware_disktype=sparse --property vmware_adaptertype=ide --property hypervisor_type="vmware" --file  CentOS-7-x86_64-GenericCloud.vmdk

I manage to log into the CentOS terminal and got that there is no interface eth0 (not present). Also there is a "eno16777728" interface in "ip a" without IP of respective confir files in network-scripts.

Both CentOS 7 1511 and 1611 have the same problem.

I tried with Cirros, Ubuntu, Debian and CentOS 6 Generic Cloud and they all work perfectly. All of them were converted and loaded into Glance with the same commands and parameters.

Thanks

The update finished without errors but the UI and the CLI does not show that the current version is 9.1:

[root@fuel ~]# fuel fuel-version api: '1' auth_required: true feature_groups: - experimental - advanced openstack_version: mitaka-9.0 release: '9.0'

Is there anything wrong?

If you still have that actual keypair working, you could create a script that executes ssh commands into each instance, injects the new key into ~/.ssh/authorized_keys and then remove the old key.

Something like:

ssh user@server echo "NEW KEY" >> ~/.ssh/authorized_keys
ssh user@server "sed -i.bak '/OLD KEY/d' ~/.ssh/authorized_keys"

You could create a list of all instance IPs you have or fetch the instance IPs using Openstack API though this would be more advanced.

If you are interested testing the Murano packages, let me know.

Since I'm modifying docker-container package, I was able to fetch $.host.instance.floatingIpAddress and replace my placeholder text. The solution is actually:

Properties:
....
.....
extraopts:
   Contract: $.string()

Methods:
  initialize:
    Body:
    ....
      - $._address: $.host.instance.floatingIpAddress
      - $._extraOpts: str($.extraopts).replace("%FLOATINGIP%", str($._address))

Using this, I can pass --hostname %FLOATINGIP% to the docker container dynamically.

The only quirk is that this package only works when deploying over Docker Standalone Hosts. If you deploy on a Kubernetes Pod, the deployment fails since it does not find "instance" object. Still looking for a solution.

I'm facing a problem where I'm trying to deploy a container (Gitlab in this case) where it expects a docker parameter with the instance's IP address (--hostname [IP]).

I've implemented some changes to docker-container, docker-interface-library and docker-standalone-host to support additional run parameters like --restart, etc. I'm trying to pass --hostname %HOST% and try to replace %HOST% with the public IP address but I saw that the $.ApplicationEndpoints is not created until the application is deployed but I need in the beginning of the process.

Is there any way to fetch the public IP from the docker host? Thanks

To link containers, you can check Influx and InfluxDB applications from Murano apps repository (https://github.com/openstack/k8s-dock...). They implement a linked architecture between two containers and fetch information from each other.

Regarding other parameters, I've implemented a new version of the docker-container, docker-interface and standalone-host packages to support volume mapping in the format [HostDirectory]:[ContainerDirectory]. Ex. /srv/etc:/etc,/srv/log:/var/log.

I'm already implementing a way to pass additional parameters like "--restart always" and etc... It works but I've been trying to send the application's IP address to the container (to use on --hostname [IP]) for example but this is still unsuccessful.

How's your cluster DRS settings? Check if the admission control is set to "Fully Automated".

Right click your cluster -> Edit Settings -> "vSphere DRS" -> Automation Level.

I think this will automate the distribution.

Have you deployed an instance with a VMDK image? VMware ESXi doesn't support QCOW images. You can convert between formats and upload it back to Glance.

Check this guide: http://docs.openstack.org/image-guide...

After replacing the switch with one that has 1Gbps ports (the old one had 100Mbps ports) the problem was solved. No more timeouts.

I think the 300 seconds is not enough to upload the files to my datastore, maybe it's my network. Any idea about which file contains the timeout parameter? I'm not too used to puppet, nailgun, astute and etc... Thanks

I tried with more nodes with the same problem. It seems like a problem related to deploy the images into VMware datastores. No idea on what's wrong. The only thing is that the Fuel node and the controller nodes are all VMs in ESXi.

It's not complaining (other than having no HA). It fails on image upload to the datastore. I see the files getting uploaded than they get deleted. I will try with 3 nodes to check if same problem happens.

By the way, I'm deploying Mitaka over Ubuntu 14.04. The MOS 9.0 default.

You can mirror the repositories into your fuel node (with internet access) and them deploy the packages locally without internet access to all the nodes. Take a look into fuel-createmirror --help

There is a problem deploying Zabbix 2.0.0 having mirrored the reopsitories locally.

The problem has been fixed on the 2.5.0 version that can be built from git source:

yum install createrepo rpm rpm-build dpkg-devel
easy_install pip
pip install fuel-plugin-builder
git clone https://github.com/openstack/fuel-plugin-external-zabbix.git 
fpb --check ./fuel-plugin-external-zabbix
fpb --build ./fuel-plugin-external-zabbix
fuel plugins --install fuel-plugin-external-zabbix/zabbix_monitoring-2.5-2.5.0-1.noarch.rpm

I checked some repositories and a couple of them are already updated but I bellieve Mirantis still need to package and publish on the site. https://github.com/stackforge/fuel-pl... https://github.com/stackforge/fuel-pl...

Answering my own question, inside each plugin the file "metadata.yaml" defines a parameter with a version constraint:

Ex. fuel_version: ['6.1']

Now all plugins are only available to MOS 6.1. They must be updated to be compatible with 7.0.

No, this is not possible. The vCPU allocation is limited into one host.

You can have multiple VMs having a sum of vCPUs to more than the host has CPUs but you cannot have the vCPUs spanning to multiple hosts (physical servers).

I opened a plugin package and found out that there is a tag for MOS version where i'ts currently set to 6,1. I believe the plugins must be updated to be able to deploy them on a 7.0 environment. For now I will revert my env to 6.1.

I had a MOS 6.1 Fuel installation with a couple plugins (fwaas, lbaas, zabbix) installed. The environments I deployed in this version had the plugins available and it's settings shown when deploying.

After updating the Fuel master node to 7.0, I deleted the environment I had to redeploy using latest version but the plugins are not installed nor it's settings shown in "Settings" pane.

All plugins are show in the "Plugins" tab from top and also in "fuel plugins" CLI.