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

Keep actions in this pack being generic with simple implementation #36

Open
userlocalhost opened this issue Aug 20, 2019 · 1 comment
Open

Comments

@userlocalhost
Copy link
Collaborator

userlocalhost commented Aug 20, 2019

Goal

Replace current actions that is created for some specific purpose with generic ones.

Background and Problem

Some current actions (host_udpate_status, host_get_status and so on) in this pack were made for specific purpose.

But actions in an integration pack should provide more generic purpose with simple and reusable implementation.

Proposal

This propose to make generic actions that could fill in for current ones and replace them.

When user want to make an action that is for specific purpose, user should make a workflow that utilizes actions in integration packs.

That's my fault, the main cause of this situation is that I didn't understand the core concept of difference between integration pack and automation pack.

I think the relationship between integration pack and automation pack seem like to the one of library and application. Application provides functionalities for user by using of libraries. If a library provides only some specific purpose functions, it couldn't fascinate application developer.

@namachieli
Copy link
Collaborator

I'm a big fan of a single effective action.py kind of approach and I agree with your above post.

While it will take some effort to modify the existing actions, I would support a moratorium on new actions requiring the use of call_api.py, ensuring we stick to your approach going forward.

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

No branches or pull requests

3 participants