Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 39E0EEA13 for ; Thu, 10 Jan 2013 19:07:46 +0000 (UTC) Received: (qmail 58018 invoked by uid 500); 10 Jan 2013 19:07:45 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 57989 invoked by uid 500); 10 Jan 2013 19:07:45 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 57980 invoked by uid 99); 10 Jan 2013 19:07:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Jan 2013 19:07:45 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of shadowsor@gmail.com designates 209.85.220.172 as permitted sender) Received: from [209.85.220.172] (HELO mail-vc0-f172.google.com) (209.85.220.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Jan 2013 19:07:39 +0000 Received: by mail-vc0-f172.google.com with SMTP id fw7so695598vcb.3 for ; Thu, 10 Jan 2013 11:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=auutPsu1OLZR7t8IiRyqIU6AeNSefdycWkTEaqayjvc=; b=mSu+VNzVns/tLCgXo42B2ovrERJ2yxjDd05wcLct3x0GEkNfG1n2z+JYp6MVGhXcIf 6No362ItCZjMd31x1BlgGbZ0Hed2w0szq+zcTtL57qY2DsfnqG9cVHtsO4QMtyXgCX1e khK1wsFOCZorchOMFaMFNga2LHvWr2aLNEbhfcRn6YsR6SmSdX9Q1wCdFFC3xpybWvT7 RZza7tilNMUuOskMEhCBU9Qmqq7RjlmvkGENmsSw266dN/biwJztc25rSJ3cuEWvqmjX VQ6kjrK603a8ZuJWGaYzZbrmGRJlhInS1hdfsQwos3/UUPXKYTQolSbJwaSL5WoHBUF3 dNEQ== MIME-Version: 1.0 Received: by 10.52.16.167 with SMTP id h7mr79159282vdd.117.1357844838217; Thu, 10 Jan 2013 11:07:18 -0800 (PST) Received: by 10.58.152.143 with HTTP; Thu, 10 Jan 2013 11:07:18 -0800 (PST) In-Reply-To: References: <4B2EA7702410EE4FB4AF54931A777FED010C1D21C454@LONPMAILBOX01.citrite.net> Date: Thu, 10 Jan 2013 12:07:18 -0700 Message-ID: Subject: Re: [DISCUSS] add/remove NIC on VM From: Marcus Sorensen To: "cloudstack-dev@incubator.apache.org" Content-Type: multipart/alternative; boundary=bcaec50409183df79a04d2f3e37f X-Virus-Checked: Checked by ClamAV on apache.org --bcaec50409183df79a04d2f3e37f Content-Type: text/plain; charset=ISO-8859-1 That would be great. We'll put the code in a feature branch and you can look at it and help us make any adjustments. Brian has been spending a lot of time on it, and I've wanted him to have credit for that by submitting to reviews.apache.org, once that happens we can create a branch for it. I think the proposal is a bit out of scope of 645 as it's more about making NICs their own entity like volumes are (and potentially entailing all of the extras Chiradeep mentions), whereas 645 is much simpler, its about modifying a VM that is already deployed rather than having to recreate it to get a network you want, but ultimately yours is a better long term method. I am wondering if it would be best to leave this particular feature 645 as-is, and then take on a separate effort to make NICs into standalone resources and pull in all of those other associated features. 645 would be a subset of the proposed functionality without really hindering us from moving on to the better solution. Alternatively we can drop 645 or make it a child of the bigger effort and just work toward it for 4.2. On Thu, Jan 10, 2013 at 11:45 AM, Chiradeep Vittal < Chiradeep.Vittal@citrix.com> wrote: > +1 on ENI-compatibility. > Note that there is more than just CLOUDSTACK-645 > - with ENI you can have multiple Ips per ENI > - with ENI the security group is attached to the nic instead of the vm > - there's additional APIs obviously to manage the lifecycle. > > On 1/10/13 8:36 AM, "Simon Waterhouse" > wrote: > > >There is an issue https://issues.apache.org/jira/browse/CLOUDSTACK-645 to > >add/remove a network on VM. > > > >I would like to alter the interface proposed so we instead add methods to > >explicitly create/destroy a NIC and attach/detach it from a VM - the > >feature would then be directly analogous to the AWS Elastic Network > >Interface. > > > >I am a newcomer to CloudStack development, but I would be happy to take > >on some work in this area (write feature spec, implement API methods > >etc.) to build upon the work contributed by Marcus and team - from what > >I can see from CLOUDSTACK-645 much of the required functionality is > >already in place; I am just suggesting we expose it in a slightly > >different way... > > > >Regards > >Simon > > --bcaec50409183df79a04d2f3e37f--