-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: yggdrasil engine #152
base: main
Are you sure you want to change the base?
Conversation
This is awesome work! But as early feedback, these are my initial thoughts: should we consider having:
I think the current implementation should co-exist until there is full feature parity and we have enough testing done with the client using rust implementation of the engine. There is also a question on how we would provide custom strategies, etc, but I think that is less relevant to bring up at the moment. Otherwise, I only have kudos to give! This is really awesome and impressive! |
So this:
Is an excellent idea and I'd like to do that. Yggdrasil is surprisingly more battle tested than it appears, since it forms the core of Edge and Edge has been feature complete for 6 months or so (minus custom strategies). The Ruby engine from Yggdrasil is a pretty thin wrapper around that but there's always scope for things to go wrong with such a large change. Medium to long term, the Ruby implementation won't be able to keep up with Yggdrasil unless it implements a full grammar parser (which I don't think is sane) so the pure Ruby implementation days are probably coming to an end in the next few months to years. I'm not convinced about pulling the existing Ruby engine in the SDK code out into a separate gem because of that (and I also don't want to deal with potential issues with refactoring that out on top of this complexity). I had kinda of thought to revert all the deletes and toggle between Yggdrasil and the existing code within the SDK. Once we're happy it works we can cull out the existing implementation. Idle thoughts still Custom strategies are coming! I have a blob of terribly ugly code on my machine that is a drop in replacement for custom strategies here but it needs work before more eyes see it. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Shhh stalebot, shh. |
211fcdf
to
b513382
Compare
…h namespace and remove usage of these throughout the bodebase
d85faf8
to
156356c
Compare
1622da5
to
8e64f84
Compare
f865a47
to
c2fba12
Compare
3c49290
to
9dc382e
Compare
@rarruda Okay, this is coming out of draft. We've spoke a lot internally about keeping a pure Ruby impl around but I think we'd rather go forward and if folks need a pure Ruby impl they can use a previous version until they can upgrade. Coverage is failing but looking at the details, a lot of that is because of the massive LOC reduction on this. There's little but logging that isn't covered. |
@@ -15,48 +14,35 @@ def initialize | |||
end | |||
|
|||
def generate_report | |||
now = Time.now | |||
metrics = Unleash&.engine&.get_metrics() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this optional here? It doesn't seem optional in client.rb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question! This may be my Rust opinions coming through here. The Client is owns the engine and makes it available to everything else when it's started up. Everything else may or may not have access to it, so this is paranoia and memory and ownership hygiene
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable to me. Can't wait to see Yggdrasil take over the rest of our SDKs as well :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
After looking extremely superficially at the PR:
all of the above can be done in a separate branch, before merging to master, but it is not strictly required. an extra thought then is that it might also be a good idea to have a pointer in the README in the master branch a pointer to the pre release branch, so to make it more obvious what the roadmap is. This is amazing work! ❤️ I hope someone bakes you a cake 🍰 and buys you a beer 🍺 ! |
shutdown is meant as the clean shutdown method, and shutdown! As the unclean version of it. The idea of saving in the clean shutdown/way, so if it does get restarted later, the it would pick up where it left off if the server is unavailable. Most likely it's a corner case that few will meet. |
I'm amazed how closely you read these commits haha and it makes me think I need to write better commit messages We shouldn't need this because it gets saved as it gets read from the Unleash API. We should have the most recent version of the API state already written from the last call. I don't think saving again is going to help much unless the user is dynamically bootstrapping or something equivalently evil |
It would happen in some race condition where the thread that would write to disk is not yet finished, but it is finished loading into memory, and you tell it to shutdown in between. Incredibly rare and weird. Or some sort of strange dynamic bootstrapping, and the state doesn't get flushed to disk correctly. Not really a normal use case. As you mentioned only would happen in really strange scenarios.
You have to forgive me, but sometimes I get bored during vacations. 😛 |
5130dd6
to
faa78d2
Compare
faa78d2
to
3fb4688
Compare
d8fecbc
to
0518b74
Compare
What's this?
This swaps out the logic for feature toggles in the SDK by using Yggdrasil. In particular, constructs that are now removed are:
For consideration
Perhaps controversial but I've also trimmed back the logic for custom strategies, a lot of this was to support the legacy way of registering custom strategies and has been marked as deprecated for some time. Yggdrasil won't let the caller get hooks into the custom strategies and so a lot of this isn't really possible anymore
We have no JRuby implementation right now, that's possible with Yggdrassil but not trivial. JRuby seems fairly important so we need to make a plan for this
Release strategy for this. It's a big change and we should be careful here