[openstack-dev] [nova] what is our shipped paste.ini going to be for Kilo

Sean Dague sean at dague.net
Tue Mar 17 22:53:29 UTC 2015

On 03/17/2015 04:17 PM, Robert Collins wrote:
> On 17 March 2015 at 23:48, Sean Dague <sean at dague.net> wrote:
>> On 03/16/2015 10:56 PM, Robert Collins wrote:
> ...
>>> Better at the cost of forcing all existing users to upgrade just to
>>> keep using code of their own that already worked.
>>> Not really 'better' IMO. Different surely.
>>> We could (should) add Warning: headers to inform about this, but
>>> breaking isn't healthy IMO.
>> No, that's the point, *no* existing users are forced to upgrade. This is
>> going to require a manual change after your upgrade to get this new
>> default behavior, which we'll need to explain in the release notes.
>> This is not a code change, it's a sample config change.
> I may be confused. Let me spell out what's in my head.
> Firstly, new clouds will default to an API that throws errors from
> [some] existing SDK's (and perhaps also custom apps that are adding
> unexpected fields via regular SDKs). Folk driving multiple clouds who
> try to talk to these new ones will get errors and be unable to use
> those clouds until those errors are fixed. Either by fixing the SDK,
> or by going to the [now deployed] cloud and complaining.

There is a theoretical bogee man here, that doesn't really have a data
point. Kenichi did a survey of a bunch of the SDKs when we were looking
at strict validation in Tempest a few months back, and this kind of edge
condition was not discovered. We can figure out what the survey is again
for that.

> Secondly, you say that paste.ini is a config file, but I recall Dan
> Prince saying in TripleO that they aren't config files we should be
> editing, and we should instead be using the upstream one as-is, so we
> did that there. So there's some confusion at least in some circles
> about whether these are config-for-users or not :).

If we put it in /etc, it's definitely overwritable. We're treating
required changes to it in upgrade testing something that needs to be
specifically called out. We blocked cinder changes recently over that.

I agree we (OpenStack) put things in etc that we probably shouldn't,
especially if we want interop. But they are currently in etc. I'm not
boiling that ocean today. If we believe this is all really read only,
lets get it out of flat files some time in the near future.

> I may be jumping at shadows, like the whole
> must-have-nova-bm-to-ironic upgrade discussion was, so I'm not going
> to argue very strongly here - if my scenarios are wrong, thats cool.
> OTOH if I've described something plausible or something we don't have
> but can get data on, perhaps its worth considering.

It's worth another survey. Honestly, it would be really great if we were
regularly testing jclouds and fog against our upstream. And this other
100 item laundry list I've got. :)

However, when it comes to what makes sense for the Kilo release, I think
there is a very good case for 2.1 on the 2 endpoint. That's how we've
been tempest testing for 2 months.


Sean Dague

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150317/5d558fe1/attachment.pgp>

More information about the OpenStack-dev mailing list