Open Stack

On Jan 18, 2014, at 9:58 AM, Jesse Noller <jesse.noller at RACKSPACE.COM> wrote:

> 
> On Jan 18, 2014, at 12:00 AM, Jamie Lennox <jamielennox at redhat.com> wrote:
> 
>> I can't see any reason that all of these situations can't be met. 
>> 
>> We can finally take the openstack pypi namespace, move keystoneclient -> openstack.keystone and similar for the other projects. Have them all based upon openstack.base and probably an openstack.transport for transport.
>> 
>> For the all-in-one users we can then just have openstack.client which depends on all of the openstack.x projects. This would satisfy the requirement of keeping projects seperate, but having the one entry point for newer users. Similar to the OSC project (which could acutally rely on the new all-in-one).
>> 
>> This would also satisfy a lot of the clients who have i know are looking to move to a version 2 and break compatability with some of the crap from the early days.
>> 
>> I think what is most important here is deciding what we want from our clients and discussing a common base that we are happy to support - not just renaming the existing ones.
>> 
>> (I don't buy the problem with large amounts of dependencies, if you have a meta-package you just have one line in requirements and pip will figure the rest out.)
> 
> You’re assuming:
> 
> 1: Pip works when installing the entire dependency graph (it often doesn’t)
> 2: For some of these requirements, the user has a compiler installed (they don’t)
> 3: Installing 1 “meta package” that install N+K dependencies makes end user consumers happy (it doesn’t)
> 4: All of these dependencies make shipping a single binary deployment easier (it doesn’t)
> 5: Installing and using all of these things makes using openstack within my code conceptually simpler (it doesn’t)
> 
> We can start with *not* renaming the sub clients (meaning) collapsing them into the singular namespace; but the problem is that every one of those sub dependencies is potential liability to someone using this single client. 
> 
> If yes, we could only target fedora, and rely on yum & rpm, I’d agree with you - but for python application dependencies across multiple OSes and developers doing ci/cd using these systems I can’t. I also don’t want user to stumble into the nuanced vagaries of the sub-clients when writing application code; writing glue code to bind them all together does work very well (we know this from experience).
> 

As much as I would like to say (with my pip developer and PyPI Admin hat on) that depending on 22+ libraries in a single client will be a seamless experience for end users I can’t in good faith say that it would be yet. We’re working on trying to make that true but honestly each dependency in a graph does introduce risk.

As of right now there is no real dependency solver in pip, so if someone depends on the openstack client themselves, and then depends on something else that depends on one of the sub clients as well if those version specs don’t match up there is a very good chance that the end user will run into a very confusing message at runtime. Openstack itself has run into this problem and it was a big motivator for the global requirements project.

Additionally it’s not uncommon for users to have policy driven requirements that require them to get every dependency they pull in checked for compliance (License, security etc). Having a 22+ node dependency graph makes this issue much harder in general.

I also believe in general it’s asking for user confusion. It’s much simpler to document a single way of doing it, however splitting the clients up and then wrapping them with a single “openstack” client means that you have at least two ways of doing something; The direct “use just a single library” approach and the “use the openstack wrapper” approach. Don’t underestimate the confusion this will cause end users.

Keeping them all under one project will make it far easier to have a cohesive API amongst all the various services, it will reduce duplication of efforts, as well as make it easier to track security updates and I believe a wholly superior end user experience.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140118/93f08b5d/attachment.pgp>