+1 for option 2) But I have a question: how do we fit with this into the scope of Feature Freeze and Soft Code Freeze this week? Any ETAs?
2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh <vkramsk...@mirantis.com>: > FYI: There is Strict-Transport-Security > <https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security> header > which can also be useful here (unless we want to make SSL for master node > optional) > > 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov <vshars...@mirantis.com>: > >> Hi, >> >> +1 to 2nd solution too. >> >> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L <e...@mirantis.com> wrote: >> >>> Hi, >>> >>> +1 to 2nd solution, in this case old environments will work without >>> additional >>> actions. Agents for new environments, CLI and UI will use SSL. >>> But probably for UI we will have to perform redirect on JS level. >>> >>> Thanks, >>> >>> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin < >>> sbogat...@mirantis.com> wrote: >>> >>>> Hi guys, >>>> in overall movement of Fuel to use secure sockets we think about >>>> wrapping master node UI and API calls to SSL. But there are next caveat: >>>> >>>> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten >>>> a little. But if it will be rewritten in 7.0 and HTTPS on master node will >>>> be forced by default, it will break upgrade from previous releases to 7.0 >>>> due fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS >>>> by default and fuel-nailgun-agent on all environments won't upgraded, so it >>>> won't be able to connect to master node after upgrade. It breaks seamless >>>> upgrade procedure. >>>> >>>> What options I see there: >>>> 1. We can forcedly enable SSL for master node and rewrite clients in >>>> 7.0 to be able to work over it. In release notes for 7.0 we will write >>>> forewarning that clients which want to upgrade master node from previous >>>> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in >>>> all deployed environments. >>>> >>>> 2. We can have both SSL and non-SSL versions enabled by default and >>>> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL >>>> availability and be able to work in plain HTTP for legacy mode. So, for all >>>> new environments SSL will be used by default and for old ones plain HTTP >>>> will continue to work too. Master node upgrade will not be broken in this >>>> case. >>>> >>>> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client, >>>> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next >>>> releases. It is just postponed version of first clause, so it doesn't seems >>>> valid for me, actually. >>>> >>>> I would be really glad to hear what you think about this. Thank you in >>>> advance. >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Vitaly Kramskikh, > Fuel UI Tech Lead, > Mirantis, Inc. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev