[Pulp-dev] fedorapeople.org fixtures

2020-04-28 Thread David Davis
Our Jenkins jobs for Pulp 2 are disabled and that also includes the job that builds the fixtures and publishes them to fedorapeople.org[0]. With the new pulp-fixtures container[1], it's less essential that we have fixtures published somewhere. I think the two options we have are to either retire

Re: [Pulp-dev] Export-by-repositoryversion : design thinking needed!

2020-04-28 Thread David Davis
David On Mon, Apr 27, 2020 at 3:16 PM Grant Gainey wrote: > Discussions with Katello uncovered a use-case that we thought about > briefly in the initial design of import/export, and then put aside to get > to first-light. That issue is "must be able to export a specific set of >

Re: [Pulp-dev] the "relative path" problem

2020-04-28 Thread David Davis
Yes, that's correct. During our meeting we discussed two options: the first was to extend RepositoryContent to store relative path per ContentArtifact as storing a relative_path per Content won't work for multi-Artifact Content units. An alternative that I pitched was to have plugins (or maybe

Re: [Pulp-dev] pulp_file 1.0

2020-04-28 Thread David Davis
It seemed like we were all in agreement so I went ahead and merged https://github.com/pulp/pulp_file/pull/380. Thanks to everyone for the feedback. David On Mon, Apr 27, 2020 at 9:13 AM Daniel Alley wrote: > +1 to 1.0 > > On Mon, Apr 27, 2020 at 5:57 AM Ina Panova wrote: > >> Based on the

Re: [Pulp-dev] the "relative path" problem

2020-04-28 Thread Matthias Dellweg
That is only used for passthrough publication afaik. If you publish each content unit "by hand", you create a new relative path for each published artifact. That is, why it can be empty and still the content can be published. On Tue, Apr 28, 2020 at 4:09 PM Daniel Alley wrote: > We realized in

Re: [Pulp-dev] the "relative path" problem

2020-04-28 Thread Daniel Alley
We realized in our discussion that the original proposal described in my email will not work, because "relative_path" ultimately describes the path of the published *artifacts* (not content), and for content types with multiple artifacts, storing this information in a field on RepositoryContent

Re: [Pulp-dev] Pulp 3 CLI MVP

2020-04-28 Thread David Davis
I've also started working on some questions about how the CLI will work. Feel free to add some of your own: https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig?view#Technical-discussion David On Tue, Apr 28, 2020 at 8:05 AM David Davis wrote: > I have set up a meeting to discuss the CLI technical

Re: [Pulp-dev] Pulp 3 CLI MVP

2020-04-28 Thread David Davis
I have set up a meeting to discuss the CLI technical design. Below are the details. I think a video conference might be easier for technical discussion but am open to consider meeting on #pulp-meeting again. URL: https://meet.google.com/vgx-bzbb-wnh Date/time: April 30, 2020 at 9:00am ET (1pm