Adds cloud_services table

[petrblaho]

This table will be used for CloudService model.

EDIT (@blomquisg): Pulled from #7996

[Ladas]

probably adding scheduling_enabled or disabled, based on what it means

[petrblaho]

We have scheduling_disabled_reason there too... so this push me to using scheduling_disabled but I think scheduling_enabled seems more appropriate.... what do you think?

Update: renamed to scheduling_disabled

[Ladas]

maybe I would call it host_name and zone_name, but it can be like it is now. Looks good to me now 👍

[blomquisg]

What are source and binary? These names are too ambiguous right now. If you give me a decent explanation, I could help with a better column name.

[Fryguy]

Expanations are here for source and here for binary. I have a comment on binary below in this PR thread

[blomquisg]

@petrblaho I think I asked this in another PR (not sure which)...

What's the difference between a cloud_service and a system_service?

In other words, could the fields being added to this new cloud_service table, just be added to system_service and we use that instead?

I'm not sure I understand the distinction here.

[blomquisg]

What's the difference between a cloud_service and a system_service?

Answering my own question...

Just talked to @Ladas about this. He said that cloud_service details actually come from the OSP Cloud REST API. While the system_service details come from the the OSP Infra SSA.

We would have a CloudService available on the cloud side regardless of whether the there's a corresponding OSP Infra connected to provide the SystemService.

[petrblaho]

@blomquisg I think answers for your inline questions can be found in discussion at #7996 - @Fryguy already asked similar questions.

And as I can see you already has the answer for CloudService vs. SystemService.

[petrblaho]

@blomquisg zonename, hostname and binary are coming from Fog Compute Service model - so I need to store that to match CloudService with AvailabilityZone, Host and SystemService from MIQ models.

[Fryguy]

Aside from my comments, everything else looks fine, though I do question the binary column name. I get that it matches fog's interface, but when I hear "binary" in a database I think of the binary column type...I'm not thinking about an executable on the command line. Maybe executable or cli might be a better name choice. @Ladas @blomquisg thoughts?

EDIT: My thoughts on binary might be tainted by the fact that we already have a method called binary on the binary_blobs table, but maybe that's just me 😉

[petrblaho]

@Fryguy executable_name - what do you think?

And I should probably rename zonename to availability_zonename...

[blomquisg]

@Fryguy executable_name - what do you think?

I like this better.

And I should probably rename zonename to availability_zonename...

availability_zone_name , maybe? ... I know it's inconsistent with hostname ...

[Fryguy]

yeah exectuable_name sounds great...very clear.

[blomquisg]

Summary of a conversation from https://gitter.im/ManageIQ/manageiq/providers

• Keep hostname because the user wants to see what host the service is on, and there might not be an underlying OSP Infra layer to dereference cloud_service.host.hostname.
• Remove availability_zone_name because this is a cloud object, and should definitely have a relationship in cloud_service, so cloud_service.availability_zone.name should always work.
• Rename binary to executable_name for clarity.

Thanks @petrblaho !!

[Fryguy]

Looks great @petrblaho ...if you could align the symbols for style, then this is good to go.

[Fryguy]

LGTM 👍 will merge when green.

[miq-bot]

Checked commit petrblaho@c99b526 with ruby 2.2.3, rubocop 0.37.2, and haml-lint 0.16.1
1 file checked, 0 offenses detected
Everything looks good. 👍