Sent this to the wrong list the first time, my bad. See below.
Paul Ward/Rochester/IBM wrote on 05/28/2014 02:12:10 PM:
> From: Paul Ward/Rochester/IBM
> To: openstack-dev@lists.openstack.org,
> Date: 05/28/2014 02:12 PM
> Subject: [Openstack-stable-maint] Stable exception
>
> I'll start by saying that we don't need this ported to icehouse as we've
> included it in our distro, as Alan suggested.
>
> However, I would like to explain why we needed it. We do generate
> cert files for the controller node. However, for cases where the different
> services are all running on the controller node, we use 127.0.0.1 as the
> address they communicate on. Since the cert was based on hostname,
> this will fail unless we have the api_insecure flag set. And since we're
> communicating on 127.0.0.1, it's ok to ignore ssl errors.
>
> Since this is in Juno, and we've patched it in Icehouse for our distro, we
> have no pressing need to backport this one. Thanks for keeping an
> eye on it!
>
> Alan Pevec wrote:
> > https://bugs.launchpad.net/neutron/+bug/1306822
> > https://bugs.launchpad.net/neutron/+bug/1309694
> >
> > Those bugs describe the missing options, but do not do a great job of
> > describing the impact of not having them. My guess is that without those
> > parameters, you have to rely on system certificates (as you can't
> > provide your own and you can't disable the check). Is that a correct
> > assumption ? Who is impacted by these bugs ?
>
> I think you're right that 1309694 can be worked around by using system
> cert store.
> Disabling cert check bug 1306822 is definitely not needed - why would
> you use certs if you don't check them?
> So unless more justification is provided in the bugs (importance of
> both is Undecided) I don't think we have the case for granting the
> exception.
>
> Distributions are of course free to take those patches, if it suits
> their policies.
> BTW having such backports proposed is fine even if denied for stable
> merge, we can use stable reviews as a mean to share patches among
> distros.
>
> > If my interpretation is correct, then this falls a bit in a grey area:
> > it is a "feature" to allow your own certificate to be provided, but it
> > could be seen as a bug (feature gap) if Neutron was the only project in
> > Icehouse not having that feature (and people would generally expect
> > those parameters to be present). Is Neutron the only project that misses
> > those parameters ?
>
> Currently yes, only Neutron has a new feature in Icehouse to send port
> events to Nova but Cinder will need to same to properly fix the race
> with volumes during VM setup.
>
> Cheers,
> Alan