Bug 1420860

Hi,

On a fresh osp9->osp10 upgrade, the required v3 definition are in the api-paste.ini.

On a osp8->osp9 upgrade as well.  On both platform the 

    cinder --os-volume-api-version 3 create 10

worked.

Looking at the puppet code, it does look like there is no special handling of the v3 configuration for cinder/api-paste.ini.  So it looks like this file has the required (in the package) bits since at least some version of osp8.


So, do you happen to have moved this platform from osp7 all the way to osp10 ?

Did you keep the original api-paste.ini so that I can have a look at it ?

Actually, on a freshly installed OSP8, 

cinder --os-volume-api-version 3 create 10

tells me that version must be one of 1 or 2

And indeed, the api.paste.ini only mentions v1 and v2

Hi David,

yes, you're right, on a new osp8 installation only v2 is presents.  But at the controller-major upgrade step during osp8->osp9 upgrade, the api-paste.ini get updated to include v3 definition.  This is package installation only.  My guess is that there was some local modification done to the file and the package management system didn't replace with the new version.

So I think this should be a documentation warning, as currently, no provision is done to manage this file at all (only package installation and upgrade).  Something along those lines:

"check setting for new configuration file with local modification and review the differences and adjust accordingly:

  find /etc -print | egrep "rpmnew$|rpmsave$"
"

The whole rpmnew/rpmsave is well described there[1]

[1]: https://www.redhat.com/archives/rhl-list/2003-December/msg04713.html

Would it be a valuable solution.

Asking pm as well.

If there was local modification, we are unable to detect such changes and support successful upgrade. In this case manual steps would be needed. Is it the case David?

Sorry for the delay, I was merely providing an additional data point.

But looking at "my" deployment, the /etc/cinder/api-paste.ini seem to have updated well during the upgrade to OSP9, it now has sections on cinder v3. However something else is is still fishy, 

cinder --os-volume-api-version 3 create 10

still tell me that the version must be one of 1 or 2. And looking at 

openstack catalog list

there is an endpoint for cinder and cinderv2 but none for cinderv3.

But I guess that's a topic for a different Bz....

In regards to #3, in my opinion, we should automate the process rather then asking the user to review rpmnew files. If files have been modified _manually_, i.e. outside the control of the OSP-d all bets are off anyway. But if a user has used a parameter like 

controllerExtraConfig:
  cinder::config::api_paste_ini_config

to modify the api_paste, we shouldn't force the user to go through a manual verification. Wouldn't it make more sense to instead put the api-paste under puppet-control rather then relying on the RPM?

With regards to comment #4 and the first half of comment #5, could you please ask how cinder ini file got changed? If it is manual, then it is well documented that those changes are the changer's responsibility to maintain. If the change came in the form as in the 2nd part of comment #5, then it is indeed a director bug, though I did not reproduce it.

I'll check with the user, but what I know is:
* the templates do not contain the cinder::config::api_paste_ini_config 
* the environment got updated from OSP8 before, I just wanted to mention it. As said in comment #3 the file should have been updated in the upgrade process.

(In reply to Martin Schuppert from comment #7)
> I'll check with the user, but what I know is:
> * the templates do not contain the cinder::config::api_paste_ini_config 
> * the environment got updated from OSP8 before, I just wanted to mention it.
> As said in comment #3 the file should have been updated in the upgrade
> process.

Amit, while the env was on OSP7, there was work done to integrate a 3rd party self service portal, but it is not sure if the /etc/cinder/api-paste.ini was modified during that time. What we can definitely say is that the file was not managed at any time via OSP-d.

Hi,

We discovered that enabling tls was enough to have this file modified.

so this is one use case where the costumer has nothing to do to have this file updated which then disable the normal package upgrade handling of this file. 

I proposed a patch upstream to remove the tls done is this file when we upgrade to 10.  TLS is handled in another way now but this leftover will cause problem.