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

Create the provider when creating the config_manager #62

Conversation

agrare
Copy link
Member

@agrare agrare commented May 13, 2020

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.

@agrare agrare requested a review from Fryguy as a code owner May 13, 2020 20:19
@agrare
Copy link
Member Author

agrare commented May 13, 2020

cc @skateman this should let us use the DDF create_from_params on the Foreman::ConfigurationManager

@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch from c12df78 to b115261 Compare May 13, 2020 20:34
@skateman
Copy link
Member

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 Provider but the Manager so it will head to inconsistencies in the names. We could solve it by delegating the name= to the Provider but as the API provides the name of the Manager we would be setting the suffixed name on the Provider which triggers the ensure_manager and sets a double suffix on the Manager.

It adds to the confusion that ensure_provider calls the ensure_manager and they are both setting values. We should probably just use one of them and my choice is the ensure_provider as that would be the new way of adding configuration managers. This doesn't solve the problem with the suffix, but at least would decrease the complexity of the code.

If we really want to keep the suffixing, we should probably add checks that ensure that the suffix is just added once in the Manager and it's not being added to the Provider.

@skateman
Copy link
Member

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:
ManageIQ/manageiq-ui-classic#7047
#60

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.

@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch from b115261 to af1da58 Compare May 14, 2020 13:36
@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch from af1da58 to 451da64 Compare May 14, 2020 20:58
@agrare
Copy link
Member Author

agrare commented May 14, 2020

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.

Copy link
Member

@skateman skateman left a 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": [],
  // ...
}

app/models/manageiq/providers/foreman/provider.rb Outdated Show resolved Hide resolved
@agrare
Copy link
Member Author

agrare commented May 15, 2020

Also when I edit a manager, it won't update the name of the provider, just the manager.

Actually it does update the provider name if you edit the manager and vice versa

>> foreman_c_manager = ManageIQ::Providers::Foreman::ConfigurationManager.first
=> #<ManageIQ::Providers::Foreman::Provider id: 25, type: "ManageIQ::Providers::Foreman::Provider", name: "Foreman", guid: "66f4c9f4-f992-41bb-919a-2ecd214c0515", zone_id: 2, created_at: "2020-05-15 14:21:20", updated_at: "2020-05-15 14:21:20", tenant_id: 1>
=> "Foreman Configuration Manager"
>> foreman_c_manager.provider.name
=> "Foreman"
>> foreman_c_manager.name
=> "Foreman Configuration Manager"
>> foreman_c_manager.name = "Foreman Updated Configuration Manager"
>> foreman_c_manager.save!
=> true
>> foreman_c_manager.provider.name
=> "Foreman Updated"
>> foreman_c_manager.name
=> "Foreman Updated Configuration Manager"
>> foreman_c_manager.provider.name = "Foreman"
>> foreman_c_manager.provider.save!
=> true
>> foreman_c_manager.name
>> foreman.name
=> "Foreman Configuration Manager"

@agrare
Copy link
Member Author

agrare commented May 15, 2020

Also when requesting endpoints and authentications through the API, I am getting empty arrays:

Really? That's not what I'm seeing:

$ curl --user admin:smartvm http://localhost:3000/api/providers/63\?attributes\=authentications,endpoints 2>/dev/null | python -m json.tool
{
    "api_version": null,
    "authentications": [
        {
            "authtype": "default",
            "id": "19",
            <clip>
            "type": "AuthUseridPassword",
            "updated_on": "2020-05-15T14:21:21Z",
            "userid": "admin"
        }
    ],
    "created_on": "2020-05-15T14:21:20Z",
    "enabled": true,
    "endpoints": [
        {
            <clip>
            "resource_id": "25",
            "resource_type": "Provider",
            "role": "default",
            "security_protocol": null,
            "updated_at": "2020-05-15T14:21:20Z",
            "url": "https://localhost",
            "verify_ssl": 0
        }
    ],
    "guid": "bc31901d-2738-4ca3-b3b7-8be638fba838",
    "host_default_vnc_port_end": null,
    "host_default_vnc_port_start": null,
    "href": "http://localhost:3000/api/providers/63",
    "id": "63",
     "name": "Foreman Configuration Manager",
    "provider_id": "25",
    "type": "ManageIQ::Providers::Foreman::ConfigurationManager",
    "uid_ems": null,
}

@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch from c2ffb65 to e94e1b7 Compare May 15, 2020 14:57
@skateman
Copy link
Member

skateman commented May 18, 2020

Also when I edit a manager, it won't update the name of the provider, just the manager.

Actually it does update the provider name if you edit the manager and vice versa

>> foreman_c_manager = ManageIQ::Providers::Foreman::ConfigurationManager.first
=> #<ManageIQ::Providers::Foreman::Provider id: 25, type: "ManageIQ::Providers::Foreman::Provider", name: "Foreman", guid: "66f4c9f4-f992-41bb-919a-2ecd214c0515", zone_id: 2, created_at: "2020-05-15 14:21:20", updated_at: "2020-05-15 14:21:20", tenant_id: 1>
=> "Foreman Configuration Manager"
>> foreman_c_manager.provider.name
=> "Foreman"
>> foreman_c_manager.name
=> "Foreman Configuration Manager"
>> foreman_c_manager.name = "Foreman Updated Configuration Manager"
>> foreman_c_manager.save!
=> true
>> foreman_c_manager.provider.name
=> "Foreman Updated"
>> foreman_c_manager.name
=> "Foreman Updated Configuration Manager"
>> foreman_c_manager.provider.name = "Foreman"
>> foreman_c_manager.provider.save!
=> true
>> foreman_c_manager.name
>> foreman.name
=> "Foreman Configuration Manager"

Maybe from the console, but not if I do the update via the API 😕 we're using ems.assign_attributes(params) and ems.save!.

@Fryguy
Copy link
Member

Fryguy commented May 18, 2020

we're using ems.assign_attributes(params) and ems.save!.

ems.save! should do the part where it updates the provider...are you not seeing that happen?

@skateman
Copy link
Member

@Fryguy yeah, that's what I'm saying. You can try with the 2 PRs mentioned here

@skateman
Copy link
Member

ManageIQ/manageiq#18818

@skateman
Copy link
Member

@agrare could you please rebase this, so @h-kataria test it without the issue?

Copy link
Member

@skateman skateman left a 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
Copy link
Member

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.

@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch 2 times, most recently from 96c94d1 to 27d56b7 Compare June 24, 2020 13:58
"#{provider.name} Configuration Manager"
end

delegate :name=, :zone, :zone=, :zone_id=, :to => :provider
Copy link
Member

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.

@skateman
Copy link
Member

It's almost working, there's a slight issue with the validation of the provider URL when editing. I'll investigate...

@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch from ef4c33a to 452a512 Compare June 24, 2020 17:33
@agrare
Copy link
Member Author

agrare commented Jun 24, 2020

@skateman yeah we weren't delegating endpoints= and authentications= so it was just destroying those on edit

@agrare
Copy link
Member Author

agrare commented Jun 24, 2020

There still seems to be an issue with verify_ssl always being 1, looks like the DDF form is saying it is a boolean checkbox but it really is an integer but that's not an issue with this PR as far as I can tell

@agrare
Copy link
Member Author

agrare commented Jun 25, 2020

I think the issue is that the provider isn't also saved with the ems when using .assign_attributes(:name => "").

When I do:

ems.name = "abcd"
ems.save!

then it works, but

ems.assign_attributes(:name => "abcd")
ems.save!

Not so much.

@skateman
Copy link
Member

Can we force the save of the provider when the EMS is being saved?

@agrare
Copy link
Member Author

agrare commented Jun 25, 2020

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

@skateman
Copy link
Member

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 😕

@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch 2 times, most recently from 70ca2df to e0aad78 Compare June 30, 2020 12:59
@agrare agrare force-pushed the auto_create_provider_for_configuration_manager branch from e0aad78 to dc9feda Compare June 30, 2020 13:01
@skateman
Copy link
Member

skateman commented Jul 1, 2020

Works well with ManageIQ/manageiq#20318

Copy link
Member

@skateman skateman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Seal of Approval

This is far from ideal, but the simplest way to ensure that changes to
the foreman provider get saved when edited from the API
@miq-bot
Copy link
Member

miq-bot commented Jul 1, 2020

Checked commits agrare/manageiq-providers-foreman@8141a03~...cfaaa5b with ruby 2.5.7, rubocop 0.69.0, haml-lint 0.28.0, and yamllint
4 files checked, 0 offenses detected
Everything looks fine. 🍪

ems.save!
end
end
end
Copy link
Member Author

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

Copy link
Member

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.

@gtanzillo gtanzillo merged commit 65634b0 into ManageIQ:master Jul 2, 2020
@agrare agrare deleted the auto_create_provider_for_configuration_manager branch July 2, 2020 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants