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

Add new class ServiceContainerTemplate. #15429

Merged
merged 3 commits into from
Jul 13, 2017

Conversation

lfu
Copy link
Member

@lfu lfu commented Jun 22, 2017

Add new class ServiceContainerTemplate for container template provisioning.

Includes on ManageIQ/manageiq-providers-openshift#27.
Depends on #15475.

https://www.pivotaltracker.com/story/show/134027413

@miq-bot assign @gmcculloug
@miq-bot add_label enhancement, services, providers/containers

cc @bzwei

$log.log_hashes(opts)

params = process_parameters(opts[:parameters])
@created_objects = container_template.instantiate(params, opts[:container_project_name])
Copy link
Contributor

Choose a reason for hiding this comment

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

It is not safe to use an instance variable.

@bzwei
Copy link
Contributor

bzwei commented Jun 23, 2017

@gmcculloug @lfu Evidently we need to remember created objects between steps in the state machine, and more importantly we are always requested to tell the user what objects are created in the provisioning.
There can be two approaches:

  1. Directly add each object as a resource to the service.
  2. Create a stack object and add each object as a resource to the stack. Add the stack as a resource to the service.

Approach No 2 is the way we handle Ansible provisioning. Although Ansible Tower job is a true object in provider, we never collect jobs through refresh. The job is directly created in VMDB. I see the similarity here.

# :dialog option should specify the project name, either an existing project or a new project name
dialog_options = options[:dialog]
existing = overrides.delete(:existing_project_name) || dialog_options['dialog_existing_project_name']
new = overrides.delete(:new_project_name) || dialog_options['dialog_new_project_name']
Copy link
Member

Choose a reason for hiding this comment

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

@lfu Avoid using keywords as variable names and would also expect this to be a more descriptive name. Suggest new_project_name

end

def stack(action)
service_resources.find_by(:name => action, :resource_type => 'OrchestrationStack').try(:resource)
Copy link
Member

Choose a reason for hiding this comment

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

@lfu @bzwei Are there going to be different stacks based on the action? I would expect there would only ever be one stack connected to service_resources.

Copy link
Contributor

Choose a reason for hiding this comment

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

right, we don't need to distinguish action. There is only one stack.

@gmcculloug
Copy link
Member

@bzwei I am ok with the stack approach here, is there a container object this would normally be representing? What type of objects/data would you normally expect to represent as part of the stack?


def check_completed(action)
done = stack(action).provider_objects.all? { |obj| obj.resource_category.constantize.find_by(:name => obj.name) }
message = done ? "completed" : "not completed yet"
Copy link
Member

Choose a reason for hiding this comment

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

Do we have another message string we use besides "not completed yet"? I'm thinking "in progress" but we should be consistent here if possible.

Copy link
Member Author

Choose a reason for hiding this comment

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

There is no standard incomplete message. So I took "in progress".

@lfu lfu force-pushed the service_container_template branch 2 times, most recently from 837e02b to 324abeb Compare June 27, 2017 14:58
@bzwei
Copy link
Contributor

bzwei commented Jun 27, 2017

@lfu There are a few items missing from your implementation. I'll work with you offline.

@lfu
Copy link
Member Author

lfu commented Jun 27, 2017

@gmcculloug Container template may contain objects that would be created during the provisioning. An Orchestration stack is added into the service as an virtual layer to keep track of the created container objects. A list of these objects would be returned by container_template#instantiate as soon as the call is done. But these objects only appear in VMDB later after provider refresh.

Here is an example of the created container object.

{"apiVersion"=>"v1", "kind"=>"Route", "metadata"=>{"name"=>"dotnet-example"}, "spec"=>{"host"=>"", "to"=>{"kind"=>"Service", "name"=>"dotnet-example"}}}

@gmcculloug
Copy link
Member

Another consideration around using stacks is retirement. The base model includes RetirementManagement but I do not think we have anything to do here. Does retirement need to be undefined for the subclassed model ManageIQ::Providers::ContainerManager::OrchestrationStack?

What would happen if retire_now was called on this instance?

@bzwei
Copy link
Contributor

bzwei commented Jun 27, 2017

@gmcculloug Retirement should delete the objects in the provider and then the stack in VMDB

@lfu lfu force-pushed the service_container_template branch from 324abeb to 51237c3 Compare June 27, 2017 23:24
end

def stack
service_resources.find_by(:name => 'Provision', :resource_type => 'OrchestrationStack').try(:resource)
Copy link
Contributor

Choose a reason for hiding this comment

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

To be consistent do you want to use ResourceAction::PROVISION?

params
end

def get_job_options(action)
Copy link
Contributor

Choose a reason for hiding this comment

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

why job option? there is no concept of job in contain template provisioning.

"#{action.downcase}_job_options".to_sym
end

def parameters_from_dialog
Copy link
Contributor

Choose a reason for hiding this comment

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

consider to make a mix-in to be shared by a few similar service classes.

@lfu lfu force-pushed the service_container_template branch from 51237c3 to 8d7902c Compare June 28, 2017 14:33
def check_completed(action)
return [true, 'not supported'] unless action == ResourceAction::PROVISION

done = stack.resources.all? do |obj|
Copy link
Contributor

Choose a reason for hiding this comment

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

move the logic to stack.raw_status method.

@lfu lfu force-pushed the service_container_template branch 4 times, most recently from 29be82b to 30d479e Compare July 5, 2017 19:04
@lfu lfu force-pushed the service_container_template branch from 30d479e to 990c224 Compare July 7, 2017 16:07
@lfu
Copy link
Member Author

lfu commented Jul 10, 2017

Travis test failure is due to the dependency on the changes in ManageIQ/manageiq-providers-openshift#27.

@lfu lfu force-pushed the service_container_template branch from 990c224 to a26e9f7 Compare July 11, 2017 21:18
@gmcculloug
Copy link
Member

@bzwei Can you give this one last review.

@lfu lfu force-pushed the service_container_template branch from a26e9f7 to 9c87802 Compare July 12, 2017 14:21
private :add_provider_objects

def add_provider_object(object)
raise _("Provision with container template [#{container_template.name}] failed: #{object}") if object[:kind].blank?
Copy link
Contributor

Choose a reason for hiding this comment

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

can we not raise an error but mark the resource status failure, and stack status failure?

raise MiqException::MiqOrchestrationProvisionError, err.to_s, err.backtrace
end

def self.status_class
Copy link
Contributor

Choose a reason for hiding this comment

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

any particular reason the status needs a subclass?

@lfu lfu force-pushed the service_container_template branch from 9c87802 to ebc3a91 Compare July 12, 2017 18:50
belongs_to :container_template, :foreign_key => :orchestration_template_id, :class_name => "ContainerTemplate"

def self.create_stack(container_template, params, project_name)
new(:name => container_template.name,
Copy link
Contributor

Choose a reason for hiding this comment

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

I saw the other PR you created OrchestrationStack for OpenShift and its Status class. It then makes sense to revert your earlier code to use the Status subclass, but here you need to create the stack instance with the right class.

miq_class.nil? || miq_obj
end

update_attributes(:status => 'succeeded') if done
Copy link
Contributor

Choose a reason for hiding this comment

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

need to update_attributes for the case in line 23.

$log.log_hashes(opts)

params = process_parameters(opts[:parameters])
new_stack = ManageIQ::Providers::Openshift::ContainerManager::OrchestrationStack.create_stack(container_template, params, opts[:container_project_name])
Copy link
Contributor

Choose a reason for hiding this comment

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

Derive the full OrchestrationStack class name from container manager.

@lfu lfu force-pushed the service_container_template branch from ebc3a91 to e8669a5 Compare July 13, 2017 14:05
@lfu lfu force-pushed the service_container_template branch from e8669a5 to b86af5a Compare July 13, 2017 14:18
@miq-bot
Copy link
Member

miq-bot commented Jul 13, 2017

Checked commits lfu/manageiq@0ec3330~...b86af5a with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
5 files checked, 0 offenses detected
Everything looks fine. 🏆

@lfu
Copy link
Member Author

lfu commented Jul 13, 2017

@bzwei @gmcculloug Please review.

@bzwei
Copy link
Contributor

bzwei commented Jul 13, 2017

Looks good.

@gmcculloug gmcculloug merged commit a50d793 into ManageIQ:master Jul 13, 2017
@gmcculloug gmcculloug added this to the Sprint 65 Ending Jul 24, 2017 milestone Jul 13, 2017
@lfu lfu deleted the service_container_template branch October 16, 2017 20:14
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.

4 participants