cloud-init team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

I don't know if you got a response to this elsewhere. I suspect you
did. It seems like you have come to the right assesment.  read_seeded
was just written well before there was the potential for network
config.

Seeding network config via local filesystem path makes sense enough,
but I think if you managed to put the files into the filesystem
somewhere than you could just have easily have seeded via
/var/lib/cloud/seed/nocloud.


On Wed, Jul 3, 2019 at 4:02 AM Conrad Hoffmann <ch@xxxxxxxxxxxxx> wrote:
>
> Hi there!
>
> I was attempting to use the nocloud data source with a custom seed dir
> including a network-config, but this did not seem to work. I think
> others may have had the same problem [1][2], so I decided to look into it.
>
> Just looking at the code path, the issue is rather obvious: when
> specifying e.g. `ds=nocloud;s=/` on the command line, cloud-init will
> use `util.read_seeded` [3] on that, which simply never looks for a
> network-config.
>
> As a first test, I replaced the call to `read_seeded` with one to
> `pathprefix2dict` alread used elsewhere in the data source. You can see
> the diff here [4]. This works for me, but I know this is not a solution:
> it would break the nocloud-net data source, as `pathprefix2dict` only
> operates on local files, whereas `read_seeded` handles URLs as well.
>
> Now, I will admit, I am not sure I have really understood the greater
> scheme of things with the various loading and merging of dicts in the
> nocloud datasource, but my guess would be that `read_seeded` (and in
> fact it's companion `read_optional_seed`) can be considered deprecated,
> as they do not handle network-config and their function signature does
> not allow adding that without touching all callers. Instead, I thought
> it might make sense to support URLs in `pathprefix2dict`?
>
> I'd be very happy to supply patches for this if someone can confirm that
> it makes sense or can point out a more appropriate approach.
>
> Thanks a lot for keeping all the clouds running,
> Conrad
>
> [1] https://bugs.launchpad.net/cloud-init/+bug/1809180
> [2] https://lists.launchpad.net/cloud-init/msg00188.html
> [3]
> https://git.launchpad.net/cloud-init/tree/cloudinit/sources/DataSourceNoCloud.py#n168
> [4]
> https://git.launchpad.net/~bitfehler/cloud-init/commit/?id=0735b3ea5489869b29fa50123564d45b4cdca6ca
>
> --
> Mailing list: https://launchpad.net/~cloud-init
> Post to     : cloud-init@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cloud-init
> More help   : https://help.launchpad.net/ListHelp