I'll add my vote for network type attribute as well. Nachi's proposal below is
a good example of how this can be used as well.
Thanks,
Kyle
On Jul 17, 2012, at 12:17 PM, Nachi Ueno wrote:
> Hi folks
>
> I'm +1 for a network type attribute, because the simple change can
> support another usecas
Hi Dan:
If no one else has expressed an interest in this area, I'd like to help out in
this area. devstack is an area I've spent some time playing around with and can
likely help out with.
Thanks,
Kyle
On Jul 5, 2012, at 1:29 PM, Dan Wendlandt wrote:
> Hi folks,
>
> I talked with the heads o
I agree with all your points here Dan. Lets not take any sort of upgrade hit
now, given the constraints on the V1 API you point out below. Going forward
post V2, upgrades will need to be taken into account.
On Jun 29, 2012, at 11:54 AM, Dan Wendlandt wrote:
> Hi Gary,
>
> Based on discussions
On Jun 29, 2012, at 1:50 AM, Dan Wendlandt wrote:
> Hi folks,
>
> Ryota from NEC sent an email to the list earlier tonight about pushing their
> NEC Quantum plugin (currently hosted outside of the main Quantum repo), into
> the main Quantum repo. As some of you will recall, at the Folsom summ
01 PM, Dan Wendlandt wrote:
>
>
> On Tue, Jun 26, 2012 at 7:40 PM, Kyle Mestery (kmestery)
> wrote:
>
> On Jun 26, 2012, at 1:37 PM, Dan Wendlandt wrote:
>
> >
> >
> > On Tue, Jun 26, 2012 at 6:28 PM, Kyle Mestery (kmestery)
> > wrote:
> > Hi folk
On Jun 26, 2012, at 1:37 PM, Dan Wendlandt wrote:
>
>
> On Tue, Jun 26, 2012 at 6:28 PM, Kyle Mestery (kmestery)
> wrote:
> Hi folks:
>
> I think this is the correct forum for this question, but please let me know.
>
> When Nova migrates a virtual machine fr
Hi folks:
I think this is the correct forum for this question, but please let me know.
When Nova migrates a virtual machine from one host to another, who transfers
the data for the port stored in the OVS DB? I assume this must be handled by
the virt driver. Is this the case? Or is this not supp
ng for some more
>> involved projects, I can probably give you some ideas as well. However,
>> some of these projects are on the critical path for Folsom, so its up to you
>> as to whether they would be a good match for the developer if they do not
>> have a lot of exper
Quantum devs:
Is this list of low hanging fruit bugs still accurate:
https://bugs.launchpad.net/quantum/+bugs?field.tag=low-hanging-fruit
Looks like out of the 7 on this list, 5 have already been committed. Are there
any new bugs that could be added to this list for new folks to work on?
I hav
On May 21, 2012, at 12:20 PM, Gary Kotton wrote:
>
> Hi,
> Thanks for the comments. Please see my replies inline. I hope that these will
> not take up too much CPU on your side.
> Thanks
> Gary
>
> On 05/21/2012 07:57 PM, Dan Wendlandt wrote:
>> Btw, this actually isn't the case for the OVS plug
On May 17, 2012, at 8:09 AM, Gary Kotton wrote:
> Hi,
> Please see the link for a detailed design of the scalable agent solution. I
> plan to start to work on the actual implementation beginnig of next week.
> Please let me know if you have any comments and or suggestions. Please note
> that I h
On Apr 30, 2012, at 11:44 PM, Gary Kotton wrote:
> On 05/01/2012 12:12 AM, Kyle Mestery (kmestery) wrote:
>> This is great Gary, thanks for sharing! I'm going through this in detail
>> now. Is the goal to try and create blueprints to address some of these
>> issue
This is great Gary, thanks for sharing! I'm going through this in detail now.
Is the goal to try and create blueprints to address some of these issues in
Quantum, with similar work on the oVirt side? Or until the core gaps and
limitations are fixed, oVirt integration will only be a POC?
Thanks,
+1 for the Google Hangout idea for those of us who are remote!
Kyle
On Jan 19, 2012, at 6:05 AM, Deepak Garg wrote:
>
> HI Dan,
>
> Regarding the remote meetups, G+ hangout is fine for me but if it compromises
> the meeting
> quality in any way, you may consider the in-person meetup and creat
14 matches
Mail list logo
