Sounds good. Pretty similar to what I was thinking. Is #4 (Install wizard should not ask you the typical series of questions about db connect string, user/pass, root user/pass. Instead the standalone should have set these to fixed values) because all the credentials on the production system will be transferred? We're not suggesting that we'd have fixed username/password for the test system containing production data, are we?
For #8, regarding "the user doesn't see this happening", how about a progress bar in case the production system, the connection to it, or the data transfer is slow? As far as encrypting the data being transferred, this would be great as long as it can be done relatively easily, since it will be production data. How about having the standalone generate a long (e.g., 1024-character) random string, passing it to the production server, and then using that string to encrypt & decrypt the data. That way, the key would only exist in the memory of the standalone while it was transferring the data. Cheers, -Burke On Mon, Nov 7, 2011 at 9:22 PM, Darius Jazayeri <[email protected]> wrote: > Wyclif and I discussed on IRC, and came up with this: > > 1. User downloads standalone, unzips, and double clicks on the JAR > 2. User chooses a "show me install wizard" option (needs a ticket) > 3. Install wizard asks (a) Standard, (b) Custom, (c) Test an upgrade > (requires uncommenting some code that already exists). User chooses (c). > 4. Install wizard should *not* ask you the typical series of questions > about db connect string, user/pass, root user/pass. Instead the standalone > should have set these to fixed values. > 5. Install wizard asks for the URL of the production server you want > to test an upgrade for. > 6. Test server verifies that the production server is reachable at > that URL, and that it's running the Release Testing module. If either check > fails, give an appropriate error message, and return to the previous step. > 7. Test server asks user for username/password for the production > server, and verifies that they're valid. If not, ask again. > 8. Test server uses those credentials to fetch an appropriate sql > dump, and zip file of modules. (It does this server-side, the user doesn't > see this happening. To do: decide whether we need to encrypt the sqldump we > write to a temp directory, or if the Release Testing module should > de-identify it as it outputs it.) > 9. Install wizard loads up the sql dump, and puts the modules in the > right place. > 10. Install wizard runs the liquibase update scripts > 11. Finally, a login screen! > > -Darius > > On Mon, Nov 7, 2011 at 5:42 PM, Darius Jazayeri <[email protected]>wrote: > >> Hi Wyclif, >> >> I was wondering if you could give a step-by-step overview of the process >> you're envisioning as our target from this sprint. >> >> 1. User downloads standalone 1.9-beta, unzips it, and double clicks on >> the JAR >> ...(what happens here)... >> N. User sees a login window to a standalone instance whose DB is >> populated with data from an existing install. >> >> -Darius >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
