'Persistent' IP addresses for the hosts
Can I ensure that in every run, host0 will get the same IP from the network IP pool? I'd imagine that they would, by the order of their init.json.in - but i'm not sure this is the case. TIA, Y.
On 03/29 15:25, Yaniv Kaul wrote:
Can I ensure that in every run, host0 will get the same IP from the network IP pool? I'd imagine that they would, by the order of their init.json.in - but i'm not sure this is the case.
They happen to be, but it's not by design, just coincidence. If at any point the json lib or python change any implementation details that might change. I see there's no way to add mapping*, though the code is there (just not used anywhere). * mapping == name-ip association in the dhcp pool Feel free to open an issue on it, should be relatively easy to enable
TIA, Y.
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro@redhat.com> wrote:
On 03/29 15:25, Yaniv Kaul wrote:
Can I ensure that in every run, host0 will get the same IP from the network IP pool? I'd imagine that they would, by the order of their init.json.in - but i'm not sure this is the case.
They happen to be, but it's not by design, just coincidence. If at any point the json lib or python change any implementation details that might change.
I see there's no way to add mapping*, though the code is there (just not used anywhere).
* mapping == name-ip association in the dhcp pool
Feel free to open an issue on it, should be relatively easy to enable
I wonder if my (abandoned, need to revive it) patch[1] would have helped. Should! Need to ensure that the order the VMs are executed is consistent though - not sure it is? I'd expect it to be in the order listed in the init.json.in file. Y.
TIA, Y.
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On 03/30 09:00, Yaniv Kaul wrote:
On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro@redhat.com> wrote:
On 03/29 15:25, Yaniv Kaul wrote:
Can I ensure that in every run, host0 will get the same IP from the network IP pool? I'd imagine that they would, by the order of their init.json.in - but i'm not sure this is the case.
They happen to be, but it's not by design, just coincidence. If at any point the json lib or python change any implementation details that might change.
I see there's no way to add mapping*, though the code is there (just not used anywhere).
* mapping == name-ip association in the dhcp pool
Feel free to open an issue on it, should be relatively easy to enable
I wonder if my (abandoned, need to revive it) patch[1] would have helped. Should! Need to ensure that the order the VMs are executed is consistent though - not sure it is?
Afaik we are completely relying on the json/yaml loader to provide the domains list, if we require it to be consistent, will have to check the libs
I'd expect it to be in the order listed in the init.json.in file. Y.
TIA, Y.
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On 30 March 2016 at 14:49, David Caro <dcaro@redhat.com> wrote:
On 03/30 09:00, Yaniv Kaul wrote:
On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro@redhat.com> wrote:
On 03/29 15:25, Yaniv Kaul wrote:
Can I ensure that in every run, host0 will get the same IP from the network IP pool? I'd imagine that they would, by the order of their init.json.in - but i'm not sure this is the case.
Keeping the IP fixed will mean you cannot start multiple environments on the same machine because you will have IP collisions. We may want to just have the last IP octet be fixed while the subnet address will be set according to which subnet is available on the host. Why do we want fixed addresses when we have name resolution working insode the environment anyway?
On Wed, Mar 30, 2016 at 3:38 PM, Barak Korren <bkorren@redhat.com> wrote:
On 30 March 2016 at 14:49, David Caro <dcaro@redhat.com> wrote:
On 03/30 09:00, Yaniv Kaul wrote:
On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro@redhat.com> wrote:
On 03/29 15:25, Yaniv Kaul wrote:
Can I ensure that in every run, host0 will get the same IP from the network IP pool? I'd imagine that they would, by the order of their init.json.in - but i'm not sure this is the case.
Keeping the IP fixed will mean you cannot start multiple environments on the same machine because you will have IP collisions. We may want to just have the last IP octet be fixed while the subnet address will be set according to which subnet is available on the host. Why do we want fixed addresses when we have name resolution working insode the environment anyway?
Keeping the IP fixed should be an option, not mandatory. The reason I need it is that I have an input file that needs the IP addresses of the hosts I'm running. Theoretically it should have supported host names, practically, it doesn't seem to work well with it :( Y.
Keeping the IP fixed should be an option, not mandatory. The reason I need it is that I have an input file that needs the IP
addresses of the hosts I'm running.
Theoretically it should have supported host names, practically, it doesn't seem to work well with it :( Y.
Maybe we can live-generate the file from the lago status output?
On Wed, Mar 30, 2016 at 5:33 PM, Barak Korren <bkorren@redhat.com> wrote:
Keeping the IP fixed should be an option, not mandatory. The reason I need it is that I have an input file that needs the IP
addresses of the hosts I'm running.
Theoretically it should have supported host names, practically, it doesn't seem to work well with it :( Y.
Maybe we can live-generate the file from the lago status output?
Indeed... <ugly-hack-not-tested-yet> with open('../robo.conf.in') as f: robo_conf_in = f.read() replacements = { '@HOST0@': prefix.virt_env.get_vm(_get_prefixed_name('host0').ip(), '@HOST1@': prefix.virt_env.get_vm(_get_prefixed_name('host1').ip(), '@HOST2@': prefix.virt_env.get_vm(_get_prefixed_name('host2').ip(), } for k, v in replacements.items(): robo_conf_out = robo_conf_in.replace(k, v, 1) with open('../robo.conf', 'w') as out: out.write(robo_conf_out) out.close() </ugly-hack-not-tested-yet>
On 30 March 2016 at 22:31, Yaniv Kaul <ykaul@redhat.com> wrote:
On Wed, Mar 30, 2016 at 5:33 PM, Barak Korren <bkorren@redhat.com> wrote:
Maybe we can live-generate the file from the lago status output?
Indeed...
<ugly-hack-not-tested-yet> with open('../robo.conf.in') as f: robo_conf_in = f.read()
replacements = { '@HOST0@': prefix.virt_env.get_vm(_get_prefixed_name('host0').ip(), '@HOST1@': prefix.virt_env.get_vm(_get_prefixed_name('host1').ip(), '@HOST2@': prefix.virt_env.get_vm(_get_prefixed_name('host2').ip(), } for k, v in replacements.items(): robo_conf_out = robo_conf_in.replace(k, v, 1)
with open('../robo.conf', 'w') as out: out.write(robo_conf_out) out.close()
</ugly-hack-not-tested-yet>
If you don't expect robo.conf.in to come from an untrusted source, consider using string.format with a dict rather then looping with string.replace. Also consider constructing the dict with a mapping comprehension expression looping over the hosts (See [1] for tutorial of the syntax, you can use the {..foo..} syntax if you don't care about Python 2.6 compatibility or the dict(...) syntax if you do) [1]: http://www.bogotobogo.com/python/python_dictionary_comprehension_with_zip_fr... -- Barak Korren bkorren@redhat.com RHEV-CI Team
participants (3)
-
Barak Korren -
David Caro -
Yaniv Kaul