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

[Brian Bouterse]

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 linked to, it looks
> like it's only two options, Linux or OSX, and as he said Linux currently
> just means Ubuntu, and OSX may face some hurdles.
>
That is right, but what we could do is have Travis be a loading environment
for a docker container that is loaded from dockerhub. With that approach I
think we can test Fedoras, CentOS, and maybe even RHEL on Travis. I know
other people do this I can link to some examples if people want to look at
it more closely. I think this is one reason why Travis doesn't offer more
runtimes since you can get others through containers. OSX is special though
because it can't be containerized so they have to offer that one. RQ can't
run on Windows so we can't run there at all :(

I think we should explore putting ^ CI in place before we take Pulp3 after
the 3.0 RC but before the GA.


>
> Are there other forms of testing we would be willing and able to use to be
> able to officially back more OS's?  I'd really like to see more broad
> support.  At the very least, yes, we can list that it should work on a
> number of others and that we develop in Fedora, but certainly we can test
> in more OS's to a level of confidence to count as official support, right?
>
> As for documentation, David, what sort of questions have you been getting
> about it?  I mean, we have documentation.  I know we can likely improve it,
> or at least the visibility of it as a recent review suggested.  Is there a
> particular area of concern that we could address?
>
> Thanks,
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Wed, Sep 19, 2018 at 3:02 PM, Brian Bouterse 
> wrote:
>
>> 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 working. For instance with Fedora, even with dev
>> environments, it's possible that we aren't booting into both F27 and F28
>> often enough and Pulp break from a dependency change. With CI running for
>> the supported OS's, we'll know almost as fast as our users do when there is
>> an issue on a supported OS. I think this is part of the "supported OS"
>> value proposition. It allows us to be very precise on exactly which
>> versions are being continuously tested on, down to the specific versions.
>>
>> Other/more ideas are welcome.
>>
>>
>>
>> On Wed, Sep 19, 2018 at 1:19 PM David Davis 
>> wrote:
>>
>>> 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 what makes sense to me. Let's have Pulp claim official support
 for any distro that we have CI for (Travis). This ensures every pull
 request change and nightlies are tested and provable on all supported
 distros. I believe support is about provable testing so without CI we can't
 ensure it in an ongoing way otherwise. Additionally though, we should say
 that Pulp will likely run anywhere that has the Python 3.6 runtime and has
 all necessary dependencies, which likely includes MacOS, Debian, etc. From
 a practical perspective Pulp likely will run well on all these distros, so
 even though we wouldn't claim formal support, our users probably aren't
 limited much in-practice.

 The only strange thing with ^ approach is that currently Travis only
 tests on Ubuntu so we would not be able to claim additional support until
 we started testing other distros in containers on Travis (totally do-able)
 [0]. I'm ok w/ that though.

 What do you all think?

 [0]: https://docs.travis-ci.com/user/multi-os/




 On Wed, Sep 12, 2018 at 1:52 PM, David Davis 
 wrote:

> Our last Pulp 3.0 planning ended a bit early a few weeks ago and there
> were a few outstanding questions that I would like to bring up on list for
> discussion and get some feedback.
>
> The first is around which OSes we are supporting and what will support
> include (testing on the OS, fixing platform-specific bugs, etc). We
> identified CentOS and Fedora as having official support. Then we also said
> we would support MacOS, Debian, and Ubuntu. Some confirmation and
> clarification on which OSes we are supporting and what support 

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

[Kersom]

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 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, and as he said Linux currently
> just means Ubuntu, and OSX may face some hurdles.
>
> Are there other forms of testing we would be willing and able to use to be
> able to officially back more OS's?  I'd really like to see more broad
> support.  At the very least, yes, we can list that it should work on a
> number of others and that we develop in Fedora, but certainly we can test
> in more OS's to a level of confidence to count as official support, right?
>
> As for documentation, David, what sort of questions have you been getting
> about it?  I mean, we have documentation.  I know we can likely improve it,
> or at least the visibility of it as a recent review suggested.  Is there a
> particular area of concern that we could address?
>
> Thanks,
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Wed, Sep 19, 2018 at 3:02 PM, Brian Bouterse 
> wrote:
>
>> 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 working. For instance with Fedora, even with dev
>> environments, it's possible that we aren't booting into both F27 and F28
>> often enough and Pulp break from a dependency change. With CI running for
>> the supported OS's, we'll know almost as fast as our users do when there is
>> an issue on a supported OS. I think this is part of the "supported OS"
>> value proposition. It allows us to be very precise on exactly which
>> versions are being continuously tested on, down to the specific versions.
>>
>> Other/more ideas are welcome.
>>
>>
>>
>> On Wed, Sep 19, 2018 at 1:19 PM David Davis 
>> wrote:
>>
>>> 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 what makes sense to me. Let's have Pulp claim official support
 for any distro that we have CI for (Travis). This ensures every pull
 request change and nightlies are tested and provable on all supported
 distros. I believe support is about provable testing so without CI we can't
 ensure it in an ongoing way otherwise. Additionally though, we should say
 that Pulp will likely run anywhere that has the Python 3.6 runtime and has
 all necessary dependencies, which likely includes MacOS, Debian, etc. From
 a practical perspective Pulp likely will run well on all these distros, so
 even though we wouldn't claim formal support, our users probably aren't
 limited much in-practice.

 The only strange thing with ^ approach is that currently Travis only
 tests on Ubuntu so we would not be able to claim additional support until
 we started testing other distros in containers on Travis (totally do-able)
 [0]. I'm ok w/ that though.

 What do you all think?

 [0]: https://docs.travis-ci.com/user/multi-os/




 On Wed, Sep 12, 2018 at 1:52 PM, David Davis 
 wrote:

> Our last Pulp 3.0 planning ended a bit early a few weeks ago and there
> were a few outstanding questions that I would like to bring up on list for
> discussion and get some feedback.
>
> The first is around which OSes we are supporting and what will support
> include (testing on the OS, fixing platform-specific bugs, etc). We
> identified CentOS and Fedora as having official support. Then we also said
> we would support MacOS, Debian, and Ubuntu. Some confirmation and
> clarification on which OSes we are supporting and what support will mean
> would be good. Does anyone have any thoughts?
>
> Secondly, I just wanted to confirm that for the RC, we are planning on
> providing only Python packages via PyPI. I imagine we’ll work on providing
> other packaging formats like RPMs after the RC but before the GA.
>
> Lastly, there were some questions around what level of documentation
> we’re planning on having for the release. I’m not sure of 

[Pulp-dev] pulpcore 3.0.0b8 released

[Dennis Kliban]

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 [4]

The beta documentation is available here[5].

[0] https://pypi.org/project/pulpcore/3.0.0b8/
[1] https://pypi.org/project/pulpcore-plugin/0.1.0b6/
[2] https://bit.ly/2PPyGCO
[3] https://github.com/pulp/pulp/pull/3637
[4] https://github.com/pulp/pulp/pull/3630
[5] https://docs.pulpproject.org/en/3.0/beta/
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[David Davis]

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 what makes sense to me. Let's have Pulp claim official support for
> any distro that we have CI for (Travis). This ensures every pull request
> change and nightlies are tested and provable on all supported distros. I
> believe support is about provable testing so without CI we can't ensure it
> in an ongoing way otherwise. Additionally though, we should say that Pulp
> will likely run anywhere that has the Python 3.6 runtime and has all
> necessary dependencies, which likely includes MacOS, Debian, etc. From a
> practical perspective Pulp likely will run well on all these distros, so
> even though we wouldn't claim formal support, our users probably aren't
> limited much in-practice.
>
> The only strange thing with ^ approach is that currently Travis only tests
> on Ubuntu so we would not be able to claim additional support until we
> started testing other distros in containers on Travis (totally do-able)
> [0]. I'm ok w/ that though.
>
> What do you all think?
>
> [0]: https://docs.travis-ci.com/user/multi-os/
>
>
>
>
> On Wed, Sep 12, 2018 at 1:52 PM, David Davis 
> wrote:
>
>> Our last Pulp 3.0 planning ended a bit early a few weeks ago and there
>> were a few outstanding questions that I would like to bring up on list for
>> discussion and get some feedback.
>>
>> The first is around which OSes we are supporting and what will support
>> include (testing on the OS, fixing platform-specific bugs, etc). We
>> identified CentOS and Fedora as having official support. Then we also said
>> we would support MacOS, Debian, and Ubuntu. Some confirmation and
>> clarification on which OSes we are supporting and what support will mean
>> would be good. Does anyone have any thoughts?
>>
>> Secondly, I just wanted to confirm that for the RC, we are planning on
>> providing only Python packages via PyPI. I imagine we’ll work on providing
>> other packaging formats like RPMs after the RC but before the GA.
>>
>> Lastly, there were some questions around what level of documentation
>> we’re planning on having for the release. I’m not sure of a good way to
>> address this and am looking for feedback.
>>
>> Thanks.
>>
>> David
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Brian Bouterse]

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 about the storage capacity needed for
> the sheer number of sqlite3 databases generated.  Maybe a script could
> periodically empty /var/lib/pulp/debug/ as it reaches certain configured
> size/age limits?
>
We did have a similar feature in Pulp2 that would output a cProfile with
the filename being the task UUID. (docs link below). I don't think storage
wasn't an issue there, but users would have to confirm for us. When users
would use it, they would turn the feature on, run the troublesome workload,
then turn it off again so it's usually a few tasks only. I think each db
will be very small < 1MB probably.

https://docs.pulpproject.org/dev-guide/debugging.html#task-performance-analysis


> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Mon, Sep 17, 2018 at 2:36 PM, Brian Bouterse 
> wrote:
>
>> I'm interested in implementing a data collection feature for Pulp3. This
>> will allow us to easily and accurately benchmark pipeline performance to
>> clearly show improvement as we make changes. Borrowing from my old queueing
>> theory days... here is a data collection feature proposal:
>>
>> https://pulp.plan.io/issues/4021
>>
>> Any comment/ideas are welcome. Thank you!
>>
>> -Brian
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Removing PublishedArtifact?

[Brian Bouterse]

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
scope of work for #4020 is only to extend the content app to search
ContentArtifact.relative_path before returning the 404 if no
PublishedArtifact or PublishedMetadata objects match for that publication.

What about doing that? Also I'm kind of hoping to deliver this code to the
plugin writer kind of soon. Thank you again for all the great input here
and on the input.

On Tue, Sep 18, 2018 at 8:59 AM David Davis  wrote:

> I think that pulp_deb could maybe create its own association between
> publication and artifacts. The problem is that PublishedArtifacts is a
> one-size-fits-all solution that probably ought to be instead implemented in
> plugins that require some specialized way to join publications and
> artifacts.
>
> David
>
>
> On Tue, Sep 18, 2018 at 4:51 AM Matthias Dellweg  wrote:
>
>> Not entierly sure, that this is related, but a while ago, we laid out a
>> road map for the pulp3_deb plugin [1]. It includes 8 different
>> publishers, that publish different metadata for the same repository
>> version. As far as i understand, that is exactly, what
>> PublishedArtifacts are for. If it were possible to just use ordinary
>> Artifacts and associate them with a Publication instead of a
>> RepositoryVersion it might be ok in that context.
>>
>> Cheers, Matthias
>>
>> [1] https://etherpad.net/p/pulp-deb-pulp3/timeslider#2902
>>
>> On Mon, 17 Sep 2018 12:45:15 -0400
>> Brian Bouterse  wrote:
>>
>> > A plugin writer (@oleksander) pointed out to me that PublishedArtifact
>> > seems a bit out of place for his usage. I can see why he thinks that,
>> > and after thinking about it, Pulp does seem a bit over-complicated in
>> > this area. I've written [0] to describe the problem, promote
>> > discussion of this issue, and hopefully decide on a resolution.
>> >
>> > [0]: https://pulp.plan.io/issues/4020
>> >
>> > Discussion and collaboration is welcome!
>> >
>> > -Brian
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Removing PublishedArtifact?

[David Davis]

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. That
seems safer.

David


On Wed, Sep 19, 2018 at 1:54 PM Brian Bouterse  wrote:

> 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
> scope of work for #4020 is only to extend the content app to search
> ContentArtifact.relative_path before returning the 404 if no
> PublishedArtifact or PublishedMetadata objects match for that publication.
>
> What about doing that? Also I'm kind of hoping to deliver this code to the
> plugin writer kind of soon. Thank you again for all the great input here
> and on the input.
>
> On Tue, Sep 18, 2018 at 8:59 AM David Davis  wrote:
>
>> I think that pulp_deb could maybe create its own association between
>> publication and artifacts. The problem is that PublishedArtifacts is a
>> one-size-fits-all solution that probably ought to be instead implemented in
>> plugins that require some specialized way to join publications and
>> artifacts.
>>
>> David
>>
>>
>> On Tue, Sep 18, 2018 at 4:51 AM Matthias Dellweg  wrote:
>>
>>> Not entierly sure, that this is related, but a while ago, we laid out a
>>> road map for the pulp3_deb plugin [1]. It includes 8 different
>>> publishers, that publish different metadata for the same repository
>>> version. As far as i understand, that is exactly, what
>>> PublishedArtifacts are for. If it were possible to just use ordinary
>>> Artifacts and associate them with a Publication instead of a
>>> RepositoryVersion it might be ok in that context.
>>>
>>> Cheers, Matthias
>>>
>>> [1] https://etherpad.net/p/pulp-deb-pulp3/timeslider#2902
>>>
>>> On Mon, 17 Sep 2018 12:45:15 -0400
>>> Brian Bouterse  wrote:
>>>
>>> > A plugin writer (@oleksander) pointed out to me that PublishedArtifact
>>> > seems a bit out of place for his usage. I can see why he thinks that,
>>> > and after thinking about it, Pulp does seem a bit over-complicated in
>>> > this area. I've written [0] to describe the problem, promote
>>> > discussion of this issue, and hopefully decide on a resolution.
>>> >
>>> > [0]: https://pulp.plan.io/issues/4020
>>> >
>>> > Discussion and collaboration is welcome!
>>> >
>>> > -Brian
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Removing PublishedArtifact?

[Brian Bouterse]

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 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. That
> seems safer.
>
> David
>
>
> On Wed, Sep 19, 2018 at 1:54 PM Brian Bouterse 
> wrote:
>
>> 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
>> scope of work for #4020 is only to extend the content app to search
>> ContentArtifact.relative_path before returning the 404 if no
>> PublishedArtifact or PublishedMetadata objects match for that publication.
>>
>> What about doing that? Also I'm kind of hoping to deliver this code to
>> the plugin writer kind of soon. Thank you again for all the great input
>> here and on the input.
>>
>> On Tue, Sep 18, 2018 at 8:59 AM David Davis 
>> wrote:
>>
>>> I think that pulp_deb could maybe create its own association between
>>> publication and artifacts. The problem is that PublishedArtifacts is a
>>> one-size-fits-all solution that probably ought to be instead implemented in
>>> plugins that require some specialized way to join publications and
>>> artifacts.
>>>
>>> David
>>>
>>>
>>> On Tue, Sep 18, 2018 at 4:51 AM Matthias Dellweg 
>>> wrote:
>>>
 Not entierly sure, that this is related, but a while ago, we laid out a
 road map for the pulp3_deb plugin [1]. It includes 8 different
 publishers, that publish different metadata for the same repository
 version. As far as i understand, that is exactly, what
 PublishedArtifacts are for. If it were possible to just use ordinary
 Artifacts and associate them with a Publication instead of a
 RepositoryVersion it might be ok in that context.

 Cheers, Matthias

 [1] https://etherpad.net/p/pulp-deb-pulp3/timeslider#2902

 On Mon, 17 Sep 2018 12:45:15 -0400
 Brian Bouterse  wrote:

 > A plugin writer (@oleksander) pointed out to me that PublishedArtifact
 > seems a bit out of place for his usage. I can see why he thinks that,
 > and after thinking about it, Pulp does seem a bit over-complicated in
 > this area. I've written [0] to describe the problem, promote
 > discussion of this issue, and hopefully decide on a resolution.
 >
 > [0]: https://pulp.plan.io/issues/4020
 >
 > Discussion and collaboration is welcome!
 >
 > -Brian
 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Dana Walker]

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 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 about the storage capacity needed for
>> the sheer number of sqlite3 databases generated.  Maybe a script could
>> periodically empty /var/lib/pulp/debug/ as it reaches certain configured
>> size/age limits?
>>
> We did have a similar feature in Pulp2 that would output a cProfile with
> the filename being the task UUID. (docs link below). I don't think storage
> wasn't an issue there, but users would have to confirm for us. When users
> would use it, they would turn the feature on, run the troublesome workload,
> then turn it off again so it's usually a few tasks only. I think each db
> will be very small < 1MB probably.
>
> https://docs.pulpproject.org/dev-guide/debugging.html#task-
> performance-analysis
>
>
>> --Dana
>>
>> Dana Walker
>>
>> Associate Software Engineer
>>
>> Red Hat
>>
>> 
>> 
>>
>> On Mon, Sep 17, 2018 at 2:36 PM, Brian Bouterse 
>> wrote:
>>
>>> I'm interested in implementing a data collection feature for Pulp3. This
>>> will allow us to easily and accurately benchmark pipeline performance to
>>> clearly show improvement as we make changes. Borrowing from my old queueing
>>> theory days... here is a data collection feature proposal:
>>>
>>> https://pulp.plan.io/issues/4021
>>>
>>> Any comment/ideas are welcome. Thank you!
>>>
>>> -Brian
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Brian Bouterse]

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 working. For instance with Fedora, even with dev
environments, it's possible that we aren't booting into both F27 and F28
often enough and Pulp break from a dependency change. With CI running for
the supported OS's, we'll know almost as fast as our users do when there is
an issue on a supported OS. I think this is part of the "supported OS"
value proposition. It allows us to be very precise on exactly which
versions are being continuously tested on, down to the specific versions.

Other/more ideas are welcome.



On Wed, Sep 19, 2018 at 1:19 PM David Davis  wrote:

> 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 what makes sense to me. Let's have Pulp claim official support
>> for any distro that we have CI for (Travis). This ensures every pull
>> request change and nightlies are tested and provable on all supported
>> distros. I believe support is about provable testing so without CI we can't
>> ensure it in an ongoing way otherwise. Additionally though, we should say
>> that Pulp will likely run anywhere that has the Python 3.6 runtime and has
>> all necessary dependencies, which likely includes MacOS, Debian, etc. From
>> a practical perspective Pulp likely will run well on all these distros, so
>> even though we wouldn't claim formal support, our users probably aren't
>> limited much in-practice.
>>
>> The only strange thing with ^ approach is that currently Travis only
>> tests on Ubuntu so we would not be able to claim additional support until
>> we started testing other distros in containers on Travis (totally do-able)
>> [0]. I'm ok w/ that though.
>>
>> What do you all think?
>>
>> [0]: https://docs.travis-ci.com/user/multi-os/
>>
>>
>>
>>
>> On Wed, Sep 12, 2018 at 1:52 PM, David Davis 
>> wrote:
>>
>>> Our last Pulp 3.0 planning ended a bit early a few weeks ago and there
>>> were a few outstanding questions that I would like to bring up on list for
>>> discussion and get some feedback.
>>>
>>> The first is around which OSes we are supporting and what will support
>>> include (testing on the OS, fixing platform-specific bugs, etc). We
>>> identified CentOS and Fedora as having official support. Then we also said
>>> we would support MacOS, Debian, and Ubuntu. Some confirmation and
>>> clarification on which OSes we are supporting and what support will mean
>>> would be good. Does anyone have any thoughts?
>>>
>>> Secondly, I just wanted to confirm that for the RC, we are planning on
>>> providing only Python packages via PyPI. I imagine we’ll work on providing
>>> other packaging formats like RPMs after the RC but before the GA.
>>>
>>> Lastly, there were some questions around what level of documentation
>>> we’re planning on having for the release. I’m not sure of a good way to
>>> address this and am looking for feedback.
>>>
>>> Thanks.
>>>
>>> David
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Dana Walker]

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, and as he said Linux currently just
means Ubuntu, and OSX may face some hurdles.

Are there other forms of testing we would be willing and able to use to be
able to officially back more OS's?  I'd really like to see more broad
support.  At the very least, yes, we can list that it should work on a
number of others and that we develop in Fedora, but certainly we can test
in more OS's to a level of confidence to count as official support, right?

As for documentation, David, what sort of questions have you been getting
about it?  I mean, we have documentation.  I know we can likely improve it,
or at least the visibility of it as a recent review suggested.  Is there a
particular area of concern that we could address?

Thanks,

--Dana

Dana Walker

Associate Software Engineer

Red Hat




On Wed, Sep 19, 2018 at 3:02 PM, Brian Bouterse  wrote:

> 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 working. For instance with Fedora, even with dev
> environments, it's possible that we aren't booting into both F27 and F28
> often enough and Pulp break from a dependency change. With CI running for
> the supported OS's, we'll know almost as fast as our users do when there is
> an issue on a supported OS. I think this is part of the "supported OS"
> value proposition. It allows us to be very precise on exactly which
> versions are being continuously tested on, down to the specific versions.
>
> Other/more ideas are welcome.
>
>
>
> On Wed, Sep 19, 2018 at 1:19 PM David Davis  wrote:
>
>> 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 what makes sense to me. Let's have Pulp claim official support
>>> for any distro that we have CI for (Travis). This ensures every pull
>>> request change and nightlies are tested and provable on all supported
>>> distros. I believe support is about provable testing so without CI we can't
>>> ensure it in an ongoing way otherwise. Additionally though, we should say
>>> that Pulp will likely run anywhere that has the Python 3.6 runtime and has
>>> all necessary dependencies, which likely includes MacOS, Debian, etc. From
>>> a practical perspective Pulp likely will run well on all these distros, so
>>> even though we wouldn't claim formal support, our users probably aren't
>>> limited much in-practice.
>>>
>>> The only strange thing with ^ approach is that currently Travis only
>>> tests on Ubuntu so we would not be able to claim additional support until
>>> we started testing other distros in containers on Travis (totally do-able)
>>> [0]. I'm ok w/ that though.
>>>
>>> What do you all think?
>>>
>>> [0]: https://docs.travis-ci.com/user/multi-os/
>>>
>>>
>>>
>>>
>>> On Wed, Sep 12, 2018 at 1:52 PM, David Davis 
>>> wrote:
>>>
 Our last Pulp 3.0 planning ended a bit early a few weeks ago and there
 were a few outstanding questions that I would like to bring up on list for
 discussion and get some feedback.

 The first is around which OSes we are supporting and what will support
 include (testing on the OS, fixing platform-specific bugs, etc). We
 identified CentOS and Fedora as having official support. Then we also said
 we would support MacOS, Debian, and Ubuntu. Some confirmation and
 clarification on which OSes we are supporting and what support will mean
 would be good. Does anyone have any thoughts?

 Secondly, I just wanted to confirm that for the RC, we are planning on
 providing only Python packages via PyPI. I imagine we’ll work on providing
 other packaging formats like RPMs after the RC but before the GA.

 Lastly, there were some questions around what level of documentation
 we’re planning on having for the release. I’m not sure of a good way to
 address this and am looking for feedback.

 Thanks.

 David

 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>