https://toitlang.org/ logo
Join Discord
Powered by
Missing in artemis, device list/device del
# help
m
I was trying to find the post in #918498540232253483 explaining this, and I cant find it, but I feel like this would be a welcome addition to the artemis tool. At the moment I have the ability use 
artemis device flash
to create a new device with a device UUID. I can then interact through the artemis tool using that UUID in the device and fleet commands. Unless I then store that UUID somewhere I can easily loose track of which device id's I can use and manage through the artemis tool. I understand that this was not the original intension of the tool, and it would be best to manage the devices through some other means, but I also feel like its a very natural place to get the complete list of devices currently assigned to an organisation.
k
We are adding better support for managing fleets in the next release. We can show you the list of all devices you have registered in your broker, but we'd like to provide even more structure than just that.
We're thinking of keeping the fleet information in a version control friendly directory/file structure and let Artemis manage it.
@mattsoftware We have spent a few weeks solidifying the fleet story. Artemis v0.6.0 is a big step in that direction. We maintain the fleet state locally in a form that is easy to have under version control.
m
I will check it out later today thanks
is there a way to not hardcode my wifi credentials in the config files - if these are meant to be committed to git for state then I really don't want them in the commits
I'm also not really a fan of git for state either - its not like you can really branch of a state and make changes etc. Also if you dont push state then if other people are also managing the fleet they will be out of date
That was the major issue with early terraform until they moved to an s3 backed state and dynamodb lock files
but i'll have more of a play when i get time to work out the workflow, these are just initial comments!
k
Thanks, @mattsoftware. We will prioritize adding a way to manage secrets. I'd also like to add a basic GitHub workflow that allows some level of push-to-update.
m
It might make more sense in a gitopts scenario. Still doens't make much sense in a branch situation, but again, i'll probably need to have a think about that a bit harder too 🙂
k
The state of the individual devices is backed by Postgres, but maybe there are still things that need improvement as multiple people start managing a fleet.
The pod specifications are very "branchable", but maybe those are the only ones. You can add new devices (experimental ones?) on a branch and have them become "visible" when merged back to main. Messing with other devices is probably going to be a bit confusing.
m
right, its good that there is some state outside git, so i'll stress less about that 🙂
k
The pods are now compiled (transitively closed) and uploaded, so you can talk about a device running a specific (built) version of your software.
artemis fleet status
shows it.
m
Let me play a little more and i'll get back to you - and yes, i'm just upskilling about pods now - and that whole concept about the specific build etc is very cool!
k
Looking forward to your feedback! 🙂
m
sorry i'm a little slow - its a side project that needs to slot in with everything else. As soon as I can massage it to a work project I will be able to iterate faster 🙂
k
I totally get it. Been there, done that 🙂
You might enjoy how we upload the pods in individual parts, so the parts shared by multiple pods only need to be uploaded once.
The biggest one is the ELF file for the firmware with all its debugging symbols.
But it is very sharable.
(it is all taken care of by 
artemis pod upload
and 
artemis pod download
, so you will not really see this)
PreviousNext
Powered by