Hi Dina,
Le 14/10/2013 17:14, Dina Belova a écrit :
Hello everyone!
Guys, now we have Nova dependency in Climate like:
-f http://tarballs.openstack.org/nova/nova-master.tar.gz#egg=nova-master
nova>=master
That was done to implement Nova-based scheduler filter for physical
reservations and store its code in Climate project itself. Now Climate
is really light weighted project, that do not really need all these
deps connected wit Nova. Still, now that future filter is part of
Climate physical reservations logic.
I'm unsure the concern is only related to physical reservations. Let me
explain further.
Actually, for Climate v0.1, we would not need to deliver our own filter,
as we'll be relying on Pcloud filter [1] as we will have a 1:1 relation
in between a reservation and a pcloud.
As the pcloud is only provided with hosts when the lease starts, the
pcloud filter is giving results only when the lease is running. At the
end of the lease, the pcloud is deleted even if the hosts are still
running VMs, so the magic still does.
The clear reason why we need to provide a Lease Filter is that we don't
want to provide to end-users unclear messages : if the user is trying to
boot a VM using a pcloud UUID for a lease that hasn't started yet, he
should get an ERROR message "Sorry, the lease hasn't started yet"
instead of "Sorry, there is no hosts to match for your request".
That's actually a matter of having a deferred scheduling system, not
particularly related to physical hosts. Provided you would like to
provision an Heat stack *which would be scheduled when the lease starts,
and not when the lease is created*, you would have same concern. On the
implementation you're starting with, you won't have need for a filter,
but you can't assess it would be the case later on.
That's why we have the following question: do you think it's normal to
have such dependency there, or it will be better to create separate
repo like "climate-filters" and put there any filters and their
dependencies?
What can you advise?
Well, I don't have a clear opinion on that. The main pros for moving out
are :
1. Climate gate testing is less dependent on Nova
2. Build time for testing is quicker
On the other hand, the cons are :
1. Having two repos could mean duplicate work
2. There is need for maintaining a backwards compatibility in between
Climate and its filters (as there are two projects, like Nova and its
client)
3. We would be more documentation-dependent, as it's up to the
operator to deploy both Climate and Climate-filters for having physical
reservations working
Of course, I also feel pain when doing a tox -r on Climate as Nova is
pulling lots of dependencies, but I don't want to put complexity in
place just because I want to run faster my tests... :(
-Sylvain
Best regards,
Dina Belova
Software Engineer
Mirantis Inc.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
