The proposal to merge ~t0rrant/cloud-init:1819966-sysconfig-options into
cloud-init:master has been updated.
Status: Needs review => Work in progress
For more details, see:
https://code.launchpad.net/~t0rrant/cloud-init/+git/cloud-init/+merge/371948
--
Your team cloud-init Commiters is
For in-tree testing there are two main options; first writting unittests;
under tests/unitests/test_handlers/test_.py are most of the config
module tests.
For an integration test, the next best way is to build the package, via
./package/[brpm|bddeb] which can create a .rpm or deb you can
Hey Ryan,
I'm having trouble finding the best way to test the code, I can always launch a
full stack for this but that feels a bit overpowered for testing just one
module.
Is there any way I could test this on my development environment, for the
network in my first commit I could test it with
cloud-init really relies on networking in almost all cases; unless networking
config is disable, cloud-init is going to generate a network config for the
system and as I understand sysconfig, we will need to set NETWORKING=yes to
ensure that the OS networking service brings up networking.
The best way to update the /etc/sysconfig/network contents with custom values
is via the write_files in append mode.
A more robust solution would be to implement a config module: cc_sysconfig.py
which could read in existing files from /etc/sysconfig, parse them with
util.load_shell_content()
Hi Ryan,
> There is no direct integration in the module for dhcp provided ntp servers at
> this time. It's possible but there isn't a great interface (AFAIK) to query
> your OS for the dhcp response for a given interface.
sorry but I don't understand your comment. The proposed change has
There is no direct integration in the module for dhcp provided ntp servers at
this time. It's possible but there isn't a great interface (AFAIK) to query
your OS for the dhcp response for a given interface.
--
https://code.launchpad.net/~t0rrant/cloud-init/+git/cloud-init/+merge/371948
Your
Hi,
@Ryan: the `NTPSERVERARGS` was just an example from the original issue
#1819966, what got me there in the first place was that when I wrote anything
to `/etc/sysconfig/network` it was replaced by static content generated by
cloud-init's `render_network_state` function on reboot.
>From
does the cc_ntp module work alongside dhcp? what if your ntp servers are
obtained via dhcp?
--
https://code.launchpad.net/~t0rrant/cloud-init/+git/cloud-init/+merge/371948
Your team cloud-init commiters is requested to review the proposed merge of
~t0rrant/cloud-init:1819966-sysconfig-options
Hi Manual,
Thanks for creating a potential fix. The various network-config formats that
cloud-init handles don't lend themselves to writing arbitrary configuration
values to renderer specific files, in your case, the NTPSERVERARGS is a
sysconfig renderer specific value that doesn't have an
The proposal to merge ~t0rrant/cloud-init:1819966-sysconfig-options into
cloud-init:master has been updated.
Description changed to:
Added a new handle (handle_sysconfig) to deal with the new key.
Using the options passed in the cloud-init config file a /etc/sysconfig/network
file is
Manuel Torrinha has proposed merging
~t0rrant/cloud-init:1819966-sysconfig-options into cloud-init:master.
Commit message:
Added support for arbitrary options in sysconfig
These options should be added within the `sysconfig` key, as such:
```
network:
version: 2
sysconfig:
12 matches
Mail list logo
