Sensu-install missing on docker image

[billm]

same issue. different issue? Config is installed at /etc/sensu/conf.d/plivosms_handler.json

using --map_go_event_into_ruby

The config is just the boilerplate from the tronfu repo with numbers and auth tokens changed.

{"assets":["sensu/sensu-ruby-runtime","asachs01/sensu-plugins-plivo"],"component":"pipelined","handler":"plivo","level":"info","msg":"event pipe handler executed","namespace":"default","output":"/var/cache/sensu/sensu-backend/a07bcfa3cca17c108e77e00a79d78a2d604ce3a5f1595b6bb535ceb6c7a244add6e0e62b81977be86eac2b94d214e0833fe3c0f0901f9a437efdd12f3e2d2da4/lib/ruby/2.4.0/bundler/gems/sensu-plugins-plivo-4b0b9839c685/bin/handler-plivosms.rb:66:in `handle': undefined method `[]' for nil:NilClass (NoMethodError)\n\tfrom /var/cache/sensu/sensu-backend/a07bcfa3cca17c108e77e00a79d78a2d604ce3a5f1595b6bb535ceb6c7a244add6e0e62b81977be86eac2b94d214e0833fe3c0f0901f9a437efdd12f3e2d2da4/lib/ruby/2.4.0/gems/sensu-plugin-4.0.0/lib/sensu-handler.rb:91:in `block in \u003cclass:Handler\u003e'\n","status":1,"time":"2020-01-09T00:32:46Z"}

[jspaleta]

hmm same error.

I think your json config is subtly invalid.

II just cut it back to

{
 "plivosms":{"id":"xxxxx"} 
}

i get past that error to a different error associated with a missing attribute

[billm]

huh… yeah I redid the config now I get. Makes me wonder if this code even works too.

{"assets":["sensu/sensu-ruby-runtime","asachs01/sensu-plugins-plivo"],"component":"pipelined","handler":"plivo","level":"info","msg":"event pipe handler executed","namespace":"default","output":"/var/cache/sensu/sensu-backend/a07bcfa3cca17c108e77e00a79d78a2d604ce3a5f1595b6bb535ceb6c7a244add6e0e62b81977be86eac2b94d214e0833fe3c0f0901f9a437efdd12f3e2d2da4/lib/ruby/2.4.0/bundler/gems/sensu-plugins-plivo-4b0b9839c685/bin/handler-plivosms.rb:93:in `handle': uninitialized constant PlivoSMS::RestAPI (NameError)\nDid you mean?  RestClient\n\tfrom /var/cache/sensu/sensu-backend/a07bcfa3cca17c108e77e00a79d78a2d604ce3a5f1595b6bb535ceb6c7a244add6e0e62b81977be86eac2b94d214e0833fe3c0f0901f9a437efdd12f3e2d2da4/lib/ruby/2.4.0/gems/sensu-plugin-4.0.0/lib/sensu-handler.rb:91:in `block in \u003cclass:Handler\u003e'\n","status":1,"time":"2020-01-09T00:59:47Z"}

{                                                                                                    
  "plivosms":{                                                                                       
    "id":"xxx",                                                                     
    "token":"xxx",                                              
    "number":"xxx",                                                                           
    "recipients":{                  
      "xxx": {                                                                        
        "subscriptions":[ "proxy" ],                                                          
        "checks":["foo"],                                                                     
        "cutoff": 1                                                                           
      }
    }
  }
}

[jspaleta]

I don’t understand your last error… its not something i’m seeing here locally doing manually tests of the gem.
But regardless,

This handler won’t work without an update to its logic for Sensu Go
it’s making use of the Sensu Core event “subscribers” attribute
for some reason… which does not exist in the new event model.

So this handler has to be updated to work with Sensu Go.

It looks like subscribers was something I missed in the mapping logic.

I think it should translate into “subscriptions” now but I’ll need to double check.

Are you in contact with the upstream author? This plugin is outside of the sensu-plugins collection so I don’t have access to fix this directly.

[billm]

No I’m not in contact with the upstream author. This isn’t even the plugin I want to use directly. I have a much much simpler custom written plivo plugin that was working with sensu-classic but I was having the same handler error I was having with this one.

If I could figure out how to package it up like you’ve done here I may be able to get that to work, but honestly I’m losing patience. F*cking 3 days of work to get a 25 line ruby script to execute. It’s just too damn complicated. I think it might be time for us to call time of death on sensu-go.

[jspaleta]

So I’m finally getting the last error… using the handler manually…

my comment about subscribers was a red herring.

The last error seems to indicates ot me this handler was written against a very old plivo ruby gem and the plivo module as changed syntax.

I think I have a working version locally with the necessary changes…im getting auth errors now.

[billm]

oh! Sweet. Are you going to push that to bonsai?

[jspaleta]

Packaging ruby up as assets is a little complicated, because of the runtime deps and the need for the ruby environment.

Assets are an advanced usage pattern, but if the ruby script is working you can get things working an a ruby env in the client just using a more traditional gem install process.

[billm]

also how are you testing the handler manually? I think I’m having extra trouble here because I’m testing in the alpine image. AFAICT I can’t test it manually there, since there’s no ruby.

[jspaleta]

well that’s the rub right… if I put this into bonsai myself without being an active user of the service, this is going to probably bitrot…i’m not sure that’s the best thing.

What we need is someone invested in the service integration to take on primary maintainership.

[billm]

should I volunteer here?

[jspaleta]

no im not manually testing in alpine…no. I don’t use alpine day to day…so i don’t trust my ability to troubleshoot it.
Alpine is…fascinatingly…different from all the other linuxes…making some interesting choices like using musl for libc and ressl for ssl by default…

[jspaleta]

I’ll put it on github with all the automation necessary to get this working, but I’m not sure I want to maintain it my bonsai namespace as a thing people depend on. My bonsai namespace is very much “here by dragons” stuff… its my brand.

I’ll get it as far as knowing it builds I can test against the free plivo acount…but…beyond that… i dont want to overpromise

[billm]

• Version 0.0.1: cannot find a Bonsai configuration file

there is a .bonsai.yml file. I guess I don’t understand what how or what builds all of the various arch artifacts.

I hate having to beg for a 1 line change but apparently that’s where I’m at since I can’t seem to get this to build myself and hosted in bonsai.

@aaronsachs:

 plivo = RestAPI.new(auth_id, auth_token)
 plivo = Plivo::RestClient.new(auth_id, auth_token)

[billm]

If I could like “learn how to fish” here I’d be super happy, but right now I feel like I’m missing 3/4 of whatever happens to build an asset.

[jspaleta]

What are you doing to generate the asset tarball? I ask because the build/deploy scripting in the repo you forked right now is somewhat dependent on the travisCI environment and the scripting makes some assumptions about env vars provided and will fail to run if certain env_vars are not set. This is deliberate. It’s not really tuned for local assets builds. If I understood what you were doing to build the asset, that error might make more sense.

The details in the intended build process for these assets is in the .travis.xml with controls the travisCI environment. The meat of the asset build is in the deploy section, which runs a script taken from a helper repository (installed in travis pre_deploy) that I specifically spun up to provide best-practices for the community sensu-plugins collection so we can start generating assets as part of the regular github release process managed by TravisCI. It makes heavy use of Docker images for each target linux platform There’s room to improve the scripting further to make local builds easier to fire off.

I hadn’t had time yet to generate the asset as I was making sure the underlying handler worked. The last thing i did was fix the Plivo syntax error by manually testing the ruby gem using standard gem build/gem install sort of interatings. Actually, it might not be clear how to do that so let me be explicit.

I’m running a development Sensu backend on my network (on a raspi cluster…but that’s immaterial at the moment)… but i’m using sensuctl on my fedora workstation to manually test the ruby handler using:
sensuctl event info <entity> <check> --format json | handler-plivosms.rb --map-go-event-into-ruby 1

This lets me manually extract a sensu go event as a json string and pipe it into a handler under development, outside of the production env. This is how i do initial testing for handlers I haven’t used before so I can make sure I construct the Sensu Go handler resource correctly with any need env_var tweaks or what not. This is how I found and fixed that Plivo syntax error.

[billm]

@jspaleta I was basically following the hello world example here:

The "Hello World" of Sensu Assets

In this tutorial, I’ll walk you through packaging up a pretty standard bash script. The goal here is to show that you can take some of those scripts that are hanging around in the nooks and crannies of your organization and package them up as assets. The Setup hello-world.sh #!/bin/sh STRING="Hello World" echo $STRING if [ $? -eq 0 ]; then exit 0 else exit 2 fi The first step is to ensure that our directory structure is in place. As noted in Sensu Go example asset structure, our sc…

But simply taring up the asset and creating a github release for it doesn’t seem to be what gets generated, in for example, @aaronsachs “releases” on his github:

https://github.com/asachs01/sensu-plugins-plivo/releases

so all the different arch tar balls? I have no idea where those come from.

@jspaleta so you’re still working on this then? Thanks for that.

[jspaleta]

Oh yeah there still loads to be done around lowering the bar for sharable assets.

Statically compiled golang assets are absolutely the easiest thing to share, interpreted languages or shell scripts are more complicated.

But if you are just trying to build assets for your own environment, the process is quite easy and the hello world example covers it. But you have to tune the environment to ensure the implicit requirements are met. If you control your environment fully, its quite easy to package up assets like shell or ruby scripts for your own consumption similar to the hello world example. You can be sure that the ruby env or the bash shell or anything else you need is already in the environment before you use the asset.

But the downside to that is you can’t easily share those assets with others using slightly different environments. This is why the statically compiled golang is superior here… much less overhead to worry about to produce reusable binary content.

When sharing assets, you can’t assume things will be available in the other person’s environment. Assets aren’t a full packaging system, there’s no dependency management. The intent is assets should provide everything they need…

However to support the existing collection of Ruby based sensu-plugins, we sort of stretched that intent a bit and found a way to layer multiple assets…so we could provide a consistent ruby-runtime asset for individual sensu-plugins assets to build and run against.
It’s a more complicated process, which is why I spun up the helper repository with the scripting…and drove it into the travisCI config…so as we refactor the best practice build process for the ruby runtime… individual plugins under the sensu-plugins org will be able to make use of it.

[billm]

Yeah I’m still really unclear how what the .rb assets that end up on the alpine image are related to the tar file I was creating using the method above.

So, I’m still unclear what’s happening here. Are you planning on releasing this ruby plivo plugin with your changes via bonsai, or is @aaronsachs going to update his bonsai release? I feel, at this point, that I don’t have anywhere near the dev environment necessary to build it myself, and I need this to work or I can’t move forward with sensu-go. I thought packaging the asset was a much simpler thing than it appears that it is, for ruby assets anyway.

[jspaleta]

Does this help?

Using Ruby based assets that require the Ruby runtime asset

Introduction To simplify the burden of providing a working Ruby environment in each Sensu plugin, Sensu is making available re-usable Ruby runtime assets, and corresponding docker images that can help make it easier to use the existing collection of Ruby assets. This will be a quick guide to walk you through using Ruby assets that require the Ruby runtime asset to work correctly. If you want to know how you can build assets that make use of the Ruby runtime, please read the companion quickstar…