
The many ways to launch FreeBSD in EC2 - cperciva
http://www.daemonology.net/blog/2018-12-26-the-many-ways-to-launch-FreeBSD-in-EC2.html
======
pbalau
> Just run a buildworld/buildkernel of your modified FreeBSD, set up a few
> parameters (AWS keys, AWS region, and an S3 bucket to be used for staging
> the upload), and cd /usr/src/release && make ec2ami.

This is as FreeBSDish as it gets :)

~~~
cperciva
To be fair, this is for people who have made changes to the FreeBSD base
system -- so the buildworld/buildkernel is kind of axiomatic.

~~~
pbalau
It was mostly a joke, back in the day when I started using freebsd, it seemed
that the answer for 'how do I do such-and-such with FreeBSD' was, most of the
time, 'cd /usr/src && make such-and-such'

~~~
cperciva
Indeed -- annoyance with that is why I wrote FreeBSD Update. My view is that
regular users should never have to compile anything, and I certainly wouldn't
be happy if the _first_ option for running FreeBSD in EC2 involved running a
buildworld.

But I'm just fine with saying that this is an option for people who want to
make their own changes to the FreeBSD base system. (And moreover, anyone who
is making such changes is unlikely to be scared off by the
buildworld/buildkernel; in fact, they've already done it, when they were
making their changes offline.)

~~~
4ad
Hi Colin.

Why is freebsd-update(8) so slow? When upgrading between releases, it's
significantly slower than apt, yum, dnf, Solaris IPS, pkgin, FreeBSD's own
pkg(8), Windows Update, macOS update, while fundamentally doing less than any
of these tools. It's bordering on being unusably slow.

What's the problem here? Thanks.

~~~
cperciva
FreeBSD Update is doing something it was never designed for. I wrote it as a
tool for security updates -- which inherently affect just a handful of files
--and have a number of paranoid checks in it, in order that it can be safely
run blindly.

We needed a tool for upgrading between releases, and I was able to hack that
into FreeBSD Update, but I didn't change the fundamental design. At this
point, we're all waiting for pkgbase so there's no reason to revisit the
design now.

------
a012
Thanks Colin for the guides, though as I can find, only FreeBSD in BSD world
bothered to provide already baked and ready to use EC2 AMI (including AWS ENA
driver).

~~~
cperciva
I think you're right; at various times people have managed to build NetBSD,
OpenBSD, and (I think) DragonFlyBSD and published instructions, but I don't
think anyone has pushed to have those projects ship official images.

I don't blame them. It's a lot of work, and for most developers, if they need
to run something in EC2, their need is satisfied once they have images --
whether official images are publicly available is irrelevant. I'm in the
position of not just wanting to use EC2 _now_ , but wanting to make sure it's
available for me in the future -- so having a large userbase is important,
both so that other people can find bugs before me, and so that FreeBSD is
something Amazon cares about (the ENA driver was ported to FreeBSD by a team
hired by Amazon... without that, it would have taken us years to catch up).

~~~
voltagex_
There's a financial cost to having these AMIs online, right?

~~~
cperciva
Kind of. Yes, but it's on the order of a couple cents per month.

------
late2part
Is freenas running on AWS yet? Any interest in this if not?

~~~
cpach
Out of curiosity: What would be the use case/benefits of running FreeNAS on
AWS?

~~~
late2part
Had a really long conversation with some remarkably smart folks about this.

Here are the pros:

1\. It's a tool folks use; and being able to use it in AWS/Azure/GCP/etc would
be useful

2\. When folks use a tool they know, and need more capacity/locations, it'd be
nice to be able to 'cloudburst' into AWS/Azure/GCP/etc

Here are the Cons:

1\. Smarty pants folks can come up with many theoretical and plausible
solutions for anything FreeNAS can do in AWS using proprietary lockin
solutions from AWS. If you just reformulate your requirements, there's another
solution you can use instead of FreeNAS

2\. ZFS is good at helping with diverse physical volumes and this paradigm is
moot with AWS EBS volumes (as they are not physical volumes). However, this
argument reduces to "don't do parity/erasure coding across EBS volumes."

So, reply here if you want it and I'll work w/ some folks to make it happen.

In my case, there are a lot of places where we use disparately multitiered
storage on freenas/zfs/filesystem($foo) and sometimes it makes sense to
temporarily "cloudburst" into AWS while waiting hardware to support the load.

