Katello::Errors::Pulp3Error: value too long for type character varying(255)

Support
21

What version of Katello are you on? Backporting the fix may well be problematic/impossible, since it will involve a DB migration.

22

I was already afraid that this would be the case. :frowning:
Anyway, this not a blocking issue for the upcoming new systems to be provisioned.
Normally we provision our systems with Centos/Rocky.
But for some specific cases another OS as Ubuntu is necessary.
So it would be fixed as soon we have the time to upgrade our system with the latest version.

23

I now have a PR that I believe will fix this issue: https://github.com/pulp/pulp_deb/pull/364

However, I have no way of testing it since I donā€™t have a repo that reproduces the issue.
Given the error message, I am pretty confident in the fix.

Due to the required DB migration, patching the fix into a non development environment is difficult/dangerous to anyone without relevant DB-migration experience. I am leaning towards merging this blindā€¦ :slightly_frowning_face:

24

Perhaps baculasystems support will let me do a test sync if I email themā€¦

25

@quba42 ,

Thanks for the fast feedback/fix, but ā€¦

Hmm, Iā€™m not sure if they would allow it, unless they provide a link for a trial-version.
I just checked the content of the Release file for the community-repo, but this would not help as the file contains only the component ā€œmainā€ which is indeed the only one available in the repo.
And I canā€™t say that the repo of the trial-version would also contain all those unnecessary components as we have in our enterprise-repo.

From our side we will also open a ticket at bacula to inform them that the list of components contains to much possibles as are made available in the repo.
Hope they will apply a changes for us, even better in their build process of the repos.

26

They probably wonā€™t change this, since it is perfectly legal for APT repos to contain an arbitrary number of components. It is simply a bad assumption on the pulp_deb side, that ā€œ256 characters is enough for all reposā€ā€¦

27

Yeah, right. But is does not make any sense to configure all these unnecessary components if they are not provided at all in the repo.
It should not be that difficult for them to create the file in a correct way with only the components they provide.
Same applies for the checksum-data.

Anyway, we will see how they will reply.

Worse case for us is that we probably have to wait until we can upgrade to the latest version of Foreman/Katello/Pulp.

28

Update: It looks like we will need to add a fix on the Katello side as well, I opened the following issue to track this: Bug #33804: In rare cases upstream APT (deb content) repos can exceed size limited DB fields - Katello - Foreman

29

@quba42 ,
We are currently testing the upgrade-actions on an old foreman-server:

  • Foreman 2.3.x/Katello 3.18.x ā†’ Foreman 2.4.x / Katello 4.0.x
  • Foreman 2.4.x/Katello 4.0.x ā†’ Foreman 2.5.x / Katello 4.1.x
  • Foreman 2.5.x / Katello 4.1.x ā†’ Foreman 3.0.x / Katello 4.2.x

Are the fixes available for this version?

Thnx for your feedback.

30

Unfortunately not, since the full fix requires a DB migration in both Katello and pulp_deb, it will not be fixed before Katello 4.4 and is unlikely to be backported from there. :frowning_face:

31

@quba42 ,
Thanks for the feedback, however, this is really a blocking issue for us.

Is there no way we could apply these fixes (code and DB) manually?
If not, when can we expect this new version of Katello 4.4?

Thnx in advance

32

@Justin_Sherrill Perhaps you can weigh in: My understanding is that since the pulp_deb fix (released in a version of pulp_deb compatible against pulpcore>=3.15 contains a DB migration that cannot be backported without changing the order of migrations, we canā€™t get the fix into a Katello version not yet using pulpcore>=3.15?

It is of course possible to backport the fix while manually changing the order of the migration, but then one can never re-converge on the upstream order and is committed to maintaining ones own migrations for ever? Including adjusting the order of all further migrations coming in from all future pulp_deb releases?

33

@quba42 ,
Thnx for asking.
Additional info regarding the pulpcore version we currently have running in Forman 3.01 / Katello 4.2.1:

rpm -qa | grep pulpcore
tfm-rubygem-pulpcore_client-3.14.1-1.el7.noarch
python3-pulpcore-3.14.9-1.el7.noarch

We hope there is a possibility for us to apply these changes manually.

Regards.

34

In theory it might also be possible to build a temporary workaround fix that does not need the migration, (and will work so long as the user selects a subset of the upstream repoā€™s components that does not exceed the 255 characters available in the DB). However, I donā€™t think I can justify the time to work on that since it just isnā€™t a pressing issue for us right nowā€¦

35

@quba42 ,
Configuring the specific component(s) was one of the actions we tested out when I discovered this issue.
In our case ā€œmainā€ was the only one we needed.

So, when you might find the time for this possible fix that would be great and Iā€™m looking forward for your feedback and instructions what I need to change and where. Even when this is a temporary fix until Katello 4.4 becomes available.

Thanks in advance.

Regards.