Problem deploying openstack-ha with juju deploy

[Aymen Frikha]

When deploying an openstack HA with bundle with juju deploy, openstack services didn't start correctly. Most of openstack services were not added to keystone catalog:
keystone catalogue

Service: compute

+-------------+-------------------------------------------------------------+

| Property | Value |

+-------------+-------------------------------------------------------------+

| adminURL | http://10.20.0.101:8774/v2/71b3e04035e44e7eaea0bd76e822b063 |

| id | 63a0d024627149499af6076835917830 |

| internalURL | http://10.20.0.101:8774/v2/71b3e04035e44e7eaea0bd76e822b063 |

| publicURL | http://10.20.0.101:8774/v2/71b3e04035e44e7eaea0bd76e822b063 |

| region | |

+-------------+-------------------------------------------------------------+

Service: object-store

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| adminURL | http://10.20.0.107:80/swift |

| id | 05eaafa69f0c44129b9fc02a807deb15 |

| internalURL | http://10.20.0.107:80/swift/v1 |

| publicURL | http://10.20.0.107:80/swift/v1 |

| region | |

+-------------+----------------------------------+

Same charms/ parameters / relations were added in another bundle with juju-deployer tool and everything works fine with this tool. But not with juju deploy. The bundle used with juju deploy is:
https://pastebin.canonical.com/172084/

The bundle used with juju-deployer is this:
https://pastebin.canonical.com/172085/

[Anastasia (anastasia-macmood)]

Could you please clarify what version of juju you are using?

[Aymen Frikha (aym-frikha)]

I use juju : 2.0.1-xenial-amd64

[Anastasia (anastasia-macmood)]

From Francesco Banconi:

Bundle deployment acts at the Juju model level: it deploys charms, adds units, machines, relations, etc. It does not include any workload specific logic which is the responsibility of charms. To work around possible races in charms' implementation, juju-deployer used to artificially add a time sleep (like 60 seconds or similar) from when the units are created to when relations are established. The native bundle deployment is an opportunity to discover and fix those races, which would come up every time the charms are manually added by the user.

Since services fail to be registered to keystone when relations are added before units are created, this is a charm bug.