Ceph services on channel quincy

Bug #1974481 reported by Nicholas Anderson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Charms Deployment Guide
Fix Released
Medium
Peter Matulis

Bug Description

- [x ] This doc is inaccurate in this way: ______

It appears that the guide was updated yesterday to reflect jammy/yoga instillations of OpenStack. As a consequence, it looks like all the service deployments added channel flags to the "juju deploy" command. When a specific version is not designated, it appears that --channel yoga/stable is being selected as the "default".

For some reason, ceph-osd, ceph-mon, and ceph-radosgw are deploying to --channel quincy/stable. Is this an oversite? If it is not, could an explanation be added in the Ceph-osd section? I was under the impression that services had to be deployed under the same version of OpenStack in order to work properly.

-----------------------------------
Release: 0.0.1.dev465 on 2022-05-19 20:51:17
SHA: f00dd88ee89c0242479eb62a67085e6fabffd99e
Source: https://opendev.org/openstack/charm-deployment-guide/src/deploy-guide/source/install-openstack.rst
URL: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-openstack.html

Revision history for this message
Nicholas Anderson (nanderson91) wrote :
Revision history for this message
Billy Olsen (billy-olsen) wrote :

The channels for the charms will relate to the version of software that is being managed by the charm. When it comes to Ceph, the version of software is the Ceph version (e.g. quincy). Since there is no "Yoga" version of Ceph, there is no yoga channel published. This is a bit of a departure in previous trains of thought, but the truth does still hold that the Yoga Version of OpenStack should be paired with the Quincy version of Ceph, especially in a hyperconverged deployment scenario.

If you take a non-hyperconverged scenario then it makes even more sense to have the charm channel track the version of the software it manages. In this scenario, you can clearly deploy the Yoga version of Cinder with the Quincy version of Ceph. As long as it is not hyperconverged, you can also deploy the Xena version of Cinder with the Quincy version of Ceph.

Can you elaborate how you are determining that the --channel yoga/stable is being selected as the default? It is true that there can be a default channel set for specific charm, but I was unaware that we were making this choice already except for a specific charm or two where there was little to no risk in providing a default channel before users migrated to charmhub-delivered charms (e.g. mysql-innodb-cluster).

Revision history for this message
Nicholas Anderson (nanderson91) wrote :

Thanks for the reply.

"Can you elaborate how you are determining that the --channel yoga/stable is being selected as the default?"

In the previous version of the deployment guide that was focal/xena. The "source:" in the .yamls was focal/xena and the --channel flag was omitted in the juju deploy commands. I have used the --channel flag a couple times in my test deployments in the last couple months to get around the lxd bug and the mysql-router bug. In all the "juju deploy" commands in the current guide, with the exception of the ceph services and the mysql-router, all the services are deployed with the flags "--series jammy --channel yoga/stable" and I was infering that as a "default".

Thanks for the explanation above, that makes more sense. As the --channel flag is being used in the guide for every deploy command now, it might be worth adding a note similar to your explanation to reduce confusion. As a newer user on the platform I was under the incorrect assumption that the --channel flag was <openstack-version>/<stability version> when not requesting a specific charm version.

Revision history for this message
Billy Olsen (billy-olsen) wrote :

> Thanks for the explanation above, that makes more sense. As the --channel flag is being used in
> the guide for every deploy command now, it might be worth adding a note similar to your
> explanation to reduce confusion. As a newer user on the platform I was under the incorrect
> assumption that the --channel flag was <openstack-version>/<stability version> when not
> requesting a specific charm version.

To be fair, the --channel flag does mean openstack-version/stability-level when using it for OpenStack service charms. I think further confusion is that Ceph is not part of OpenStack, but commonly included with kind of thing.

As you point out in your screencapture, there are other places where the channel flag is used (such as mysql-inndob-cluster, rabbit, etc) and it does not reference openstack/stability.

I'm glad that the comment helped clarify things. I think its worth seeing if there's something we can include in the documentation that can help further clarify that.

Changed in charm-deployment-guide:
importance: Undecided → Low
status: New → Triaged
Changed in charm-deployment-guide:
assignee: nobody → Peter Matulis (petermatulis)
status: Triaged → In Progress
Changed in charm-deployment-guide:
importance: Low → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-deployment-guide (master)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-deployment-guide (master)

Reviewed: https://review.opendev.org/c/openstack/charm-deployment-guide/+/855093
Committed: https://opendev.org/openstack/charm-deployment-guide/commit/5f6fec4323a6af9ed114b03628fb0ccafb4b6c7c
Submitter: "Zuul (22348)"
Branch: master

commit 5f6fec4323a6af9ed114b03628fb0ccafb4b6c7c
Author: Peter Matulis <email address hidden>
Date: Mon Aug 29 17:54:14 2022 -0400

    Add info re software version selection

    Make it clearer how software versions are selected for
    charms and for cloud services.

    Closes-Bug: #1974481
    Change-Id: Idcb64aa12ff7e9069d8b0cf20a008ca55ff7ac78

Changed in charm-deployment-guide:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.