no way to specify openstack interface

[Junien F]

Hi,

When using the openstack provider, I'd like to be able to tell juju to use the "internal" endpoints only, and not the public endpoints like it's doing today. As far as I can see, this is not currently possible.

Thanks

[John A Meinel (jameinel)]

Do you mean for agents talking to each other, or are you saying the
controller/provisioner talking to Openstack?

I thought we just had you specify an Openstack URL, which you could give us
the private URL.

John
=:->

On Wed, Jan 23, 2019 at 3:01 PM Junien Fridrick <email address hidden>
wrote:

> Public bug reported:
>
> Hi,
>
> When using the openstack provider, I'd like to be able to tell juju to
> use the "internal" endpoints only, and not the public endpoints like
> it's doing today. As far as I can see, this is not currently possible.
>
> Thanks
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1812986
>
> Title:
> no way to specify openstack interface
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1812986/+subscriptions
>

[Junien F (axino)]

I mean the controller/provisioner talking to Openstack.

You specify a keystone URL, but then keystone will give you admin, private, and public endpoints to all other services (see e.g. https://pastebin.canonical.com/p/KkYW2rR85D/, although in that case all endpoints are the same).

And so you should be able to tell juju "only use the private endpoints" or "only use the admin endpoints"

[John A Meinel (jameinel)]

I'm fine adding some way to tell Juju that "use 'internal' APIs rather than 'public' APIs for services". However, I'd be curious why those are better. I thought 'internal' was meant to be 'for traffic from Openstack to Openstack, use internal, not "for cloud traffic to the Openstack".

As far as using "admin", I'm pretty sure that those don't expose the same methods, as they are meant for "humans that are administrating the applications" not "consuming the applications".

[Junien F (axino)]

"However, I'd be curious why those are better." nothing is "better", it's just something I feel people should be able to tweak. And it would certainly help us very much in our scenario where juju is used to deploy, in the cloud, a proxy to the APIs (said proxy becoming the "public" endpoint, but not the internal one).

AFAIK "admin" exposes the same method as public or internal. In most clouds, all the endpoints are the same (I know the admin endpoint for keystone used to be different, but that's no the case anymore).

[Jamon Camisso (jamon)]

Being able to juju config the model to use any of the os-internal, os-admin, or os-public hostnames would be very useful.

I ran into a situation where I would have liked to be able to specify the endpoint.

Specifically, the environment in question was setup and initially pointed at the internal VIP for keystone.

However, all services in the Openstack cloud in question are setup with a service proxy using public IPs and DNS names with TLS.

Attempting to juju add-unit resulted in a mismatch between what the cloud expected from its simplestreams index.json region, and the DNS name, e.g.:

{
 "format": "index:1.0",
 "index": {
  "auto.sync": {
   "cloudname": "region01",
   "clouds": [
    {
     "endpoint": "https://keystone.....com:5000/v3",
     "region": "region01"....

Whereas mongodb showed the VIP:

juju:PRIMARY> db.clouds.find();
{ "_id" : "cloud", "name" : "cloud", "type" : "openstack", "auth-types" : [ "userpass" ], "endpoint" : "https://10.10.10.10:5000/v3", "regions" : { "region01" : { "endpoint" : "https://10.10.10.10:5000/v3" } }, "ca-certificates" : [ ], "txn-revno" : NumberLong(2), "txn-queue" : [ ] }

This resulted in not being able to find an image to boot when adding a unit to a model in the environment. 'juju add-unit service-proxy' showed a machine error while provisioning in juju status;

'no "bionic" images in region01 with arches [amd64 arm64 ppc64el s390x]'

I edited the document and it works now:

juju:PRIMARY> db.clouds.update({"_id": "cloud"}, {$set:
               {"regions.region01.endpoint":
               "https://keystone.....:5000/v3"}});

So specifying the os-* endpoint in the model/controller config would be helpful.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.