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

Embedded Ansible setup guide #276

Closed
wants to merge 5 commits into from
Closed

Embedded Ansible setup guide #276

wants to merge 5 commits into from

Conversation

himdel
Copy link
Contributor

@himdel himdel commented Dec 8, 2017

Mostly expanded from https://gist.github.com/carbonin/8cfd24906d3c1513c5b91736226f0007

This adds a guide to enable embedded ansible in devel mode, using DockerEmbeddedAnsible which sets up a local awx instance under docker.

Cc @carbonin , @martinpovolny , @ZitaNemeckova


* Debian: `/etc/postgresql/9.6/main/`
* Fedora: `/var/lib/pgsql/data/`
* MacOSX: `/usr/local/var/postgres/`
Copy link
Member

Choose a reason for hiding this comment

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

I would imagine these would depend heavily on where you installed the package from.

For example I'm using Fedora and my postgresql.conf file is in /var/lib/pgsql/9.5/data

Copy link
Member

Choose a reason for hiding this comment

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

Something like this is probably more portable.

$ psql -d postgres -c 'show config_file'
               config_file               
-----------------------------------------
 /var/lib/pgsql/9.5/data/postgresql.conf
(1 row)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Except then we need the right invocation for each system :)...

$ psql -d postgres -c 'show config_file'
ERROR:  must be superuser to examine "config_file"

Copy link
Contributor Author

@himdel himdel Dec 8, 2017

Choose a reason for hiding this comment

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

I think I'll just add a mention that these dirs may wary, and that you may have some luck running that command, WDYT?

The idea was mostly so that people have a place to start looking, it will always depend on the current version, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, added a note about these depending on other stuff, and a note that you can try running that command.

Make sure your `pg_hba.conf` contains:

```
host all all 172.17.0.1/24 md5
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure this subnet is the same for all docker installations.

Maybe an explicit address isn't a good idea here. I would say instead to allow connections from the subnet used by the docker0 interface.

For example, ip a shows this for me, but that gateway address might not be the same for everyone.

    docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:3a:94:df:ba brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a note on running ip addr show dev docker0, thanks :)

Copy link
Member

Choose a reason for hiding this comment

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

Maybe these postgresql.conf and pg_hba.conf changes should be made to the developer setup guide with a note that you'll only need them if you want to use embedded ansible.

```


Ensure your DB user (the one in `config/database.yml`) has `superuser` rights..
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this needs to be specified here as this is suggested in the main developer setup document

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd keep it just to make sure :). It surprised me so it could surprise more people, and ... assuming every devel has removed any security from their postgres install is probably wrong, even though those instructions mention it.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think this needs to be specified here as this is suggested in the main developer setup document

Well I don't have it that way. Security is one of the reasons.

This setup adds more stuff that depends on the superadmin config?

I don't think we should be doing that and I definetly agree that if it's really needed we write it here (again).

Copy link
Contributor Author

@himdel himdel Dec 11, 2017

Choose a reason for hiding this comment

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

This setup adds more stuff that depends on the superadmin config?

Unfortunately the worker needs to create a DB and a role, so yes. :(

Agreed it's a bad idea, in the gitter discussion @Fryguy mentioned this should be something that should be optional for the more exotic setups ... but for now we seem to be stuck with it, yes.

Copy link
Member

Choose a reason for hiding this comment

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

So, you can't rake evm:db:reset either?

Copy link
Member

Choose a reason for hiding this comment

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

If you run differently then the default guides, you're going to have issues because we can't know how you diverged from the guides. Please either change the default guides to be "right", include sensible alternatives in the guides, or use the defaults. It's hard enough to maintain these guides when people use the defaults, if they don't use the defaults, the guides become stale and it's easy to accidentally break someone else's setup.

@martinpovolny
Copy link
Member

@himdel : thank you for taking the time to do this work.

I think that in the future we should not merge PRs with functionality that cannot be setup for testing (and the setup is not explained) in the PR.

I mean if special steps are needed to review a PR the steps should be publically available so that anyone can test and review and work with the PR.

bdunne
bdunne previously requested changes Dec 11, 2017

Your PostgreSQL must be configured to allow connections from the docker container, so that AWX can connect to manageiq's database.

Your ManageIQ DB user (the one in `manageiq/config/database.yml`) must have the `SUPERUSER` privilege (or at least needs to be able to create roles and databases).
Copy link
Member

Choose a reason for hiding this comment

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

That's already a requirement of the development setup.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See #276 (comment)

Nobody who knows about DB security follows these intstructions precisely :).


### Dependencies

You need docker.
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should add any more than this. Different platforms have it packaged with their native package manager otherwise Docker has instructions for installation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, we needed to find out how to do this on a mac. I can either throw this info away, or include it in the guide :).

Since many of our devels use macs, I think this is valuable :).

Your ManageIQ DB user (the one in `manageiq/config/database.yml`) must have the `SUPERUSER` privilege (or at least needs to be able to create roles and databases).


Config file locations (where to expect it):
Copy link
Member

Choose a reason for hiding this comment

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

Again, do we need this? It's going to be different for every platform

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Again, we can make it easy by giving people info they'll probably need, or we can tell them to go looking.

If you're willing to answer all the questions from people trying to follow the document, I'm willing to remove it :).

```


Ensure your DB user (the one in `config/database.yml`) has `superuser` rights..
Copy link
Member

Choose a reason for hiding this comment

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

So, you can't rake evm:db:reset either?

If you've already set up an AWX instance this way and want to clean it up:

```
psql -d postgres -c 'DROP DATABASE awx'
Copy link
Member

Choose a reason for hiding this comment

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

We should probably enhance rake evm:db:reset to handle these for us.

In both cases, you may also need to clean up the old authentications (in Rails console):

```
db = MiqDatabase.first
Copy link
Member

Choose a reason for hiding this comment

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

These should probably be cleaned up on provider destroy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should.. but aren't :).

I had to do this to get it working, so IMHO this needs to be in the guide

Copy link
Member

Choose a reason for hiding this comment

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

This sounds like a provider bug we should fix. I'm fine with keeping these steps but open an issue and link to the issue so we can circle back and remove this if and when it's fixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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


```
db = MiqDatabase.first
db.authentication_type('ansible_secret_key').delete # db.ansible_secret_key.delete
Copy link
Member

Choose a reason for hiding this comment

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

Also, shouldn't these be destroy?

Copy link
Contributor Author

Choose a reason for hiding this comment

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


### Procfiles

Under your `manageiq/` directory, create these 2 files:
Copy link
Member

Choose a reason for hiding this comment

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

Can this information be in Procfile.example instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Regardless of it's presence in Procfile.example, this needs to be here too, so that people know which lines to uncomment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

With ManageIQ/manageiq#16679 merged, can this just be a pointer to that now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed


### Setting it up

* configure your server to enable the ansible role (from Rails console):
Copy link
Member

Choose a reason for hiding this comment

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

Also, you should be able to rake evm:start and turn the role on. Right @carbonin ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've never run evm:start and don't really intend to. That's simply not how UI does it..

Copy link
Member

Choose a reason for hiding this comment

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

@himdel If that's the case, there's some things you just won't be able to do in the UI. I would not expect all features on the appliance to be feasible or desirable in a rails server process.

Copy link
Contributor Author

@himdel himdel Dec 11, 2017

Choose a reason for hiding this comment

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

Do you know which? So far, everything seemed to work...

But, as long as this is mostly around refresh or things like that I think that's perfectly acceptable - at least, I have not needed to evm:start for any PR I've reviewed in the last year, so.. :)

At least, still better than that "Embedded Ansible not supported, deal with it" :)

Copy link
Member

Choose a reason for hiding this comment

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

@himdel replication, server failover, various platform/provider specific things such as scanning vms/instances on various providers. We will try to make things easier if we can but at some point we have to say it's too much effort and frankenstein code if there's an easy workaround.

Copy link
Contributor Author

@himdel himdel Dec 11, 2017

Choose a reason for hiding this comment

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

@jrafanie Ah, perfect, thanks! :) I don't think we get many UI PRs dealing with those things.

I agree that when you want to test replication, etc., you need to run the whole app.

But this mostly is so that every member of the team can actually test embedded ansible PRs in their devel setups, and for that I think this is OK :).

Copy link
Member

Choose a reason for hiding this comment

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

I long ago accepted that there's just some things that are easier to let run on appliances. Thanks for questioning this because if there are easy changes to do, we should do them. With that said, though we have to be careful not to add too much hard to maintain hackery. At some point, we'll need to step back, measure the size of each yak and see if it's worth shaving.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed there.. but.. if the UI team can't run code needed to merge PRs, we would literally waste hours on reviews, so... balance :)

Copy link
Member

Choose a reason for hiding this comment

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

If you need to run most PRs locally before merge, that sounds like the problem in the workflow. The only ones I ever run manually on an appliance are ones where tests would be brittle or even useless since they'd require mocks around everything, such as running system commands in ruby and testing some side effect much later (black console partitioning, etc.)

@himdel
Copy link
Contributor Author

himdel commented Dec 11, 2017

So, you can't rake evm:db:reset either?

I never tried. What does it do?

@himdel
Copy link
Contributor Author

himdel commented Dec 11, 2017

@bdunne As far as I can tell ... evm:db:reset drops the database and creates it again.

If that's so... nobody can use it :). Not if you want to keep your data :). So no, not a solution for people trying to get embedded ansible working in devel mode, no :).

@bdunne
Copy link
Member

bdunne commented Dec 11, 2017

@himdel Right, it's a replacement for rake db:reset. It's used by many people to fix issues with test databases that have data in them, and any time you need to start from a clean state.

@himdel
Copy link
Contributor Author

himdel commented Dec 11, 2017

@bdunne So I'd assume we can't use it in the guide :).

The intended audience for this document is essentially:

  • I have a DB which I work with because I have all the data
  • there's a PR touching embedded ansible I need to test
  • => how do I do that :)

(or "there's a PR touching embedded ansible I need to write" :))

Anything that removes my data is probably not for everybody :)

@Fryguy
Copy link
Member

Fryguy commented Dec 11, 2017

If that's so... nobody can use it :)

LOL I think I use it daily.

@martinpovolny
Copy link
Member

If that's so... nobody can use it :)

LOL I think I use it daily.

Seems the typical workflow on the UI is very different to the backend.

For most UI developers a database with all the important types of entities populated is a precious resource that is shared and passed from one dev to another.

@jrafanie
Copy link
Member

Seems the typical workflow on the UI is very different to the backend.

For most UI developers a database with all the important types of entities populated is a precious resource that is shared and passed from one dev to another.

This is fine and hopefully switching branches isn't too much of a hassle with that flow. Whatever gets the job done but clearly we have completely different perspectives. Please open issues or PRs when there's contamination such as the provider destroy not removing authentications since those of us using evm:db:reset frequently are unlikely to get burned by it. I wonder if it has anything to do with the async destroy of providers.

Is there are a document that illustrates the differences between the current guides and what is done in the UI workflow?

@martinpovolny
Copy link
Member

This is fine and hopefully switching branches isn't too much of a hassle with that flow.

It depends. What I do is keep several databases and switch between the databases as I switch branches. Especially between releases.

Is there are a document that illustrates the differences between the current guides and what is done in the UI workflow?

I am not aware of such document. And there's not that much difference. Many UI people keep databases and switch between databases. And some use more secure database authorization configuration. But @himdel, @ZitaNemeckova and @romanblanco might know more about such differences as they go throught the setup with students.

@romanblanco
Copy link
Member

But @himdel, @ZitaNemeckova and @romanblanco might know more about such differences as they go throught the setup with students.

@martinpovolny We don't have anything special for students, that I'd be aware of.

@himdel
Copy link
Contributor Author

himdel commented Dec 18, 2017

The only difference that wasn't mentioned here already that I'm aware of - most of us don't use manageiq/plugins/manageiq-ui-classic, choosing to have manageiq/ and manageiq-ui-classic/ side by side. That was documented in the UI split guide, until somebody chose to remove it :) (#202) - but the new plugin instructions work too, so.. not really seeing a point in documenting this again.

@himdel
Copy link
Contributor Author

himdel commented Dec 18, 2017

Ping @bdunne ... looks like this is waiting on you.. Anything else needs to be fixed here?

@martinpovolny
Copy link
Member

ping @bdunne ?


```
# redirect local 54321 to docker-machine - otherwise, localhost:54321 doesn't work
docker-machine ssh default -L 54321:127.0.0.1:54321
Copy link
Member

@Glutexo Glutexo May 30, 2018

Choose a reason for hiding this comment

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

Wouldn’t it be better to set up a proper port forwarding in VirtualBox? This way it wouldn’t be necessary to keep the SSH session open. It’d be a less hacky solution too.

See https://stackoverflow.com/questions/32174560/port-forwarding-in-docker-machine

You’d need to run something like this

VBoxManage modifyvm "default" --natpf1 "awx,tcp,127.0.0.1,54321,,54321"

or you can set it up in the VirtualBox GUI.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds better, how would you do that so that it only affects the docker machine and not other VirtualBox machines?

Copy link
Member

Choose a reason for hiding this comment

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

The setting is machine-specific. The default there in the command is a name of the Docker Machine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

mentioned as an alternative

@djberg96
Copy link
Contributor

I feel like this should be merged, and any corrections or updates that need to be made can be done in separate PR's. I get that the UI team has a different workflow from the backend folks, but I think we can adapt and/or tuit how we want to do those bits. Or update the doc later.

Otherwise this seems like it will languish.

@himdel
Copy link
Contributor Author

himdel commented Jan 21, 2019

Rebased, updated to use Procfile.example from ManageIQ/manageiq#16679, and to mention VBoxManage as an alternative for making the database accessible to the docker VM on macs.

I can no longer vouch for any of those instructions to be current and accurate though.
They worked a year ago ;).

@bdunne
Copy link
Member

bdunne commented Jan 21, 2019

I get that the UI team has a different workflow from the backend folks, but I think we can adapt and/or tuit how we want to do those bits. Or update the doc later.

I know that certain teams (not just the UI) have somewhat different workflows and use cases and I have no problem with that. People should follow whatever workflow is most productive for them.
That being said, my two biggest concerns here are:

  • We have enough trouble keeping our own documentation up to date and I don't think we should attempt to document the usage of other products in our documentation, especially when it is different for every platform.
  • I think we should document and support one simple success path for a generic developer environment setup. Any supplemental documents should build off of this base. There are many configurations that can be changed for various purposes, like enhanced Postgres security, but if people are familiar enough with this, they'll probably know how to configure that and they'll be responsible for troubleshooting the problems that may arise because of it.

@himdel
Copy link
Contributor Author

himdel commented Jan 21, 2019

I respectfully disagree, because that's not how you use the documentation.

The intended audience here was: I'm already a UI developer, and need to get ansible working.

Removing the info about databases will force everybody to have to look up some other piece documentation.
What's the point of a setup guide if you have to use other guides to understand it?

I think if you want the documentation simple, the process needs to be simple as well. It's not.

For example:
If you can get rid of the need for docker, we can drop a lot of the content here.
Most of the stuff around postgres is here only because there are special needs when using docker, especially on macs.
But if I remove this, nobody on a mac will be able to get this working. Or they will have to spend at least a day to figure out those things. (I have.)

But as long as we need people who use macs to be able to set up ansible, we need to document everything they will need to do.

Otherwise, this guide will be:

  • set up ansible (somehow)
  • figure out how procfiles work, and set that up
  • make sure you DB is accessible from everywhere and has a remotely accessible superuser account (somehow)
  • figure out how to setup docker properly on your platform
  • figure out how to make docker see your database
  • a bunch of paragraphs about the manageiq console details

In other words, I believe the documentation would be completely useless without the details :).

At the same time, I'd really love to not have to document all those things.
But .. then, we can't depend on them.

(Or we need to exclusively hire people who all have experience configuring postgres, experience using docker, experience setting SNAT/DNAT/some kind of tunels, and experience setting up ansible.)

@bdunne bdunne dismissed their stale review January 21, 2019 18:24

Okay, can someone else review instead?

@martinpovolny
Copy link
Member

@himdel : I could use a working Ansible setup for a PR I am working on. Going to test your Guide.

@himdel
Copy link
Contributor Author

himdel commented Jun 7, 2019

Thanks :)

Just heads up, I'm not sure if this will be useful for much longer, as far as I know there's no AWX in 5.11,
replaced by ansible runner, if I understand right (https://bugzilla.redhat.com/show_bug.cgi?id=1717139).

@martinpovolny
Copy link
Member

Cool and is there a way to test?

@himdel
Copy link
Contributor Author

himdel commented Jun 7, 2019

Maybe @carbonin knows more.. I'm not sure ansible runner is even ready yet, I don't see any PRs.

@carbonin
Copy link
Member

carbonin commented Jun 7, 2019

Yeah, @NickLaMuro and I are hoping to get the first pass in soon. I'm also trying to ensure that everything works locally as long as you have ansible-runner installed.

@carbonin
Copy link
Member

carbonin commented Jun 7, 2019

You can watch ManageIQ/manageiq#18687 for status. That's the first pass on runner.

@himdel
Copy link
Contributor Author

himdel commented Jun 7, 2019

Thanks!!! I'd love to be able to live without docker in development :)

@NickLaMuro
Copy link
Member

For what it is worth, ManageIQ/manageiq#18687 is about 3 tests away from passing, so we are pretty close.

Also, @Fryguy had some primitive steps for installing ansible-runner (on a Mac) in his architecture issue here:

ManageIQ/manageiq-design#45

So you could possibly use that as a jumping off point for the re-working of this guides PR.

@Fryguy
Copy link
Member

Fryguy commented Jun 7, 2019

I just added an embedded ansible github label as well, to make it easier to find these PRs. Once we've merged the main one, we are going to iterate on follow up PRs.

@Fryguy
Copy link
Member

Fryguy commented Sep 13, 2019

@himdel The new embedded ansible is done, and ivanchuk-1 release is right around the corner. Would you like to revamp this PR or close it? Whichever you prefer.

@himdel himdel closed this Sep 16, 2019
@himdel
Copy link
Contributor Author

himdel commented Sep 16, 2019

Closing, this may still be useful as-is if we need to debug embedded ansible pre-ivanchuk,
and right now I'm completely ignorant of almost everything in the new implementation, so, perhaps not the right person to write that guide :)

@himdel
Copy link
Contributor Author

himdel commented Sep 23, 2019

As for the new thing, here's what I figured so far:

@NickLaMuro any ideas there please?

@NickLaMuro
Copy link
Member

NickLaMuro commented Sep 23, 2019

simulate_queue_worker is not enough

@himdel huh, that is a bit surprising, but I have almost exclusively been running/testing this on an appliance since I don't want to jack up my machine by running some playbook inadvertently.

I will look into this this morning, but you only really should need simulate_queue_worker to handle some quick seeding, but after that, a page refresh should be enough to see the "Add new repo" button and such. There is no worker necessary besides a generic worker for running playbooks, but I will see what simulate_queue_worker is doing to determine what needs to be done.

@himdel
Copy link
Contributor Author

himdel commented Sep 23, 2019

Thanks Nick :)

I tried restarting the server too, but still, MiqRegion.my_region.role_active?('embedded_ansible') is stubbornly false (ref)

(a ManageIQ::Providers::EmbeddedAnsible::Provider does exist)

@NickLaMuro
Copy link
Member

NickLaMuro commented Sep 30, 2019

@himdel oh crap... I just realized I have left this for a week now with no response... sorry!

So, I don't have a firm "this will fix it" but something you might be able to do is run the server with "rake evm:start" and let that run for a bit. My guess is it should run though some of the code here:

https://github.com/ManageIQ/manageiq/blob/master/app/models/miq_server/role_management.rb

And would most likely handle what is needed to enable the role, but not positive. I still haven't figured out what triggers the seeding when a role is activated, which is why I am not able to give you a bin/rails r "oneliner" yet...

Note: I was looking into this, but I didn't really have anything concrete to share, and still don't think this is a good solution either, hence the radio silence.

@himdel
Copy link
Contributor Author

himdel commented Oct 3, 2019

Thanks @NickLaMuro, no problem, a week is beneath my threshold really :)
Of course, that said, if we can't enable embedded ansible during development, those parts of UI will rot ;).

Right now, the server claims embedded ansible is on in Server Settings,
but MiqRegion.my_region.role_active?('embedded_ansible') is still false.

(MiqServer.my_server.role is "", MiqServer.my_server.assigned_server_roles an empty collection.)
(MiqServer.my_server.settings[:server][:role] does contain embedded_ansible in the list, which is why Server Settings show the role as enabled.)

@himdel
Copy link
Contributor Author

himdel commented Oct 3, 2019

When running as evm:start,
the my_server instance is the same id, but suddenly MiqServer.my_server.role is "automate,database_operations,database_owner,embedded_ansible,ems_inventory,ems_operations,event,remote_console,reporting,scheduler,smartstate,user_interface,web_services", sasigned_server_roles have 13 entries, and stuff seems to work :).

@himdel
Copy link
Contributor Author

himdel commented Oct 3, 2019

So, sounds like the issue is that MiqServer#assigned_server_roles is never set in development?

@jrafanie
Copy link
Member

jrafanie commented Oct 3, 2019

Maybe ManageIQ/manageiq#19328 would help your workflow in regards to setting the assigned roles and activating them. I can't tell if you're running this only in bin/rails server or another way. But, if it's rails server, putting the lines from that PR to assign the roles and activate them could possibly be used here

@NickLaMuro
Copy link
Member

Quick Instructions

  1. Start a development server:

    $ bin/rails s
  2. Enable the Embedded Ansible role on the settings page

  3. From the console, run the following:

    $ bin/rails c
    irb> ManageIQ::Providers::EmbeddedAnsible.seed
    irb> MiqServer.my_server.reload_settings # just incase
    irb> MiqServer.my_server.sync_assigned_roles
    irb> MiqServer.my_server.monitor_server_roles
    irb> MiqRegion.my_region.role_active?('embedded_ansible')
    #=> true

Long Answer (WTF is going on here)

Well, the tl;dr for the "long answer" since bin/rails s doesn't run a MiqServer instance which is in charge of both seeding the EmbeddedAnsible data and setting up server roles.

The methods specifically that are locking you out are found here:

https://github.com/ManageIQ/manageiq-ui-classic/blob/fbd7afa844298d5d7dc2ece8de168eff746c1ba5/app/helpers/application_helper/button/embedded_ansible.rb#L1-L5

Specifically:

  • !MiqRegion.my_region.role_active?('embedded_ansible')
  • ManageIQ::Providers::EmbeddedAnsible::Provider.count.zero?

Each of those are described below:

Seeding

So seeding for EmbeddedAnsible is located here, and that will get triggered by lib/evm_database.rb here (which is included as part of the [OTHER_SEEDABLE_CLASSES][]). This is triggered on server start by the [MiqServer.start][], so this explains why you didn't see this when running a local server since MiqServer.start is never triggered when doing

$ bin/rails s

So above, I have simulated that by just calling the seed method directly:

ManageIQ::Providers::EmbeddedAnsible.seed

I was initially under the impression that activating the role actually enabled this seeding, but that is I guess not the case. However, I admittedly spent way to much time trying to determine that wasn't the case...

Server roles

So this part also took a bit to figure out...

Again, this is something that is triggered by the MiqServer, and it is part of the monitor_loop:

https://github.com/ManageIQ/manageiq/blob/65e86960ed9f17d3250c23437af28db655a2b633/app/models/miq_server.rb#L342

This does eventually call the role balancing code and activates the needed roles, but it requires using the role data from the "default roles" from the settings, which isn't set here.

This is set and modified via the ops UI, and updates from there eventually trigger this method:

https://github.com/NickLaMuro/manageiq/blob/65e86960ed9f17d3250c23437af28db655a2b633/app/models/miq_server/configuration_management.rb#L9-L14

Which will reload the settings value that has now been updated via the Ops UI. This gets synced to the MiqServer instances as part of the [monitor_workers][] call, which eventually triggers .sync_assigned_roles in [sync_needed?][].

.sync_assigned_roles will eventually call [MiqServer#role=][] to create the AssignedServerRole records to the server, but doesn't activate them.

Note: Up until a little over a week ago, #role= was the only method, but someone (adam) decided to change it to make this explanation even more verbose than it needed to be...

So the MiqServer#monitor_server_roles roles is then in charge of just that, and will activate any of the created roles that need to be activated.

At this point, after these three lines have been called:

MiqServer.my_server.reload_settings # just incase
MiqServer.my_server.sync_assigned_roles
MiqServer.my_server.monitor_server_roles

MiqRegion.my_region.role_active?('embedded_ansible') should now return true and the UI should work as expected.

Should this be much more straight forward in development mode? Yes
Do I have an idea how we would go about doing that? No

But hopefully, for @himdel and others, this explanation gives insight into the "why", and we can determine the "how" for the above from that.

@himdel himdel deleted the embedded_ansible branch January 26, 2021 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants