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

2020-04-27 Thread Daniel Alley
There is a video call scheduled to discuss this issue tomorrow (Tuesday April 28th) at 13:30 UTC (please convert to your local time). https://meet.google.com/scy-csbx-qiu On Sat, Apr 25, 2020 at 7:02 AM David Davis wrote: > I had a chance to think about this some more yesterday and wanted to

Re: [Pulp-dev] redmine process for katello-integration-related issues

2020-04-27 Thread Grant Gainey
On Mon, Apr 27, 2020 at 3:08 PM Brian Bouterse wrote: > On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey wrote: > >> >> Sooo, how about the following for YARP (Yet Another Redmine Process): >> >>- Anything with a katello-PX tag, gets a *Katello* tag >>- Open issues with a Katello-P1 tag,

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

2020-04-27 Thread Grant Gainey
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 RepositoryVersions for the specified Repositories" (as opposed to "export

Re: [Pulp-dev] redmine process for katello-integration-related issues

2020-04-27 Thread Brian Bouterse
On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey wrote: > Once more unto the breach, dear friends, once more... > > When last we saw our process, we were at something like this: > > On Thu, Apr 23, 2020 at 8:12 AM Grant Gainey wrote: > >> OK, so let's take a step back. The thing that the initial

Re: [Pulp-dev] redmine process for katello-integration-related issues

2020-04-27 Thread Grant Gainey
Once more unto the breach, dear friends, once more... When last we saw our process, we were at something like this: On Thu, Apr 23, 2020 at 8:12 AM Grant Gainey wrote: > OK, so let's take a step back. The thing that the initial proposal is/was > attempting to address is that with the current

[Pulp-dev] unit test runners disabled for Pulp 2 repositories

2020-04-27 Thread Dennis Kliban
Due to challenges with maintaining infrastructure used to run unit tests for Pulp 2 Pull Requests on GitHub, I've disabled the requirement for these checks to pass before merging. I do not anticipate any challenges with manually testing PRs due to the low volume of changes in those repos.

[Pulp-dev] Certguard compatibility with Centos/RHEL7

2020-04-27 Thread Brian Bouterse
Here's a recap of a plan between @jsherrill @sajha @ehelms and myself around adding a feature to certguard that will provide compatibility with Apache 2.6.4. Currently certguard is compatible only with Apache 2.6.10+. Below is a summary of the plan. * pulp_certguard to introduce compatibility

Re: [Pulp-dev] pulp_file 1.0

2020-04-27 Thread Daniel Alley
+1 to 1.0 On Mon, Apr 27, 2020 at 5:57 AM Ina Panova wrote: > Based on the extended reply from David referring to semver, I am in favour > or releasing pulp_file 1.0. > > Also, comments inline. > > Regards, > > Ina Panova > Senior Software Engineer| Pulp| Red Hat Inc. > > "Do not go

Re: [Pulp-dev] serializers in pulp 3 can't use write_only fields

2020-04-27 Thread Daniel Alley
I just want to point out that we have a somewhat similar kind of feature implemented, "minimal serializers", which uses the 2-serializer approach. It is a very tiny amount of extra code/work. e.g. https://github.com/pulp/pulpcore/blob/master/pulpcore/app/serializers/task.py#L119

Re: [Pulp-dev] pulp_file 1.0

2020-04-27 Thread Ina Panova
Based on the extended reply from David referring to semver, I am in favour or releasing pulp_file 1.0. Also, comments inline. Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On

Re: [Pulp-dev] serializers in pulp 3 can't use write_only fields

2020-04-27 Thread Ina Panova
I like option number 2 more, even if there is more work behind the scene it is more explicit and does not leave opened questions like ' why certain fields are null' Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where