I also removed the old lambda based callback template from the repo. We're now using an SNS topic as part of a CustomFunction, to know when a user has deployed the stack (https://github.com/someengineering/fix-cf/blob/main/fix-role...). More work on our side, but less sketchy than executing code just to receive a callback that tells us the role name and account id.
We're currently working on Azure, but it's not stable enough to be listed here.
> > AWS, Google Cloud, DigitalOcean, VMWare Vsphere, OneLogin, and Slack
> kind of a weird mix of control planes
:D agreed. Two of these things are not like the others. There are also Github, Posthog and Scarf plugins.
To explain, Fix Inventory doesn't care about Cloud resources per se. It can create an inventory of whatever kind of resources. fixcore maintains a large graph of resources and makes them searchable. fixworker runs collector plugins and ships their results to the core. In theory you could build a plugin that monitors the sensors of your farm's greenhouses and run automations and reporting on them.
Slack for instance is there because when you want to notify a user on Slack it makes it convenient to lookup their internal Slack ID based on e.g. their Email address.
So you might do lookups like: AWS resource tag -> OneLogin User -> Email -> Slack UID.
The reasoning is explained in the very section of our Github org README you quoted this sentence from. Our main open source project is Fix Inventory (https://github.com/someengineering/fixinventory) and that is very well documented (https://inventory.fix.security) and uses no commercial 3rd party libraries.
The Fix SaaS frontend that you're referring to and that you find at https://fix.security builds upon Fix Inventory. We could have just made it closed-source like every other SaaS (think Grafana Cloud). But because I'm a big proponent of OSS we decided to open source our entire SaaS stack, frontend, backend as well as all internal tooling. The main intend here is transparency, not so you spin up your own SaaS environment.
Essentially we develop the SaaS for ourselves first and foremost, but saw no reason to make it closed source. So that is why it might be using any number of commercial 3rd party add-ons.
> I'm curious to know what Material UI provided that any other open-source UI library did not.
I believe it was some MUI X table features like multi row sorting that we didn't feel like re-implementing. I'm sure there's other open source libs that would do that, but we've settled on MUI and are not going to start mixing different UI libraries for different visual elements if we don't absolutely have to.
Like I wrote for us it was a one-off job to find and remove 6+ year old build artifacts that would never be needed again. I just looked for the cheapest solution of getting rid of them. I couldn't do it by prefix alone (prod files mixed in the same structure as the build artifacts) which is why delete.py supports patterns (the `--aws-s3-pattern` arg takes a regex).
If AWS' own tools work for you it's surely the better solution than my scripts. Esp. if you need something on an ongoing bases.
I had a similar issue at my last job. Whenever a user created a PR on our open source project artifacts of 1GB size consisting of hundreds of small files would be created and uploaded to a bucket. There was just no process that would ever delete anything. This went on for 7 years and resulted in a multi-petabyte bucket.
It's not exactly meant for end-users, but if you know your way around Python/S3 it might help. I build it for a one-off purge of old data. s3.py takes a `--aws-s3-collect` arg to create the index. It lists one or more buckets and can store the result in a sqlite file.
In my case the directory listing of the bucket took almost a week to complete and resulted in a 80GB sqlite.
I also added a very simple CLI interface (calling it virtual filesystem would be a stretch) that allows to load the sqlite file and browse the bucket content, summarise "directory" sizes, order by last modification date, etc. It's what starts when calling s3.py without the collect arg.
Then there is delete.py which I used to delete objects from the bucket, including all versions (our horrible bucket was versioned which made it extra painful). On a versioned bucket it has to run twice, once to delete the file and once to delete the then created version, if I remember correctly - it's been a year since I built this.
I also removed the old lambda based callback template from the repo. We're now using an SNS topic as part of a CustomFunction, to know when a user has deployed the stack (https://github.com/someengineering/fix-cf/blob/main/fix-role...). More work on our side, but less sketchy than executing code just to receive a callback that tells us the role name and account id.