Join us monthly on Wednesdays for Community Office Hours focused on Nomad. Please use this thread to ask technical questions to be answered during the 60-minute live office hours.
During Community Office Hours, we will have experts available to provide advice on technical architecture, give recommendations for operational best practices, review current Github issues, or dive into the open source-code itself.
The hosting teammates will reference this thread during each Community Office Hours focusing on Nomad.
Hi there, I have just watched the coh of Nomad and loved it. Mike asked for food for thought about status and especially about historical status. The current state of (historical) status can be confusing. What Julie shown of the new design is a good way to solved it. By default show the current status of the job, but allow people to see the historical status of the job.
For me I would like to able to see the historical status e.g. when something has happened over the weekend. The historical status view can show you if something has happened and rescheduled/deployed. Not don’t want always to send a message to the engineer during the weekend when this happened, but you want to know if it has happened. This could mean that something is wrong and could be become an issue later.
For the rest, love the direction this is going. Keep it up!
Good to know that historical status is helpful. Is there some good cutoff for when you no longer care about statuses?
For instance, we can show only the allocations with versions from the last successful deployment (or later in case of a failed deployments). Or we could make a cutoff by time (hard to get this right though). Or maybe the last N versions?
In the case of the jobs from the weekend, would those still be from the latest deploy or are you thinking you re-deploy some fix over the weekend, but still want visibility for the second to last deploy later?
For me, a good cutoff would be like a week. If something went wrong multiple times within a week, then there should be looked into.
The cutoff based on time would be nice, but as you said that will be hard to get it wright.
In the case of the jobs from the weekend, would those still be from the latest deploy or are you thinking you re-deploy some fix over the weekend, but still want visibility for the second to last deploy later?
Hi there, I have simple configuration with nomad v.1.3.2 with qemu driver and I want to make bridge network configuration and job to take dhcp from my local network.
In the last community office hours, I had suggested that a banner text would be helpful. I see that it is part of 1.5.0 GA. Lovely to see this UX feature part of the release.
Also, do you think it’s time for another COH since 1.5.0 is GA?
Here’s one administrative question: the “Check out the recordings here” only have seems to only have recordings for 2020? What about for 2021, 2022… maybe even 2023?
I’m wondering when the next Office Hours for Nomad is scheduled (I couldn’t see it via the link at the top).
I’m interested to hear discussion regarding the BSL license change and what that means in the context of Nomad specifically. Could someone provide an example of a (hypothetical) commercial product using Nomad that would be considered to be in contravention of the BSL license?
