Skip to content
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

Refactor muchos' EC2-specific python code? #279

Open
keith-ratcliffe opened this issue Sep 4, 2019 · 2 comments
Open

Refactor muchos' EC2-specific python code? #279

keith-ratcliffe opened this issue Sep 4, 2019 · 2 comments

Comments

@keith-ratcliffe
Copy link
Contributor

keith-ratcliffe commented Sep 4, 2019

It may be worth considering moving towards a template-driven approach for all EC2 cluster types, since it could be used as an alternative to the current "default mode" behavior, i.e., for ephemeral-only clusters

That would significantly reduce the amount of python needed overall (but at the expense of forcing users down the path of using templates, when maybe they don't even need/want the additional flexibility...and complexity)

@ctubbsii
Copy link
Member

ctubbsii commented Sep 4, 2019

We don't technically have "users" for Muchos. Since this is an "in-house" set of scripts intended for Fluo(/Accumulo) developers, and not a wider user audience. The Fluo PMC does not "release" this as a product of the Foundation (at least, we haven't yet, and there's no current plans to do so), and we don't have any versioning. So, the only consideration is whether it currently works for those of us actively developing on Fluo(/Accumulo).

As such, I wouldn't be concerned about breaking changes or changing how Muchos works. The Fluo (and Accumulo) developers can adapt to whatever the current code is, so long as it aids our development.

I'd be strongly in favor dropping the "default mode" and only using the "template mode" that you added in #274 ; that would reduce the amount of EC2 code we need to maintain. The more we can do that, the better.

@keith-turner
Copy link
Contributor

but at the expense of forcing users down the path of using templates, when maybe they don't even need/want the additional flexibility...and complexity

I think the good documentation and examples you provided address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants