Re: [Pulp-dev] [Pulp-list] Github Discussions
On Wed, Jun 16, 2021 at 7:21 PM David Davis wrote: > > One of the main reasons we wanted to move off mailing lists is that signing > up is inconvenient for users that may just want to ask a single question. But > I agree that Github Discussions is not so great if users want to periodically > monitor news and discussions for a project like Pulp. I wonder perhaps if > Discourse[0] would be a better fit (see Foreman's use of discourse as an > example[1]). It provides a mailing list mode that users can enable if they > want to interact solely via email. And also, it also offers more granular > control of notifications and auth with services like Github. > The Fedora mailing list system (HyperKitty) actually manages to strike a good balance here. You can sign in with OIDC/Social Login with Fedora, Google, etc. and post to a list and only be subscribed to that thread. Or you can subscribe to the whole list and do things like we do now. > One of the main concerns we've had around using Discourse is hosting it > ourselves but it does look like Discourse provides a free plan for open > source projects[2]. It has some limitations (not sure if they'd be an issue > for us?) but I've submitted an application to see if we qualify. I should > hear back in a couple days. > I suspect not, but it'd be an interesting surprise if we qualified. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] [Pulp-list] Github Discussions
Well, let's see if that works. Another concern I have is about filtering stuff from discussions in Gmail. It's pretty hard to do filtering of GitHub mail... On Wed, Jun 16, 2021 at 4:29 PM David Davis wrote: > > If you watch the repo, you should be able to get notifications when there's > new activity? > > David > > > On Wed, Jun 16, 2021 at 3:13 PM Neal Gompa wrote: >> >> On Wed, Jun 16, 2021 at 11:59 AM David Davis wrote: >> > >> > Yesterday at open floor, we discussed decommissioning pulp-dev list in >> > favor of of using Github Discussions[0] for developer discussions. >> > >> > If there are no objections, I plan to decommission the pulp-dev list next >> > week. >> > >> > [0] https://github.com/pulp/community/discussions >> > >> >> I don't know how I'd be able to keep track of what's going on with >> GitHub Discussions. With mailing list discussions, it's relatively >> easy for me to see the topics as they're coming in and participate off >> the cuff. With GitHub Discussions, it doesn't seem possible for me to >> do that. >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] [Pulp-list] Github Discussions
On Wed, Jun 16, 2021 at 11:59 AM David Davis wrote: > > Yesterday at open floor, we discussed decommissioning pulp-dev list in favor > of of using Github Discussions[0] for developer discussions. > > If there are no objections, I plan to decommission the pulp-dev list next > week. > > [0] https://github.com/pulp/community/discussions > I don't know how I'd be able to keep track of what's going on with GitHub Discussions. With mailing list discussions, it's relatively easy for me to see the topics as they're coming in and participate off the cuff. With GitHub Discussions, it doesn't seem possible for me to do that. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] pulpcore team meeting notes - May 25, 2021
Brian, That's awesome! I'll also note that a variation of this workflow would be desired for mirrors too, such as mirroring distributions or prominent third-party repos (EPEL, Packman, COPRs, OBS repos, etc.). On Thu, Jun 3, 2021 at 11:11 AM Brian Bouterse wrote: > > Thank you for sharing this use case outline with me. I am hoping we can > prioritize rbac work like this. It's very important. > > On Wed, Jun 2, 2021 at 11:35 AM Neal Gompa wrote: >> >> Hey Brian, >> >> Yes, for sure! I'm basically looking into using RBAC to support a >> workflow like so: >> >> * Automation via a service account imports RPMs and DEBs into a pool >> * Automation via another service account selects those packages to >> publish into various staging repos >> * Select users/groups can promote those packages to their assigned >> "stable" repos >> >> The idea is that I can partition ACLs for various functions of Pulp to >> prevent unwanted actions. >> >> >> On Wed, Jun 2, 2021 at 10:56 AM Brian Bouterse wrote: >> > >> > Hi Neal, >> > >> > Apologies for the late reply. We've added the RBAC to various endpoints in >> > pulpcore and some plugins, but what I think would be helpful is if we had >> > a way to more clearly identify what has RBAC and what doesn't across >> > pulpcore and plugins. Would that be helpful? >> > >> > Thank you, >> > Brian >> > >> > >> > On Tue, May 25, 2021 at 11:46 AM Neal Gompa wrote: >> >> >> >> On Tue, May 25, 2021 at 11:23 AM Brian Bouterse >> >> wrote: >> >> > >> >> > * Making top-level Authentication page in docs >> >> > * https://pulp.plan.io/issues/8799 >> >> >> >> The docs currently mention that RBAC stuff is planned, is there >> >> something that shows the status of that? This is something that I'd >> >> love to see in Pulp sooner rather than later... >> >> >> >> >> >> -- >> >> 真実はいつも一つ！/ Always, there's only one truth! >> >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] pulpcore team meeting notes - May 25, 2021
Hey Brian, Yes, for sure! I'm basically looking into using RBAC to support a workflow like so: * Automation via a service account imports RPMs and DEBs into a pool * Automation via another service account selects those packages to publish into various staging repos * Select users/groups can promote those packages to their assigned "stable" repos The idea is that I can partition ACLs for various functions of Pulp to prevent unwanted actions. On Wed, Jun 2, 2021 at 10:56 AM Brian Bouterse wrote: > > Hi Neal, > > Apologies for the late reply. We've added the RBAC to various endpoints in > pulpcore and some plugins, but what I think would be helpful is if we had a > way to more clearly identify what has RBAC and what doesn't across pulpcore > and plugins. Would that be helpful? > > Thank you, > Brian > > > On Tue, May 25, 2021 at 11:46 AM Neal Gompa wrote: >> >> On Tue, May 25, 2021 at 11:23 AM Brian Bouterse wrote: >> > >> > * Making top-level Authentication page in docs >> > * https://pulp.plan.io/issues/8799 >> >> The docs currently mention that RBAC stuff is planned, is there >> something that shows the status of that? This is something that I'd >> love to see in Pulp sooner rather than later... >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] pulpcore team meeting notes - May 25, 2021
On Tue, May 25, 2021 at 11:23 AM Brian Bouterse wrote: > > * Making top-level Authentication page in docs > * https://pulp.plan.io/issues/8799 The docs currently mention that RBAC stuff is planned, is there something that shows the status of that? This is something that I'd love to see in Pulp sooner rather than later... -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Removing MD5 and SHA-1 as default available checksums in 3.11
On Thu, Mar 11, 2021 at 3:31 AM Matthias Dellweg wrote: > > > > On Thu, Mar 11, 2021 at 9:13 AM Neal Gompa wrote: >> >> On Wed, Mar 10, 2021 at 10:20 PM Brian Bouterse wrote: >> > >> > Thanks Quirin for the questions. I put my understanding and >> > recommendations inline. Other devs please share your perspectives and >> > advice, especially if they differ from what is written here. More >> > questions and discussion are welcome. This is complicated stuff, but we >> > want to be here to help. >> > >> > On Wed, Mar 10, 2021 at 11:40 AM Quirin Pamp wrote: >> >> >> >> To summarize: I am uncertain how best to proceed, but perhaps I am >> >> overthinking this and simply respecting ALLOWED_CONTENT_CHECKSUMS and >> >> letting users decide is best. >> > >> > The question I'll ask to help answer yours is: how much does pulp_deb >> > break with 3.11's defaults? This would be good to know. Want to run a few >> > tests and let us know? Maybe we can help give more info with that. >> > >> > Aside from that, my general advice is to expect that pulp_deb users will >> > change this setting, and to have the pulp_deb code work with the checksums >> > it has available and error when it cannot fulfill their request due to not >> > having the checksums it would need to do so. >> >> There is one difference between the RPM ecosystem and the Debian >> ecosystem here. APT will absolutely choke on a repository if MD5 is >> missing, even if it won't use it for "integrity". Various aspects of the >> Debian >> ecosystem still use MD5 because it's the only guaranteed algorithm. >> >> Two major points where it's still mandatory: >> >> * Debian Source Control files and repodata generated for "sources". >> The dsc file (ex. rpm[1]) uses MD5 for *file list*, and that's *not* >> optional. There *are* extra Checksums sections that you're supposed to >> use for integrity verification, but they are technically optional, and >> the only *guaranteed* algorithm is MD5, which is used for the Files >> section. >> >> * Debian InRelease and other repodata index files. The InRelease file >> (ex. Ubuntu 20.04[2]) *guarantees* MD5Sums (note capital "S") for the >> file list, and while the current advice is that clients *must* also >> request a SHA2 algorithm to verify the integrity of the files, the >> first section using MD5 *must* be present or the repodata is invalid. >> >> The repository format wiki page[3] somewhat details this (though being >> a wiki page, it's as inconsistent as any other wiki page, yay?). > > > Reading this section from the Wiki page you mention, I understand that > everything but SHA256 is indeed optional in the Release file (and i assume > the InRelease file too). > > Servers shall provide the InRelease file, and might provide a Release files > and its signed counterparts with at least the following keys: > > Suite and/or Codename > Architectures > Components > Date > SHA256 > > Still having a unsigned Release file and MD5Sum is currently highly > recommended. Unsigned Release is probably the only truly optional part (and that's needed for pre-2016 APT versions), but in practice, I haven't been able to leave out MD5Sum from APT repository metadata without breaking clients. Admittedly, I haven't tried recently (as in not in the last couple of years, the last time I tried was in the Ubuntu 17.04 timeframe). -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Removing MD5 and SHA-1 as default available checksums in 3.11
On Wed, Mar 10, 2021 at 10:20 PM Brian Bouterse wrote: > > Thanks Quirin for the questions. I put my understanding and recommendations > inline. Other devs please share your perspectives and advice, especially if > they differ from what is written here. More questions and discussion are > welcome. This is complicated stuff, but we want to be here to help. > > On Wed, Mar 10, 2021 at 11:40 AM Quirin Pamp wrote: >> >> To summarize: I am uncertain how best to proceed, but perhaps I am >> overthinking this and simply respecting ALLOWED_CONTENT_CHECKSUMS and >> letting users decide is best. > > The question I'll ask to help answer yours is: how much does pulp_deb break > with 3.11's defaults? This would be good to know. Want to run a few tests and > let us know? Maybe we can help give more info with that. > > Aside from that, my general advice is to expect that pulp_deb users will > change this setting, and to have the pulp_deb code work with the checksums it > has available and error when it cannot fulfill their request due to not > having the checksums it would need to do so. There is one difference between the RPM ecosystem and the Debian ecosystem here. APT will absolutely choke on a repository if MD5 is missing, even if it won't use it for "integrity". Various aspects of the Debian ecosystem still use MD5 because it's the only guaranteed algorithm. Two major points where it's still mandatory: * Debian Source Control files and repodata generated for "sources". The dsc file (ex. rpm[1]) uses MD5 for *file list*, and that's *not* optional. There *are* extra Checksums sections that you're supposed to use for integrity verification, but they are technically optional, and the only *guaranteed* algorithm is MD5, which is used for the Files section. * Debian InRelease and other repodata index files. The InRelease file (ex. Ubuntu 20.04[2]) *guarantees* MD5Sums (note capital "S") for the file list, and while the current advice is that clients *must* also request a SHA2 algorithm to verify the integrity of the files, the first section using MD5 *must* be present or the repodata is invalid. The repository format wiki page[3] somewhat details this (though being a wiki page, it's as inconsistent as any other wiki page, yay?). Probably the correct thing to do here is to make it possible to propagate the correct error information up so that users can be informed about missing algorithms and *why* so they can enable it. And if any installer is going to do Pulp with Debian, they also can't ask for weak algorithms to be disabled. [1]: http://archive.ubuntu.com/ubuntu/pool/universe/r/rpm/rpm_4.14.2.1+dfsg1-1build2.dsc [2]: http://archive.ubuntu.com/ubuntu/dists/focal/InRelease [3]: https://wiki.debian.org/DebianRepository/Format -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] [Pulp-list] Removing MD5 and SHA-1 as default available checksums in 3.11
On Sun, Feb 14, 2021 at 9:22 PM Daniel Alley wrote: >> >> RPM and Migration plugin users will need to add this back in at 3.11 upgrade >> time for your systems to continue working. > > > Just to clarify, this only applies if you are using RPM repositories that use > MD5 or SHA1 checksums. None of the Red Hat or CentOS repositories for RHEL / > CentOS 8 do, and only a couple of the RHEL / CentOS 7 repositories do, mosty > the smaller and less used ones. > > MD5 can be left disabled unless you are managing extremely old or > misconfigured repositories. > SHA1 is required for SLE 11 and RHEL 5, as neither can process SHA2-based checksums. While RHEL 5 is firmly EOL, SLE 11 is still supported for two more years for SUSE customers using LTSS for SLE 11 SP4. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Travis pricing
On Tue, Nov 3, 2020 at 3:35 PM David Davis wrote: > > Travis recently announced changes to their plan pricing that will impact > open-source projects such as Pulp[0]. It's likely that we'll exhaust the > monthly budget that Travis is going to give OSS projects and we're not sure > how generous Travis will be giving out extra build minutes. > > Given our concern, members of the CI team met today to discuss our options. > We have some notes[1] from our meeting about some of the options that stood > out to us. We'd like to have a plan in place when the new pricing gets rolled > out to our organization. > > Any feedback is welcome. > > [0] https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing > [1] https://hackmd.io/n6kStnNiTPGekAWGdNvbhA Could we use the Fedora CI Zuul instance[2]? There's already a ton of other projects using one of the Zuul instances on softwarefactory-project.io, and leveraging the Fedora CI infrastructure could also help future efforts in doing auto-release to Fedora for Pulp releases, too. [2]: https://fedora.softwarefactory-project.io/zuul/projects -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulpcon is live!
There seems to be no video besides a mouse pointer...? On Mon, Sep 14, 2020 at 9:33 AM Melanie Corr wrote: > Hi Neal, > > We learned quite late the stream URL is restricted. > We are streaming here: https://www.youtube.com/watch?v=_hxjqAD8hEI > <https://meet.google.com/linkredirect?authuser=0=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D_hxjqAD8hEI> > Will fix the video soon. > You are very welcome to join the meeting rather than the stream. > > Melanie > > Ar Luan 14 MFómh 2020 ag 14:27, scríobh Neal Gompa : > >> On Mon, Sep 14, 2020 at 8:20 AM Fabricio Aguiar < >> fabricio.agu...@redhat.com> wrote: >> >>> Hey everyone, >>> >>> PulpCon is live! >>> >>> *Streaming:* >>> >>> https://stream.meet.google.com/stream/a763e128-14b0-4f31-964f-74bed0a43e8a >>> >>> *Schedule:* >>> https://hackmd.io/@pulp/pulpcon2020_schedule >>> >>> >> I don't seem to be able to access the stream...? >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > > > -- > > Melanie Corr, RHCE > > Community Manager > > Red Hat <https://www.redhat.com> > > Remote, Ireland > > mc...@redhat.com > M: +353857774436 IM: mcorr > <https://www.redhat.com> > > -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulpcon is live!
On Mon, Sep 14, 2020 at 8:20 AM Fabricio Aguiar wrote: > Hey everyone, > > PulpCon is live! > > *Streaming:* > https://stream.meet.google.com/stream/a763e128-14b0-4f31-964f-74bed0a43e8a > > *Schedule:* > https://hackmd.io/@pulp/pulpcon2020_schedule > > I don't seem to be able to access the stream...? -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Should signing service be associated with Publication or Repository?
On Thu, Mar 19, 2020 at 11:14 PM Dennis Kliban wrote: > > RPM plugin allows users to define a signing service per repository. All > publications created from repository versions of that repository are signed > with that signing service. > > The Debian plugin requires the user to specify the signing service each time > a publication is created. The signing service foreign key is stored with each > publication. > > Even though the implementation in Debian requires the user to provide the > service href each time a publication is created, it seems like a stronger > model. The signing service associated with a repository can change thus > making it challenging to keep track of which signing service was used to > create a publication. > > We should change the behavior in the RPM plugin before we release this > feature. Isn't the reason for the difference that Debian repos only have repodata signed and not packages? I guess technically we could use different GPG keys for each repository publish, but that would lead to multiple copies of the same RPM with different data, since the expectation is that both RPMs and the repodata should be signed for RPM repositories. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp3 Applicability Design thoughts (and Katello)
On Fri, Jan 17, 2020 at 10:16 AM David Davis wrote: > > Neal, > > Thanks for the feedback. Any idea if Cobbler or Pulp users would be > interested in applicability[0] being part of Pulp 3? One of the big changes > in Pulp 3 is that Pulp no longer maintains content consumer information so > we're debating about also dropping applicability from Pulp as well. > Cobbler[1] is used exclusively for provisioning systems, so I don't think it would matter that much. Uyuni[2] (which is a fork of Spacewalk that is actively developed and maintained) would have the same usage model as Satellite/Foreman+Katello. I'm not exactly sure what Foreman+Katello's requirements are from Pulp, but Spacewalk/Uyuni would have the same ones, since it serves the same function. [1]: http://cobbler.github.io/ [2]: https://www.uyuni-project.org/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp3 Applicability Design thoughts (and Katello)
On Fri, Jan 17, 2020 at 8:31 AM Justin Sherrill wrote: > > There have been some design discussions going on around applicability > (https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A) in pulp3. > > There are some big changes compared to pulp2, including: > > * Package profile, module profile,and repository list have to be > uploaded on every applicability computation > > * Calls for applicability are not asynchronous (which makes sense as > they are one profile at a time). > > Also keep in mind that due to the complexity of all the information > needed, Katello has been the primary (and sometimes the only?) user of > the service. > > For an example of what this might looks like, consider a repository that > syncs some new packages. For 10,000 clients, it has to send the full > package profiles for all 10,000 clients, as well as the other > information in 10,000 api calls. In Addition our task workers will have > to wait around for all 10,000 clients to be calculated. One last point > is that katello already knows all the NVREA's for the rpms, which rpms > are in which repositories, which artifacts are in which modules, and > which packages are in what errata. > > Given all this, does it make sense for pulp to calculate the > applicability? Or does it make sense for katello to? > > This assumes that no one else wants to use applicability in pulp3 (and > given the barrier to entry is even higher than it was in pulp2, that may > be possible). > The Cobbler team is interested in integrating with Pulp 3, though no investigation or work on this has started yet. I've also had a couple of conversations about it with the Uyuni developers, too. The biggest hangup previously for integrating Pulp into other tools is the MongoDB dependency that nobody wanted to deal with. Now that is gone, it has started looking interesting to people again. This is also part of the reason why I'd like to see the Pulp 3 stack shipped in Fedora. It would make it much easier for people to use it and explore integrating their infrastructure with it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] RPM plugin meeting notes
On Thu, Nov 7, 2019 at 3:48 PM Tatiana Tereshchenko wrote: > > Advisory > > Opensuse advisory > > some fields differs (reboot_suggested != restart_suggested) > These are not the same fields. The restart_suggested field indicates that the update tool should restart itself after this update is applied and continue onward. SUSE updateinfo uses both fields. Cf. https://en.opensuse.org/openSUSE:Standards_Rpm_Metadata_UpdateInfo#restart_suggested > AI: convince createrepo_c team to support suse fields :) > Is there something in createrepo_c that prevents the extra fields from working? This is the first time I'm hearing of it, as the SUSE guys have been using createrepo_c for a while now in their build system... -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Proposal to move Pulp 2 dev environment to CentOS
On Wed, Jul 24, 2019, 11:40 AM Daniel Alley wrote: > Proposal: The pulp/devel repository will install a CentOS 7 base box > instead of a Fedora 28 one > > Rationale: > > * CentOS / RHEL is what our users are using. Using a different platform > can result in different behavior in the development environment vs what > users see -- this happened to me recently and wasted a couple of hours on > both the Dev and QE sides > * Fedora 28 is EOL and no longer receiving updates > * Pulp 2 the custom dev installation script (pulp-dev.py) is broken on > Fedora 29+ and I deemed it probably not worth the time or effort to fix > * The RPM plugin is also broken on Fedora 29+ -- legacy "createrepo" was > obsoleted entirely and as far as I can tell you can't import some of the > libraries we are using from that package anymore > * There's little point in tracking fast-moving Fedora changes at this > point in Pulp 2's lifecycle anyways > > I have a branch that already works on CentOS. It's a few patches behind > but would take about 5 minutes to get cleaned up. > > Any objections? > This sounds good to me. I hope we are still developing and testing on Fedora for Pulp 3, though? ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] black
On Thu, Jun 27, 2019 at 7:59 AM David Davis wrote: > Follow up question to adding support for black: should we drop flake8? We > shouldn't need it anymore since black is pep8 compliant but I'm happy to > keep it around at least temporarily if people prefer? > Drop it. It's redundant and annoying anyway. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Python 3.6 will be formally included in RHEL 7.7
On Thu, Jun 6, 2019 at 10:08 AM Mike DePaulo wrote: > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/new_features#enhancement_compiler-and-tools > > This means that once RHEL 7.7 & CentOS 7.7 come out, the lack of an EPEL7 > python3-createrepo_c package for Pulp 3's pulp_rpm should be a lot easier to > address. We'll simply work with the maintainers on an update for EPEL7's > createrepo_c package, so that it includes the python3-createrepo_c subpackage. > Isn't createrepo_c in RHEL Extras now? If it is, then it'll be removed from EPEL, and you'll need to take it up with RHEL to get that fixed. :( -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3 Default Ports
On Wed, Mar 6, 2019 at 10:05 AM Neal Gompa wrote: > > On Wed, Mar 6, 2019 at 10:01 AM Eric Helms wrote: > > > > For most Pulp 3 installations, it seems there are two default applications > > that will be running: API and content. Those applications are set to run on > > 8000 and 8080 respectively. I was thinking that it might be more obvious > > for operators and developers to have the defaults next to each other in > > order to make it more predictable and easier to remember. Ultimately, these > > ports should be configurable for different environments, but sane easy to > > remember defaults have their value. > > > > My suggestion is: 8080 (API) and 8081 (content). > > > > I would suggest not using any standard HTTP auxiliary ports by > default. Is there a compelling reason to do so? > Welp, this isn't clear enough. I mean that the ports should be unique to Pulp rather than something that could be construed as something that would unknowingly conflict. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3 Default Ports
On Wed, Mar 6, 2019 at 10:01 AM Eric Helms wrote: > > For most Pulp 3 installations, it seems there are two default applications > that will be running: API and content. Those applications are set to run on > 8000 and 8080 respectively. I was thinking that it might be more obvious for > operators and developers to have the defaults next to each other in order to > make it more predictable and easier to remember. Ultimately, these ports > should be configurable for different environments, but sane easy to remember > defaults have their value. > > My suggestion is: 8080 (API) and 8081 (content). > I would suggest not using any standard HTTP auxiliary ports by default. Is there a compelling reason to do so? -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3 for Fedora
On Tue, Feb 12, 2019 at 1:53 PM Patrick Creech wrote: > > On Tue, 2019-02-12 at 12:03 -0500, Neal Gompa wrote: > > On Tue, Feb 12, 2019 at 11:55 AM Brian Bouterse wrote: > > > This identifies that packaging Pulp into Fedora is valuable. Thank you > > > for that. I've got a few questions to help us > > > get there. > > > > > > What is the recommendation for where to keep the spec files for these > > > items? Is it directly in the Fedora infra? The > > > Pulp upstream repos aren't supposed to contain packaging bits anymore is > > > my understanding. > > > > > > > Spec files and other packaging specific data *must* reside in Fedora > > Dist-Git: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity > > > > Spec files in upstream repos is up to the upstream, but Fedora > > infrastructure cannot access them and cannot rely on them. > > I'm not quite ready to wade into the broader conversation yet.. > > But to clarify on this one point: > > Upstream can create a one size fits all spec file that conforms to fedora's > policies, and a copy of said spec file will > need to be commited to fedora's dist git and the package in fedora will be > built from that dist git location. > > To ease maintenance in this case, this keeps upstream from having to manage > separate spec files in multiple locations. > When an update in fedora is needed, the spec file can be copied mostly as-is, > iirc. > > There are other projects that do such, immediately my mind thinks of the > candlepin team's subman work. > > The DNF stack, Spacewalk clients, and snapd package maintenance works in a similar manner to what you described. But it shouldn't be a big deal. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3 for Fedora
On Tue, Feb 12, 2019 at 11:55 AM Brian Bouterse wrote: > > This identifies that packaging Pulp into Fedora is valuable. Thank you for > that. I've got a few questions to help us get there. > > What is the recommendation for where to keep the spec files for these items? > Is it directly in the Fedora infra? The Pulp upstream repos aren't supposed > to contain packaging bits anymore is my understanding. > Spec files and other packaging specific data *must* reside in Fedora Dist-Git: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity Spec files in upstream repos is up to the upstream, but Fedora infrastructure cannot access them and cannot rely on them. > What is the Fedora policy on distributing pre-release software like release > candidates for a new major release? Is it OK that pulpcore be at RC2 for > example? Feel free to link me to docs too. > It's really up to the maintainers and how they feel about the quality of the software. Betas or RCs are fine in my book if they work reasonably well. They can be updated to final as a post-GA update. Unlike a lot of distributions, Fedora makes it pretty easy to ship updates throughout the life of a distribution release, so it's not really that much of a worry. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3 for Fedora
On Mon, Feb 11, 2019 at 3:15 PM David Davis wrote: > > Neal, > > I completely agree with the points you brought up and would love to see Pulp > 3 shipped in Fedora. The only thing I am hesitant about is the timing. Fedora > 30 is shipping in May, correct? We’re approaching an RC for Pulp’s core but > none of the plugins are really ready. I think releasing Pulp for Fedora 31 in > the fall might be more feasible but maybe we can re-evaluate in March. > If things are in a usable state, there's no reason not to start the packaging work and go through the package review process[1]. That lets us sort out issues early and get them addressed in time for integration into the distribution. Failing that, there could be a COPR[2] for it if it doesn't fully make it. [1]: https://fedoraproject.org/wiki/Package_Review_Process [2]: https://copr.fedorainfracloud.org/ > Also, I’d love to talk more about integrating Pulp into's Fedora > infrastructure. I joined the Pulp team a couple years ago and have been > constantly wondering why Fedora is not using Pulp to manage and distribute > its RPMs. Maybe at some point we can give you a demo of Pulp 3 and figure out > how we can help fill Fedora’s needs. > I know that previously Pulp was considered for at least hosting the container images[3]. I'm not sure what happened there. It'd be a good idea to introduce yourself to releng[4] and infrastructure[5] folks and propose the idea. [3]: https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service [4]: https://lists.fedoraproject.org/archives/list/rel-...@lists.fedoraproject.org/ [5]: https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Pulp 3 for Fedora
Hello all, I wanted to ask about having Pulp 3 land in Fedora. We've had Pulp 2 in the distribution for several releases now (it was dropped in Fedora 28~29). The new Pulp 3 stuff looks wicked cool and seems to be a vast improvement over Pulp 2. With MongoDB being dropped in Fedora 30[1], there's no longer an opportunity to run the current Pulp on Fedora. Moreover, Fedora has been aggressively moving to drop Python 2 components[2] and has done so for more than half of all Python components packaged in the distribution[3]. I had briefly discussed this with a few folks before, and they'd been under the impression that packaging for Fedora would be difficult. On the contrary, Python packaging in Fedora has never been easier! We now have the ability to auto-generate runtime dependencies[4] (which can also be activated on a per-spec basis in F28 and RHEL8) and an excellent tool for auto-generating the spec files for packaging Python software that is released to PyPI[5]. I would love to see Pulp reintroduced to Fedora now so that it could debut with the Fedora 30 release. It could also be interesting to see if we could leverage the new Pulp 3 in Fedora infrastructure for RPMs, OSTrees, and Docker containers in place of the hodgepodge of things we have now. I've heard good things about how Pulp 3 is developing, and I'd love to see it available on Fedora so I could use it there too. :) What do you all think? Best regards, Neal [1]: https://fedoraproject.org/wiki/Changes/MongoDB_Removal [2]: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal [3]: https://fedora.portingdb.xyz/ [4]: https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault [5]: https://github.com/fedora-python/pyp2rpm -- 真実はいつも一つ！/ Always, there's only one truth! ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
