Add new skills for Kubernetes management, package updates, and EC2 operations#2
Add new skills for Kubernetes management, package updates, and EC2 operations#2ytsssun wants to merge 9 commits intocbgbt:developfrom
Conversation
7f83f57 to
ed83b99
Compare
cbgbt
left a comment
There was a problem hiding this comment.
This is great! I think these inherently add a lot of value. I have a few comments that I would like your thoughts on.
| @@ -0,0 +1,182 @@ | |||
| --- | |||
| name: add-kubernetes-variant | |||
There was a problem hiding this comment.
Does this need to create a settings plugin? Or do we just use the same one for new k8s variants?
There was a problem hiding this comment.
We might - depending on if there are any breaking change in kubelet config or if there are new settings we want to opt-in upon the launch of the variant.
There was a problem hiding this comment.
I tend to think the settings plugin change is more case by case and less "workflow-ish" if that makes sense?
| @@ -0,0 +1,167 @@ | |||
| --- | |||
| name: analyze-kubernetes-release | |||
There was a problem hiding this comment.
I'm curious about the output of this, and wonder how it makes these go/no-go decisions. I might suggest finding a way to get this to lean on fact-find or research-document so that our outputs are based on citable facts. I worry about the risk of hallucination.
There was a problem hiding this comment.
Good call. This is where I wonder if we should just use the research-document skill or create a new skill.
If we want to keep this, I think we can add extra phase to explicitly do fact check. Thoughts?
| On first use, collect infrastructure details and save to `launch-config.toml`: | ||
|
|
||
| ```bash | ||
| cat > skills/launch-bottlerocket-ec2/launch-config.toml << 'EOF' |
There was a problem hiding this comment.
Might be cool to get this to use CDK one day.
There was a problem hiding this comment.
#6 I created an issue for this - but let me know if you think otherwise.
| #### EKS Mode | ||
|
|
There was a problem hiding this comment.
This is fine for now, but we probably want some forest-wide sense of cluster management. In other words, there should be a brdev tool for cluster management and an easy way to see which clusters exist and their status (abstracted away in brdev) Then rather than needing to get the CAs, the tooling can manage it.
Can you cut an issue for this?
There was a problem hiding this comment.
Cut a issue here.
| ```bash | ||
| cd ../.. # Back to core-kit root | ||
|
|
||
| # Build both packages |
There was a problem hiding this comment.
Let's make this a skill reference to keep things consistent.
| **Access host rootfs via sheltie (full host access):** | ||
| ```bash | ||
| CMD_ID=$(aws ssm send-command \ | ||
| --instance-ids INSTANCE_ID \ | ||
| --document-name "AWS-RunShellScript" \ | ||
| --parameters '{"commands":["apiclient exec admin sheltie -- containerd --version"]}' \ | ||
| --region REGION \ | ||
| --query 'Command.CommandId' \ | ||
| --output text) && \ | ||
| sleep 4 && \ | ||
| aws ssm get-command-invocation \ | ||
| --command-id $CMD_ID \ | ||
| --instance-id INSTANCE_ID \ | ||
| --region REGION \ | ||
| --query 'StandardOutputContent' \ | ||
| --output text | ||
| ``` |
There was a problem hiding this comment.
I've been doing some reading about skills, and one suggestion that I've been seeing that I think makes sense is that we can instead package commands like this as scripts that get shipped alongside the skill. Then in the SKILL.md we simply suggest that the agent call that script with the right arguments.
So I think here we'd have brief descriptions like:
**Simple command, control container context**
./scripts/control-container-command.sh <INSTANCE_ID> <command/script>I haven't been doing a great job at that in the existing skills, but this would further reduce token utilization. It's basically an easy way to package additional tools that don't end up in the context window unless the skill is loaded.
There was a problem hiding this comment.
Updated - I 100% agree with this. Having scripts are manifest would make the model behavior more predictable.
skills/ssm-executor/SKILL.md
Outdated
| | Context | Access | How to Reach | | ||
| |---------|--------|-------------| | ||
| | Control container | SSM agent, apiclient | Direct SSM command | | ||
| | Admin container | AL2023 userspace, /.bottlerocket/rootfs | `apiclient exec admin` | | ||
| | Host namespace | Full rootfs, all binaries | `apiclient exec admin sheltie --` | |
There was a problem hiding this comment.
I think this implies we need something under $FOREST/docs to talk about these contexts. It's not clear to me if all agents working in the forest should just know it, or if we should make it dynamically discoverable. BUT this is very useful information that should be hoisted and shared.
75e7a37 to
138d876
Compare
…aking changes step Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Analyze Kubernetes release KEPs and CHANGELOG for SIG Node/Network changes affecting Bottlerocket with go/no-go recommendation. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Promote pre-release Kubernetes packages to GA by updating source URLs and hashes to official EKS-D release artifacts. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Add a new Kubernetes variant to the bottlerocket repository. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Update a kit package to the latest upstream version with checksum verification and build testing. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Launch Bottlerocket EC2 instances in standalone, ECS, or EKS modes. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Execute commands on Bottlerocket K8s nodes via a privileged pod with host namespace access. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Execute commands on any Bottlerocket EC2 instance via SSM Session Manager. Works with all variants (ECS, K8s, standalone) without requiring Kubernetes access. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
Add Kubernetes Version Management, Package Maintenance, and Build & Test skills to the index with improved organization by category. Signed-off-by: Yutong Sun <yutongsu@amazon.com>
138d876 to
dbe5344
Compare
|
Breaking down the PR into smaller PRs:
|
This PR adds 8 new skills and updates the README index with improved organization.
New Skills
README Updates
Maintenance, Build & Test, Feature Development, Settings Development