Open Stack

Apologies, that came out all wrong...

On 10 April 2014 09:28, John Garbutt <john at johngarbutt.com> wrote:
> I think writing this up as a nova-spec is going to make this process
> much easier:
> https://wiki.openstack.org/wiki/Blueprints#Nova
>
> It will save you having to re-write your document once you want to
> submit a blueprint, and we can all see each others comments in gerrit,
> and more clearly see how things change and evolve. The way the
> template in nova-spec works, it should also help you with structuring
> your argument.

Thats just want I would find easier, its just a suggestion.

> Please don't design assuming a single vendor solution, that is sure to
> get rejected (at least my me) at the blueprint review stage. You might
> want a different vendor in each AZ to isolate you from failures due to
> vendor bugs, if you are digging for a use case.

I guess thats a tenant use case, I got confused reading through those.

> I still can't see a clear description of the "tenant" use cases, I
> still think thats the key to getting agreement here, and getting
> useful feedback at the summit. Not sure I understand the tables, they
> seem a bit confusing/distracting.

Sorry, forgot to mention, you are making good progress here. But,
given the loop we are going around here, I think agreeing the "ideal"
use cases, then looking at the detail, and looping back to see if
everything "works" is probably the right approach. Other ideas
welcome!

Once there are the use cases, given all the Config vs API debates, I
would look at the pure data flow, in a Config/API agnostic way.
Agreeing the info needed from the user, then in the VIF driver, then
in between, etc. We should be able to agree on that, before returning
to the host aggregates API vs something new API vs more config debate.
Right it doesn't seem to be clear what is required, so its hard to
know what the best approach is, compared to other features we already
have in Nova.

At the moment I am struggling to see the whole picture, getting the
general idea clear before the summit would be awesome, so we can
discuss how to stage the implementation, deal with backwards
compatibility, etc.

Thanks,
John

> On 10 April 2014 09:14, yongli he <yongli.he at intel.com> wrote:
>> 于 2014年04月10日 15:59, Irena Berezovsky 写道:
>>
>> Hi Robert,
>>
>> Thanks a lot the inputs you posted in the doc.
>>
>> I have raised there few questions and added use case for High Availability.
>>
>> Another concern I have is regarding the assumption that there is no case to
>> mix different vendor cards in the setup. I think that mixing Cisco and Intel
>> or Mellanox cards does not make sense, but Intel and Mellanox cards can
>> coexist. At least for my understanding, but I may be wrong, both Intel and
>> Mellanox take HW VEB (HW embedded switch) approach.
>>
>> 1. open to mail list.
>> 2. admin/usr won't mixing Intel/Cisco/Mellanox card...., does not mean we
>> should disable it, or don't give a chance.
>> 3. i raise couple of question and questioning the aggregate solution. see
>> inline comments.
>>
>> https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit
>>
>> Yongli He
>>
>>
>>
>> Thanks,
>>
>> Irena
>>
>>
>>
>> From: Robert Li (baoli) [mailto:baoli at cisco.com]
>> Sent: Wednesday, April 09, 2014 11:11 PM
>> To: Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli
>> (yongli.he at intel.com); Itzik Brown; beagles at redhat.com
>> Subject: Re: PCI SR-IOV use cases initial doc
>>
>>
>>
>> Hi,
>>
>>
>>
>> I updated the doc with some of my thoughts.
>>
>>
>>
>> Thanks,
>>
>> Robert
>>
>>
>>
>> On 3/24/14, 8:41 AM, "Irena Berezovsky" <irenab at mellanox.com> wrote:
>>
>>
>>
>> Hi,
>>
>> I have created the initial doc to capture PCI SR-IOV networking use cases:
>>
>> https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit
>>
>>
>>
>> I have updated the agenda for tomorrow meeting to discuss the use cases.
>>
>>
>>
>> Please comment and update
>>
>>
>>
>> BR,
>>
>> Irena
>>
>>