-
Notifications
You must be signed in to change notification settings - Fork 36
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
Create the provider when creating the config_manager #62
Create the provider when creating the config_manager #62
Conversation
cc @skateman this should let us use the DDF |
c12df78
to
b115261
Compare
This suffix building in the name is causing a lot of headache. Do we really need it? When I try to edit a newly created provider, it won't set the name of the It adds to the confusion that If we really want to keep the suffixing, we should probably add checks that ensure that the suffix is just added once in the |
I created a UI PR that allows you to run the new provider forms for the Configuration Managers and adjusted the DDF schema to make the params validation on the API side pass. These should allow you to try some things: Note that after applying your changes there's an exception in the old forms when editing a provider, but it doesn't block you from working with the new form. |
b115261
to
af1da58
Compare
af1da58
to
451da64
Compare
Okay this now updates the provider name when the manager name is changed. I want to keep the old way (creating and updating the provider) as well as the DDF forms way (creating and updating the Configuration Manager) working until we officially move over to DDF. Then we can get rid of the Provider#ensure_managers and ConfigurationManager#ensure_provider and just use one but for now both routes work even if it seems like overkill. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea, but I have some concerns about the naming. Also when I edit a manager, it won't update the name of the provider, just the manager. I guess you'd need to delegate the name=
to the provider.
Also when requesting endpoints
and authentications
through the API, I am getting empty arrays:
// GET /api/providers/ID\?attributes\=authentications,endpoints
{
// ...
"authentications": [],
"endpoints": [],
// ...
}
Actually it does update the provider name if you edit the manager and vice versa
|
Really? That's not what I'm seeing:
|
c2ffb65
to
e94e1b7
Compare
Maybe from the console, but not if I do the update via the API 😕 we're using |
|
@agrare could you please rebase this, so @h-kataria test it without the issue? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're facing some delegation errors for endpoints/authentications when editing a provider. Also changing the name (and I guess also the zone) of the manager doesn't prevail on the provider with the before_save
callback. The code is a little chaotic as there are before callbacks in both models. I understand that you'd like to keep the old behavior for compatibility, so here's my idea:
Let's define a name=
method that removes the Configuration Manager
suffix from the name and sets it on the provider, imagine it as a delegate_with_a_replace
. The zone
and zone=
methods should be delegated normally and then we can strip down the ensure_provider
to the absolute minimum and get rid of the ˙ensure_provider_name_and_zone` method.
We would need to change the ensure_managers
method on the other side, to propagate back the suffixed name as the before_validation
callback doesn't get called upon an edit.
:verify_credentials, | ||
:with_provider_connection, | ||
:to => :provider | ||
|
||
belongs_to :provider, :autosave => true, :dependent => :destroy | ||
|
||
before_save :ensure_provider_name_and_zone |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The before_save
doesn't really deal with the new name
and zone
value coming from an edit action. I debugged the method below and the name
value was the one stored in the DB and not the one I'm changing the value to. It works well on create, but not when editing through the API.
96c94d1
to
27d56b7
Compare
"#{provider.name} Configuration Manager" | ||
end | ||
|
||
delegate :name=, :zone, :zone=, :zone_id=, :to => :provider |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'd also need zone_id
here so the API returns the correct info.
It's almost working, there's a slight issue with the validation of the provider URL when editing. I'll investigate... |
ef4c33a
to
452a512
Compare
@skateman yeah we weren't delegating |
There still seems to be an issue with verify_ssl always being |
I think the issue is that the provider isn't also saved with the ems when using When I do:
then it works, but
Not so much. |
Can we force the save of the provider when the EMS is being saved? |
That's what the autosave should be doing, we could explicitly save the provider if we override edit_with_params which is a little gross |
I'd like to avoid a hack like this if possible 😕 |
70ca2df
to
e0aad78
Compare
e0aad78
to
dc9feda
Compare
Works well with ManageIQ/manageiq#20318 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is far from ideal, but the simplest way to ensure that changes to the foreman provider get saved when edited from the API
Checked commits agrare/manageiq-providers-foreman@8141a03~...cfaaa5b with ruby 2.5.7, rubocop 0.69.0, haml-lint 0.28.0, and yamllint |
ems.save! | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been having a lot of issues with getting the provider autosave working across all the different provider repos. I want to unblock @skateman while we work those out and the simplest way to do that is to manually save the provider while creating/editing the configuration_manager via the API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is ugly, but if it works, I'm good with that.
Stay consistent with the rest of the managers which create the "primary" manager and auto-creates the provider.
This will allow the UI to add ConfigurationManagers the same way they add everything else (permissions and all) which will enable allowing us to add other types of ConfigurationManagers.