[Pulp-dev] Integer IDs in Pulp 3

[David Davis]

Before the release of Pulp 3.0 GA, I think it’s worth just checking in to
make sure we want to use UUIDs over integer based IDs. Changing from UUIDs
to ints would be a very easy change at this point  (1-2 lines of code) but
after GA ships, it would be hard if not impossible to switch.

I think there are a number of reasons why we might want to consider integer
IDs:

- Better performance all around for inserts[0], searches, indexing, etc
- Less storage required (4 bytes for int vs 16 byes for UUIDs)
- Hrefs would be shorter (e.g. /pulp/api/v3/repositories/1/)
- In line with other apps like Katello

There are some downsides to consider though:

- Integer ids expose info like how many records there are
- Can’t support sharding or multiple dbs (are we ever going to need this?)

[0] http://kccoder.com/mysql/uuid-vs-int-insert-performance/

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

Re: [Pulp-dev] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core

[Dennis Kliban]

+1

On Wed, May 23, 2018 at 10:41 AM, Brian Bouterse 
wrote:

> Through feedback on the issue and discussion in #pulp-dev, one small
> language revision [0] was added to PUP5 [1]. I believe we are ready to call
> a vote.
>
> Voting for PUP5 is open and will close on June 2nd. Please respond with
> your vote to this thread if you feel so inclined (lazy consensus). Barring
> any -1's cast, PUP5 will be merged on June 4th.
>
> [0]: https://github.com/richardfontana/pups/commit/
> 99fcd35e1cc396a1ba5a34555f093304dd07a333
> [1]: https://github.com/pulp/pups/pull/9
>
> -Brian
>
>
> On Tue, May 15, 2018 at 10:47 AM, Brian Bouterse 
> wrote:
>
>> @ipanova, I think of the core team as only maintaining pulp/pulp and
>> pulp/devel so I limit the scope of this to those repos only. I think
>> pulp_rpm (or any plugin) could adopt the CCRC without a PUP by following
>> the "Displaying the CRCC section
>> "
>> in their own repo.
>>
>> @dawalker, relicensing to GPLv3 is an alternative. It's not a bad option,
>> but it would be more complicated. Since every committer with even a single
>> line of current code is a copyright holder of the codebase, and it would
>> require a 100% signoff from all copyright holders, in practice this can be
>> difficult. Also someone may not even use that email anymore so it may not
>> even be possible. I haven't assessed how many Pulp3 committers we have
>> currently for the Pulp3 codebase.
>>
>> I was recently part of a relicensing which failed
>> , but it
>> shows what the process looks like:  https://github.com/python-bugz
>> illa/python-bugzilla/issues/25 If someone wants to champion switching to
>> GPLv3 and create an issue like that and get all the signoffs I'm not
>> opposed to relicensing to GPLv3 instead of adopting the CRCC.
>>
>> On Mon, May 14, 2018 at 1:34 PM, Dana Walker  wrote:
>>
>>> Other than the noted point that it takes time, is there any reason why
>>> Pulp should stay on the current license instead of moving to GPLv3 (one of
>>> the stated alternatives in this PUP)?  I don't know much about the
>>> differences currently, but it strikes me that our new Pulp 3 using Python 3
>>> would be a good fit for moving to a new license as well that has taken
>>> various things such as this enforcement issue into account and evolved over
>>> time.
>>>
>>> Thoughts?
>>>
>>> --Dana
>>>
>>> Dana Walker
>>>
>>> Associate Software Engineer
>>>
>>> Red Hat
>>>
>>> 
>>> 
>>>
>>> On Mon, May 14, 2018 at 6:28 AM, Ina Panova  wrote:
>>>
 *understanding



 
 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, May 14, 2018 at 12:27 PM, Ina Panova 
 wrote:

> To make a concrete example to prove my understating:
>
> Since pulp_rpm is maintained by core team we could adopt this change,
> meanwhile pulp_deb is beyond our control and we( core team) cannot enforce
> or influence this change.
> Yes?
>
>
>
> 
> 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 Tue, May 8, 2018 at 5:55 PM, Brian Bouterse 
> wrote:
>
>> A Pulp Update Proposal (PUP) pull request has been opened by the
>> go-to-lawyer for the Pulp community, Richard Fontana. The PUP is PUP5 
>> [0].
>> I don't want to paraphrase it here, so please read it [0] if you are
>> interested to understand what it does.
>>
>> I am proposing a period of questions/discussion via the list/PR and
>> then a call for a vote according to the process. All questions are 
>> welcome,
>> please ask.
>>
>>
>> # Timeline
>>
>> Today - May 18th mailing list and PR discussion
>> May 18th - formally call for a vote which would end 12 calendar days
>> from then May 30th
>> May 30th - Merge or reject
>>
>>
>> # FAQs
>>
>> Is this relicensing Pulp?
>> No. It's still GPLv2. This adopts a procedural enforment approach
>> within the existing license. See @rfontana's response here:
>> https://github.com/pulp/pups/pull/9#issuecomment-384523020
>>
>> Do all prior contributors need to sign off on this change?
>> No, because it's not a relicensing.
>>
>> Does this affect core, plugins, or both?
>> This PR is only scoped to affect the GPLv2 codebases maintained by
>> the core team. Plugins make their own decisions without PUPs. Initially
>> this would be pulp/pulp, and as other GPLv2 repositories are maintained 
>> by
>> the core team, it would apply to this in

Re: [Pulp-dev] is 3.0-dev branch ready to become master?

[Dennis Kliban]

On Wed, May 23, 2018 at 10:17 AM, Jeff Ortel  wrote:

>
>
> On 05/23/2018 06:20 AM, Brian Bouterse wrote:
>
> It sounds like there isn't much blocking this, but does that mean the devs
> should go ahead with planning and making the branching changes?
>
> Also I want to confirm: is the scope of this planned change only for
> pulp/pulp and pulp/devel repos for now?
>
>
> Agreed.
>
>
+1

>
>
> On Tue, May 22, 2018 at 10:56 AM, Patrick Creech 
> wrote:
>
>> On Mon, 2018-05-21 at 19:51 -0400, Dennis Kliban wrote:
>> > We need to start planning the creation of  a "2.17-dev" branch from the
>> current master and merging "3.0-dev" into "master". We would then create
>> new "2.Y-dev" branch after each "2.Y.0" release. All
>> > 3.0 work would then land on master.
>>
>> Might I suggest a y-version agnostic 2-dev or 2-master or similar branch
>> instead?  This would reflect better the state of the branch as "Pulp 2
>> master" and will prevent us from having to rename a lot
>> of items each release.
>>
> +1 to this naming.
>
> +1
>

+1


>
>
>
>> This would also help enforce our cherry-pick model of 'merge to master,
>> pick back to -release branches for releases' and will provide us a feature
>> branch to branch off our '2.y-release' branches
>> without adding in confusion each .y cycle.
>>
>>
>> > Do our release engineering tools support this change? If not, what
>> would it take to support it?
>>
>> Yes.  There'd be some small changes required to use the new master branch
>> insted of 'master', but that's it.
>>
>> > ___
>> > 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 
> listPulp-dev@redhat.comhttps://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] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core

[Brian Bouterse]

Through feedback on the issue and discussion in #pulp-dev, one small
language revision [0] was added to PUP5 [1]. I believe we are ready to call
a vote.

Voting for PUP5 is open and will close on June 2nd. Please respond with
your vote to this thread if you feel so inclined (lazy consensus). Barring
any -1's cast, PUP5 will be merged on June 4th.

[0]:
https://github.com/richardfontana/pups/commit/99fcd35e1cc396a1ba5a34555f093304dd07a333
[1]: https://github.com/pulp/pups/pull/9

-Brian


On Tue, May 15, 2018 at 10:47 AM, Brian Bouterse 
wrote:

> @ipanova, I think of the core team as only maintaining pulp/pulp and
> pulp/devel so I limit the scope of this to those repos only. I think
> pulp_rpm (or any plugin) could adopt the CCRC without a PUP by following
> the "Displaying the CRCC section
> "
> in their own repo.
>
> @dawalker, relicensing to GPLv3 is an alternative. It's not a bad option,
> but it would be more complicated. Since every committer with even a single
> line of current code is a copyright holder of the codebase, and it would
> require a 100% signoff from all copyright holders, in practice this can be
> difficult. Also someone may not even use that email anymore so it may not
> even be possible. I haven't assessed how many Pulp3 committers we have
> currently for the Pulp3 codebase.
>
> I was recently part of a relicensing which failed
> , but it
> shows what the process looks like:  https://github.com/python-
> bugzilla/python-bugzilla/issues/25 If someone wants to champion switching
> to GPLv3 and create an issue like that and get all the signoffs I'm not
> opposed to relicensing to GPLv3 instead of adopting the CRCC.
>
> On Mon, May 14, 2018 at 1:34 PM, Dana Walker  wrote:
>
>> Other than the noted point that it takes time, is there any reason why
>> Pulp should stay on the current license instead of moving to GPLv3 (one of
>> the stated alternatives in this PUP)?  I don't know much about the
>> differences currently, but it strikes me that our new Pulp 3 using Python 3
>> would be a good fit for moving to a new license as well that has taken
>> various things such as this enforcement issue into account and evolved over
>> time.
>>
>> Thoughts?
>>
>> --Dana
>>
>> Dana Walker
>>
>> Associate Software Engineer
>>
>> Red Hat
>>
>> 
>> 
>>
>> On Mon, May 14, 2018 at 6:28 AM, Ina Panova  wrote:
>>
>>> *understanding
>>>
>>>
>>>
>>> 
>>> 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, May 14, 2018 at 12:27 PM, Ina Panova  wrote:
>>>
 To make a concrete example to prove my understating:

 Since pulp_rpm is maintained by core team we could adopt this change,
 meanwhile pulp_deb is beyond our control and we( core team) cannot enforce
 or influence this change.
 Yes?



 
 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 Tue, May 8, 2018 at 5:55 PM, Brian Bouterse 
 wrote:

> A Pulp Update Proposal (PUP) pull request has been opened by the
> go-to-lawyer for the Pulp community, Richard Fontana. The PUP is PUP5 [0].
> I don't want to paraphrase it here, so please read it [0] if you are
> interested to understand what it does.
>
> I am proposing a period of questions/discussion via the list/PR and
> then a call for a vote according to the process. All questions are 
> welcome,
> please ask.
>
>
> # Timeline
>
> Today - May 18th mailing list and PR discussion
> May 18th - formally call for a vote which would end 12 calendar days
> from then May 30th
> May 30th - Merge or reject
>
>
> # FAQs
>
> Is this relicensing Pulp?
> No. It's still GPLv2. This adopts a procedural enforment approach
> within the existing license. See @rfontana's response here:
> https://github.com/pulp/pups/pull/9#issuecomment-384523020
>
> Do all prior contributors need to sign off on this change?
> No, because it's not a relicensing.
>
> Does this affect core, plugins, or both?
> This PR is only scoped to affect the GPLv2 codebases maintained by the
> core team. Plugins make their own decisions without PUPs. Initially this
> would be pulp/pulp, and as other GPLv2 repositories are maintained by the
> core team, it would apply to this in the future as well.
>
>
> [0]: https://github.com/pulp/pups/pull/9/files
>
> Thanks,
> Brian
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

[Jeff Ortel]

In classic relational modeling, using ID as the primary key is common 
practice.  Especially when ORMs are involved.  The "id" added by plugin 
writers is a natural key so naming it ID goes against convention.  Every 
field in base models used by plugins has potential for name collisions.  
Where does it end?  Every column having a pulp_ or _ prefix?  Plugins 
create relatively few tables and it doesn't seem unreasonable for plugin 
writers to select other names to resolve naming conflicts.


On 05/23/2018 07:50 AM, Brian Bouterse wrote:
Currently the Content model [0] has 'id' as it's primary key which is 
inherited from MasterModel here [1]. By naming our pk 'id', we are 
preventing plugin writers from also using that field. That field name 
is common for content types. For example: both RPM and Nuget content 
also expect to use the 'id' field to store data about the content type 
itself (not Pulp's pk). We learned about the Nuget incompatibility at 
ConfigMgmgtCamp from a community member. I learned about this issue 
with RPM from @dalley.


The only workaround a plugin writer has is to call their field 
'rpm_id' or something like that. I don't see how it's unavoidable that 
this renaming won't be passed directly onto the user for things like 
filtering, creating units, etc. I think that is an undesirable outcome 
just so that the Pulp pk can be named 'id'.


One option would be to rename 'id' to 'pulp_id' at the MasterModel. 
This is also somewhat ugly for Pulp developers, but it would be (a) 
crystal clear to the user in all cases and (b) allow Content writers 
to model their content types correctly.


Another option would be to rename the pk for 'Content' specifically 
and not at the MasterModel level. I think that would create more 
confusion than benefit so I recommend doing it at the MasterModel level.


What do you all think?

[0]: 
https://github.com/pulp/pulp/blob/6f492ee8fac94b8562dc62d87e6886869e052e7e/pulpcore/pulpcore/app/models/content.py#L106
[1]: 
https://github.com/pulp/pulp/blob/d1dc089890f167617fe9917af087d5587708296b/pulpcore/pulpcore/app/models/base.py#L25


-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] is 3.0-dev branch ready to become master?

[Jeff Ortel]

On 05/23/2018 06:20 AM, Brian Bouterse wrote:
It sounds like there isn't much blocking this, but does that mean the 
devs should go ahead with planning and making the branching changes?


Also I want to confirm: is the scope of this planned change only for 
pulp/pulp and pulp/devel repos for now?


Agreed.




On Tue, May 22, 2018 at 10:56 AM, Patrick Creech > wrote:


On Mon, 2018-05-21 at 19:51 -0400, Dennis Kliban wrote:
> We need to start planning the creation of  a "2.17-dev" branch
from the current master and merging "3.0-dev" into "master". We
would then create new "2.Y-dev" branch after each "2.Y.0" release. All
> 3.0 work would then land on master.

Might I suggest a y-version agnostic 2-dev or 2-master or similar
branch instead?  This would reflect better the state of the branch
as "Pulp 2 master" and will prevent us from having to rename a lot
of items each release.

+1 to this naming.

+1



This would also help enforce our cherry-pick model of 'merge to
master, pick back to -release branches for releases' and will
provide us a feature branch to branch off our '2.y-release' branches
without adding in confusion each .y cycle.


> Do our release engineering tools support this change? If not,
what would it take to support it?

Yes.  There'd be some small changes required to use the new master
branch insted of 'master', but that's it.

> ___
> 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] Pulp CLI MVP User Stories

[Bihan Zhang]

Quick correction to 1). My goal throughout the next week is to see if I can
get Tab completable LIST working.
In particular I would like the user to be able to run `pulp-cli
repositories  ` to generate a list of repositories. and `pulp-cli
repositories --repository-pk=UUID versions ` to list out possible
repository versions.
This should be possible because the cli tool that we're basing our cli off
of is aware of our REST API schema.
I would also like to get general Tab complete working, and see how
difficult it would be to add a more complex command that would require more
than 1 REST API call.

And if time permitted I will see if I can get Task polling to work.

On Tue, May 22, 2018 at 6:56 PM, Dennis Kliban  wrote:

> A few of us[0] met earlier today to discuss further steps with the CLI. We
> agreed on the following next steps:
>
> 1) Over the next week @bizhang is going to explore how we can add value to
> coreapi-cli[1] - in particular see about adding polling for operations that
> return tasks
>
> 2) We want to send a note out to pulp-list to ask users the following
> questions:
>
> - What commands or functionality in the CLI do you rely on the most?
> - Are there things you wish the CLI had or did?
> - Why do you use the CLI over using the REST API directly?
> - Do you strictly use the CLI or do you use other things like Katello or
> the REST API?
> - Would you prefer a CLI or a basic web UI (that leverages something like
> Django admin)?
>
>
> [0] dawalker, daviddavis, bizhang, asmacdo, dkliban
> [1] http://www.coreapi.org/
>
> On Mon, May 21, 2018 at 11:26 AM, Bihan Zhang  wrote:
>
>> I'm +1 to shipping a CLI out with our GA. According to our last community
>> survey ~47% of users used a CLI, vs ~33% using a REST API (the last ~20%
>> uses Katello/Sat UI/Foreman) [0].
>>
>> I think there should be some single call operations that the CLI does
>> support- for example creating a pulp_python remote from a requirements.txt.
>> The pulp_python REST API remote endpoint expects a dictionary of projects,
>> and specifiers; the same information present in a requirements.txt, but it
>> would be inappropriate for the endpoint to only support remote creation
>> from a requirements.txt, since there's many other formats this information
>> might be present in (Pipfile, Pipfile.lock, pyproject.toml, etc)
>> So the REST API should be left generic, but the CLI should support
>> parsing these files and sending a formatted request to the endpoint.
>>
>> The role of CLI should be to make workflows easier but I think for the GA
>> we should have minimal workflows. We should start with a 1-1 mapping for
>> core endpoints, with perhaps one additional 'pulp-cli quickstart' command
>> that will create a repository, a remote, a publisher, and a distribution
>> with a single command. Any additional workflow features can be added by
>> user request.
>>
>> And plugins can ship out their own CLI features (or not) separately.
>>
>> [0] https://pulpproject.org/2017/08/08/community-survey-results/
>>
>>
>>
>> On Mon, May 21, 2018 at 10:24 AM, Bryan Kearney 
>> wrote:
>>
>>> On 05/21/2018 09:56 AM, David Davis wrote:
>>> >> that the CLI does no "single call" operations. Those are already
>>> > handled veyr well by httpie.
>>> >
>>> > If a user wants for example to update an object
>>> > (repo/remote/distribution/etc), then they have to switch from the CLI
>>> to
>>> > httpie?
>>>
>>>
>>> I assume pulp is focused on sysadmins, yes? If so, are there other tools
>>> targeted at this audience that does not have a cli?
>>>
>>> -- bk
>>>
>>>
>>>
>>>
>>> ___
>>> 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] 'id' versus 'pulp_id' on Content

[Austin Macdonald]

In Pulp 2, having id fields bit us really badly. The reason may have been
specific to Mongoengine, but my understanding is that it is bad practice
anyway.

On Wed, May 23, 2018 at 9:22 AM, David Davis  wrote:

> Correct me if I’m wrong but don’t we call pk in most places instead of id?
> If so, it would seem like replacing id with pulp_id wouldn’t be that ugly.
>
> Also, I wonder about the created and last_updated fields. Seems like those
> could cause conflicts in the future too. At the very least, it might be
> nice to document which field names are reserved on the Content model.
>
> David
>
> On Wed, May 23, 2018 at 8:50 AM, Brian Bouterse 
> wrote:
>
>> Currently the Content model [0] has 'id' as it's primary key which is
>> inherited from MasterModel here [1]. By naming our pk 'id', we are
>> preventing plugin writers from also using that field. That field name is
>> common for content types. For example: both RPM and Nuget content also
>> expect to use the 'id' field to store data about the content type itself
>> (not Pulp's pk). We learned about the Nuget incompatibility at
>> ConfigMgmgtCamp from a community member. I learned about this issue with
>> RPM from @dalley.
>>
>> The only workaround a plugin writer has is to call their field 'rpm_id'
>> or something like that. I don't see how it's unavoidable that this renaming
>> won't be passed directly onto the user for things like filtering, creating
>> units, etc. I think that is an undesirable outcome just so that the Pulp pk
>> can be named 'id'.
>>
>> One option would be to rename 'id' to 'pulp_id' at the MasterModel. This
>> is also somewhat ugly for Pulp developers, but it would be (a) crystal
>> clear to the user in all cases and (b) allow Content writers to model their
>> content types correctly.
>>
>
>> Another option would be to rename the pk for 'Content' specifically and
>> not at the MasterModel level. I think that would create more confusion than
>> benefit so I recommend doing it at the MasterModel level.
>>
>> What do you all think?
>>
>> [0]: https://github.com/pulp/pulp/blob/6f492ee8fac94b8562dc62d87e
>> 6886869e052e7e/pulpcore/pulpcore/app/models/content.py#L106
>> [1]: https://github.com/pulp/pulp/blob/d1dc089890f167617fe9917af0
>> 87d5587708296b/pulpcore/pulpcore/app/models/base.py#L25
>>
>> -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] 'id' versus 'pulp_id' on Content

[Daniel Alley]

Maybe

_created
> _id
> _last_updated
>

?

I'm not sure whether we use pk or id more often, but we use both quite a
lot.

On Wed, May 23, 2018 at 9:22 AM, David Davis  wrote:

> Correct me if I’m wrong but don’t we call pk in most places instead of id?
> If so, it would seem like replacing id with pulp_id wouldn’t be that ugly.
>
> Also, I wonder about the created and last_updated fields. Seems like those
> could cause conflicts in the future too. At the very least, it might be
> nice to document which field names are reserved on the Content model.
>
> David
>
> On Wed, May 23, 2018 at 8:50 AM, Brian Bouterse 
> wrote:
>
>> Currently the Content model [0] has 'id' as it's primary key which is
>> inherited from MasterModel here [1]. By naming our pk 'id', we are
>> preventing plugin writers from also using that field. That field name is
>> common for content types. For example: both RPM and Nuget content also
>> expect to use the 'id' field to store data about the content type itself
>> (not Pulp's pk). We learned about the Nuget incompatibility at
>> ConfigMgmgtCamp from a community member. I learned about this issue with
>> RPM from @dalley.
>>
>> The only workaround a plugin writer has is to call their field 'rpm_id'
>> or something like that. I don't see how it's unavoidable that this renaming
>> won't be passed directly onto the user for things like filtering, creating
>> units, etc. I think that is an undesirable outcome just so that the Pulp pk
>> can be named 'id'.
>>
>> One option would be to rename 'id' to 'pulp_id' at the MasterModel. This
>> is also somewhat ugly for Pulp developers, but it would be (a) crystal
>> clear to the user in all cases and (b) allow Content writers to model their
>> content types correctly.
>>
>
>> Another option would be to rename the pk for 'Content' specifically and
>> not at the MasterModel level. I think that would create more confusion than
>> benefit so I recommend doing it at the MasterModel level.
>>
>> What do you all think?
>>
>> [0]: https://github.com/pulp/pulp/blob/6f492ee8fac94b8562dc62d87e
>> 6886869e052e7e/pulpcore/pulpcore/app/models/content.py#L106
>> [1]: https://github.com/pulp/pulp/blob/d1dc089890f167617fe9917af0
>> 87d5587708296b/pulpcore/pulpcore/app/models/base.py#L25
>>
>> -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] 'id' versus 'pulp_id' on Content

[David Davis]

Correct me if I’m wrong but don’t we call pk in most places instead of id?
If so, it would seem like replacing id with pulp_id wouldn’t be that ugly.

Also, I wonder about the created and last_updated fields. Seems like those
could cause conflicts in the future too. At the very least, it might be
nice to document which field names are reserved on the Content model.

David

On Wed, May 23, 2018 at 8:50 AM, Brian Bouterse  wrote:

> Currently the Content model [0] has 'id' as it's primary key which is
> inherited from MasterModel here [1]. By naming our pk 'id', we are
> preventing plugin writers from also using that field. That field name is
> common for content types. For example: both RPM and Nuget content also
> expect to use the 'id' field to store data about the content type itself
> (not Pulp's pk). We learned about the Nuget incompatibility at
> ConfigMgmgtCamp from a community member. I learned about this issue with
> RPM from @dalley.
>
> The only workaround a plugin writer has is to call their field 'rpm_id' or
> something like that. I don't see how it's unavoidable that this renaming
> won't be passed directly onto the user for things like filtering, creating
> units, etc. I think that is an undesirable outcome just so that the Pulp pk
> can be named 'id'.
>
> One option would be to rename 'id' to 'pulp_id' at the MasterModel. This
> is also somewhat ugly for Pulp developers, but it would be (a) crystal
> clear to the user in all cases and (b) allow Content writers to model their
> content types correctly.
>

> Another option would be to rename the pk for 'Content' specifically and
> not at the MasterModel level. I think that would create more confusion than
> benefit so I recommend doing it at the MasterModel level.
>
> What do you all think?
>
> [0]: https://github.com/pulp/pulp/blob/6f492ee8fac94b8562dc62d87e
> 6886869e052e7e/pulpcore/pulpcore/app/models/content.py#L106
> [1]: https://github.com/pulp/pulp/blob/d1dc089890f167617fe9917af0
> 87d5587708296b/pulpcore/pulpcore/app/models/base.py#L25
>
> -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] 'id' versus 'pulp_id' on Content

[Brian Bouterse]

Currently the Content model [0] has 'id' as it's primary key which is
inherited from MasterModel here [1]. By naming our pk 'id', we are
preventing plugin writers from also using that field. That field name is
common for content types. For example: both RPM and Nuget content also
expect to use the 'id' field to store data about the content type itself
(not Pulp's pk). We learned about the Nuget incompatibility at
ConfigMgmgtCamp from a community member. I learned about this issue with
RPM from @dalley.

The only workaround a plugin writer has is to call their field 'rpm_id' or
something like that. I don't see how it's unavoidable that this renaming
won't be passed directly onto the user for things like filtering, creating
units, etc. I think that is an undesirable outcome just so that the Pulp pk
can be named 'id'.

One option would be to rename 'id' to 'pulp_id' at the MasterModel. This is
also somewhat ugly for Pulp developers, but it would be (a) crystal clear
to the user in all cases and (b) allow Content writers to model their
content types correctly.

Another option would be to rename the pk for 'Content' specifically and not
at the MasterModel level. I think that would create more confusion than
benefit so I recommend doing it at the MasterModel level.

What do you all think?

[0]:
https://github.com/pulp/pulp/blob/6f492ee8fac94b8562dc62d87e6886869e052e7e/pulpcore/pulpcore/app/models/content.py#L106
[1]:
https://github.com/pulp/pulp/blob/d1dc089890f167617fe9917af087d5587708296b/pulpcore/pulpcore/app/models/base.py#L25

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

Re: [Pulp-dev] is 3.0-dev branch ready to become master?

[Brian Bouterse]

It sounds like there isn't much blocking this, but does that mean the devs
should go ahead with planning and making the branching changes?

Also I want to confirm: is the scope of this planned change only for
pulp/pulp and pulp/devel repos for now?


On Tue, May 22, 2018 at 10:56 AM, Patrick Creech  wrote:

> On Mon, 2018-05-21 at 19:51 -0400, Dennis Kliban wrote:
> > We need to start planning the creation of  a "2.17-dev" branch from the
> current master and merging "3.0-dev" into "master". We would then create
> new "2.Y-dev" branch after each "2.Y.0" release. All
> > 3.0 work would then land on master.
>
> Might I suggest a y-version agnostic 2-dev or 2-master or similar branch
> instead?  This would reflect better the state of the branch as "Pulp 2
> master" and will prevent us from having to rename a lot
> of items each release.
>
+1 to this naming.


> This would also help enforce our cherry-pick model of 'merge to master,
> pick back to -release branches for releases' and will provide us a feature
> branch to branch off our '2.y-release' branches
> without adding in confusion each .y cycle.
>
>
> > Do our release engineering tools support this change? If not, what would
> it take to support it?
>
> Yes.  There'd be some small changes required to use the new master branch
> insted of 'master', but that's it.
>
> > ___
> > 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