See the entire conversation

One of the interesting things about AWS Firecracker is that it is (one of?) the first OSS projects *originated* by AWS. It will be interesting to see how outside contributions and community are curated. Some comments after a 2 minute look at the repo/docs:
55 replies and sub-replies as of Nov 27 2018

First, there is a Code of Conduct (github.com/firecracker-mi…). It is very corporate though where violations are reported to an amazon alias. If a real community forms it'll be interesting to see if this shifts to be a community driven thing.
firecracker-microvm/firecracker
Secure and fast microVMs for serverless computing. - firecracker-microvm/firecracker
github.com
One thing missing from firecracker is either the DCO or a CLA. This is very surprising! One of these is typical when accepting any outside contributions. I expect to see this fixed ASAP once external PRs start coming in. Will be interesting to see what they pick.
(FWIW, I'm not a fan of CLAs that are owned by commercial companies. It gives the company free reign to re-license in the future and dual license. The chrome VMM base will prevent that in this case and isnt' as big an issue with Apache 2.0. IANAL tho.)
Summary of Firecracker from OSS community PoV: looks like a great start but some missing pieces. Clearly not going to be community driven (like k8s, Apache, OpenStack) but rather vendor driven. Not "throw it over the wall" OSS though (chrome, android). Looking forward to more!
Oh! One thing I forgot -- there is a pre-submit check on PRs that leads to an AWS login screen. Looks like you have to be an Amazon employee (or have an AWS login?) to see the presubmit checks?
Kubernetes had (and still has but is working on it!) the issue where the OSS block and tackle was still overly tied to Google internal systems. It has been super hard to unwind that over time. Hopefully they'll run all the build/release/test infra for this in the open too.
I am sure @arungupta will work with the team to sort out these issues out, as you say it takes time. Personally I am over the moon some of this tech can see the light of day outside amazon so people inside can be a part of the greater community.
Yep, feedback accepted, will work with the team to sort them out! // @anliguori
It's not using internal Amazon systems, it's using publicly available AWS services like CodeBuild. It's not the intention to run this behind a curtain, and all of the build infrastructure is set up in a way that is could be run through other services like Travis CI if needed.
Sorry for not being clear. But, regardless, you have to be an Amazon employee to see that, yes? We had the same problem with k8s where some of the project block and tackle required you to be a Googler (even though it used GCP).
A lot of effort in k8s went into building infrastructure from the ground up that scales, is maintained by the community and is as open as possible. Check prow: github.com/kubernetes/tes… and prow.k8s.io
kubernetes/test-infra
Test infrastructure for the Kubernetes project. Contribute to kubernetes/test-infra development by creating an account on GitHub.
github.com
Obviously something like Prow is *way* overkill in this case. But the fact that pre-submit check links send make to a login page sends the wrong signal from a community point of view.
Well, I'm an Amazon employee and I can't see the log that was generated. The link goes to the CloudWatch log for the build, but it doesn't give me a clue about what AWS account it lives in. An easy thing to do is just push the logs to a public S3 bucket.
And so it starts wrt building your own CI/CD system that is OSS friendly. FWIW, pushing logs to GCS was one of the early steps for k8s :) Will be interesting to see how this evolves!
We will fix that. There are some technical challenges as most popular open source build platforms don't do nested yet. Yeah, I know nested is useful here :-)
The funny thing is that I'll probably use desktop VMware or GCP to play with it because I don't want to pay $5/hour to play with it on AWS. I really do think that nested will become a critical feature here. Not everyone will run on metal.
Definitely not "open source in license only." The people who are named maintainers today are payed by Amazon. The project will be shaped by those people and Amazon's peculiar ways. So, rather than community driven or vendor driven, I hope this will be a customer driven project.
"Customer driven" in this case sounds like marketing BS. At the end of the day who controls the roadmap? Who decides where the project goes? Who defines what he customer is? That's all amazon (for now). And that's okay!
The customer thing is my own philosophy on how I would like the project to be run, but I can see how it could read like marketing. It means working backwards from customers, and applying some of the mechanisms we use internally at Amazon to an OSS project.
Don't get me wrong -- having tenants and an idea of what and who the project is for is critical. And that is being driven by Amazon (for now). Giving that up to the community is super hard. It requires deep thinking about governance and who has standing to influence project.
And you can't do that stuff too early. You need a core community to form before you can hand things off to it. But you can signal early on that you are serious about building something that goes beyond AWS.
A good place to start might be examples/docs on how to launch/use firecracker on other clouds. That starts to establish the idea that the technology isn't tied to AWS. That can be super tricky inside of a company though.
There will be other more subtle signals. If you set up a community call will you force everyone to install Chime? Because the only people that use Chime are Amazon employees and it is super buggy last I tried. K8s started with hangouts but then moved to zoom.
There are POTS dial-in numbers for Chime... And full VTC is working very nicely from Chrome running on my Ubuntu laptop, nothing extra to install. But I hear your feedback, and you bring up a number of points that we have some deep thinking and discussions about already.
If you are using a POTS dial-in number you are talking to lawyers. ;)
If you needed more encouragement, GCE supports nested virt, so firecracker should work all the way down to an f1.micro (although I wouldn't necessarily want to run it there :)
I know! I'm going to look to get it working. But the instructions look like you have to spin around 3 times counter clockwise and say "nested vert" while facing north. It should be easier or on by default. It is on Azure I think.
Yeah -- it is just the "create an image" bit that is strange. Modeling the nested virt capability as a license string seems like a hack. Is it because plumbing a new option through the API/console/gcloud is just pure pain?
I hope that everyone we interact with will influence the project in some way. For high level mechanisms like tenets to set the direction, we welcome feedback and suggestions from anyone.
But that is my point. "Feedback and suggestions" isn't community driven. It is still Amazon driven. But also that is ok and appropriate at this stage. The question, IMO, is signaling when/how/if that might change and those can be driven by non-AWS folks.
Concretely, Kubernetes, for example, has a steering committee with limits on company representation. That sets the tone/charter for the rest of the project. We delegate power to other groups run by the community. No one (google, red hat, etc) can act unilaterally.
You can't do that from day 1. But you can start to give more power to external folks. Your first external maintainer is probably the next big step.
The last bullet of github.com/firecracker-mi… is intended to be a lightweight DCO. If anything more is needed, I expect we would simply use DCO.
firecracker-microvm/firecracker
Secure and fast microVMs for serverless computing. - firecracker-microvm/firecracker
github.com
Ah! Good to know. I missed that! I was going to check the pre-submit checks for that but they aren't public. I do see that all of the existing PR commits do have the signed-off-by.
One of the the things we learned at @heptio is that folks can often be confused by the "-s" stuff and it is tricky to apply after-the-fact and re-push. Some more help on how to do that will probably smooth things for users. Newer git makes it easier:
How to use git interactive rebase for signing off a series of commits
I would like to sign off all commits on a branch that I have finished and want to send to an upstream project (e.g. via a pull request on GitHub). A recommended way I've found is to use git rebas...
stackoverflow.com
That's not an oversight. We generally don't do DCO. If others in the community are eager for it I don't have a problem adopting it.
We would love to have external maintainers :-)
Good to hear! Might be worth thinking about what those folks would look like and what they'd have to do to get there. Also pre-clear it with the lawyers and such.
Yeah, I think all communities are really trying to figure this out. We wanted to have something from the start but if we are successful in the long term, I would love to have a community based mechanism here.
It is a great start! And I love seeing a CoC from the get go. These things are *hard* though. Like *really* hard.
OMG thank you. More of these. SoundCloud?
Great breakdown.
Worth keeping in mind that it is a fork of Chromium’s crosvm
Yeah - I recognize that when talking about the license and the lack of DCO/CLA further in the thread.
But it is clear that this is a pretty deep fork with a different purpose so I guess it is new enough IMO to establish a new community.
Thanks for the feedback! It is an open source project, we’ll actively listen to community and customers actively and evolve!
Firecracker is awesome but AWS Amplify has been an OSS project for just over a year now with a lot of community involvement and completely originated in AWS
Not an expert there but it looks like Amplify *only* works with AWS backends? If so, I view it as more of an SDK vs. a core technology like Firecracker.
Nope, it's designed to be independent. Much of the implementation is for AWS backend right now but the category design is pluggable. For instance Auth0 can be used for some auth pieces instead of cognito, you can use generic REST or GraphQL endpoints with API component, etc
Well, the getting started docs start with creating an AWS account so it looks like a SDK to me even if things are pluggable. ¯\_(ツ)_/¯ aws-amplify.github.io/docs/
You have to give customers somewhere for getting started 😃, and it's not just a client lib but also toolchain for codegen, backend automation, etc