Open Stack

Hey Matt!

On 11/30/2012 01:24 PM, Matt Joyce wrote:
> 
> Maybe this isn't super helpful, but it has to be said.
> 
> I've been doing some packaging work for openstack lately.  And, that's
> lead to me getting a bit testy on IRC.  Sorry for that.

Sorry to cause you frustration.

> A big part of my frustration comes from the way we version inside of
> OpenStack core.
> 
> I'll break this down to two different concerns.
> 
> 
> 1.  First Concern - No standard.
> 
> We are ostensibly doing milestones for components, and independent yet
> standardized versioning for clients.
> 
> Except for swift which is just kind of doing it's own thing not being a
> part of OpenStack at all.
> 
> Now we're discussing possibly introducing a fourth versioning scheme.
> 
> It makes the automation of packaging that much more difficult if I have
> to come up with new logic for every single component of openstack that
> has a different versioning scheme.
> 
> Which leads me to the second point.
> 
> 2.  Second Concern - .git derives our versioning
> 
> First, thank god for the versioninfo file.  Without it, cinderclient
> would be unbuildable in certain situations.

Totally. It's pretty important.

> It boils down to this logic:
> 
> from cinderclient/openstack/common/setup.py  ( which btw is common
> SOLELY to cinderclient every other client does this logic in a different
> yet standard fashion ).

I did not realize cinderclient had diveged. We should fix that. (patch
coming)

> def get_post_version(projectname):
>     """Return a version which is equal to the tag that's on the current
>     revision if there is one, or tag plus number of additional revisions
>     if the current revision has no tag."""
> 
>     if os.path.isdir('.git'):
>         version = _get_git_post_version()
>         write_versioninfo(projectname, version)
>         return version
>     return open(os.path.join(projectname, 'versioninfo'),
> 'r').read().strip()
> 
> This basically says either grab the version from .git, or the
> versioninfo file.  Except that generating the versioninfo file requires
> .git.


Well, there is a bug in the logic there. Currently it tries to keep the
versioninfo file up to date at all costs, so if it finds that it has a
git repo, it will recreate the versioninfo file.

Except that makes evil for git-buildpackage. Sorry, I just didn't catch it.

The fix for that is to always trust the versioninfo file if it exists.
Since it gets created on tarball creation as part of our release
process, it should never not be there - and to only fall back to git if
the versioninfo file does not exist.

I can come up with no valid situation where a person will have a copy of
the code with neither an upstream git repo OR a tarball generated
versioninfo file. (although please check me if I'm wrong there)

> So I end up having to write logic to figure out release tagging and plug
> in versioninfo files into the clients.  Which would be fine except right
> now we have 3 different approaches to tagging repos in the project.

There should only be two here- cinderclient being different is a bug.
jeblair and I have been having conversations on how to consolidate
libraries and non-libraries into one single method - but let's call it
two for right now because we haven't finished that.

> Please for the love of all that is happy and free in the world, don't
> create a fourth.

I agree. I do not think we need a third mechanism. I'm fairly certain we
can accomplish with Mark wants to do with the mechanisms we have.

What I'm talking about below isn't extra mechanisms, it's more about
version choosing.

> Hope this doesn't come off as aggressive or angry it's more exasperation. 

Totally. As a person who has had my head in the middle of automation
around our versioning and release mechanism since day 1, BELIEVE ME, I
understand the bouts of exasperation. :)

> On Fri, Nov 30, 2012 at 11:29 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
> 
>     Actually, if we have some snapshot releases which look like this:
> 
>     2012.2~G2~5 (for instance)
> 
>     That get turned in to python versions that look like this:
> 
>     2012.2-alpha2.5  (for instance)
> 
>     Then I don't understand why we couldn't upload snapshots and real
>     releases to pypi - and then have nova do:
> 
>     oslo-foo>=2012.2,<=2013.1
> 
>     In its pip-requires.
> 
>     (we might be splitting hairs on this one)
> 
>     On 11/30/2012 11:07 AM, Joshua Harlow wrote:
>     > Is there a versioning scheme that can be followed here?
>     >
>     > Stable releases on pypi have even numbers, odd numbers are unstable?
>     >
>     > Isn't something like that pretty common (?), then u can just upload
>     > everything to pypi.
>     >
>     > Maybe that¹s another idea.
>     >
>     > On 11/30/12 5:45 AM, "Mark McLoughlin" <markmc at redhat.com
>     <mailto:markmc at redhat.com>> wrote:
>     >
>     >> On Mon, 2012-11-26 at 22:40 +0000, Mark McLoughlin wrote:
>     >>> On Fri, 2012-11-23 at 11:55 +0100, Thierry Carrez wrote:
>     >>>> There seem to be two options there: just push everything on the
>     same
>     >>>> PyPI module, or have multiple PyPI modules for each series..
>     I'd say
>     >>>> the latter looks worse.
>     >>>
>     >>> I don't really buy that unstable development releases of Oslo
>     have to go
>     >>> to PyPI in order for core projects to be able to consume them.
>     >>>
>     >>> pip supports http:// URLs of tarballs. Why not use that during
>     >>> development?
>     >>
>     >> I'm kinda waiting for opinions on this :-)
>     >>
>     >> Cheers,
>     >> Mark.
>     >>
>     >>
>     >> _______________________________________________
>     >> OpenStack-dev mailing list
>     >> OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>