Difference between revisions of "Meetings/Passthrough"

Revision as of 15:56, 8 January 2014

Definitions

A specific PCI attachment (could by a virtual function) is described by:

• vendor_id
• product_id
• address

There is a whitelist (at the moment):

• which devices on a specific hypervisor host can be exposed

There is an alias (at the moment):

• groupings of PCI devices

The user view of system

For GPU passthrough, we need things like:

• user request a "large" GPU
• could be from various vendors or product versions

For network, we need things like:

• user requests a nic for a specific neutron network
• they want to say if it's virtual (the default type) or passthrough (super fast, slow, etc)
• this includes groups by address (virtual function, etc) so it's specific to a particular _group_ of neutron network, each with specific configurations (e.g. VLAN id, a NIC attached to a specific provider network)
• or it involves a NIC that can be programmatically made to attach to a specific neutron network

The user view of requesting things

For GPU passthrough:

• user requests a flavor extra specs *imply* which possible PCI devices can be connected

For SRIOV:

• user requests neutron nics, on specific neutron networks, but connected in a specific way (i.e. high speed SRIOV vs virtual)
• some of the nics may be virtual, some may be passthrough, and some might be a different type of passthrough

Agenda on Jan. 8th, 2014

Let's go over the key concepts and use cases. In the use cases, neutron or neutron plugin specific configurations are not mentioned.

Key Concepts

• PCI Groups

1. A PCI group is a collection of PCI devices that share the same functions or belong to the same subsystem in a cloud.

In fact, two proposals exist for PCI group definition - via API, with the implication that they're stored centrally in the database, and via config, specifically a (match expression -> PCI group name) in the compute node configuration. A competing proposal is PCI aliases, which work on the current assumption that all PCI device data is returned to the database and PCI devices can be selected by doing matching at schedule time and thus a name -> match expression mapping is all that need be saved. Thus the internal question of "should all device information be returned to the controller" drives some of the design options.

1. it's worth mentioning that using an API to define PCI groups make them owned by the tenant who creates them.

• Pre-defined PCI Groups

For each PCI device class that openstack supports, a PCI group is defined and associated with the PCI devices belonging to that device class. For example, for the PCI device class net, there is a predefined PCI group named net

• User-defined PCI Groups

User can define PCI groups using a Nova API.

• PCI Passthrough List (whitelist)

1. Specified on a compute node to define all the PCI passthrough devices and their associated PCI groups that are available on the node.
2. blacklist (exclude list) may be added later if deemed necessary.

• vnic_type:

1. virtio: a virtual port that is attached to a virtual switch
2. direct: SRIOV without macvtap
3. macvtap: SRIOV with macvtap

This configuration item is not essential to PCI passthrough. It's also a Neutron configuration item.

• nova boot: new parameters in --nic option

1. vnic-type=“vnic” | “direct” | “macvtap”
2. pci-group=pci-group-name
3. port-profile=port-profile-name This property is not related directly to use of PCI passthrough for networks. It is a requirement of 802.1BR-based systems.

• neutron port-create: new arguments

1. --vnic-type “vnic” | “direct” | “macvtap”
2. --pci-group pci-group-name
3. port-profile port-profile-name

• Nova SRIOV Configuration

1. vnic_type = <vnic-type>: specified in controller node to indicate the default vnic-type that VMs will be booted with. default value is "vnic"
2. sriov_auto_all = <on | off>: specified in compute nodes to indicate that all sriov capable ports are added into the ‘net’ PCI group.
3. sriov_only = <on | off>: specified in compute nodes to indicate that nova can only place VMs with sriov vnics onto these nodes. Default value is on for nodes with SRIOV ports.
4. sriov_pci_group = <pci-group-name>: specified in compute nodes in which all of its SRIOV ports belong to a single pci group.

The SRIOV cofiguration items are enhancements to the base proposal that make it much easier to configure compute hosts where it is known that all VFs will be available to cloud users.

Use Cases

These use cases do not include non-network passthrough cases.

• SRIOV based cloud

1. All the compute nodes are identical and all the NICs are SRIOV based
2. All the NICs are connected to the same physical network

In this cloud, the admin only needs to specify vnic_type=direct on the controller and sriov_auto_all=on on the compute nodes in the nova configuration file. In addition, the new arguments introduced in the nova boot command are not required.

• A cloud with mixed Vnics

1. On compute nodes with sriov ports only, set sriov_auto_all = on
2. On compute nodes without sriov ports, no change is required

In such a cloud, when booting a VM with sriov vnic, the nova boot command would look like:

   nova boot --flavor m1.large --image <image_id>
                          --nic net-id=<net-id>,vnic-type=direct <vm-name>

This will require some minimum change in the existing applications.

• A Cloud that requires multiple SRIOV PCI groups

1. create all the pci-groups in the cloud by invoking a Nova API
2. on compute nodes that support a single pci group and in which all of the SRIOV ports belong to this group, set sriov_auto_all=on, sriov_pci_group=<group_name>
3. on compute nodes that support multiple pci groups, define the pci-passthrough-list

In such a cloud, when booting a VM with sriov macvtap, the nova boot command would look like:

    nova boot --flavor m1.large --image <image_id> 
                   --nic net-id=<net-id>,vnic-type=macvtap,pci-group=<group-name> <vm-name>

• Introducing new compute nodes with SRIOV into an existing cloud

Depending on the cloud and the compute node being introduced:

1. it could be as simple as adding sriov_auto_all=on into the nova config file
2. it could be setting sriov_auto_all=on and pci_group=<group_name>
3. it could be defining the pci-passthrough-list.

• NIC hot plug

Evolving Design Doc

https://docs.google.com/document/d/1EMwDg9J8zOxzvTnQJ9HwZdiotaVstFWKIuKrPse6JOs/edit?usp=sharing

Ian typed up a complete proposal in two sections in that document, which is pulled out here: https://docs.google.com/document/d/1svN89UXKbFoka0EF6MFUP6OwdNvhY4OkdjEZN-rD-0Q/edit# - this proposal takes the 'PCI groups via compute node config' approach and makes no attempt at proposing APIs.

Previous Meetings

http://eavesdrop.openstack.org/meetings/pci_passthrough_meeting/2013/pci_passthrough_meeting.2013-12-24-14.02.log.html http://eavesdrop.openstack.org/meetings/pci_passthrough/

Meeting log on Dec. 17th, 2013

<irenab> baoli: hi

[08:57] <baoli> Hi Irena

[08:57] == tedross [tedross@nat/redhat/x-culmgvjwkhbnuyww] has joined #openstack-meeting-alt

[08:58] <irenab> baoli: unfortunately I cannot participate actively today, will try to follow the log and email later to day

[08:59] <baoli> ok

[09:00] == natishalom [~qicruser@2.55.138.181] has joined #openstack-meeting-alt

[09:00] == HenryG [~HenryG@nat/cisco/x-aesrcihoscocixap] has joined #openstack-meeting-alt

[09:00] == tedross [tedross@nat/redhat/x-culmgvjwkhbnuyww] has left #openstack-meeting-alt []

[09:01] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]

[09:01] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:03] <baoli> Hi, is Yongli there?

[09:04] == yjiang51 [yjiang5@nat/intel/x-uobnfwflcweybytj] has joined #openstack-meeting-alt

[09:04] == jdob [~jdob@c-50-166-75-72.hsd1.nj.comcast.net] has quit [Quit: Leaving]

[09:04] == jdob_ [~jdob@c-50-166-75-72.hsd1.nj.comcast.net] has joined #openstack-meeting-alt

[09:04] <yjiang51> baoli: hi

[09:05] == hajay__ [~hajay@99-46-140-220.lightspeed.sntcca.sbcglobal.net] has joined #openstack-meeting-alt

[09:05] <baoli> yjang: hi

[09:05] <yjiang51> baoli: do we have the meeting?

[09:05] <baoli> Yes, it's on. Hopefully, Yongli will join

[09:06] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]

[09:07] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:07] <yjiang51> baoli: got it and thanks

[09:07] == natishalom [~qicruser@2.55.138.181] has quit [Ping timeout: 252 seconds]

[09:07] == heyongli [~yhe@221.216.132.130] has joined #openstack-meeting-alt

[09:07] <baoli> yhe, HI

[09:08] <heyongli> hello, every one

[09:08] <yjiang51> heyongli: hi

[09:08] <baoli> Hi everyone, let's start

[09:08] == hajay_ [~hajay@66.129.239.12] has quit [Ping timeout: 252 seconds]

[09:08] <baoli> Yongli has summarized his wiki with his email

[09:09] <heyongli> i just arrived home from hospital, sorry late

[09:09] == hajay__ [~hajay@99-46-140-220.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 264 seconds]

[09:10] <baoli> yhe, np. Hopefully, you are well

[09:10] == lsmola_ [~Ladas@ip-94-112-129-242.net.upcbroadband.cz] has joined #openstack-meeting-alt

[09:10] <heyongli> my, son. so i think you might worry about he use case right?

[09:10] <baoli> Can we start with pci-flaovr/pci-group definition? Do we agree that they are the same?

[09:11] <heyongli> in my brain, it's a filter with name, but in the flat dict structure, no sub pci-filter

[09:12] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]

[09:12] <baoli> Well, we want to agree conceptually.

[09:12] == BrianB_ [4066f90e@gateway/web/freenode/ip.64.102.249.14] has joined #openstack-meeting-alt

[09:13] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:13] <heyongli> cause for me it's just a the white list with name, so conceptually it's simple, can be describe clear in this way

[09:14] <baoli> Ok. So, they all define a group of devices with similar properties.

[09:15] <heyongli> agree

[09:15] <baoli> great

[09:16] <heyongli> any other concern for the flavor?

[09:16] <baoli> Now, it seems to me that pci-flavor can be defined by both nova API and by means of configuration

[09:16] <baoli> from your email

[09:16] <heyongli> config is going to fade out

[09:17] <heyongli> for config fade out, any concern?

[09:17] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 245 seconds]

[09:17] <baoli> in your email, what is "admin config sriov"?

[09:17] <heyongli> just mean this step is done by admin

[09:17] == abramley [~abramley@69.38.149.98] has joined #openstack-meeting-alt

[09:18] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:18] <heyongli> John want the picture for user and for admin is clearly defined

[09:18] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Remote host closed the connection]

[09:18] == jdob_ [~jdob@c-50-166-75-72.hsd1.nj.comcast.net] has quit [Quit: Leaving]

[09:18] == jdob [~jdob@c-50-166-75-72.hsd1.nj.comcast.net] has joined #openstack-meeting-alt

[09:19] <baoli> We have some concerns over phasing out the configuration

[09:19] <baoli> Did you check the log from last meeting?

[09:19] <heyongli> i do, but not see the strong reason

[09:20] <baoli> How is it in your mind the nova pci-flavor-update is going to be used?

[09:20] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:20] <heyongli> just the the whole content for the filter

[09:21] <baoli> Well, I'd like to know who is going to invoke it and when

[09:21] <heyongli> toltaly replace or set the new defination for the flavor

[09:21] == ijw [~ijw@nat/cisco/x-urnealzfvlrtqrbx] has joined #openstack-meeting-alt

[09:21] <heyongli> define this , then the device is pass the whitelist and got group into a flavor

[09:22] <ijw> Soirry I'm late

[09:22] == banix [banix@nat/ibm/x-bhsigoejtesvdhwi] has joined #openstack-meeting-alt

[09:22] <baoli> ijw: np

[09:22] == eankutse [~Adium@50.56.230.39] has joined #openstack-meeting-alt

[09:22] == eankutse1 [~Adium@50.57.17.244] has joined #openstack-meeting-alt

[09:22] == eankutse [~Adium@50.56.230.39] has quit [Read error: No buffer space available]

[09:23] <heyongli> this is just the whitelist's DB version, via API

[09:24] <ijw> Apologies for jumping in, but did we do the API/no-API discussion yet?

[09:24] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 245 seconds]

[09:24] <heyongli> current topic

[09:25] <baoli> heyongli: let's assume a new compute node is added, what do you do to provision it?

[09:25] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:25] <heyongli> 2.1.1 admin check PCI devices present per host

[09:25] <ijw> I would ask, given that Openstack's design tenets are all about decentralising where possible, why would you centralise the entirety of the PCI information?

[09:26] <ijw> Have to admit I came a bit late to that document - because all the work was going on in the other doducment

[09:26] <ijw> Which didn't mention this at all

[09:26] <heyongli> this is not relevent to tenet, it's admin's work

[09:27] <ijw> It's actually not the problem. It's not that it's not relevant to the tenant, it's why you have to actively do anything to add a compute node at all. In every other respect a compute node joins the cluster with no activity

[09:27] == yamahata__ [~yamahata@192.55.55.39] has quit [Ping timeout: 240 seconds]

[09:28] <ijw> So, for instance, I boot a compute node, RAM goes up, disk goes up, CPUs go up, but I've not had to edit a central table to do that, the compute node reports in and it just happens.

[09:28] == abramley [~abramley@69.38.149.98] has quit [Quit: abramley]

[09:28] <ijw> I like this - it means when I provision a cluster I just have to get each node to provision correctly and the cluster is up. Conversely when the node goes down the resources go away.

[09:28] == yamahata__ [yamahata@nat/intel/x-hvbvnjztdhymckzk] has joined #openstack-meeting-alt

[09:28] == esker [~esker@rrcs-67-79-207-12.sw.biz.rr.com] has joined #openstack-meeting-alt

[09:29] == denis_makogon [~dmakogon@194.213.110.67] has quit [Ping timeout: 240 seconds]

[09:29] <heyongli> cause pci-flavor is global, you don't need to config it specifically,

[09:29] <ijw> So I would strongly argue that the nodes should decide what PCI passthrough devices they have, independently and without reference to central authority.

[09:29] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds]

[09:30] <ijw> Yes, but that says that all my nodes are either identical or similar, and while that may be true it makes more sense to keep that configuration on and with the machine rather than in a central DB just in case it's not.

[09:30] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:30] <heyongli> ijw: suppose you had 500 server's bring in, all with same configration, like same slot for a same pci device

[09:31] <ijw> Yup, then I would boot them up all with the same config file on each, same as I install the same software on each. That's a devops problem and it's got plenty of solutions.

[09:31] <baoli> heyongli, a pci-flaovr is a global name. But what's part of a pci-flaovr is a matter of the compute host that supports that flavor

[09:31] == julim [~julim@pool-173-76-179-202.bstnma.fios.verizon.net] has joined #openstack-meeting-alt

[09:31] == ruhe [~ruhe@91.207.132.76] has quit [Ping timeout: 246 seconds]

[09:31] <heyongli> then you got this flow to easily bring all them up ready for pci: export the flavor in aggreate

[09:31] == shakayumi [~shakayumi@156.39.10.22] has quit [Ping timeout: 250 seconds]

[09:31] <ijw> heyongli: If I were doing this with puppet, or chef, or ansible, or whatever, I would work out what type of host I had and put a config on it to suit. This is solving a problem that doesn't exist.

[09:32] == jmaron [~jmaron@pool-173-61-178-93.cmdnnj.fios.verizon.net] has joined #openstack-meeting-alt

[09:32] <ijw> And aggregates divide machines by location, generally, not type.

[09:32] == yamahata [~yamahata@i193022.dynamic.ppp.asahi-net.or.jp] has quit [Read error: Connection timed out]

[09:33] == aignatov [~aignatov@91.207.132.72] has quit [Ping timeout: 245 seconds]

[09:33] <ijw> In summary, do not like. I don't understand why it's a good idea to use APIs to describe basic hardware details.

[09:33] <baoli> yeyongli: I think that you agreed the aggregate is a high level construct. It has nothing to do with how a compute node decides what devices belong to which pci-flavor/pci-group

[09:33] <heyongli> i might wrong, but aggregate bp say it's a sub group of hosts with same property that's why aggregate's meta data and scheduler do it's work

[09:33] == denis_makogon [~dmakogon@194.213.110.67] has joined #openstack-meeting-alt

[09:33] == markmcclain [~markmccla@c-98-242-72-116.hsd1.ga.comcast.net] has quit [Quit: Leaving.]

[09:34] == yamahata [~yamahata@i193022.dynamic.ppp.asahi-net.or.jp] has joined #openstack-meeting-alt

[09:34] == irenab [c12fa5fb@gateway/web/freenode/ip.193.47.165.251] has quit [Ping timeout: 272 seconds]

[09:34] <ijw> Aggregates are there for scheduling, though, not provisioning

[09:34] == natishalom [~qicruser@62.90.11.161] has joined #openstack-meeting-alt

[09:34] == aignatov [~aignatov@91.207.132.76] has joined #openstack-meeting-alt

[09:34] <baoli> yeyongli: i have no problem with nova pci-flavor-create, but with nova pci-flavor-update

[09:34] == natishalom [~qicruser@62.90.11.161] has quit [Client Quit]

[09:34] <baoli> so, aggregate can still work

[09:34] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 248 seconds]

[09:34] <ijw> I have a problem with using APIs and the database to do this *at all*.

[09:35] <heyongli> what's that?

[09:35] <ijw> That we shouldn't be storing this information centrally. This is exactly what per-host config files are for.

[09:36] <baoli> ijw: let's focus on the API versus configuration. Not diverage to use of DB.

[09:36] <ijw> Also, this is not something that changes on a whim, it changes precisely and only when the hardware in your cluster changes, so it seems to me that using a config file will make that happen per the devops comments above, and using APIs is solving a problem that doesn't really exist.

[09:37] <heyongli> acctually i argued for the aggregate is is for provisioning, failed

[09:37] <ijw> baoli: there's no disctinction to speak of. The APIs clearly change a data model that lives somewhere that is not on the individual compute hosts.

[09:38] <ijw> So, why do we need this to be changeable by API at all, and why should the information be stored centrally? These are the two questions I want answers to for this proposal to make sense.

[09:38] <heyongli> hi, ijw, if use per host setting there still need a central thing: the alias, but alias is fade out also

[09:39] <ijw> No, you don't, you can work out aliases/groups/whatever by what compute hosts report. Only the scheduler needs to know it and it can work it out on the fly.

[09:39] <heyongli> so global flavor combined the whitelist and flavor

[09:39] <heyongli> if no global thing, how do you know there is 'sth' to be ready for use?

[09:39] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:40] <ijw> That's what the scheduler does. Practically speaking you never know if you can schedule a machine until you schedule a machine.

[09:40] <yjiang51> ijw: heyongli, I think we need persuade john if we have anything different. Is it possible to get John on this meeting?

[09:40] <ijw> The only difference in what you're saying is that you couldn't validate a launch command against groups when it's placed, and that's certainly a weakness, but not a very big one.

[09:41] <heyongli> ijw: no, you must provide you request to scheduele, so how do you want tell the schedule what you want?

[09:41] <ijw> Which John?

[09:41] <ijw> extra_specs in the flavor.

[09:41] <ijw> Listing PCI aliases and counts rather than PCI flavors.

[09:42] <ijw> This assumes that your aliases are named by string so that you can refer to them (which is an idea I largely stole from the way provider network work, btw)

[09:43] <baoli> heyongli: I guess that we didn't do a good job in the google doc in describing how the pci-group works. Otherwise, it describes exactly why alias is not needed, and pci-group should work

[09:43] <ijw> So, in my scheme: 1. you tell the compute host that PCI device x is usable by passthrough with flavor 'fred'. You schedule a machine requesting one of 'fred' in its flavor, and the scheduler finds the host. This is back to the simple mechanism we have now, I don't really thing it needs complicating.

[09:44] <ijw> Sorry, s/flavor/group/ in the first location that last comment.

[09:44] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]

[09:44] == ruhe [~ruhe@91.207.132.72] has joined #openstack-meeting-alt

[09:45] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:45] == heyongli [~yhe@221.216.132.130] has quit [Ping timeout: 248 seconds]

[09:46] == esker [~esker@rrcs-67-79-207-12.sw.biz.rr.com] has quit [Remote host closed the connection]

[09:46] == esker [~esker@198.95.226.40] has joined #openstack-meeting-alt

[09:47] == demorris [~daniel.mo@rrcs-67-78-97-126.sw.biz.rr.com] has joined #openstack-meeting-alt

[09:47] <ijw> Bad moment time for network trouble…

[09:47] <yjiang51> ijw: yes, seems he lose the connection

[09:48] == mtreinish [~mtreinish@pool-173-62-56-236.pghkny.fios.verizon.net] has quit [Ping timeout: 272 seconds]

[09:49] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 248 seconds]

[09:50] <yjiang51> ijw: but I agree that if we need create pci flavor each time to make compute node's PCI information available seems not so straightforward.

[09:51] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:51] == heyongli [~yhe@221.216.132.130] has joined #openstack-meeting-alt

[09:51] == mtreinish [~mtreinish@pool-173-62-56-236.pghkny.fios.verizon.net] has joined #openstack-meeting-alt

[09:51] <ijw> Well, turning this around the other way, if you described the groups of PCI devices that a compute node was offering in the configuration of the compute node, what's the problem with that?

[09:52] <heyongli> ijw: np, but alias is killed during the blue print review

[09:52] <baoli> keep in mind, this is provisioning task on the part of compute nodes

[09:52] <heyongli> btw: i'm lost connection, so i don't you you see this, i just paste again:

[09:53] <heyongli> <heyongli> yeah, what's in the extra_spec?

[09:53] <heyongli> <heyongli> currently in the extra spec is alias, what would you save in there?

[09:53] <heyongli> <heyongli> no matter what you save there, that's will be global thing or something like alias currently been implemented.

[09:53] <heyongli> <heyongli> you can not elimation a global thing there, but the room for argue is where is should be define

[09:53] <heyongli> <heyongli> where it is

[09:53] <heyongli> <heyongli> and another topic/TODO is Nova community want see some code for this design for further evaluation

[09:53] <heyongli> <heyongli> i'm work on it, so we can make some progress

[09:53] <baoli> heyongli: it's <pci-flavor:no>

[09:53] == demorris [~daniel.mo@rrcs-67-78-97-126.sw.biz.rr.com] has quit [Ping timeout: 252 seconds]

[09:53] <baoli> sorry <pci-flavor:#of devices>

[09:54] <heyongli> baoli: i'm lost , what do you mean

[09:54] <ijw> heyongli: er, since we're working on two documents I don't even know which document review you're talking about.

[09:54] <baoli> in the nova flavor, you can do pci-flavor (or pci_group): 2 in the extra_specs

[09:55] <heyongli> ijw: i paste the link there long time ago

[09:55] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 248 seconds]

[09:55] <heyongli> for review, only bp is valid... am i right?

[09:55] <ijw> I think it's fairly reasonable to say that at this point 'pci flavor', 'alias' and 'group' are all synonyms. Whichever we use we're talking about a PCI device type we want to allocate.

[09:55] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[09:56] <ijw> heyongli: no, not really - this isn't a formal process, we're trying to reach agreement here;.

[09:56] <heyongli> ijw: yep, the current in tree, use synonyms: whitelist, alias

[09:56] == demorris [~daniel.mo@72.32.115.230] has joined #openstack-meeting-alt

[09:57] == jecarey [jecarey@nat/ibm/x-njofcfftyghvgqwd] has joined #openstack-meeting-alt

[09:57] <ijw> What we agree we want: to be able to nominate devices by a fairly flexible method on a host (down to host/path and as widely as vendor/device) to a specific group; to schedule a machine with a combination of device allocations from various groups. Right so far?

[09:57] <ijw> I think that's the core of where we agree.

[09:58] == gokrokve [~gokrokve@c-24-6-222-8.hsd1.ca.comcast.net] has joined #openstack-meeting-alt

[09:58] <heyongli> ijw: right i think, i agree this, and part of this is in tree except group.

[09:58] <ijw> Beyond that, there are two different proposals, one with an API and one which is config driven. How do we choose between them?

[09:58] <heyongli> ijw: for me this is a trade off.

[09:59] <ijw> For me, it's not - I see the API as lots more complex and also harder to use

[09:59] <heyongli> config many many machine had scale problem

[09:59] == chandankumar [chandankum@nat/redhat/x-qhjjbtjvegvuzagq] has quit [Quit: Leaving]

[09:59] == amitgandhi [~amitgandh@72.32.115.231] has joined #openstack-meeting-alt

[10:00] <ijw> But if you're configuring many machines, then there's no problem, because you have a deployment system that will configure them identically. I do 10 node clusters automatically, I'm sure if I have 500 there's going to be no logging into them and accidentally typoing the config

[10:00] <baoli> heyongli: it's not really a scale problem in terms of provisioning

[10:00] <ijw> So that's a non-problem and I think we should remove that from the discussion

[10:00] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has quit [Ping timeout: 261 seconds]

[10:01] == markmcclain [~markmccla@c-24-99-84-83.hsd1.ga.comcast.net] has joined #openstack-meeting-alt

[10:01] <ijw> (Note this is different from host aggregates - I might aggregate hosts by physical location of by power strip, things I absolutely can't determine automatically, so there's no parallel there)

[10:01] == gokrokve [~gokrokve@c-24-6-222-8.hsd1.ca.comcast.net] has quit [Remote host closed the connection]

[10:01] == gokrokve [~gokrokve@c-24-6-222-8.hsd1.ca.comcast.net] has joined #openstack-meeting-alt

[10:02] == SushilKM [~SushilKM@202.174.93.15] has quit [Ping timeout: 250 seconds]

[10:02] == jcooley_ [~jcooley@c-76-104-157-9.hsd1.wa.comcast.net] has joined #openstack-meeting-alt

[10:03] == mpanetta [~mpanetta@72.3.234.177] has joined #openstack-meeting-alt

[10:03] <heyongli> aggregate can be use on pci, but it not must to be like this way, whitout aggregate it should still work .

[10:05] == denis_makogon [~dmakogon@194.213.110.67] has quit [Ping timeout: 240 seconds]

[10:05] == flwang1 [~flwang@106.120.178.5] has joined #openstack-meeting-alt

[10:05] == denis_makogon [~dmakogon@194.213.110.67] has joined #openstack-meeting-alt

[10:06] == kgriffs [~kgriffs@nexus.kgriffs.com] has joined #openstack-meeting-alt

[10:06] <kgriffs> o/

[10:06] <amitgandhi> 0/

[10:06] <kgriffs> amitgandhi: you're alive!

[10:06] <flwang1> meeting time?

[10:06] <flaper87> yo yo

[10:06] <amitgandhi> yup made it back in one piece

[10:06] <flwang1> o/

[10:06] == ametts [~ametts@72.3.234.177] has joined #openstack-meeting-alt

[10:07] <kgriffs> will Malini be here today for the mtg?

[10:08] <ijw> OK, we're out of time, I think we have to take this to the list.

[10:09] <ametts> kgriffs: I see her in #cloudqueues. Just pinged her.

[10:09] <ijw> To which end I've just mailed out what I was saying.