Igor, that's an anonymous vote for question stated in a wrong way. Sorry, but it doesn't really look like a valuable input for the discussion.
On Tue, Dec 15, 2015 at 9:47 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > FYI: so far (according to poll [1]) we have > > * 11 votes for keeping 9.2 > * 4 votes for restoring 9.3 > > [1] > https://docs.google.com/spreadsheets/d/1RNcEVFsg7GdHIXlJl-6LCELhlwQ_zmTbd40Bk_jH1m4/edit?usp=sharing > > On Tue, Dec 15, 2015 at 8:34 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: >> Folks >> >> Let me add my 2c here. >> >> I am for using Postgres 9.3. Here is an additional argument to the ones >> provided by Artem, Aleksandra and others. >> >> Fuel is being sometimes highly customized by our users for their specific >> needs. It has been Postgres 9.3 for a while and they might have as well >> gotten used to it and assumed by default that this would not change. So some >> of their respective features they are developing for their own sake may >> depend on Postgres 9.3 and we will never be able to tell the fraction of >> such use cases. Moreover, downgrading DBMS version of Fuel should be >> inevitably considered as a 'deprecation' of some features our software suite >> is providing to our users. This actually means that we MUST provide our >> users with a warning and deprecation period to allow them to adjust to these >> changes. Obviously, accidental change of Postgres version does not follow >> such a policy in any way. So I see no other ways except for getting back to >> Postgres 9.3. >> >> >> On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >>> >>> Hey Mike, >>> >>> Thanks for your input. >>> >>> > actually not. if you replace your ARRAY columns with JSON entirely, >>> >>> It still needs to fix the code, i.e. change ARRAY-specific queries >>> with JSON ones around the code. ;) >>> >>> > there's already a mostly finished PR for SQLAlchemy support in the >>> > queue. >>> >>> Does it mean SQLAlchemy will have one unified interface to make JSON >>> queries? So we can use different backends if necessary? >>> >>> Thanks, >>> - Igor >>> >>> On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer <mba...@redhat.com> wrote: >>> > >>> > >>> > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote: >>> >> Hey Julien, >>> >> >>> >>> >>> >>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql >>> >> >>> >> I believe this blueprint is about DB for OpenStack cloud (we use >>> >> Galera now), while here we're talking about DB backend for Fuel >>> >> itself. Fuel has a separate node (so called Fuel Master) and we use >>> >> PostgreSQL now. >>> >> >>> >>> does that mean Fuel is only going to be able to run with PostgreSQL? >>> >> >>> >> Unfortunately we already tied up to PostgreSQL. For instance, we use >>> >> PostgreSQL's ARRAY column type. Introducing JSON column is one more >>> >> way to tighten knots harder. >>> > >>> > actually not. if you replace your ARRAY columns with JSON entirely, >>> > MySQL has JSON as well now: >>> > https://dev.mysql.com/doc/refman/5.7/en/json.html >>> > >>> > there's already a mostly finished PR for SQLAlchemy support in the >>> > queue. >>> > >>> > >>> > >>> >> >>> >> - Igor >>> >> >>> >> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou <jul...@danjou.info> >>> >> wrote: >>> >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote: >>> >>> >>> >>>> The things I want to notice are: >>> >>>> >>> >>>> * Currently we aren't tied up to PostgreSQL 9.3. >>> >>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a >>> >>>> set of JSON operations. >>> >>> >>> >>> I'm curious and have just a small side question: does that mean Fuel >>> >>> is >>> >>> only going to be able to run with PostgreSQL? >>> >>> >>> >>> I also see >>> >>> >>> >>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql, >>> >>> maybe it's related? >>> >>> >>> >>> Thanks! >>> >>> >>> >>> -- >>> >>> Julien Danjou >>> >>> // Free Software hacker >>> >>> // https://julien.danjou.info >>> >> >>> >> >>> >> __________________________________________________________________________ >>> >> 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 >> >> >> >> >> -- >> Yours Faithfully, >> Vladimir Kuklin, >> Fuel Library Tech Lead, >> Mirantis, Inc. >> +7 (495) 640-49-04 >> +7 (926) 702-39-68 >> Skype kuklinvv >> 35bk3, Vorontsovskaya Str. >> Moscow, Russia, >> www.mirantis.com >> www.mirantis.ru >> vkuk...@mirantis.com >> >> __________________________________________________________________________ >> 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 -- Aleksandra Fedorova CI Team Lead bookwar __________________________________________________________________________ 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
