Re: [Pulp-dev] Questions around Pulp 3.0 RC release

On Wed, Sep 19, 2018 at 3:55 PM Dana Walker wrote: > I agree with Brian 100% that if we say something is officially supported, > we need to back that statement up, be that with Travis or some other level > of testing, or bugfix support, etc. > > Looking at the multi-os docs for Travis that Brian

Re: [Pulp-dev] Questions around Pulp 3.0 RC release

Containers are a possible solution to add more OS's to the matrix.[0] However, I think containers do not support SELinux. Then we will not be able to test any feature/issue related to SELinux. [0] https://docs.travis-ci.com/user/docker/ On Wed, Sep 19, 2018 at 3:55 PM, Dana Walker wrote: > I

[Pulp-dev] pulpcore 3.0.0b8 released

The following packages are now available on PyPI: - pulpcore 3.0.0b8 [0] - pulpcore-plugin 0.1.0b6 [1] Comprehensive list of changes and bugfixes for beta 7 can be found here[2]. Breaking changes include: * Dropped support for Python 3.5 [3] * Id field no longer returned by REST API

Re: [Pulp-dev] Questions around Pulp 3.0 RC release

What about Fedora? We use it in our development environment so I think I would feel comfortable claiming official support for it as well it’s not in our CI environment. Other than that, your proposal sounds good to me. David On Fri, Sep 14, 2018 at 12:02 PM Brian Bouterse wrote: > Here is

Re: [Pulp-dev] Stages API Performance Data Collection

On Mon, Sep 17, 2018 at 3:10 PM Dana Walker wrote: > I love this idea! Running benchmarks as we go will allow us to react > quickly if there are unforeseen performance pain points. > Sweet! > > Have you run anything similar to this proposal back in Pulp2 or > elsewhere? I'm a little concerned

Re: [Pulp-dev] Removing PublishedArtifact?

Thank you for all this feedback. I'm convinced that we should leave PublishedArtifact and PublishedMetadata as is w.r.t ticket #4020. I've revised it as such. For the plugin writer I'm working with, they do want to have the ContentArtifact.relative_path be the final repository layout. So now the

Re: [Pulp-dev] Removing PublishedArtifact?

What about the case where a plugin publishes a subset of content from the repo version? Then the content app might match something it’s not supposed to. I think @jortel mentioned having an option on the publication to pass through requests to the repo version if there’s no published artifact.

Re: [Pulp-dev] Removing PublishedArtifact?

I agree. +1. I revised the story to include the Publication attribute pass_through which is a Boolean and defaults to False, so the feature is disabled by default. Sound ok? https://pulp.plan.io/issues/4020 On Wed, Sep 19, 2018 at 2:04 PM David Davis wrote: > What about the case where a plugin

Re: [Pulp-dev] Stages API Performance Data Collection

Cool, thanks for the clarification. Sounds great. Dana Walker Associate Software Engineer Red Hat On Wed, Sep 19, 2018 at 1:04 PM, Brian Bouterse wrote: > > > On Mon, Sep 17, 2018 at 3:10 PM Dana Walker wrote: > >> I love this idea! Running

Re: [Pulp-dev] Questions around Pulp 3.0 RC release

I want to advocate we follow the policy even for Fedora. We can anecdotally say in the distribution docs that we use Fedora in our development environment and that we expect it to work there too. Without CI it's hard to know on an everyday basis which specific versions of a distribution are

Re: [Pulp-dev] Questions around Pulp 3.0 RC release

I agree with Brian 100% that if we say something is officially supported, we need to back that statement up, be that with Travis or some other level of testing, or bugfix support, etc. Looking at the multi-os docs for Travis that Brian linked to, it looks like it's only two options, Linux or OSX,