Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A1F94200D11 for ; Mon, 2 Oct 2017 13:40:34 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A096D1609EF; Mon, 2 Oct 2017 11:40:34 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id BCD241609DE for ; Mon, 2 Oct 2017 13:40:33 +0200 (CEST) Received: (qmail 35749 invoked by uid 500); 2 Oct 2017 11:40:32 -0000 Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cloudstack.apache.org Delivered-To: mailing list users@cloudstack.apache.org Received: (qmail 35735 invoked by uid 99); 2 Oct 2017 11:40:32 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Oct 2017 11:40:32 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id BE0771A16E6 for ; Mon, 2 Oct 2017 11:40:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[FROM_MISSPACED=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id tuXq0ZBjof0U for ; Mon, 2 Oct 2017 11:40:29 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id E4A105FB06 for ; Mon, 2 Oct 2017 11:40:28 +0000 (UTC) Received: from localhost (cust-asf2.ponee.io [163.172.22.184]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 07404E0E18 for ; Mon, 2 Oct 2017 11:40:27 +0000 (UTC) MIME-Version: 1.0 Message-ID: Subject: Re: listTemplates: multiple items with same ID References: From: "Richard Downer" In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" x-ponymail-sender: 320bca71fc381a4a025636043ca86e734e31cf8b Date: Mon, 02 Oct 2017 11:40:27 -0000 x-ponymail-agent: PonyMail Composer/0.2 To: X-Mailer: LuaSocket 3.0-rc1 archived-at: Mon, 02 Oct 2017 11:40:34 -0000 Rafael, I have a sample `listTemplates` output. It's a real mixed bag. 5 templates with crossZones==false have duplicated IDs, but duplicated a different number of times. There are 4 instances of "GNU/Linux Fedora 20 - Minimal - 64bits", 14 instances of "GNU/Linux Ubuntu 14.04 - Minimal - 64bits"; other images duplicated 5 times or 8 times. If it is relevant - in each case, there are no other instances of the template with other IDs (i.e. there are 4 "GNU/Linux Fedora 20 - Minimal - 64bits" with a single ID, but no other templates with that name). Any theory on how this might have happened (database manual intervention)? If there's any other information you might find helpful please let me know, although I do not have direct access to the ACS instance in question (it's my client's client's ACS) so it may take me a little while to get answers. Thanks for your help! Richard. On 2017-10-02 11:31, Rafael Weingärtner wrote: > I would consider this a valid assumption. I checked one of the ACS > environments (version 4.9.2, updated from 4.5) that I know use multiple > zones, and all of the templates that have IDs duplicated have > crossZones==true. > > We would need more information from this ACS that you are debugging to pin > point the problem. How many templates that have crossZones==false are > presenting this duplication problem? If it is a bug, I would expect > everyone of them to have duplicated IDs. However, if this is the only thing > they differ from other single zone templates, I would guess that these > templates suffered from manual intervention in the database. > > On Mon, Oct 2, 2017 at 7:22 AM, Richard Downer wrote: > > > Rafael, > > > > Thanks for the information. Is there any information in listTemplates > > which would indicate if a template is in multiple zones? e.g. is the > > `crossZones` parameter a reliable indicator - can we normally be guaranteed > > that there will be no duplicated IDs in templates where crossZones==false? > > > > Currently jclouds will expect all templates where crossZones==false to > > have unique IDs. I am trying to determine if this is a valid assumption, or > > if jclouds needs a bug fix to be prepared for a duplicate ID at any time. > > > > Many thanks > > Richard. > > > > > > On 2017-09-29 15:24, Rafael Weingärtner > > wrote: > > > If the template is in multiple zones at the same time, then you are going > > > to have multiple template objects with the same ID. Otherwise, this > > should > > > not happen. You could check the database table "vm_template" to see if > > you > > > find any inconsistency there. > > > > > > On Fri, Sep 29, 2017 at 9:21 AM, Richard Downer > > wrote: > > > > > > > Hello, > > > > > > > > I'm debugging an issue on behalf of one of our users. We are using > > Apache > > > > jclouds to talk to Apache CloudStack which is on a customer's site. > > > > > > > > jclouds is invoking the `listTemplates` API, but is then choking while > > > > processing the query results. It seems that on this CloudStack > > instance, > > > > there are multiple templates with same ID - these all seem to refer to > > the > > > > same OS image, but in different zones - and jclouds doesn't like it > > when > > > > things have the same ID but different content. > > > > > > > > Digging through the email archives, I found this message: > > > > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/ > > > > 201501.mbox/%3C54C6C184.3010306@gmail.com%3E > > > > ..which suggests that if a template is cross-zone, then it has the > > same ID > > > > in all zones. > > > > > > > > However the templates in this case all have "crossZones":false, and the > > > > above linked message sets the expectation that templates will NOT have > > the > > > > same ID. > > > > > > > > Could somebody confirm the expectations for uniqueness of template > > IDs? Is > > > > it guaranteed that (under normal circumstances) template IDs are unique > > > > except for when crossZones is set - or is duplicate template IDs > > always a > > > > possibility? Does jclouds need to change its understanding of the > > > > uniqueness of template IDs, or is there something odd about this > > customer's > > > > CloudStack installation? > > > > > > > > Thanks! > > > > > > > > Richard. > > > > > > > > > > > > > > > > -- > > > Rafael Weingärtner > > > > > > > > > -- > Rafael Weingärtner >