Introduce storage factory framework and composable CLI by yurishkuro · Pull Request #625 · jaegertracing/jaeger

yurishkuro · 2018-01-01T03:55:03Z

Main changes:

deprecate --span-storage.type CLI flag
instead use env variable SPAN_STORAGE (and optionally DEPENDENCY_STORAGE)
CLI options only include flags relevant to the selected storage type(s)
introduce storage.Factory interface for creating different storage components like spanstore.Reader
introduce meta-factory plugin/storage.Factory that instantiates concrete factories based on the above env vars
concrete factories may implement plugin.Configurable interface that allows them to define custom CLI flags and to be initialized from Viper
removed a lot of duplicated code for storage initialization in collector/query/standalone
added new cobra command env that prints help about configuring via env vars

Related to #422, #608

coveralls · 2018-01-01T07:31:03Z

Coverage decreased (-0.3%) to 99.65% when pulling 7fc4b69 on storage-factory into d7d1c74 on master.

coveralls · 2018-01-01T21:50:27Z

Coverage decreased (-1.04%) to 98.957% when pulling b024a6d on storage-factory into d7d1c74 on master.

coveralls · 2018-01-01T22:10:40Z

Coverage remained the same at 100.0% when pulling e1891fe on storage-factory into d7d1c74 on master.

coveralls · 2018-01-02T05:14:20Z

Coverage remained the same at 100.0% when pulling 988f748 on storage-factory into d7d1c74 on master.

black-adder · 2018-01-02T15:55:03Z

plugin/storage/factory.go

+	if f.depStoreType == "" {
+		f.depStoreType = f.spanStoreType
+	}
+	uniqueTypes := map[string]struct{}{


what black magic is this?

https://play.golang.org/p/nlo0NL_M0M2

your example fails with explicit literals, but uq works correctly.

I don't understand the why though, at runtime uq is also just literals no? so uq should fail too?

Well, it doesn't fail if you remove uq2 from the example. If I were to guess, it's due to compiler optimization. When you init the map with the actual literals, compiler can check for uniqueness, and it's a reasonable behavior to fail since such statement is more likely to be a typo. But when you init with dynamic values, compiler cannot check anything, and the initialization is reduced to a sequence of m[k] = v.

black-adder

pretty nice. Things like this seem like they're a breaking change if someone had written their own main function to startup Jaeger. Do we need to cut a major release for things like this?

black-adder · 2018-01-02T15:59:34Z

storage/factory.go

+// See also
+//
+// plugin.Configurable
+type Factory interface {


maybe a Close() function too?

no use case for it right now, if we need it in the future I'd rather use io.Closer

black-adder · 2018-01-02T16:29:17Z

storage/factory.go

@@ -0,0 +1,44 @@
+// Copyright (c) 2017 Uber Technologies, Inc.


I can forsee us needing to support other storage factories like SamplingFactory. Would that mean we keep adding functions to this interface or create a new interface for each factory? If the latter, wouldn't it make more sense to split this factory into SpanFactory and DependencyFactory?

I guess the question is - how likely is it for someone to run SpanStore on C, DepsStore on ES, SamplingStore on smth else, etc.?

We could split the interfaces, but their implementations would still need to be in a single struct, both for meta-factory and for individual backends.

black-adder · 2018-01-02T16:33:51Z

plugin/storage/factory.go

+	if f.depStoreType == "" {
+		f.depStoreType = f.spanStoreType
+	}
+	uniqueTypes := map[string]struct{}{


I don't understand the why though, at runtime uq is also just literals no? so uq should fail too?

yurishkuro · 2018-01-02T17:16:06Z

Things like this seem like they're a breaking change if someone had written their own main function to startup Jaeger. Do we need to cut a major release for things like this?

A bit of a philosophical question. Strictly speaking, Jaeger is distributed in binary form, we haven't made commitment to preserve the internal APIs. Yes, some people may have forked and extended at the source level, because we don't have a good plugin framework, but I think these changes actually make it easier to extend, even if they are breaking. And this change is a step towards supporting external plugins.

yurishkuro · 2018-01-03T15:35:58Z

@objectiser @pavolloffay what do you think?

pavolloffay · 2018-01-03T15:41:01Z

I am looking at this now, so far it looks fine. Somehow I wanted to skip env var but I don't have a good alternative solution for it

coveralls · 2018-01-03T15:49:44Z

Coverage remained the same at 100.0% when pulling b11efc9 on storage-factory into 544fb43 on master.

objectiser · 2018-01-03T15:57:15Z

Haven't looked in detail at the code but the general approach looks good.

In terms of the env var vs command line - although viper is used to generally manage the command line options, couldn't a hard coded solution just be used to scan for this one command line option (if not provided via env var), just to keep a consistent approach with all options?

pavolloffay · 2018-01-03T15:49:12Z

cmd/standalone/main.go


 // standalone/main is a standalone full-stack jaeger backend, backed by a memory store
 func main() {
+	if os.Getenv(storage.SpanStorageEnvVar) == "" {


Isn't dependency storage missing?

it defaults to span storage, I will add a comment

pavolloffay · 2018-01-03T15:50:53Z

cmd/standalone/main.go

+	if os.Getenv(storage.SpanStorageEnvVar) == "" {
+		os.Setenv(storage.SpanStorageEnvVar, "memory")
+	}
+	storageFactory, err := storage.NewFactory()


What about passing values of SpanStorageType and DependencyStorageType to the factory and abstract the factory of env vars?

the main idea is to remove the dispatching logic from main(). It's certainly possible to de-couple the actual dispatching factory from the source of storage types parameters, e.g. something like

storageFactory, err := storage.NewFactory(storage.StorageTypesFromEnv())

I see, the code snippet looks better.

yurishkuro · 2018-01-03T18:19:05Z

In terms of the env var vs command line - although viper is used to generally manage the command line options, couldn't a hard coded solution just be used to scan for this one command line option (if not provided via env var), just to keep a consistent approach with all options?

@objectiser yes, we can manually scan the os.Args[1:] for a fixed set of switches. However, right now we have a convention that all cmd line switches can also be defined in a config file, this will no longer be true without even more hacking, e.g. searching for the --config-file switch manually as well and reading it before cmd.Execute() is called. Then why not do the same for log-level, etc. - seems like a slippery road.

Another interesting alternative might be to converge to a single binary where query, collector etc. are just commands, e.g. jaeger collector [switches]. I am not sure, but it might be possible to have the so-called "global" flags parsed before the flags for the sub-commands are fully defined.

coveralls · 2018-01-03T22:56:32Z

Coverage remained the same at 100.0% when pulling 34a1380 on storage-factory into b0d3fa9 on master.

coveralls · 2018-01-04T15:48:34Z

Coverage remained the same at 100.0% when pulling 4661cb6 on storage-factory into 32bc1b7 on master.

yurishkuro · 2018-01-06T02:44:12Z

I ran a bunch of other experiments and still think env vars are the best option, because:

CLI flags are parsed once, whether or not we use subcommands with spf13/cobra. So if we want storage X to be specified on the CLI, all options for X have to be pre-declared as flags before the arguments are parsed.
it is possible to parse the args twice, first by using a throw-away flag.FlagSet that will only read flags like storage type, plugin dir, log-level, etc., and then use their values to define other flags and run the cobra command normally. However, this approach has a big downside. There will almost always be parse errors since we can only define flags we know about at the first pass. So if someone makes a typo in the --span-storage.type flag, flagSet.Parse() will report an error that we will need to (silently) ignore, a very unexpected behavior for CLI flags.

coveralls · 2018-01-06T04:27:10Z

Coverage remained the same at 100.0% when pulling 000e45d on storage-factory into 32bc1b7 on master.

coveralls · 2018-01-06T20:38:01Z

Coverage remained the same at 100.0% when pulling 8b41562 on storage-factory into d2f85a4 on master.

Signed-off-by: Yuri Shkuro <ys@uber.com>

coveralls · 2018-01-07T18:00:10Z

Coverage remained the same at 100.0% when pulling db3913a on storage-factory into d2f85a4 on master.

Signed-off-by: Yuri Shkuro <ys@uber.com>

coveralls · 2018-01-07T20:16:49Z

Coverage remained the same at 100.0% when pulling 67a1d67 on storage-factory into d2f85a4 on master.

yurishkuro · 2018-01-07T20:43:21Z

I ended up adding manual parsing for the deprecated switch, which will provide better backwards compatibility, but it would still not work with the existing Kubernetes templates since they are actually using config files

yurishkuro requested review from black-adder and pavolloffay January 1, 2018 03:55

yurishkuro requested a review from vprithvi as a code owner January 1, 2018 03:55

ghost assigned yurishkuro Jan 1, 2018

ghost added the review label Jan 1, 2018

yurishkuro force-pushed the storage-factory branch from 32e84fa to 7fc4b69 Compare January 1, 2018 05:57

yurishkuro changed the title ~~[WIP] Storage factory framework~~ Introduce storage factory framework and composable CLI Jan 1, 2018

yurishkuro mentioned this pull request Jan 1, 2018

Introduce a framework for components lifecycle #627

Open

black-adder reviewed Jan 2, 2018

View reviewed changes

yurishkuro force-pushed the storage-factory branch from 988f748 to b11efc9 Compare January 3, 2018 15:36

pavolloffay reviewed Jan 3, 2018

View reviewed changes

yurishkuro force-pushed the storage-factory branch from b11efc9 to 34a1380 Compare January 3, 2018 22:40

yurishkuro force-pushed the storage-factory branch from 34a1380 to 4661cb6 Compare January 4, 2018 15:35

black-adder approved these changes Jan 5, 2018

View reviewed changes

yurishkuro force-pushed the storage-factory branch from b0dcb36 to 00e6797 Compare January 6, 2018 19:15

Introduce storage factory framework and composable CLI

db3913a

Signed-off-by: Yuri Shkuro <ys@uber.com>

yurishkuro force-pushed the storage-factory branch from 8b41562 to db3913a Compare January 7, 2018 17:47

Support previous command line option as deprecated

67a1d67

Signed-off-by: Yuri Shkuro <ys@uber.com>

yurishkuro merged commit 8db7a11 into master Jan 7, 2018

ghost removed the review label Jan 7, 2018

This was referenced Jan 8, 2018

Use SPAN_STORAGE env var instead of deprecated command line option jaegertracing/jaeger-kubernetes#61

Closed

Use SPAN_STORAGE env var instead of deprecated command line option jaegertracing/jaeger-openshift#45

Closed

black-adder mentioned this pull request Jan 9, 2018

💾 Additional storage backends #638

Open

20 tasks

yurishkuro mentioned this pull request Jan 11, 2018

Consider renaming SPAN_STORAGE env var to SPAN_STORAGE_TYPE #642

Closed

yurishkuro deleted the storage-factory branch May 6, 2018 19:46

clubanderson mentioned this pull request Mar 11, 2026

🌱 jaeger: How to support plugins kubestellar/console-kb#564

Merged

		@@ -0,0 +1,44 @@
		// Copyright (c) 2017 Uber Technologies, Inc.

Conversation

yurishkuro commented Jan 1, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coveralls commented Jan 1, 2018

Uh oh!

coveralls commented Jan 1, 2018

Uh oh!

coveralls commented Jan 1, 2018

Uh oh!

coveralls commented Jan 2, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

black-adder left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yurishkuro commented Jan 2, 2018

Uh oh!

yurishkuro commented Jan 3, 2018

Uh oh!

pavolloffay commented Jan 3, 2018

Uh oh!

coveralls commented Jan 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

objectiser commented Jan 3, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yurishkuro commented Jan 3, 2018

Uh oh!

coveralls commented Jan 3, 2018

Uh oh!

coveralls commented Jan 4, 2018

Uh oh!

yurishkuro commented Jan 6, 2018

Uh oh!

coveralls commented Jan 6, 2018

Uh oh!

coveralls commented Jan 6, 2018

Uh oh!

coveralls commented Jan 7, 2018

Uh oh!

coveralls commented Jan 7, 2018

Uh oh!

yurishkuro commented Jan 7, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

yurishkuro commented Jan 1, 2018 •

edited

Loading

coveralls commented Jan 3, 2018 •

edited

Loading