Corresponding ticket: https://bugs.launchpad.net/fuel/+bug/1528613 (Prohibit creation of Nova-Network enabled 8.0 environments)
Aleksey Kasatkin On Tue, Dec 22, 2015 at 4:22 PM, Sheena Gregson <[email protected]> wrote: > I agree – I don’t think we can change the user’s ability to manage old > releases. This work should be about preventing the selection of > nova-network for new environments on 8.0 release and later – we should > restrict this via all methods of interaction, including UI, CLI and API if > possible. > > > > *From:* Oleg Gelbukh [mailto:[email protected]] > *Sent:* Tuesday, December 22, 2015 3:09 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > [email protected]> > *Subject:* Re: [openstack-dev] [Fuel] Removal of support for nova-network > > > > Sergii, > > > > Nailgun will still have data of clusters with old releases, should they be > in the database backup. And it still has to be able to manage them. > > > > -- > > Best regards, > > Oleg Gelbukh > > > > On Tue, Dec 22, 2015 at 11:58 AM, Sergii Golovatiuk < > [email protected]> wrote: > > Hi, > > > > There won't be upgrade to 8.0. User will be able to backup and load data > to a new master node. nova-network has been deprecated for 2 releases so we > can remove it. If we remove it we can remove tests from acceptance testing > as well as from auto-tests so it should remove tech debt so will release > our QA/CI resources to focus on other tests. > > > > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > > > On Tue, Dec 22, 2015 at 12:28 AM, Evgeniy L <[email protected]> wrote: > > Hi, > > > > We mustn't touch Nailgun's logic, otherwise after upgrade user won't be > able > > to manage her/his old nova Cluster. So lets just remove it from UI. > > Also as far as I know we should provide a way to manage old clusters not > > for a release, but for a couple of years. > > > > Thanks, > > > > On Tue, Dec 22, 2015 at 10:40 AM, Igor Kalnitsky <[email protected]> > wrote: > > I don't think it's a good idea to drop support of 7.0 nova-network > setup in 8.0. We should keep compatibility for at least one release. > > > On Tue, Dec 22, 2015 at 9:15 AM, Aleksey Kasatkin > <[email protected]> wrote: > > Sergii, > > > > We could remove it completely from nailgun if support for 7.0 and > earlier is > > not required. > > > > > > Aleksey Kasatkin > > > > > > On Tue, Dec 22, 2015 at 3:27 AM, Sergii Golovatiuk > > <[email protected]> wrote: > >> > >> Hi, > >> > >> Finally we can deprecate nova-network ... > >> We should remove it from UI, nailgun logic and tests to have less > >> technical debt. > >> > >> -- > >> Best regards, > >> Sergii Golovatiuk, > >> Skype #golserge > >> IRC #holser > >> > >> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson <[email protected]> > >> wrote: > >>> > >>> Hey guys – > >>> > >>> > >>> > >>> I know this has been a topic of a lot of discussion – Adrian informed > me > >>> on Friday that QA has confirmed the multi-hypervisor use case has been > >>> tested successfully without nova-network, so we can finally deprecate > it! > >>> > >>> > >>> > >>> Users who want to deploy multiple hypervisors will need to use the Fuel > >>> DVS plugin (Neutron ML2 driver) to support their vCenter computes and > the > >>> KVM/QEMU computes can use Neutron + GRE/VXLAN. > >>> > >>> > >>> > >>> I’ve created a kind of “cover all the things” bug here: > >>> https://bugs.launchpad.net/fuel/+bug/1528407. Given the state of > >>> nova-network right now in Fuel, I have marked it as Critical. > >>> > >>> > >>> > >>> Let’s start the conversation on here and make sure all the bases are > >>> covered – if additional bugs need to be logged or there’s > administrative > >>> overhead, let me know and I’ll be happy to help out! > >>> > >>> > >>> > >>> Sheena Gregson | Sr. Product Manager | Mirantis > >>> > >>> p: +1 650 646 3302 | e: [email protected] > >>> > >>> > >>> > >>> > >>> > >>> > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> [email protected]?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > [email protected]?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
