Bug 1026824

Created attachment 715423 [details]
cloud-init iso

Attaching iso. this was using http://download.opensuse.org/repositories/Cloud:/Images:/Leap_42.2/images/openSUSE-Leap-42.2-OpenStack.x86_64.qcow2

The issue is actually with python-setuptools.

/usr/lib/python2.7/site-packages/pkg_resources/__init__.py

imports packaging.requirements which is provided by python-packaging.

python-setuptools in d:l:p has

Requires:       python-packaging

but python-setuptools in openSUSE:Leap_42.2 does not have this dependency, which is why the image fails to boot.

I have added the missing dependency explicitly to the image build as a work around.

Jan, I suspect the problem also exists in SLE 12, possibly also in SLE 11, I have not checked SLE 11. As d:l:py has already been converted to singlespec I was not certain how you wanted to handle this and if you wanted to take this opportunity to make openSSUE Leap 42.1, 42.1, and SLE 12 singlespec aware.

setuptools < 30.0 should only rely on python-six, and ship its own dependencies.

setuptools >= 30.0 also should not go to Leap

did you take the updated package from d:l:py by any chance? I'm pretty sure that the problem does not exist with stock python-setuptools 18.0.0 from SLE/Leap

error on line 72 seems to match contents of python2-setuptools-34.2.0-91.4.noarch.rpm from Factory -- which does have a requirement on python2-packaging

this is not a Leap problem

OK, yes we are picking up setuptools from d:l:p but we are also getting python-packaging, see [1]

http://downloadcontent.opensuse.org/repositories/Cloud:/Images:/Leap_42.2/images/openSUSE-Leap-42.2-OpenStack.x86_64-0.0.4-Build3.17.packages

Thus I am not sure why the import would fail.....

This is not a Leap42.2 bug. Leap42.2 has setuptools 18.0.1 which contains a copy of packaging.
@Robert: why are you not using setuptools from Leap:42.2 ?

Let me try and summarize the image setup and why it is the way it is. From there we can discuss how to improve the situation. I ask everyone to keep an open mind and not only focus on OpenStack and that when it comes to cloud frameworks me an my team are Switzerland, i.e. we are neutral and consider needs of all frameworks without favoring one or another. The cloud frameworks we work with are AWS, GCE, Msft Azure, and OpenStack. Although given that we do not have a partner we work with on a day to day basis that uses OpenStack I have to admit that the OpenStack images get less love than they should.

All images in Cloud:Images are configured to include and pull packages from the Cloud:Tools project. The reason for this is that the tools such as aws-cli, python-azure-agent, and others move pretty fast to accommodate new features/services in the respective frameworks. Having the CLI tools in the images is important at least for AWS, GCE, and Msft Azure. Thus one of the goals for Cloud:Images is to provide images that somewhat keep pace with the cloud frameworks, initialization code and cli tools.

In order to do this the Cloud:Tools project aggregates packages from d:l:py, for example a new version of aws-cli often requires updates to python-boto3, python-botocore and others that are developed/maintained in d:l:py. This is also why Cloud:Tools is such a big mess now and getting hit hard by the singlespec initiative, but that's a different topic. Anyway, because of the aggregate we end up with newer versions of python modules in the images then are in the distribution, such as Leap 42.2.

In this specific case I think the chain is that one of the tools need{s.ed} python-setuptools_scm, which was not available in one of the build targets in Cloud:Tools. Thus python-setuptools_scm was aggregated, but that in turn required the new version of python-setuptools and well you know the domino effect from here.

Dirk started a process that should reduce this domino effect which is really triggered by the many build targets we need in Cloud:Tools. However, the setup Dirk started has not been followed through consistently and quite frankly until yesterday the light in my head hadn't turned on to fully understand the intend and effect of Dirk's work. Add to that a lack of communication between the two of us.....

However, even if we follow Dirk's idea of aggregates per distro (build target) collected in one aggregation target package we can still end up in the same situation we are in today as the dependency chain does not really change. If an upstream package we want/need in Cloud:Tools needs a newer python package than the version available in the target distro we will need to aggregate this into Cloud:Tools and we end up with a similar chain/domino effect.

Of course the simple solution is to simply not include Cloud:Tools in the image build. Then we get everything that is in Leap 42.2 for example and nothing else. With the effect of course that we potentially fall behind on features for using and interacting with cloud frameworks, I do not like that idea.

Another option could be to create a Cloud:Images:Stable project. We'd leave the images in Cloud:Images alone to pick up the "latest and greatest" with the risk of the occasional bug such as this, and in the :Stable project we would have the same image description but without including Cloud:Tools, thus we'll only pick up packages from the target distro. Maintaining the two projects should only be a small increment as the configuration should only differ by a couple of lines easily picked out by diff.

I'll leave it at this for people to digest, but again, please keep in mind there is more than one cloud framework and we should be Switzerland.

for the record, the new python-setuptools also depends on python-appdirs, and python-packaging requires python-pyparsing.
the packages list is 404 for me, but maybe your dependency chain is broken somewhere else along the way?

This is automated batch bugzilla cleanup.

The openSUSE 42.2 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug against that version (see the "Version"
component in the bug fields), or alternatively open
a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime