Perhaps there is some confusion again as to the nature of the 4.4-forward branch.
A while back, we agreed that changes put in here would not be cherry picked to 4.4 unless requested so by the developer and agreed to by the RM. Changes in 4.4-forward that do not go into 4.4 will at least go into 4.4.1 (assuming such a release happens). On Thu, Jul 17, 2014 at 9:48 PM, Daan Hoogland <[email protected]> wrote: > They keep coming in with cherry-picks that include this file. I will > remove them. > > On Fri, Jul 18, 2014 at 12:22 AM, Nitin Mehta <[email protected]> > wrote: > > Hi Daan - I am not sure I get your point here. These changes were put in > > as I want them in 4.4.1, but were not critical enough to be put in 4.4. > > > > Thanks, > > -Nitin > > > > On 17/07/14 2:58 PM, "Daan Hoogland" <[email protected]> wrote: > > > >>sure? I saw that the last few lines where not in the last version. > >> > >>I'm not confortable with this bit, it has been coming up a few time > >>before already looks like some commit on 4.4-forward is trying to > >>sneak it's way into the release: > >> > >>@@ -2439,4 +2474,16 @@ > >> CONSTRAINT > `fk_lb_healthcheck_policy_details__lb_healthcheck_policy_id` > >>FOREIGN KEY > > >>`fk_lb_healthcheck_policy_details__lb_healthcheck_policy_id`(`lb_policy_id > >>`) > >>REFERENCES `load_balancer_healthcheck_policies`(`id`) ON DELETE > >>CASCADE > >> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; > >> > >>+ALTER TABLE `cloud`.`snapshot_policy` ADD COLUMN `display` tinyint(1) > >>NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed to > >>the end user'; > >>+ > >>+CREATE TABLE `cloud`.`snapshot_policy_details` ( > >>+ `id` bigint unsigned NOT NULL auto_increment, > >>+ `policy_id` bigint unsigned NOT NULL COMMENT 'snapshot policy id', > >>+ `name` varchar(255) NOT NULL, > >>+ `value` varchar(1024) NOT NULL, > >>+ `display` tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the > >>detail can be displayed to the end user', > >>+ PRIMARY KEY (`id`), > >>+ CONSTRAINT `fk_snapshot_policy_details__snapshot_policy_id` FOREIGN > >>KEY `fk_snapshot_policy_details__snapshot_policy_id`(`policy_id`) > >>REFERENCES `snapshot_policy`(`id`) ON DELETE CASCADE > >>+) ENGINE=InnoDB DEFAULT CHARSET=utf8; > >>+ > >> INSERT INTO `cloud`.`configuration`(category, instance, component, > >>name, value, description, default_value) VALUES ('Advanced', > >>'DEFAULT', 'management-server', 'vm.password.length', '6', 'Specifies > >>the length of a randomly generated password', '6') ON DUPLICATE KEY > >>UPDATE category='Advanced'; > >> > >>On Thu, Jul 17, 2014 at 11:53 PM, Amogh Vasekar > >><[email protected]> wrote: > >>> Seems good, looks like was an issue with a newline somewhere. But > >>>deploydb > >>> went fine on 4.4 > >>> > >>> Thanks, > >>> Amogh > >>> > >>> On 7/17/14 2:42 PM, "Daan Hoogland" <[email protected]> wrote: > >>> > >>>>Amogh, I couldn't help myself. please have a look at the resulting > >>>>setup/db/db/schema-430to440.sql > >>>> > >>>>On Thu, Jul 17, 2014 at 11:35 PM, Daan Hoogland > >>>><[email protected]> > >>>>wrote: > >>>>> On Thu, Jul 17, 2014 at 11:19 PM, Amogh Vasekar > >>>>> <[email protected]> wrote: > >>>>>> c8ca15b95a57a3d79b71c76c913e295f6490f05d > >>>>> > >>>>> Amogh, it has conflicts. I will have a look at those in the morning > >>>>> > >>>>> -- > >>>>> Daan > >>>> > >>>> > >>>> > >>>>-- > >>>>Daan > >>> > >> > >> > >> > >>-- > >>Daan > > > > > > -- > Daan > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
