Open Stack

Jiang,

I would like to reduce "magic"

1) We are using already RPC (because all compute nodes update are done in
DB via conductor (which means RPC call).
So count of RPC calls and size of msg will be the same.

2) There is no lazy load when you have to fetch all data about all compute
nodes on every request to scheduler.

3) Object models are off topic

Best regards,
Boris Pavlovic

Mirantis Inc.




On Fri, Jul 19, 2013 at 11:23 PM, Jiang, Yunhong <yunhong.jiang at intel.com>wrote:

>  Boris****
>
>        I think you in fact covered two topic, one is if use db or rpc for
> communication. This has been discussed a lot. But I didn’t find the
> conclusion. From the discussion,  seems the key thing is the fan out
> messages. I’d suggest you to bring this to scheduler sub meeting.****
>
> ** **
>
>
> http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-06-11-14.59.log.html
> ****
>
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg00070.html
> ****
>
> http://comments.gmane.org/gmane.comp.cloud.openstack.devel/23 ****
>
> ** **
>
>        The second topic is adding extra tables to compute nodes. I think
> we need the lazy loading for the compute node, and also I think with object
> model, we can further improve it if we utilize the compute node object.***
> *
>
> ** **
>
> Thanks****
>
> --jyh****
>
> ** **
>
> ** **
>
> *From:* Boris Pavlovic [mailto:boris at pavlovic.me]
> *Sent:* Friday, July 19, 2013 10:07 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Nova] New DB column or new DB table?****
>
>  ** **
>
> Hi all, ****
>
> ** **
>
> We have to much different branches about scheduler (so I have to repeat
> here also).****
>
> ** **
>
> I am against to add some extra tables that will be joined to compute_nodes
> table on each scheduler request (or adding large text columns).****
>
> Because it make our non scalable scheduler even less scalable. ****
>
> ** **
>
> Also if we just remove DB between scheduler and compute nodes we will get
> really good improvement in all aspects (performance, db load, network
> traffic, scalability )****
>
> And also it will be easily to use another resources provider (cinder,
> ceilometer e.g..) in Nova scheduler. ****
>
> ** **
>
> And one more thing this all could be really simple implement in current
> Nova, without big changes ****
>
>
> https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit?usp=sharing
> ****
>
> ** **
>
> ** **
>
> Best regards,****
>
> Boris Pavlovic ****
>
> ** **
>
> Mirantis Inc.****
>
> ** **
>
> On Fri, Jul 19, 2013 at 8:44 PM, Dan Smith <dms at danplanet.com> wrote:****
>
> > IIUC, Ceilometer is currently a downstream consumer of data from
> > Nova, but no functionality in Nova is a consumer of data from
> > Ceilometer. This is good split from a security separation point of
> > view, since the security of Nova is self-contained in this
> > architecture.
> >
> > If Nova schedular becomes dependant on data from ceilometer, then now
> > the security of Nova depends on the security of Ceilometer, expanding
> > the attack surface. This is not good architecture IMHO.****
>
> Agreed.****
>
>
> > At the same time, I hear your concerns about the potential for
> > duplication of stats collection functionality between Nova &
> > Ceilometer. I don't think we neccessarily need to remove 100% of
> > duplication. IMHO probably the key thing is for the virt drivers to
> > expose a standard API for exporting the stats, and make sure that
> > both ceilometer & nova schedular use the same APIs and ideally the
> > same data feed, so we're not invoking the same APIs twice to get the
> > same data.****
>
> I imagine there's quite a bit that could be shared, without dependency
> between the two. Interfaces out of the virt drivers may be one, and the
> code that boils numbers into useful values, as well as perhaps the
> format of the JSON blobs that are getting shoved into the database.
> Perhaps a ceilo-core library with some very simple primitives and
> definitions could be carved out, which both nova and ceilometer could
> import for consistency, without a runtime dependency?
>
> --Dan****
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
> ** **
>
> _______________________________________________
> 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/20130720/5c263858/attachment.html>