22:01:02 <danwent> #startmeeting
22:01:03 <openstack> Meeting started Tue May 24 22:01:02 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:04 <dendrobates> w/o the dash
22:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:01:13 <danwent> haha, thank god rick is running things :)
22:01:18 <salv-orlando> Hi everybody
22:01:23 <troytoman> hello all
22:01:25 <adjohn> Hey
22:01:26 <dendrobates> the agenda is here:  http://wiki.openstack.org/Network/Meetings
22:01:48 <ecarlin> hello
22:01:52 <somikbehera> hi everybody
22:01:53 <RamD> Hello
22:02:01 <jamesurquhart> hello
22:02:01 <ying> hello
22:02:02 <AlexNeef> hi all
22:02:06 <danwent> hi folks.  want to introduce brad, a new guy on our team from nicira
22:02:13 <danwent> (not new to nicira, but new to netstack)
22:02:27 <danwent> brad, you there?
22:02:48 <danwent> maybe i need to go over to his cube and kick him.
22:02:49 <dendrobates> attendance fail  :)
22:03:03 <bhall> I'm here :)
22:03:04 <salv-orlando> poor brad
22:03:04 <danwent> one more and its a fail hat trick for me
22:03:09 <bhall> (no kicking necessary)
22:03:12 <bhall> hi everyone..
22:03:13 <salv-orlando> I hope Dan does not kick like Chuck Norris
22:03:30 <danwent> ok, if rick needs to run in 30 mins, let's try to get things started, shall we?
22:03:39 <danwent> #topic extensions
22:03:45 <ecarlin> stanford people don't kick like chuck norris :-)
22:03:52 <danwent> rough
22:04:21 <danwent> so, I think the main question is how do we let plugins expose non base capabilities
22:04:39 <ying> before talking about data extensions, shall we talk about data attributes in core API?
22:04:58 <danwent> ah, you mean like id, name, date_created?
22:05:00 <ying> as the extension is something beyond that
22:05:03 <ying> yes
22:05:08 <AlexNeef> did we agree to use the /cap/{key} mechanic in the api?
22:05:40 <danwent> AlexNeef, let's save that for the next discussion (even if the core concept itself is not an extension)
22:05:41 <romain_lenglet> I don't think so
22:06:08 <danwent> ok, ying, are you proposing some additional fields for the base beyond what was in salvatore's spec on the wiki?
22:06:23 <danwent> I think that included and id,name for networks, and an id for ports?
22:06:26 <AlexNeef> ok - I did update a lot of the base attirbutes
22:06:43 <ying> not put on the wiki yet,it here http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.pdf
22:06:57 <ying> yes, I saw Alex's updates
22:07:05 <AlexNeef> I'm not sure people saw that: http://wiki.openstack.org/QuantumAPISpec
22:07:27 <AlexNeef> I wanted to get the ball rolling thinking about the data attributes
22:07:28 <romain_lenglet> can somebody explain me again why we have to replace API extensions with extensible data attributes?
22:07:28 <ying> we need to make sure that we agree all the base attributes in the core API
22:07:37 <ying> then, we can see what needed for extension
22:08:16 <danwent> romain: I don't think we have to, but that is part of the next discussion.
22:08:24 <romain_lenglet> good, let's discuss that
22:08:29 <salv-orlando> Agree with ying, but I think the topic was for discussing a mechanism for extension API rather than defining what is "base" and what is "extension"
22:08:37 <danwent> +1
22:08:45 <danwent> that is exactly what I was typing :)
22:08:46 <somikbehera> agree.
22:08:59 <danwent> in my mind, the entire API is still experimental
22:09:14 <danwent> so I don't think we need to be making final calls here.
22:09:18 <markwash_> have you all taken a look at the instrumentation for extensions in nova?
22:09:19 <dendrobates> so everyone wants to discuss the extension mechanism now?
22:09:38 <danwent> if ying is ok with it, I would suggest doing so.
22:10:00 <somikbehera> markwash_ : some of us have and hopefully we are going to discuss nova/openstack extension mechanism here too and may use them
22:10:09 <ying> so we are clear about the data attributes?
22:10:15 <ying> ok
22:10:23 <danwent> Ok, extensions.
22:10:45 <danwent> so I believe we are planning on using Openstack standard extension mechanisms.
22:10:56 <danwent> or at least we'll work with jorge to identify whether they are suitable.
22:11:03 <ecarlin> +1
22:11:06 <salv-orlando> +1
22:11:10 <somikbehera> +1
22:11:11 <johnpur> +1
22:11:12 <romain_lenglet> +1
22:11:27 <bhall> +1
22:11:30 <dendrobates> I think we should use them and suggest modifications if we find shortfalls
22:11:33 <RamD> +1
22:11:38 <jamesurquhart> Just to be clear, though, the "standard" hasn't been officially blessed yet, right?
22:11:38 <danwent> Ok, so it seems to me that openstack extensions let us add attributes to any of the network or port objects using the data extension mehcanism
22:11:55 <dendrobates> jamesurquhart: right, but nearly
22:12:00 <danwent> james: yes, we can still help improve the standard.
22:12:02 <jamesurquhart> Cool.
22:12:04 <danwent> if it is lacking
22:12:13 <AlexNeef> I'm not sure i understand what that really means tangibly
22:12:29 <danwent> we will also need to consider how to add additional API methods and API objects (i.e., go beyond data extension).
22:12:35 <AlexNeef> is the standard extention model in some type of contradiction with yings model?
22:12:37 <danwent> AlexNeef: clarify?
22:12:42 <ecarlin> a draft of the extensions guide is happening as we speak and will be submitted to the policy board soon for final approval
22:12:49 <danwent> Alex: I don't think so.
22:12:51 <ying> I think they are converging
22:13:12 <ying> standard mechanism defines how to define and discovery the extension
22:13:28 <danwent> So the work item I was proposing around quantum-extensions is not so much defining what is or is not an extension
22:13:31 <ying> it has data extension part, we can use that for key value model
22:13:36 <romain_lenglet> danwent: +1 on supporting additional methods, that's necessary and that could be all that we need (i.e. no need for additional data attributes, we just need extra methods)
22:13:43 <danwent> but rather the mechanisms by which plugins can expose extensions.
22:14:00 <ecarlin> if ying feels there is a shortcoming with the proposed extension model, i suggest he get with jorge and adjust.  if it's a shortcoming here, it will likely be elsewhere.  let's make the standard extension model better vs. deviating.
22:14:10 <danwent> romain: I think that is an interesting point.  One could argue that data extension is not the right way to do at all.
22:14:22 <danwent> this is a good discussion to have.
22:14:38 <ecarlin> the extension model supports additional api operations
22:14:39 <markwash_> so, I definitely like jorge's extensions model, but it didn't seem to be built for yings use case precisely
22:15:12 <markwash_> from what I understand, the quantum api is looking for ways to expose plugin functionality that it doesn't necessarily know about ahead of time, right?
22:15:20 <ying> yes, I agree. we can use it for my key value model
22:15:20 <danwent> mark: yes
22:15:36 <dendrobates> does everyone understand ying's use case?
22:15:40 <somikbehera> I think jorge's extension model allows to extend the API with new methods for specific methods therefore not ncessarily requiring extensible data objects..
22:15:49 <danwent> romain: where you advocating for an approach that limits what extensions are considered "valid" to only using new API objects + methods?
22:15:50 <jamesurquhart> dendrobates: My question as well
22:16:13 <romain_lenglet> danwent: both approaches are dual
22:16:24 <romain_lenglet> but I feel we'll need extra methods in extensions anyway
22:16:33 <danwent> romain: agreed.
22:16:35 <romain_lenglet> so we could just go all with extra methods
22:17:04 <danwent> romain: would that be excluding the "data extension" approach?
22:17:06 <ying> my understanding is that extra methods go with the extended resources
22:17:13 <somikbehera> i like that as then its clear from API who is adding those methods as they can be in a separate rest namespace
22:17:21 <ying> by adding new resources, we can add new methods
22:17:33 <somikbehera> while with data attributes, the namespace gets polluted with standard namespace.
22:18:19 <danwent> ying: can you define "resources" ?  you're not talking about a URI, are you?
22:18:44 <ying> resource is the subject in the web service, like network, port ,etc
22:18:51 <danwent> yes, ok.
22:19:07 <romain_lenglet> we'll need extra methods on ports, networks, etc.
22:19:17 <romain_lenglet> not merely on new resources
22:19:29 <ying> romain: could you give soem example?
22:19:36 <danwent> I think adding new methods need to be in scope.
22:19:53 <danwent> as well as adding new resources.
22:20:16 <salv-orlando> +1
22:20:22 <AlexNeef> whats a new resource?
22:20:24 <jamesurquhart> danwent: But not new data attributes? (Just trying to get this debate clear in my head)
22:20:35 <danwent> To me, the interesting question is do we want to limit what people can do by saying that they should not "extend" the "base" objects in the API (network, port).  I don't have a strong feeling on this, but others may.
22:20:52 <danwent> port and network is a "resource"
22:21:02 <danwent> in the base API.
22:21:25 <danwent> James: does that answer your question?
22:21:34 <AlexNeef> So I can create an extention with additonal types of resources like "MyPort"
22:21:46 <ying> yes
22:21:58 <jamesurquhart> danwent: sort of. I'll "listen" further for a bit… ;)
22:21:58 <danwent> I think the "data extension" mechanism would let you add new key-values to the existing Port object.
22:22:05 <salv-orlando> Why don't we reason around the "capability" feature? Is a capability an extended composite attribute of the port or is it a "Port_Capability" resource?
22:22:06 <AlexNeef> That seems like we will break introperability quickly
22:22:10 <danwent> I believe we are discussing whether this should be allowed.
22:22:33 <AlexNeef> salv: good idea i need to anchor this concept somewhere
22:22:41 <ying> salv: that's my initial question
22:22:54 <ying> do we need to have any cap in the base API?
22:23:00 <RamD> Salv: this is more like port-profile in our proposal
22:23:16 <AlexNeef> So i vote for capabilties as a comonent of an existing resource
22:23:24 <AlexNeef> i.e. port/cap/
22:23:32 <danwent> I think generally there is a need to associate new types of state + actions with existing types of resources (e.g., a set of ACLs on a port)
22:23:45 <danwent> or the ability to put a port in "Admin down" state.
22:24:28 <RamD> Yes. port-profile kind of constructs provide "grouping" them eg ACL across # of Port resources
22:24:39 <ying> Alex: you mean cap is attributes with base resource port?
22:25:11 <AlexNeef> One concenpt of a "capabilty" is that it's a static feature of a resource. It just describes it. things like ACL's are really features, that you interact with
22:25:31 <somikbehera> I think we can easily dop port profiles, cap etc. using Jorge's extension mechanism.
22:25:36 <salv-orlando> I think something like port_cap sound more natural but pollutes the namespace, whereas port_profile maybe is not as natural but keeps base and extended namespace separate
22:25:40 <somikbehera> *easily do
22:25:57 <danwent> port-profile imply a template, no?
22:26:25 <danwent> i.e., something that can be applied to many ports?
22:26:33 <ying> yes
22:26:34 <salv-orlando> danwent: I think so...
22:26:34 <danwent> to me that is a somewhat different discussion.
22:26:35 <AlexNeef> agree - theres no implied coupling between an actual port
22:26:35 <ying> one to many
22:26:51 <RamD> port-profile is a set of attributes that can be applied to many ports
22:27:05 <RamD> e.g. Same ACLs for # of ports
22:27:27 <dendrobates> ying: should that exist in Donabe instead?
22:27:42 <danwent> so the ACL itself is not an attribute of the port with a port-profile, is that correct?
22:27:55 <danwent> dendrobates: I was thinking along similar lines.
22:28:09 <ying> it's associated with port, hence, I think it belongs to quantum
22:28:15 <jamesurquhart> dendrobates:  different than network container. more a "grouping" like a role
22:28:22 <markwash_> somikbehera: my only point is that I feel like the extension mechanism is something you do when something really doesn't fit into core at this time
22:28:27 <RamD> Ying +1
22:28:42 <markwash_> somikbehera: but we are all talking about these things like some set of quantum plugins will probably need to use them
22:29:08 <danwent> could we focus on a simpler use case for a second?
22:29:18 <AlexNeef> ying: i disagree, many other services will make use of quantum components without being owned in the base api
22:29:18 <danwent> like wanting to expose statistics on a port as an extension?
22:29:19 <salv-orlando> danwent: If you have it shoot!
22:29:51 <danwent> the port-profile case (while potentially valuable) actually conflates several unresolved issues in my mind.
22:30:08 <somikbehera> markwash_:  not all plugins but some plugins may use/implement the adavanced functionality
22:30:23 <salv-orlando> Ok, let's analyze statistics use case, from an API user perspective
22:30:53 <danwent> one way to do it would be to use data-extension to expose a "statistics" field in the port object itself.
22:31:09 <danwent> another way would be to add a new URL: /network/<id>/port</id>/stats
22:31:10 <salv-orlando> If a user wrote a client app which fetches statics using /port/statistics that would be quite easy and natural
22:31:15 <AlexNeef> statistics are a good case because in addition to reading them i may also want to clear them
22:31:16 <somikbehera> markwash_ : therefore we could have the advanced stuff be extensions
22:31:21 <danwent> or /port-stats/<id>
22:31:24 <ying> alex: disagree with whether we need port profile here?
22:31:27 <salv-orlando> but the user would not be aware of the fact that "statistics" is an extension
22:31:42 <dendrobates> guys I need to go to my kids school.  I will catch up later.  I will send an email out about my webex topic.
22:31:55 <AlexNeef> +1 to using webex
22:31:58 <ecarlin> you would do that as /v1/networks/{netid}/ports/{portid}/ext/{vendor-id}/statistics
22:32:06 <danwent> by rick!
22:32:13 <ecarlin> you would know it's an extensions because of the URI
22:32:20 <ecarlin> plus all extensions are queryable
22:32:23 <danwent> in theory, i think all of those mechanisms would be supported using openstack extensions.
22:32:30 <ecarlin> yes
22:32:30 <salv-orlando> ecarlin +1
22:32:33 <somikbehera> +1
22:32:47 <markwash_> danwent: I agree that they can be supported using the openstack extensions mechanism
22:33:13 <markwash_> danwent: I think the question is, are they general enough to not require the extensions mechanism?
22:33:16 <danwent> I think we are discussing whether the idea of adding a "statistics" field to the "base" port attribute should be discuraged.
22:33:21 <AlexNeef> +1 that however we could also /v1/networks/{netid}/ports/{portid}/statistics/ext/{vendor-id}
22:33:39 <AlexNeef> which would allow us a base set of stats with the option to extend by vendor if we want
22:33:46 <markwash_> danwent: apologies if I'm off base
22:33:48 <salv-orlando> Same URI structure could be used also for new resources e.g.: v1/ext/{vendor-id}/strangeresource
22:34:02 <danwent> mark: not sure I following your last question.  can you clarify?
22:34:07 <ying> let's take statistics use case, we first define an extension: statistics, then later we want to extend statistics by adding new stat attributes
22:34:23 <danwent> Erik, you've put a lot of thought into extensions, what is your take?
22:34:25 <markwash_> danwent: so to me, I love extensions because when I have something that nobody else can use or support, I can still fit it into the api
22:34:37 <ying> is that another extension based on existing extension: statistics?
22:34:52 <markwash_> danwent: but I don't love adding all the extra length to the urls and complicated namespaces if its actually a pretty general use case
22:34:55 <danwent> :mark yes, that's the idea.  extensions can then be "promoted" to base if people like them.
22:35:11 <markwash_> danwent: it seems like punting on first down
22:35:19 <markwash_> danwent: I love punting on fourth down
22:35:27 <markwash_> danwent: but I'd rather see if it fits in core first
22:35:28 <ecarlin> the idea is to keep core universally applicable, i.e. it should work with every plugin
22:35:39 <ecarlin> if everyone supported port statistics, we could make it core
22:35:44 <ecarlin> if not, if would be an extensions
22:35:49 <danwent> mark: Our motivation was to get the core L2 functionality out first.
22:36:00 <ecarlin> over time, if that became "standard", it would get promoted to core
22:36:01 <danwent> mark: then aggressively promote.
22:36:09 <markwash_> ecarlin: so different vendor supplied statistics packages, with the same interface, would still have different urls?
22:36:17 <ecarlin> we should guard core and keep it universally applicable
22:36:22 <markwash_> ecarlin: and different attribute names in existing objects?
22:36:23 <danwent> main goal is to get a simple "core" out, without months of discussion of what is or is not in core
22:36:43 <danwent> L2 connectivity only seemed like a very simple line to draw.
22:36:44 <AlexNeef> so i agree we need to get the "core" but having a place holder so software can know that there will be a mechaism for retreiving stats, capabilties, etc from the get go is valuable
22:37:08 <AlexNeef> even if we only define a really small set of base stats or capabilities
22:37:15 <ecarlin> markwash: no, there are multi-vendor extension prefixes so the URI can be the same
22:37:23 <somikbehera> AlexNeef: the same can be achieved via an extension till the exntension gets universally accepted.
22:37:27 <markwash_> ecarlin: okay cool
22:37:30 <ecarlin> this is exactly how OpenGL works which is where Jorge derived this approach
22:37:31 <jamesurquhart> danwent: It seems that stats is a unique case to most people here. Is that right? Or are there other topics that would garner the same debate?
22:37:59 <danwent> QoS, ACLs, etc.  all seemed to get people very excited and wanting to go in different directions.
22:38:28 <danwent> We had to spend a lot of time to get people to just settle on tackling L2 connectivity.
22:38:47 <danwent> so we went with a model where people could go do anything they wanted, as long as it started out as an extension.
22:38:53 <jamesurquhart> OK, so I guess I would agree that starting with simple base is best, but that comes with the cost of breaking backward compatibility as functions move from extensions to core over time.
22:38:54 <markwash_> ecarlin: I definitely buy the concept of extensions, I just worry that the cost of adding an extension is greater to the user and deployer than we are guessing now
22:39:08 <danwent> then once we got the base in place (still as an experimental-only solution), we could tackle advanced APIs.
22:39:10 <ecarlin> I think we should keep those out of core for now and keep it simple.  We spent a lot of time at the summit paring things back to basic L2 connectivity.
22:39:18 <markwash_> ecarlin: perhaps we can reduce that cost however with our code
22:39:33 <ecarlin> if people want to support more now, go for it, that's what extensions are for, but i would vote to keep core simple for starters
22:40:08 <ecarlin> i think this is much broader than quantum
22:40:10 <jamesurquhart> ecarlin: We should, however, acknowledge that there are tradeoffs for things we know are *likely* to be common in future
22:40:21 <AlexNeef> ecarlin: I agree in concept, but think there are some peices that are reqruired for basic cfunctionality that are missing
22:40:29 <ecarlin> across any service, plugins should be able to expose capablities in consistent ways
22:40:41 <ecarlin> we need a framework for that that all services can utilize
22:40:48 <AlexNeef> static capabilities are an example
22:40:57 <ying> so, what should we include in core? it's still my question?
22:40:57 <jamesurquhart> ecarlin: Sure. Not sure that is what is being debated at this point.
22:41:28 <danwent> to me the first piece of the puzzle is making sure quantum can even support API extensions.
22:42:02 <markwash_> danwent: supporting extensions in the base case is no difficulty--slap a middleware or straight http proxy on top of the regular api, have it call what you need it to call
22:42:05 <jamesurquhart> danwent: +1, but once solved it quickly exposes base vs. extension issue
22:42:06 <danwent> the debate about what is or is not core will probably continue indefnitely, but I'd really like to get someone coding on supporting extensions :)
22:42:32 <markwash_> danwent: but perhaps your focus is on something more elegant?
22:42:54 <somikbehera> ying: salvateore has a core API spec up for review for a few weeks that defines the agreement on core from summit.
22:42:56 <RamD> I think the question is what is the must have that we need in base API...better to have it now rather than later.
22:43:14 <AlexNeef> +1
22:43:15 <danwent> I actually think with our plugin infrastructure it will be a bit more complex.  It will partially depend on whether we allow data extension or not.
22:43:47 <RamD> danwent: Agree lots of unknown for me
22:44:15 <ying> somikbehera: yes, I read through that spec. It defines the resources and operations associated with resources, but not defined the attributes associated with each resource. Alex added some later.
22:44:27 <danwent> I think in the absence of agreement here we have to stick to what we outlined at the summit.
22:44:29 <ying> for example, network has name, id, port has state
22:44:34 <salv-orlando> We have two rather orthogonal discussion: properly defining the core and a mechanism for extending it
22:44:49 <danwent> +1
22:44:58 <salv-orlando> While the former is pretty much "blurred" at the moment as mark pointed out we can start doing progress on the second
22:45:01 <jamesurquhart> salv-orlando: +1
22:45:33 <danwent> I think salv-orlando is very close to having a first cut of the base networks + port code ready.
22:45:35 <RamD> Yep..that's why Ying started it with that
22:45:46 <salv-orlando> While a team adds the extension middleware, we can all together discuss the nature of the core
22:45:58 <markwash_> apologies if I have derailed things :-/
22:46:02 <danwent> we can continue to iterate on that once it is out.... this API is still experimental, so no need to worry about what is or is not in it.
22:46:14 <salv-orlando> and then what is core will be handled by the API I'm already implementing, and what is not core goes through the extension mechanism
22:46:22 <danwent> mark: healthy discussion :)
22:46:37 <somikbehera> properly defining core: we can first deliver what we defined at the summit, quickly iterate and add more, its all about being agile right?
22:46:51 <salv-orlando> markwash_: you were suggesting before your code (API serialization?) can be helpful for us. In which way?
22:47:15 <Sumit> as far as the base spec is concerned, the point of discussion is more about what are the attributes of the resources
22:47:17 <ecarlin> folks, i'm talking to jorge on the phone.  he is going to join in a minute to address extensions questions.
22:47:17 <salv-orlando> somikbehera: +1
22:47:24 <Sumit> i dont think we nailed them down during the summit
22:47:31 <danwent> ecarlin: great, thanks
22:47:49 <Sumit> if we know what the attributes are, we can accordingly definer relevant operations/API
22:48:16 <ecarlin> he said nova is working on a way to have plugins auto register api extensions
22:48:17 <salv-orlando> I suggest moving the discussion on attribute to etherpad, and then discuss it next week
22:48:19 <Sumit> not to say that what is being currently proposed is not correct
22:48:22 <danwent> The focus on L2 connectivity was a pretty strong theme of the summit
22:48:34 <markwash_> salv-orlando: what ecarlin just said ^^
22:48:48 <danwent> while recognizing that there was a whole bug of other things that we will eventually add to the base.
22:49:01 <danwent> (it was just that everyone's list of what else to add to the base was different)
22:49:30 <danwent> ecarlin: very cool.
22:49:46 <danwent> so are we waiting on jorge?
22:50:00 <ecarlin> he is joining...
22:50:26 <danwent> I personally thing that extensions are a great way to "prototype" a proposal for base, as it is a very concrete proposal.
22:50:35 <ecarlin> exactly
22:51:35 <danwent> other topics while we're waiting:  we're hoping to send the base quantum framework + some integration with Salvatore + an open vswitch plugin for review soon.
22:51:52 <danwent> everything is still completely experimemental, but you have to start somewhere :)
22:52:01 <danwent> hi jorge :)
22:52:04 <jorgew> Hey guys
22:52:20 <somikbehera> anybody who has questions/confusion regarding the extension mechanism, should check jorge's presentation from the summit.
22:52:45 <ying> Jorgew:a question about extension mechanism? For data extension, can we use it to extend an existing extension?
22:53:28 <jorgew> not sure I follow — can you ellaborate
22:53:44 <ying> For example, we define an extension "statistics", which has 4 attributes? Later we want to add 5th attr to it, should we add another extension?
22:54:03 <ying> Or, we just modify previous extension's schema file?
22:54:05 <markwash_> ying: from what I understand yes--the only difficulty is making sure the order of operations works out right for when the extensions' logic runs
22:54:20 <jorgew> Typically Yes that means a different extension
22:54:27 <jorgew> but really
22:54:50 <jorgew> it depends on what you client support is
22:55:14 <markwash_> ying: to clarify I was answering "can we". whether or not it is the right choice probably depends on the specific situation
22:55:25 <jorgew> the correct thing to do is to define anothor one.
22:55:51 <ecarlin> and would it supersede the previous extension?
22:56:18 <ying> you mean define another extension with the same name "statistics" to supersede previous one?
22:56:49 <jorgew> Right. It can — you can have both extensions simultaneously though i'm not sure that makes sense
22:56:54 <RamD> How "versioning" is handled? more in lines of compat.
22:57:11 <ecarlin> jorge: do you recommend putting a version in the extension name?
22:57:19 <jorgew> I would call it statistics2  that's whats typically done in gl
22:57:42 <jorgew> but that said it's a different extension
22:57:43 <ying> if that's the case, does it mean we won't use "data extension" independently? It always come alone with an resource extension?
22:57:46 <RamD> Is this where key-value pairs have value
22:58:28 <somikbehera> ying: correct, as its cleaner and we know which extension added what
22:59:02 <jorgew> ying: no it doesnt mean that though — you can extend the data without adding new resources
22:59:19 <danwent> Ok, so it seems like were we are at is that plugins will be able to register API extensions of any type using the standard openstack mechanisms.  This includes extending existing resources (data extension), adding new resources, and adding new methods to existing resources.  Is that a fair statement or is this still something we are debating?
22:59:40 <salv-orlando> Sounds fair to me
22:59:44 <somikbehera> +1
23:00:05 <danwent> I'm looking for "-1"'s at this point.  Anyone disagree?
23:00:06 <ying> not debating, just want make sure that we can use data extension independently
23:00:15 <jorgew> Keep in mind that params are also valuable
23:00:25 <danwent> jorge: can you clarify?
23:00:40 <danwent> adding params to existing resources?
23:00:46 <markwash_> GET /networks?rax-pie:extendedparam=foo
23:00:47 <jorgew> for example to implement queries and filters
23:00:48 <ying> because to extend <key, value> list, we may not want to re-define the statistics again
23:00:56 <jorgew> right
23:01:00 <danwent> Mark: ah, great point
23:01:35 <danwent> ok, so add in the ability to handle extensions in parameters.
23:01:48 <danwent> Ok, so I think we're all on the same page.
23:01:58 <ecarlin> jorge, am i correct that all extensions (data, resources, params, headers, mime-types, etc.) are independent
23:02:27 <jorgew> yes.
23:02:40 <danwent> other than webex, which we'll handle via email, are there other topics to cover?
23:02:47 <ying> then, the discovery is independent, too.
23:02:55 <danwent> webex = discussing hold and recording meetings over webex
23:02:57 <ying> thus, it's client to match them together?
23:03:11 <ying> based on version?
23:03:31 <ecarlin> all extensions can be queried and have specific meaning
23:03:32 <salv-orlando> danwent: agenda says "Quantum dev status" and "Open discussion"
23:03:35 <jorgew> right they are dependant on version
23:03:42 <ecarlin> extensions are independent of the api version, afaik
23:04:01 <danwent> # quantum-dev
23:04:07 <jorgew> no extensions are at the vesion level
23:04:10 <danwent> #topic quantum-dev
23:04:19 <danwent> man, we need rick :)
23:04:22 <salv-orlando> you had your hat-trick :-)
23:04:27 <danwent> :)
23:04:31 <ecarlin> ah, yes
23:04:34 <jamesurquhart> Congrats, Dan ;)
23:04:43 <ecarlin> because it's past version in the uri
23:04:56 <danwent> I mentioned earlier, we're hoping to get something out for review by the next meeting.  completely experimental, not a locked down API, but enough that someone could play with it.
23:05:11 <danwent> james: one of my few talents :)
23:05:21 <danwent> other quantum dev updates?
23:05:22 <jorgew> right an extension in ver 1 may be a core feature in ver 2
23:05:43 <danwent> #topic open-discussion
23:05:59 <salv-orlando> quantum dev update: API getting in space, code infrastructure "borrowed" from Openstack API
23:06:07 <AlexNeef> I wanted to mention I added a port state concept to the wiki
23:06:27 <AlexNeef> i was looking for feedback
23:06:28 <salv-orlando> Yes Alex I saw that and I'm considering it globally accepted.
23:06:40 <troytoman> just want to highlight the etherpad on network flows: http://etherpad.openstack.org/network-flows
23:06:42 <salv-orlando> at least that what it looked like on the etherpad
23:06:48 <danwent> Alex: yup, I think that's a good idea (it already had to +1s on the etherpad, no dissent).  Seems inline with L2 connectivity.
23:06:55 <danwent> to -> two
23:07:06 <Sumit> I wanted to bring up the topic semantics of "attachments/attach"
23:07:15 <troytoman> I am concerned that we don't have a consistent picture of how Nova/Quantum/Melange interact and what data is passed between services
23:07:17 <salv-orlando> yeah I wanted to discuss that as well
23:07:26 <troytoman> please chime in there if you have some thoughts
23:07:29 <Sumit> have posted the question on etherpad, may be we can continue the discussion there or over emails?
23:07:38 <salv-orlando> troytoman: Sure
23:07:53 <danwent> sumit:  on API etherpad?
23:08:01 <Sumit> yeah
23:08:08 <markwash_> troytoman: as a lazy nova dev :-), I'd love it if I didn't have to store as much state in my own db to query the status of my vms and their nics
23:08:11 <danwent> ok, sounds good.
23:08:25 <salv-orlando> Sumit: I'm ok with discussing it here, but we are already 8 minutes overtime
23:08:37 <Sumit> yeah no worries, we can take it offline
23:08:59 <troytoman> I've also added a strawman flow for the 3 services at the use cases wiki: http://wiki.openstack.org/NetworkUsecases
23:09:06 <Sumit> would request input though
23:09:11 <troytoman> posted it there so we could look at a diagram
23:09:29 <troytoman> just one idea - will look forward to the discussion throughout the week
23:09:44 <danwent> ok, sounds good troy
23:09:53 <danwent> I will definitely take a look and give feedback.
23:10:02 <danwent> any other topics for open discussion?
23:10:06 <salv-orlando> Silly question on code development:
23:10:07 <AlexNeef> I had one other open topic: that I was trying to address through capabilities but maybe people have other ideas
23:10:16 <danwent> salv was first :)
23:10:24 <salv-orlando> this is quick
23:10:39 <AlexNeef> np
23:10:46 <salv-orlando> We are borrowing a lot of code from nova. What about authorship and copyright?
23:11:45 <salv-orlando> if we take for instance nova.wsgi and make it quantum.common.wsgi should the file be still copyright of "Openstack LLC"?
23:11:45 <danwent> alex: can you pre-type?
23:11:45 <danwent> yeah, I had asked Rick about that earlier.
23:11:45 <danwent> he said there is no clear right answer.
23:12:14 <danwent> might thought is that if you borrow a whole file from someone, probably keep the copyright.
23:12:27 <danwent> if you think you'll end up filling most of the file, change it.
23:12:36 <danwent> that is what I do, but is by no means legally informed
23:12:55 <danwent> any lawyers on the channel?
23:13:14 <salv-orlando> I'm really not into legal things... I would not worry now about it. That's is something we can always sort out with sed
23:13:25 <danwent> agreed.
23:13:27 <danwent> Ok, alex?
23:13:54 <AlexNeef> There are different types of L2 we would like to support. Most obviously (for Mellanox) infiniband, but also people might what DCE/DCB to be able to do FCoE or other things. I need a mechaism to allow me to create a network with these capabilities.
23:14:07 <AlexNeef> i will send an email on this topic, it's not a quick thing i guess
23:14:23 <danwent> yeah, but an important point to tackle.  Sounds good Alex.
23:14:24 <salv-orlando> Not, and probably related to the "core" definition issue
23:14:27 <romain_lenglet> AlexNeef: isn't that possible with the current api proposal?
23:14:45 <AlexNeef> I don't think so
23:15:03 <AlexNeef> i need an indication from the VIFs of what their expected class of service is
23:15:06 <salv-orlando> No, that's not possible. The current API only creates "dumb" networks :-)
23:15:16 <romain_lenglet> and?
23:15:25 <romain_lenglet> what's the limitation?
23:15:28 <ecarlin> i think that should be abstracted by the quantum service
23:15:35 <romain_lenglet> me too
23:15:43 <salv-orlando> an "extension"?
23:15:43 <ecarlin> you just get an l2 network, how the provider chooses to implement it is up to them
23:15:47 <danwent> Alex: do you need more info from the remote-interface, it sounds like?
23:15:52 <AlexNeef> you can't abstract something like "lossless" over a lossy network
23:15:58 <ecarlin> you can't say give me a vmware or xenserver vm in nova
23:16:06 <ecarlin> you just get what the provider has set up
23:16:18 <danwent> ok, i think we've stumbled onto a bigger topic :)
23:16:21 <AlexNeef> but you can say give me a 4 core vm
23:16:38 <AlexNeef> or give me 5 gigs of RAM right
23:16:50 <ecarlin> ok, so now we are talking about "flavors" of networks
23:16:52 <troytoman> we did talk, at the summit, about networks having capabilities and needing some way to ID what those are
23:16:58 <danwent> Alex: maybe try to handle this with extensions, or describe how extensions are insufficient?  I don't think I fully understand the use case yet.
23:17:03 <AlexNeef> The technical compute guys will say give me a lossless network
23:17:15 <troytoman> you would either have to do it through a flavors mechanism or a more granular attribute level, I think
23:17:17 <romain_lenglet> I think that can be expressed / controlled by extensions to the core api
23:17:26 <somikbehera> +1
23:17:47 <AlexNeef> maybe
23:17:54 <ecarlin> i think it can be an extension or just a property of a partcular quantum deployment
23:17:55 <AlexNeef> you can do anything in extentions right
23:18:07 <danwent> Alex: that's the hope :)
23:18:08 <romain_lenglet> AlexNeef: yeah
23:18:15 <somikbehera> yup, since you have to provide implementation backing it
23:18:15 <jorgew> yea :-)
23:18:25 <danwent> ok, so I think we're good?
23:18:29 <ecarlin> the networks resource is L2 - that's all we are promising
23:18:41 <romain_lenglet> the only thing at this stage is to make sure that the core api doesn't prevent anybody from implementing their own kind of networking, possibly with extensions
23:18:57 <danwent> romain: yup, i agree with that goal.
23:19:08 <romain_lenglet> and I think we meet that goal with the current proposal
23:19:16 <danwent> ok, 20 minutes over time... we good to go?
23:19:29 <danwent> #endmeeting