Bug 796493

ok, I am happy to add this for next -maint release, BUT I dont think we should add a new rpm.  I would much prefer to just add a new command or something that will get you the same information.  Since all the components have different version numbers, this sounds like more of some kind of 'global release name', am I reading that right?  What we have now in debug grabs a listing of all aeolus rpms, so we should already have most of the useful debug info there.  Again, happy to add it, just want to clarify direction and not add a new rpm

(In reply to comment #1)
> ok, I am happy to add this for next -maint release, BUT I dont think we should
> add a new rpm.  I would much prefer to just add a new command or something that
> will get you the same information.  Since all the components have different
> version numbers, this sounds like more of some kind of 'global release name',
> am I reading that right?

Yup, we are looking for a product release name.. 
like.. 
CloudForms-CloudEngine-Beta1
CloudForms-CloudEngine-Beta2

etc.. this is intended so customers know exactly which build of CE they are using.



  What we have now in debug grabs a listing of all
> aeolus rpms, so we should already have most of the useful debug info there. 
> Again, happy to add it, just want to clarify direction and not add a new rpm

I CE engineers would not have a problem figuring out which release, but customers might. The intended audience is customers.


Talk to Hugh or Mike for details.. this is not a must have, but its an easy add/fix.

We went with the idea of a rpm to be consistent w/ RHEL and Fedora

The release rpm and text would have to be rev'd for each release.

Adding steve and eck to cc list, so I can get their thoughts when time comes to add this.

Ok, I discussed this a bit with eck, posting summary of his thoughts here.  He thought perhaps we could include the version a package was built for in the rpm release. Right now our releases look like: n.el6cf, we could perhaps make thms something like n.el6cf1.1.  Saying "this machine is 1.1" means that every single rpm is a 1.1 build. You'd have to either wire all the rpms up such that they would refuse to deviate from each other, or just have the cfX.Y in the release and examine them to see what is out of whack.  Assuming this target were added, we would need to kick off a new build for all the 1.1 packages, so they all have the right release, although that brings up a question of, do we rebuild everything? It would probably be good to rebuild everything and verify that it all still builds.  If you put it in the release, then the customer can answer "what release of cloudforms they are running?", with 'rpm -qa | grep \.el6cf'

My two cents, sure, aeolus release version in the rpm release (comment 4) but I also like the idea of a new command outputting a pretty product release name in comment 2 and believe it is needed as well.

So the issue with comment 2 remains that it is very possible to upgrade some, but not all components of aeolus, so any 'named version' of the product would be easily broken, unless we implemented the 'hardwired together versions' eck mentions above, which seems like a bad road to me.  What if we changed that to instead be something like:

$ aeolus-version
  aeolus-conductor-0.13.0-0.el6cf1.1
  imagefactory-1.1.1-0.el6cf1.0
  aeolus-configure-2.8.0-0.el6cf1.1

where this list is all cf rpms?

This (possibly) could additionally format that in a little more readble way, determining that you have components a and c, release 1.1, and b of release 1.0.  However, even in this case I have some concern about the usefulness and accuracy of such information.  Why would we not just output the list of installed versions of rpms, and then the customer can pass that list along to support?  I am afraid if we get to fancy here, we will spend a bunch of effort on something breakable and of questionable (imo) benefit.  Having the release version embedded in the rpm version scheme as eck suggested would allow us to list out the cf rpms for the user (basically running the rpm/grep command above for them)

Modifying the dist-tag is something we'll have to run by PM, but I don't think that is the best answer anyway.

Internally we use the dist-tag to distinguish packages between layered products. We do this to some extent with versioning too (el6cf vs. a theoretical el7cf). At most I could see el6cf2 for a new major release, but you guys have already identified the underlying problem with this: customers could half install updates. How could we tell what they're running if they have some 1.0, some 1.0.1, and some 1.1? That should not be stuffed into the dist-tag. I don't think development wants to rebuild all packages to update the dist-tag either. Don't forget that means the entire rails stack with each release, and advisories for them. Pass.

The original RFE (which did not come from a customer, no offense) was to identify a way to figure out the overall product version. I think the best we can do in the short term is major releases of CloudForms (1.x vs. 2.x). If we're really expecting customers to stay within sanctioned package sets, we could investigate other alternatives like groupupdate or have the cloudforms-release package depend on the upgrades we expect to be delivered.

As an aside, installing the RHEL 6.3 redhat-release does not mean everything is 6.3 either. I'm not saying this is the Right Way, but I will admit that our system of packaging is not perfect.

Dave, wanted to make sure you saw comment 7, and wanted to get your thoughts.

The team (dev/qe/releng) has decieded to leave the system the way it is for now, if problems arise we can revisit.