eature entirely, you'd be ok. Otherwise
you'll either need to run httpd also in the same pod, or find another
storage option.
--
Michael Hrivnak
Principal Software Engineer, RHCE
Red Hat
___
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
der the other.
>
> *[3.1+]* PyPI *Cache Use Case:*
>
> As a user, I can use Pulp as a PyPI cache
>
Does this just mean taking advantage of the on-demand features of Pulp? Or
is there anything more to it? If it's just the former, you'll probably get
this for free from core.
--
Michael H
e note that any dissemination,
> distribution, or copying of this communication is strictly prohibited. If
> you have received this e-mail in error, please notify the sender of the
> error.
>
> ___
> Pulp-list mailing list
> Pulp-list@re
level, would that work for you?
Thanks!
--
Michael Hrivnak
Principal Software Engineer, RHCE
Red Hat
___
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
On Tue, Sep 26, 2017 at 4:07 PM, Dennis Kliban wrote:
> We should start scheduling these calls again. I am interested in
> discussing workflows and REST API for
>
> - moving content between repositories
> - purging orphaned content/artifacts and orphaned publications.
>
.
--
Michael Hrivnak
Principal Software Engineer, RHCE
Red Hat
___
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
Pulp's services either in a v6-only environment, or in a manner
such that they talk to each other over v6? Which OS and which message
broker do you use?
Thanks for any feedback you can give. Even just a "yes all that works for
me on $OS" would be very helpful.
--
Michael Hrivnak
Red Hat Summit is this week in Boston. Pulp will be sharing a booth with
Foreman (theforeman.org). If you'll be attending, please come say hi and
grab a sticker! Look for us in Community Central.
https://www.redhat.com/en/summit/2017
--
Michael Hrivnak
Principal Software Engineer, RHCE
Red
I just looked at the repo, and other.xml is 720MB compressed!!! Wow! I
wonder what's in there.
For comparison, just for fun, I checked RHEL 6.8. The other.xml file there
is under 5MB compressed.
The setting to change where the working directory lives is intended to help
in a scenario where
We found the user object that was in an bad state and corrected it. The
workaround is documented here:
https://pulp.plan.io/issues/2591#note-14
Thanks, Kodiak, for helping us gather more info about the bug!
Michael
On Sat, Mar 18, 2017 at 4:21 PM, Kodiak Firesmith
wrote:
When you say they are "stuck tasks", what exactly are you seeing?
I wonder if the problem might just be with pulp_celerybeat. If it was
failing to queue messages in the broker, that might result in you seeing
- TaskStatus records that stay in "waiting"
- scheduled tasks don't appear to ever get
This event will start at 10am EST, approximately 17 minutes from now. The
original announcement below contains an incorrect conversion from UTC to
EST.
Michael
On Tue, Feb 28, 2017 at 10:26 AM, Brian Bouterse
wrote:
> Starting this Thursday, the Pulp community is hosting
ash...@imsweb.com>
wrote:
> Nice! I’d be interested in seeing how this could be deployed on OpenShift.
>
>
>
> *From:* pulp-list-boun...@redhat.com [mailto:pulp-list-boun...@redhat.com]
> *On Behalf Of *Jiri Tyr
> *Sent:* Monday, February 27, 2017 5:53 PM
> *To:* Michael Hrivn
Yes, this will be fixed in Pulp 3.
Michael
On Sun, Feb 19, 2017 at 3:57 PM, Richard Gray <richard.g...@smxemail.com>
wrote:
>
>
> On 2017-02-18 05:25, Michael Hrivnak wrote:
>
>> Since this is a relatively common issue, I decided to respond via blog
>> post:
>&g
On Fri, Feb 17, 2017 at 6:27 PM, Aaron Johnson
wrote:
> What release of Pulp does this affect? Does having more memory solve this
> problem?
This affects all releases of Pulp 2 as far as I can remember. Having more
memory does help, especially if you aren't doing a lot
t 11:35 AM, Jiri Tyr <jiri@gmail.com> wrote:
> Thanks for the blog post, Michael. I have just one question: Why the "rpm
> repo copy all" doesn't walk through all the available types of content to
> prevent the program to consume all memory and fail?
>
> On Fri,
Since this is a relatively common issue, I decided to respond via blog post:
http://pulpproject.org/2017/02/17/why-does-copy-use-lots-of-memory/
Michael
On Thu, Feb 16, 2017 at 4:22 PM, Richard Gray
wrote:
> On 2017-02-17 10:07, Richard Gray wrote:
>
>> given size?
The recommended way to do this in Pulp would be to:
- create one Pulp repo for each remote source and sync them as normal
- create a Pulp repo to hold the combined contents
- copy each repo's content into the combined repo
Each time you did a sync on one of the repos, you would then re-copy its
as I can
>> install it in a virtual environment (even requiring python 3). Upgrades
>> also seem to go fairly smoothly besides the occasional need to add a -devel
>> package for dependencies.
>>
>>
>>
>> On Thu, Nov 17, 2016 at 9:20 AM, Michael Hrivnak <
On Thu, Nov 17, 2016 at 9:32 AM, wrote:
> We are currently testing the use of pulp consumer for centralized package
> installation across our EL 5/6/7 servers and hope to use it in production
> in the near future.
>
> Will the pulp consumer packages (and deps) be
We need your input on when to stop making builds of Pulp for el6.
Running Pulp on el6, which uses Python 2.6, has been getting more difficult
over time. Many libraries we depend on have dropped support for Python 2.6,
which exacerbates the usual challenge of making dependencies available on
an
As you point out, there are good reasons to take other approaches.
One advantage of pulp's restrictive approach is that it forces the
migration writer to know with certainty which migrations will have already
run. You can imagine the trouble that might ensue if two developers created
migrations
If I understand correctly, I think you want to have one or more yum repos
managed somewhere outside of pulp that is your "backup". They contain every
RPM and similar that pulp knows about. Naive question; what is it about
this type of backup that is more convenient for you than just making a
I went through this and found it to be fairly easy. I installed fc25 alpha
via the netinstall image here:
https://getfedora.org/en/server/prerelease/
I chose a minimal install.
Then I just followed the instructions here:
http://docs.pulpproject.org/user-guide/installation/f24+.html
and did a
That will be in the 2.10.0 release.
https://pulp.plan.io/issues/1982
Michael
On Wed, Aug 24, 2016 at 2:34 PM, Eric Helms wrote:
> Howdy,
>
> Is there a way with the API or pulp-admin to force resync a repository and
> have all steps re-ran (including metadata being
This is wonderful to see!
One additional thought as we move toward Pulp 3.0 using a relational DB
with django: We should be able to allow the use of django-admin:
https://docs.djangoproject.com/en/1.8/ref/contrib/admin/
This is a web app that allows basic CRUD operations based on inspection of
As many of you know, we are switching from mongodb to postgres in Pulp 3.0.
This will come with quite a few changes. For one in particular, we need
your input about how you use Pulp's user and permission system. Anything
you can tell us about how you use the current user/perm system would be
very
Users of Chrome are noticing that when they try to visit
http://pulpproject.org, they are being presented with a red page that
claims "Google Safe Browsing recently detected phishing on
website-pulp.rhcloud.com."
We have not been able to find any evidence that the site is compromised,
but have
Until we get a fix released that makes the parser more forgiving, you can
skip the errata portion of a sync by using the "skip" setting on the yum
importer. Here is how to add that setting with pulp-admin:
pulp-admin rpm repo update --repo-id=myrepo --skip=erratum
That will cause your repo to
; <mailto:ash...@imsweb.com <mailto:ash...@imsweb.com>>> wrote:
>>>
>>> FWIW I just upgraded from 2.7 -> 2.8 and it was approx. 1-2
>>> hr
>>> upgrade to get through the migrations in pulp-manage-db.
>>>
>
Did you get any feedback on whether one particular migration seemed to be
running for a lot of that time?
Michael
On Fri, Jul 1, 2016 at 7:23 AM, Eric Helms wrote:
> Howdy,
>
> We (Katello) have had users reporting incredibly long upgrade times when
> upgrading from 2.6 to
RHN Tools. Strangely when I searched for that Errata on the RHN
> website I couldn't find it.
> On Jun 30, 2016 11:37 AM, "Michael Hrivnak" <mhriv...@redhat.com> wrote:
>
>> Matthew,
>>
>> Which repository were you syncing when you saw that erratum fail?
>>
Matthew,
Which repository were you syncing when you saw that erratum fail?
Thanks,
Michael
On Thu, Jun 30, 2016 at 10:31 AM, Matthew Madey wrote:
> I just ran into this on a RHEL erratum today:
>
> Task Failed
>
> Could not parse errata `updated` field: expected format
On naming, I have a slight preference toward keeping the pulp_ prefix
convention, but that might just be rooted in habit. My general feeling is
that the name of a git repo should stand on its own, and the fact that it
may be present on github within a particular user or organization's
namespace
If you are in the area, I will be giving a presentation about Pulp this
weekend at the SouthEast LinuxFest in Charlotte, NC. The talk will be at
11:30am on Sunday.
http://www.southeastlinuxfest.org/
Michael
___
Pulp-list mailing list
Jiri,
Pulp does not have that feature currently. The gpgkey setting is only used
by pulp-agent running on a managed host to install the key with the yum
repo file. However, what you describe would be a valuable feature to have.
If you like, please file a story here:
There's no harm in doing it now, except the slight extra merge work that
needs to happen as you pointed out. That said, I'm not sure we have much to
gain by doing it now.
Technically we don't need to make the branch until someone is ready to
commit something that is in 2.10. Hopefully that will
Using good-old curl, grep, and wc, I also came up with 3645 errata in the
RHEL 6 current "server" repo for x86_64 on the Red Hat CDN. One possible
explanation for seeing more errata at the RHN link is that some of them
might be architecture-specific, and thus wouldn't show up in the x86_64
repo
Using a proxy such as varnish or squid is a key part of the on-demand
workflow. Consider this common use case:
With some type of systems management software, a user initiates a "yum
update" or equivalent on 1000 machines at once. They're all the same or
similar, so they want to retrieve the same
I found the release note from django that talks about not supporting
postgres 8.4 in django 1.8:
https://docs.djangoproject.com/en/1.9/releases/1.8/#support-for-postgresql-versions-older-than-9-0
Are you aware of any actual incompatibility? Or are they not supporting
postgres before 9.0, because
Thanks for that great feedback. We will soon be doing a major overhaul of
website and docs, which Brian Bouterse is especially eager to dive into.
This kind of feedback is very helpful, so please send more!
Michael
On Thu, Apr 28, 2016 at 12:55 PM, Bryan Kearney wrote:
> A
Sam,
There is a known issue with the qpid copr repo used for el6. I understand
it is expected to be fixed tomorrow. Here are details including
work-arounds:
https://www.redhat.com/archives/pulp-list/2016-March/msg00087.html
Michael
On Sun, Apr 3, 2016 at 2:38 PM, Mallick, Samiron
Some users have discovered that when trying to install qpid (one of the
message brokers we support) on el6, using the copr repo that the qpid
project has provided [0], there is a problem with dependency resolution. It
appears that qpid-proton-c was updated in EPEL to 0.12, and the special el6
Yes, pulp allows you to delete each of the artifact types from a docker
repo. See this link for an intro to the three content types that comprise
docker v2 content in pulp:
http://pulp-docker.readthedocs.org/en/latest/user-guide/concepts.html#repository-and-tags
Michael
On Fri, Mar 25, 2016 at
Make sure you have a trailing slash. I get these differing results:
$ curl -k -I https://localhost/pulp/repos/
HTTP/1.1 200 OK
$ curl -k -I https://localhost/pulp/repos
HTTP/1.1 404 Not Found
Michael
On Sat, Mar 26, 2016 at 3:06 PM, Kodiak Firesmith
wrote:
> Start
I've been able to reproduce this problem with python-semantic-version. The
workaround is thankfully simple. After changing your repo file in
/etc/yum.repos.d/ to point at pulp 2.8, do this:
$ sudo yum remove python-semantic-version
This will remove a number of pulp packages also. That's ok. Then
I filed a bug report and submitted a fix, which will appear in 2.8.1.
https://pulp.plan.io/issues/1789
Michael
On Thu, Mar 17, 2016 at 12:53 PM, Michael Hrivnak <mhriv...@redhat.com>
wrote:
> This appears to be a regression in 2.7.
>
> In 2.6 (and earlier), at the complet
This appears to be a regression in 2.7.
In 2.6 (and earlier), at the completion of each rpm download, the file
would be moved from its temporary location to the permanent location. That
means for any given sync, you would never have more files in that temporary
location than you did concurrent
Regarding the support for on-demand content fetching that will be released
very soon in 2.8.0, there is a use case that needs improvement. If you'd
like to provide feedback on proposed solutions, read on.
Problem: A user has a repo with a download policy of "on_demand". They
update the policy to
On Thu, Mar 10, 2016 at 9:23 AM, Bryan Kearney wrote:
>
>
> When katello does a publish or a promote, what do you call that? It would
> be nice to track those items and see progress over time.
>
>
A publish in katello is a publish in pulp. A promotion in katello is a copy
in
+1
An obvious challenge is stabilizing external variables, but they're all
solvable problems. We especially need hardware performance and network
performance to be consistent across test runs. That likely means dedicated
hardware, and a local copy of any content being sync'd. We should consider
Help us help you! Safely test your data now for compatibility with the
coming 2.8 upgrade, and let us know if you have any problems. If so, we'll
fix them before release!
See this blog post for details on how to test your data:
Mohammed,
The problem is revealed in this strange-looking error, seen on line 16 of
your paste: "local error: no renegotiation".
Docker is written in Go, the network library for which famously and
contentiously [0] does not support TLS renegotiation.
So the challenge with docker is that you
Good news! A fix has already been done and will be released with 2.8.0.
https://pulp.plan.io/issues/1263
Michael
On Fri, Mar 4, 2016 at 9:13 AM, Michael Hrivnak <mhriv...@redhat.com> wrote:
> If you don't mind filing an issue about it in our tracker, we'll take a
> loo
.com/raw/3YCq7dTN
>>
>> I'll get in touch with Artifactory support, if it's possible to fix this
>> on their side. Thanks for help
>>
>> Vasek
>>
>> On Wed, Mar 2, 2016 at 10:26 PM, Michael Hrivnak <mhriv...@redhat.com>
>> wrote:
>>
Interesting. Can you provide the contents of
https://artifactory-master.test.com/artifactory/yum-local/test-repo/6/x86_64/repodata/repomd.xml
?
It should have an element like this: 1456870296
But based on the error you're seeing, I suspect it does not, or that it is
empty. Unfortunately, we
on, Feb 29, 2016 at 7:41 PM, Michael Hrivnak <mhriv...@redhat.com>
> wrote:
>
>> It looks like this should work for you:
>>
>> docker pull dev-32-79.lon1.centos.org:5000/pulptest/busybox
>>
>> Michael
>>
>> On Mon, Feb 29, 2016 at 3:32 AM, Mohammed Ze
It looks like this should work for you:
docker pull dev-32-79.lon1.centos.org:5000/pulptest/busybox
Michael
On Mon, Feb 29, 2016 at 3:32 AM, Mohammed Zeeshan <
mohammed.zee1...@gmail.com> wrote:
> Hi,
>
> I have managed to successfully setup a pulp/crane setup in a test
> environment. I am
On Wed, Feb 3, 2016 at 9:36 PM, Jeremy Cline wrote:
>
> Is there any reason to be configuring an event listener to POST to a
> URL over HTTPS when you expressly *don't* want to be secure?
>
>
Good point, although at the moment I suspect it's an issue of convenience.
If an app
Good point. In theory there shouldn't be any sensitive information in the
POSTed data, but I can imagine some users wanting to maintain strict
guarantees that no information leaks out through a man-in-the-middle
attack. This notifier also has the option to provide username and password
credentials
I'm glad we're clarifying use cases, but back to agreeing on a solution: Would
it be sufficient for katello if we added an option to that notifier to skip
cert verification, but make the default behavior to do the validation?
Would anyone object to that?
That would be a simple fix to help avoid
I am at SCALE [0] now, and the next two weekends will be at FOSDEM [1] and
DevConf [2]. If any pulp users are attending and would like to talk pulp in
person, please be in touch!
I am doing talks [3] [4] on pulp at SCALE and FOSDEM, and Ina Panova is
doing a pulp talk [5] at DevConf.
Michael
It sounds like you want to use "remove-missing", which will remove local
packages that are now missing from the remote repo.
However, if the remote feed actually now has A1, A2, and B1, but you don't
care about A1 anymore, then set retain-old-count to 0. That will cause pulp
to keep zero old
Lynn,
Thanks for asking. You are correct that this setting only works during sync.
Pulp is designed right now so that once content is in the system, it can be
copied around very quickly and cheaply. As such, we've avoided doing much
of anything during copy besides add references in the DB.
Pulp 2.8 introduces a new level of data validation at the database access
layer. This is great, with one exception. Some of the content pulp manages,
such as rpms, has a poorly-defined schema that has changed over time. In
short, we need help verifying that our new data access layer will be able
Well then, here is a PR for your collective review:
https://github.com/pulp/pulp/pull/2188
Michael
On Mon, Nov 23, 2015 at 12:55 PM, Sean Myers <sean.my...@redhat.com> wrote:
> On 11/23/2015 12:04 PM, Michael Hrivnak wrote:
> > Following up on this: https://github.com/pulp/pulp/
Following up on this: https://github.com/pulp/pulp/pull/2067/files
... the problem seems to be that mongoengine's DateTimeField does not
attach a timezone to the datetime objects it pulls out of the DB, but some
(most? all?) parts of pulp expect to compare datetimes that DO have a
timezone. I've
Jason,
That is unfortunately a known issue that we are trying to work through as
quickly as possible. Proton was recently upgraded in EPEL6 to version 0.10,
which caused compatibility issues with the broker build that we provide.
In the mean time, you have these options:
- run qpid on EL7 or
I propose that we do not facilitate upgrading directly to pulp 2.8 from any
release earlier than 2.4. I could easily be talked into drawing the line at
2.5.
With the tremendous amount of refactor work going on in 2.8, maintaining
those old migrations is more challenging than ever. Many used code
I think your plan is spot-on. In usually makes sense to have a 1-1 mapping
of remote repos to pulp repos, and to keep the pulp repo as a simple mirror
of that remote repo. From there, you can copy out of the pulp-hosted
mirrors to compose new repos with whatever mix of content you like.
Michael
pulp supports removal of specific images/layers. Removing one from the
middle of an ancestry line definitely breaks its children permanently.
Given a rhel base image, a generic python web app image based on that, and
then a custom app image as the "leaf" of your tree, assume you need to
patch a
On Wed, Sep 2, 2015 at 4:27 PM, Scott McCarty wrote:
> All,
> I had an epiphany the other day, that I would love to be able to
> synchronize an entire stack:
>
> 1. RPM Content for OS
> 2. Puppet Modules to configure
> 3. Docker Images built from the above
> 4. RPM
Nick,
I'm glad you made it onto the list!
The blog post about trying pulp with docker is still current. It's a
convenient way to experiment with a non-production-quality deployment. I'm
not aware that anyone has made a nulecule definition, but I'd love to see
it if someone has. The most likely
I will be at LinuxCon and ContainerCon in Seattle in two weeks. I won't be
presenting specifically about pulp, but if any of our community will be at
the conference, I would love to get together. Please let me know if you
plan to attend.
Pulp's repositories are hosted on fedorapeople.org, which has a planned outage
starting in a few hours at 2015-07-08 21:00 UTC. The outage is expected to last
three hours.
Their announcement:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-July/001640.html
The announcement does
Developers,
We will soon have two betas (2.6.3 and 2.7.0) being tested concurrently. If you
need to make a code change to the 2.6.3 beta, which will be in the 2.6-testing
branch, please talk to me first to confirm the correct base commit on which to
make your changes. If I'm not available, ask
A change to qpid's packaging was pushed to EPEL7 recently, and it may cause
problems for pulp users. We are working with the qpid team on a fix, but for
now, here is a summary of what changed and how to work around it.
TL;DR if you see anything complain that qpidtoollibs is missing, run yum
I published a blog post today about how easy it is to use Pulp's Docker images.
http://www.pulpproject.org/2015/05/21/use-docker-to-try-pulp/
Enjoy,
Michael
___
Pulp-list mailing list
Pulp-list@redhat.com
Ben,
It looks like you might have an alternate content source configured that it's
trying to refresh.
https://pulp.readthedocs.org/en/2.6-release/user-guide/content-sources.html
Michael
- Original Message -
From: ben stanley ben.stan...@exemail.com.au
To: pulp-list@redhat.com
Tomas,
Your best option is to use pulp's new (in upcoming 2.7) notification system. It
would let openshift listen for specific task types it cares about, and respond
accordingly. You can read about it here:
https://github.com/pulp/pulp/blob/master/docs/dev-guide/integration/events/index.rst
- Original Message -
From: Patrick Swartz patrick.swa...@tyson.com
To: pulp-list@redhat.com
Sent: Friday, April 17, 2015 11:10:50 AM
Subject: [Pulp-list] does pulp require a repomd.xml file to sync
Hello,
I’m still learning Pulp and ran across an issue I need help
Patrick,
Pulp does generate the repomd.xml during publish, so maybe it's just a matter
of giving the right URL to spacewalk. Based on your command, I'd expect the
repo to be available here:
https://yourmachine/pulp/repos/content/dist/rhel/server/6/6Server/x86_64/os/
Try browsing to there, and
/release-notes/2.6.x.html
https://pulp-rpm.readthedocs.org/en/latest/user-guide/release-notes/2.6.x.html
https://pulp-puppet.readthedocs.org/en/latest/user-guide/release-notes/2.6.x.html
Thank you to everyone who helped test the betas and release candidates.
Michael Hrivnak
Alan,
Thanks for the feedback! It's great to have help testing that sort of thing.
Michael
- Original Message -
From: Alan Milligan alan.milli...@last-bastion.net
To: pulp-list@redhat.com
Sent: Thursday, March 19, 2015 9:43:54 AM
Subject: [Pulp-list] MongoDB 3.x support
Hi,
I've just
Alex,
I'm glad you were able to get things back up and running. So would you
summarize your path to success as 1) free up some space, 2) restart services,
and then everything was fine? Did you have to do anything with mongodb?
FWIW, my favorite way to quickly free up space and inodes is yum
Copying just an errata will add it to the updateinfo.xml file in the
destination repo. --recursive will additionally copy the rpms it references and
any dependencies they have.
Michael
- Original Message -
From: Jo De Troy jo.de.t...@gmail.com
To: pulp-list@redhat.com
Sent: Tuesday,
Fred,
Pulp does not make guarantees about preserving mtime on files or ensuring that
mtime sorts in lock-step with epoch-version-release. That is not a use case
pulp tries to support, but it would be interesting to know why that's useful to
you.
Publishing a yum repo makes it available to the
Ben,
A running task should not have a finish time. What version of pulp are you
using?
It would be helpful to see all of the log output related to a specific task
where you saw this behavior. You can probably grep the system log the task ID
to find what we need.
Here is info about where pulp
There is a new blog post describing under-the-hood changes coming to Pulp:
http://www.pulpproject.org/2015/01/02/pulp-in-the-new-year/
Enjoy,
Michael
___
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
, December 17, 2014 9:29:14 AM
Subject: Re: [Pulp-list] working directories proposal
On 12/15/2014 02:54 PM, Michael Hrivnak wrote:
- Add a new config value in the 'server' section called
'working_directory'. It's default value would be /var/lib/storage
We should have pulp in the path. /var
Paul,
Sorry about all the log noise. The system is behaving normally, and the logging
is misleading. It is not an error when the .treeinfo file isn't present. We
fixed this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1126083
Michael
- Original Message -
From: Paul Gonin
One of the big points of convenience with having the python packages under one
repo is the ability to make one pull request that touches multiple packages.
This is quite common, for example something as simple as adding a constant to
the common package. Would we lose that ability if we started
As a reminder, I'll be a mix of PTO and travelling to Brno this week. I'll be
watching email in case you need anything, but I likely won't have phone service
through Wednesday. Please contact Jeff Ortel for anything time-sensitive.
Michael
___
Christina,
We are working on that issue now. Making pulp-admin do TLS will require a small
code change similar to this one: https://github.com/pulp/pulp/pull/1244/files
Stay tuned.
Michael
- Original Message -
From: Christina Plummer cplum...@gmail.com
To: pulp-list
There is a bug [0] in Pulp 2.4.1 that will affect any user who does a sync of
Red Hat Enterprise Linux 6Server (which is a shortcut for the latest 6.x
release). Since version 6.6 was released today [1], the treeinfo file in the
6Server repository has new metadata. Pulp 2.4.1 handles that
I'm told that this issue has been resolved, so please try the sync again.
Michael
- Original Message -
From: Michael Hrivnak mhriv...@redhat.com
To: Josh Baird jba...@follett.com
Cc: pulp-list@redhat.com
Sent: Friday, September 26, 2014 4:23:20 PM
Subject: Re: [Pulp-list] Errors syncing
This appears to be caused by incorrect metadata on the upstream server. I've
alerted the team responsible for that content, and they are investigating.
In the mean time, you can work-around the issue by skipping the distribution
step during sync:
$ pulp-admin rpm repo update --repo-id=foo
\nOrganizer: Michael Hrivnak mhriv...@redhat.com \n\nLocation: 16W106
- Monopoly - 16 - RDU 16w106-...@redhat.com \nResources: 16W106 - Monop
oly - 16 - RDU 16w106-...@redhat.com (Site: RDU Building: RDU Floor:16 Ro
om: 16W106 Proj) \nTime: Monday\, September 29\, 2014\, 3:00:00 PM - 5:00:00
PM
Sorry for the accidental traffic everyone! I accidentally invited the wrong
list.
Michael
- Original Message -
From: Michael Hrivnak mhriv...@redhat.com
To: pulp-list pulp-list@redhat.com
Sent: Friday, September 26, 2014 5:25:21 PM
Subject: [Pulp-list] Cancelled: Pulp planning
You have
You could have the web handler copy the attribute worker_name to queue, so
the API returns both. Then mark queue as deprecated in the documentation.
That would let us comfortably release this as part of a 2.6 or 3.0.
Would that cover all public-API use cases? Or does that data get exposed
1 - 100 of 148 matches
Mail list logo