On Thu, Dec 6, 2018 at 10:24 AM Mike Lykov <combr@ya.ru> wrote:

05.12.2018 13:04, Eitan Raviv пишет:
> After further investigation I would like to share one more important
> piece of information that explains the "reset" behaviour of the network
> configuration:

Thanks for that detailed clarification.

> When a VM is started in 'Run once' mode, the initialization parameters
> supplied for that run are always passed by engine to cloud-init in the
> guest for application.

It's clear and work as intended.

> But if a VM is started in 'Run' mode, the initialization parameters are
> passed to cloud-init on the guest only if this is the first run (be it
> 'Run' or 'Run once'). On every consecutive run in 'Run' mode no
> parameters are passed to the guest, and therefore (as I quoted from the
> cloud-init documentation earlier in this thread) cloud-init falls back
> to DHCP configuration on the guest.

> When this behaviour was introduced into engine the reasoning was that
> after the initial configuration of the VM, there is no reason to resend
> the configuration on every 'Run' but only on 'Run once'.

Yes, there is no reason, but for new user it looks very confusing:
- create VM
- configure cloud-init parameters (like IP addr)
- Run VM (not once), parameters applied (all OK? as it seems)
- work with/in VM
- Stop VM (maybe after period of time when VM counts as 'configured
successfully') for some maintetance
- Run VM and try to access it (it is 'configured successfully' some
time ago, isn't it?)
- NO ACCESS to VM and configurаtion is LOST
- try to access via console with 'WTF?' exclamation ....

Why cloud-init in this scenario after successful configuration is not
turn off/disable himself (by touch that file, for example) ?

Instead of it cloud-init+ovirt force user to:
- try to figure why configuration is lost, learn "custom script" format
- write "custom script" for touch /etc/cloud/cloud-init.disabled and
reboot
- run once VM to apply parameters
- run VM as usual ?

> Due to the behaviour of the current cloud-init package, this causes an
> unexpected side effect that should be dealt with by disabling cloud-init
> in one of the methods I described earlier in this thread.

Are there use cases when cloud-init (as a service) may require to start
repeatedly on consecutive usual VM runs?
If will need to change parameters user may use "Run Once" start with new
parameters - in this case a 'disabled' file may be ignored.
But what reason to finding a configuration while usual run at all?

--
BR, Mike

>
> On Wed, Nov 28, 2018 at 10:12 AM Eitan Raviv <eraviv@redhat.com
> <mailto:eraviv@redhat.com>> wrote:
>
> On Wed, Nov 28, 2018 at 7:29 AM Mike Lykov <combr@ya.ru
> <mailto:combr@ya.ru>> wrote:
> >
> > 27.11.2018 16:15, Eitan Raviv пишет:
> > > According to cloud-init 0.7.9 documentation cloud-init is
> configured
> > > to run by default on each boot [1] and to render the user-selected
> > > network configuration on first boot [2]. Also, in absence of a data
> > > source to configure the network, it will fall back to
> configuring DHCP
> > > on eth0 [2].
> > >
> > > As you noted, if you run a VM once, and then in the next
> regular run
> > > the cloud-init flag is not selected in the VM configuration in
> engine,
> > > there is no data-source and cloud-init falls back to dhcp as
> > > documented.
> >
> > Thanks for the explanation. What intended use of this
> subsystem/feature
> > are supposed to?
> >
> > My setup is not in cloud, it's local and use static IP adresses
> for VM.
> > I do not want to configure each VM network in console by hand.
> > I create VM from template (template have installed cloud-init
> package),
> > configure cloud-init hostname/eth0 network in engine, and as "custom
> > script" (at the same moment) I set a "touch
> > /etc/cloud/cloud-init.disabled" ?
>
> Either that or add custom script to disable just cloud-init network
> re-config as you did manually.
> Please consult the documentation for the custom script syntax and format
> (e.g. search for 'runcmd' in
> https://cloudinit.readthedocs.io/en/0.7.9/topics/examples.html)
>
> > Then I "Run once" a VM, stop it, and run as usual without data source
> > and fallback.
> > Or I name network interface not "eth0" and therefore without need for
> > custom script?
>
> I did not test the outcome of assigning the static IP to another NIC.
> Just sharing a thought...
>
> >
> >
> > > The 'marker' file you refer to are also documented as follows:
> > >
> > > * disabling cloud-init altogether [1] with: touch
> /etc/cloud/cloud-init.disabled
> > > * preventing cloud-init from configuring the network [2] with: echo
> > > ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg
> > > whichever scenario is used to run a VM, this can be accomplished by
> > > adding the above commands to the custom_script that cloud-init
> runs at
> > > the last stage of its operation [3].
> > >
> > > There is possibly a third 'hack' that would not require any
> marker file:
> > > * assign your static IP to a NIC not named 'eth0'
> > > I have not tested it myself but it looks like a corollary of [2]
> > >
> > > HTH
> > >
> > > [1]
> https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator
> > > [2]
> https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local
> > > [3]
> https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final
> > >
> > > On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru
> <mailto:combr@ya.ru>> wrote:
> > >>
> > >> 20.11.2018 15:30, Mike Lykov пишет:
> > >>
> > >>> "cloud-init used to use a "marker" file that it created on
> initial
> > >>> execution. If that "marker" file existed it would not rerun
> on reboot. "
> > >>> - are it not working in ovirt/this cloud-init version ?
> > >>
> > >> new restart:
> > >>
> > >> ----------
> > >> 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if
> files that
> > >> we need already exist from a previous run that would allow us
> to stop early.
> > >> 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no
> > >> previous run detected that would allow us to stop early.
> > >> -------------
> > >>
> > >> which files it try to find ?
> > >>
> > >> --
> > >> Mike
> > >>
> > >> _______________________________________________
> > >> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
> > >> To unsubscribe send an email to users-leave@ovirt.org
> <mailto:users-leave@ovirt.org>
> > >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > >> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > >> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5DWNRQZ3VPRWPFYMOLT/
> > > _______________________________________________
> > > Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
> > > To unsubscribe send an email to users-leave@ovirt.org
> <mailto:users-leave@ovirt.org>
> > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > > oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > > List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS2TA2B6FILCNIYPHAW5/
> > >
> >
>
>
> _______________________________________________
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-leave@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ORAWKILE2YBG3VIAICI3SWSKTVYSOGGF/
>
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UXIU527YFPFD7MAWEMNO4V72DYOH3PVX/