Inconsistent tag between ocatavia and retrofit

[Nobuto Murata]

If I'm not mistaken from the documentation, octavia-diskimage-retrofit charm will add "octavia-diskimage-retrofit" tag out of the box.

https://jaas.ai/octavia-diskimage-retrofit#charm-config-amp-image-tag
> amp-image-tag
> (string) When set the charm will add tag to any newly created
> images. . Note that the charm will allways add the
> ``octavia-diskimage-retrofit`` tag to created images, this is for
> convenience and may be used by the charm for housekeeping in the
> future.

However, Octavia charm configures itself to look for "octavia-amphora" out of the box.

https://jaas.ai/octavia#charm-config-amp-image-tag
> amp-image-tag
> (string) Glance image tag for selection of Amphorae image to boot
> load balancer instances.
> octavia-amphora

And the deployment guide directs that amp-image-tag option in the retrofit charm needs to be set as "octavia-amphora".

https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-octavia.html
> Octavia uses Amphorae (cloud instances running HAProxy) to provide
> LBaaS services; an appropriate image must be uploaded to Glance with
> the tag octavia-amphora.

> juju deploy octavia-diskimage-retrofit \
> --config amp-image-tag=octavia-amphora

Can we have a consistent tag out of the box?

[Frode Nordahl (fnordahl)]

As noted in the configuration option description:
     "When set the charm will add tag to any newly created images. . Note that the charm will allways add the ``octavia-diskimage-retrofit`` tag to created images, this is for convenience and may be used by the charm for housekeeping in the future."

The ``octavia-diskimage-retrofit`` tag is added regardless of configuration, if you set the configuration option it will add what you configure in addition to the mentioned tag.

The act of adding the tag that Octavia looks for can have impact on Octavia's ability to create new load balancer instances depending on how existing image tags are maintained etc.

As such it is deliberately made into an operator choice to have the charm do it unconditionally.

There is room for further development and improvement of the whole amphora life cycle management story from the charms perspective, but that body of work would include more than changing the default of this configuration option.