Can we remove imagefactory from Fedora completely instead?

What is your Python 3 plan?

Please?

Consider this a nonresponsive BZ

This the first reminder.

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

This the second reminder. Are you responsive?

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

This the third reminder. Are you responsive?

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

(In reply to Miro Hrončok from comment #1)
> Can we remove imagefactory from Fedora completely instead?

We can't remove this,  it's used by rel-eng for arm/cloud/container images.

There was a second part of the question:

What is your Python 3 plan?

I've got an e-mail from Chris Lalancette on Tuesday:

> Sorry for not responding earlier.
> 
> I'm not really involved with imagefactory at all, though I am still the maintainer of Oz.
> As Daniel pointed out, you'll want to start with Ian Mcleod for that package (he can point you in the right direction).
> 
> 
> Chris 

Naturally I've asked Chris to give the package to Ian. So far, that did not happen, so I'm adding NEEDINFO Ian Mcleod.

What is imagefactory's Python 3 plan?

Note that Python 2 imagefactory dependencies are going away from Fedora https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/62H7QTOSNLFQNKQZWINSBMMIF4SDA7Q3/ - I assume that simply ignoring the Python 3 question won't work well given that "we can't remove this, it's used by releng".

Here's the upstream issue: https://github.com/redhat-imaging/imagefactory/issues/423 - oz is apparently Python 3 ready.

Apologies folks.  My attention has been strongly focused

Premature submission, let's try that again.

Apologies folks.  My attention has been strongly focused elsewhere for the last month.

Although it's had a happy home as part of koji, you'll see from the changelog that Image Factory is effectively in maintinence mode.

Because of it's role in rel-eng, Brendan Reilly (now copied on the bug) has very kindly stepped up and has been helping with some of these maintenance tasks.

The core feature set has not seen any change in years.  There's been a fair amount of bit-rot in other areas, particularly those related to actually communicating with external cloud providers.  These features are not used as part of the koji integration.

All this is to say that Python 3 migration will be the biggest change this project has seen in a long time.

I think the best approach would be to combine this with stripping out as many of the rotted components as possible.

What I'm aware is still being used as part of koji and perhaps in a few other pipelines:

imagefactory <--- Core library bits
imagefactory-plugins <--- Mostly metapackage
imagefactory-plugins-TinMan <--- Integration with Oz for basic disk image building (qcow2/raw outputs in koji)
imagefactory-plugins-Docker <--- Generation of filesystem tarballs and full Docker base images

These remaining packages are involved in the workflows to generate OVA files for vSphere and RHEV-M/oVirt/RHV as well as Vagrant Boxes for various providers.

imagefactory-plugins-RHEVM
imagefactory-plugins-vSphere
imagefactory-plugins-ovfcommon
imagefactory-plugins-OVA

As a _very_ first step, I'll spend a bit of time right now sorting through the rpm-level deps for these packages, determining their python 3 status and removing any that are truly dead (and cutting out the feature in the associated plugins).

Generally speaking, the things that are good candidates for culling:

The EC2-specific code - much of which dates back to the earlier style of "Disk image plus detached kernel and initrd" images that EC2 required before it supported HVM.  This seems to be very much a legacy feature of EC2 at this point and it's not something I'm aware of anyone using from Factory, certainly not in the rel-eng context.

The connectivity code for vSphere, OpenStack and RHEV-M - This is an area where supporting libraries have either fallen away or may not have migrated to Python3.  I don't believe any of this is widely used.

The REST-api daemon - I am aware of one user of this feature, Tim Flink.  I've CCed him on the bug and will follow up.

Thank You, Ian.

A status update for those who may be watching this with any interest...

I have a work-in-progress branch for the python3 migration here:

https://github.com/redhat-imaging/imagefactory/tree/feature/python3_wip

At the time of this update, I've done basic sanity tests on:

* Base image generation via the CLI
* OVA/Vagrant generation via the CLI
* Non-https basic functionality of the REST interface

I have had to remove XML support from the REST code due the lack of a python3 capable "picklingtools".
I have confirmation from Tim Flink that he does use the daemon/REST functionality and I'm seeking
clarification/confirmation about whether this use case requires XML and/or SSL.

Finally, the upstream oz project, which is a core part of making Image Factory work, has landed python3 migration in F30:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-9ac4c9713a

Image Factory attempts to import oz as a module (as opposed to running it via its CLI).  SO.... the above update breaks Factory in F30.

And that's fine.  What I'll likely do in the next week or so is just merge the python3 WIP stuff, build it and submit as an update.

It will be less broken than a python2.7 based Factory that attempts to import Oz.

> And that's fine.  What I'll likely do in the next week or so is just merge
> the python3 WIP stuff, build it and submit as an update.

Can we land it into F31/rawhide first and verify things work there first. I put conditionals for py2/py3 into oz for F-30 because I feel we're too close to F-30 GA atm and Fedora infra relies heavily on this so I'd sooner let it bake in rawhide and coordinate py3 going back into F-30 once we know those use cases work and are stable.

For the Python 2 removal, backporting to F30 is not that important -- the focus is on Rawhide and future releases.

Ian, thanks for the update. Was there any progress since then?

Note that imagefactory doesn't install:

Error: 
 Problem: conflicting requests
  - nothing provides python2-libguestfs needed by imagefactory-1.1.11-2.fc30.noarch

A week has passed and this bug is still in the NEW state and the package does not install.

Please fix this or indicate that you are working ona  fix by setting the state to ASSIGNED.

After 3 such reminders, this package may be orphaned.

https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Removing_non-installable_packages_from_the_distro

Thanks

My previous comment might have come across a bit too aggressive. I'm sorry, that was not my intention.

In preparation for the Python 2 EOL, we are removing all non-installable Python 2 packages:
https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Removing_non-installable_packages_from_the_distro

I'm mass requesting information and I guess I was a bit too overzealous.

Note that you don't have to actually fix this right now, setting the bug to ASSIGNED will just mark this as being worked on, so I'll know it is being taken care of. If this happens to quickly, feel free to reach to me any time for help (with specific problems).

In preparation for the Python 2 EOL, we are removing all non-installable Python 2 packages:
https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Removing_non-installable_packages_from_the_distro

This bug is still in the NEW state and the package does not install. Please indicate you are working on a fix by setting the state to ASSIGNED. When this bug is four weeks in the NEW state, the package may be orphaned.

Note that you don't have to actually fix this right now, setting the bug to ASSIGNED will just mark this as being worked on, so I'll know it is being taken care of. If this happens too quickly, feel free to reach to me any time for help (with specific problems).

(My previous comment might have come across a bit too aggressive. I'm sorry, that was not my intention.)

(If you know for sure this package shall be removed, consider doing it.)

Thank You!

This bug is still in the NEW state and the package does not install. Please indicate you are working on a fix by setting the state to ASSIGNED. When this bug is four weeks in the NEW state, the package may be orphaned.

This bug is still in the NEW state and the package does not install. Please indicate you are working on a fix by setting the state to ASSIGNED. When this bug is four weeks in the NEW state, the package may be orphaned.

It's being worked upon, it's also critical rel-eng infra

I'm just going to close this since it no longer bothers me (it is fixed from my POV). I'd appreciate if you could be a bit more responsive in bugzilla :(

Thanks for the fix.