Re: [Pulp-dev] creating repository version resources using a single REST endpoint

On Mon, Jan 8, 2018 at 2:36 PM, David Davis wrote: > How would REST API users discover the possible values for ‘operation’? I > guess we could put it in the help text for the field. > > I’m unsure of the value of having an operation param. I think I prefer the > idea of

Re: [Pulp-dev] creating repository version resources using a single REST endpoint

On Mon, Jan 8, 2018 at 2:39 PM, Austin Macdonald wrote: > I like the concept of single REST endpoint that is responsible for all the > ways to create a RepositoryVersion, but I don't quite understand how this > would work. Since the endpoint is purely pulpcore, how can the >

Re: [Pulp-dev] creating repository version resources using a single REST endpoint

How would REST API users discover the possible values for ‘operation’? I guess we could put it in the help text for the field. I’m unsure of the value of having an operation param. I think I prefer the idea of just having users supply importer or add/remove_content (but not both) or having two

Re: [Pulp-dev] creating repository version resources using a single REST endpoint

I like the concept of single REST endpoint that is responsible for all the ways to create a RepositoryVersion, but I don't quite understand how this would work. Since the endpoint is purely pulpcore, how can the RepositoryVersionViewSet import the plugin defined tasks that correspond to the action

Re: [Pulp-dev] Stop distributing gofer

On Mon, 2018-01-08 at 09:08 -0600, Jeff Ortel wrote: > > Thoughts? > Sounds good from a releng pov for upstream, with the caveat of what to do about EL5? We technically still have client bits published for that distro. signature.asc Description: This is a digitally signed message part

[Pulp-dev] creating repository version resources using a single REST endpoint

Enable users to POST to /api/v3/repositories/123abc456/versions/ with one required parameter 'operation'. This parameter would be an identifier for a task Pulp would run to create a new version. Any additional parameters passed in by the API user would be passed along to the task. pulpcore would

Re: [Pulp-dev] Github keywords

Even if we don't change this, It's something we should keep in mind since our PR #s are currently in a spot where they may frequently overlap with issue #s. At some point they'll diverge again and it won't be so much of an issue, but currently it is. I don't know precisely how the redmine

[Pulp-dev] 500 error during logrotate

Hi team, I'd like some input on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1512426 The httpd error log there shows what is wrong. I would have expected the request to indeed be handled gracefully but that doesn't seem to be the case. Interestingly, I wasn't able to reproduce the

[Pulp-dev] Github keywords

Today, I had a PR[0] that was accidentally closed by another PR[1]. The issue is that the format we’re using attach our commits to redmine issues (e.g. 'fixes #1234’) is the exact same format as what Github uses[2]. I’m wondering if we should change our format. I hate to do so but at the same

[Pulp-dev] Stop distributing gofer

The gofer package is distributed in Fedora and Copr[1] for EL6 & EL7.  Gofer is an external (to the project) dependency much like Celery.  I propose we stop distributing gofer and update our documentation to refer users to the existing sources. Thoughts? [1]