⬆️ Upgrade all dependencies to the latest #83
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
3 times, most recently
from
20515bc
to
e1c31a0
Compare
The fact that the non-ISO login options were available in the demo labeled ISO was just confusing. Also set up the infastructure to apply patches, and applied at least one patch to start with. Changed the nodered flow to use the appropriate case for the payment method. Testing done: - Ran `bash demo-iso15118-2-ocpp-201.sh -3` - Plugged in with PnC - Charging started Signed-off-by: Shankari <[email protected]>
Before this, if we wanted to make changes to the demo, we used to comment code in/out. Let's make those switches available as command line arguments to avoid editing the script constantly. Testing done: - Ran `bash demo-iso15118-2-ocpp-201.sh -r $PWD -1` - and `bash demo-iso15118-2-ocpp-201.sh -r $PWD -1 -m` and everything launched both times. Signed-off-by: Shankari <[email protected]>
The citrine setup scripts are already pulled out,
pulling out maeve as well to prep for a more significant
refactor later.
Testing done:
`bash demo-iso15118-2-ocpp-201.sh -r $PWD -3 -m` and
successfully connected to maeve
```
2024-11-11 21:59:26.836301 [INFO] ocpp:OCPP201 :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3
2024-11-11 21:59:26.886329 [INFO] evse_security:E :: Requesting key/pair: CSMS
2024-11-11 21:59:27.216402 [INFO] ocpp:OCPP201 :: OCPP client successfully connected to TLS websocket server
2024-11-11 21:59:27.228421 [INFO] ocpp:OCPP201 :: Received BootNotificationResponse: {
"currentTime": "2024-11-11T21:59:27.000Z",
"interval": 300,
"status": "Accepted"
}
with messageId: 9327a063-11c5-4946-9ec4-96631fd09adb
```
Signed-off-by: Shankari <[email protected]>
To simplify the script and make it easier to refactor.
Testing done:
- maeve starts up and the manager connects to it
- citrineos does not start up, but that is unchanged from the
main branch
Will punt on debugging citrineos until we have rolled forward
- maeve testing
```
2024-11-11 22:43:40.693974 [INFO] ocpp:OCPP201 :: Using certificate: "/ext/source/build/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
2024-11-11 22:43:40.694660 [INFO] ocpp:OCPP201 :: Using key file: "/ext/source/build/dist/etc/everest/certs/client/csms/CSMS_LEAF.key"
2024-11-11 22:43:40.701120 [INFO] evse_security:E :: Building new certificate hierarchy!
2024-11-11 22:43:40.780705 [INFO] evse_security:E :: Requesting certificate file: [CSMS] file:"/ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-11-11 22:43:40.737677 [DEBG] ocpp:OCPP201 :: Loading ca csms bundle to verify server certificate: /ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-11-11 22:43:40.823477 [INFO] evse_security:E :: Requesting certificate file: [CSMS] file:"/ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-11-11 22:43:40.909915 [INFO] evse_security:E :: Requesting key/pair: V2G
2024-11-11 22:43:40.913828 [INFO] evse_security:E :: TPM Key: false
2024-11-11 22:43:40.924600 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-11-11 22:43:40.927839 [INFO] ocpp:OCPP201 :: OCPP client successfully connected to TLS websocket server
2024-11-11 22:43:40.940441 [INFO] ocpp:OCPP201 :: Received BootNotificationResponse: {
"currentTime": "2024-11-11T22:43:40.000Z",
"interval": 300,
"status": "Accepted"
}
with messageId: 351ad980-332b-4c63-9ba4-0a1a07250928
```
- citrine testing
```
Cloning EVerest from /Users/kshankar/Desktop/data/joet-everest/everest-demo into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/everest-demo
Cloning CitrineOS CSMS from https://github.com/citrineos/citrineos-core.git into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms and starting it
Cloning into 'citrineos-csms'...
remote: Enumerating objects: 16467, done.
remote: Counting objects: 100% (303/303), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 16467 (delta 139), reused 161 (delta 70), pack-reused 16164 (from 1)
Receiving objects: 100% (16467/16467), 5.06 MiB | 2.60 MiB/s, done.
Resolving deltas: 100% (10384/10384), done.
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt
Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms/Server/data/certificates
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms/Server /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt
```
Citrine failure on both main and this branch
```
127.9 npm verbose exit 0
127.9 npm info ok
131.7 npm verbose exit 1
131.7 npm verbose code 1
------
failed to solve: process "/bin/sh -c npm install --workspaces --verbose && npm run compile --workspaces --verbose" did not complete successfully: exit code: 1
Failed to start CitrineOS.
```
Signed-off-by: Shankari <[email protected]>
Before this change, the citrine and maeve parts of the demo were essentially copies of each other - they performed very similar tasks but due to subtle differences, the steps were long if-guarded blocks of code. This commit builds on 2a82485 and 821ac3c to identify the common tasks and pull them out into separate scripts. The tasks then represent a "CSMS access layer" or common interface. The details of the CSMS are hidden from the top-level demo script. Support for other CSMSes can be added by adding a new directory and implementing these scripts. Testing done: - With the build and run commands in the script commented out and exiting right after "start the CSMS" <details> <summary>Maeve</summary> ``` Cloning into 'maeve-csms'... remote: Enumerating objects: 3775, done. remote: Counting objects: 100% (1108/1108), done. remote: Compressing objects: 100% (362/362), done. remote: Total 3775 (delta 853), reused 886 (delta 742), pack-reused 2667 (from 1) Receiving objects: 100% (3775/3775), 1.30 MiB | 511.00 KiB/s, done. Resolving deltas: 100% (2700/2700), done. /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA/maeve-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA/maeve-csms/config/certificates Validating that the certificates are set up correctly config/certificates/csms.pem: OK Chain: depth=0: CN=host.docker.internal, O=EVerest, C=DE, DC=CPO (untrusted) depth=1: CN=CPOSubCA2, O=EVerest, C=DE, DC=V2G (untrusted) depth=2: CN=CPOSubCA1, O=EVerest, C=DE, DC=V2G (untrusted) depth=3: CN=V2GRootCA, O=EVerest, C=DE, DC=V2G Patching the CSMS to enable EVerest organization patching file docker-compose.yml Patching the CSMS to enable local mo root patching file 'config/manager/config.toml' Patching the CSMS to enable local mo root patching file 'manager/handlers/ocpp201/authorize.go' Build and run Waiting 5s for maeve services to finish starting... Adding a charger and RFID card to maeve While running subscript, DEMO_VERSION is v2.0.1-sp3 MaEVe CSMS started, adding charge station with Security Profile 3 (note: profiles in MaEVe start with 0 so SP-2 == OCPP SP-3) curl: (7) Failed to connect to localhost port 9410 after 0 ms: Couldn't connect to server Charge station added, adding user token curl: (7) Failed to connect to localhost port 9410 after 0 ms: Couldn't connect to server curl: (7) Failed to connect to localhost port 9410 after 0 ms: Couldn't connect to server /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA ``` </details> <details> <summary>CitrineOS</summary> ``` Cloning into 'citrineos-csms'... remote: Enumerating objects: 16467, done. remote: Counting objects: 100% (303/303), done. remote: Compressing objects: 100% (221/221), done. remote: Total 16467 (delta 139), reused 161 (delta 70), pack-reused 16164 (from 1) Receiving objects: 100% (16467/16467), 5.07 MiB | 898.00 KiB/s, done. Resolving deltas: 100% (10346/10346), done. /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.wBOfhaXf/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.wBOfhaXf Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.wBOfhaXf/citrineos-csms/Server/data/certificates Validating that the certificates are set up correctly Server/data/certificates/certChain.pem: OK Chain: depth=0: CN=host.docker.internal, O=EVerest, C=DE, DC=CPO (untrusted) depth=1: CN=CPOSubCA2, O=EVerest, C=DE, DC=V2G (untrusted) depth=2: CN=CPOSubCA1, O=EVerest, C=DE, DC=V2G (untrusted) depth=3: CN=V2GRootCA, O=EVerest, C=DE, DC=V2G No patches to apply Build and run Waiting 5s for citrineos services to finish starting... Adding a charger and RFID card to citrineos Received Token: Failed to retrieve access token. ``` </details> - After putting everything back in <details> <summary> MaEVe starts and charges</summary> ``` Build and run WARN[0000] The "UID" variable is not set. Defaulting to a blank string. WARN[0000] The "GID" variable is not set. Defaulting to a blank string. WARN[0000] The "UID" variable is not set. Defaulting to a blank string. WARN[0000] The "GID" variable is not set. Defaulting to a blank string. [+] Building 3.3s (35/35) FINISHED docker:desktop-linux => [manager internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 947B 0.0s => [gateway] resolve image config for docker-image://docker.io/docker/dockerfile:1.2 1.3s => [manager auth] docker/dockerfile:pull token for registry-1.docker.io 0.0s => CACHED [gateway] docker-image://docker.io/docker/dockerfile:1.2@sha256:e2a8561e419ab1ba6b2fe6cbdf49fd92b95912df1cf7d 0.0s => [manager internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [manager internal] load build definition from Dockerfile 0.0s => [gateway internal] load metadata for gcr.io/distroless/static:nonroot 0.7s ... [+] Running 5/5 ✔ Network maeve-csms Created 0.1s ✔ Container maeve-csms-firestore-1 Healthy 0.1s ✔ Container maeve-csms-mqtt-1 Healthy 0.1s ✔ Container maeve-csms-manager-1 Healthy 0.1s ✔ Container maeve-csms-gateway-1 Created 0.1s Waiting 5s for maeve services to finish starting... Adding a charger and RFID card to maeve While running subscript, DEMO_VERSION is v2.0.1-sp3 MaEVe CSMS started, adding charge station with Security Profile 3 (note: profiles in MaEVe start with 0 so SP-2 == OCPP SP-3) Charge station added, adding user token API calls to CSMS finished, Starting everest 2024-11-12 01:05:17.068938 [INFO] ocpp:OCPP201 :: Received BootNotificationResponse: { "currentTime": "2024-11-12T01:05:17.000Z", "interval": 300, "status": "Accepted" } with messageId: a9c9100f-ba3b-4000-bd5e-09ae2b3f4699 2024-11-12 01:05:17.501430 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry. 2024-11-12 01:05:22.543468 [INFO] evse_security:E :: Requesting key/pair: V2G 2024-11-12 01:05:22.547168 [INFO] evse_security:E :: TPM Key: false ``` </details> <details> <summary>Citrine fails like on master</summary> ``` No patches to apply Build and run /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5/citrineos-csms/Server /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5 WARN[0000] /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5/citrineos-csms/Server/docker-compose.yml: `version` is obsolete [+] Building 8.5s (22/26) docker:desktop-linux => [directus internal] load build definition from directus.Dockerfile 0.0s => => transferring dockerfile: 887B 0.0s => [directus internal] load metadata for docker.io/directus/directus:10.10.5 1.0s => [directus auth] directus/directus:pull token for registry-1.docker.io 0.0s => [directus internal] load .dockerignore 0.0s => => transferring context: 314B 0.0s ... => [citrine build 4/5] RUN npm install --workspaces --verbose && npm run compile --workspaces --verbose 93.2s => => # npm verbose logfile logs-max:10 dir:/root/.npm/_logs/2024-11-12T01_10_43_406Z- => => # npm verbose logfile /root/.npm/_logs/2024-11-12T01_10_43_406Z-debug-0.log => => # > @citrineos/[email protected] clean => => # > rm -rf dist/* tsconfig.tsbuildinfo => => # npm verbose exit 0 => => # npm info ok 116.8 npm verbose exit 0 116.8 npm info ok 121.5 npm verbose exit 1 121.5 npm verbose code 1 ------ failed to solve: process "/bin/sh -c npm install --workspaces --verbose && npm run compile --workspaces --verbose" did not complete successfully: exit code: 1 Failed to start citrineos ``` </details> Signed-off-by: Shankari <[email protected]>
- Move the validation to the lower level since the directory structure is different - Add code to copy the real root over to citrine - Add validation to citrine As an aside, I wonder if this weird configuration (the actual root CA isn't there?!) is the reason that the self-signed certs are not working with Citrine. Need to investigate once we roll forward. Testing done: as part of 86b1ea8 Signed-off-by: Shankari <[email protected]>
Several of the options in the demo do not actually work For example: - Citrine fails to build (even on main) - SP1 (and SP2) won't work with TLS EVerest#78 (comment) Fixes: - Error out before Citrine build with a message indicating that it is not supported - Patch the config for SP1 and SP2 to disable TLS Testing done: - Citrine ``` Cloning citrineos CSMS from https://github.com/citrineos/citrineos-core.git into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd/citrineos-csms and starting it Cloning into 'citrineos-csms'... remote: Enumerating objects: 16467, done. remote: Counting objects: 100% (303/303), done. remote: Compressing objects: 100% (221/221), done. remote: Total 16467 (delta 139), reused 161 (delta 70), pack-reused 16164 (from 1) Receiving objects: 100% (16467/16467), 5.07 MiB | 969.00 KiB/s, done. Resolving deltas: 100% (10346/10346), done. /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd/citrineos-csms/Server/data/certificates Validating that the certificates are set up correctly Server/data/certificates/certChain.pem: OK Chain: depth=0: CN=host.docker.internal, O=EVerest, C=DE, DC=CPO (untrusted) depth=1: CN=CPOSubCA2, O=EVerest, C=DE, DC=V2G (untrusted) depth=2: CN=CPOSubCA1, O=EVerest, C=DE, DC=V2G (untrusted) depth=3: CN=V2GRootCA, O=EVerest, C=DE, DC=V2G No patches to apply Build and run CitrineOS does not currently build due to issues with npm dependencies. It is disabled until we roll forward. Apologies for the inconvenience! ``` - Maeve ``` Successfully copied 84.5kB to everest-ac-demo-manager-1:/ext/source/build/dist/share/everest/modules/OCPP201/device_model_storage.db Successfully copied 3.07kB to everest-ac-demo-manager-1:/tmp/ /ext/source /workspace patching file config/config-sil-ocpp201-pnc.yaml ``` And then charging with EIM was successful Signed-off-by: Shankari <[email protected]>
Fix issues flagged by codacy
These were primarily
- no default shell specified for all the newly added subscripts
- added bash
- some environment variables were not quoted
- quoted them
Signed-off-by: Shankari <[email protected]>
- `config-docker.json`: is no longer needed since we don't support 1.6j (EVerest#80) - `config.json` is no longer needed, since it is removed and replaced by the `component_config` directory (EVerest/libocpp#740) - `device_model_storage_maeve_sp1.db` is now created by the manager at startup based on the `component_config` directory This should now work for the basic (non-ISO/non-OCPP use cases) Signed-off-by: Shankari <[email protected]>
Since the architecture name has now changed to `amd64` instead of `x64_64`. This partially reverts EVerest@b0dfa4d Additional details at: EVerest#78 (comment) Testing done: - Before this change `docker compose -f docker-compose.build.yml build` errors out - After this change `docker compose -f docker-compose.build.yml build` does not error out at the same step Signed-off-by: Shankari <[email protected]>
Testing done: - Basic AC demo works EVerest#78 (comment) Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
from
e1c31a0
to
bdc5712
Compare
- The alpine build-kit is now deprecated, use the recommended one EVerest#78 (comment) ``` --------------------------------------------- WARNING This docker image is depreacted. Please use the debian based build-kit 'ghcr.io/everest/everest-ci/build-kit-base' instead. Fore more information see EVerest/everest-ci#22 --------------------------------------------- ``` - Now that there is a standard install script, instead of only test-and-install, so that we can roll forward EVerest#78 (comment) Testing done: - Built successfully using a container - Ran the `everest-demo/docker-compose.yml` and `everest-demo/docker-compose.iso15118-dc.yml` scripts. Both worked. - Testing `everest-demo/docker-compose.ocpp201.yml` fails because go is running into SSL issues on my work laptop. Need to figure out how to resolve that EVerest#78 (comment) Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
2 times, most recently
from
198cc92
to
81a5c2b
Compare
After the changes to roll forward to the recommended image, fa2fc02 the build directory is in `/ext/build` and not `/ext/source/build`. In this commit, we change all the entrypoint scripts to point to the new location. This is a requirement for the demos to work after fa2fc02 Signed-off-by: Shankari <[email protected]>
* 👷Initial workflow to checkout and build the CSMS This can definitely be polished, but it works now so can unblock EVerest#78 Changes: - Add a new workflow - Configure it with a hardcoded set of images to build for maeve - Apply compile-time patches - Build and push, similar to the original `cicd` workflow ----- full list of changes ----- * Build on pull requests to upgrade branches as well * Handle the two directories correctly Need to explicitly `cd` into `everest-demo` And apply patches from there * Fix repo format * Fix checked out directory format * Again change directory properly before building * Now that build works, re-tag and push * Fix invalid workflow format * Really fix the format * read the env properly (from within the demo) * Login before pushing * Switch to the build-push-action so that push to packages works EVerest#78 (comment) * Actually push the values * Give more permissions to the token To be consistent with https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions * Change the permission to "admin" So that we can really really push?! * Temporarily switch to US-JOET so we can verify that it works * Split the maeve patches into compile time and runtime And apply only the compile time patch while building the image Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
from
b315eac
to
5bd8fc7
Compare
This is a follow-on to 20068a2 now that we are in the right repo We also restore the `pull_request` check and set the push to false since we don't want to push on every change to a PR, only when it has been approved and merged Signed-off-by: Shankari <[email protected]>
Since it is not working anyway due to lack of disk space EVerest#78 (comment) Signed-off-by: Shankari <[email protected]>
Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
from
9288b9b
to
46f9890
Compare
Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
from
46f9890
to
aa971b1
Compare
Signed-off-by: K. Shankari <[email protected]>
Summary of changes:
- Switch to using pre-built images
- This is copying over the docker-compose and modifying
it to use images; we can and should do better
- Apply runtime patches to the CSMS
- After changing the paths in the script to run them from the current location
- Apply change paths throughout
- Remove the second EVSE and connector so they are not created in the device model
- Question: Is `/ext/dist/share/everest/modules/OCPP201/component_config/` now the source of truth? Will it always rewrite the DB? Is the DB then just for convenient access?
- Since we are now on debian, install patch using apt-get
- The new version is after the external payment was removed externally, so add it back using patches
- Since we can no longer copy over a DB with the CSMS value (since it will be overridden), we use `sed` to change it in the component_config
- With the new build, the build is in `/ext/build` and the distribution is in `/ext/dist` - changed paths in `demo` and the manager patches to match
- change to the new module names for the new release
- although we added back a patch to support the payment method, we are still using `ac` and `dc` in the JsEvManager, not `AC_three_phase_core`. Change the nodered flow to match.
- change the CSMS build action to prepend the csms name to the image name so that we don't create CSMS image called `manager` which overrides the everest manager
Testing done:
- `bash demo-iso15118-2-ocpp-201.sh -r $(pwd) -1` works without any additional changes
NOTE that this still needs the manager to be pushed since it is too large to be built by the CI dec0ca2
And there is still a fair amount of immediate cleanup to be
done as well. But this was getting long and complex, and I
wanted to check it in before it got too unwieldy.
Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
from
dbc2f2d
to
b613ba6
Compare
Switch the maeve running `docker-compose` to the main ever est demo repo, and to the new tag names (consistent with b613b a6c49f00339a090abe033aecfb45101dbad) Testing done: - Retagged my local copies of the images ``` sdesk-35737s:everest-demo kshankar$ docker tag ghcr.io/us- joet/everest-demo/gateway:0.0.16 ghcr.io/everest/everest-demo/ maeve-gateway:0.0.17-localbuild sdesk-35737s:everest-demo kshankar$ docker tag ghcr.io/us- joet/everest-demo/gateway:0.0.16 ghcr.io/everest/everest-demo/ maeve-gateway:0.0.17-localbuild ``` - ran the demo script - images were found and used properly Signed-off-by: Shankari <[email protected]>
Now that the device model DB is overridden on startup, we cannot configure the CSMS URL by copying over the database any more (b613ba6, EVerest#78 (comment)). Instead we have to edit the `InternalCtrlr.json` file before the server starts up so that it is configured properly in the device model DB that is created at startup. We do this by using `sed` to replace `localhost` with the correct CSMS URL. But the CSMS URL is different based on the the profile (SP1, SP2, SP3) and the CSMS (Maeve vs CitrineOS). So we make the following changes: - remove all the DB override files since they are not relevant any more - instead, define the SP and CSMS specific enviroment variables in the CSMS-specific apply-patches file - we may want to change this to a separate file later if there are other environment variables we want to specify - specifying this in CSMS-specific files means that we can easily support other CSMSes without modifying the demo file - change the demo script to run separate sed commands that modify the `InternalCtrlr.json` with the correct URL for the service profile and CSMS Signed-off-by: Shankari <[email protected]>
|
This is is pretty good shape now, so going to pivot to the external service integration for a bit before coming back and dealing with other cleanup issues. |
This is not strictly required, since this is a sub script that we source in the main script. But the static code analysis tool complains, so let's fix it. Signed-off-by: Shankari <[email protected]>
shankari
force-pushed
the
upgrade_to_sept_2024_release
branch
from
d8ceb39
to
9eaccad
Compare
This is a partial fix for EVerest#78 There is still much cleanup to be done, but I want to pivot to the MIDAS integration right now Signed-off-by: Shankari <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should now work for the basic (non-ISO/non-OCPP use cases)