Announcing gooseBit an alternative to the hawkBit update server

[James Hilliard]

We are thrilled to announce the launch of our new software project,
gooseBit, an innovative and user-friendly alternative to the existing
hawkBit project.

Why gooseBit?
Ease of Setup and Deployment: gooseBit is designed with simplicity in
mind, ensuring that you can set up and deploy an update server with
minimal hassle.

DDI API Specification: gooseBit implements hawkBit's DDI API
specification, allowing for the use of existing hawkBit integrations.

Apache-2.0 Licensed: We believe in open-source principles and have
released this software under the permissive Apache-2.0 license.

Backed by Upstream Data Inc: gooseBit is proudly developed and
maintained by Upstream Data(https://upstreamdata.com/).

We invite you to explore gooseBit and welcome contributions.

You can find the project here on github:
https://github.com/UpstreamDataInc/goosebit

James Hilliard
CTO, Upstream Data Inc.
https://upstreamdata.com/

[Stefano Babic]

Hi James,

On 12.07.24 23:27, James Hilliard wrote:
> We are thrilled to announce the launch of our new software project,
> gooseBit, an innovative and user-friendly alternative to the existing
> hawkBit project.
>

Many thanks to share this project and publish it under FOSS, very
appreciated.

> Why gooseBit?
> Ease of Setup and Deployment: gooseBit is designed with simplicity in
> mind, ensuring that you can set up and deploy an update server with
> minimal hassle.
>
> DDI API Specification: gooseBit implements hawkBit's DDI API
> specification, allowing for the use of existing hawkBit integrations.
>
> Apache-2.0 Licensed: We believe in open-source principles and have
> released this software under the permissive Apache-2.0 license.
>
> Backed by Upstream Data Inc: gooseBit is proudly developed and
> maintained by Upstream Data(https://upstreamdata.com/).
>
> We invite you to explore gooseBit and welcome contributions.
>

I have just a set of basic questions:

- how will be manged the project ? Through github (issues and MR), via
Mailing List, ...?

- There should be at least as short doc how to contribute to the
project, coding style, etc.

- there is not yet documentation, but at least a quick install should
help. Something adding poetry install and "poetry run python3 main.py"
(this is what I did to start it into a container).

- Coding via filename seems a little weak :

- I see that /configData is supported, but data are just discarded.
Which are your plans for this ? We could also define some data that
SWUpdate should define for a better support of gooseBit. I really think
about current firmware version, that Hawkbit discards but it could be
used to check out if there was an offline update and the device has
already a current software.

- a short list of what should be added first to the project will be nice.

We can also add a reference to your project in SWUpdate's documentation,
maybe in the chapter about backends.

Many thanks again,
Stefano

[James Hilliard]

On Sun, Jul 21, 2024 at 4:09 AM Stefano Babic
<stefan...@swupdate.org> wrote:
>
> Hi James,
>
> On 12.07.24 23:27, James Hilliard wrote:
> > We are thrilled to announce the launch of our new software project,
> > gooseBit, an innovative and user-friendly alternative to the existing
> > hawkBit project.
> >
>
> Many thanks to share this project and publish it under FOSS, very
> appreciated.
>
> > Why gooseBit?
> > Ease of Setup and Deployment: gooseBit is designed with simplicity in
> > mind, ensuring that you can set up and deploy an update server with
> > minimal hassle.
> >
> > DDI API Specification: gooseBit implements hawkBit's DDI API
> > specification, allowing for the use of existing hawkBit integrations.
> >
> > Apache-2.0 Licensed: We believe in open-source principles and have
> > released this software under the permissive Apache-2.0 license.
> >
> > Backed by Upstream Data Inc: gooseBit is proudly developed and
> > maintained by Upstream Data(https://upstreamdata.com/).
> >
> > We invite you to explore gooseBit and welcome contributions.
> >
>
> I have just a set of basic questions:
>
> - how will be manged the project ? Through github (issues and MR), via
> Mailing List, ...?

Through github issue and MR at the moment(for software like gooseBit
I like having the ability to run tests and such automatically in MR's)

I can add you as a project maintainer on github if you'd like by the way.

> - There should be at least as short doc how to contribute to the
> project, coding style, etc.

Yeah, at the moment it's kind of just standard github MR workflow,
we should probably enforce styling using github's CI and document
any style preferences that are not enforced by the CI.

> - there is not yet documentation, but at least a quick install should
> help. Something adding poetry install and "poetry run python3 main.py"
> (this is what I did to start it into a container).

Yeah, we should probably add some more detail to the setup docs:
https://github.com/UpstreamDataInc/goosebit/tree/581f8304cb5d2df8a3c6b22e040c9643cc57ca16?tab=readme-ov-file#setup

There is an open MR working on some documentation stuff:
https://github.com/UpstreamDataInc/goosebit/pull/23

> - Coding via filename seems a little weak :

Yeah, I wasn't about to come up with a better solution, have any
ideas?

> - I see that /configData is supported, but data are just discarded.
> Which are your plans for this ? We could also define some data that
> SWUpdate should define for a better support of gooseBit. I really think
> about current firmware version, that Hawkbit discards but it could be
> used to check out if there was an offline update and the device has
> already a current software.

SWUpdate sends the current firmware version by default? I was sticking
it in a config var.

> - a short list of what should be added first to the project will be nice.

Roadmap discussion:
https://github.com/UpstreamDataInc/goosebit/issues/18

> We can also add a reference to your project in SWUpdate's documentation,
> maybe in the chapter about backends.

Yeah, thinking it may also be useful to set up some automated integration
testing between gooseBit and SWUpdate. Could have maybe a separate
project for that or have something in gooseBit project automatically
test against SWUpdate or something in SWUpdate project automatically
test against gooseBit, not sure what best option there is.

[Ezra Buehler]

Hi,

On 21 Jul 2024, at 12:48, James Hilliard <james.h...@gmail.com> wrote:

On Sun, Jul 21, 2024 at 4:09 AM Stefano Babic

<stefan...@swupdate.org> wrote:

- Coding via filename seems a little weak :

Yeah, I wasn't about to come up with a better solution, have any
ideas?

That is probably going to change. Here my suggestion:

Cheers,

Ezra

[Stefano Babic]

Hi James,

Ok, got it.

>
> I can add you as a project maintainer on github if you'd like by the way.

Thanks - I can't promise I could be active here, I will try.

>
>> - There should be at least as short doc how to contribute to the
>> project, coding style, etc.
>
> Yeah, at the moment it's kind of just standard github MR workflow,
> we should probably enforce styling using github's CI and document
> any style preferences that are not enforced by the CI.

Right

>
>> - there is not yet documentation, but at least a quick install should
>> help. Something adding poetry install and "poetry run python3 main.py"
>> (this is what I did to start it into a container).
>
> Yeah, we should probably add some more detail to the setup docs:
> https://github.com/UpstreamDataInc/goosebit/tree/581f8304cb5d2df8a3c6b22e040c9643cc57ca16?tab=readme-ov-file#setup
>
> There is an open MR working on some documentation stuff:
> https://github.com/UpstreamDataInc/goosebit/pull/23
>
>> - Coding via filename seems a little weak :
>
> Yeah, I wasn't about to come up with a better solution, have any
> ideas?
>

I have ideas, but I don't know if you like them. I see Ezra's answer, so
I will answer to his mail.

>
>> - I see that /configData is supported, but data are just discarded.
>> Which are your plans for this ? We could also define some data that
>> SWUpdate should define for a better support of gooseBit. I really think
>> about current firmware version, that Hawkbit discards but it could be
>> used to check out if there was an offline update and the device has
>> already a current software.
>
> SWUpdate sends the current firmware version by default? I was sticking
> it in a config var.

Not as default, but it is *higlhy* suggested to my customers to do this.
SWUpdate sends data as key/value in configData, and Hawkbit does nothing
with these, but it stores in database. It is possible to set up filter
in Hawkbit based on these values, and then it is possible to set up a
rollout with a filter that exclude device with the same formware from
rollout. A little convoluted, but this is what Hawkbit offers.

As we have here free hands, we could also have a list of recommended
key/values pairs that SWUpdate should send to gooseBit. And we can have
a field for the running firmware, that gooseBit can use.

>
>> - a short list of what should be added first to the project will be nice.
>
> Roadmap discussion:
> https://github.com/UpstreamDataInc/goosebit/issues/18
>

Ok

>> We can also add a reference to your project in SWUpdate's documentation,
>> maybe in the chapter about backends.
>
> Yeah, thinking it may also be useful to set up some automated integration
> testing between gooseBit and SWUpdate. Could have maybe a separate
> project for that or have something in gooseBit project automatically
> test against SWUpdate or something in SWUpdate project automatically
> test against gooseBit, not sure what best option there is.

I will take some time to think about.

Regards,
Stefano

[Stefano Babic]

Hi Ezra,

On 21.07.24 13:07, Ezra Buehler wrote:
> Hi,
>
>> On 21 Jul 2024, at 12:48, James Hilliard <james.h...@gmail.com>
>> wrote:
>>
>> On Sun, Jul 21, 2024 at 4:09 AM Stefano Babic
>> <stefan...@swupdate.org> wrote:
>>
>>> - Coding via filename seems a little weak :
>>
>> Yeah, I wasn't about to come up with a better solution, have any
>> ideas?
>>
>
> That is probably going to change. Here my suggestion:
>

> 19.png
> Alternate update location support by b-rowan · Pull Request #19 ·
> UpstreamDataInc/goosebit

> <https://github.com/UpstreamDataInc/goosebit/pull/19#discussion_r1685660990>
> github.com
> <https://github.com/UpstreamDataInc/goosebit/pull/19#discussion_r1685660990>
>
> <https://github.com/UpstreamDataInc/goosebit/pull/19#discussion_r1685660990>
>

As you mentioned here, this raises to me the curiosity to know why
Django was not chosen (it will be my first choice). It is just for my
curiosity.

I think that the best way is that the data are automatically detected
from the SWU. this requires some kind of inspection, but it is not so
hard. A SWU is just a cpio archive, and extracting sw-description from
the SWU is easy. It is mandatory in SWU to add a "version" attribute.
gooseBit could then extract the version from the SWu (version
attribute), and then the filename could even be JaneDoe.swu, it does not
matter. And gooseBit can check if the same version is uploaded with
different names by checking version and computing a hash on the whole SWU.

Going further, model and revision could be read from the
hardware-compatibility attribute. It is just to understand how goposeBit
should know about the SWU details and extract data from sw-description.

Best regards,
Stefano


>
> Cheers,
> Ezra
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/548DD47E-A3AD-4868-B6BD-6914A1C72159%40easyb.ch <https://groups.google.com/d/msgid/swupdate/548DD47E-A3AD-4868-B6BD-6914A1C72159%40easyb.ch?utm_medium=email&utm_source=footer>.

[Ezra Buehler]

Hi,

> On 21 Jul 2024, at 15:46, Stefano Babic <stefan...@swupdate.org> wrote:
>
> As you mentioned here, this raises to me the curiosity to know why
> Django was not chosen (it will be my first choice). It is just for my
> curiosity.

I guess a more modern (async) framework/libraries were chosen.

>
> I think that the best way is that the data are automatically detected
> from the SWU. this requires some kind of inspection, but it is not so
> hard. A SWU is just a cpio archive, and extracting sw-description from
> the SWU is easy. It is mandatory in SWU to add a "version" attribute.
> gooseBit could then extract the version from the SWu (version
> attribute), and then the filename could even be JaneDoe.swu, it does not
> matter. And gooseBit can check if the same version is uploaded with
> different names by checking version and computing a hash on the whole SWU.
>
> Going further, model and revision could be read from the
> hardware-compatibility attribute. It is just to understand how goposeBit
> should know about the SWU details and extract data from sw-description.

I like the Idea. We already briefly touched on the topic but figured it is too complicated. But in that case, we should give it a try.

Cheers,
Ezra

[James Hilliard]

On Sun, Jul 21, 2024 at 7:39 AM Stefano Babic

Ok, yeah, we did something like this in gooseBit using the firmware
version in the configData.

[James Hilliard]

On Sun, Jul 21, 2024 at 7:46 AM Stefano Babic

<stefan...@swupdate.org> wrote:
>
> Hi Ezra,
>
> On 21.07.24 13:07, Ezra Buehler wrote:
> > Hi,
> >
> >> On 21 Jul 2024, at 12:48, James Hilliard <james.h...@gmail.com>
> >> wrote:
> >>
> >> On Sun, Jul 21, 2024 at 4:09 AM Stefano Babic
> >> <stefan...@swupdate.org> wrote:
> >>
> >>> - Coding via filename seems a little weak :
> >>
> >> Yeah, I wasn't about to come up with a better solution, have any
> >> ideas?
> >>
> >
> > That is probably going to change. Here my suggestion:
> >
> > 19.png
> > Alternate update location support by b-rowan · Pull Request #19 ·
> > UpstreamDataInc/goosebit
> > <https://github.com/UpstreamDataInc/goosebit/pull/19#discussion_r1685660990>
> > github.com
> > <https://github.com/UpstreamDataInc/goosebit/pull/19#discussion_r1685660990>
> >
> > <https://github.com/UpstreamDataInc/goosebit/pull/19#discussion_r1685660990>
> >
>
> As you mentioned here, this raises to me the curiosity to know why
> Django was not chosen (it will be my first choice). It is just for my
> curiosity.

As far as I'm concerned Django is basically a legacy framework at
this point, not something that one should use for new projects without
a good reason, it has some async support but it's inferior to frameworks
that were designed to be async native from the beginning.

> I think that the best way is that the data are automatically detected
> from the SWU. this requires some kind of inspection, but it is not so
> hard. A SWU is just a cpio archive, and extracting sw-description from
> the SWU is easy. It is mandatory in SWU to add a "version" attribute.
> gooseBit could then extract the version from the SWu (version
> attribute), and then the filename could even be JaneDoe.swu, it does not
> matter. And gooseBit can check if the same version is uploaded with
> different names by checking version and computing a hash on the whole SWU.

I think we were only using the sw-description version for compatibility
release compatibility determination or something, maybe it would be a
good idea to have sw-description specify the build timestamp or so

>
> Going further, model and revision could be read from the
> hardware-compatibility attribute. It is just to understand how goposeBit
> should know about the SWU details and extract data from sw-description.

Yeah, we should definitely add some SWU parsing capability.