On Wed, May 22, 2013 at 07:26:06PM +0000, Alena Prokharchyk wrote: > On 5/22/13 11:11 AM, "Chip Childers" <chip.child...@sungard.com> wrote: > > >On Wed, May 22, 2013 at 06:08:52PM +0000, Animesh Chaturvedi wrote: > >> Alena and I discussed with folks at Orange, their use-case can be > >>supported in AdvancedZone without SecurityGroup by creating account > >>specific guest network. Alena will look at their database to help them > >>migrate the db > > > >Well done, and thank you for doing a real-time support session! > > > >Alena, do you expect that we will have an "official" database migration > >script that needs to be in the release? Or is this just something that > >you believe to be very unique to that user? > > > > > Chip, > > The purpose of this migration script is to transform Advance SG enabled > zone to Advance SG disabled zone while being on 2.2.x. It should be used > only by the customers who created this kind of zone and added VmWare > hypervisor to it - something that CS didn't support even back in 2.2.x (no > support for SG groups on vmWare, in both Basic and Advance zone). > > I don't think the script should become a part of the release as officially > we don't support SG enabled to SG disabled zone conversion.
Understood. However, can we post it somewhere so that it can be referenced if someone has this issue in the future? > > > Customers who configured Advance SG enabled zone with Xen/KVM hypervisors, > will expect their configuration to work as it used to, after upgrading to > 4.1. Nothing should be changed in their DB, SG functionality should be > preserved as well. For that, Anthony's code merge for Advance SG enabled > zone should become a part of 4.1. Otherwise we should announce that this > functionality is not supported in 4.1, and 2.2.x customers having this > type of zone, shouldn't upgrade to 4.1 CS. > I'm not advocating pulling in the SG for Advanced Zones feature anymore. I *do* realize that we will still have some stranded users sitting on 2.x versions (which stinks), but the decision to drop support was pre-ASF and the re-inclusion of the feature should follow the normal process (bring it in via a standard new feature merge window). Based on the notes above - I'm going to *not* block on CLOUDSTACK-2463 anymore. -chip > > -Alena. > > > > >
