[Pulp-dev] Meeting Minutes: Sprint 66

[Robin Chan]

7-Feb-2020

New Sprint 66 query: https://pulp.plan.io/issues?query_id=142

Stats on how we did in previous 2 week  Sprint 65 Query
:

 New - 7

 Assigned - 10

 Post - 11

 Modified - 17

Closed - CURRENTRELEASE - 5

Closed - WORKSFORME - 2

Closed - NOTABUG -

Closed - WONTFIX -1

Closed - COMPLETE -

Closed - NOTABUG -

Action Items from last Sprint Planning

   -

   none


Dates:

https://pulp.plan.io/projects/pulp/wiki/Sprint_Plans

Sprint Goals/Focus:

   -

   Support of Automation Hub’s work to port to a Pulp plugin pretty much
   done


   -

   3.2 Release - End of Feb 26th
   -

   CI support for branches in ansible-pulp
   -

   Wrapping up signing feature - pulpcore
   -

   2.21.1 dev-freeze 19-Feb
   -

  https://pulp.plan.io/projects/pulp/wiki/2211_Release_Schedule


Other things happening during the sprint (including outages)

   -




Current sprint:

Anything not moving forward?

https://pulp.plan.io/issues/5859 - Needs some feedback blocking moving
forward

Sprint candidates:

https://pulp.plan.io/issues?query_id=26

None.

The are the remaining 3.1 items to only be added to last sprint based on
brian/david availability for the sprint:

5613 

5286 

Pending Items:

   -


QE Focus:

Action Items:

   -

   rchan: Clear Sprint Candidate https://pulp.plan.io/issues?query_id=26


   -

   rchan: send out planning minutes
   -

   https://pulp.plan.io/issues/5945 - need final agreement w/misa. Note:
   lots of implementation already complete
   -

   Rchan check with dkliban on content signing in sprint


Robin Chan

She/Her/Hers

Satellite Software Engineering Manager - Pulp

Red Hat 

IRC: rchan

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

[Pulp-dev] Importers/Exporters

[David Davis]

Grant and I met today to discuss importers and exporters[0] and we'd like
some feedback before we proceed with the design. To sum up this feature
briefly: users can export a repository version from one Pulp instance and
import it to another.

# Master/Detail vs Core

So one fundamental question is whether we should use a Master/Detail
approach or just have core control the flow but call out to plugins to get
export formats.

To give some background: we currently define Exporters (ie
FileSystemExporter) in core as Master models. Plugins extend this model
which allows them to configure or customize the Exporter. This was
necessary because some plugins need to export Publications (along with
repository metadata) while other plugins who don't have Publications or
metadata export RepositoryVersions.

The other option is to have core handle the workflow. The user would call a
core endpoint and provide a RepositoryVersion. This would work because for
importing/exporting, you wouldn't ever use Publications because metadata
won't be used for importing back into Pulp. If needed, core could provide a
way for plugin writers to write custom handlers/exporters for content types.

If we go with the second option, the question then becomes whether we
should divorce the concept of Exporters and import/export. Or do we also
switch Exporters from Master/Detail to core only?

# Foreign Keys

Content can be distributed across multiple tables (eg UpdateRecord has
UpdateCollection, etc). In our export, we could either use primary keys
(UUIDs) or natural keys to relate records. The former assumes that UUIDs
are unique across Pulp instances. The safer but more complex alternative is
to use natural keys. This would involve storing a set of fields on a record
that would be used to identify a related record.

# Incremental Exports

There are two big pieces of data contained in an export: the dataset of
Content from the database and the artifact files. An incremental export
cuts down on the size of an export by only exporting the differences.
However, when performing an incremental export, we could still export the
complete dataset instead of just a set of differences
(additions/removals/updates). This approach would be simpler and it would
allow us to ensure that the new repo version matches the exported repo
version exactly. It would however increase the export size but not by much
I think--probably some number of megabytes at most.

[0] https://pulp.plan.io/issues/6134

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

Re: [Pulp-dev] Read access in Github

[Dana Walker]

+1 helpful right now, even if our CI/CD moves elsewhere eventually

Dana Walker

She / Her / Hers

Software Engineer, Pulp Project

Red Hat 

dawal...@redhat.com




On Fri, Feb 14, 2020 at 8:56 AM Ina Panova  wrote:

> +1 this change will make things easier.
>
>
> 
> Regards,
>
> Ina Panova
> Senior 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 Fri, Feb 14, 2020 at 9:50 AM Tatiana Tereshchenko 
> wrote:
>
>> +1 to make restarting travis jobs available to everyone in pulp org
>>
>> On Fri, Feb 14, 2020 at 6:33 AM Brian Bouterse 
>> wrote:
>>
>>> +1 this would be helpful
>>>
>>> On Thu, Feb 13, 2020, 8:44 PM Daniel Alley  wrote:
>>>
 +1, I occasionally come across a repo where I can't even restart my own
 CI jobs, which is frustrating.  Probably even moreso to any new devs with
 less access.

 On Thu, Feb 13, 2020 at 1:30 PM David Davis 
 wrote:

> At our CI/CD meeting, Fabricio pointed out that anyone with read
> access to a repository can restart a Travis job. I think we could create a
> team in Github with all Pulp organization members that has read access to
> all of our repos. Then anyone could restart Travis jobs.
>
> Thoughts?
>
> 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

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

Re: [Pulp-dev] Read access in Github

[Ina Panova]

+1 this change will make things easier.



Regards,

Ina Panova
Senior 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 Fri, Feb 14, 2020 at 9:50 AM Tatiana Tereshchenko 
wrote:

> +1 to make restarting travis jobs available to everyone in pulp org
>
> On Fri, Feb 14, 2020 at 6:33 AM Brian Bouterse 
> wrote:
>
>> +1 this would be helpful
>>
>> On Thu, Feb 13, 2020, 8:44 PM Daniel Alley  wrote:
>>
>>> +1, I occasionally come across a repo where I can't even restart my own
>>> CI jobs, which is frustrating.  Probably even moreso to any new devs with
>>> less access.
>>>
>>> On Thu, Feb 13, 2020 at 1:30 PM David Davis 
>>> wrote:
>>>
 At our CI/CD meeting, Fabricio pointed out that anyone with read access
 to a repository can restart a Travis job. I think we could create a team in
 Github with all Pulp organization members that has read access to all of
 our repos. Then anyone could restart Travis jobs.

 Thoughts?

 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
>>>
>> ___
>> 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] Read access in Github

[Tatiana Tereshchenko]

+1 to make restarting travis jobs available to everyone in pulp org

On Fri, Feb 14, 2020 at 6:33 AM Brian Bouterse  wrote:

> +1 this would be helpful
>
> On Thu, Feb 13, 2020, 8:44 PM Daniel Alley  wrote:
>
>> +1, I occasionally come across a repo where I can't even restart my own
>> CI jobs, which is frustrating.  Probably even moreso to any new devs with
>> less access.
>>
>> On Thu, Feb 13, 2020 at 1:30 PM David Davis 
>> wrote:
>>
>>> At our CI/CD meeting, Fabricio pointed out that anyone with read access
>>> to a repository can restart a Travis job. I think we could create a team in
>>> Github with all Pulp organization members that has read access to all of
>>> our repos. Then anyone could restart Travis jobs.
>>>
>>> Thoughts?
>>>
>>> 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
>>
> ___
> 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