Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131014/7bfb8a99/attachment.html>