Re: [Pulp-dev] issue #3360 follow up

[Austin Macdonald]

+1 @daviddavis, @dkliban, @jortel's plan.

I've added a comment to the issue, https://pulp.plan.io/issues/3360#note-11

On Fri, Feb 23, 2018 at 2:25 PM, David Davis  wrote:

> After meeting with @dkliban and @jortel to discuss #3360, we came up with
> an alternative proposal that has some small tweaks. Basically, all three
> parameters (add_content, remove_content, and base_version) could be used
> together and the parameter for the repository version would be called
> ‘base_version’. I think the parameter name of base_version make sense
> because it aligns with the code and since we’re allowing all three
> parameters to be used in conjunction, the repo version is a sort of base
> that you build on by adding/removing content.
>
> Would like to get people’s thoughts on this alternate proposal.
>
>
> David
>
> On Mon, Feb 19, 2018 at 12:51 PM, Jeff Ortel  wrote:
>
>> I'm concerned that having a single endpoint with a complicated
>> combination of parameters that control how the endpoint behaves isn't
>> ideal.  Especially since some of the parameters are mutually exclusive.
>> Seems that having /api/v3/repositories//versions/ endpoint do one
>> thing is cleaner.  Should we go with the approach of simpler endpoints, I
>> would suggest something like  /api/v3/repositories//versions/clone/
>> that accepts parameter "version" in the body that is an href to an existing
>> version.  If we go with a single complex endpoint, I'd suggest
>> "cone_version" as the parameter.
>>
>> As an aside, the existing add_content_units and remove_content_units
>> should be renamed.  "_content" is already plural so adding the "_units" is
>> the singular form that's made plural.  Should just be add_content,
>> remote_content.
>>
>>
>> On 02/16/2018 03:30 PM, Dennis Kliban wrote:
>>
>> Earlier today several of us discussed issue 3360[0]. In our discussion we
>> concluded that it is valuable for users to be able to create exact copies
>> of repository versions within a repository and across different
>> repositories. I have updated the issue to reflect what we discussed. We
>> decided that this use case should be included in the MVP.
>>
>> The issue currently states that the parameter will be called
>> 'mirror_repository_version'. However, we could not agree if that is
>> actually the best name for this parameter. Suggestions for a better name
>> are welcome on this thread or as comments on the issue.
>>
>>
>> [0] https://pulp.plan.io/issues/3360
>>
>> -Dennis
>>
>>
>> ___
>> 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
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] IBM's yum "repository" vs a normal sane repository

[Will Darton]

 I know this has been a day, but it took me a while to circle back around
to it. But in case anyone else runs into this, I have successfully gotten
an IBM AIX system, to use IBM's yum/rpm to retrieve content from IBM
mirror'd repositories in Foreman and Red Hat Satellite.

What was missing were the libxml2 rpms , though yum wouldn't say exactly
that, and there isn't a fancy ldconfig command I know on AIX

In the end, needed these:
/ # uname -a
AIX hostname  2 7 00FAF6804C00

/ # rpm -qa | egrep 'libxml|python|yum|rpm' | sort
AIX-rpm-7.2.2.0-6.ppc
libxml2-2.9.5-1.ppc
libxml2-python-2.9.5-1.ppc
python-2.7.10-1.ppc
python-devel-2.7.10-1.ppc
python-iniparse-0.4-1.noarch
python-pycurl-7.19.3-1.ppc
python-tools-2.7.10-1.ppc
python-urlgrabber-3.10.1-1.noarch
yum-3.4.3-5.noarch
yum-metadata-parser-1.1.4-2.ppc

And a repo conf such as this:

[Satellite_AIX_Toolbox_noarch]
name=AIX noarch repository
sslclientcert = /opt/freeware/etc/pki/entitlement.pem
sslclientkey = /opt/freeware/etc/pki/entitlement-key.pem
sslcacert = /opt/freeware/etc/pki/cacert.pem
sslverify=1
baseurl=https://capsule.example.com/pulp/repos/ORG/LAB/eue-aix72-server-ppc/
custom/eue_ibm_aix/noarch/
enabled=1
gpgcheck=0

# yum repolist
repo id
repo name
  status
AIX_Toolbox_noarch
   AIX noarch mirror
 79
AIX_Toolbox_ppc
AIX PPC mirror
 355
AIX_Toolbox_ppc-7.2
AIX PPC mirror
  10
Satellite_AIX_Toolbox_noarch
   AIX noarch repository
 79

now off to conquer subscription-manager
Thanks for the advise!


Will Darton
7032322344
RHC{A,DS,E,VA,SA} 130-047-673

“There is excellence all around you. You need only to be aware to stop and
savor it.” - Anton Ego

On Mon, Jan 29, 2018 at 10:58 AM, Will Darton  wrote:

> So the source of the mirror is here:
>
> https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/
> RPMS/ppc-7.2/repodata/9d2f104b8df5e04cb901daf712e21d
> 547df7cebc383eca3a4c757afa03708df3-primary.xml.gz
>
> And I extracted the downloaded primary
> https://pastebin.com/Wm9XNzph
>
> Appreciate any guidance. I got distracted working on some other foreman
> things for AIX
>
> Will Darton
> 7032322344 <(703)%20232-2344>
> RHC{A,DS,E,VA,SA} 130-047-673
>
> “There is excellence all around you. You need only to be aware to stop
> and savor it.” - Anton Ego
>
> On Mon, Jan 22, 2018 at 5:20 PM, Sean Myers  wrote:
>
>> On 01/19/2018 02:36 PM, Will Darton wrote:
>> > Brian thanks for the response
>> > So pardon my newb question here, but I've not delved this deep in yum
>> repo
>> > xmls..
>> > Would the formatting of the xml make a difference?
>>
>> Not Brian, but the short answer is "no". Long answer below.
>>
>> > In the foreman generated primary.xml I have a stanza such as this
>> > 
>> > http://linux.duke.edu/metadata/common;
>> > xmlns:rpm="http://linux.duke.edu/metadata/rpm;>
>> >   libgomp
>> >   ppc
>> >   
>> >   081c485b68e30e6c3f53a3b0932f3b
>> > 0067d687797713303734060e6c555da745
>> >   GCC OpenMP 2.5 shared support library
>> >   This package contains GCC shared support library which is
>> > needed
>> > for OpenMP 2.5 support.
>> >
>> >
>> > if [ "0" == 1 ]
>> > then
>> >
>> > Work in Progress
>> >   
>> >
>> >
>> > And then in the direct mirrored primary.xml I have the same stanza but
>> with
>> > proper formatting
>> > 
>> >   libgomp
>> >   ppc
>> >   
>> >   081c485b68e30e6c3f53a3b0932f3b
>> > 0067d687797713303734060e6c555da745
>> >   GCC OpenMP 2.5 shared support library
>> >   This package contains GCC shared support library which is
>> > needed
>> > for OpenMP 2.5 support.
>> >
>> >
>> > if [ "0" == 1 ]
>> > then
>> >
>> > Work in Progress
>> >   
>> >
>> >
>> >
>> > I do notice also in the foreman/pulp generated primary.xml, there
>> appears
>> > to be a missing  stanza after the   So I'm
>> guessing
>> > the xml is getting misread as its ingested and regenerated by pulp
>>
>>  is functionally identical to [0]; the
>> location
>> of the slashes matters there.
>>
>> Additionally, whitespace between tags should't matter[1][2], so the
>> newline
>> before ">
>> I think it's unlikely that those two things are the cause of the problem
>> here.
>> The original error does indicate a malformed xml document, unfortunately
>> doesn't
>> go into detail about exactly where:
>>
>> > TypeError: Parsing primary.xml error: Start tag expected, '<' not
>> > found
>>
>> I suspect it's failing on the very start of the document, though, since
>> that's
>> the only real place a parser can be sure it needs to see a start tag.
>>
>> In your direct mirrored xml example, the xml declaration [0] and the outer
>> metadata tag as seen in the foreman-generated xml seem to be missing:
>>
>> > 
>> > 
>>
>> It might be useful to debugging to paste that mirrored primary.xml
>> somewhere, in
>> its entirety.
>>
>> [0]: https://www.w3.org/TR/REC-xml/#sec-prolog-dtd
>>
>> [1]: https://www.w3.org/TR/REC-xml/#NT-EmptyElemTag - Note that the
>> definition
>> there implicitly supports only "" 

[Pulp-dev] Plugin triage

[David Davis]

At our last retrospective, we discussed the possibility of not triaging
plugin issues as part of our biweekly triage sessions. We didn’t reach an
agreement so I took the action item to start a discussion on pulp-dev.

First off some benefits of not triaging plugin issues as part of our triage
sessions:

- If we let plugin teams triage their own issues, they can select a time
when the whole team is able to meet. Our biweekly meeting tends to only
involve a subsets of plugin teams.
- Time is wasted when plugin issues come up and usually just the plugin
team members discuss it.
- We don’t have a consistent policy around which plugin issues we triage.
For instance, we don’t triage pulp_deb.

There are some downsides however:

- I think the biggest issue is that there’ll be less transparency into
plugins. This could lead to more siloing and less cross-pollination.
- Potentially more meetings if all plugins decide to schedule their own
triage meetings.
- Plugin issues could go untriaged if plugin teams aren’t responsible.

A couple solutions to the problem that were proposed:

- Ask plugin teams schedule their own triage meetings. They could probably
do this on a less regular basis.
- Have plugin teams triage their issues how they want. This could even be
asynchronously as issues come in. Could be done via IRC/email/etc.

I think at the least it might be worth trying out an alternative approach
for a limited time (e.g. 2 months) and then reevaluating. Thoughts?

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