Return-Path: X-Original-To: apmail-cloudstack-issues-archive@www.apache.org Delivered-To: apmail-cloudstack-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8B24F18542 for ; Fri, 31 Jul 2015 03:10:05 +0000 (UTC) Received: (qmail 9847 invoked by uid 500); 31 Jul 2015 03:10:05 -0000 Delivered-To: apmail-cloudstack-issues-archive@cloudstack.apache.org Received: (qmail 9698 invoked by uid 500); 31 Jul 2015 03:10:05 -0000 Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list issues@cloudstack.apache.org Received: (qmail 9519 invoked by uid 500); 31 Jul 2015 03:10:05 -0000 Delivered-To: apmail-incubator-cloudstack-issues@incubator.apache.org Received: (qmail 9494 invoked by uid 99); 31 Jul 2015 03:10:05 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jul 2015 03:10:05 +0000 Date: Fri, 31 Jul 2015 03:10:05 +0000 (UTC) From: "Dave Garbus (JIRA)" To: cloudstack-issues@incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CLOUDSTACK-8691) deployVirtualMachine should not error when userdata is provided if at least one NIC supports it MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CLOUDSTACK-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Garbus updated CLOUDSTACK-8691: ------------------------------------ Description: In our environment, we assign VMs a default NIC without the userdata service, however, we also assign a secondary network that has the userdata service enabled. In previous releases, and confirmed in the issue below, the API simply warned about the default NIC not supporting userdata but continued to go on to create the virtual machine. https://issues.apache.org/jira/browse/CLOUDSTACK-4630?focusedCommentId=13770148&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13770148 As of 4.5.1, The API completely errors out and does not create the VM, even though one of the NICs supports the userdata service. I can get around this behavior by calling deployVirtualMachine with 'startvm' set to false, and then a call to updateVirtualMachine with userdata=. Of course, this breaks the automation that we have in place. I really don't understand why the API would fail to create the VM as long as one of the NICs supported the userdata service. This seems like a regression from the previous releases and should be fixed. Here is the issue in which the change was made: https://issues.apache.org/jira/browse/CLOUDSTACK-6748 Steps to reproduce: 1. Create two networks in CloudStack, one with userdata service enabled, and one without. 2. Use deployVirtualMachine API call to create a virtual machine with both networks as well as userdata. The first (default) network should be the one without the userdata service and the second network should be the userdata-enabled network. 3. The API should present the following error: {{Error: Unable to deploy VM as UserData is provided while deploying the VM, but there is no support for UserData service in the default network }} was: In our environment, we assign VMs a default NIC without the userdata service, however, we also assign a secondary network that has the userdata service enabled. In previous releases, and confirmed in the issue below, the API simply warned about the default NIC not supporting userdata but continued to go on to create the virtual machine. https://issues.apache.org/jira/browse/CLOUDSTACK-4630?focusedCommentId=13770148&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13770148 As of 4.5.1, The API completely errors out and does not create the VM, even though one of the NICs supports the userdata service. I can get around this behavior by calling deployVirtualMachine with 'startvm' set to false, and then a call to updateVirtualMachine with userdata=. Of course, this breaks the automation that we have in place. I really don't understand why the API would fail to create the VM as long as one of the NICs supported the userdata service. This seems like a regression from the previous releases and should be fixed. Here is the issue in which the change was made: https://issues.apache.org/jira/browse/CLOUDSTACK-6748 Steps to reproduce: 1. Create two networks in CloudStack, one with userdata service enabled, and one without. 2. Use deployVirtualMachine API call to create a virtual machine with both networks as well as userdata. The first (default) network should be the one without the userdata service and the second network should be the userdata-enabled network. 3. The API should present the following error: {{Error: Unable to deploy VM as UserData is provided while deploying the VM, but there is no support for UserData service in the default network 217}} > deployVirtualMachine should not error when userdata is provided if at least one NIC supports it > ----------------------------------------------------------------------------------------------- > > Key: CLOUDSTACK-8691 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8691 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the default.) > Components: API > Affects Versions: 4.5.1 > Environment: CentOS 6.X > Reporter: Dave Garbus > Priority: Critical > Labels: userdata > > In our environment, we assign VMs a default NIC without the userdata service, however, we also assign a secondary network that has the userdata service enabled. In previous releases, and confirmed in the issue below, the API simply warned about the default NIC not supporting userdata but continued to go on to create the virtual machine. > https://issues.apache.org/jira/browse/CLOUDSTACK-4630?focusedCommentId=13770148&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13770148 > As of 4.5.1, The API completely errors out and does not create the VM, even though one of the NICs supports the userdata service. I can get around this behavior by calling deployVirtualMachine with 'startvm' set to false, and then a call to updateVirtualMachine with userdata=. Of course, this breaks the automation that we have in place. > I really don't understand why the API would fail to create the VM as long as one of the NICs supported the userdata service. This seems like a regression from the previous releases and should be fixed. Here is the issue in which the change was made: > https://issues.apache.org/jira/browse/CLOUDSTACK-6748 > Steps to reproduce: > 1. Create two networks in CloudStack, one with userdata service enabled, and one without. > 2. Use deployVirtualMachine API call to create a virtual machine with both networks as well as userdata. The first (default) network should be the one without the userdata service and the second network should be the userdata-enabled network. > 3. The API should present the following error: {{Error: Unable to deploy VM as UserData is provided while deploying the VM, but there is no support for UserData service in the default network }} -- This message was sent by Atlassian JIRA (v6.3.4#6332)