Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-2764

Deploy Rice standalone server to our test environments

    Details

      Description

      Here are the notes from our meeting today regarding this:

      • Update the build.xml in rice and add dist-external and dist-war
        • generated war file from dist-war will get automatically deployed to wsa131 via the j2ee_deploy_war script on wsa123
      • We need to update do-daily-updates.sh in kul-cfg-envs to add "kupdate" statements in our script so that we execute the daily update
        • Initially, let's start with just the STG environment and use the RICESTG database
        • part of the kupdate script should be able to create the RICESTG database using our nightly database export
        • so our first environments will use the STG database
      • Update /usr/local/rice/rice-config.xml to reflect configuration changes in rice 1.0, verify files in /usr/local/rice/stg/...
      • at any point during the day we can probably just run do-daily-updates.sh to test an initial deployment
        • IMPORTANT: no two projects can run their updates scripts at the same time
      • We also need to update (and move to KULRICE) the documentation at the following location:
        https://test.kuali.org/confluence/display/KULFOUND/Kuali+Rice+Test+Environments

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Bulk change of all Rice 1.0 issues to closed after public release.

            Show
            ewestfal Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.
            Hide
            caseyhb Casey Boettcher (Inactive) added a comment -

            Potential further work would involve understanding why PATH had to be set explicitly in 'maven' macro in order to avoid javac FileNotFound error

            Show
            caseyhb Casey Boettcher (Inactive) added a comment - Potential further work would involve understanding why PATH had to be set explicitly in 'maven' macro in order to avoid javac FileNotFound error
            Hide
            caseyhb Casey Boettcher (Inactive) added a comment -

            More info on the problem reported in this comment: https://test.kuali.org/jira/browse/KULRICE-2764?focusedCommentId=119846#action_119846

            Both j2eemgr and tomcat users have javac on their paths, both on wsa123 and wsa131

            I've forced the PATH environment variable to include /usr/local/java/bin for the forked JVM created by the maven macro in rice's build.xml. I've also turned on debugging and included an echo task that will hopefully echo the true PATH used by the forked JVM, though, on reflection, the output might not accurately reflect its environment. Does a JVM inherit the environment from which it's spawned?

            Note that, even were I to want to set the maven.build flag (as I suggested at the end of the referenced comment) I could not have done so, because of the way this system of scripts is set up and because of the logic behind ant's if/unless target attributes. In order to have maven.build in the generated ant properties file, I would have to alter the ksetprops function to echo this into the generated file from the rice settings file. But this would occur for every project (KC, KFS and rice). That's not a problem, since I could set a default of "false" in the shared-properties file and a value of "true" in the Rice settings file. That would be superfluous code, however, because regardless of the value maven.build is set to, the dist-maven target would be run instead of dist-ant for every project. In ant, "if" and "unless" check for the existence of a property and disregard its value entirely.

            Show
            caseyhb Casey Boettcher (Inactive) added a comment - More info on the problem reported in this comment: https://test.kuali.org/jira/browse/KULRICE-2764?focusedCommentId=119846#action_119846 Both j2eemgr and tomcat users have javac on their paths, both on wsa123 and wsa131 I've forced the PATH environment variable to include /usr/local/java/bin for the forked JVM created by the maven macro in rice's build.xml. I've also turned on debugging and included an echo task that will hopefully echo the true PATH used by the forked JVM, though, on reflection, the output might not accurately reflect its environment. Does a JVM inherit the environment from which it's spawned? Note that, even were I to want to set the maven.build flag (as I suggested at the end of the referenced comment) I could not have done so, because of the way this system of scripts is set up and because of the logic behind ant's if/unless target attributes. In order to have maven.build in the generated ant properties file, I would have to alter the ksetprops function to echo this into the generated file from the rice settings file. But this would occur for every project (KC, KFS and rice). That's not a problem, since I could set a default of "false" in the shared-properties file and a value of "true" in the Rice settings file. That would be superfluous code, however, because regardless of the value maven.build is set to, the dist-maven target would be run instead of dist-ant for every project. In ant, "if" and "unless" check for the existence of a property and disregard its value entirely.
            Hide
            ewestfal Eric Westfall added a comment -

            Casey, that sounds like a good idea if we can get that to work. A couple of things we need to consider though:

            1) dist-server is currently overlaying files from web/src/main/config into the standalone war, this includes things like license acknowledgements and an updated index.html that doesn't include the sample application links. We'll need to try and figure out how to do something similar in maven
            2) dist-server is executing a replacement of "dev" with the environment code in web.xml in the WAR file. We will need to figure out how to do this as well so that the packaged web.xml has the correct environment code.

            Show
            ewestfal Eric Westfall added a comment - Casey, that sounds like a good idea if we can get that to work. A couple of things we need to consider though: 1) dist-server is currently overlaying files from web/src/main/config into the standalone war, this includes things like license acknowledgements and an updated index.html that doesn't include the sample application links. We'll need to try and figure out how to do something similar in maven 2) dist-server is executing a replacement of "dev" with the environment code in web.xml in the WAR file. We will need to figure out how to do this as well so that the packaged web.xml has the correct environment code.
            Hide
            caseyhb Casey Boettcher (Inactive) added a comment -

            Files related to KULRICE-2764

            Show
            caseyhb Casey Boettcher (Inactive) added a comment - Files related to KULRICE-2764

              People

              • Assignee:
                caseyhb Casey Boettcher (Inactive)
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2 days, 4 hours
                  2d 4h
                  Remaining:
                  Remaining Estimate - 2 days, 4 hours
                  2d 4h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified