[openstack-dev] [Fuel] Deprecation of GRE network segmentation in Fuel 8.0
Hi all! AFAIK, GRE network segmentation option has been deprecated for clusters with Neutron since 7.0 release, both on UI and Library side. One still can use the option via CLI as no relevant changes were made to Nailgun API. Though appropriate warning is displayed in the case. So I wanted to ask: are we going to carry such behavior of the API in 8.0 or should we also remove processing of the option? In my opinion we should at least forbid cluster creation via API with the parameter as this is the only stage it is accepted. Enhancing of input data validation for appropriate handler will do the trick. Relevant internal Nailgun logic (serialization, networking etc.) will be unchanged in order to support compatibility with already existing clusters after master node upgrade. FYI, there is a relevant bug [1] on Lauchpad. [1] https://bugs.launchpad.net/fuel/7.0.x/+bug/1478924 -- Regards!) __ 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-dev] [Fuel] Default PostgreSQL server encoding is 'ascii'
Hi, folks! Recently I've been working on this bug [1] and have found that default encoding of database server used by FUEL infrastructure components (Nailgun, OSTF, etc) is ascii. At least this is true for environment set up via VirtualBox scripts. This situation may (and already does returning to the bug) cause obfuscating problems when dealing with non-ascii string data supplied by user such as names for nodes, clusters etc. Nailgun encodes such data in UTF-8 before sending to the database so misinterpretation by former while saving it is sure thing. I wonder if we have such situation on all Fuel environments or only on those set by VB scripts, because as for me it seems as pretty serious flaw in our infrastructure. It would be great to have some comments from people more competent in areas regarding to the matter. [1] https://bugs.launchpad.net/fuel/+bug/1472275 -- Regards!) __ 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-dev] [Fuel][FFE] API must allow VIP to be manually set to ANY valid IP address
Colleagues, I would like to request a feature freeze exception for 'API must allow VIP to be manually set to ANY valid IP address' [1]. There are three patches still under the review process [2][3][4]. [2][3] are blocked by merge freeze for UI changes due to separation of fuel-ui and fuel-web repositories. [4] introduces fix for old tech debt issue and blocked by corresponding issue in cluster upgrade code. That needs to be addressed properly too in the scope of the feature. To merge the changes we need at most one week of time. [1]: https://blueprints.launchpad.net/fuel/+spec/allow-any-vip [2]: https://review.openstack.org/#/c/286046/ [3]: https://review.openstack.org/#/c/285297/ [4]: https://review.openstack.org/#/c/284841/ -- Regards!) __ 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-dev] [Fuel] API changes for Nailgun cluster upgrade extension
Hi, fuelers! In accordance to policy of API changing in Fuel components established in this mail thread [1] the purpose of this notice is to inform everyone concerned about such modifications pertaining to Nailgun cluster upgrade extension that is going to be landed into upstream. New handler of HTTP requests for copying of VIPs from cluster under the upgrade to seed cluster is going to be added [2]. This handler is accessible by URL (omitting here the root part for Nailgun API) '/clusters//upgrade/vips/' where '' is indicator of seed cluster. The reason for introducing the separate handler (before the operation was done as part of copying of network settings which in turn is triggered by cluster clone action) is that, as described here [3], copying of VIPs must be done for cluster with assigned nodes, thus, in context of upgrade, after calling to reassign nodes handler. The handler supports POST operation and accepts no data payload as all needed information is retrieved from cluster link object created on cloning of original cluster. In case of success response with empty body and 200 HTTP status code is returned. In case when cluster object with given '' is not found in data base 404 code is returned, and in case when validation for the inbound request has failed the status code of response is 400. [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-October/077624.html [2]: https://review.openstack.org/#/c/286621/ [3]: https://bugs.launchpad.net/fuel/+bug/1552744 -- Regards!) __ 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
Re: [openstack-dev] [Fuel][FFE] API must allow VIP to be manually set to ANY valid IP address
I'm glad to inform you that all required functionality for the feature was successfully landed into upstream and FFE is not needed anymore. On Mon, Feb 29, 2016 at 7:23 PM, Artem Roma <ar...@mirantis.com> wrote: > Colleagues, > I would like to request a feature freeze exception for 'API must allow VIP > to be manually set to ANY valid IP address' [1]. > > There are three patches still under the review process [2][3][4]. > > [2][3] are blocked by merge freeze for UI changes due to separation of > fuel-ui and fuel-web repositories. > > [4] introduces fix for old tech debt issue and blocked by corresponding > issue in cluster upgrade code. That needs to be addressed properly too in > the scope of the feature. > > To merge the changes we need at most one week of time. > > [1]: https://blueprints.launchpad.net/fuel/+spec/allow-any-vip > [2]: https://review.openstack.org/#/c/286046/ > [3]: https://review.openstack.org/#/c/285297/ > [4]: https://review.openstack.org/#/c/284841/ > > -- > Regards!) > -- Regards!) __ 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
