9:43 p.m.
At first glance in the scenario you list below, there's no need to even bother with
the promotion concept. You would just install the new version (with a new name) and let
apps point over to it as they are ready.
To achieve the flow your suggesting without versioning would actually require an extra
step. Prior to promoting the next version, you would need to deploy a duplicate of the
current version with a new name. Then the small set of apps not ready for the update
would need to have their connections pointed to the copy. Then you could safely promote
the next version without interrupting the lagging apps.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>,
"teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
> Well there are two possibilities here. One is that there is a
> roll-back. The other is that a new version of a VDB has been chosen as
> the default but some of the organization is not ready to use the newer
> version. In which case they would modify their clients to use the
> previous version until they are ready to use the new one.
>
> So, in the "roll-back" scenario, the change is transparent to the
> clients while in the "not-ready-to-upgrade" scenario the administrative
> change is placed on the client. These are the two cases we have with
> legacy customers.
Maybe I'm misunderstanding, but I don't believe your "new version"
scenario makes practical sense. If an organization is implementing a
new version and not ready to force that change on certain
applications, departments, etc., wouldn't they want just that - no
change to those areas? They're likely not going to impose the need to
change a slew of existing clients to use the old VDB just to enable
new clients to use the previous VDB name. Rather, they'd want to
deploy the new VDB with a new name that only the new clients use.
Then migration to the new VDB name for other clients could be easily
scheduled and managed. Seems like the alternative would be a
change-control nightmare.
Here is how it works. All clients are using an existing VDB and
development creates a new version of that VDB. They put it through all
the testing and identify any possible conflicts and changes that a
client may need to make. The VDB is then slated to be migrated to
production during their quarterly maintenance window. However, a small
group within the organization have not been able to complete all of
their testing necessary to use the new version of the VDB. In this
case, a business decision is made to proceed with the migration into
production and the "small group" is notified that they have until MM/dd
to complete their testing or they will need to point their clients at an
old version of the VDB. The old version will be left in production but
as a deprecated source.
--
Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary(a)redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Looking to carve out IT costs?
http://www.redhat.com/carveoutcosts/
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
10:17 p.m.
New subject: [teiid-designer-dev] VDB Versioning Feature
On Thu, 2010-02-18 at 15:43 -0500, Steven Hawkins wrote:
At first glance in the scenario you list below, there's no need
to
even bother with the promotion concept. You would just install the
new version (with a new name) and let apps point over to it as they
are ready.
To achieve the flow your suggesting without versioning would actually
require an extra step. Prior to promoting the next version, you would
need to deploy a duplicate of the current version with a new name.
Then the small set of apps not ready for the update would need to have
their connections pointed to the copy. Then you could safely promote
the next version without interrupting the lagging apps.
+1
Especially when in this situation clients have to anyhow modify their
client settings to explicit version number to avoid the automatic
promotion. Instead they need to change the name.
Another side effect of with the version scheme is you have clients
deployment profiles segmented, some are banking on the "active-default"
behavior and some are banking on the explicit version behavior. Say once
everybody migrated to same "latest" version, it is good likely hood that
the client profiles with explicit version numbers will not be re-visited
to fix them to use "active-default" thus they fail to promote themselves
when next version rolls around.
Ramesh..
11:13 p.m.
New subject: [teiid-designer-dev] VDB Versioning Feature
On Thu, 2010-02-18 at 15:43 -0500, Steven Hawkins wrote:
At first glance in the scenario you list below, there's no need
to
even bother with the promotion concept. You would just install the
new version (with a new name) and let apps point over to it as they
are ready.
Well, except for the fact that the clients do not want to change their
connection properties. In other words, whatever the business as a whole
deems as the latest and greatest, they are fine with. It is just that
there is normally some stragglers that do things their way and disregard
the business decision. In these cases, these stragglers would be
responsible for updating their client connection properties to point to
the renamed (previous version) VDB. Must like in legacy, they would
update their connection properties to point to the old version.
To achieve the flow your suggesting without versioning would
actually
require an extra step. Prior to promoting the next version, you would
need to deploy a duplicate of the current version with a new name.
Then the small set of apps not ready for the update would need to have
their connections pointed to the copy. Then you could safely promote
the next version without interrupting the lagging apps.
Right. In this scenario the new VDB would get the name of the old VDB
so that client apps that were following the business decision would not
need to make a change to get the newer VDB. And the lagging users would
update their clients to point to the renamed VDB.
I am not familiar with how we are packaging and naming VDBs to achieve
this but in my opinion, making this a manual process seems logical and
there would be no need for the system to automatically keep track of
things.
Furthermore, the functionality of "active-default" can be achieved the
same way. Just make the active-default or latest version a base name.
MyCoolSource.vdb. When a new version is available for integration
testing but you are not ready to promote it to the "active-default" or
"latest-version", deploy it as MyCoolSource_NextGen.vdb. In this case,
users who want to use the NextGen version would simply change their
client app to point to MyCoolSource_NextGen.vdb and everyone else will
continue to use the "active-default" of MyCoolSource.vdb.
When you are ready to move the "active-default" to the contents of
MyCoolSource_NextGen.vdb then you simply copy MyCoolSource.vdb to
MyCoolSource_OldGen.vdb, copy MyCoolSource_NextGen.vdb to
MyCoolSource.vdb and voila. The only downside here is that
MyCoolSource.vdb and MyCoolSource_NextGen.vdb are duplicates but I
really don't see this as a problem.
The naming convention would be up to business rules and we might want to
make some kind of best practice suggestions to make this manageable but
concept could be just as easily accomplished with version numbers in the
name:
MyCoolSource_v1.vdb
MyCoolSource_v2.vdb
MyCoolSource_v3.vdb
And to achieve "active-default" or "latest-version" you would use
MyCoolSource.vdb -> MyCoolSource_v3.vdb as a symbolic link or copy of
the version you wanted to use.
Of course, this logic all falls apart if the VDB actually contains a
descriptor that defines its name to the system in which case the process
is the same but a bit more complicated because you wouldn't be able to
simply copy/symlink.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>,
"teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
> On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
>
> > Well there are two possibilities here. One is that there is a
> > roll-back. The other is that a new version of a VDB has been chosen as
> > the default but some of the organization is not ready to use the newer
> > version. In which case they would modify their clients to use the
> > previous version until they are ready to use the new one.
> >
> > So, in the "roll-back" scenario, the change is transparent to the
> > clients while in the "not-ready-to-upgrade" scenario the
administrative
> > change is placed on the client. These are the two cases we have with
> > legacy customers.
>
> Maybe I'm misunderstanding, but I don't believe your "new
version"
> scenario makes practical sense. If an organization is implementing a
> new version and not ready to force that change on certain
> applications, departments, etc., wouldn't they want just that - no
> change to those areas? They're likely not going to impose the need to
> change a slew of existing clients to use the old VDB just to enable
> new clients to use the previous VDB name. Rather, they'd want to
> deploy the new VDB with a new name that only the new clients use.
> Then migration to the new VDB name for other clients could be easily
> scheduled and managed. Seems like the alternative would be a
> change-control nightmare.
>
Here is how it works. All clients are using an existing VDB and
development creates a new version of that VDB. They put it through all
the testing and identify any possible conflicts and changes that a
client may need to make. The VDB is then slated to be migrated to
production during their quarterly maintenance window. However, a small
group within the organization have not been able to complete all of
their testing necessary to use the new version of the VDB. In this
case, a business decision is made to proceed with the migration into
production and the "small group" is notified that they have until MM/dd
to complete their testing or they will need to point their clients at an
old version of the VDB. The old version will be left in production but
as a deprecated source.
--
Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary(a)redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Looking to carve out IT costs?
http://www.redhat.com/carveoutcosts/
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
5180
days inactive
5180
days old
2 comments
3 participants
participants (3)
-
Larry O'Leary -
Ramesh Reddy -
Steven Hawkins