Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[sparkplug-dev] Eclipse Sparkplug Specification Project – Meeting Notes – 15 December 2020

Eclipse Sparkplug Specification Project – Meeting Notes – 15 December 2020

 

  • Attendees
    • Chad Kienle
    • Dominik Obermaier
    • Ian Craggs
    • Ilya Binshtok
    • Nathan Davenport
    • Wes Johnson
  • Intro by Ian Craggs. Welcome to the team Ian!!
  • Status of work up to now...
    • Recap of how the spec was originally created and where we are headed as of now.
    • 3 Artifacts required to release v1.0 version of the Sparkplug spec.
      • Spec itself
      • TCK that covers the full spec
      • Reference implementation (aka. compatible implementation ... one or more)
    • Review of Jakarta TCK coverage reports
      • We will follow this same pattern using the same tools
    • How do we automate our Sparkplug tests?
      • Tahu needs to become a compatible implementation... not there yet. It is mainly libraries around encoding and decoding currently.
      • 2 different profiles: Used by TCK and compatible implementation
        • Edge client
        • Host client
      • Outstanding requirements
        • MQTT Server required
        • Test client? 
        • Can we use the HiveMQ open source MQTT server implementation? 
          • HiveMQ has test infra to spin up an MQTT broker and intercept broker messages/packets for validation... driven via authored validation logic.
            • Dependencies
              • hivemq-extension-sdk
              • hivemq-testcontainer-junit
            • Uses standard Junit test @Rules
            • Docker image pulled and deployed 
            • Dominik walked through docs around how to author tests using this existing infra.
            • Dominik walked through docs around HiveMQ Extensions/Services/Interceptors that will help greatly with validation.
            • Maven and Gradle supported.
            • Links
      • GOAL: Get one E2E automation working for a single normative statement.
    • Reminder: July 2021 goal to release of initial version of the spec
    • Q: What does the test driver look like for our needs?
      • Interfaces defined that ensure compatible implementation can spin up the required resources given their specific constraints (OS flavor, HW specs, client profile, optional SP features – on/off, etc.)
      • Should be mostly automated.
      • How are the test operations/sequences defined? Server behavior can drive client behavior, the client response can then be validated.
      • Who will support vendors testing their compatible implementation? We need to think more about how this process should be defined.

 

Thanks,

Nathan

Back to the top