Rodolfo, Thanks for the links. This is what is needed for ephemeral node! What is about target cluster nodes? We need to manage their network configuration some how (assign IPs, set up bonding etc). MAAS is used as IPAM service in Airship 1.0 but it will be replaced in favor of Metal3. So we may want to have the same mechanism of ip allocation for ephemeral cluster and for target cluster. On Fri, Sep 20, 2019 at 7:47 PM PACHECO, RODOLFO J <rp2723@att.com> wrote:

Forgot to add, Jerome’s POC has an example that looks closer to a CR expectations https://github.com/keleustes/treasuremap/blob/kustomize/site/seaworthy/netwo...

Regards

*Rodolfo Pacheco*

*Home/Office* 732 5337671

*From: *"PACHECO, RODOLFO J" <rp2723@att.com> *Date: *Friday, September 20, 2019 at 11:40 AM *To: *Dmitry Ukov <dukov@mirantis.com>, " airship-discuss@lists.airshipit.org" <airship-discuss@lists.airshipit.org> *Subject: *Re: [Airship-discuss] IPAM for Airship

Dmitry

In Airship 1.0 we had such a document . I expect for 2.0 we need an equivalent CR for this type of information

Is what we have been calling Catalog or DB like Document’s

Here is an example from treasuremap

https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/net...

I think that is what you are thinking about.

Regards

*Rodolfo Pacheco*

*Home/Office* 732 5337671

*From: *Dmitry Ukov <dukov@mirantis.com> *Date: *Friday, September 20, 2019 at 11:37 AM *To: *"airship-discuss@lists.airshipit.org" < airship-discuss@lists.airshipit.org> *Subject: *[Airship-discuss] IPAM for Airship

Hello,

I'm working on cloud-init generator as a part of airshipctl bootstrap isogen command.

This cloud init will be used to deploy K8s on ephemeral node.

Following information is needed to set up ephemeral node:

- IP address - Net mask - Default Gateway - DNS server address

There is no CRD/CR that actually has this information. For example BareMetalHost resource has IP and Netmask as a part of Status field (and determined dynamically by beremetal operator) and there is no info about Default GW and DNS.

This actually leads us to the situation where we need to have IPAM (ip address management) operator and appropriate CRs/CRDs.

Unfortunately there is not much IPAM services that can act as K8s operator (I've found only one actually https://github.com/inwinstack/ipam <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_inwinstack_ipam&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=c8c5DfwYKVyHfFy7VcpEn5JOI4G1u4qxCaCy9cDsgAI&s=d7costGUiy-0u1vBkTFbV8Gf4-BIyHE3PGYKZ49NK7k&e=> and it has limitations I guess).

As an alternative we have to implement IPAM as a part of Airship 2.0.

What do you think?

--

Kind regards

Dmitry Ukov

Principal Deployment Engineer

Mirantis, Inc.

-- Kind regards Dmitry Ukov Principal Deployment Engineer Mirantis, Inc.

I think we may intertwining two separate needs. The first and most urgent need is to understand how we will declare the static IP assignments for each baremetal host up front, much like we do within Airship 1.0. I disagree that MaaS behaves as an IPAM service – for the most part all it does is enforce the static assignments we declare within Drydock BaremetalNode documents as in here: https://github.com/airshipit/treasuremap/blob/master/site/seaworthy/baremeta... I missed the latest bootstrap-sig call, however when we were initially discussing this one very simple way to get started with this is to represent the network configuration as cloud-init data in the BareMetalHost (BMH) CRD. There is support for that now without introducing any additional CRDs or fields. The second need you are addressing, where files/CRs like “common-addresses” become more important and have definitions for all the various subnets--abstracted from specific machines, is supporting a more liberal IP assignment mechanism in Airship 2.0, where users need only define subnets, and we can support allocating addresses automatically. This is where IPAM truly becomes a requirement but I think it is premature to look at this and feel this may be a subsequent step to delivering static functionality. Alan Meadows From: PACHECO, RODOLFO J Sent: Friday, September 20, 2019 9:07 AM To: Dmitry Ukov <dukov@mirantis.com> Cc: airship-discuss@lists.airshipit.org Subject: Re: [Airship-discuss] IPAM for Airship Agree, we expect the document that defines this information to be generic. Meaning it will be used by both ephemeral and target clusters. Regards Rodolfo Pacheco Home/Office 732 5337671 From: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>> Date: Friday, September 20, 2019 at 11:49 AM To: "PACHECO, RODOLFO J" <rp2723@att.com<mailto:rp2723@att.com>> Cc: "airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>" <airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>> Subject: Re: [Airship-discuss] IPAM for Airship Rodolfo, Thanks for the links. This is what is needed for ephemeral node! What is about target cluster nodes? We need to manage their network configuration some how (assign IPs, set up bonding etc). MAAS is used as IPAM service in Airship 1.0 but it will be replaced in favor of Metal3. So we may want to have the same mechanism of ip allocation for ephemeral cluster and for target cluster. On Fri, Sep 20, 2019 at 7:47 PM PACHECO, RODOLFO J <rp2723@att.com<mailto:rp2723@att.com>> wrote: Forgot to add, Jerome’s POC has an example that looks closer to a CR expectations https://github.com/keleustes/treasuremap/blob/kustomize/site/seaworthy/networks/common-addresses.yaml<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_keleustes_treasuremap_blob_kustomize_site_seaworthy_networks_common-2Daddresses.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=eSPJlb86ECKHCgBeXNfbCrcBGq7doKl90sZz1JU-HJM&s=5hGWlv6RN10N-cPbl_8lnzrGFZRmONETR55X1GdKN7g&e=> Regards Rodolfo Pacheco Home/Office 732 5337671 From: "PACHECO, RODOLFO J" <rp2723@att.com<mailto:rp2723@att.com>> Date: Friday, September 20, 2019 at 11:40 AM To: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>>, "airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>" <airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>> Subject: Re: [Airship-discuss] IPAM for Airship Dmitry In Airship 1.0 we had such a document . I expect for 2.0 we need an equivalent CR for this type of information Is what we have been calling Catalog or DB like Document’s Here is an example from treasuremap https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/networks/common-addresses.yaml<https://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_airship_treasuremap_src_branch_master_site_seaworthy_networks_common-2Daddresses.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=eSPJlb86ECKHCgBeXNfbCrcBGq7doKl90sZz1JU-HJM&s=wvOJ_Dykh2xTn3clmits97RK3Pk5sSKbS6JAdw8eE1s&e=> I think that is what you are thinking about. Regards Rodolfo Pacheco Home/Office 732 5337671 From: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>> Date: Friday, September 20, 2019 at 11:37 AM To: "airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>" <airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>> Subject: [Airship-discuss] IPAM for Airship Hello, I'm working on cloud-init generator as a part of airshipctl bootstrap isogen command. This cloud init will be used to deploy K8s on ephemeral node. Following information is needed to set up ephemeral node: * IP address * Net mask * Default Gateway * DNS server address There is no CRD/CR that actually has this information. For example BareMetalHost resource has IP and Netmask as a part of Status field (and determined dynamically by beremetal operator) and there is no info about Default GW and DNS. This actually leads us to the situation where we need to have IPAM (ip address management) operator and appropriate CRs/CRDs. Unfortunately there is not much IPAM services that can act as K8s operator (I've found only one actually https://github.com/inwinstack/ipam<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_inwinstack_ipam&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=c8c5DfwYKVyHfFy7VcpEn5JOI4G1u4qxCaCy9cDsgAI&s=d7costGUiy-0u1vBkTFbV8Gf4-BIyHE3PGYKZ49NK7k&e=> and it has limitations I guess). As an alternative we have to implement IPAM as a part of Airship 2.0. What do you think? -- Kind regards Dmitry Ukov Principal Deployment Engineer Mirantis, Inc. -- Kind regards Dmitry Ukov Principal Deployment Engineer Mirantis, Inc.

Dmitry, To be clear I see three phases to this effort: 1) Just put the cloud-init for network config verbatim in the BMH doc for the advanced network configuration (or rather in the example below, within a secret referenced by the BMH doc – as is the metal3-io approach today). 2) Put the intended network configuration data in another CR, or enhance BMH CRD to store it separately and then generate the appropriate cloud-init data to configure the networking – potentially leveraging some of the hardware detected by ironic hardware inventory discovery to help with that process. I think this is what you’re currently thinking but I think we may be going a step ahead of what’s required initially. This is my main point. 3) Finally, I think the last phase is introducing IPAM support so users do not have to explicitly define every interface address for hosts – airship, an ipam operator, or whatever can help identify the next available. The baremetalhost_types you refer to would be populated by ironic inventory. I think trying to represent the network configuration in some structured way, and potentially use some of the hardware configuration discovered as well, in order to generate cloud-init is more in-line with #2 above. Really, I’m talking about #1 right now and to be specific about what I’m suggesting, let me propose the following simple solution. Imagine a baremetal Ubuntu host (which we can easily imitate with virtual machines). For this example, let’s pretend we want this host to have two interfaces – ens1 and ens4 -- both with static addresses. You can obviously expand this simple example to account for N interfaces, with bonding, VLANs, and so on. I would have the following cloud-init for my theoretical “host10”: #cloud-config write_files: - path: /etc/network/interfaces.d/10-ens1.cfg owner: root:root permissions: '0644' content: | auto ens1 iface ens1 inet static address 10.1.1.10 netmask 255.255.255.0 gateway 10.1.1.1 - path: /etc/network/interfaces.d/11-ens4.cfg owner: root:root permissions: '0644' content: | auto ens4 iface ens4 inet static address 10.4.1.10 netmask 255.255.255.0 runcmd: - [ ifup, ens1] - [ ifup, ens4] I would create a Secret for this user-data, “host10-user-data”. This would theoretically be where this is stored declaratively as a document in my set. apiVersion: v1 data: userData: $(base64 -w 0 <<data above>>) kind: Secret metadata: name: host10-user-data namespace: metal3 type: Opaque I would create a BMH CR for host10: apiVersion: v1 kind: Secret metadata: name: host10-bmc-secret type: Opaque data: username: YWRtaW4= password: cGFzc3dvcmQ= --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: host10 spec: online: true bootMACAddress: 00:3b:8b:0c:ec:8b bmc: address: ipmi://192.168.111.1:6230 credentialsName: master-0-bmc-secret userData: name: host10-user-data namespace: metal3 --- At this point, what I’ve done is fully declare the advanced network configuration for “host10” within the constraints of what exists today – in other words, this works right now in metal3-io. I could extract this cloud-init for whatever host is being used as the ephemeral host as well for use in ISO generation. My point is basically I think going with #1 now so we can achieve E2E functionality seems like the most expedient approach. Let me know if any aspect of this doesn’t make sense. Alan Meadows From: Dmitry Ukov [mailto:dukov@mirantis.com] Sent: Friday, September 20, 2019 10:18 AM To: MEADOWS, ALAN <am240k@att.com> Cc: PACHECO, RODOLFO J <rp2723@att.com>; airship-discuss@lists.airshipit.org Subject: Re: [Airship-discuss] IPAM for Airship Alan,

MaaS behaves as an IPAM service – for the most part all it does is enforce the static assignments we declare within Drydock BaremetalNode documents as in here: https://github.com/airshipit/treasuremap/blob/master/site/seaworthy/baremetal/nodes.yaml#L48-L86<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_airshipit_treasuremap_blob_master_site_seaworthy_baremetal_nodes.yaml-23L48-2DL86&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OI-s0Rr_BtNj0OcKWGZyuA&m=j4XnOJ5N_gtPrZSJlEi7x4Gdbn474aeBXiNi4oyXMIo&s=CT5Rs_ulfgsRJ_aRLjbQn9cMYSNnTrEj1DnUfBUVmkU&e=> I've missed this part :(

I missed the latest bootstrap-sig call, however when we were initially discussing this one very simple way to get started with this is to represent the network configuration as cloud-init data in the BareMetalHost (BMH) CRD. There is support for that now without introducing any additional CRDs or fields. Unfortunately BareMetalHost does not have all information. Here is what is supported https://github.com/metal3-io/baremetal-operator/blob/master/pkg/apis/metal3/v1alpha1/baremetalhost_types.go#L249<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_metal3-2Dio_baremetal-2Doperator_blob_master_pkg_apis_metal3_v1alpha1_baremetalhost-5Ftypes.go-23L249&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OI-s0Rr_BtNj0OcKWGZyuA&m=j4XnOJ5N_gtPrZSJlEi7x4Gdbn474aeBXiNi4oyXMIo&s=-4AQiMysvbUC-zagc0GLr9UMPmjY6bq3tTIFLZHJEW8&e=>. NIC structure is assigned as a property of HardwareDetails structure which is associated to Status property of BareMetalHost. AFAIK Status property is not supposed to be a source of data for CR defined in operator, it's filled in after reconcile event checks resource status. So technically we can not use this property for data. Moreover there is not Default gw and dns server setting.

As an alternative temporary solution (until we decide what to do with IPAM) we can put DNS server in a cluster config (i.e. airshipctl config) or supply it as CLI flag for isogen and calculate default gateway as a first address of a network On Fri, Sep 20, 2019 at 8:14 PM MEADOWS, ALAN <am240k@att.com<mailto:am240k@att.com>> wrote: I think we may intertwining two separate needs. The first and most urgent need is to understand how we will declare the static IP assignments for each baremetal host up front, much like we do within Airship 1.0. I disagree that MaaS behaves as an IPAM service – for the most part all it does is enforce the static assignments we declare within Drydock BaremetalNode documents as in here: https://github.com/airshipit/treasuremap/blob/master/site/seaworthy/baremetal/nodes.yaml#L48-L86<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_airshipit_treasuremap_blob_master_site_seaworthy_baremetal_nodes.yaml-23L48-2DL86&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OI-s0Rr_BtNj0OcKWGZyuA&m=j4XnOJ5N_gtPrZSJlEi7x4Gdbn474aeBXiNi4oyXMIo&s=CT5Rs_ulfgsRJ_aRLjbQn9cMYSNnTrEj1DnUfBUVmkU&e=> I missed the latest bootstrap-sig call, however when we were initially discussing this one very simple way to get started with this is to represent the network configuration as cloud-init data in the BareMetalHost (BMH) CRD. There is support for that now without introducing any additional CRDs or fields. The second need you are addressing, where files/CRs like “common-addresses” become more important and have definitions for all the various subnets--abstracted from specific machines, is supporting a more liberal IP assignment mechanism in Airship 2.0, where users need only define subnets, and we can support allocating addresses automatically. This is where IPAM truly becomes a requirement but I think it is premature to look at this and feel this may be a subsequent step to delivering static functionality. Alan Meadows From: PACHECO, RODOLFO J Sent: Friday, September 20, 2019 9:07 AM To: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>> Cc: airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org> Subject: Re: [Airship-discuss] IPAM for Airship Agree, we expect the document that defines this information to be generic. Meaning it will be used by both ephemeral and target clusters. Regards Rodolfo Pacheco Home/Office 732 5337671 From: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>> Date: Friday, September 20, 2019 at 11:49 AM To: "PACHECO, RODOLFO J" <rp2723@att.com<mailto:rp2723@att.com>> Cc: "airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>" <airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>> Subject: Re: [Airship-discuss] IPAM for Airship Rodolfo, Thanks for the links. This is what is needed for ephemeral node! What is about target cluster nodes? We need to manage their network configuration some how (assign IPs, set up bonding etc). MAAS is used as IPAM service in Airship 1.0 but it will be replaced in favor of Metal3. So we may want to have the same mechanism of ip allocation for ephemeral cluster and for target cluster. On Fri, Sep 20, 2019 at 7:47 PM PACHECO, RODOLFO J <rp2723@att.com<mailto:rp2723@att.com>> wrote: Forgot to add, Jerome’s POC has an example that looks closer to a CR expectations https://github.com/keleustes/treasuremap/blob/kustomize/site/seaworthy/networks/common-addresses.yaml<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_keleustes_treasuremap_blob_kustomize_site_seaworthy_networks_common-2Daddresses.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=eSPJlb86ECKHCgBeXNfbCrcBGq7doKl90sZz1JU-HJM&s=5hGWlv6RN10N-cPbl_8lnzrGFZRmONETR55X1GdKN7g&e=> Regards Rodolfo Pacheco Home/Office 732 5337671 From: "PACHECO, RODOLFO J" <rp2723@att.com<mailto:rp2723@att.com>> Date: Friday, September 20, 2019 at 11:40 AM To: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>>, "airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>" <airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>> Subject: Re: [Airship-discuss] IPAM for Airship Dmitry In Airship 1.0 we had such a document . I expect for 2.0 we need an equivalent CR for this type of information Is what we have been calling Catalog or DB like Document’s Here is an example from treasuremap https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/networks/common-addresses.yaml<https://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_airship_treasuremap_src_branch_master_site_seaworthy_networks_common-2Daddresses.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=eSPJlb86ECKHCgBeXNfbCrcBGq7doKl90sZz1JU-HJM&s=wvOJ_Dykh2xTn3clmits97RK3Pk5sSKbS6JAdw8eE1s&e=> I think that is what you are thinking about. Regards Rodolfo Pacheco Home/Office 732 5337671 From: Dmitry Ukov <dukov@mirantis.com<mailto:dukov@mirantis.com>> Date: Friday, September 20, 2019 at 11:37 AM To: "airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>" <airship-discuss@lists.airshipit.org<mailto:airship-discuss@lists.airshipit.org>> Subject: [Airship-discuss] IPAM for Airship Hello, I'm working on cloud-init generator as a part of airshipctl bootstrap isogen command. This cloud init will be used to deploy K8s on ephemeral node. Following information is needed to set up ephemeral node: * IP address * Net mask * Default Gateway * DNS server address There is no CRD/CR that actually has this information. For example BareMetalHost resource has IP and Netmask as a part of Status field (and determined dynamically by beremetal operator) and there is no info about Default GW and DNS. This actually leads us to the situation where we need to have IPAM (ip address management) operator and appropriate CRs/CRDs. Unfortunately there is not much IPAM services that can act as K8s operator (I've found only one actually https://github.com/inwinstack/ipam<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_inwinstack_ipam&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=c8c5DfwYKVyHfFy7VcpEn5JOI4G1u4qxCaCy9cDsgAI&s=d7costGUiy-0u1vBkTFbV8Gf4-BIyHE3PGYKZ49NK7k&e=> and it has limitations I guess). As an alternative we have to implement IPAM as a part of Airship 2.0. What do you think? -- Kind regards Dmitry Ukov Principal Deployment Engineer Mirantis, Inc. -- Kind regards Dmitry Ukov Principal Deployment Engineer Mirantis, Inc. -- Kind regards Dmitry Ukov Principal Deployment Engineer Mirantis, Inc.

Dmitry, To be clear I see three phases to this effort: 1) Just put the cloud-init for network config verbatim in the BMH doc  for the advanced network configuration (or rather in the example below, within a secret referenced by the BMH doc – as is the metal3-io approach today). 2) Put the intended network configuration data in another CR, or enhance BMH CRD to store it separately and then generate the appropriate cloud-init data to configure the networking – potentially leveraging some of the hardware detected by ironic hardware inventory discovery to help with that process.  I think this is what you’re currently thinking but I think we may be going a step ahead of what’s required initially.  This is my main point. 3) Finally, I think the last phase is introducing IPAM support so users do not have to explicitly define every interface address for hosts – airship, an ipam operator, or whatever can help identify the next available. The baremetalhost_types you refer to would be populated by ironic inventory.  I think trying to represent the network configuration in some structured way, and potentially use some of the hardware configuration discovered as well, in order to generate cloud-init is more in-line with #2 above. Really, I’m talking about #1 right now and to be specific about what I’m suggesting, let me propose the following simple solution.  Imagine a baremetal Ubuntu host (which we can easily imitate with virtual machines).  For this example, let’s pretend we want this host to have two interfaces – ens1 and ens4 -- both with static addresses.  You can obviously expand this simple example to account for N interfaces, with bonding, VLANs, and so on. I would have the following cloud-init for my theoretical “host10”: #cloud-config write_files: - path: /etc/network/interfaces.d/10-ens1.cfg   owner: root:root   permissions: '0644'   content: |     auto ens1     iface ens1 inet static         address 10.1.1.10         netmask 255.255.255.0         gateway 10.1.1.1 - path: /etc/network/interfaces.d/11-ens4.cfg   owner: root:root   permissions: '0644'   content: |     auto ens4     iface ens4 inet static         address 10.4.1.10         netmask 255.255.255.0 runcmd: - [ ifup, ens1] - [ ifup, ens4] I would create a Secret for this user-data, “host10-user-data”.  This would theoretically be where this is stored declaratively as a document in my set. apiVersion: v1 data:   userData: $(base64 -w 0 <<data above>>) kind: Secret metadata:   name: host10-user-data   namespace: metal3 type: Opaque I would create a BMH CR for host10: apiVersion: v1 kind: Secret metadata:   name: host10-bmc-secret type: Opaque data:   username: YWRtaW4=   password: cGFzc3dvcmQ= --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata:   name: host10 spec:   online: true   bootMACAddress: 00:3b:8b:0c:ec:8b   bmc:     address: ipmi://192.168.111.1:6230     credentialsName: master-0-bmc-secret   userData:     name: host10-user-data     namespace: metal3 --- At this point, what I’ve done is fully declare the advanced network configuration for “host10” within the constraints of what exists today – in other words, this works right now in metal3-io.  I could extract this cloud-init for whatever host is being used as the ephemeral host as well for use in ISO generation. My point is basically I think going with #1 now so we can achieve E2E functionality seems like the most expedient approach. Let me know if any aspect of this doesn’t make sense. Alan Meadows From: Dmitry Ukov [mailto:dukov@mirantis.com] Sent: Friday, September 20, 2019 10:18 AM To: MEADOWS, ALAN <am240k@att.com> Cc: PACHECO, RODOLFO J <rp2723@att.com>; airship-discuss@lists.airshipit.org Subject: Re: [Airship-discuss] IPAM for Airship Alan, 

 MaaS behaves as an IPAM service – for the most part all it does is enforce the static assignments we declare within Drydock BaremetalNode documents as in here: https://github.com/airshipit/treasuremap/blob/master/site/seaworthy/baremeta... I've missed this part :(

I missed the latest bootstrap-sig call, however when we were initially discussing this one very simple way to get started with this is to represent the network configuration as cloud-init data in the BareMetalHost  (BMH) CRD.  There is support for that now without introducing any additional CRDs or fields. Unfortunately BareMetalHost does not have all information. Here is what is supported https://github.com/metal3-io/baremetal-operator/blob/master/pkg/apis/metal3/.... NIC structure is assigned as a property of HardwareDetails structure which is associated to Status property of BareMetalHost. AFAIK Status property is not supposed to be a source of data for CR defined in operator, it's filled in after reconcile event checks resource status. So technically we can not use this property for data. Moreover there is not Default gw and dns server setting. 

As an alternative temporary solution (until we decide what to do with IPAM) we can put DNS server in a cluster config (i.e. airshipctl config) or supply it as CLI flag for isogen and calculate default gateway as a first address of a network