You are right Ron, but there is always security fixes that might require db changes on a point release.
On Tue, Dec 29, 2015 at 5:39 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > As an old-timer but a new cloudstack user, it strikes me as a bit odd > that changes to the database are allowed within a minor version change. > This seems to cause a lot more problems than it solves. > > It could delay the release of someone's pet enhancement or bug fix but the > idea of not being able to upgrade from 4.5.3 to 4.6.2 is frightening. > The prospect of having upgrade scripts for 4.5.2 to 4.6.0, 4.6.1 and4.6.2 > as well as as a separate upgrade from 4.5.3 to 4.6.2 and similar scripts > for 4.5.4, 4.5.5, etc. to 4.6.2, 4.6.3, 4.6.4 and so on, is unpleasant. > This would have to continue until someone says that 4.5.x is dead and no > upgrade scripts to new 4.6.x releases will be available. > > In projects that I have run, a change to the database required a new major > release so a single conversion will take one from 4.5.x to 4.6.x > > The nice thing about release numbers is that one never runs out! > > Ron > > > > On 29/12/2015 10:08 AM, Daan Hoogland wrote: > >> CCYY == YYYY >> >> On Tue, Dec 29, 2015 at 3:06 PM, Rafael Weingärtner < >> rafaelweingart...@gmail.com> wrote: >> >> I also liked the date-format, what did you mean with CCYY? >>> >>> >>> >>> The way I think we might have a problem, would be to commits/PRs that end >>> up creating files with same names. Then, we would have to agree upon a >>> way >>> to solve those conflicts, such as appending an extra character to >>> indicate >>> a sequence to be followed or adding more data such as HH and mm to the >>> naming convention (YYYY-MM-DD-HH-mm). >>> >>> >>> I liked the way Wido suggested, we could just remove the “-” from >>> “YYYY-MM-DD-HH-mm” and use the value as an integer (YYYYMMDDHHmm). >>> >>> >>> >>> It seems that we are reaching a consensus. I would love to hear back from >>> other devs though, especially committers. >>> >>> >>> >>> BTW: do I have permission to create a page on the wiki so I can add >>> everything we discuss and agree upon here? This way, we could add that >>> page >>> to the guidelines for devs creating PRs and committers reviewing and >>> merging them. >>> >>> On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander <w...@widodh.nl> >>> wrote: >>> >>> >>>> On 29-12-15 14:46, Daan Hoogland wrote: >>>> >>>>> Wido, Rafael, >>>>> >>>>> I like the date-format but then of course CCYY-MM-DD. I can still think >>>>> >>>> of >>>> >>>>> ways to screw up that (or the plain int;) >>>>> >>>>> 20151229 is a valid integer which you can simply use to compare with. >>>> >>>> 100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much. >>>> >>>> My point is that the database version should be separated from the code >>>> base. >>>> >>>> Wido >>>> >>>> On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner < >>>>> rafaelweingart...@gmail.com> wrote: >>>>> >>>>> Wido, that is true, you are right; the naming on upgrade routines can >>>>>> >>>>> use a >>>> >>>>> numeric value independent of the number of the version. The numeric >>>>>> >>>>> value >>>> >>>>> can be a simple integer that is incremented each routine that is added >>>>>> >>>>> or a >>>> >>>>> time stamp when the routine was added. The point is that we would have >>>>>> >>>>> to >>>> >>>>> link a version to a number. That would enable us to use flywaydb. >>>>>> >>>>>> To use that approach I think we might need to break compatibility as >>>>>> >>>>> you >>> >>>> pointed out earlier, but I believe that the benefits of an improved >>>>>> >>>>> way >>> >>>> to >>>> >>>>> manage upgrade routines will compensate by the breaking of >>>>>> >>>>> compatibility. >>>> >>>>> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander <w...@widodh.nl> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On 29-12-15 13:21, Rafael Weingärtner wrote: >>>>>>> >>>>>>>> I got your point Daan. >>>>>>>> >>>>>>>> Well, and if we linked a version of ACS with a time stamp in the >>>>>>>> >>>>>>> format >>>> >>>>> of >>>>>>> >>>>>>>> DD.MM.YYYY? >>>>>>>> >>>>>>>> In that case you could also say. >>>>>>> >>>>>>> ACS 4.6.0 == db ver X >>>>>>> >>>>>>> You don't have to say ver >= X, you can also say ver = X. >>>>>>> >>>>>>> We could then use the time stamp in the same format to name upgrade >>>>>>>> routines. This way the idea of running all of the routines in >>>>>>>> >>>>>>> between >>> >>>> version during upgrades could be applied. >>>>>>>> >>>>>>>> Same goes for giving all database changes a simple numeric int which >>>>>>> keeps incrementing each time a change is applied ;) >>>>>>> >>>>>>> Wido >>>>>>> >>>>>>> On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland < >>>>>>>> >>>>>>> daan.hoogl...@gmail.com >>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Rafael, >>>>>>>>> >>>>>>>>> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner < >>>>>>>>> rafaelweingart...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Thanks, Daan and Wido for your contributions, I will discuss them >>>>>>>>>> >>>>>>>>> as >>> >>>> follows. >>>>>>>>>> >>>>>>>>>> Daan, about the idea of per commit upgrades. Do you mean that we >>>>>>>>>> >>>>>>>>> separate >>>>>>> >>>>>>>> each change in the database that is introduced by PRs/Commits in a >>>>>>>>>> different file (routine upgrade) per ACS version? >>>>>>>>>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another >>>>>>>>>> >>>>>>>>> PR) >>>> >>>>> and >>>>>>> >>>>>>>> so forth >>>>>>>>>> >>>>>>>>>> If that is the case, we can achieve that using a simple convention >>>>>>>>>> >>>>>>>>> naming >>>>>>> >>>>>>>> as I suggested. Each developer when she/he needs to change or add >>>>>>>>>> >>>>>>>>> something >>>>>>>>> >>>>>>>>>> in the database creates an upgrade routine separately and gives it >>>>>>>>>> >>>>>>>>> an >>>> >>>>> execution order to be taken by Flywaydb. I think that could help >>>>>>>>>> >>>>>>>>> RMs >>> >>>> to >>>>>> >>>>>>> track and isolate the problem, right? >>>>>>>>>> >>>>>>>>>> Yes, with one little caveat. We do not know in what version a >>>>>>>>> >>>>>>>> feature/PR >>>>>>> >>>>>>>> will end up at the time of implementing, so a name containing the >>>>>>>>> >>>>>>>> version >>>>>>> >>>>>>>> would not be ideal. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Wido, now I understand your example. >>>>>>>>>> I understand your worry about upgrade paths, and that is the >>>>>>>>>> >>>>>>>>> point I >>> >>>> want >>>>>>> >>>>>>>> to discuss and solve. In your example, if we release a 4.6.0 and >>>>>>>>>> >>>>>>>>> later >>>>>> >>>>>>> a >>>>>>> >>>>>>>> 4.5.3. You said that there would be no upgrade path from 4.5.3 to >>>>>>>>>> >>>>>>>>> 4.6.0. >>>>>>> >>>>>>>> Well, today that is what happens. However, if we change the >>>>>>>>>> >>>>>>>>> technology >>>>>> >>>>>>> we >>>>>>> >>>>>>>> use to upgrade the database (using a tool such as Flywaydb) and if >>>>>>>>>> >>>>>>>>> we >>>> >>>>> define a standard to create upgrade routines that would not be a >>>>>>>>>> >>>>>>>>> problem. >>>>>>> >>>>>>>> As I have written in my first email, to go from a version to >>>>>>>>>> >>>>>>>>> another >>> >>>> we >>>>>> >>>>>>> should be able to run all of the upgrade routines in between them >>>>>>>>>> (including the upgrade routine of the goal version). Therefore, if >>>>>>>>>> >>>>>>>>> we >>>> >>>>> release a version 4.6.0, and then 4.5.3, if someone upgrades to >>>>>>>>>> >>>>>>>>> 4.5.3 >>>> >>>>> from >>>>>>>>> >>>>>>>>>> any other version, and then wants to upgrade to 4.6.0, that would >>>>>>>>>> >>>>>>>>> not >>>> >>>>> be >>>>>>> >>>>>>>> a >>>>>>>>> >>>>>>>>>> problem, it would be a metter of running only the routine upgrade >>>>>>>>>> >>>>>>>>> of >>> >>>> 4.6.0 >>>>>>>>> >>>>>>>>>> version. We do not need to explicitly create upgrade paths. They >>>>>>>>>> >>>>>>>>> should >>>>>> >>>>>>> be >>>>>>>>> >>>>>>>>>> implicit by our upgrade conventions. >>>>>>>>>> >>>>>>>>>> About creating versions of the code that rely on some version of >>>>>>>>>> >>>>>>>>> the >>> >>>> database. I do not like much because of compatibility issues that >>>>>>>>>> >>>>>>>>> might >>>>>> >>>>>>> arise. For instance, let’s say version X of ACS depends on version >>>>>>>>>> >>>>>>>>> =Y >>>>>>> of >>>>>>> >>>>>>>> the database. If I upgrade the database to version Y + 1 or +2, >>>>>>>>>> >>>>>>>>> the >>> >>>> same >>>>>>> >>>>>>>> ACS version has to keep running nice and shiny. My worry is that >>>>>>>>>> >>>>>>>>> may >>> >>>> bring >>>>>>>>> >>>>>>>>>> some complications, such as to remove columns that cease to be >>>>>>>>>> >>>>>>>>> used >>> >>>> or >>>>>> >>>>>>> data >>>>>>>>> >>>>>>>>>> structure that we might want to improve. >>>>>>>>>> >>>>>>>>>> I normally see that the database version and the code base are >>>>>>>>>> >>>>>>>>> tied >>> >>>> in >>>>>> >>>>>>> a >>>>>>> >>>>>>>> mapping 1 to 1. Maybe I am having troubles identifying the >>>>>>>>>> >>>>>>>>> benefits >>> >>>> of >>>>>> >>>>>>> that >>>>>>>>> >>>>>>>>>> change. >>>>>>>>>> >>>>>>>>>> Thanks for your time ;) >>>>>>>>>> >>>>>>>>>> On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander < >>>>>>>>>> >>>>>>>>> w...@widodh.nl >>> >>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 28-12-15 21:34, Rafael Weingärtner wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Wido, Rohit, >>>>>>>>>>>> I have just read the feature suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Wido, I am not trying to complicate things, quite the opposite, >>>>>>>>>>>> >>>>>>>>>>> I >>> >>>> just >>>>>>>>> >>>>>>>>>> illustrate a simple thing that can happen and is happening; I >>>>>>>>>>>> >>>>>>>>>>> just >>> >>>> pointed >>>>>>>>>>> >>>>>>>>>>>> how it can be easily solved. >>>>>>>>>>>> >>>>>>>>>>>> About the release of .Z, releases more constant and others, I do >>>>>>>>>>>> >>>>>>>>>>> not >>>>>> >>>>>>> want >>>>>>>>>> >>>>>>>>>>> to mix topics. Let’s keep this thread strict to discuss database >>>>>>>>>>>> >>>>>>>>>>> upgrades. >>>>>>>>>>> I do not want to start the release discussion, but what I meant >>>>>>>>>>> >>>>>>>>>> is >>> >>>> that >>>>>>> >>>>>>>> we try to find a technical solution to something which might be >>>>>>>>>>> >>>>>>>>>> solved >>>>>> >>>>>>> easier by just changing the way we release. >>>>>>>>>>> >>>>>>>>>>> 4.6.0 is released and afterwards 4.5.3 is released. How does >>>>>>>>>>> >>>>>>>>>> somebody >>>>>> >>>>>>> upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code >>>>>>>>>>> >>>>>>>>>> doesn't >>> >>>> support that path. >>>>>>>>>>> >>>>>>>>>>> So my idea is to split the database version from the code >>>>>>>>>>> >>>>>>>>>> version. >>> >>>> The code requires database version >= X and during boot it simply >>>>>>>>>>> >>>>>>>>>> checks >>>>>>>>> >>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> The database migration tool can indeed do the DB migration, it >>>>>>>>>>> >>>>>>>>>> doesn't >>>>>> >>>>>>> have to be the mgmt server who does the upgrade. >>>>>>>>>>> >>>>>>>>>>> Now, about the FS. I agree with Rohit that we should have only >>>>>>>>>>>> >>>>>>>>>>> one >>> >>>> way >>>>>>>>> >>>>>>>>>> of >>>>>>>>>> >>>>>>>>>>> managing database upgrades and creation. I just do not like the >>>>>>>>>>>> >>>>>>>>>>> idea >>>>>> >>>>>>> of >>>>>>>>> >>>>>>>>>> creating a tool that work as a wrapper on frameworks/tools such >>>>>>>>>>>> >>>>>>>>>>> as >>> >>>> flywaydb. I think that those frameworks already work pretty good >>>>>>>>>>>> >>>>>>>>>>> as >>>> >>>>> they >>>>>>>>>> >>>>>>>>>>> are; and, I would rather maintain configurations than some >>>>>>>>>>>> >>>>>>>>>>> wrapper >>> >>>> code. >>>>>>>>>> >>>>>>>>>>> I personally like the way ACS works during upgrades (I just do >>>>>>>>>>>> >>>>>>>>>>> not >>> >>>> like >>>>>>>>> >>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>>> code itself and how things are structured), as a system >>>>>>>>>>>> >>>>>>>>>>> administrator I >>>>>>>>> >>>>>>>>>> like to change the version in the >>>>>>>>>>>> >>>>>>>>>>> “/etc/apt/sources.list.d/cloudstack.list” >>>>>>>>>>> >>>>>>>>>>>> and use the "apt-get" "update" and "install" from the command >>>>>>>>>>>> >>>>>>>>>>> line. I >>>>>> >>>>>>> do >>>>>>>>>> >>>>>>>>>>> not see the need to add another tool that is just a wrapper to >>>>>>>>>>>> >>>>>>>>>>> the >>> >>>> mix. >>>>>>>>> >>>>>>>>>> If >>>>>>>>>>> >>>>>>>>>>>> I update ACS code to 4.7.0, why would I let the database schema >>>>>>>>>>>> >>>>>>>>>>> in >>> >>>> an >>>>>> >>>>>>> older >>>>>>>>>>> >>>>>>>>>>>> version? And if we want version DB schemas and application code >>>>>>>>>>>> >>>>>>>>>>> separately >>>>>>>>>>> >>>>>>>>>>>> maintaining somehow compatibility between them, which would >>>>>>>>>>>> >>>>>>>>>>> bring >>> >>>> a >>>> >>>>> whole >>>>>>>>>> >>>>>>>>>>> other level of complexity to the code; I think we should avoid >>>>>>>>>>>> >>>>>>>>>>> that. >>>>>> >>>>>>> The flywaydb can be easily integrated with everything we have >>>>>>>>>>>> >>>>>>>>>>> now; >>> >>>> we >>>>>> >>>>>>> could >>>>>>>>>>> >>>>>>>>>>>> have a maven profile for developers and integrate it in ACS >>>>>>>>>>>> >>>>>>>>>>> bootstrap >>>>>> >>>>>>> using >>>>>>>>>>> >>>>>>>>>>>> its API as a Spring bean. Therefore, we could remove the current >>>>>>>>>>>> “DatabaseUpgradeChecker “, “DbUpgrade” and other classes that >>>>>>>>>>>> >>>>>>>>>>> aim >>> >>>> to >>>>>> >>>>>>> do >>>>>>>>> >>>>>>>>>> that. We could even add the creation of the schema into the >>>>>>>>>>>> >>>>>>>>>>> first >>> >>>> time >>>>>>>>> >>>>>>>>>> it >>>>>>>>>> >>>>>>>>>>> boots using flywaydb and retire the “cloudstack-setup-database” >>>>>>>>>>>> >>>>>>>>>>> script, >>>>>>>>> >>>>>>>>>> or >>>>>>>>>>> >>>>>>>>>>>> at least make it less complicated, using it just to configure >>>>>>>>>>>> >>>>>>>>>>> the >>> >>>> database >>>>>>>>>>> >>>>>>>>>>>> URL and users. >>>>>>>>>>>> >>>>>>>>>>>> The point is that to use Flywaydb we would have to agree upon a >>>>>>>>>>>> >>>>>>>>>>> convention >>>>>>>>>>> >>>>>>>>>>>> on creating routines (java and SQL) to execute upgrades. >>>>>>>>>>>> >>>>>>>>>>> Moreover, >>> >>>> using >>>>>>>>>> >>>>>>>>>>> a >>>>>>>>>>> >>>>>>>>>>>> tool such as Flywaydb we do not need to worry about upgrade >>>>>>>>>>>> >>>>>>>>>>> paths. >>> >>>> As I >>>>>>>>> >>>>>>>>>> wrote in the email I used to start this thread, the upgrade has >>>>>>>>>>>> >>>>>>>>>>> to >>> >>>> be >>>>>> >>>>>>> straightforward, to go to a version we have to run all of the >>>>>>>>>>>> >>>>>>>>>>> upgrade >>>>>> >>>>>>> routines between the current version until the desired one. Our >>>>>>>>>>>> >>>>>>>>>>> job >>>> >>>>> is >>>>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>>> create upgrade routines that work and name them properly, the >>>>>>>>>>>> >>>>>>>>>>> job >>> >>>> of >>>>>> >>>>>>> the >>>>>>>>>> >>>>>>>>>>> tool is to check the current version, the desired one, the >>>>>>>>>>>> >>>>>>>>>>> upgrades >>>> >>>>> that >>>>>>>>>> >>>>>>>>>>> it >>>>>>>>>>> >>>>>>>>>>>> needs to run and execute everything properly. >>>>>>>>>>>> >>>>>>>>>>>> Yes, indeed. I just wanted to start the discussion if we >>>>>>>>>>> >>>>>>>>>> shouldn't >>> >>>> version the database differently from the code. >>>>>>>>>>> >>>>>>>>>>> Additionally, I do not see the need to break compatibility as >>>>>>>>>>>> >>>>>>>>>>> Rohit >>>> >>>>> suggested in the FS; in my opinion, everything we have up today >>>>>>>>>>>> >>>>>>>>>>> can >>>> >>>>> be >>>>>>>>> >>>>>>>>>> migrated to the new structure I proposed. If we use a tool such >>>>>>>>>>>> >>>>>>>>>>> as >>> >>>> Flywaydb, I even volunteered for that. The only thing we have to >>>>>>>>>>>> >>>>>>>>>>> discuss >>>>>>>>>> >>>>>>>>>>> and agree upon is the naming conventions for upgrades routines, >>>>>>>>>>>> >>>>>>>>>>> where >>>>>> >>>>>>> to >>>>>>>>>> >>>>>>>>>>> put them and the configurations for flywaydb. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for your contribution and time. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Dec 28, 2015 at 2:10 PM, Rohit Yadav < >>>>>>>>>>>> >>>>>>>>>>> rohit.ya...@shapeblue.com> >>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Rafael and Wido, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for starting a conversation in this regard, I could not >>>>>>>>>>>>> >>>>>>>>>>>> pursue >>>>>>>>> >>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>>> Chimp tool due to other $dayjob work though it’s good to see >>>>>>>>>>>>> >>>>>>>>>>>> some >>> >>>> discussion has started again. Hope we’ll solve this in 2016. >>>>>>>>>>>>> >>>>>>>>>>>>> In my opinion, we will need to first separate the database >>>>>>>>>>>>> >>>>>>>>>>>> init/migration >>>>>>>>>>> >>>>>>>>>>>> tooling away from mgmt server (right now the mgmt server does >>>>>>>>>>>>> >>>>>>>>>>>> db >>> >>>> migrations >>>>>>>>>>> >>>>>>>>>>>> when it starts and there is a code/db version mismatch) and >>>>>>>>>>>>> >>>>>>>>>>>> secondly >>>>>> >>>>>>> make >>>>>>>>>>> >>>>>>>>>>>> sure that we’re using the same code/tool to deploy database >>>>>>>>>>>>> >>>>>>>>>>>> (right >>>> >>>>> now, >>>>>>>>>> >>>>>>>>>>> users use the cloudstack-setup-database python tool while >>>>>>>>>>>>> >>>>>>>>>>>> developer >>>>>> >>>>>>> use >>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>>> maven/java DatabaseCreator activated by the -Ddeploydb flag). >>>>>>>>>>>>> >>>>>>>>>>>>> After we’ve addressed these two issues we can look into how we >>>>>>>>>>>>> >>>>>>>>>>>> can >>>> >>>>> support >>>>>>>>>>> >>>>>>>>>>>> minor releases workflow (or decide to do something else, like >>>>>>>>>>>>> >>>>>>>>>>>> not >>> >>>> support >>>>>>>>>>> >>>>>>>>>>>> .Z releases like Wido mentioned), and see if we can or want to >>>>>>>>>>>>> >>>>>>>>>>>> use >>>> >>>>> any >>>>>>>>> >>>>>>>>>> existing migration tool or write a wrapper tool “chimp” that >>>>>>>>>>>>> >>>>>>>>>>>> uses >>> >>>> existing >>>>>>>>>>> >>>>>>>>>>>> tools (some of those are mentioned in the Chimp FS like >>>>>>>>>>>>> >>>>>>>>>>>> flywaydb >>> >>>> etc). >>>>>>>>> >>>>>>>>>> For >>>>>>>>>>> >>>>>>>>>>>> allowing users to go back and forth from a db schema/version, >>>>>>>>>>>>> >>>>>>>>>>>> we’ll >>>>>> >>>>>>> also >>>>>>>>>> >>>>>>>>>>> need some new DB migration >>>>>>>>>>>>> >>>>>>>>>>>> conventions/versioning/rules/static-checking, >>>>>>>>>> >>>>>>>>>>> and how developer need to write such paths (forward and >>>>>>>>>>>>> >>>>>>>>>>>> reverse) >>> >>>> etc. >>>>>>>>> >>>>>>>>>> The best approach I figured at the time was to decide that >>>>>>>>>>>>> >>>>>>>>>>>> we’ll >>> >>>> use >>>>>> >>>>>>> the >>>>>>>>>> >>>>>>>>>>> previous db upgrade path mechanism till a certain CloudStack >>>>>>>>>>>>> >>>>>>>>>>>> version >>>>>> >>>>>>> (say >>>>>>>>>>> >>>>>>>>>>>> 4.8.0) and after that we’ll use the new approach or tooling to >>>>>>>>>>>>> upgrade/downgrade DB schemas (thereby retiring away from the >>>>>>>>>>>>> >>>>>>>>>>>> old >>> >>>> DB >>>>>> >>>>>>> upgrade >>>>>>>>>>> >>>>>>>>>>>> path mess). >>>>>>>>>>>>> >>>>>>>>>>>>> [image: ShapeBlue] <http://www.shapeblue.com> Rohit Yadav >>>>>>>>>>>>> >>>>>>>>>>>> Software >>>>>> >>>>>>> Architect , ShapeBlue d: * | s: +44 203 603 0540* >>>>>>>>>>>>> <%7C%20s:%20+44%20203%20603%200540> | m: *+91 8826230892* >>>>>>>>>>>>> <+91%208826230892> e: *rohit.ya...@shapeblue.com | t: * >>>>>>>>>>>>> <rohit.ya...@shapeblue.com%20%7C%20t:> | w: * >>>>>>>>>>>>> >>>>>>>>>>>> www.shapeblue.com >>>> >>>>> * >>>>>> >>>>>>> <http://www.shapeblue.com> a: >>>>>>>>>>>>> 53 Chandos Place, Covent Garden London WC2N 4HS UK Shape Blue >>>>>>>>>>>>> >>>>>>>>>>>> Ltd >>> >>>> is a >>>>>>>>> >>>>>>>>>> company incorporated in England & Wales. ShapeBlue Services >>>>>>>>>>>>> >>>>>>>>>>>> India >>> >>>> LLP >>>>>>>>> >>>>>>>>>> is a >>>>>>>>>>> >>>>>>>>>>>> company incorporated in India and is operated under license >>>>>>>>>>>>> >>>>>>>>>>>> from >>> >>>> Shape >>>>>>>>> >>>>>>>>>> Blue >>>>>>>>>>> >>>>>>>>>>>> Ltd. Shape Blue Brasil Consultoria Ltda is a company >>>>>>>>>>>>> >>>>>>>>>>>> incorporated >>> >>>> in >>>>>> >>>>>>> Brasil >>>>>>>>>>> >>>>>>>>>>>> and is operated under license from Shape Blue Ltd. ShapeBlue SA >>>>>>>>>>>>> >>>>>>>>>>>> Pty >>>>>> >>>>>>> Ltd >>>>>>>>>> >>>>>>>>>>> is >>>>>>>>>>> >>>>>>>>>>>> a company registered by The Republic of South Africa and is >>>>>>>>>>>>> >>>>>>>>>>>> traded >>>> >>>>> under >>>>>>>>>> >>>>>>>>>>> license from Shape Blue Ltd. ShapeBlue is a registered >>>>>>>>>>>>> >>>>>>>>>>>> trademark. >>> >>>> This email and any attachments to it may be confidential and >>>>>>>>>>>>> >>>>>>>>>>>> are >>> >>>> intended >>>>>>>>>>> >>>>>>>>>>>> solely for the use of the individual to whom it is addressed. >>>>>>>>>>>>> >>>>>>>>>>>> Any >>> >>>> views >>>>>>>>>> >>>>>>>>>>> or >>>>>>>>>>> >>>>>>>>>>>> opinions expressed are solely those of the author and do not >>>>>>>>>>>>> >>>>>>>>>>>> necessarily >>>>>>>>>> >>>>>>>>>>> represent those of Shape Blue Ltd or related companies. If you >>>>>>>>>>>> >>>>>>>>>>>> -- Daan
