Skip to content
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.

bool data type is not supported for "toProtoMetric" function #10

Closed
candysmurf opened this issue Aug 18, 2016 · 4 comments
Closed

bool data type is not supported for "toProtoMetric" function #10

candysmurf opened this issue Aug 18, 2016 · 4 comments
Labels

Comments

@candysmurf
Copy link
Contributor

candysmurf commented Aug 18, 2016

bool data is valid as either metric data or ConfigMap (BoolMap). By supplying bool data type to either metric or config, func toProtoMetric caused panic.

@IRCody
Copy link
Contributor

IRCody commented Aug 22, 2016

Can you rephrase this with a more specific example? I don't understand what your saying.

@candysmurf
Copy link
Contributor Author

Input

                     Metric{
                Namespace: NewNamespace("a", "b", "c"),
                Version:   3,
                Timestamp: time.Now(),
                Data:      true,
                Tags:      map[string]string{"label": "abc"},
            },

Output

Errors:

  * /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin/metric_test.go
  Line 66: - unsupported type: %!s(bool=true)
  goroutine 64 [running]:
  panic(0x464640, 0xc820365c90)
    /Users/egu/.gvm/gos/go1.6.2/src/runtime/panic.go:443 +0x4e9
  github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin.toProtoMetric(0xc8202b9170, 0x3, 0x3, 0x3, 0x0, 0x45e040, 0xc820364bb0, 0xc820350570, 0xecf4dc6d0, 0x22eedab, ...)
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin/metric.go:78 +0x82b
  github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin.TestToFromProtoMetric.func1()
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin/metric_test.go:66 +0xce
  github.com/jtolds/gls._m(0x0, 0xc820357240)
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/jtolds/gls/stack_tags.go:39 +0x2b
  github.com/jtolds/gls.markS(0x0, 0xc820357240)
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/jtolds/gls/stack_tags.go:16 +0x2b
  github.com/jtolds/gls.addStackTag(0x0, 0xc820357240)
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/jtolds/gls/stack_tags.go:13 +0x37
  github.com/jtolds/gls.(*ContextManager).SetValues(0xc82015c560, 0xc820350750, 0xc820357240)
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/jtolds/gls/context.go:92 +0x4b3
  github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin.TestToFromProtoMetric(0xc8202b8ea0)
    /Users/egu/.gvm/pkgsets/go1.6.2/snap-2016-06/src/github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin/metric_test.go:83 +0x1f1
  testing.tRunner(0xc8202b8ea0, 0x8dc0d8)
    /Users/egu/.gvm/gos/go1.6.2/src/testing/testing.go:473 +0x98
  created by testing.RunTests
    /Users/egu/.gvm/gos/go1.6.2/src/testing/testing.go:582 +0x892

  goroutine 1 [chan receive]:
  testing.RunTests(0x704b88, 0x8dbfa0, 0x14, 0x14, 0x1)
    /Users/egu/.gvm/gos/go1.6.2/src/testing/testing.go:583 +0x8d2
  testing.(*M).Run(0xc820135ee8, 0x605f58)
    /Users/egu/.gvm/gos/go1.6.2/src/testing/testing.go:515 +0x81
  main.main()
    github.com/intelsdi-x/snap-plugin-lib-go/v1/plugin/_test/_testmain.go:92 +0x117

  goroutine 17 [syscall, locked to thread]:
  runtime.goexit()
    /Users/egu/.gvm/gos/go1.6.2/src/runtime/asm_amd64.s:1998 +0x1

@IRCody IRCody added the bug label Aug 24, 2016
@IRCody
Copy link
Contributor

IRCody commented Aug 24, 2016

Ok. After looking at the code specified in the stack trace I see what you're referencing. Stated in more clear terms, bool is not one of the accepted types for the "Data" field. It is one of the accepted types by protobuf however and there is not any real reason for it not to be added here (other than I forgot to add it). I have a feeling this probably needs to be done on the snap side as well.

I don't see the connection with config. Can you elaborate on that?

Edit: Tagging the snap PR I think this work should be done in: #1150

@IRCody
Copy link
Contributor

IRCody commented Aug 24, 2016

I actually think there is another separate issue with the config here. The config is being dropped on it's way out of the plugin. I'm not sure that behavior makes sense. I can imagine the config being used on later steps in the workflow also.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants