sskracic@redhat.com
sskracic@redhat.com- Email: sskracic@redhat.com
- Registered on: 02/19/2015
- Last connection: 10/15/2021
Issues
Projects
- Pulp (Private Access, 02/19/2015)
- RPM Support (Private Access, 02/19/2015)
- Puppet Support (Private Access, 02/19/2015)
- Docker Support (Private Access, 02/19/2015)
- Python Support (Private Access, 02/19/2015)
- Packaging (Private Access, 02/19/2015)
- Crane (Private Access, 02/19/2015)
- OSTree Support (Private Access, 02/19/2015)
- Debian Support (Private Access, 02/19/2015)
- Nectar (Private Access, 02/19/2015)
- File Support (Private Access, 07/17/2017)
- Container Support (Private Access, 12/06/2019)
- Migration Plugin (Private Access, 01/14/2020)
Activity
09/23/2021
-
Issue #9434 (MODIFIED): Unable to switch distribution from repository to repo version and vice versa~~~
pulp_core: 3.14.5
pulp_container: 2.7.1
~~~
In RHUI workflow we support pre-syncing the content and then making it available (say at GA) with
by simply repointing the distribution. This works correctly in pulp_rpm, but pulp_con...
09/16/2021
-
Strangely enough, it became an issue for RHUI deployment. The thing is, entitlement certificate for RHUI (which is supplied
in the client_cert of the remote) is often revoked, sometimes on a daily basis, and is then replaced by a fresh... Issue #9398: No optimized syncs after a change to repo's remote?My environment:
pulpcore - 3.14.5
pulp-rpm - 3.14.2
RHEL 8
I am fighting a weird performance issue. After a change to a remote that is attached to some repository (for example when a client certificate is changed), all further s... -
It all makes sense now. Once there is genuinely new content available, and a new repository version· Commented on issue
is created, I'm getting optimized syncs afterwards.
09/15/2021
-
Forgot to add I am using the mirrored syncing, if that's relevant. Issue #9398: No optimized syncs after a change to repo's remote?My environment:
pulpcore - 3.14.5
pulp-rpm - 3.14.2
RHEL 8
I am fighting a weird performance issue. After a change to a remote that is attached to some repository (for example when a client certificate is changed), all further s... -
My environment:· Closed issue
pulpcore - 3.14.5
pulp-rpm - 3.14.2
RHEL 8
I am fighting a weird performance issue. After a change to a remote that is attached to some repository (for example when a client certificate is changed), all further s...
06/21/2021
-
Issue #8944 (CLOSED - CURRENTRELEASE): Cannot sync RHEL6 repos from cdn.redhat.com- a containerized pulp based on pulp-ci-centos image with:
pulpcore-3.13.0
pulp-rpm-3.13.0
I am not sure whether it's a Pulp bug or a CDN data error, but RHEL6 i386 and x86_64
repo syncing repeatedly fails with this error. The ...
05/27/2021
-
dalley wrote:
> @sskracic I would call this "an expected but unfortunate corner case". In this situation, which would you prefer to happen?
>
> * The current behavior (with maybe some additional logging of warnings)
> * Have entire... Story #8673: Auto-publishing should be more fault-tolerantI admit the title is a bit vague.
During auto-publishing sync of a very large repository (rhel-7-server-rpms), the `rq` process got killed by oom-killer sometime in the middle of the publishing step. So the new repository version (1)...
05/20/2021
-
Issue #8787 (CLOSED - CURRENTRELEASE): "UnboundLocalError: local variable 'result' referenced before assignment" on attempt to sync some reposToday I was trying to sync some Red Hat repos with fresh pulp-rpm 3.12.0 release. Everything went well, except for couple of repos that generated this stack trace in the logs:
~~~
May 20 11:20:17 pulp3.skracic.net rq[1495551]: pulp ...
05/03/2021
-
Story #8681 (CLOSED - CURRENTRELEASE): RFE: auto-publishing step should be visible in progress reportsWhen a sync is invoked on a repository with auto-publish enabled, after the actual content is fetched
from the remote, the task spends considerable
amount of time presumably generating metadata, but all progress reports are in state co...
04/30/2021
-
Story #8673 (NEW): Auto-publishing should be more fault-tolerantI admit the title is a bit vague.
During auto-publishing sync of a very large repository (rhel-7-server-rpms), the `rq` process got killed by oom-killer sometime in the middle of the publishing step. So the new repository version (1)...
Also available in: Atom
.