| 18 May 2025 |
 geekodour | i am quite confused about them keeping the github actions totally community supported | 17:33:42 |
 commiterate | Most AWS teams are fairly small (maybe 5-10 people) and there's generally no distinction between engineering, QA, and devops/SRE. It's just "software development engineer" (SDE) which handles all 3 functions which they can get away with because the internal tooling is, IMO, very well done.
Each organization is basically a big ensemble of a bunch of small teams (e.g. control plane team, data plane team, frontend team for AWS console stuff) as the leaves which roll up into a reporting tree.
That means most teams are actually pretty lean and don't have much extra capacity for other stuff. More important areas like the AWS CLI + SDKs or AWS CDK will have additional dedicated resources beyond SDEs to handle a lot of customer interactions. | 19:30:44 |
| commiterate | I don't know if the IMDS team themselves own EC2 metadata mock. If it is, they're probably dealing with a lot of internal IMDS development work.
If not, it's probably something more owned by solutions architects (e.g. most stuff under the aws-labs GitHub org like coldsnap) who are also working on many other things.
| 19:32:34 |
| commiterate | * I don't know if the IMDS team themselves own EC2 metadata mock. If it is, they're probably dealing with a lot of internal IMDS development work.
If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.
| 19:33:07 |
| commiterate | * Most AWS teams are fairly small (maybe 5-10 people) and there's generally no distinction between engineering, QA, and devops/SRE. It's just "software development engineers" (SDEs) who handles all 3 functions which they can get away with because the internal tooling is, IMO, very well done and generally pushes for better designs since you have to consider both the operational burden and testing aspects in designs.
Each organization is basically a big ensemble of a bunch of small teams (e.g. control plane team, data plane team, frontend team for AWS console stuff) as the leaves which roll up into a reporting tree.
That means most teams are actually pretty lean and don't have much extra capacity for other stuff. More important areas like the AWS CLI + SDKs or AWS CDK will have additional dedicated resources beyond SDEs to handle a lot of customer interactions. | 19:34:26 |
| commiterate | * Most AWS teams are fairly small (maybe 5-10 people) and there's generally no distinction between engineering, QA, and devops/SRE. It's just "software development engineers" (SDEs) who handles all 3 functions which they can get away with because the internal tooling is, IMO, very well done and generally pushes for better designs since you have to consider both the operational burden and testing aspects in designs.
Each organization is basically a big ensemble of a bunch of small teams (e.g. control plane team, data plane team, frontend team for AWS console stuff) as the leaves which roll up into a reporting tree.
That means most teams are actually pretty lean and don't have much extra capacity for other stuff. More important areas like the AWS CLI + SDKs or AWS CDK will have additional dedicated resources beyond SDEs to handle a lot of customer interactions (e.g. support engineers, solutions architects). | 19:35:13 |
| commiterate | Regardless, the various waves of layoffs and reshuffling of people to work on "AI" stuff has put a lot more strain on things | 19:36:30 |
| commiterate | * I don't know if the IMDS team themselves own EC2 metadata mock. If they do, they're probably dealing with a lot of internal IMDS development work.
If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.
| 19:38:10 |
| commiterate | * I don't know if the IMDS team themselves own EC2 metadata mock. If they do, they're probably dealing with a lot of internal IMDS development work (it's an eternal cycle of dealing with new EC2 instance type bringups).
If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.
| 19:38:42 |
| commiterate | * I don't know if the IMDS team themselves own EC2 metadata mock. If they do, they're probably dealing with a lot of internal IMDS development work (it's an eternal cycle of dealing with new EC2 instance type bring ups and fire fighting for most EC2 Nitro teams).
If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.
| 19:38:57 |
| commiterate | * Most AWS teams are fairly small (maybe 5-10 people) and there's generally no distinction between engineering, QA, and devops/SRE. It's just "software development engineers" (SDEs) who handles all 3 functions which they can get away with because the internal tooling is, IMO, very well done and generally pushes for better designs since you have to consider both the operational burden and testing aspects in designs.
Each organization is basically a big ensemble of a bunch of small teams (e.g. control plane team, data plane team, frontend team for AWS console stuff) as the leaves which roll up into a reporting tree.
That means most teams are actually pretty lean and don't have much extra capacity for other stuff. More important areas like the AWS CLI + SDKs or AWS CDK will have additional dedicated resources beyond SDEs to handle a lot of customer interactions (e.g. support engineers, solutions architects).
As a result, they rely heavily on community contributions with AWS SDEs mostly acting as reviewers. | 19:40:01 |
| commiterate | AWS also doesn't really use these kind of local mocks much internally. Integration + E2E test suites on real infrastructure is always used instead. | 19:46:54 |
| 19 May 2025 |
 Arian | AKA I should come up with a fix myself :D | 08:57:12 |
| commiterate | basically. As usual per open source, if you want something done you have to do it yourself | 16:44:10 |
| commiterate | * basically. As usual in open source, if you want something done you have to do it yourself | 17:07:47 |
| commiterate | * Most AWS teams are fairly small (maybe 5-10 people) and there's generally no distinction between engineering, QA, and devops/SRE. It's just "software development engineers" (SDEs) who handle all 3 functions which they can get away with because the internal tooling is, IMO, very well done and generally pushes for better designs since you have to consider both the operational burden and testing aspects in designs.
Each organization is basically a big ensemble of a bunch of small teams (e.g. control plane team, data plane team, frontend team for AWS console stuff) as the leaves which roll up into a reporting tree.
That means most teams are actually pretty lean and don't have much extra capacity for other stuff. More important areas like the AWS CLI + SDKs or AWS CDK will have additional dedicated resources beyond SDEs to handle a lot of customer interactions (e.g. support engineers, solutions architects).
As a result, they rely heavily on community contributions with AWS SDEs mostly acting as reviewers. | 17:18:37 |
| 24 May 2025 |
|  fromtheeast710 joined the room. | 05:10:18 |
| 26 May 2025 |
|  @xengi42:matrix.org joined the room. | 08:13:00 |
| 27 May 2025 |
|  matrixrooms.info mod bot (does NOT read/send messages and/or invites; used for checking reported rooms) joined the room. | 15:50:06 |
| 1 Jun 2025 |
|  Sean Thawe joined the room. | 23:48:47 |
| 7 Jun 2025 |
| matrixrooms.info mod bot (does NOT read/send messages and/or invites; used for checking reported rooms) left the room. | 22:15:14 |
| matrixrooms.info mod bot (does NOT read/send messages and/or invites; used for checking reported rooms) joined the room. | 23:18:55 |
| 9 Jun 2025 |
|  SigmaSquadron joined the room. | 13:06:37 |
| 10 Jun 2025 |
|  Niclas Overby Ⓝ joined the room. | 13:44:00 |
|  @niclasoverby:beeper.com left the room. | 14:50:09 |
| Niclas Overby Ⓝ changed their display name from Niclas Overby to Niclas Overby Ⓝ. | 16:32:33 |
| 19 Jun 2025 |
| @xengi42:matrix.org left the room. | 16:25:45 |
| 21 Jun 2025 |
|  @sielicki:matrix.org left the room. | 22:20:22 |
| 26 Jun 2025 |
| commiterate | amazon-ec2-ssh-utils should be fully functional now and I reached out to AWS EIC again to transfer ownership.
If you want to use it, I'd fork it since it's still being force-pushed occasionally. systems/nixosModules/test.nix has an example of how to set it up with the OpenSSH daemon (though it should be used without --source ec2-key-pairs to prevent man-in-the-middle attacks).
| 05:09:37 |
| commiterate | * amazon-ec2-ssh-utils should be fully functional now. I've reached out to AWS EIC again to transfer ownership.
If you want to use it, I'd fork it since it's still being force-pushed occasionally. systems/nixosModules/test.nix has an example of how to set it up with the OpenSSH daemon (though it should be used without --source ec2-key-pairs to prevent man-in-the-middle attacks).
| 05:20:32 |
