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 registry for prospectors #4980

Merged
merged 2 commits into from Aug 25, 2017
Merged

Conversation

kvch
Copy link
Contributor

@kvch kvch commented Aug 23, 2017

From now on it is possible to register prospectors in init functions, just like modules in Metricbeat.

Example:

func init() {
	err := prospectors.Register("log", NewProspector)
	if err != nil {
		panic(err)
	}
}

General prospector functions were moved to prospectors package (for a lack of a better name). In prospector.go new prospectors should be imported to register.

"github.com/elastic/beats/filebeat/registrar"
"github.com/elastic/beats/libbeat/cfgfile"
"github.com/elastic/beats/libbeat/common"
"github.com/elastic/beats/libbeat/common/cfgwarn"
"github.com/elastic/beats/libbeat/logp"

_ "github.com/elastic/beats/filebeat/prospector"
Copy link

@urso urso Aug 23, 2017

Choose a reason for hiding this comment

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

in other places we use something like github.om/elastic/beats/<beatname>/include/list.go, to build/provide an import list of 'plugins'.

It would be nice not to have a package named prospector and another one named prospectors. Rather have on prospector package only if possible.

Copy link
Member

Choose a reason for hiding this comment

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

Here is for example the script that generates the imports for metricbeat: https://github.com/elastic/beats/blob/master/metricbeat/scripts/generate_imports.py

"github.com/elastic/beats/libbeat/logp"
)

type ProspectorFactoryData struct {
Copy link

Choose a reason for hiding this comment

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

how about naming it 'Context' or 'Environment'?

Keep in mind, the package names is part of a type its full. Try to reduce stuttering if possible. e.g.

prospectors.ProspectorFactory can be minimized to prospectors.Factory. And prospectors.ProspectorFactoryData to prospectors.Context.

BeatDone chan struct{}
}

type ProspectorFactory func(config *common.Config, outletFactory channel.OutleterFactory, data ProspectorFactoryData) (Prospectorer, error)
Copy link

Choose a reason for hiding this comment

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

appropos naming, I will not complain if you rename channel.OutleterFactory to channel.Factory ;)

@urso
Copy link

urso commented Aug 23, 2017

Just a few minor comments. All in all LGTM

@@ -49,6 +50,13 @@ func NewProspector(cfg *common.Config, outletFactory channel.OutleterFactory) (*
return p, nil
}

func init() {
Copy link
Member

Choose a reason for hiding this comment

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

Could we always put the init functions on the top after the imports? I kind of like them at the top as it becomes also obvious they are executed first.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

It's really great to have this. This will give us much more flexibility. I think we need to improve / fix the naming over time and it will probably become more obvious on what it should be when we start working with it.

@kvch kvch force-pushed the refactor/prospector-plugin branch from 7e00cfe to f51bc23 Compare August 23, 2017 19:48
@kvch kvch added the in progress Pull request is currently in progress. label Aug 23, 2017
@kvch
Copy link
Contributor Author

kvch commented Aug 23, 2017

I addressed the notes. However, I am not satisfied with the package structure and names, but so far I don't have better idea.

I also added renaming channel.OutleterFactory to channel.Factory.

@@ -0,0 +1,8 @@
package include
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 suggest to move this directly under filebeat instead of prospectr as we ave it in other projects.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

LGTM. I think we can keep iterating on the naming to get it right. I suggest to merge this feature now as it will give us new flexibility in adding prospector types.

@ruflin
Copy link
Member

ruflin commented Aug 24, 2017

@kvch There seem to be some issues with the tests. Ping me when you got the build green.

@kvch kvch force-pushed the refactor/prospector-plugin branch 2 times, most recently from cf521c9 to e6eba4c Compare August 24, 2017 11:40
@kvch kvch removed the in progress Pull request is currently in progress. label Aug 24, 2017
@urso
Copy link

urso commented Aug 24, 2017

We still need the prospector and prospectors packages each? Given the imports moved to filebeat/include/list.go, there should be no more circular dependencies.

@kvch
Copy link
Contributor Author

kvch commented Aug 24, 2017

I will remove it \o/

@kvch kvch force-pushed the refactor/prospector-plugin branch from e6eba4c to 9fae267 Compare August 24, 2017 13:15
@kvch
Copy link
Contributor Author

kvch commented Aug 24, 2017

I had to rename Factory in factory.go which is a struct that contains data of the Registrar. Its new name is RegistrarContext. So outside the package its name is prospector.RegistrarContext and the concrete factories of prospectors type can be prospector.Factory.

@kvch
Copy link
Contributor Author

kvch commented Aug 24, 2017

jenkins, test it

@ruflin
Copy link
Member

ruflin commented Aug 25, 2017

@urso Never saw this Jenkins error before:

.....F........S.SS..SS........
======================================================================
FAIL: Checks CLI overwrite actually overwrites some config variable by
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\jenkins\workspace\elastic+beats+pull-request+multijob-windows\beat\libbeat\label\windows\src\github.com\elastic\beats\libbeat\tests\system\test_base.py", line 57, in test_invalid_config_cli_param
    proc.check_kill_and_wait()
  File "C:\Users\jenkins\workspace\elastic+beats+pull-request+multijob-windows\beat\libbeat\label\windows\src\github.com\elastic\beats\libbeat\tests\system\beat\beat.py", line 89, in check_kill_and_wait
    return self.check_wait(exit_code=exit_code)
  File "C:\Users\jenkins\workspace\elastic+beats+pull-request+multijob-windows\beat\libbeat\label\windows\src\github.com\elastic\beats\libbeat\tests\system\beat\beat.py", line 78, in check_wait
    exit_code, actual_exit_code)
AssertionError: Expected exit code to be 0, but it was 1

As the error is not related to this change, I think we can move forward here.

@ruflin ruflin merged commit 366a584 into elastic:master Aug 25, 2017
@ruflin
Copy link
Member

ruflin commented Aug 25, 2017

@kvch Great job on this one. Lets now do small interations on top of it to potentially improve handling and even simplify things further.

@kvch kvch mentioned this pull request Aug 25, 2017
3 tasks
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.

None yet

3 participants