Skip to content
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 129 commits into from
May 2, 2024
Merged

Merge dev to master #435

merged 129 commits into from
May 2, 2024

Conversation

JanneKiiskila
Copy link
Contributor

Merge whole dev to master.

Mo Chen and others added 30 commits November 16, 2021 13:14
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.
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.
@JanneKiiskila JanneKiiskila self-assigned this May 2, 2024
@JanneKiiskila JanneKiiskila merged commit c9de6d1 into master May 2, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants