Re: [Pulp-dev] Pulp 2 plugin release plan

2018-06-19 Thread Tom McKay 
Just curious, but I assume that for an async plugin release that would
imply zero changes to the exposed APIs and only fixes to the underlying
code?

As a consumer of pulp, we install pulp-server not individual plugins. If a
plugin changes it's exposed interface (ie. API) then I'd expect a bump on
the primary product version.

Foreman has an interface layer that, if the API changes, may itself require
updates. If API is 100% backward compatible, then there shouldn't be a
problem.

On Tue, Jun 19, 2018 at 11:06 AM, Dennis Kliban  wrote:

> On Tue, Jun 19, 2018 at 10:54 AM, Ina Panova  wrote:
>
>> Dennis,
>> thank you for sending out the summary of our meeting.
>>
>> Just to highlight and check the overall understanding -  there will be
>> one repository per Y pulp release which might contain multiple Z and Y
>> plugin version releases.
>> Correct me if i am wrong.
>>
>>
> That is correct.
>
>
>
>> What would be our next steps in terms of collaboration with the build
>> team?
>>
>>
>>
> My understanding was that Patrick is planning to do some investigation and
> report back on this thread. Please correct me if I am wrong.
>
>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> 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 Mon, Jun 18, 2018 at 8:20 PM, Dennis Kliban 
>> wrote:
>>
>>> Earlier today a few of us met to discuss how we can release new Y
>>> releases of plugins without a Y release of the platform accompanying them.
>>>
>>> The initial proposal was to publish a new Y release of a plugin at the
>>> same time as a Z release of platform and other plugins. More concretely, we
>>> were discussing putting pulp-docker-* 3.2.0 packages into the 2.16
>>> repository[0]. This repository currently contains 3.1.3 packages.
>>> Publishing 3.2.0 packages to this repository would completely remove the
>>> 3.1.3 pulp-docker packages. Since 3.1.3 pulp-docker-* packages were only
>>> published to the 2.16 repository, the only 3.1.z package available after a
>>> publish of 3.2.0 would be 3.1.2 in the 2.15 repository[1]. After
>>> identifying this problem, we decided to NOT release pulp-docker-* 3.2.0
>>> with the 2.16.2 z-stream release.
>>>
>>> In order to eliminate this problem in the future, we would like to
>>> investigate if it will be possible to compose repositories with new Y
>>> releases of plugins while retaining the previous versions of packages that
>>> were already published to the repository before. If this is possible, we
>>> would try to start composing our Z stream repositories in such a way
>>> starting with 2.17.0 release.
>>>
>>> Questions? Thoughts? Ideas?
>>>
>>>
>>> [0] https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server/x86_64/
>>> [1] https://repos.fedorapeople.org/pulp/pulp/stable/2.15/7Server/x86_64/
>>>
>>>
>>> ___
>>> 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] Pulp 2 plugin release plan

2018-06-19 Thread Dennis Kliban 
On Tue, Jun 19, 2018 at 10:54 AM, Ina Panova  wrote:

> Dennis,
> thank you for sending out the summary of our meeting.
>
> Just to highlight and check the overall understanding -  there will be one
> repository per Y pulp release which might contain multiple Z and Y plugin
> version releases.
> Correct me if i am wrong.
>
>
That is correct.



> What would be our next steps in terms of collaboration with the build team?
>
>
>
My understanding was that Patrick is planning to do some investigation and
report back on this thread. Please correct me if I am wrong.


>
> 
> Regards,
>
> Ina Panova
> 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 Mon, Jun 18, 2018 at 8:20 PM, Dennis Kliban  wrote:
>
>> Earlier today a few of us met to discuss how we can release new Y
>> releases of plugins without a Y release of the platform accompanying them.
>>
>> The initial proposal was to publish a new Y release of a plugin at the
>> same time as a Z release of platform and other plugins. More concretely, we
>> were discussing putting pulp-docker-* 3.2.0 packages into the 2.16
>> repository[0]. This repository currently contains 3.1.3 packages.
>> Publishing 3.2.0 packages to this repository would completely remove the
>> 3.1.3 pulp-docker packages. Since 3.1.3 pulp-docker-* packages were only
>> published to the 2.16 repository, the only 3.1.z package available after a
>> publish of 3.2.0 would be 3.1.2 in the 2.15 repository[1]. After
>> identifying this problem, we decided to NOT release pulp-docker-* 3.2.0
>> with the 2.16.2 z-stream release.
>>
>> In order to eliminate this problem in the future, we would like to
>> investigate if it will be possible to compose repositories with new Y
>> releases of plugins while retaining the previous versions of packages that
>> were already published to the repository before. If this is possible, we
>> would try to start composing our Z stream repositories in such a way
>> starting with 2.17.0 release.
>>
>> Questions? Thoughts? Ideas?
>>
>>
>> [0] https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server/x86_64/
>> [1] https://repos.fedorapeople.org/pulp/pulp/stable/2.15/7Server/x86_64/
>>
>>
>> ___
>> 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] Pulp 2 plugin release plan

2018-06-19 Thread Ina Panova 
Dennis,
thank you for sending out the summary of our meeting.

Just to highlight and check the overall understanding -  there will be one
repository per Y pulp release which might contain multiple Z and Y plugin
version releases.
Correct me if i am wrong.

What would be our next steps in terms of collaboration with the build team?




Regards,

Ina Panova
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 Mon, Jun 18, 2018 at 8:20 PM, Dennis Kliban  wrote:

> Earlier today a few of us met to discuss how we can release new Y releases
> of plugins without a Y release of the platform accompanying them.
>
> The initial proposal was to publish a new Y release of a plugin at the
> same time as a Z release of platform and other plugins. More concretely, we
> were discussing putting pulp-docker-* 3.2.0 packages into the 2.16
> repository[0]. This repository currently contains 3.1.3 packages.
> Publishing 3.2.0 packages to this repository would completely remove the
> 3.1.3 pulp-docker packages. Since 3.1.3 pulp-docker-* packages were only
> published to the 2.16 repository, the only 3.1.z package available after a
> publish of 3.2.0 would be 3.1.2 in the 2.15 repository[1]. After
> identifying this problem, we decided to NOT release pulp-docker-* 3.2.0
> with the 2.16.2 z-stream release.
>
> In order to eliminate this problem in the future, we would like to
> investigate if it will be possible to compose repositories with new Y
> releases of plugins while retaining the previous versions of packages that
> were already published to the repository before. If this is possible, we
> would try to start composing our Z stream repositories in such a way
> starting with 2.17.0 release.
>
> Questions? Thoughts? Ideas?
>
>
> [0] https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server/x86_64/
> [1] https://repos.fedorapeople.org/pulp/pulp/stable/2.15/7Server/x86_64/
>
>
> ___
> 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] Ideas for the plugin template

2018-06-19 Thread Austin Macdonald 
I've written up stories for this work, which I've marked as sprint
candidates. I'd like to get them groomed this week if possible.

Testing: https://pulp.plan.io/issues/3773
Documentation: https://pulp.plan.io/issues/3772

On Mon, Jun 18, 2018 at 3:48 PM, Dennis Kliban  wrote:

> +1
>
> On Mon, Jun 18, 2018 at 3:14 PM, Dana Walker  wrote:
>
>> +1
>>
>> (Already said it during review, but figured I'd make it official here.)
>>
>> Dana Walker
>>
>> Associate Software Engineer
>>
>> Red Hat
>>
>> 
>> 
>>
>> On Mon, Jun 18, 2018 at 2:01 PM, Daniel Alley  wrote:
>>
>>> +1
>>>
>>> On Mon, Jun 18, 2018 at 12:16 PM, Brian Bouterse 
>>> wrote:
>>>
 +1

 On Mon, Jun 18, 2018 at 8:47 AM, Ina Panova  wrote:

> +1
>
>
>
> 
> Regards,
>
> Ina Panova
> 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 Thu, Jun 14, 2018 at 10:19 PM, Bihan Zhang 
> wrote:
>
>> +1
>> I think the plugin_template is very valuable for bootstrapping plugin
>> development, but we have had issues with keeping it up to date. Creating 
>> a
>> smash test that will enforce this on new PRs make perfect sense to me.
>>
>>
>>
>> On Thu, Jun 14, 2018 at 11:29 AM, Austin Macdonald > > wrote:
>>
>>> I've recently updated the plugin_template to work with the latest
>>> master (3.0). [0] The template handles almost all of the
>>> bootstrapping
>>> work necessary to write a new plugin, so it is valuable to keep it
>>> up to
>>> date. Given human nature, it's likely that the plugin_template will
>>> tend
>>> to fall behind as it did recently. I have some ideas to save time
>>> while
>>> keeping the template current and useful.
>>>
>>> 1) Move the plugin writer docs [1] into the plugin_template
>>> repository
>>> - Leave a (very) high level overview in the core docs with a
>>> link to
>>>   the template docs.
>>> - Plugin writer docs PRs would only go to one place, and it
>>> would
>>>   be easier keep the docs in line with the code.
>>> - Narrative docs in the template would explain what needs to
>>> be
>>>   done generally, linking to the modules.
>>> - Specific instructions would live in the code modules
>>> alongside
>>>   basic working code, and additional commented out code
>>>   to demonstrate and explain more complex behaviors.
>>>
>>>  2) Add pulp_smash tests for basic functionality of a bootstrapped
>>> plugin.
>>>  - Run these tests as a check on pulpcore and template PRs
>>>  - Ensure that discoverability works
>>>  - Fail with breaking Plugin API changes
>>>  - If the test uses pulp_smash, it would include a base set
>>> of
>>>integration tests for every new plugin.
>>>
>>> My reasoning is that no matter what changes we make to pulpcore,
>>> we need to keep the plugin writer docs updated. Doing this in the
>>> template will provide value for plugin writers, and will inform
>>> pulpcore
>>> developers when it needs to be updated.
>>>
>>> [0]: https://github.com/pulp/plugin_template/pull/9
>>> [1]: https://github.com/pulp/pulp/tree/master/docs/plugins/plugin
>>> -writer
>>>
>>>
>>>
>>> ___
>>> 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
>
>

 ___
 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
>>
>>
>
> ___
> 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