[Airship-discuss] IPAM for Airship

[Dmitry Ukov]

Alan,

This makes sense. Thanks for the idea! I did not actually look at the
problem from that point of view. Let's keep netconfig as a secret and it
will be annotated for ephemeral node

On Fri, Sep 20, 2019 at 10:20 PM MEADOWS, ALAN <am240k at att.com> wrote:

> 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 at mirantis.com]
> Sent: Friday, September 20, 2019 10:18 AM
> To: MEADOWS, ALAN <am240k at att.com>
> Cc: PACHECO, RODOLFO J <rp2723 at att.com>;
> airship-discuss at 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
> 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.
> 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
>
>

-- 
Kind regards
Dmitry Ukov
Principal Deployment Engineer
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190921/3af7733d/attachment.html>