It's important to note that given the change in the upgrade method, there will be no actual downgrade of the package, since Fuel 8.0 Admin Node will be installed on a clean system. So, from the upgrade standpoint I see no obstacles to have 9.2 in Fuel 8.0. I also greet any chance to reduce the number of packages maintained in-house.
Depending on native packages is also important in the light of the initiative to separate deployment of Fuel from installation of operating system [1]. [1] https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning -- Best regards, Oleg Gelbukh On Mon, Dec 14, 2015 at 10:50 PM, Sergii Golovatiuk < sgolovat...@mirantis.com> wrote: > Hi, > > If we can stick with upstream PostgresSQL that would be really nice. > Otherwise security updates and regular package update will be a burden of > package maintainers. Ideally we should have as less forked packages as > possible. > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Mon, Dec 14, 2015 at 5:47 AM, Aleksandr Didenko <adide...@mirantis.com> > wrote: > >> Hi, >> >> > Downgrading for no reason could bring us to big trouble and bad user >> experience >> >> +1 to this. Let's keep PostgreSQL 9.3. >> >> Regards, >> Alex >> >> On Mon, Dec 14, 2015 at 2:04 PM, Artem Silenkov <asilen...@mirantis.com> >> wrote: >> >>> Hello! >>> >>> Vote for update. >>> >>> 1. We have already shipped 9.3 in fuel-7.0. Downgrading such complicated >>> package without any reason is not good thing at all. User experience could >>> suffer a lot. >>> 2. The next reason is tests. We have tested only 9.3, 9.2 was not tested >>> at all. I'm sure we could bring serious regressions by downgrading, >>> 3. Postgres-9.3 is not custom. It was taken from KOJI packages and >>> backported without any modification. It means that this package is >>> officially tested and supported by Fedora, which is good. >>> 4. One shipped package more is not a huge burden for us. It was >>> officially backported from official sources, tested and suits our need >>> perfectly. Why do we need to play such dangerous games downgrading for no >>> reasons? >>> >>> Let me notice that all packages are maintained by mos-packaging team now >>> And we are perfectly ok with postgres-9.3. >>> >>> Downgrading for no reason could bring us to big trouble and bad user >>> experience. >>> >>> Regards, >>> Artem Silenkov >>> --- >>> MOs-Packaging >>> >>> On Mon, Dec 14, 2015 at 3:41 PM, Bartłomiej Piotrowski < >>> bpiotrow...@mirantis.com> wrote: >>> >>>> On 2015-12-14 13:12, Igor Kalnitsky wrote: >>>> > My opinion here is that I don't like that we're going to build and >>>> > maintain one more custom package (just take a look at this patch [4] >>>> > if you don't believe me), but I'd like to hear more opinion here. >>>> > >>>> > Thanks, >>>> > Igor >>>> > >>>> > [1] https://bugs.launchpad.net/fuel/+bug/1523544 >>>> > [2] https://review.openstack.org/#/c/249656/ >>>> > [3] http://goo.gl/forms/Hk1xolKVP0 >>>> > [4] https://review.fuel-infra.org/#/c/14623/ >>>> > >>>> > >>>> __________________________________________________________________________ >>>> > 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 >>>> > >>>> >>>> I also think we should stay with what CentOS provides. Increasing >>>> maintenance burden for something that can be implemented without bells >>>> and whistles sounds like a no-go. >>>> >>>> Bartłomiej >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >> >> > > __________________________________________________________________________ > 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
