Foreman broker #291
Foreman broker #291
Conversation
| help="Name of the Foreman hostgroup to deploy the host", | ||
| ), | ||
| ] | ||
| _execute_options = [] |
There was a problem hiding this comment.
were you planning on using the job invocation for executes at this time or a later time?
There was a problem hiding this comment.
It is implemented to use job invocation for executes and I already tried it within robottelo tests (mediated through the created host object).
I had no use for implementing this as a standalone feature for the command line so far. Or am I missing something here?
There was a problem hiding this comment.
I have no solid requirement for hooking up the execute functionality through the cli and Broker's execute method. I was primarily just thinking that it looks like you have everything needed here to set that up.
knoppi
force-pushed
the
foreman-broker
branch
2 times, most recently
from
949cfce to
5c3f89c
Compare
|
@knoppi It looks like your test failure is due to a chicken/egg design limitation around Broker's config that I can likely address for 0.5. I assume these tests are passing locally. |
There might be some design issue with my test as well. They were passing locally when I ran them with a non-working, but valid config. Yesterday when reworking I realized they fail without pointing to my test settings. They fail during validation because they cannot find the required settings (organization, location, username, password). I then checked how you do this for other providers. For containers there is no setting defined as My preferred solution would be reading the settings in the class ForemanBind where they are actually needed, so I could overwrite the validators in the MockStub. With the current design, I see two options:
Option 1 would leave me rather useless tests. Option 2 seems error-prone but error handling should be sufficient to indicate if you are using the wrong values or forgot to set some. Do you have an oppinion on that? |
|
Since you're loading the settings in the init phase, you also have the option to pass a MockStub version of the settings that has the values you want for your test. ...
settings = kwargs.pop("stub_settings", settings)However, since most of your validators are set to must_exist, you'd still fail dynaconf's settings validation. Hold tight for now and we'll see if the change I'm working on for local settings init will help. |
- Rename ForemanAPI to ForemanBind - Put Foreman Bind in a separate file - Create exception for FormanBind - Make internal method private - Add method to query hostgroup information
|
Hi, I'm not sure if the tests work after the rebase. Locally they would never take the settings from the repo. In my latest commit you will find a workaround. With that, tests pass. |
* Add foreman broker * add example settings for Foreman broker * Reorganize classes - Rename ForemanAPI to ForemanBind - Put Foreman Bind in a separate file - Create exception for FormanBind - Make internal method private - Add method to query hostgroup information * Apply organizational changes in tests too * Get rid of constructor call in provider_help * Hotfix for github action --------- Co-authored-by: Jan Bundesmann <bundesmann@atix.de>
As dicussed in #284 we created a draft for a foreman broker. Command execution relies on foreman's remote execution.
No configuration of foreman is done by this broker and host provisioning relies solely on correctly configured host groups. The broker can understand the parameters
imageandcompute_resourceto do an image based deployment which accelerates the checkout process.