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

>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>