[
https://issues.apache.org/jira/browse/BROOKLYN-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107864#comment-15107864
]
Hadrian Zbarcea commented on BROOKLYN-217:
------------------------------------------
Hi [~geomacy],
I looked at your branch, looks great. Here are some comments:
* agree that startWithSshAsync could be better organized. I actually wonder if
it's not better to move back to a Driver based implementation vs
SaltLifecycleEffectorTasks
* the leftover files from my previous attempts can be removed, obviously
* when installing you may add a check if the salt-call executable is present
(if so skip install)
* if {{salt-call --local}} is used it may be better (just in MASTERLESS mode)
to pass '-X' to install_salt.sh
* we could add config for using a proxy via download '-H' flag with
install_salt.sh
This latter part is something that concerns me a bit. My previous impl was
installing the salt-minion and salt-ssh packages via the package manager
configured with the system. Downloading the bootstrap script from the net may
not be an option for many environments behind a firewall. This is not just a
salt entity issue but a more general one.
The SimultatedLocation is useless in this context in the SaltIntegrationTest.
The desire was to allow more support for testing without using a more real
location. The rule for DriverInferenceForSimulatedLocation was needed in the
Driver based implementation, but useless now. On a side note, the code is split
between the o.a.b.cm.salt and o.a.b.cm.salt.impl packages. The rationale was
that best practices in OSGi dictate to hide implementation as private package
as much as possible. A driver inference rule would be needed for that if we
were to move to that kind of model across the board.
Back to effectors, I think the "apply" effector makes sense. Sensors, yeah, not
sure, but more could be added later.
> Support for SaltStack
> ---------------------
>
> Key: BROOKLYN-217
> URL: https://issues.apache.org/jira/browse/BROOKLYN-217
> Project: Brooklyn
> Issue Type: Improvement
> Reporter: Hadrian Zbarcea
> Assignee: Hadrian Zbarcea
> Fix For: 0.9.0
>
>
> SaltStack is a popular configuration management tool.
> SaltStack would rapidly extend its support for managing services in a cloud
> infrastructure by using SaltStack master/minions and leveraging SaltStack
> formulas. SaltStack grains provide metrics about hosts and installation and
> would be a good source of sensors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
