[SRU] radosgw-admin user create error message confusing if user with email already exists

The attachment "Patch to improve error message" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Attaching the debdiff done for Luminous (based off Matthew Vernon's patch).

Looking at the ceph source code for Hirsute this has yet to be fixed there and the SRU process requires that bugs first be fixed in the development release of Ubuntu.

Hi Brian,

James Page is doing a newer hirsute release in [0] which includes this fix as well. I'll upload the debdiffs for various Ubuntu releases as well.

[0] https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1922883

Attaching debdiff for Focal.

Attaching debdiff for Groovy.

Attaching debdiff for Hirsute.

@pponnuvel

The versions in the UNAPPROVED queue for groovy and focal already have this included - please check the git repository for anything inflight :)

Thanks, James. Do you know this is in the SRU queue and when this patch might be committed?

This bug was fixed in the package ceph - 16.2.0-0ubuntu1

---------------
ceph (16.2.0-0ubuntu1) hirsute; urgency=medium

  [ Chris MacNaughton ]
   * d/p/bug1914584.patch: Improve rgw diagnostic when reusing email
    (LP: #1914584).

  [ James Page ]
  * New stable release for Ceph Pacific (LP: #1922883):
    - d/control: Add BD's on libicu-dev and libsqlite3-dev.
    - d/control,libsqlite3-mod-ceph*: Add new binary packages
      for sqlite3 extension module for Ceph.
    - d/rules: Enable RBD RWL and SSD Cache features.
    - d/radosgw.install: Add new rgw-gap* binaries.
    - d/python3-cephfs.install: Restore ceph_volume_client.py
      for use in OpenStack Manila deployments.
    - d/control,rules: Add BD's on libpmem{obj}-dev and enable use
      of system libraries.
  * Dropped patches, all included in release:
    - d/p/fix-ftbfs-c++17.patch
    - d/p/fix-boost-1.74-build.patch
    - d/p/issue49494.patch
  * d/p/*: Refresh.
  * d/p/32bit-fixes.patch: Additional updates for armhf compilation
    failures.
  * d/rules: Disable LTO.

 -- James Page <email address hidden> Sat, 10 Apr 2021 08:14:20 +0100

This bug was fixed in the package ceph - 16.2.0-0ubuntu1~cloud0
---------------

 ceph (16.2.0-0ubuntu1~cloud0) focal-wallaby; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 ceph (16.2.0-0ubuntu1) hirsute; urgency=medium
 .
   [ Chris MacNaughton ]
    * d/p/bug1914584.patch: Improve rgw diagnostic when reusing email
     (LP: #1914584).
 .
   [ James Page ]
   * New stable release for Ceph Pacific (LP: #1922883):
     - d/control: Add BD's on libicu-dev and libsqlite3-dev.
     - d/control,libsqlite3-mod-ceph*: Add new binary packages
       for sqlite3 extension module for Ceph.
     - d/rules: Enable RBD RWL and SSD Cache features.
     - d/radosgw.install: Add new rgw-gap* binaries.
     - d/python3-cephfs.install: Restore ceph_volume_client.py
       for use in OpenStack Manila deployments.
     - d/control,rules: Add BD's on libpmem{obj}-dev and enable use
       of system libraries.
   * Dropped patches, all included in release:
     - d/p/fix-ftbfs-c++17.patch
     - d/p/fix-boost-1.74-build.patch
     - d/p/issue49494.patch
   * d/p/*: Refresh.
   * d/p/32bit-fixes.patch: Additional updates for armhf compilation
     failures.
   * d/rules: Disable LTO.

Hello Matthew, or anyone else affected,

Accepted ceph into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ceph/15.2.11-0ubuntu0.20.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Matthew, or anyone else affected,

Accepted ceph into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ceph/15.2.11-0ubuntu0.20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

With SRU verification test, it doesn't quite work as intended. I believe the problem is with the upstream patch [0].

I've asked for clarification/confirmation [1]. I'll then have to mark the verifications failed, I am afraid. This obviously affects 15.2.11 release as well. I'll try to get this fixed upstream as soon as possible and re-submit patches. Please let me know if there's anything else that can be (or needs to be) done.

[0] https://github.com/ceph/ceph/pull/39293
[1] https://github.com/ceph/ceph/pull/39293#issuecomment-827751233

Submitted patch upstream: https://github.com/ceph/ceph/pull/41065

Confirmed that the patch needs re-work. So marking all verification failed.

I've opened an issue in upstream tracker [0]. Submitted the patch upstream [1]. Once that gets approved, backports to Nautilus, Octopus, and Pacific to follow.

I am not sure how 15.2.11 release can be worked around whether we wait for upstream acceptance or proceed without this patch. Please let me know what you think, James/Corey.

[0] https://tracker.ceph.com/issues/50554
[1] https://github.com/ceph/ceph/pull/41065

Hello Matthew, or anyone else affected,

Accepted ceph into ussuri-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:ussuri-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ussuri-needed to verification-ussuri-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ussuri-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This (incorrect) patch is in upstream master and backported to Nautilus, Octopus, and Pacific. This isn't critical and doesn't break functionality - except for an incorrect error message if user attributes modification fails. However, the reported problem still exists. So I've marked all verifications as failed.

This bug was fixed in the package ceph - 15.2.11-0ubuntu0.20.10.2

---------------
ceph (15.2.11-0ubuntu0.20.10.2) groovy; urgency=medium

  * d/p/bug1914584.patch: Drop as this patch does not fix the
    actual issue.

ceph (15.2.11-0ubuntu0.20.10.1) groovy; urgency=high

  [ James Page ]
  * d/p/bug1917414.patch: Cherry pick fix to isa-l to remove use of text
    relocation calls which cause ceph-osd and ceph-mon daemons to fail
    to start (LP: #1917414).

  [ Chris MacNaughton ]
  * d/p/bug1914584.patch: Improve rgw diagnostic when reusing email
    (LP: #1914584).

  [ James Page ]
  * SECURITY UPDATE: New upstream stable point release (LP: #1921349).
    - CVE-2021-20288
    - d/p/bug1911900-fix-scrub-blocking-balancer.patch:
      Drop, included in release.
    - d/p/32bit-fixes.patch: Update for mismatched size_t/uint64_t on
      armhf causing compilation failure.

 -- James Page <email address hidden> Fri, 30 Apr 2021 12:10:45 +0100

This bug was fixed in the package ceph - 15.2.11-0ubuntu0.20.04.2

---------------
ceph (15.2.11-0ubuntu0.20.04.2) focal; urgency=medium

  * d/p/bug1914584.patch: Drop as this patch does not fix the actual
    issue.

ceph (15.2.11-0ubuntu0.20.04.1) focal; urgency=medium

  [ James Page ]
  * d/p/bug1917414.patch: Cherry pick fix to isa-l to remove use of
    text relocation calls which cause ceph-osd and ceph-mon daemons to
    fail to start on aarch64 (LP: #1917414).

  [ Chris MacNaughton ]
  * d/p/bug1914584.patch: Improve rgw diagnostic when reusing email
    (LP: #1914584).

  [ James Page ]
  * SECURITY UPDATE: New upstream stable point release (LP: #1921349):
    - CVE-2021-20288
    - d/p/bug1911900-fix-scrub-blocking-balancer.patch:
      Drop, included in release.
    - d/p/32bit-fixes.patch: Resolve compilation failure on armhf due to
      mismatched size_t/uint64_t types.

 -- James Page <email address hidden> Fri, 30 Apr 2021 12:13:27 +0100

Marking bug tasks back to New as patch was reverted due to testing failures.

This bug was fixed in the package ceph - 15.2.12-0ubuntu0.20.10.1

---------------
ceph (15.2.12-0ubuntu0.20.10.1) groovy-security; urgency=medium

  * SECURITY UPDATE: New upstream release (LP: #1929179):
    - CVE-2021-3509: Dashboard XSS via token cookie.
    - CVE-2021-3531: Swift API denial of service.
    - CVE-2021-3531: HTTP header injects via CORS in RGW.

 -- James Page <email address hidden> Mon, 24 May 2021 16:05:29 +0100

This bug was fixed in the package ceph - 15.2.12-0ubuntu0.20.04.1

---------------
ceph (15.2.12-0ubuntu0.20.04.1) focal-security; urgency=medium

  * SECURITY UPDATE: New upstream release (LP: #1929179):
    - CVE-2021-3509: Dashboard XSS via token cookie.
    - CVE-2021-3531: Swift API denial of service.
    - CVE-2021-3531: HTTP header injects via CORS in RGW.

 -- James Page <email address hidden> Mon, 24 May 2021 16:07:20 +0100

Attaching debdiff built on focal for octopus

I'm unsubscribing the sts-sponsors team, due to the fact that this bug has strayed very far from the correct SRU process. If the sts-sponsors team should sponsor patches for this bug, please reset this bug to fix-released and open a new bug to track patching it.

The SRU process can be found here:
https://wiki.ubuntu.com/StableReleaseUpdates

please note specifically if verification fails:
https://wiki.ubuntu.com/StableReleaseUpdates#Verification

you should either upload correct patches on top of the -proposed version, using the same bug number, or - if you choose to just revert and reupload - you should *NOT* use -v with the new upload to automatically move the not-actually-fixed bug into fix-released.

sorry to clarify it looks like this is a bug in the scripting used by the openstack team, marking this as fix-released during a 'stable update' (comment 23 and comment 24) even though it wasn't fixed. that's quite messy and confusing, and even more reason not to re-use this bug. :-/

Reverted the 'status' of the bug to the previous states.

As Dan Streetman pointed out, 'reuse' of this bug causes
confusion and strays from the standard SRU process.
I creates a new bug to carry out the SRU

https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1940456

The fixed patch is already accepted upstream and backported
to supported upstream releases as well. So this is just a
standard SRU process now that'll be done via LP#1940456.

As a member of the SRU team I disagree with Dan on this, I don't think it's incorrect to reuse the same bug (with history) for iterations of an SRU for the same issue.

However, it IS incorrect to mark a bug 'fix released' when there has been no corresponding upload to the target archive/series.

Actually, rereading comment #26 from Dan, it looks to me that he agrees that yes, using the same bug # for iterations is correct. So I'm not really clear what's going on here.

Comments #19 and #20 probably relate to some tasks being marked as Fix Released due to the way that the proposed -> updates migration works - the changelog is generated based on what's already in updates for the migration. Thus the bug fixed in the first uploaded but then reverted in the second gets marked as Fix Released.

The fix that is being worked on still resolves *this* bug so I think re-use is OK - when I discussed with sil21000 whilst working on the revert we agreed that the tasks would need to be reset once the update was released (and that this was less than ideal).

Anyway I hope that provides some context for this discussion.

> So I'm not really clear what's going on here.

That's the problem, and why I suggested a new bug should be opened for this bug; it was marked fix-released but never actually fix-released, and then it was going to be re-used by manually changing from fix-released back to new and then go thru the process again. Not confusing at all right? ;-)

I had to re-read the bug 4-5 times to finally understand that the bug was initially incorrectly marked fix-released in comment 20 and comment 21, when in fact the incorrect fix never actually made it to -updates, but then again was incorrectly marked fix-released in comment 23 and comment 24, still without the incorrect (or correct) fix ever making it into -updates, and then was about to be 'fixed' yet a 3rd time with an actual fix.