-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge dev to master #435
Merged
Merged
Merge dev to master #435
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
Socket proxy is part of the container signing feature. It will proxy the docker unix socket and eventually filter messages.
fix bouncer version file the snapcraft cmake plugin doesn't copy the .git directory from the download folder into the build directory, so git commands may not work in the build phase. the command does seem to work in some environments because git "falls up" the directory structure looking for a containing .git folder, usually finding the .git folder of snap-pelion-edge, which obviously contains the wrong version for the part.
Docker sock was moved to /run/snap.snap-pelion-edge/var/run/. We need to update this script to use the same.
Use bouncer proxy socket path instead of docker socket when image signing is enabled.
Signed-off-by: Cristian Prundeanu <[email protected]>
bouncer needs to run as a service so that it can handle the docker-proxy.socket. it also needs the network-bind plug so that it can open a listening socket.
This fixes fix yq failure to read the maestro yaml config file on startup. This commit fixes these log errors: maestro[]: Error: unknown command "r" for "yq" maestro[]: Run 'yq --help' for usage. maestro[]: Error: unknown command "r" for "yq" maestro[]: Run 'yq --help' for usage. The yq version was not version-locked and yq version 4.0 is a major breaking change from previous versions: https://github.com/mikefarah/yq/releases/tag/4.0.0-alpha1
Add multiple connections support.
The version is the same, we just reference the tag name instead of the SHA.
The meta build is at 1.15.8, but 1.15.13 has a few extra bug fixes and security fixes. https://golang.org/doc/devel/release#go1.15.minor
The patches had to be refreshed as well. The main changes are that 1) the mbed-cloud-client library was turned into a git submodule which required some adjustment, and 2) the network proxy functionality in mbed-cloud-client had to be totally rewritten. The mbed-cloud-client network proxy patch is based on this PR: https://github.com/PelionIoT/mbed-cloud-client-internal/pull/3262/
According to the Pelion Edge 2.4 changelog, the userdata/mbed folder should have permissions restricted to 700 and owner=root.
the tagged version of devicedb 1.10.0 didn't print the correct version on the command line. this is a bug in devicedb where the old version was hardcoded and wasn't bumped to 1.10.0 during the release.
edge-core is now compiled in 3 modes: * factory mode * developer mode * byoc mode https://github.com/PelionIoT/mbed-edge#configuring-edge-build TODO: * add code to the launch script to check which mode to start
Now that we have multiple versions of edge-core installed in the snap, we need to provide the user with a config option to choose which one to start. The new snap configuration variable is "edge-core.provision-mode" and valid values are "factory", "developer", "byoc", and "auto". The default is "auto". For factory mode, the expectation is that the mcc_config folder exists. For developer mode, the expectation is that the developer mode binary was built with developer credentials and installed into the snap. For byoc mode, the expectation is that the user has provided a CBOR file at /var/snap/pelion-edge/common/device.cbor. See https://github.com/PelionIoT/mbed-edge/tree/master/edge-tool#readme for instructions on how to create a CBOR. The provision-mode is only useful if the device hasn't already been provisioned, i.e., if the mcc_config folder doesn't exist, because if the device is provisioned we just boot in factory mode regardless of the snap config option. To switch modes if the device is already provisioned: 1. stop the pelion-edge snap services 2. backup the existing mcc_config folder if desired 3. delete the existing mcc_config folder 4. set the snap config option edge-core.provision-mode 5. provision credentials as in the expectations above 6. start the pelion-edge snap services
the 'grade' flag in snapcraft.yaml is used to indicate whether a snap is ready for release, so we can use that flag to indicate when to include the byoc and developer variants of edge-core under that assertion that we shouldn't include developer tools in production builds.
This fixes a build breakage issue with the python snapcraft plugin used for building python projects. The python package manager pip dropped support for python2 and for python3.5 in pip version 21 and the plugin was patched to pin the version of pip. canonical/snapcraft#3428
edge-tool can convert Pelion Cloud developer credentials (mbed_cloud_dev_credentials.c and update_default_resources.c) into a CBOR file that is used for registration by edge-core in BYOC mode. https://github.com/PelionIoT/mbed-edge/tree/master/edge-tool
edge-tool.py v0.16.1 requires a json config file and unfortunately it must be named .mbed_cloud_config.json which means it's a hidden file and the home plugin doesn't allow access to the user's hidden files.
when starting edge-core in factory mode, if the device is not provisioned at the factory, then edge-core will still create the mcc_config/WORKING/ folder, but its contents will be empty. this is fixable by performing the factory provisioning step with FCCE, but for a grade:devel snap, this breaks auto mode.
The edge-core launch code should be driven first by the user setting, and only then fallback to auto detection.
Snapcraft supports Python 3.5 in the `core` base snap. The mbed-edge edge-tool recently updated one of its python dependencies, cryptography, to version 3.3.2 which doesn't support Python 3.5 and only supports Python 3.6+
the python package setup.py for edge-tool didn't install the edge_tool.py main script which meant that edge-tool wasn't runnable in the snap.
install the edge_tool.py utility under the wigwag folder so that it is bundled in a similar directory structure as seen in the meta-mbed-edge yocto recipe.
This reverts commit ffea43d. Downgrade kubelet back to the version before network policies until we add missing dependency CoreDNS which replaces CNI plugins.
This pulls in the echo $NORM fix to edge-info. We do want to keep the versions in sync, though.
We have updated the edge-testnet command, let's pull it in.
Use the github action checkout while at it.
To perhaps a bit better highlight why it's failing. For some reason it can't execute: ``` 2024-02-23T12:26:52.6318145Z Building edge-core-tool 2024-02-23T12:26:53.7942185Z + '[' devel = devel ']' 2024-02-23T12:26:53.7948577Z + snapcraftctl build 2024-02-23T12:26:54.7042119Z + python3 -m venv /build/parts/edge-core-tool/install 2024-02-23T12:26:55.3181545Z Error: Command '['/build/parts/edge-core-tool/install/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. 2024-02-23T12:26:55.3354171Z Failed to build 'edge-core-tool'. 2024-02-23T12:26:55.3358277Z ```
This one works at least for me, locally.
This should get us 7.5.4 (or another minor version) instead of going to 8.x which seems to break things.
To keep up with GitHub node16 deprecation.
As we had two jobs called "Build" that made it rather confusing.
Separate snap-builders wanted/needed.
We do not use core22, so no point in downloading it and copying it over.
Do issue a warning in the logs.
I hope at least.
We get lots of deprecation notes now due to node16 being deprecated in GitHub.
Seems if we have ["self-hosted", "snap"] it can choose also just self-hosted (which does not look right to me). We had just a job land at the NUC, which is definitely NOT capable to build the snap in any sensible time.
The client runners do not have snap, so that they could install yq via that way.
Seems we can exceed it easily, if mercury is too loaded.
to avoid waits for confirmation from the user (which isn't coming).
This fixes the ping problem we're having with Canonical now.
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.
Merge whole dev to master.