Hi John & Cephadm folks,
Given this a Python-only package, have you considered publishing that to PyPI? (It seems there's an approved PEP to bring TUF metadata support to the Python SCM, but not yet implemented).
We already have some Ceph Python packages published there (teuhology, ceph-medic, ceph-deploy, ...). Probably some of those maintainers (@Zack Cerza , @Ken Dreyer ) could tell us more about their experience with that.
PyPi itself supports package hashes and signatures:
- When uploading the package with twine (or setuptools) you need to generate the stand-alone signature and pass it together with the main package: "twine cephadm-17.2.4-py3-none-any.whl cephadm-17.2.4-py3-none-any.whl.asc"
- BTW, the wheel distribution format (zip-like too) also supports embedded signatures.
- The stand-alone signature will then be available in the PyPI repo: "https://files.pythonhosted.org/packages/<hash>/cephadm-17.2.4.tar.gz.asc"
- Unfortunately, "pip" does not (yet) automatically verify the signature, so users will have to verify it with a: "gpg --verify cephadm-17.2.4-py3-none-any.whl.asc cephadm-17.2.4-py3-none-any.whl"
Hope it helps!
Kind Regards,
ErnestoOn Wed, Sep 28, 2022 at 4:18 PM John Mulligan <phlogistonjohn@xxxxxxxxxxxxx> wrote:
(Sending again from my list-subscribed address -- apologies for any
duplicates.)
On Tuesday, September 27, 2022 6:56:22 PM EDT Dan Mick wrote:
> For some time now, the cephadm "binary" (executable program) has been
> being processed specially (extracted from the build packages) and the
> resultant single file has been placed in the "build artifacts" directory
> of packages:
>
> https://github.com/ceph/ceph-build/pull/1913
> and followon bugfix in
> https://github.com/ceph/ceph-build/pull/1919
>
> The intent was to have a build-specific place for the appropriate
> cephadm for testing, but also to have a stable place in the release
> repositories for the unpackaged binary.
Excellent, thanks. It helps to understand where the files in those download
directories are coming from.
>
> This seems to be working for final rpm releases:
>
> http://download.ceph.com/rpm-17.2.3/el8/noarch/cephadm
>
> and development rpm releases:
>
> https://3.chacra.ceph.com/r/ceph/wip-yuri4-testing-2022-09-27-1405/cee7690a0
> a431bd223254670505200901fccbd16/centos/9/flavors/default/noarch/cephadm
>
Thanks a bunch for that link - since there's no "reef" or "main" at
download.ceph.com I wasn't sure where to look for recent stuff.
I can confirm that file is a python zipapp. One thing that could be an issue is
that the shebang in the file doesn't look as I expect it to... but that's
something for us to investigate independently.
> but not for deb releases:
>
> http://download.ceph.com/debian-17.2.3/pool/main/c/ceph/
>
> https://4.chacra.ceph.com/r/ceph/wip-yuri4-testing-2022-09-27-1405/cee7690a0
> a431bd223254670505200901fccbd16/ubuntu/jammy/flavors/default/pool/main/c/cep
> h/
>
> so something further apparently needs to be done to the deb repo build.
> The hope was that, if anything about the build process ever evolved
> (like, say, making the cephadm file a zipfile instead of a Python script
>
As noted above it "just worked" for the RPM version. I'm not sure how to start
debugging it... if you would be so kind to help us (me) start debugging it I'd
really appreciate it.
> :)), this process would be immune to such changes. But we never
>
> finished getting the documentation/recommended practice updated.
>
Please let us know how we can help with this as well.
One concern I have with the "extract cephadm from packages" approach, beyond
technical stuff like shebangs, is that the existing user workflow is not
distribution specific. The user could be on ubuntu, or fedora, or centos, etc
and follow the same flow. I wonder if we could also create a download URL
(redirect?) that as not distro specific?
> On 9/27/2022 11:22 AM, John Mulligan wrote:
> > Hi all,
> >
> > As some of you are already aware the orchestration team is working on
> > refactoring the cephadm command line tool [1]. The first part of the
> > effort: building cephadm from source files into a consumable "binary" has
> > been done.
> >
> > When we last discussed the effort in the CLT call a couple of points came
> > up. First, the current instructions for bootstrapping a system with
> > cephadm recommends downloading a script directly from github [2] (see
> > "CURL-Based Installation"). We'd like to keep the general workflow but
> > would need a new download location for it. Following that, there was a
> > suggestion that artifacts that are built and provided by the Ceph project
> > should be signed.
> >
> > In order to proceed with the cephadm effort we're reaching out for help on
> > getting these tasks done. This is something we need assistance from those
> > more knowledgeable about the build and website infrastructure. I posted a
> > work-in- progress PR [3] that starts making related changes to the
> > documentation, but can't complete it until we have a more concrete plan
> > on where people can download (and verify) their bootstrap copy of
> > cephadm.
> >
> > Anyone who has pointers to who are the best team members to follow up with
> > this effort - please let us know!
> >
> > Thank you.
> >
> > -- John Mulligan (on behalf of the Ceph Orchestration team )
> >
> > [1] - https://pad.ceph.com/p/cephadm-refactoring
> > [2] - https://docs.ceph.com/en/latest/cephadm/install/
> > [3] - https://github.com/ceph/ceph/pull/48180
> >
> >
> >
> > _______________________________________________
> > Dev mailing list -- dev@xxxxxxx
> > To unsubscribe send an email to dev-leave@xxxxxxx
>
> _______________________________________________
> Dev mailing list -- dev@xxxxxxx
> To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
