Re: [Pulp-dev] Installing RQ

[Daniel Alley]

Yup.

(pulp) [vagrant@pulp3 pulp_python]$ which rq
> ~/.virtualenvs/pulp/bin/rq
>

Inside a virtualenv everything is kind of weird, for example "pip" and
"python" both map to the python 3 variants instead of the python 2
variants, which you would typically expect those names to map to.

On Tue, Aug 7, 2018 at 2:46 PM, David Davis  wrote:

> In the vagrant environment, there is no /usr/bin/rq. Instead it uses the
> rq executable inside the pulp virtualenv:
>
> https://github.com/pulp/devel/blob/0a37a02c1bbe809509c0215a0ff349
> 15f090068e/ansible/roles/systemd/templates/pulp_resource_manager.j2#L11
>
> David
>
>
> On Tue, Aug 7, 2018 at 2:38 PM Jeff Ortel  wrote:
>
>> It has been my experience that /usr/bin/rq is only installed by 'pip
>> install rq' and it's not installed by 'pip3 install rq'.
>>
>> The only work around I have found is to:
>>
>> 1. pip install rq
>> 2. pip3 install rq
>> 3. edit /usr/bin/rq to use python3.
>>
>> How is this handled in the vagrant environment?  It's not obvious to me
>> looking at pulp-devel.
>>
>> ___
>> 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] Installing RQ

[David Davis]

In the vagrant environment, there is no /usr/bin/rq. Instead it uses the rq
executable inside the pulp virtualenv:

https://github.com/pulp/devel/blob/0a37a02c1bbe809509c0215a0ff34915f090068e/ansible/roles/systemd/templates/pulp_resource_manager.j2#L11

David


On Tue, Aug 7, 2018 at 2:38 PM Jeff Ortel  wrote:

> It has been my experience that /usr/bin/rq is only installed by 'pip
> install rq' and it's not installed by 'pip3 install rq'.
>
> The only work around I have found is to:
>
> 1. pip install rq
> 2. pip3 install rq
> 3. edit /usr/bin/rq to use python3.
>
> How is this handled in the vagrant environment?  It's not obvious to me
> looking at pulp-devel.
>
> ___
> 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] Installing RQ

[Jeff Ortel]

It has been my experience that /usr/bin/rq is only installed by 'pip 
install rq' and it's not installed by 'pip3 install rq'.


The only work around I have found is to:

1. pip install rq
2. pip3 install rq
3. edit /usr/bin/rq to use python3.

How is this handled in the vagrant environment?  It's not obvious to me 
looking at pulp-devel.


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

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[Dennis Kliban]

This seems like a regression from behavior in 2.16.4. It was introduced
with the new features added in 2.17. We should run the same test against
2.16.4 and see the results.

On Tue, Aug 7, 2018 at 2:23 PM, Jeremy Audet  wrote:

> #3875 was discovered when running tests against nightly RPMs.
>
> ___
> 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] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[Jeremy Audet]

#3875 was discovered when running tests against nightly RPMs.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[David Davis]

Were the automated tests running against master or a nightly build? Looks
like the bug was introduced in the rich dependency work which hasn’t been
released yet:

https://github.com/dralley/pulp_rpm/commit/f85007c0e6cc93e4320f12dfd9c7568707c25759#diff-9c78b41ed1e2ec586589ed71d730b93eR231

That said, #3875 will be included in the 2.17.0 release.

David


On Tue, Aug 7, 2018 at 1:49 PM Jeremy Audet  wrote:

> I don't think that's the case. This regression was detected by existing
> automated tests that were added on September 6th, 2016. See:
> https://github.com/PulpQE/pulp-smash/commit/346244cd5cc3aac4ec2551afe1fd38c996a41bf6
> ___
> 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] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[Jeremy Audet]

I don't think that's the case. This regression was detected by existing
automated tests that were added on September 6th, 2016. See:
https://github.com/PulpQE/pulp-smash/commit/346244cd5cc3aac4ec2551afe1fd38c996a41bf6
___
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

[Dana Walker]

While I have not given your suggestion a lot of thought yet, it seems
sound.  I'd been wondering about the state of this discussion recently and
had already decided I'm onboard with whatever the majority decides merely
to get us moving again.

I want us to make good decisions so as to increase adoption of Pulp, but
for that to even matter, we need it finished and to swap to Pulp 3 from
Pulp 2.  At this point, I'm willing to say let's just pick what most prefer
and move forward (and that goes for any of these design discussions) and if
given the power of hindsight we'd like to make different decisions, we can
do so in Pulp 4.

--Dana

Dana Walker

Associate Software Engineer

Red Hat




On Tue, Aug 7, 2018 at 1:23 PM, Daniel Alley  wrote:

> With this in mind, I'm thinking that the leading underscore (_) could be
>> used broadly to denote *generated* *or metadata* fields and the
>> following would be reasonable:
>>
>
> I'm on board with this, I think your revised description of what '_' could
> symbolize makes a lot of sense.
>
>
>
> On Tue, Aug 7, 2018 at 12:47 PM, Jeff Ortel  wrote:
>
>> After long consideration, I have had a change of heart about this.  I
>> think.  In short, Pulp's data model has unique requirements that make it
>> acceptable to deviate from common convention regarding ID as the PK.
>> Mainly that the schema is extensible by plugin writers.  Given the plugin
>> architecture, I think it's reasonable to think of "core" fields like: ID,
>> CREATED and LAST_MODIFIED as metadata.  Although, the ID is harder to fit
>> in this semantic, I think it's reasonable to do for consistency and to
>> support the user query use-case re: content having an natural ID
>> attribute.  Taking this further, the *href* attributes *could* be though
>> of in the same category.
>>
>> With this in mind, I'm thinking that the leading underscore (_) could be
>> used broadly to denote *generated* *or metadata* fields and the
>> following would be reasonable:
>>
>> _id
>> _created
>> _last_updated
>>
>> _href
>> _added_href
>> _removed_href
>> _content_href
>>
>> I highly value consistency so this applies to the entire schema.
>>
>> This will introduce a few fairly odd things into the schema that I
>> *suppose* we can live with.
>>
>> - Two fields on *some* tables named (ID ,  _ID).  To mitigate confusion,
>> we should serialize the *pk* and not* _id*.  This will also be
>> consistent with *pk* parameters passed in.
>> - I expect django will generate foreign key fields with double
>> understores.  Eg: content__id
>>
>> I'm still -1 for using a *pulp_* prefix.
>>
>> Thoughts?
>>
>>
>> On 06/18/2018 01:15 PM, Daniel Alley wrote:
>>
>> I'm -1 on going the underscore idea, partly because of the aforementioned
>> confusion issue, but also partly because but I've noticed that in our API,
>> the "underscore" basically has a semantic meeting of "href, [which is]
>> generated on the fly, not stored in the db".
>>
>> Specifically:
>>
>>- '_href'
>>- '_added_href'
>>- '_removed_href'
>>- '_content_href'
>>
>> So I think if we use a prefix, we should avoid using one that already has
>> a semantic meaning (I don't know whether we actually planned for that to be
>> the case, but I think it's a useful pattern / distinction and I don't think
>> we should mess with 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

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[Daniel Alley]

I think it's because the problem only ever existed on master and never made
it into to a release.

On Tue, Aug 7, 2018 at 12:55 PM, Jeremy Audet  wrote:

> https://pulp.plan.io/issues/3875 is a regression and does not appear to
> be included in the list of fixed bugs, above.
>
> ___
> 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]

>
> With this in mind, I'm thinking that the leading underscore (_) could be
> used broadly to denote *generated* *or metadata* fields and the following
> would be reasonable:
>

I'm on board with this, I think your revised description of what '_' could
symbolize makes a lot of sense.



On Tue, Aug 7, 2018 at 12:47 PM, Jeff Ortel  wrote:

> After long consideration, I have had a change of heart about this.  I
> think.  In short, Pulp's data model has unique requirements that make it
> acceptable to deviate from common convention regarding ID as the PK.
> Mainly that the schema is extensible by plugin writers.  Given the plugin
> architecture, I think it's reasonable to think of "core" fields like: ID,
> CREATED and LAST_MODIFIED as metadata.  Although, the ID is harder to fit
> in this semantic, I think it's reasonable to do for consistency and to
> support the user query use-case re: content having an natural ID
> attribute.  Taking this further, the *href* attributes *could* be though
> of in the same category.
>
> With this in mind, I'm thinking that the leading underscore (_) could be
> used broadly to denote *generated* *or metadata* fields and the following
> would be reasonable:
>
> _id
> _created
> _last_updated
>
> _href
> _added_href
> _removed_href
> _content_href
>
> I highly value consistency so this applies to the entire schema.
>
> This will introduce a few fairly odd things into the schema that I
> *suppose* we can live with.
>
> - Two fields on *some* tables named (ID ,  _ID).  To mitigate confusion,
> we should serialize the *pk* and not* _id*.  This will also be consistent
> with *pk* parameters passed in.
> - I expect django will generate foreign key fields with double
> understores.  Eg: content__id
>
> I'm still -1 for using a *pulp_* prefix.
>
> Thoughts?
>
>
> On 06/18/2018 01:15 PM, Daniel Alley wrote:
>
> I'm -1 on going the underscore idea, partly because of the aforementioned
> confusion issue, but also partly because but I've noticed that in our API,
> the "underscore" basically has a semantic meeting of "href, [which is]
> generated on the fly, not stored in the db".
>
> Specifically:
>
>- '_href'
>- '_added_href'
>- '_removed_href'
>- '_content_href'
>
> So I think if we use a prefix, we should avoid using one that already has
> a semantic meaning (I don't know whether we actually planned for that to be
> the case, but I think it's a useful pattern / distinction and I don't think
> we should mess with 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

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[Jeremy Audet]

https://pulp.plan.io/issues/3875 is a regression and does not appear to be
included in the list of fixed bugs, above.
___
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

[Jeff Ortel]

After long consideration, I have had a change of heart about this. I 
think.  In short, Pulp's data model has unique requirements that make it 
acceptable to deviate from common convention regarding ID as the PK.  
Mainly that the schema is extensible by plugin writers. Given the plugin 
architecture, I think it's reasonable to think of "core" fields like: 
ID, CREATED and LAST_MODIFIED as metadata. Although, the ID is harder to 
fit in this semantic, I think it's reasonable to do for consistency and 
to support the user query use-case re: content having an natural ID 
attribute.  Taking this further, the /href/ attributes /could/ be though 
of in the same category.


With this in mind, I'm thinking that the leading underscore (_) could be 
used broadly to denote /generated/ /or metadata/ fields and the 
following would be reasonable:


_id
_created
_last_updated

_href
_added_href
_removed_href
_content_href

I highly value consistency so this applies to the entire schema.

This will introduce a few fairly odd things into the schema that I 
/suppose/ we can live with.


- Two fields on /some/ tables named (ID ,  _ID).  To mitigate confusion, 
we should serialize the *pk* and not*_id*. This will also be consistent 
with *pk* parameters passed in.
- I expect django will generate foreign key fields with double 
understores.  Eg: content__id


I'm still -1 for using a /pulp_/ prefix.

Thoughts?


On 06/18/2018 01:15 PM, Daniel Alley wrote:
I'm -1 on going the underscore idea, partly because of the 
aforementioned confusion issue, but also partly because but I've 
noticed that in our API, the "underscore" basically has a semantic 
meeting of "href, [which is] generated on the fly, not stored in the db".


Specifically:

  * '_href'
  * '_added_href'
  * '_removed_href'
  * '_content_href'

So I think if we use a prefix, we should avoid using one that already 
has a semantic meaning (I don't know whether we actually planned for 
that to be the case, but I think it's a useful pattern / distinction 
and I don't think we should mess with it).


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

[Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

[Ina Panova]

All outstanding issues and regressions were resolved.

The code for 2.17.0 is now frozen. Check the list of work completed and
prepared for the release:

https://tinyurl.com/y96j92hl



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."
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, July 31

[Brian Bouterse]

On Mon, Aug 6, 2018 at 6:50 PM, Robin Chan  wrote:

> I am checking in on build status.
> Thanks, David for sending a note about newly discovered [4] and marking it
> as required. Let's continue to use [0] to check that we have all the PR in.
>
> Please check my understanding below on a few items.
> 1. The commit for [1] should be included in 2.17.0 even thought it missed
> 2.16.3 because we will use a fresh branch from master when starting the
> 2.17 build process. No new issues need be created, correct?
>
Correct because any .0 release is a fresh branch from 2-master so all
commits merged there like the extra one in [1] will be included.

2. I marked the following issues as part of 2.17.0 [0] as I thought they
> were missing from our list - please speak up if you disagree (or got any of
> this wrong):
>  - weak dependency [2] based on conversations during internal meeting
>  - one of the issues/regressions for which we delayed the build [3]
>
Those issues look right to include. In terms of bookkeeping, that change
puts them on the release/milestone which is great. The Platform Target
Release which is used by our automation during releases still needs to be
set. The milestone is good to plan for what work will be done even for work
that is still in ASSIGNED. The Platform Target Release should only be set
after the issue is MODIFIED. I've not made any changes. If I should or if
there are questions, lmk how I can help.

For the docker one specifically, that has different version numbers, should
it be on 2.17.0 or $next_docker_version? I'm not sure.

>
> Thanks,
> Robin
>
> [0] https://tinyurl.com/y96j92hl
> [1] https://pulp.plan.io/issues/3090
> [2] https://pulp.plan.io/issues/3847
> [3] https://pulp.plan.io/issues/3899
> [4] https://pulp.plan.io/issues/3904
>
>
> On Fri, Aug 3, 2018 at 5:30 AM, Ina Panova  wrote:
>
>> 2.17.0 Release is delayed due to unforeseen discovered issues.
>>
>> For the new tentative dates please check the release schedule [0]
>>
>> Thank you.
>>
>> [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Schedule
>>
>>
>>
>> 
>> 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 Wed, Aug 1, 2018 at 4:17 AM, Robin Chan  wrote:
>>
>>> All Pulp2 core or plugin code included in the 2.17.0 release should
>>> already be:
>>> a) merged to master
>>> b) associated with a story, refactor, task or a bugfix issue.
>>>
>>> Sorry for the late notice, our release contact is out sick unexpectedly
>>> and I failed to handle this as the backup.
>>>
>>> The list of features & bug fixes to be included in 2.17.0 can be found
>>> here[0]. The beta schedule[1] shows the 2.17.0 beta release date as
>>> Tuesday August 7th.
>>>
>>> [0] https://tinyurl.com/y96j92hl
>>> [1] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Schedule
>>>
>>>
>>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Proposed Update to PUP-4

[Dana Walker]

The PUP passed, and was merged today.


Thanks all for participating,

--Dana

Dana Walker

Associate Software Engineer

Red Hat




On Fri, Jul 27, 2018 at 10:10 AM, Dennis Kliban  wrote:

> +1
>
> On Fri, Jul 27, 2018 at 9:57 AM, Tatiana Tereshchenko  > wrote:
>
>> +1
>>
>>
>> On Tue, Jul 24, 2018 at 8:10 PM, Brian Bouterse 
>> wrote:
>>
>>> +1 Thank you!
>>>
>>> On Tue, Jul 24, 2018 at 11:37 AM, Dana Walker 
>>> wrote:
>>>
 A PR [0] is up with a proposed update to PUP-4: Code of Conduct [1].

 The proposal changes the details of where the Code of Conduct is to be
 displayed.

 Please review and provide any comments, suggestions, and +/- 1's to the
 proposed changes by Sunday August 5.

 [0] https://github.com/pulp/pups/pull/12
 [1] https://github.com/pulp/pups/blob/master/pup-0004.md

 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


>>>
>>> ___
>>> 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] How to retrieve file via pulp API?

[Dennis Kliban]

When docker communicates with Crane, the docker client receives redirects
that specify the full path to all the files you are interested in. Docker
then follows the redirects to retrieve the content from Pulp. The path for
the redirects is formed using the docker_web_distributor config. The
redirects are stored in JSON files. The format for the file is documented
here[0]. Here[1] is an example of a URL for a manifest in repository with
id 'test-repo-id':


[0]  https://docs.pulpproject.org/plugins/pulp_docker/tech-
reference/distributor.html#redirect-file
[1] https://pulp-hostname/pulp/docker/v2/test-repo-id/manifests/2/sha256:
fe9261ebcce85f6e0657957a129dbd26d3897483ba0b9ab564bc81041906







On Sat, Aug 4, 2018 at 11:15 AM, Tom McKay  wrote:

> I'd like to retrieve a file that is associated referenced in pulp, is
> there an API for that? I have info in foreman for a docker manifest (pulp
> id, storage path, etc) but am unsure how to retrieve it via pulp's API.
>
> ___
> 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