Mmm... I can understand that you perhaps need an external scheduler for your own purposes, but I think you can't expect your plugin merged upstream for two reasons : - during Icehouse, there was an effort for not having the scheduler proxying to the compute nodes - Call for scheduler needs to go thru Nova-api and no endpoints are there got just scheduling
That said, once Gantt will be lifted, discussing about possible endpoints sounds reasonable to me. -Sylvain Le 14 août 2014 05:07, "zhiwei" <zhiw...@gmail.com> a écrit : > > Hi Jay. > > The case is: When heat create a stack, it will first call our scheduler(will pass image_id), our scheduler will get image metadata by image_id. > > Our scheduler will build a placement policy through image metadata, then start booting VM. > > > Thanks. > > > On Thu, Aug 14, 2014 at 10:28 AM, Jay Pipes <jaypi...@gmail.com> wrote: >> >> On 08/13/2014 10:22 PM, zhiwei wrote: >>> >>> Thanks Jay. >>> >>> The scheduler plugin is not a scheduler filter. >>> >>> We implemented a scheduler instead of using nova native scheduler. >> >> >> OK. Any reason why you did this? Without any details on what your scheduler does, it's tough to give advice on how to solve your problems. >> >> >>> One of our scheduler component need to fetch image metadata by image_id( >>> at this time, there is not instance ). >> >> >> Why? Again, the request_spec contains all the information you need about the image... >> >> Best, >> -jay >> >>> On Thu, Aug 14, 2014 at 9:29 AM, Jay Pipes <jaypi...@gmail.com >>> <mailto:jaypi...@gmail.com>> wrote: >>> >>> On 08/13/2014 08:31 PM, zhiwei wrote: >>> >>> Hi all, >>> >>> We wrote a nova schedule plugin that need to fetch image metadata by >>> image_id, but encountered one thing, we did not have the glance >>> context. >>> >>> Our solution is to configure OpenStack admin user and password to >>> nova.conf, as you know this is not good. >>> >>> So, I want to ask if there are any other ways to do this? >>> >>> >>> You should not have to do a separate fetch of image metadata in a >>> scheduler filter (which is what I believe you meant by "plugin" above?). >>> >>> The filter object's host_passes() method has a filter_properties >>> parameter that contains the request_spec, that in turn contains the >>> image, which in turn contains the image "metadata". You can access >>> it like so: >>> >>> def host_passes(self, host_state, filter_properties): >>> request_spec = filter_properties['request___spec'] >>> >>> image_info = request_spec['image'] >>> # Certain image attributes are accessed via top-level keys, like >>> # size, disk_format, container_format and checksum >>> image_size = image_info['size'] >>> # Other attributes can be accessed in the "properties" collection >>> # of key/value pairs >>> image_props = image.get('properties', {}) >>> for key, value in image_props.items(): >>> # do something... >>> >>> Best, >>> -jay >>> >>> >>> >>> _________________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.__org >>> <mailto:OpenStack-dev@lists.openstack.org> >>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev < 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 >>> >> >> >> _______________________________________________ >> 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev