Add abstract orchestration modeling #45
Conversation
| begin | ||
| require "fog/#{provider}/network" | ||
| rescue LoadError | ||
| # is there a reason for this being automatic? |
There was a problem hiding this comment.
That is a very good question!
I dug around in an older version of fog before fog-core was split out and found this commit.
Glancing through the code, I don't see a reason why you would want networking. My guess is that this was a copy/paste fail, but let's leave this in here for now and we can create a separate PR at a later date to remove this.
|
@krames No problem renaming the methods over to |
|
@chrisroberts I would say remove them so we can encourage people to use |
|
@krames cool, already removed. aside from throwing in some docs on the models, anything else missing or questionable in this PR? |
|
@chrisroberts Thanks! I just want to loop the @geemus and @tokengeek in the DSL you added ( |
| raise NotImplemented | ||
| end | ||
| end | ||
|
|
There was a problem hiding this comment.
@geemus @tokengeek This PR has added a DSL to help facilitate adding a common abstraction for providers while keeping the high level logic at more generic level. You can see the concrete implementation in fog/fog#2971.
What are your thoughts on this approach?
|
Looks pretty good, at least at a high level (I don't feel I have sufficient concrete experience with orchestration to be able to comment on the specifics). |
|
@tokengeek @geemus I am planning on merging this PR in by the end of the week. In the meantime, @tokengeek let me know if you have reservations about this approach. |
|
@krames - Sorry not really had time. I also haven't looked at orchestration in detail. If anyone else in the community with experience can have a look that would be useful. |
|
@geemus @tokengeek I was less interested in running orchestration past you than I was the DSL ( |
|
@krames hmm. What does that look like in usage then? |
|
@geemus this PR on fog (fog/fog#2971) is dependent on this PR and is the concrete implementation on top of this abstraction. |
|
@krames so, you are pointing to the possibility of using the same pattern (at least in theory) for say |
|
Potentially. |
|
It is more meta, which can potentially be hard to debug, but it would simplify the code and reduce some duplication (especially in compute/storage where there are a lot of these repeated all over the different providers). I think there is certainly some merit to something like this anyway. |
|
Unless there are any other opinions or concerns, I'm going to finish out both PRs and throw some documentation on them too. Thanks! |
|
@chrisroberts sounds like a plan, thanks! |
|
@geemus filled out docs. was going to start on defining abstract style specs for concrete implementations to subclass and work against, but i think i may need some guidance on overall approach and it may be better suited for a different PR? Also wrapped up the fog PR that relies on this changeset: fog/fog#2971 |
|
@chrisroberts thanks for the work, seems awesome, sorry I haven't quite gotten to it yet. I think I should be able to give it a more thorough review tomorrow. |
|
Adding abstract specs would be great and definitely could help keep things on track as further providers come in to this space. Just let me know as you have questions, keeping it as a distinct PR seems like a good plan. |
|
Looks pretty good, though I must admit I lack some experience in the orchestration side in particular. I think a great next step might be to write up some docs describing at a high level what usage looks like, kind of like these examples: compute, storage. I think that would help me to understand how the pieces fit together a bit better (as well as help highlight gaps in the design, if any). What do you think? Thanks! |
|
@geemus I have seen some discussions here and there about providing an abstract spec. Are there any resources that fill this out more, or should I just take a shot and we can discuss the result (will cut a new PR for it)? I'll start on a high level description doc. Will link PR in here once I have it going. Thanks! |
|
@chrisroberts the example would be like: https://github.com/fog/fog/tree/master/tests/compute. Hope that clarifies at least a bit. We should move those in to fog-core probably, but that is where they still live at present. |
|
@geemus I ran across discussions about moving from shindo to minitest. Is that still an active goal? I'm indifferent to the library, would just like to target the correct one so it won't need to be re-implemented at a later date. |
|
@geemus PR for high level overview: fog/fog.github.com#28 |
|
@chrisroberts yeah, moving off shindo is definitely the plan. We ended up landing at minitest (though I still think about rspec sometimes), so using minitest would be preferred here. Just let me know if you have further questions from there. Thanks! |
|
This looks like great stuff. What is needed to push this through? |
|
Anything we can do to help push this forward? |
|
@kbrock I think high level docs and some testing around the abstraction itself would be great. Basically my concern at this point is around how hard (or not) it will be for us to adapt existing stuff to fit this pattern. Docs and tests both help to get us there (and ensure we don't drift). If you'd like to help with one or both that would be great. Just let me know if there is anything I can clarify or help with. Thanks! |
|
@kbrock i've moved focus on the orchestration stuff from this branch to a new lib. There are basic usage docs in the fog site repo. I hadn't focused much on the openstack part, but it should be mostly interchangeable with the RS implementation (and has been within spinoff lib). Please feel free to punt this forward if you feel like doing so. Cheers! |
|
What's the fate of this PR? I need a full stack of OpenStack Orchestration features. I saw the discussions in fog/fog#2971 where stated RackSpace Orchestration had been merged but not based on the modeling from this PR. If the modeling here is still the plan, I would like to help to push it through and then refactor OpenStack orchestration. |
|
The latest commit here has almost 4 years. I'm closing this due l believe there wont be any more development on this. Reopen or comment back if thats not the case. Thanks! |
Looking for feedback ✨