<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013年12月24日 07:35, Ian Wells wrote:<br>
</div>
<blockquote
cite="mid:CAPoubz6ysmwCX2qLieMevyQ51f7-b=4PVc1A34XT406d+J-aOg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div>On autodiscovery and configuration, we agree that each
compute node finds out what it has based on some sort of list
of match expressions; we just disagree on where they should
live.<br>
</div>
</div>
</blockquote>
i think what we talk is group/class auto discovery here. <br>
<blockquote
cite="mid:CAPoubz6ysmwCX2qLieMevyQ51f7-b=4PVc1A34XT406d+J-aOg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
I know we've talked APIs for setting that matching expression,
but I would prefer that compute nodes are responsible for
their own physical configuration - generally this seems wiser
on the grounds that configuring new hardware correctly is a
devops problem and this pushes the problem into the installer,
clear devops territory. It also makes the (I think likely)
assumption that the config may differ per compute node without
having to add more complexity to the API with host aggregates
and so on. And it means that a compute node can start working
without consulting the central database or reporting its
entire device list back to the central controller.<br>
</div>
</div>
</blockquote>
let's wait Nova core comments about this.<br>
<blockquote
cite="mid:CAPoubz6ysmwCX2qLieMevyQ51f7-b=4PVc1A34XT406d+J-aOg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<br>
</div>
<div>On PCI groups, I think it is a good idea to have them
declared centrally (their name, not their content). Now, I
would use config to define them and maybe an API for the
tenant to list their names, personally; that's simpler and
easier to implement and doesn't preclude adding an (admin) API
in the future. But I don't imagine the list of groups will
change frequently so any update API would be very infrequently
used, and if someone really feels they want to implement it
I'm not going to stop them.<br>
</div>
</div>
</blockquote>
if you try setup a only a name for the group, how about current pci
alias? We don't need create new terminology for this. and alias can
use to specify groups, but we want kill alias, seems it come back
to our discussion.<br>
<blockquote
cite="mid:CAPoubz6ysmwCX2qLieMevyQ51f7-b=4PVc1A34XT406d+J-aOg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
</div>
<div><br>
On nova boot, I completely agree that we need a new argument
to --nic to specify the PCI group of the NIC. The rest of the
arguments - I'm wondering if we could perhaps do this in two
stages:<br>
</div>
</div>
</blockquote>
agree. <br>
<br>
<blockquote
cite="mid:CAPoubz6ysmwCX2qLieMevyQ51f7-b=4PVc1A34XT406d+J-aOg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>1. Neutron will read those arguments (attachment type,
additional stuff like port group where relevant) from the port
during an attach and pass relevant information to the plugging
driver in Nova<br>
</div>
<div>2. We add a feature to nova so that you can specify other
properties in the --nic section line and they're passed
straight to the port-create called from within nova.<br>
<br>
</div>
<div>This is not specific to passthrough at all, just a useful
general purpose feature. However, it would simplify both the
problem and design here, because these parameters, whatever
they are, are now entirely the responsibility of Neutron and
Nova's simply transporting them into it. A PCI aware Neutron
will presumably understand the attachment type, the port group
and so on, or will reject them if they're meaningless to it,
and we've even got room for future expansion without changing
Nova or Neutron, just the plugin. We can propose it now and
independently, put in a patch and have it ready before we need
it. I think anything that helps to clarify and divide the
responsibilities of Nova and Neutron will be helpful, because
then we don't end up with too many cross-project-interrelated
patches.<br>
<br>
</div>
<div>I'm going to ignore the allocation problem for now. If a
single user can allocate all the NICs in the cluster to
himself, we still have a more useful solution than the one now
where he can't use them, so it's not the top of our list.<br>
</div>
<div><br>
<br>
</div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div
style="font-size:14px;font-family:Calibri,sans-serif">
<font style="font-size:medium;text-align:left"
face="Calibri,sans-serif">Time seems to be running
out for Icehouse. We need to come to agreement
ASAP. I will be out from wednesday until after new
year. I'm thinking that to move it forward after
the new year, we may need to have the IRC meeting
in a daily basis until we </font><span
style="font-size:medium;text-align:left;font-family:Calibri">reach</span><font
style="font-size:medium;text-align:left"
face="Calibri,sans-serif"> agreement. This should
be one of our new year's resolutions?</font><span><span
style="font-size:10.0pt;font-family:Consolas"></span></span></div>
</div>
</blockquote>
<div><br>
</div>
<div>Whatever gets it done.<br>
</div>
<div>-- <br>
</div>
<div>Ian.<br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>