On Thu, Sep 11, 2014 at 1:03 PM, Sebastian Kalinowski <
skalinow...@mirantis.com> wrote:

> I have some topics for [1] that I want to discuss:
> 1) Should we allow users to turn SSL on/off for Fuel master?
>     I think we should since some users may don't care about SSL and
> enabling it will just make them unhappy (like warnings in browsers,
> expiring certs).
Definitely +1. I think that Tomasz mentioned somewhere that HTTP should be
kept as the default.

> 2) Will we allow users (in first iteration) to use their own certs?
>     If we will (which I think we should and other people aslo seems to
> share this point of view), we have some options for that:
>      A) Add informations to docs where to upload your own certificate on
> master node (no UI) - less work, but requires a little more action from
> users
>      B) Simple form in UI where user will be able to paste his certs -
> little bit more work, user friendly
>     Are there any reasons we shouldn't do that?
Option A is enough. If there is enough time to implement option B, that's
cool but this should not be a blocker.

> 3) How we will manage cert expiration?
>     Stanislaw proposed that we should show user a notification that will
> tell user about cert expiration. We could check that in cron job.
>     I think that we should also allow user to generate a new cert in Fuel
> if the old one will expire.

As long as the user cannot upload a certificate, we don't need to care
about this point but it should be mentioned in the doc.
And to avoid this problem, Fuel should generate certificates that expire in
many years (eg >= 10).



> I'll also remove part about adding cert validation in fuel agent since it
> would require a significant amount of work and it's not essential for first
> iteration.
> Best,
> Sebastian
> [1] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OpenStack-dev mailing list

Reply via email to