Re: [Pulp-dev] Call for Presenters: Community Demo, Wednesday January 9th

[Dana Walker]

Moving the demo once again to Wednesday, January 30 due to conflicts.  You
may still submit additional demos.

Thanks!

--Dana

Dana Walker

Associate Software Engineer

Red Hat





On Mon, Jan 14, 2019 at 4:46 PM Dana Walker  wrote:

> Hey folks,
>
> We're moving the demo back a week once more to Wednesday, January 23.  The
> good news is this is because we're quite busy!  You still have time to
> submit additional demos.
>
> Thanks,
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
>
> On Tue, Jan 8, 2019 at 10:09 AM Dana Walker  wrote:
>
>> Hey everyone,
>>
>> We're moving the demo back a week to Wednesday, January 16.  You still
>> have time to submit additional demos.
>>
>> Thanks,
>>
>> --Dana
>>
>> Dana Walker
>>
>> Associate Software Engineer
>>
>> Red Hat
>>
>> 
>> 
>>
>>
>> On Wed, Jan 2, 2019 at 7:45 AM Dana Walker  wrote:
>>
>>> Have you contributed to Pulp or the Pulp community in some way since
>>> the last community demo? Show the community what you've done!
>>>
>>> The next community demo is scheduled for Wednesday, January 9 at 15:00
>>> UTC [0].
>>>
>>> All demos should be pre-recorded; here are some docs on how to do that
>>> [1]. Once you have your topic selected, put yourself on the agenda here [2].
>>>
>>> [0]: https://bit.ly/2F1UcDg
>>> [1]: https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes
>>> [2]: https://etherpad.net/p/Pulp_Community_Demo_Agenda
>>>
>>> Thanks,
>>>
>>> --Dana
>>>
>>> Dana Walker
>>>
>>> Associate Software Engineer
>>>
>>> Red Hat
>>>
>>> 
>>> 
>>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Removing pulp/relational-pulp from Pulp org on Jan 22nd

[Jeff Ortel]

+1, delete.

On 1/17/19 12:44 PM, Brian Bouterse wrote:
This repo [0] was an early-on repo design of Master/Detail which has 
been moved into the Pulp3 codebase for several years now. Now github 
identified several issues in it via static analysis and we're getting 
email notification about fixing them.


The author of it, @smyers, confirmed via private email that it is no 
longer used and can be deleted. I second that it should be deleted.


I am planning to delete it on Tues Jan 22nd. You can fork until then 
if you want to. If there are any concerns or problems with this, 
feedback is welcome.


[0]: https://github.com/pulp/relational-pulp

Thanks,
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] Reminder: 2.18.1 Dev Freeze Today.

[Jeff Ortel]

Any Pulp2 core or plugin code that you want included in the 2.18.1 
release must be:


- Merged to master by 22:00 UTC, Today.
- Be associated with a bugfix issue. stories, refactors, and tasks are 
not included in z-stream releases.


Thanks!

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

Re: [Pulp-dev] Providing Pulp 3 Container Images and Installation Support

[Brian Bouterse]

Thank you for this. I put some responses inline. Does it make any sense to
put this well written proposal (and its updates over time) into a wiki
page?  https://pulp.plan.io/projects/pulp/wiki/


On Fri, Jan 11, 2019 at 1:27 PM Eric Helms  wrote:

> Howdy,
>
> A few months back, the team that handles RPM packaging for Pulp 2 (my
> team) and the Pulp team got together to discuss production 'packaging'
> support for Pulp 3. Where we landed was to take a container native approach
> from the outset and provide installation support via the Ansible installer
> for Pulp 3. This RFC aims to outline the general strategy, link to existing
> work and aim towards next steps.
>
> Note: We do not plan to provide RPMs at this time in favor of a container
> native solution for deploying Pulp 3. If the user demand becomes high
> enough, we'll look to discuss and collaborate on how to move forward.
>
> Proposal
>
> The proposal is to package Pulp 3 via containers using pypi assets as the
> de-facto input source for building the container image(s). The image(s)
> would be stored on https://quay.io and initially provided with support
> through the ansible-pulp3 installer. The installer would pull and run the
> images via systemd using podman as the default with support for Docker.
> This will provide users with a singular interface for deploying and
> managing Pulp 3 no matter the choice of installation (e.g. source, pypi,
> containers). In the future, existing work to deploy on to Kubernetes would
> be brought into the installer to support deploying the containers on top of
> Kubeneretes or Openshift.
>
This sounds consistent with the discussions at PulpCon. +1

>
> Given Pulp is a plugin based ecosystem, and images are immutable plugins
> need to be handled in a user configurable way. In this space, the original
> proposal was to provide enough build tooling and documentation to allow
> users to re-build Pulp images with any combination of plugins they require.
> The Pulp published image(s) would include a base image and at least one
> image with a specific combination of plugins provided. This is an area that
> has had much discussion, and ideas. Ideas such as images that deploy plugin
> code to a shared volume, sidecar containers that provide plugins at
> runtime, a single image with all plugins and runtime configuration and the
> Discourse model of rebuilding the image locally when a plugin is added via
> a commandline.
>
I think having all the software built into one image would be the simplest.
Making it really easy for a user to pick what they want, and to get that
rebuilt over time would be valuable.

>
> Existing Work
>
> The existing work in this area is around two pull requests that have
> provided a working proof of concept. The first is the image itself [1] and
> the second is to the installer [2] that makes use of this image.
>
> The current works' biggest design assumption (up for debate) is around a
> single image vs. an image per service. The strategy difference is around a
> single image that can, with the right start command, take on the role of
> any Pulp 3 service. The multi-image strategy would aim to ensure there is
> an image per service that knows how to properly run itself. A single image
> provides a simpler build strategy to start with potentially more confusion
> to users wanting to use them within their own context.
>
If a more complicated build system makes for a simpler deployment
experience I think that's a win, so I'm +1 for the multi-image approach. If
it's too much to do right now I would understand that too.


> Open Questions
>
>  * What are the communities thoughts on this approach?
>
 * What are the gaps to get both [1] and [2] into the respective code bases?
>
I will look at reviewing these today/tomorrow ot give some initial feedback

>  * Should we stick with a single image strategy or opt to pivot to
> multi-image?
>
+1 for multi, but that is my opinion

 * What changes need to be made to selinux policies?
>
We have no selinux policy atm so none. When we need one we can do that.

 * How is plugin support handled?
>
This ticket epic describes that each plugin could choose to ship a
container w/ just their plugin code on top of core. Each plugin could add
that to the "master" pipeline that core maintains via PRs, which sounds
sustainable. Another option is to have each plugin "replicate" the code
from [1] into their own repos. That sounds unmaintainable. Suggests are
welcome.

>
> Next Steps
>
> To move forward, I'll be looking for a Pulp maintainer to help sponsor and
> shepherd this work into the Pulp ecosystem. Along with that a rough list:
>
>  * Resolve open questions
>
 * Create Pulp account on quay.io
>
I made  a pulp account for us to ship the images with.

 * Add deployment support to Travis configuration
>
Let's IRC collab so I can make the encrypted Travis secret for your PR.
Where in the Travis config does it go?

 * Get initial installer work merged
>
Yes, let's. I'm goi