Ironic Operator future, scope and naming

87 views
Skip to first unread message

Dmitry Tantsur

unread,
Dec 1, 2023, 4:55:42 AM12/1/23
to Metal3 Development List
Hi folks,

In the last community meeting, I presented [1] ironic-operator [2] as a proof of concept. Here I want to cover two questions.

(1) Adding ironic-operator to Metal3

I would like to formally propose moving the ironic-operator under Metal3 and gradually migrating to it as the primary way to install Ironic for the purposes of Metal3. Are there any objections to that? What would be the process?

If we decide to proceed, are there people who want to become reviewers on the project so that my patches can be merged too? Does anyone want to help with metal3-dev-env integration?

(2) Naming and scope

In a related openstack-discuss thread [3], a concern was voiced by one of the Red Hat OpenStack developers that they already have a thing called ironic-operator [4] that also manages Ironic but in a completely different fashion and with a completely different goal (as a part of Red Hat's OpenStack offering). I don't really envision a possibility of reconciling the two operators. While I don't necessarily see the name clash as a blocking concern, we should at least discuss that out of respect for our colleagues. Baremetal Operator could be a great name, but alas.

One opportunity here is to expand the scope of the new operator to also manage BMO and call it metal3-operator. There is definitely some benefit in doing so: the operator would be able to get the most information that BMO needs (endpoints, credentials, TLS, deploy ramdisk) from the Ironic resource. But there have been objections to this idea from the community in the past, so I'd like to hear your opinions. I can build a proof of concept if the community is interested.

Thanks!

Dmitry


-- 
Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

Tuomo Tanskanen

unread,
Dec 1, 2023, 5:36:19 AM12/1/23
to Dmitry Tantsur, Metal3 Development List
Hey,

There are only 2 hard things in computer science: cache invalidation, naming things, and off-by-one errors 😉 

That said, we've been floating an idea of Metal3 operator as well. Operator with that name should not just operate BMO and Ironic, but CAPM3 and IPAM as well. Having a Metal3 project wide operator would also make releasing and consuming Metal3 simpler and more logical.  I'm all for the idea, but to get there... easier said than done. It sounds like something Metal3 2.0 would have. I think we eventually need to go there, so a +1 from me.

Cheers, Tuomo

From: metal...@googlegroups.com <metal...@googlegroups.com> on behalf of Dmitry Tantsur <dtan...@redhat.com>
Sent: 01 December 2023 11:55
To: Metal3 Development List <metal...@googlegroups.com>
Subject: [metal3-dev] Ironic Operator future, scope and naming
 
--
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/CACNgkFxoMhra7wY%2B5ZWi%2B2toXNkbwr3g6MFZ_baHG-40ohiPFg%40mail.gmail.com.

Dmitry Tantsur

unread,
Dec 1, 2023, 5:38:48 AM12/1/23
to Tuomo Tanskanen, Metal3 Development List
On Fri, Dec 1, 2023 at 11:36 AM Tuomo Tanskanen <tuomo.t...@est.tech> wrote:
Hey,

There are only 2 hard things in computer science: cache invalidation, naming things, and off-by-one errors 😉 

LOL so true.
 

That said, we've been floating an idea of Metal3 operator as well. Operator with that name should not just operate BMO and Ironic, but CAPM3 and IPAM as well. Having a Metal3 project wide operator would also make releasing and consuming Metal3 simpler and more logical.  I'm all for the idea, but to get there... easier said than done. It sounds like something Metal3 2.0 would have. I think we eventually need to go there, so a +1 from me.

Fortunately, we don't have to support EVERYTHING at once. I don't think it will be a grand rework justifying 2.0. We can gradually add more resources (IPAM will indeed by the next target).

Dmitry
 

Huy Mai

unread,
Dec 1, 2023, 7:35:36 AM12/1/23
to Dmitry Tantsur, Tuomo Tanskanen, Metal3 Development List
Hi,

First of all, good job Dmitry! This is a huge improvement from what we currently have. Thank you so much for the efforts!

Regarding naming it, I agree that we should not use a name of an existing project, but imo "Baremetal Operator" is a bit vague. And it will be even more vague once we have a bigger operator that's in charge of the whole Metal3 wf. Maybe something obvious, like "Metal3-Ironic operator" would be more expressive?

Br,
Huy
Sent: Friday, December 1, 2023 12:38 PM
To: Tuomo Tanskanen <tuomo.t...@est.tech>
Cc: Metal3 Development List <metal...@googlegroups.com>
Subject: Re: [metal3-dev] Ironic Operator future, scope and naming
 

Dmitry Tantsur

unread,
Dec 1, 2023, 8:54:22 AM12/1/23
to Huy Mai, Metal3 Development List
Hi,

On Fri, Dec 1, 2023 at 1:35 PM Huy Mai <huy...@est.tech> wrote:
Hi,

First of all, good job Dmitry! This is a huge improvement from what we currently have. Thank you so much for the efforts!

Regarding naming it, I agree that we should not use a name of an existing project, but imo "Baremetal Operator" is a bit vague. And it will be even more vague once we have a bigger operator that's in charge of the whole Metal3 wf.

Well, one option is for the current ironic-operator to *become* this bigger operator.
 
Maybe something obvious, like "Metal3-Ironic operator" would be more expressive?

We don't call things metal3-ironic-image, metal3-ip-address-management, metal3-baremetal-operator, etc. So while metal3-operator as the "thing that manages Metal3" makes sense to me, metal3-ironic-operator as the "metal3's flavor of ironic-operator" feels inconsistent with existing naming.

Dmitry

Dmitry Tantsur

unread,
Dec 1, 2023, 9:59:34 AM12/1/23
to Metal3 Development List
On Fri, Dec 1, 2023 at 10:55 AM Dmitry Tantsur <dtan...@redhat.com> wrote:
Hi folks,

In the last community meeting, I presented [1] ironic-operator [2] as a proof of concept. Here I want to cover two questions.

(1) Adding ironic-operator to Metal3

I would like to formally propose moving the ironic-operator under Metal3 and gradually migrating to it as the primary way to install Ironic for the purposes of Metal3. Are there any objections to that? What would be the process?

If we decide to proceed, are there people who want to become reviewers on the project so that my patches can be merged too? Does anyone want to help with metal3-dev-env integration?

(2) Naming and scope

In a related openstack-discuss thread [3], a concern was voiced by one of the Red Hat OpenStack developers that they already have a thing called ironic-operator [4] that also manages Ironic but in a completely different fashion and with a completely different goal (as a part of Red Hat's OpenStack offering). I don't really envision a possibility of reconciling the two operators. While I don't necessarily see the name clash as a blocking concern, we should at least discuss that out of respect for our colleagues. Baremetal Operator could be a great name, but alas.

One opportunity here is to expand the scope of the new operator to also manage BMO and call it metal3-operator. There is definitely some benefit in doing so: the operator would be able to get the most information that BMO needs (endpoints, credentials, TLS, deploy ramdisk) from the Ironic resource. But there have been objections to this idea from the community in the past, so I'd like to hear your opinions. I can build a proof of concept if the community is interested.

To illustrate this idea, I've build a prototype showing how API to manage BMO could look like: https://github.com/dtantsur/ironic-operator/blob/bmo/api/v1alpha1/baremetalcontroller_types.go (not backed by an actual controller, so not usable).
 

Thanks!

Dmitry


-- 
Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

Ádám Rozmán

unread,
Dec 1, 2023, 2:33:40 PM12/1/23
to Dmitry Tantsur, Metal3 Development List
HI,

As I said on the community meeting, great job and I support this new operator to be integated to upstream metal3 also!
I agree with Huy that a"Metal3-Ironic-operator" would be a good name for the same reason as the others have mentioned before, we have already started to discuss a Metal3 operator that would take over some responsibilities of CAPM3 to streamline deployments for non-CAPI based deployment workflows and it would sit between CAPM3 and IPAM+BMO and would turn CAPM3 to just an "interface" for CAPI support .

I would be happy to help with reviews or metal3-dev-env integration, I have quite a lot of upstream and private experience with extending dev-env.

BR,
Adam

Sent: Friday, December 1, 2023 4:59 PM

To: Metal3 Development List <metal...@googlegroups.com>
Subject: [metal3-dev] Re: Ironic Operator future, scope and naming
 
--
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.

Adam Rozman

unread,
Dec 1, 2023, 2:56:55 PM12/1/23
to Metal3 Development List
Related to the naming, if the Metal3 prefix is not something that seems acceptable, we could also call it something like :

"Ironic-provisioner-operator"

"Ironic-kube/k8s/-oparator"

"Ironic-m3-operator"

We could go with fantasy names based on the metal + k8s + hw analogy.

"Kuborg/Kubeborg"

"Kube-ferrum, Kuberrum" (from latin ferrum = iron)

"Anvill"

Many project around K8s follows sailing/ship analogy of K8s

"Ironclad" https://en.wikipedia.org/wiki/Ironclad_warship  

So following metal and metal work related processes we could call it:

"Rivet"

Riveting is a process of fastening a metal in another metal by the use of riveting machine and small cylindrical shaft with head in one end. It is not as strong as annealing and welding but still comes handy in different parts of the ship.

Steve Baker

unread,
Dec 4, 2023, 3:34:47 AM12/4/23
to Metal3 Development List
Hi Metal3 community, it was I who raised the issue of naming this operator.

I realise this will primarily be used by Metal3, but is there a potential for using it outside of metal3, so allowing end users direct access to the ironic endpoint? If so that might open up the naming a bit, because its really a standalone baremetal as a service operator (bmaas). This might open up naming a bit, consider a palette of colours for this bikeshed:
ironic-bmaas-operator
bmaas-operator
ironic-standalone-operator (as in, not integrated with OpenStack)

I am looking forward to consuming and contributing to this operator, and I just want to minimise confusion :)

Zane Bitter

unread,
Dec 4, 2023, 3:53:09 AM12/4/23
to metal...@googlegroups.com
On 4/12/23 16:49, Steve Baker wrote:
> ironic-standalone-operator (as in, not integrated with OpenStack)

I think 'standalone' captures the key difference between what we would
use in the Metal³ community and other Ironic operators that exist or may
someday exist. That's not to say that we have to use that word in the
name, but I think we should keep that idea central if we don't end up
rolling this up into a larger metal3-operator.

- ZB

Ádám Rozmán

unread,
Dec 4, 2023, 4:04:17 AM12/4/23
to Zane Bitter, metal...@googlegroups.com
Hi,

ironic-standalone-operator sound fine to me!

Just to reiterate and avoid confusion the "larger Metal3" operator would go between CAPM3 and BMO it would take over capm3's "orchestration capabilities" this is generally how other projects behave no one as far as I know combines to the same executable their CAPI infra-provider with the actual orchestration/business logic but ofc in Metal3 there are historic reasons as Metal3 was designed for CAPI from the bottom up but the current architecture has limitations for consumers who wouldn't use CAPI for deployment. (This is a separate topic and only a concept atm)

IMO this ironic-standalone-operator (again I like this name) would communicate with BMO and would only take care of stuff that is in Ironic's scope, I am not against that in the future we would have other operators who would do e.g. software defined bare metal networking  and they would communicate with ironic-standalone-operator  but I would like to keep ironic-standalone-operator support only the ironic workflow and related stuff.

BR,
Adam
From: metal...@googlegroups.com <metal...@googlegroups.com> on behalf of Zane Bitter <zbi...@redhat.com>
Sent: Monday, December 4, 2023 10:53 AM
To: metal...@googlegroups.com <metal...@googlegroups.com>
Subject: Re: [metal3-dev] Re: Ironic Operator future, scope and naming
 
--
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.

Kashif Khan

unread,
Dec 4, 2023, 4:21:03 AM12/4/23
to Ádám Rozmán, Zane Bitter, metal...@googlegroups.com
+1 to ironic-standalone-operator naming. 

I agree to Adam's point on metal3-operator sitting somewhere in between CAPM3/IPAM and BMO.

I am happy to be a part of the reviewing process as asked in Dmitry's initial email.

BR
Kashif 
From: metal...@googlegroups.com <metal...@googlegroups.com> on behalf of Ádám Rozmán <adam....@est.tech>
Sent: Monday, December 4, 2023 11:04 AM
To: Zane Bitter <zbi...@redhat.com>; metal...@googlegroups.com <metal...@googlegroups.com>

Dmitry Tantsur

unread,
Dec 4, 2023, 6:18:26 AM12/4/23
to Ádám Rozmán, Zane Bitter, metal...@googlegroups.com, Steve Baker
Hi,

Okay, there is dangerous confusion here. See inline.

On Mon, Dec 4, 2023 at 10:04 AM Ádám Rozmán <adam....@est.tech> wrote:
Hi,

ironic-standalone-operator sound fine to me!

Just to reiterate and avoid confusion the "larger Metal3" operator would go between CAPM3 and BMO it would take over capm3's "orchestration capabilities" this is generally how other projects behave no one as far as I know combines to the same executable their CAPI infra-provider with the actual orchestration/business logic but ofc in Metal3 there are historic reasons as Metal3 was designed for CAPI from the bottom up but the current architecture has limitations for consumers who wouldn't use CAPI for deployment. (This is a separate topic and only a concept atm)

Operator is a thing that installs software on Kubernetes [1]. Calling baremetal-operator an operator was a huge mistake: it does not install any services or applications. It should have been called baremetal-controller or something like that. Nor is what you describe an operator. A metal3-operator will be something that installs Metal3: gets BMO, Ironic, IPAM and CAPM3 running. It does not talk to BMO to provision hosts. It's not even aware of them. It does not take any logic from CAPM3.

Having a single metal3-operator as opposed to several ones has a few benefits. First, you're not going to end up with a baremetal-operator-operator (a thing that would deploy BMO) :D Second, the BMO start-up logic will be able to rely on knowing where Ironic is and how to contact it. If you check my prototype [2], all it needs is a link to an Ironic resource. Everything else will be automagical: URLs, authentication, TLS, deploy kernel/ramdisk.

 

IMO this ironic-standalone-operator (again I like this name) would communicate with BMO and would only take care of stuff that is in Ironic's scope, I am not against that in the future we would have other operators who would do e.g. software defined bare metal networking  and they would communicate with ironic-standalone-operator  but I would like to keep ironic-standalone-operator support only the ironic workflow and related stuff.

Same. What you describe is not operators. The current ironic-operator installs and manages Ironic. It does not talk to BMO and never will. BMO *might* end up talking to it to simplify finding Ironic, but that's not on the radar yet.

I'm not terribly against ironic-standalone-operator, it's descriptive and avoids conflicts. Note that I personally cannot commit to supporting use cases that differ dramatically from what Metal3 does. That includes RH OSP. I won't prevent anyone from trying, but I simply cannot afford spending time on it. I'll also object to complicating the current architecture for the sake of unrelated cases.

Dmitry
 

BR,
Adam
From: metal...@googlegroups.com <metal...@googlegroups.com> on behalf of Zane Bitter <zbi...@redhat.com>
Sent: Monday, December 4, 2023 10:53 AM
To: metal...@googlegroups.com <metal...@googlegroups.com>
Subject: Re: [metal3-dev] Re: Ironic Operator future, scope and naming
 
On 4/12/23 16:49, Steve Baker wrote:
> ironic-standalone-operator (as in, not integrated with OpenStack)

I think 'standalone' captures the key difference between what we would
use in the Metal³ community and other Ironic operators that exist or may
someday exist. That's not to say that we have to use that word in the
name, but I think we should keep that idea central if we don't end up
rolling this up into a larger metal3-operator.

- ZB

--
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/189758b1-3c41-8a09-446d-dee4d6fc8efa%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.

Ádám Rozmán

unread,
Dec 4, 2023, 6:46:55 AM12/4/23
to Dmitry Tantsur, Zane Bitter, metal...@googlegroups.com, Steve Baker
Hi,

My apologies, indeed, I was just thinking about the name "operator" without thinking about the operator pattern from my part.
Thank you for bringing this up!

So then yes, we could have a Metal3 operator do deploy components and then and also way I was talking about a "metal3-controller" then.(still off topic but clears up things)

Related to the ironic-standalone-operator I just meant that Ironic and BMO communicates I didn't mean that the "Operator" talks ot BMO , but I see why my message was confusing.

So to clear up things from my side
IMO:
  • we would need in the future both Metal3-controller and Metal3-operator/Metal3-fullstack-operator

  • I am fine with the current "ironic-standalone-operator" and it's scope I still think the "ironic-standalone-operator" should exist aside from the future
    Metal3-operator e.g. there are many folks who just use BMO and ironic without Metal3, I think a modular approach would be more flexible for the future.

  • Ofc there is the question of avoiding the "BMO-operator", but it feels to me also then that the solution would be to correct the initial error and turn BMO to a bare-metal-controller and have a BMO that is really just an operator,  I wouldn't like to introduce the Metal3-oparator just to hide this issue

    I would like the final architecture to be this then:
    - CAPM3
    - Metal3-oparator/Metal3-fullstack-operator
    - Metal3-controller
    - IPAM (I guess IPAM without Metal3 doesn't make sense so this would not need it's own operator)
    - BMO
    - BM-controller
            - ironic-standalone-operator

So, this way folks who use the full stack via CAPI would be fine, folks who want Metal3 but no CAPI would be fine, folks who use just BMO + Ironic would be fine, folks who use BMO without Ironic (I think Dmitry you mentioned this use-case in the past) would be fine, and even people would use just ironic would-be fine also.

WDYT? Ofc this is a long-term plan but for me it makes the most sense.

BR,
Adam
From: Dmitry Tantsur <dtan...@redhat.com>
Sent: Monday, December 4, 2023 1:18 PM
To: Ádám Rozmán <adam....@est.tech>
Cc: Zane Bitter <zbi...@redhat.com>; metal...@googlegroups.com <metal...@googlegroups.com>; Steve Baker <sba...@redhat.com>

Jay Faulkner

unread,
Dec 4, 2023, 3:27:52 PM12/4/23
to Metal3 Development List
With my OpenStack and Ironic leadership hats on, I've been trying to steer away from the word "standalone". Ironic is rarely used completely standalone -- it's usually surrounded by a lot of supporting services, from CNCF/OpenStack/distro ecosystems (often all three simultaneously!). In the past, I've had to help alleviate misunderstandings related to what "standalone" Ironic means. I've not done a good job in the other direction (coming up with alternative naming), but I've been thinking in this direction for a while.
 
I would suggest thinking about names that focus on use cases and scale rather than focusing specifically on the tool; this will help avoid collisions in the namespace. Why even mention Ironic in the name at all?

You can obviously name it whatever you want, that's just my thoughts on it. Thanks for the hard work on making another way to get Ironic installed places!

Thanks,
Jay Faulkner
Ironic PTL

Dmitry Tantsur

unread,
Dec 6, 2023, 9:36:39 AM12/6/23
to Jay Faulkner, Metal3 Development List
Hi,

On Mon, Dec 4, 2023 at 9:28 PM Jay Faulkner <j...@gr-oss.io> wrote:
With my OpenStack and Ironic leadership hats on, I've been trying to steer away from the word "standalone". Ironic is rarely used completely standalone -- it's usually surrounded by a lot of supporting services, from CNCF/OpenStack/distro ecosystems (often all three simultaneously!). In the past, I've had to help alleviate misunderstandings related to what "standalone" Ironic means. I've not done a good job in the other direction (coming up with alternative naming), but I've been thinking in this direction for a while.

While "standalone" is not the most descriptive term ever, it does capture well how this operator differs from the one that Steve and other folks have created for OSP.
 
 
I would suggest thinking about names that focus on use cases and scale rather than focusing specifically on the tool; this will help avoid collisions in the namespace. Why even mention Ironic in the name at all?

First, I think we're overdoing it with nicknames in OpenStack. While they're funny (and sometimes very ironic!), I can only imagine the pain of someone, for whom OpenStack is not a full time job, to remember all these Glances, Swifts and Barbicans.

Second, once we set for a non-descriptive name, we need to start being very mindful of trademarks and other naming conflicts (this is why metal3 is no longer called metalkube). All OpenStack official projects have been verified, I presume Metal3 as well.

For instance, if we go for Rivet (which I love), we need someone to tell us that we can use it. Quick search shows https://www.cloudrivet.com/ which is not entirely in the same area but comes dangerously close.

Dmitry
 

Zane Bitter

unread,
Dec 6, 2023, 8:17:36 PM12/6/23
to metal...@googlegroups.com
On 7/12/23 03:36, Dmitry Tantsur wrote:
> Hi,
>
> On Mon, Dec 4, 2023 at 9:28 PM Jay Faulkner <j...@gr-oss.io
> <mailto:j...@gr-oss.io>> wrote:
>
> With my OpenStack and Ironic leadership hats on, I've been trying to
> steer away from the word "standalone". Ironic is rarely used
> completely standalone -- it's usually surrounded by a lot of
> supporting services, from CNCF/OpenStack/distro ecosystems (often
> all three simultaneously!). In the past, I've had to help alleviate
> misunderstandings related to what "standalone" Ironic means. I've
> not done a good job in the other direction (coming up with
> alternative naming), but I've been thinking in this direction for a
> while.
>
>
> While "standalone" is not the most descriptive term ever, it does
> capture well how this operator differs from the one that Steve and other
> folks have created for OSP.

baggageless-ironic-operator?
unfraught-ironic-operator?
unstacked-ironic-operator?

Hey! That last one could actually maybe work.

> I would suggest thinking about names that focus on use cases and
> scale rather than focusing specifically on the tool; this will help
> avoid collisions in the namespace. Why even mention Ironic in the
> name at all?
>
>
> First, I think we're overdoing it with nicknames in OpenStack. While
> they're funny (and sometimes very ironic!), I can only imagine the pain
> of someone, for whom OpenStack is not a full time job, to remember all
> these Glances, Swifts and Barbicans.

Not to mention stuff within Ironic like metalsmith... or tenks - even
getting the joke requires you to be an insider, let alone figuring out
what it does.

Also, the poor ratio of O. Henry references to Alanis Morrisette
references is disappointing :-P
> ------------------------------------------------------------------------
> *From:* metal...@googlegroups.com <metal...@googlegroups.com> on
> behalf of Zane Bitter <zbi...@redhat.com>
> *Sent:* Monday, December 4, 2023 10:53 AM
> *To:* metal...@googlegroups.com <metal...@googlegroups.com>
> *Subject:* Re: [metal3-dev] Re: Ironic Operator future, scope
> and naming
> On 4/12/23 16:49, Steve Baker wrote:
> > ironic-standalone-operator (as in, not integrated with OpenStack)
>
> I think 'standalone' captures the key difference between what we
> would
> use in the Metal³ community and other Ironic operators that
> exist or may
> someday exist. That's not to say that we have to use that word
> in the
> name, but I think we should keep that idea central if we don't
> end up
> rolling this up into a larger metal3-operator.
>
> - ZB
>
> --
> 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/189758b1-3c41-8a09-446d-dee4d6fc8efa%40redhat.com <https://groups.google.com/d/msgid/metal3-dev/189758b1-3c41-8a09-446d-dee4d6fc8efa%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>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/ad2f22cf-c392-40f1-91b0-aab09296d234n%40googlegroups.com <https://groups.google.com/d/msgid/metal3-dev/ad2f22cf-c392-40f1-91b0-aab09296d234n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
>
> Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany
> Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
> Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross
>
> --
> 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>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/CACNgkFyn7rNTw54LeCH6-h8881wxxVH7W30VTK0-XxPCU_CH8A%40mail.gmail.com <https://groups.google.com/d/msgid/metal3-dev/CACNgkFyn7rNTw54LeCH6-h8881wxxVH7W30VTK0-XxPCU_CH8A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Adam Rozman

unread,
Dec 7, 2023, 9:01:29 AM12/7/23
to Metal3 Development List
Hi,

I think we should vote for the name of the new operator.
I have created a poll https://take.supersurvey.com/poll5038570x34C143a8-153 and I have added all the names that have been presented during this discussion so far.

If you intend to vote please ping me in a DM and I will give you a unique code (just to avoid getting our poll spammed ).

BR,
Adam

Adam Rozman

unread,
Dec 7, 2023, 12:32:46 PM12/7/23
to Metal3 Development List
Hi,

I have got some feedback and based on that I have removed the fantasy names and the Metal3 prefix as those have arguments against them.

I have left in everything that had no arguments against + the ironic-standalone-operator as related to standalone I still see a back and forth discussion.

Please feel free to give me feedback even if you think voting is too early or pointless that is useful also, I would like to narrow down the our options.

BR,
Adam

Dmitry Tantsur

unread,
Dec 20, 2023, 5:15:25 AM12/20/23
to Adam Rozman, Metal3 Development List
Hi,

Honestly, only ironic-standalone-operator solves the conflict with the OpenStack's operator (parts like "provisioner", "bmaas", "k8s" don't provide any clear distinguishment) without getting too creative (using the -m3- part has no precedent in metal3). While metal3-ironic-operator has an unpleasant repetition of "metal3" (given the git namespace), I don't think we should rule that out either.

Realistically, the vote should be between ironic-operator (i.e. no change), ironic-standalone-operator, metal3-ironic-operator and maybe unstacked-ironic-operator just to make Zane happy (also "unstacked" is only clear to OpenStack people).

Dmitry

To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/e368aeef-7729-4406-bb5f-75bc59aab87an%40googlegroups.com.


-- 
Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,

Huy Mai

unread,
Dec 21, 2023, 2:50:44 AM12/21/23
to Dmitry Tantsur, Ádám Rozmán, Metal3 Development List
Hi,

Imo if ironic-operator​ is still considered a "valid" choice, then it looks like the perfect one.

Ironic-standalone-operator​ could be a good name, but honestly, I did not get why "standalone"​ is a better distinguisher than "k8s" and the likes.  Afaiu the other "ironic-operator" wasn't built to work on kubernetes, right?

Br,
Huy
From: metal...@googlegroups.com <metal...@googlegroups.com> on behalf of Dmitry Tantsur <dtan...@redhat.com>
Sent: Wednesday, December 20, 2023 12:15 PM
To: Ádám Rozmán <adam....@est.tech>
Cc: Metal3 Development List <metal...@googlegroups.com>
Subject: Re: [metal3-dev] Re: Ironic Operator future, scope and naming
 

Dmitry Tantsur

unread,
Dec 21, 2023, 2:57:34 AM12/21/23
to Huy Mai, Metal3 Development List
Hi,

All operators in this context are Kubernetes operators.

Dmitry

Dmitry Tantsur

unread,
Dec 21, 2023, 6:26:28 AM12/21/23
to Metal3 Development List
Hi all,

We discussed it again at yesterday's meeting and agreed that the choice is essentially between ironic-standalone-operator and metal3-ironic-operator. Good arguments have been brought up both for and against both options. Let me know what you think, otherwise I'll probably just pick one according to my gut feeling in January.

Dmitry

Dmitry Tantsur

unread,
Jan 1, 2024, 3:53:12 AMJan 1
to Fox, Kevin M, Metal3 Development List
Hi Kevin,

It will be optimized for Metal3 since that's what is driving the development, but I'd love it to be usable in other "standalone" cases. For instance, I don't mind integration with Keystone, if it does not overcomplicate the architecture (and if someone else does the whole design and coding work).

Dmitry


On Fri, Dec 22, 2023 at 10:29 PM Fox, Kevin M <Kevi...@pnnl.gov> wrote:
Is the goal to have it generic enough folks will use it to deploy for any ironic stand alone configuration for use outside of metal3, or will it be optimized specifically for integration with metal3 and not let you configure keystone, and other stuff needed to integrate it with other parts of openstack? I'd say that answer probably informs which name is better?

Thanks,
Kevin

________________________________________
From: metal...@googlegroups.com <metal...@googlegroups.com> on behalf of Dmitry Tantsur <dtan...@redhat.com>
Sent: Thursday, December 21, 2023 3:26 AM
To: Metal3 Development List
Subject: Re: [metal3-dev] Re: Ironic Operator future, scope and naming

Check twice before you click! This email originated from outside PNNL.


Hi all,

We discussed it again at yesterday's meeting and agreed that the choice is essentially between ironic-standalone-operator and metal3-ironic-operator. Good arguments have been brought up both for and against both options. Let me know what you think, otherwise I'll probably just pick one according to my gut feeling in January.

Dmitry

On Wed, Dec 20, 2023 at 11:15 AM Dmitry Tantsur <dtan...@redhat.com<mailto:dtan...@redhat.com>> wrote:
Hi,

Honestly, only ironic-standalone-operator solves the conflict with the OpenStack's operator (parts like "provisioner", "bmaas", "k8s" don't provide any clear distinguishment) without getting too creative (using the -m3- part has no precedent in metal3). While metal3-ironic-operator has an unpleasant repetition of "metal3" (given the git namespace), I don't think we should rule that out either.

Realistically, the vote should be between ironic-operator (i.e. no change), ironic-standalone-operator, metal3-ironic-operator and maybe unstacked-ironic-operator just to make Zane happy (also "unstacked" is only clear to OpenStack people).

Dmitry

On Thu, Dec 7, 2023 at 3:01 PM Adam Rozman <adam....@est.tech> wrote:
Hi,

I think we should vote for the name of the new operator.
I have created a poll https://take.supersurvey.com/poll5038570x34C143a8-153<https://take.supersurvey.com/poll5038570x34C143a8-153> and I have added all the names that have been presented during this discussion so far.
> https://groups.google.com/d/msgid/metal3-dev/189758b1-3c41-8a09-446d-dee4d6fc8efa%40redhat.com<https://groups.google.com/d/msgid/metal3-dev/189758b1-3c41-8a09-446d-dee4d6fc8efa%40redhat.com> <https://groups.google.com/d/msgid/metal3-dev/189758b1-3c41-8a09-446d-dee4d6fc8efa%40redhat.com<https://groups.google.com/d/msgid/metal3-dev/189758b1-3c41-8a09-446d-dee4d6fc8efa%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>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/ad2f22cf-c392-40f1-91b0-aab09296d234n%40googlegroups.com<https://groups.google.com/d/msgid/metal3-dev/ad2f22cf-c392-40f1-91b0-aab09296d234n%40googlegroups.com> <https://groups.google.com/d/msgid/metal3-dev/ad2f22cf-c392-40f1-91b0-aab09296d234n%40googlegroups.com?utm_medium=email&utm_source=footer<https://groups.google.com/d/msgid/metal3-dev/ad2f22cf-c392-40f1-91b0-aab09296d234n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
>
> --
>
> Red Hat GmbH <https://www.redhat.com/de/global/dach<https://www.redhat.com/de/global/dach>>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany

> Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
> Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross
>
> --
> 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>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/CACNgkFyn7rNTw54LeCH6-h8881wxxVH7W30VTK0-XxPCU_CH8A%40mail.gmail.com<https://groups.google.com/d/msgid/metal3-dev/CACNgkFyn7rNTw54LeCH6-h8881wxxVH7W30VTK0-XxPCU_CH8A%40mail.gmail.com> <https://groups.google.com/d/msgid/metal3-dev/CACNgkFyn7rNTw54LeCH6-h8881wxxVH7W30VTK0-XxPCU_CH8A%40mail.gmail.com?utm_medium=email&utm_source=footer<https://groups.google.com/d/msgid/metal3-dev/CACNgkFyn7rNTw54LeCH6-h8881wxxVH7W30VTK0-XxPCU_CH8A%40mail.gmail.com?utm_medium=email&utm_source=footer>>.



--
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>.
To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/e368aeef-7729-4406-bb5f-75bc59aab87an%40googlegroups.com<https://groups.google.com/d/msgid/metal3-dev/e368aeef-7729-4406-bb5f-75bc59aab87an%40googlegroups.com?utm_medium=email&utm_source=footer>.



--

Red Hat GmbH<https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross


--

Red Hat GmbH<https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

--
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>.
To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/CACNgkFw0KpN%2BavPRsuNfmv7GtN8%3DWL%2B2EvL9sWDd1Kak1H4wFA%40mail.gmail.com<https://groups.google.com/d/msgid/metal3-dev/CACNgkFw0KpN%2BavPRsuNfmv7GtN8%3DWL%2B2EvL9sWDd1Kak1H4wFA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages