Ad-Hoc Meetup to discuss BIOS Configuration Implementations
46 views
Skip to first unread message
Noor Muhammad Malik
Apr 7, 2021, 9:48:51 AM4/7/21
to Metal3 Development List
Hello everyone!
As discussed in today's community meeting, we're arranging an ad-hoc meet-up of everyone that is involved in the BIOS configuration work to move forward with the discussion and conclude it favorably for everyone. Here's the doodle for you to vote on for timings for this meet-up.
https://doodle.com/poll/thmsc2i82vexweaq?utm_source=poll&utm_medium=link
For those that are not fully aware, and would like to attend, here are some pertinent details:
[1] An existing proposal that discusses BIOS configuration on a single machine
https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/bios-config.md
[2] The implementation of this specification is here
https://github.com/metal3-io/baremetal-operator/pull/302
[3] Another proposal for batch configuration of BIOS across multiple machines
https://github.com/metal3-io/metal3-docs/pull/173
The concern is the incompatibility of these two approaches to exist simultaneously.
The existing meeting link for metal3 community meeting can be used
https://zoom.us/j/97255696401?pwd=ZlJMckNFLzdxMDNZN2xvTW5oa2lCZz09
As discussed in today's community meeting, we're arranging an ad-hoc meet-up of everyone that is involved in the BIOS configuration work to move forward with the discussion and conclude it favorably for everyone. Here's the doodle for you to vote on for timings for this meet-up.
https://doodle.com/poll/thmsc2i82vexweaq?utm_source=poll&utm_medium=link
For those that are not fully aware, and would like to attend, here are some pertinent details:
[1] An existing proposal that discusses BIOS configuration on a single machine
https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/bios-config.md
[2] The implementation of this specification is here
https://github.com/metal3-io/baremetal-operator/pull/302
[3] Another proposal for batch configuration of BIOS across multiple machines
https://github.com/metal3-io/metal3-docs/pull/173
The concern is the incompatibility of these two approaches to exist simultaneously.
There's another concern of the timing of implementation of [3]. [2] is already implemented and concluding review while [3] is in the design phase. Due to [2] already being delayed for more than a year, would be preferable to merge it till [3] is developed as a complementary or even alternative approach. This needs discussion.
The existing meeting link for metal3 community meeting can be used
https://zoom.us/j/97255696401?pwd=ZlJMckNFLzdxMDNZN2xvTW5oa2lCZz09
Zane Bitter
Apr 7, 2021, 12:26:58 PM4/7/21
to metal...@googlegroups.com
I had a conflict with the meeting this week, but maybe we could just
discuss it here? There's no rule that we're only allowed to do work on a
video call :)
On 7/04/21 9:48 am, Noor Muhammad Malik wrote:
> [1] An existing proposal that discusses BIOS configuration on a single
> machine
> https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/bios-config.md
> <https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/bios-config.md>
> [2] The implementation of this specification is here
> https://github.com/metal3-io/baremetal-operator/pull/302
> <https://github.com/metal3-io/baremetal-operator/pull/302>
> [3] Another proposal for batch configuration of BIOS across multiple
> machines
> https://github.com/metal3-io/metal3-docs/pull/173
> <https://github.com/metal3-io/metal3-docs/pull/173>
>
> The concern is the incompatibility of these two approaches to exist
> simultaneously.
From a user's perspective it seems fairly obvious what should happen
here: the specific overrides the general, so if both are specified then
you should get the batch config (from [3]) overridden by whatever
specific settings are configured in the BIOS config options in the CRD
(from [2]). The options being added in [2] are already ternary to allow
for the possibility that the user just wants to leave the settings as
they are (presumably manually) configured in the BIOS, so while the
mechanics of that are still up for grabs we know it won't introduce an
incompatibility at the CRD level.
Bob/Dmitry, is it possible to get this outcome from Ironic just by
ordering the clean steps properly? (i.e. can we add a clean step to do
the bulk upload followed by another one to set a specific property.) If
so then I don't see any issue with doing both.
Conversely, if it would require multiple passes of manual cleaning or
understanding of the format of the bulk config data then we have some
thinking to do.
cheers,
Zane.
discuss it here? There's no rule that we're only allowed to do work on a
video call :)
On 7/04/21 9:48 am, Noor Muhammad Malik wrote:
> [1] An existing proposal that discusses BIOS configuration on a single
> machine
> https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/bios-config.md
> <https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/bios-config.md>
> [2] The implementation of this specification is here
> https://github.com/metal3-io/baremetal-operator/pull/302
> <https://github.com/metal3-io/baremetal-operator/pull/302>
> [3] Another proposal for batch configuration of BIOS across multiple
> machines
> https://github.com/metal3-io/metal3-docs/pull/173
> <https://github.com/metal3-io/metal3-docs/pull/173>
>
> The concern is the incompatibility of these two approaches to exist
> simultaneously.
here: the specific overrides the general, so if both are specified then
you should get the batch config (from [3]) overridden by whatever
specific settings are configured in the BIOS config options in the CRD
(from [2]). The options being added in [2] are already ternary to allow
for the possibility that the user just wants to leave the settings as
they are (presumably manually) configured in the BIOS, so while the
mechanics of that are still up for grabs we know it won't introduce an
incompatibility at the CRD level.
Bob/Dmitry, is it possible to get this outcome from Ironic just by
ordering the clean steps properly? (i.e. can we add a clean step to do
the bulk upload followed by another one to set a specific property.) If
so then I don't see any issue with doing both.
Conversely, if it would require multiple passes of manual cleaning or
understanding of the format of the bulk config data then we have some
thinking to do.
cheers,
Zane.
Bob Fournier
Apr 7, 2021, 12:50:34 PM4/7/21
to Zane Bitter, metal...@googlegroups.com
Yes it should be OK. In both cases it will use the same format to apply the
BIOS config in clean_steps, the bulk set will just contain the entire list of settings. i.e:
"clean_steps": [
{
{
"interface": "bios",
"step": "apply_configuration", "args": {
"settings": [
"settings": [
... ] } }
So if the individual set was a clean step after the bulk set we would end up with the value
from the individual set. (Dmitry - correct me if that's not right).
Bob
Conversely, if it would require multiple passes of manual cleaning or
understanding of the format of the bulk config data then we have some
thinking to do.
cheers,
Zane.
--
You received this message because you are subscribed to the Google Groups "Metal3 Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metal3-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/8c476ad0-4411-a007-d282-becb9aaac374%40redhat.com.
Noor Muhammad Malik
Apr 7, 2021, 3:04:56 PM4/7/21
to Bob Fournier, Zane Bitter, Metal3 Development List
@zane I agree with what you've said, doing both looks straightforward from the CRD perspective.
And no we don't need a video call to discuss it :D Let's just say we're going to keep the discussion going here, till the poll ends, and once we decide upon a time for the meeting, if there are any discussion items left, we can move onto a meeting to further dissect this. Really appreciate the timely response! :)
@bob thanks for the application, yes it should be a series of clean steps needed to accomplish it all. Let's see what dmitry has to say about this.
To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/CAMnktEC92fEes0VbRjVnEVNCF%3Dv7HZzn4-4pvfbq5ho2nv26DQ%40mail.gmail.com.
Zane Bitter
Apr 7, 2021, 3:32:58 PM4/7/21
to Metal3 Development List, Noor Muhammad Malik, Bob Fournier
On 7/04/21 3:04 pm, Noor Muhammad Malik wrote:
> @zane I agree with what you've said, doing both looks straightforward
> from the CRD perspective.
> And no we don't need a video call to discuss it :D Let's just say we're
> going to keep the discussion going here, till the poll ends, and once we
> decide upon a time for the meeting, if there are any discussion items
> left, we can move onto a meeting to further dissect this. Really
> appreciate the timely response! :)
++
> @zane I agree with what you've said, doing both looks straightforward
> from the CRD perspective.
> And no we don't need a video call to discuss it :D Let's just say we're
> going to keep the discussion going here, till the poll ends, and once we
> decide upon a time for the meeting, if there are any discussion items
> left, we can move onto a meeting to further dissect this. Really
> appreciate the timely response! :)
> @bob thanks for the application, yes it should be a series of clean
> steps needed to accomplish it all. Let's see what dmitry has to say
> about this.
same cleaning step, I looked at the proposed PR and I see that we are
effectively requiring the bmc driver to tell us how to map from the
limited options that we are specifying directly in the BMC to the
'apply_configuration' settings. That means that even in the worst case
scenario (that ironic cannot handle multiple 'apply_configuration' clean
steps), we do have enough information in the baremetal-operator to merge
these correctly.
So given that we know there is at least one way to implement a sane
interface that includes both, for my vote I don't see this being an
obstacle to making progress on the small number of vendor-neutral
options that have been proposed. (However, I'm definitely against adding
any vendor-specific fields until we have at least reconciled that with
the bulk set proposal. imho the bulk set proposal is superior to adding
vendor-specific options with a formal schema, and should probably
replace that idea.)
We should update https://github.com/metal3-io/metal3-docs/pull/173 with
the priority order:
1. FirmwareConfig
2. bulk settings
3. whatever is currently configured
cheers,
Zane.
>
> Warm regards,
>
> Noor Muhammad Malik
> Assistant Manager
> xFlow Research Inc.
> +92 310 5382448 (GMT +5)
> www.xflowresearch.com <http://www.xflowresearch.com>
>
> So if the individual set was a clean step after the bulk set we
> would end up with the value
> from the individual set. (Dmitry - correct me if that's not right).
>
> Bob
>
>
> Conversely, if it would require multiple passes of manual
> cleaning or
> understanding of the format of the bulk config data then we have
> some
> thinking to do.
>
> cheers,
> Zane.
>
> --
> You received this message because you are subscribed to the
> Google Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to metal3-dev+...@googlegroups.com
> <mailto:metal3-dev%2Bunsu...@googlegroups.com>.
> So if the individual set was a clean step after the bulk set we
> would end up with the value
> from the individual set. (Dmitry - correct me if that's not right).
>
> Bob
>
>
> Conversely, if it would require multiple passes of manual
> cleaning or
> understanding of the format of the bulk config data then we have
> some
> thinking to do.
>
> cheers,
> Zane.
>
> --
> You received this message because you are subscribed to the
> Google Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to metal3-dev+...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/8c476ad0-4411-a007-d282-becb9aaac374%40redhat.com
> <https://groups.google.com/d/msgid/metal3-dev/8c476ad0-4411-a007-d282-becb9aaac374%40redhat.com>.
> https://groups.google.com/d/msgid/metal3-dev/8c476ad0-4411-a007-d282-becb9aaac374%40redhat.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to metal3-dev+...@googlegroups.com
> <mailto:metal3-dev+...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to metal3-dev+...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/CAMnktEC92fEes0VbRjVnEVNCF%3Dv7HZzn4-4pvfbq5ho2nv26DQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/metal3-dev/CAMnktEC92fEes0VbRjVnEVNCF%3Dv7HZzn4-4pvfbq5ho2nv26DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
Noor Muhammad Malik
Apr 7, 2021, 3:36:26 PM4/7/21
to Zane Bitter, Metal3 Development List, Bob Fournier
+1
Warm regards,
Noor Muhammad Malik
Assistant Manager
xFlow Research Inc
Noor Muhammad Malik
Assistant Manager
xFlow Research Inc
To unsubscribe from this group and stop receiving emails from it, send an email to metal3-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/c36c58e4-6a24-a835-ba9c-2f985e860735%40redhat.com.
zouy...@cn.fujitsu.com
Apr 12, 2021, 5:30:55 AM4/12/21
to Metal3 Development List
Currently [2] has been scoped down to only support small number
of vendor-neutral options, and as be discussed above, the incompatibility
between [2] and [3] is econcilable. Considering that the implementation of [3]
will take some time, I hope that [2] could be merged first.
Besides, I noticed that in the motivation section of [3]'s proposal,
it says that a user could initially set up a machine by using [2] and
then push the configuration to multiple machines via [3],
so [2] could be a complementary for [3].
Reply all
Reply to author
Forward
0 new messages