Jump to content
Don Lee

Retro 9 and 10 console on same machine?

Recommended Posts

I have several retro engine installations, and am starting my upgrade cycle.

 

Does anyone have experience running both Retro 9 console and Retro 10 console on the same machine? I will want to manage both v9 and v10 engines from the same machine. (I don't insist on running both consoles at the same time, though. ;-> )

 

Is managing both 9 and 10 engines *supported* from the Retro 10 console?

Edited by iCompute

Share this post


Link to post
Share on other sites

We did not test that particular configuration, so it's not supported. That said, we did add safeguards, so that new features like Script Save/Revert work correctly for both versions of the engine. Let us know how the upgrade process goes.

Share this post


Link to post
Share on other sites

We did not test that particular configuration, so it's not supported. That said, we did add safeguards, so that new features like Script Save/Revert work correctly for both versions of the engine. Let us know how the upgrade process goes.

 

bdunagan, how can you NOT have tested "that particular configuration"??? You have a console application that supports managing multiple servers/engines, but you don't think that some users might need the ability to manage more than just the current version????? I mentioned this to Robin about v9 and basically got the brush-off. It seems that incrementing version #s and extracting cash has become far more important than taking care of your customers by providing a useful tool.

 

With laughably high upgrade pricing and complete disregard for previous purchases and sufferings, how on Earth can a consultant like myself (who foolishly bought fully in to Retrospect 8 and) has 8 different servers to manage for my clients possibly convince them all to upgrade to v10 at once, especially considering Retrospect the company is more concerned w/ jumping to a new paid version at maximum warp than fixing bugs in the previous one? At best, new v10 versions of the Console should talk to and fully manage v8 and v9 Engines. At worst, we should AT LEAST be able to run 2 different Consoles, but this isn't the case either (and again, WHY wouldn't you have tested this? Unbelievable!), since v10 is still using and trampling over the Config80.dat files that began w/ v8. How in the world can we not at least have Config90.dat and Config100.dat files, so that different versions can co-exist?

 

Please get your acts together.

 

Fred Turner

 

P.S. Man, am I tired of ranting here, but this arrogance and lack of concern for customers' needs is unreal!

Share this post


Link to post
Share on other sites

Question to follow up: If I upgrade my engine (on a different machine) and then run a v9 console and a v10 console on my laptop, will I have two configurations - one for the v9 console and one for the v10 console, or will the console configuration be "shared"?

 

I don't ask for full upward and downward compatibility between the mismatched engines/consoles, but if that is not provided, I am hoping for confirmation that the consoles will not damage each other's configuration files.

 

Bonus points if I can run both consoles, and they have separate configs, so I can "move' the engines from one console to the next as they are upgraded.

 

It sounds like I can probably use the v10 console on a v9 engine, but this may not be safe (not tested)

 

fredturner (above) suggests that the v9 and v10 consoles "step on" each others' configuration files.

 

What is the recommended procedure for those of us with multiple engines to manage?

Share this post


Link to post
Share on other sites

bdunagan, how can you NOT have tested "that particular configuration"??? You have a console application that supports managing multiple servers/engines, but you don't think that some users might need the ability to manage more than just the current version????? I mentioned this to Robin about v9 and basically got the brush-off. It seems that incrementing version #s and extracting cash has become far more important than taking care of your customers by providing a useful tool.

 

With laughably high upgrade pricing and complete disregard for previous purchases and sufferings, how on Earth can a consultant like myself (who foolishly bought fully in to Retrospect 8 and) has 8 different servers to manage for my clients possibly convince them all to upgrade to v10 at once, especially considering Retrospect the company is more concerned w/ jumping to a new paid version at maximum warp than fixing bugs in the previous one? At best, new v10 versions of the Console should talk to and fully manage v8 and v9 Engines. At worst, we should AT LEAST be able to run 2 different Consoles, but this isn't the case either (and again, WHY wouldn't you have tested this? Unbelievable!), since v10 is still using and trampling over the Config80.dat files that began w/ v8. How in the world can we not at least have Config90.dat and Config100.dat files, so that different versions can co-exist?

 

Please get your acts together.

 

Fred Turner

 

P.S. Man, am I tired of ranting here, but this arrogance and lack of concern for customers' needs is unreal!

 

I'm in the same boat. I manage five different clients, all running Retrospect 8. I can't upgrade one without upgrading all. So everyone is stuck at V8. The odds of getting all five companies to upgrade at once is nil.

 

What is so difficult in having each console version just use their own separate pref files? Seems trivial.

Share this post


Link to post
Share on other sites

Given that the pref files are per-user, there is a very crude way to do this. Set up a different user on your management machine for each version of the console you need to run.

 

It's not pretty, but it would work. ;-> (for very small values of "work")

Share this post


Link to post
Share on other sites

I would add that this could/should be an important feature of the console, to non-destructively interoperate with the older engines. The new consoles don't even have to support the full feature set. They would simply have to be able to manage the older engines without doing anything "bad". Given that there are more people out there running v8 and v9, and having multiple "clients" that need to be managed, this need will become more urgent as new versions are released..

Share this post


Link to post
Share on other sites

Update: I upgraded my engine to 10.0.1 (105) yesterday (running on a 10.6.8 machine) and am running the 10.0 console with the 9.0 "remote" engines. As far as I can tell, it works fine, with the exception of some nits.

 

Take care with 9.0 console on 10.0 engine. It offers you the chance to "upgrade" the engine from 10.0 to 9.0. Oops.

 

It looks workable with the 10.0 console, and 9.x engines.

 

Keeping my fingers crossed.

Share this post


Link to post
Share on other sites

OK, guys. I think we are on the same page now. I see that you guys have been highlighting this issue for almost a year, in support cases and forum posts (http://forums.retrospect.com/index.php?/topic/147798-administering-mixture-of-retro-8-9-servers/). We've done a poor job handling your scenario, and we're going to fix that in the upcoming free update.

 

The next console will offer significantly better support for managing multiple servers with different versions. It will fully support v9.0+ servers and partially support v8.2 (if you only need to monitor). For fully managing v8.2 servers, you'll need to continue using the v8.2 console, but you'll be able to use it simultaneously with the next console. Moreover, the next console will only ask about upgrading your older server instances once. Finally, our free Retrospect for iOS app can monitor 8.2, 9.0.x, and 10.0.x servers right now: https://itunes.apple.com/us/app/retrospect/id496306645?mt=8.

 

To answer the other questions:

* shared configurations: v9.0+ versions of the console all share the same configuration file (located in ~/Library/Preferences/com.retrospect.retrospect.plist).

* Config80.dat: This is the server's configuration file (located in /Library/Application Support/Retrospect/). While it has 8.0 in the name, we've used the same file name for every version since then and plan to continue doing so.

* v9.0 and v10.0: We originally didn't test managing v9.0 and v10.0 servers simultaneously from a v10.0 console, so we did that over the holidays just to be sure. No problems. Please use it if it fits for your environment.

* v9.0 console with v10.0 engine: As you saw, the console doesn't do a great job deciding when to attempt a server upgrade. We fixed that in v10.0 and on.

 

We hope these upcoming refinements make managing multiple servers a better experience. Let us know what you think or if I missed something.

Share this post


Link to post
Share on other sites

Excellent. Thank you.

 

This all comports with my experience. v10 console seems to work fine managing both v9 and v10 engines. (I don't have v8 engines to test)

 

Looking forward to the updates.

Share this post


Link to post
Share on other sites

I finally had the courage to try a 10.1 upgrade (from 8.2) on two of my clients. The 10.1 console does report that it can monitor the other 8.2 engines with "limited support". The 8.2 console (running on the same computer) admins the 8.2 engines and doesn't get it's prefs trampled by the 10.1 console.

 

THANK YOU!

 

I can now proceed to get each company to upgrade on their own schedule, while maintaining a sane method of administering the varying engine versions.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×