Refactoring Context

[adisky]

Some ideas to refactor context

• Only make available single context function outside package, as with multiple functions it behaves differently
  everywhere
  https://github.com/openshift/odo/blob/master/pkg/odo/genericclioptions/context.go#L31
  add parameters to specify devfile/s2i, or if possible move the devfile/s2i detection to context,
  internally detect if clusterAccess is required for the command or not.

• Avoid using util.LogErrorAndExit(err, "") at every where in the code. All other functions to return proper errors to NewContext function.
  call LogErrorAndExit from NewContext only by checking the errors and responding with proper wrapped message.
  This way we can properly handle errors from cluster(forbidden/timeout) and make it work for those commands that does not require cluster access.

Acceptance Criteria

• Unify Context functions to one function -> NewContext()
  It will also include detection of s2i or devfile component in context and return context accordingly.
• Segregate functions into separate files, so that each utility function visible clearly. (at some places we are rewriting the code that is available as function in context package)
• Make sure some functionalities available only via context route e.g init config/envinfo, resolve app/project and remove their recurring occurrences
• Add Annotations to the commands that does not require cluster access and ignore client initialization error for them.
• Consolidate error handling at one place in the context package to have consistency in errors returned to the users.
• Move the localConfigProvider interface to some common package and extend it in way that all localConfig/Envinfo data get accessed through it.

[metacosm]

There shouldn't be any parameters for devfile/s2i/whatever: NewContext should do the detection automatically, the whole point is to isolate things so that clients don't need to know or care the type of components they're dealing with.

[adisky]

There shouldn't be any parameters for devfile/s2i/whatever: NewContext should do the detection automatically, the whole point is to isolate things so that clients don't need to know or care the type of components they're dealing with.

agreed, no parameters in NewContext autodetect s2i/devfile, requirement of cluster access and remove existing parameters as well ignoreMissingConfiguration, createAppIfNeeded

[adisky]

Document for context refactoring https://docs.google.com/document/d/1qiTTzR43jX_1igvw3oXtGJFjGVV7HeFRc8B_x37za90/edit#

[metacosm]

@adisky I've added some comments on the document, please also see: #4057 (comment)

[adisky]

@metacosm Thanks for your suggestions, I am trying to understand those

Pasting here the interface you suggested for context

package context

type Context interface {
	GetComponents() map[string]Component
	GetCurrentComponent() Component
	GetApplications() map[string]Application
	GetCurrentApplication() Application
	GetCurrentPath() string
	GetOptions() map[string]string // access command flags if needed
	GetClient() (Client, error)
	SetClient(client Client) error
}

don't you think it would be expensive to parse/evaluate with each call?

or you want to suggest, calculate and store once and give field access through functions?

type Context struct {
  application     string
  project            string
  client             Client
  options map[string] string
}

func GetContext(command  *cobra.Command) *Context {

}

func (context *Context)GetApplication() string{
}

func (context *Context)GetProject() string {
}

// all other options (e.g maxcpu, mincpu, storage for s2i or  e.g. runmode, pushcomand for devfile for devfile)
func(context *Context) GetOptions() map[string]string {

}

[metacosm]

@metacosm Thanks for your suggestions, I am trying to understand those

don't you think it would be expensive to parse/evaluate with each call?

What makes you think that things would be evaluated each time?

or you want to suggest, calculate and store once and give field access through functions?

The implementation of each function might depend on what needs to be done. That's the beauty of interfaces: you can do what you want and the calling code doesn't need to care. If you don't want to compute a value as soon as you create the underlying object, then you can defer until you actually need that value. If you can cache things, you can do it. If you need to re-compute things based on the current state of the application, you can also do it. None of these things can be done if your client code accesses the struct directly.

[adisky]

@metacosm Thanks for your suggestions, I am trying to understand those
don't you think it would be expensive to parse/evaluate with each call?

What makes you think that things would be evaluated each time?

I got confused from your comments on the doc (taken not expose struct as not create) :)