7:25 a.m.
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.
8:52 a.m.
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(a)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(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
1 a.m.
On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro(a)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(a)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(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
6:49 a.m.
On 03/30 09:00, Yaniv Kaul wrote:
On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro(a)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(a)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(a)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(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
7:38 a.m.
On 30 March 2016 at 14:49, David Caro <dcaro(a)redhat.com> wrote:
On 03/30 09:00, Yaniv Kaul wrote:
> On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro(a)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?
8:52 a.m.
On Wed, Mar 30, 2016 at 3:38 PM, Barak Korren <bkorren(a)redhat.com> wrote:
On 30 March 2016 at 14:49, David Caro <dcaro(a)redhat.com>
wrote:
> On 03/30 09:00, Yaniv Kaul wrote:
>> On Tue, Mar 29, 2016 at 4:52 PM, David Caro <dcaro(a)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.
9:33 a.m.
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?
2:31 p.m.
On Wed, Mar 30, 2016 at 5:33 PM, Barak Korren <bkorren(a)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>
12:59 a.m.
On 30 March 2016 at 22:31, Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Wed, Mar 30, 2016 at 5:33 PM, Barak Korren
<bkorren(a)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...
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
2956
days inactive
2958
days old
8 comments
3 participants
participants (3)
-
Barak Korren -
David Caro -
Yaniv Kaul