[openstack-dev] [Nova] Drop the Amazon specific flavor prefix "m1." from OpenStack flavor names

[Rohan Kanade]

This is regarding the bug  https://bugs.launchpad.net/nova/+bug/1161988

I think we should drop the Amazon specific flavor prefix "m1."  from
OpenStack flavor names
because they have no meaning in OpenStack where each deployment uses
different hardware.

Amazon has the M1 prefix to denote high memory, and it also denotes that
the instance created from M1 instance types are based on Intel Xeon
processors.
https://aws.amazon.com/ec2/instance-types/#instance-details


Which is not at all the case with OpenStack, hence i think we should remove
the prefixes from the Flavors. The only reason i see to keep the prefix is
if we are going to create some association between the flavor prefixes and
the type of hardware used or some special characteristics provided with for
that prefix (high mem, high cpu).

Regards,
Rohan Kanade
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Marconi][Oslo] Discoverable home document for APIs (Was: Re: [Nova][Glance] Support of v1 and v2 glance APIs in Nova)

[Flavio Percoco]

On 25/11/13 16:50 -0600, Dolph Mathews wrote:


On Mon, Nov 25, 2013 at 2:41 AM, Flavio Percoco  wrote:

   On 25/11/13 09:28 +1000, Jamie Lennox wrote:

   So the way we have this in keystone at least is that querying GET /
   will
   return all available API versions and querying /v2.0 for example is a
   similar result with just the v2 endpoint. So you can hard pin a version
   by using the versioned URL.

   I spoke to somebody the other day about the discovery process in
   services. The long term goal should be that the service catalog
   contains
   unversioned endpoints and that all clients should do discovery. For
   keystone the review has been underway for a while now:
   https://review.openstack.org/#/c/38414/ the basics of this should be
   able to be moved into OSLO for other projects if required.


   Did you guys create your own 'home document' language? or did you base
   it on some existing format? Is it documented somewhere? IIRC, there's
   a thread where part of this was discussed, it was related to horizon.

   I'm curious to know what you guys did and if you knew about
   JSON-Home[0] when you started working on this.


It looks like our multiple choice response might predate Nottingham's proposal,
but not by much. In keystone, it's been stable since I joined the project,
midway through the diablo cycle (summer 2011). I don't know any more history
than that, but I've CC'd Jorge Williams, who probably knows.

I really like Nottingham's approach of adding relational links from the base
endpoint, I've been thinking about doing the same for keystone for quite a
while.


As crazy as it sounds, have you guys considered migrating to
Nottingham's approach?

We picked this approach because we didn't want to invent it ourselves
and this happens to have a well defined RFC as well.

If there's something Nottingham's proposal lacks of, I think we could
provide some feedback and help making it better.



   We used json-home for Marconi v1 and we'd want the client to work in a
   'follow your nose' way. Since, I'd prefer OpenStack modules to use the
   same language for this, I'm curious to know why - if so - you
   created your own spec, what are the benefits and if it's documented
   somewhere.


Then why didn't Marconi follow the lead of one of the other projects? ;)


LOOOL, I knew you were going to say that. I think I knew about you
guys having something similar but at some point I most have forgotten
about it. That being said, the main rationals were:

   1) Using something documented and known upstream made more sense
   and it also helps getting more contributions from the community.
   2) We already knew it, which falls back in point 1.



I completely agree though - standardized version discovery across the ecosystem
would be fantastic.


All that being said, I don't think it would be very hard to migrate
Marconi to something common if we agree that json-home is not good
enough for OpenStack. Nonetheless, it'd be a shame not to provide
feedback to Mark Nottingham about it. So far, his approach has been
good enough for us - but, you know, Marconi is still way too small.

Is keystone's home schema spec documented somewhere?

Cheers,
FF

--
@flaper87
Flavio Percoco


pgpBx9SMtsMIc.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

[Chmouel Boudjnah]

On Tue, Nov 26, 2013 at 5:25 AM, Adam Young  wrote:

> Back in the Day, Barbican was just one Service of Cloud Keep.  While I
> would say that KDS belongs in the Cloud Keep, it is not the same as, and
> should not be deployed with Barbican.  Is it possible to keep them as
> separate services?  I think that is the right way to go.  Barbican is for
> the  end users of Cloud, but KDS is not.  Does this make sense?
>

I think that make sense to say that Barbican is for public and KDS for
internal services and should be kept as different WSGI daemons. If we were
having it in two different projects when assuming barbican graduate it may
end-up more confusing for the end user.

Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate broken right now

[Flavio Percoco]

On 26/11/13 00:55 -0600, Alex Gaynor wrote:

Hi all,

Right now there appears to be an issue in the gate whereby all python2.6 jobs
break.

This is resulting in a massive amount of churn for the gate, which has it
basically at a standstill. It's 1AM in the US central time, and I wasn't able
to find anyone on IRC who was able to look into this.



This seems to be the issue you're talking about, is it?

http://logs.openstack.org/49/57049/2/gate/gate-swift-python26/c1aedf1/console.html

Thanks for the heads up!
FF

--
@flaper87
Flavio Percoco


pgpkReKS5IQwB.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Keystone client support for Py3K

[Flavio Percoco]

On 25/11/13 15:46 -0500, Chuck Short wrote:

Hi,

There is a gate for python-keystoneclient for py33. I have been trying to port
it over to python3 but its blocked on httpretty right now not being pyhon3
compatible.


Erm, I checked a patch yday and didn't see the gate, I rechecked today
and now the gate is there. Is it something that happened between yday
and today, or did I go blind for 5s and didn't noticed it? :D

Thanks for the info Chuck. Are there other pieces blocking this from
moving forward? Is there something we can help with? I bet there is,
I'd like to know what parts you think should be addressed first.

Thanks again,
FF

--
@flaper87
Flavio Percoco


pgpwMjgjSiy0i.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Flavio Percoco]

On 25/11/13 21:24 -0600, Dolph Mathews wrote:


On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins 
wrote:

   This has been mentioned in other threads, but I thought I'd call it
   out and make it an explicit topic.

   We have over 100 recheck bugs open on
   http://status.openstack.org/rechecks/ - there is quite a bit of
   variation in how frequently they are seen :(. In a way thats good, but
   stuff that have been open for months and not seen are likely noise (in
   /rechecks). The rest - the ones we see happening are noise in the
   gate.

   The lower we can drive the spurious failure rate, the less repetitive
   analysing a failure will be, and the more obvious new ones will be -
   it forms a virtuous circle.

   However, many of these bugs - a random check of the first 5 listed
   found /none/ that had been triaged - are no prioritised for fixing.

   So my proposal is that we make it part of the base hygiene for a
   project that any recheck bugs being seen (either by elastic-recheck or
   manual inspection) be considered critical and prioritised above
   feature work.


I agree with the notion here (that fixing transient failures is critically high
priority work for the community) -- but marking the bug as "critical" priority
is just a subjective abuse of the priority field. A non-critical bug is not
necessarily non-critical work. The "critical" status should be reserved for
issues that are actually non-shippable, catastrophically breaking issues.



I agree with Dolph. I'd rather tag them instead of marking them as
critical. It is also true that it's not possible to land a patch if
the gate fails, which means these bugs can be interpreted as critical
as well. However, I personally don't think we should let the gate mark
those bugs as critical.

Would a combination of High + tag - elastic-recheck - make sense?

With the above it would be easier to triage them, to know where they
came from and to prioritise them correctly.

Cheers,
FF

--
@flaper87
Flavio Percoco


pgpdMm3Ymu0RB.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate broken right now

[Chmouel Boudjnah]

On Tue, Nov 26, 2013 at 9:52 AM, Flavio Percoco  wrote:

> This seems to be the issue you're talking about, is it?
>
> http://logs.openstack.org/49/57049/2/gate/gate-swift-
> python26/c1aedf1/console.html
>

Thanks for the heads up indeed, I was wondering if there was somebody on
shift/awake from infra during european hours?

This seems to be a pure infrastructure issue with the python26 gate as this
is happen for all py26 tests.

Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Bob Ball]

> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 25 November 2013 22:37
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
> deprecation plan
> 
> On 11/25/2013 05:19 PM, Matt Riedemann wrote:
> > I'll play devil's advocate here and ask this question before someone
> > else does.  I'm assuming that the requirement of a 'full' tempest run
> > means running this [1].  Is that correct?  It's just confusing sometimes
> > because there are other things in Tempest that aren't in the 'full' run,
> > like stress tests.
> >
> > [1] https://github.com/openstack/tempest/blob/master/tox.ini#L33
> >
> 
> I think the short answer is, "whatever we're running against all Nova
> changes in the gate".

Can we strip this down a bit?  I don't see any benefit in running tests that 
verify Swift's behaviour other than where it interacts with Nova.

I hope we can safely say that we should run against all "gating" tests which 
require Nova?  Currently we run quite a number of tests in the gate that 
succeed even when Nova is not running as the gate isn't just for Nova but for 
all projects.

It would be trivial to kill Nova, run the full tempest and only enable those 
jobs for a new flavour which we must run.

Thoughts?

Bob 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] EC2 Filter

[Sebastian Porombka]

Oh hai!

That's nice to hear! I would like to help by adapting this patch set to
latest and 
I will try to work out the tempest test cases.

Is there any form of documentation for new developers?

Thanks in advance
Sebastian

--
Sebastian Porombka, M.Sc.
Zentrum für Informations- und Medientechnologien (IMT)
Universität Paderborn

E-Mail: porom...@uni-paderborn.de
Tel.: 05251/60-5999
Fax: 05251/60-48-5999
Raum: N5.314 


Q: Why is this email five sentences or less?
A: http://five.sentenc.es

Please consider the environment before printing this email.




Von:  Joe Gordon 
Antworten an:  "OpenStack Development Mailing List (not for usage
questions)" 
Datum:  Montag, 25. November 2013 20:03
An:  "OpenStack Development Mailing List (not for usage questions)"

Betreff:  Re: [openstack-dev] EC2 Filter


>
>
>
>On Mon, Nov 25, 2013 at 6:22 AM, Sebastian Porombka
> wrote:
>
>Hi Folks.
>
>I stumbled over the lacking of EC2 Api filter support on Openstack and
>justinsb¹s (and the other people I forgot to mention here) attempt [1] to
>implement this against diabolo.
>
>I¹m highly interested in this feature and would like (to try) to implement
>this features against the latest base. My problem is, that I¹m unable find
>informations about the rejection of this set of patches in 2011.
>
>
>
>
>I am also not sure why this didn't get merged, but I don't see why we
>would block this code today, especially if it comes with some tempests
>tests too.
> 
>
>
>Can anybody help me?
>
>Greetings
>  Sebastian
>
>[1] 
>https://code.launchpad.net/~justin-fathomdb/nova/ec2-filters
>
>--
>Sebastian Porombka, M.Sc.
>Zentrum für Informations- und Medientechnologien (IMT)
>Universität Paderborn
>
>E-Mail: porom...@uni-paderborn.de
>Tel.: 05251/60-5999
>Fax: 05251/60-48-5999
>Raum: N5.314
>
>
>Q: Why is this email five sentences or less?
>A: http://five.sentenc.es
>
>Please consider the environment before printing this email.
>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fw: [Neutron][IPv6] Meeting logs from the first IRC meeting

[Da Zhao Y Yu]

Hi ShiXiong,

I have reviewed the code you submitted in Community. Some comments, please 
to fix it.

Also I think we need more discuss with Sean about Neutron support DHCPv6, 
before this, please review Sean and my code change for Neutron support 
DHCPv6:
https://review.openstack.org/#/c/56184/4 and 
https://review.openstack.org/#/c/52983/3

I think your code change have some conflict with them, and the design is 
also different.

Sean, what about your progress? I saw your code change jekins still in 
failed status.


Thanks & Best Regards
Yu Da Zhao(于大钊)
--
Cloud Solutions & OpenStack Development
China Systems & Technology Laboratory in Beijing
Email: d...@cn.ibm.com
Tel:   (86)10-82450677
--





- Forwarded by Yang XY Yu/China/IBM on 2013-11-25 22:17 -

Shixiong Shang  
2013-11-25 12:59
Please respond to
"OpenStack Development Mailing List \(not for usage questions\)" 



To
"OpenStack Development Mailing List (not for usage questions)" 

cc
Tuttle Randy 
Subject
Re: [openstack-dev] [Neutron][IPv6] Meeting logs from the first IRC 
meeting






Hi, guys:

I took the action item to submit the code for review based on our 
discussion during the first IRC meeting. Here is the link: 

https://review.openstack.org/#/c/58186/

The changes we proposed are based on the POC work my friend (Randy Tuttle) 
and I did back in June on Grizzly and most recent update on Havana in Oct. 
If you are interested in the whitepaper, please unicast us.

Thanks!

Shixiong




On Nov 21, 2013, at 5:34 PM, Collins, Sean (Contractor) 
 wrote:

> Meeting minutes and the logs for the Neutron IPv6 meeting has been
> posted.
> 
> We will not meet next week, due to the Thanksgiving holiday in the US.
> 
> Our next meeting will be Thursday Dec 5th - 2100 UTC, where we will
> review the goals from this week's meeting and look to create actionable
> items for I-2.
> 
> [1] https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam
> [2] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/
> -- 
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] JavaScript use policy

[Radomir Dopieralski]

On 25/11/13 18:29, Lyle, David wrote:
> We have been having this discussion here on the mailing list [1][2] and also 
> in the Horizon team meetings [3].
> 
> The overall consensus has been that we are going to move forward with a 
> JavaScript requirement.

[...]

> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/018629.html
> [2] 
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/019894.html
> [3] http://eavesdrop.openstack.org/meetings/horizon/

Please forgive me rising this subject then. The links you provided talk
about using AngularJS and node.js, and I think that's independent from
whether we will require JavaScript in the user's browser or not. In
fact, I'm following closely the AngularJS discussion and the way it is
going to be introduced specifically allows non-JavaScript fallbacks. I
also couldn't find anything about requiring JavaScript in Horizon's
documentation, so I was under the impression that this topic is still open.

I'm very happy to hear that there is a consensus and that we have a
clear policy about it. Could we maybe put that policy in writing
somewhere in the Horizon documentation, so that other people won't make
a fool of them like I just did?

-- 
Radomir Dopieralski

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate broken right now

[Sylvain Bauza]

Indeed, Climate is also impacted.

Is there a bug already open or shall I create one ?
-Sylvain


Le 26/11/2013 10:46, Chmouel Boudjnah a écrit :


On Tue, Nov 26, 2013 at 9:52 AM, Flavio Percoco > wrote:


This seems to be the issue you're talking about, is it?


http://logs.openstack.org/49/57049/2/gate/gate-swift-python26/c1aedf1/console.html


Thanks for the heads up indeed, I was wondering if there was somebody 
on shift/awake from infra during european hours?


This seems to be a pure infrastructure issue with the python26 gate as 
this is happen for all py26 tests.


Chmouel.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate broken right now

[Sylvain Bauza]

http://zuul.openstack.org/rechecks is not mentioning it by the way.

Le 26/11/2013 11:32, Sylvain Bauza a écrit :

Indeed, Climate is also impacted.

Is there a bug already open or shall I create one ?
-Sylvain


Le 26/11/2013 10:46, Chmouel Boudjnah a écrit :


On Tue, Nov 26, 2013 at 9:52 AM, Flavio Percoco > wrote:


This seems to be the issue you're talking about, is it?


http://logs.openstack.org/49/57049/2/gate/gate-swift-python26/c1aedf1/console.html


Thanks for the heads up indeed, I was wondering if there was somebody 
on shift/awake from infra during european hours?


This seems to be a pure infrastructure issue with the python26 gate 
as this is happen for all py26 tests.


Chmouel.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate broken right now

[Sylvain Bauza]

Created https://bugs.launchpad.net/openstack-ci/+bug/1255041

Le 26/11/2013 11:34, Sylvain Bauza a écrit :

http://zuul.openstack.org/rechecks is not mentioning it by the way.

Le 26/11/2013 11:32, Sylvain Bauza a écrit :

Indeed, Climate is also impacted.

Is there a bug already open or shall I create one ?
-Sylvain


Le 26/11/2013 10:46, Chmouel Boudjnah a écrit :


On Tue, Nov 26, 2013 at 9:52 AM, Flavio Percoco > wrote:


This seems to be the issue you're talking about, is it?


http://logs.openstack.org/49/57049/2/gate/gate-swift-python26/c1aedf1/console.html


Thanks for the heads up indeed, I was wondering if there was 
somebody on shift/awake from infra during european hours?


This seems to be a pure infrastructure issue with the python26 gate 
as this is happen for all py26 tests.


Chmouel.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Thierry Carrez]

Dolph Mathews wrote:
> On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
> mailto:robe...@robertcollins.net>> wrote:
> 
> So my proposal is that we make it part of the base hygiene for a
> project that any recheck bugs being seen (either by elastic-recheck or
> manual inspection) be considered critical and prioritised above
> feature work.
> 
> I agree with the notion here (that fixing transient failures is
> critically high priority work for the community) -- but marking the bug
> as "critical" priority is just a subjective abuse of the priority field.
> A non-critical bug is not necessarily non-critical work. The "critical"
> status should be reserved for issues that are actually non-shippable,
> catastrophically breaking issues.

It's a classic bugtracking dilemma where the "Importance" field is both
used to describe bug impact and priority... while they don't always match.

That said, the "impact" of those bugs, considering potential development
activity breakage, *is* quite critical (they all are timebombs which
will create future gate fails if not handled at top priority).

So I think marking them Critical + tagging them is not that much of an
abuse, if we start including the gate impact in our bug Impact
assessments. That said, I'm also fine with High+Tag, as long as it
triggers the appropriate fast response everywhere.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Christopher Yeoh]

On Tue, Nov 26, 2013 at 7:37 PM, Flavio Percoco  wrote:

> On 25/11/13 21:24 -0600, Dolph Mathews wrote:
>
>>
>> On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins <
>> robe...@robertcollins.net>
>> wrote:
>> I agree with the notion here (that fixing transient failures is
>> critically high
>> priority work for the community) -- but marking the bug as "critical"
>> priority
>> is just a subjective abuse of the priority field. A non-critical bug is
>> not
>> necessarily non-critical work. The "critical" status should be reserved
>> for
>> issues that are actually non-shippable, catastrophically breaking issues.
>>
>
>
> I agree with Dolph. I'd rather tag them instead of marking them as
> critical. It is also true that it's not possible to land a patch if
> the gate fails, which means these bugs can be interpreted as critical
> as well. However, I personally don't think we should let the gate mark
> those bugs as critical.
>
> Would a combination of High + tag - elastic-recheck - make sense?
>
> With the above it would be easier to triage them, to know where they
> came from and to prioritise them correctly.
>
>
Given that they potentially block not only critical bugs from the same
project from being fixed, but
critical bugs from all projects being fixed (and at the very least they
slow the process of fixing them
down), I think it's quite reasonable to mark them as critical.

I think it'd also be useful if there was a convention of manually tagging
the bugs as "gate" (or something
similar) when the submitting ones which were the result of transient
failures. It would make them easier
to find and reduce duplicated bug reports which can hide the apparent
regularity of the bug occurring

 Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] tenant or project

[Christopher Yeoh]

On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco  wrote:

> On 24/11/13 12:47 -0500, Doug Hellmann wrote:
>
>>
>>
>>
>> On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg 
>> wrote:
>>
>>In all honesty it doesn't matter which term we go with.  As long as we
>> are
>>consistent and define the meaning.  I think we can argue intuitive vs
>>non-intuitive in this case unto the ground.  I prefer "project" to
>> tenant,
>>but beyond being a bit of an "overloaded" term, I really don't think
>> anyone
>>will really notice one way or another as long as everything is using
>> the
>>same terminology.  We could call it "grouping-of-openstack-things" if
>> we
>>wanted to (though I might have to pull some hair out if we go to that
>>terminology).  However, with all that in mind, we have made the
>> choice to move toward
>>project (horizon, keystone, OSC, keystoneclient) and have some momentum
>>behind that push (plus newer projects already use the project
>>nomenclature).   Making a change back to tenant might prove a worse UX
>> than
>>moving everything else in line (nova I think is the one real major
>> hurdle
>>to get converted over, and deprecation of keystone v2 API).
>>
>> FWIW, ceilometer also uses project in our API (although some of our docs
>> use
>> the terms interchangeably).
>>
>
> And, FWIW, Marconi uses project as well.
>
>
Well project seems to be the way everyone is heading long term.  So we'll
do this for the Nova
V3 API.  As others have mentioned, I think the most important this is that
we all end up using
the same terminology (though with the long life of APIs we're stuck with
the both for a few years
at least).

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Marconi][Oslo] Discoverable home document for APIs (Was: Re: [Nova][Glance] Support of v1 and v2 glance APIs in Nova)

[Sam Harwell]

Nottingham's RFC is exceptionally well documented. I would be strongly against 
Marconi moving from that RFC to any other format unless the alternative was 
equally well documented. If they were equally well documented, then I would be 
neutral on changing it.

More importantly, if a project is providing discoverability for their API and 
recommending the use of that to clients, the primary unit and integration tests 
for the service need to use the discovery mechanism. It doesn't help to provide 
"discoverability" if the implementation doesn't actually provide working links 
in the service descriptor (regardless of the specific format used).

Sam

-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com] 
Sent: Tuesday, November 26, 2013 2:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jorge Williams
Subject: Re: [openstack-dev] [Keystone][Marconi][Oslo] Discoverable home 
document for APIs (Was: Re: [Nova][Glance] Support of v1 and v2 glance APIs in 
Nova)

On 25/11/13 16:50 -0600, Dolph Mathews wrote:
>
>On Mon, Nov 25, 2013 at 2:41 AM, Flavio Percoco  wrote:
>
>On 25/11/13 09:28 +1000, Jamie Lennox wrote:
>
>So the way we have this in keystone at least is that querying GET /
>will
>return all available API versions and querying /v2.0 for example is a
>similar result with just the v2 endpoint. So you can hard pin a version
>by using the versioned URL.
>
>I spoke to somebody the other day about the discovery process in
>services. The long term goal should be that the service catalog
>contains
>unversioned endpoints and that all clients should do discovery. For
>keystone the review has been underway for a while now:
>https://review.openstack.org/#/c/38414/ the basics of this should be
>able to be moved into OSLO for other projects if required.
>
>
>Did you guys create your own 'home document' language? or did you base
>it on some existing format? Is it documented somewhere? IIRC, there's
>a thread where part of this was discussed, it was related to horizon.
>
>I'm curious to know what you guys did and if you knew about
>JSON-Home[0] when you started working on this.
>
>
>It looks like our multiple choice response might predate Nottingham's 
>proposal, but not by much. In keystone, it's been stable since I joined 
>the project, midway through the diablo cycle (summer 2011). I don't 
>know any more history than that, but I've CC'd Jorge Williams, who probably 
>knows.
>
>I really like Nottingham's approach of adding relational links from the 
>base endpoint, I've been thinking about doing the same for keystone for 
>quite a while.

As crazy as it sounds, have you guys considered migrating to Nottingham's 
approach?

We picked this approach because we didn't want to invent it ourselves and this 
happens to have a well defined RFC as well.

If there's something Nottingham's proposal lacks of, I think we could provide 
some feedback and help making it better.

>
>We used json-home for Marconi v1 and we'd want the client to work in a
>'follow your nose' way. Since, I'd prefer OpenStack modules to use the
>same language for this, I'm curious to know why - if so - you
>created your own spec, what are the benefits and if it's documented
>somewhere.
>
>
>Then why didn't Marconi follow the lead of one of the other projects? 
>;)

LOOOL, I knew you were going to say that. I think I knew about you guys having 
something similar but at some point I most have forgotten about it. That being 
said, the main rationals were:

1) Using something documented and known upstream made more sense
and it also helps getting more contributions from the community.
2) We already knew it, which falls back in point 1.


>I completely agree though - standardized version discovery across the 
>ecosystem would be fantastic.

All that being said, I don't think it would be very hard to migrate Marconi to 
something common if we agree that json-home is not good enough for OpenStack. 
Nonetheless, it'd be a shame not to provide feedback to Mark Nottingham about 
it. So far, his approach has been good enough for us - but, you know, Marconi 
is still way too small.

Is keystone's home schema spec documented somewhere?

Cheers,
FF

--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Javascript development improvement

[Imre Farkas]

On 11/22/2013 06:13 PM, Julie Pichon wrote:

"Imre Farkas"  wrote:

On 11/22/2013 02:49 PM, Maxime Vidori wrote:

It seems a bit crazy to me to introduce NodeJS as a dependency just for
the sake of an easy way to run jslint. There are other options
available that run without NodeJS as a dependency.


Sadly, the only solutions which try to implement jslint in pure python are
in alpha or abandoned. If you have a python library which has the same
quality as jslint (which is written by Douglas Crockford himself), I will
be glad to take a look at it.


There's a jslint fork called jshint which is able to run in the browser
without any node.js dependency.

I created a POC patch [1] long time ago to demonstrate its capabilities.
It's integrated with qunit and runs automatically with the horizon test
suite.


Thanks Imre, this is interesting. Would you mind restoring the patch? If
you don't have time to work on it please indicate so (I don't think it's
possible to pick up a patch if the status is 'Abandoned') and someone else
can look into the test failures.


Julie, Matthias,
I restored the patch, rebased, fixed the tests, added the test files as 
Radomir suggested and removed the .jshintrc file.


The original patch was WIP and I left the failing tests intentionally, 
so that it was easier to compare the two solutions (node.js vs pure 
qunit). But as I wrote, it's cleaned up by now and only contains the latter.


Imre




The patch also contains a .jshintrc file for the node.js package but you
can remove it since it's not used by the qunit+jshint test at all.


Sounds good.

Julie


Imre

[1] https://review.openstack.org/#/c/41087/


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to stage client major releases in Gerrit?

[Thierry Carrez]

Mark Washenberger wrote:
> > FWIW, I don't think the changes glanceclient needs in v1 will
> break the
> > 'B' case above. But it does raise a question--if they did, would it be
> > sufficient to backport a change to adapt old supported stable B
> versions
> > of, say, Nova, to work with the v1 client? Honestly asking, a big
> ol' NO
> > is okay.
> 
> I'm not sure I follow all the pronouns. Could you re-state this again, I
> think I know what you're asking, but I'd like to be sure.
> 
> 
> Sorry for being so vague. I'll try to be specific.
> 
> Branch nova/stable/folsom depends on python-glanceclient/master. Suppose
> we find that nova/stable/folsom testing is broken when we stage
> (hopefully before merging) the breaking changes that are part of the
> python-glanceclient v1.0.0 release. Would it be acceptable in this case
> to have a compatibility patch to nova/stable/folsom? Or will the only
> option be to modify the python-glanceclient patch to maintain compatibility?

I think that would be an acceptable backport, with bonus points if you
can make sure it doesn't break old versions of the libs that could still
be used with stable/folsom. (That's a theoretical example though, since
we don't have a stable/folsom maintained branch anymore).

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Russell Bryant]

On 11/25/2013 08:00 PM, Matt Riedemann wrote:
> On Monday, November 25, 2013 4:37:29 PM, Russell Bryant wrote:
>> I think the short answer is, "whatever we're running against all Nova
>> changes in the gate".
> 
> Maybe a silly question, but is what is run against the check queue any
> different from the gate queue?

A better question, where can I look to see the current configuration
used for jenkins jobs?

First look at the jenkins_job_builder config to see what options are set
for various jobs:

http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml

Then, see devstack-gate here and search for TEMPEST.  You'll see what
the knobs set in the job configs do.

http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate.sh

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Drop the Amazon specific flavor prefix "m1." from OpenStack flavor names

[Russell Bryant]

On 11/26/2013 03:06 AM, Rohan Kanade wrote:
> This is regarding the bug  https://bugs.launchpad.net/nova/+bug/1161988
> 
> I think we should drop the Amazon specific flavor prefix "m1."  from
> OpenStack flavor names
> because they have no meaning in OpenStack where each deployment uses
> different hardware.
> 
> Amazon has the M1 prefix to denote high memory, and it also denotes that
> the instance created from M1 instance types are based on Intel Xeon
> processors. 
> https://aws.amazon.com/ec2/instance-types/#instance-details
> 
> 
> Which is not at all the case with OpenStack, hence i think we should
> remove the prefixes from the Flavors. The only reason i see to keep the
> prefix is if we are going to create some association between the flavor
> prefixes and the type of hardware used or some special characteristics
> provided with for that prefix (high mem, high cpu).

I think the general convention of using a prefix to indicate some class
of flavors is well established and understood, so in general I don't
like the idea of making our defaults not have a prefix.

I'm also not seeing a compelling reason to change to a different prefix.
 It's just the defaults, and I imagine most people configure their own
flavors for a production deployment anyway.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & ESX similar to KVM instantiated VMs?

[Bob Ball]

It's not certain that this will be implemented for the XenAPI driver.

Our view is that the BIOS strings shouldn't be relied upon - the hypervisor can 
clearly set them to anything so it's not really a reliable way to configure the 
application.  Also note that in some scenarios, such as PV guests in Xen 
clouds, you will not have any BIOS to query.  Finally we're not clear on the 
use case here - What's the use case for needing to know whether you VM is 
running under OpenStack or not?

Bob

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 26 November 2013 01:44
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & ESX 
similar to KVM instantiated VMs?

Hi,

In a KVM instantiated VM the following signature is present in the BIOS of the 
VM
The 'Manufacturer ' field in 'System Information' group is set to "OpenStack 
Foundation"



This helps the VM to identify that it is getting used in an OpenStack 
environment.



As far as I know XenServer is planning to set the BIOS Strings in IceHouse 
release.



Is this functionality available in other Hypervisors, especially Hyper-V & ESX?



Thanks,

Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps

[Thomas Goirand]

I'm sorry to restart this topic.

I don't mind if we upgrade to 0.1.8, but then I will need to have
patches for Havana to support version 0.1.8. Otherwise, it's going to be
very difficult on the packaging side: I will need to upload 0.1.8 for
Icehouse, but then it will break everything else (eg: Havana) that is
currently in Sid.

Was there some patches already for that? If so, please point to them so
that I can cherry-pick them, and carry the patches in the Debian
packages (it doesn't have to be backported to the Havana branch, I'm
fine keeping the patches in the packages, if at least they are identified).

Is there a way that I can grep all commits in Gerrit, to see if there
was such patches committed recently?

Cheers,

Thomas Goirand (zigo)

On 10/24/2013 09:37 PM, Morgan Fainberg wrote:
> It seems like adopting 0.1.8 is the right approach. If it doesn't work
> with other projects, we should work to help those projects get updated
> to work with it. 
> 
> --Morgan
> 
> On Thursday, October 24, 2013, Zhi Yan Liu wrote:
> 
> Hi all,
> 
> Adopt 0.1.8 as iso8601 minimum version:
> https://review.openstack.org/#/c/53567/
> 
> zhiyan
> 
> On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews
> > wrote:
> >
> > On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins
> >
> > wrote:
> >>
> >> On 24 October 2013 07:34, Mark Washenberger
> >> > wrote:
> >> > Hi folks!
> >> >
> >> > 1) Adopt 0.1.8 as the minimum version in openstack-requirements.
> >> > 2) Do nothing (i.e. let Glance behavior depend on iso8601 in
> this way,
> >> > and
> >> > just fix the tests so they don't care about these extra formats)
> >> > 3) Make Glance work with the added formats even if 0.1.4 is
> installed.
> >>
> >> I think we should do (1) because both (2) will permit surprising,
> >> nonobvious changes in behaviour and (3) is just nasty engineering.
> >> Alternatively, add a (4) which is (2) with "whinge on startup if
> 0.1.4
> >> is installed" to make identifying this situation easy.
> >
> >
> > I'm in favor of (1), unless there's a reason why 0.1.8 not viable for
> > another project or packager, in which case, I've never heard the term
> > "whinge" before so there should definitely be some of that.
> >
> >>
> >>
> >> The last thing a new / upgraded deployment wants is something like
> >> nova, or a third party API script failing in nonobvious ways with no
> >> breadcrumbs to lead them to 'upgrade iso8601' as an answer.
> >>
> >> -Rob
> >>
> >> --
> >> Robert Collins >
> >> Distinguished Technologist
> >> HP Converged Cloud
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org 
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> >
> > -Dolph
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Russell Bryant]

On 11/26/2013 04:48 AM, Bob Ball wrote:
>> -Original Message-
>> From: Russell Bryant [mailto:rbry...@redhat.com]
>> Sent: 25 November 2013 22:37
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
>> deprecation plan
>>
>> On 11/25/2013 05:19 PM, Matt Riedemann wrote:
>>> I'll play devil's advocate here and ask this question before someone
>>> else does.  I'm assuming that the requirement of a 'full' tempest run
>>> means running this [1].  Is that correct?  It's just confusing sometimes
>>> because there are other things in Tempest that aren't in the 'full' run,
>>> like stress tests.
>>>
>>> [1] https://github.com/openstack/tempest/blob/master/tox.ini#L33
>>>
>>
>> I think the short answer is, "whatever we're running against all Nova
>> changes in the gate".
> 
> Can we strip this down a bit?  I don't see any benefit in running tests that 
> verify Swift's behaviour other than where it interacts with Nova.
> 
> I hope we can safely say that we should run against all "gating" tests which 
> require Nova?  Currently we run quite a number of tests in the gate that 
> succeed even when Nova is not running as the gate isn't just for Nova but for 
> all projects.
> 
> It would be trivial to kill Nova, run the full tempest and only enable those 
> jobs for a new flavour which we must run.
> 
> Thoughts?

Would you like to come up with a more detailed proposal?  What tests
would you cut, and how much time does it save?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unwedging the gate

[Sean Dague]

On 11/25/2013 09:14 PM, James E. Blair wrote:
> Joe Gordon  writes:
> 
>> On Sun, Nov 24, 2013 at 10:48 PM, Robert Collins
>> wrote:
>>
>>> On 25 November 2013 19:25, Joe Gordon  wrote:



 On Sun, Nov 24, 2013 at 9:58 PM, Robert Collins <
>>> robe...@robertcollins.net>
 wrote:
>
> I have a proposal - I think we should mark all recheck bugs critical,
> and the respective project PTLs should actively shop around amongst
> their contributors to get them fixed before other work: we should
> drive the known set of nondeterministic issues down to 0 and keep it
> there.



 Yes! In fact we are already working towards that. See

>>> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020048.html
>>>
>>> Indeed I saw that thread - I think I'm proposing something slightly
>>> different, or perhaps 'gate blocking' needs clearing up. Which is -
>>> that once we have sufficient evidence to believe there is a
>>> nondeterministic bug in trunk, whether or not the gate is obviously
>>> suffering, we should consider it critical immediately. I don't think
>>> we need 24h action on such bugs at that stage - gate blocking zomg
>>> issues obviously do though!
>>>
>>
>> I see what your saying. That sounds like a good idea, all gate bugs are
>> critical, but only zomg gate is bad gets 24h action.
> 
> This is fundamentally the same idea -- we're talking about degrees.  And
> I'm afraid that the difference in degree between a "gate bug" and a
> "zomg gate bug" has more to do with the number of changes in the gate
> queue than the bug itself.
> 
> So yeah, my proposal is that nondeterministic bugs that show up in the
> gate should be marked critical, and the expectation is that PTLs should
> help get people assigned to them.
> 
> Nondeterministic bugs that show up in the gate with no one working on
> them are just waiting for a big queue or another nondetermistic bug to
> come along and halt everything.

Or a subtle timing change in a cloud, or one more test which reorders
the order testr runs in, or... lots of things.

Honestly, since elastic recheck came onto the scene at the end of Havana
we've gained a lot of insight on the problems of these races, how they
are really lots of little races, not a few big ones, and how the odds
end up against us with a long gate because a 40 deep queue, with a reset
happening every 10 changes (all for instance), means we actually have
end up with 40 + 30 + 20 + 10 change events in the gate, so 2.5x the
linear path, which makes this thing go geometric pretty quickly.

So I think we need to treat any race as potentially the one that's going
to kill us. Because, experience has shown we never really know which one
will put us over the edge. And the cyclic nature of these gate halts
demonstrates that a lot of people don't look at the issues until it
actually prevents them from merging code.

There is also another issue, we've turned off some tests in tempest
because they find races at a regular enough rate that they, all by
themselves, do a pretty good job of wedging the gate, and there were
times when we needed to just get things under control (because otherwise
they prevented fixes for some of the other races from getting in).

We really need to declare some times where we're going to flip these on
intentionally, and that people are signing up to go after the fallout.
The math on the race conditions shows that we can't actually keep them
from landing, but once they do, and we see them, if we can amplify their
likelyhood we can keep them from coming back.

It's important to remember that all these races we find with the gate,
can and will be tripped over by real people on their OpenStack
deployments. Not all people, not all deployments, but I'm sure these
issues are actually seen out there. Also these will give us a 2 day long
merge queue on Icehouse-3. Not might, will. So if people want the
ability to get their code merged during feature freeze, the time to act
is now.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Sean Dague]

On 11/25/2013 10:24 PM, Dolph Mathews wrote:
> 
> On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
> mailto:robe...@robertcollins.net>> wrote:
> 
> This has been mentioned in other threads, but I thought I'd call it
> out and make it an explicit topic.
> 
> We have over 100 recheck bugs open on
> http://status.openstack.org/rechecks/ - there is quite a bit of
> variation in how frequently they are seen :(. In a way thats good, but
> stuff that have been open for months and not seen are likely noise (in
> /rechecks). The rest - the ones we see happening are noise in the
> gate.
> 
> The lower we can drive the spurious failure rate, the less repetitive
> analysing a failure will be, and the more obvious new ones will be -
> it forms a virtuous circle.
> 
> However, many of these bugs - a random check of the first 5 listed
> found /none/ that had been triaged - are no prioritised for fixing.
> 
> So my proposal is that we make it part of the base hygiene for a
> project that any recheck bugs being seen (either by elastic-recheck or
> manual inspection) be considered critical and prioritised above
> feature work.
> 
> 
> I agree with the notion here (that fixing transient failures is
> critically high priority work for the community) -- but marking the bug
> as "critical" priority is just a subjective abuse of the priority field.
> A non-critical bug is not necessarily non-critical work. The "critical"
> status should be reserved for issues that are actually non-shippable,
> catastrophically breaking issues.

A race condition in a project which causes it to act with undefined
behavior some statistically significant part of the time in a relatively
small, single node, non highly parallel (at max 4 simultaneous requests)
seems catastrophically breaking to me.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Ladislav Smola]

Hello,

seems too big to do the inline comments, so just a few notes here:

If we truly want to have Templates portable, it would mean to have the 
'metadata' somehow standardised, right?
Otherwise if every UI will add their own metadata, then I hardly see the 
templates as portable. I think first step would be then to delete
the metadata and add your own, unless you are fine to have 80% of the 
template some metadata you don't use. That also won't

help the readability. What will help a readability are the verbose comments.

I am not really sure how long it can take to add new specialized tags, 
that are used only in Horizon and are well documented. I think showing
this, should get the patch merged very quickly. That seems to me like a 
portable solution.


IMO for the template catalogue we would probably need a new service, 
something like Glance, so that's probably a more distant future.


For the use-cases:
---

ad 1)
Something more general next to Description may be more useful, like 
keywords, packages or components.

Example:

Description...
Keywords: wordpress, mysql...

Or you could parse it from e.g. packages (though that is not always 
used, so being able to write it explicitly might be handy)


ad 2)
Maybe adding something like 'author' tag may be a good idea, though you 
can find all the history in git repo,
given you use https://github.com/openstack/heat-templates . If you have 
different repo, adding something like

Origin: https://github.com/openstack/heat-templates maybe?

ad 3)
So having a fix and documented schema seems to be a good way to be 
portable, at least to me. I am not
against UI only tags inside the template, that are really useful for 
everybody. We will find out by collectively

reviewing that, which usually brings some easier solution.

Or you don't think, it will get too wild to have some 'metadata' section 
completely ignored by Heat? Seems
to me like there will be a lot of cases, when people won't push their 
template to upstream, because of the
metadata they have added to their templates, that nobody else will ever 
use. Is somebody else concerned

about this?

That's my 2 cents.

Kind regards,
Ladislav


On 11/26/2013 07:32 AM, Keith Bray wrote:
Thanks Steve.  I appreciate your input. I have added the use cases for 
all to review:

https://wiki.openstack.org/wiki/Heat/StackMetadata

What are next steps to drive this to resolution?

Kind regards,
-Keith

From: Steve Baker mailto:sba...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" >

Date: Monday, November 25, 2013 11:47 PM
To: "openstack-dev@lists.openstack.org 
" 
>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related 
requirements & roadmap


On 11/26/2013 03:26 PM, Keith Bray wrote:

On 11/25/13 5:46 PM, "Clint Byrum"  wrote:


Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:

Hi Steve,

As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you and the rest of the
Openstack community that the primary purpose of pushing these
requirements
out to the community is to help improve the User Experience for Heat for
everyone. Every major UI feature that I have implemented for Heat has
been
included in Horizon, see the Heat Topology, and these requirements
should
improve the value of Heat, regardless of the UI.


Stack/template metadata
We have a fundamental need to have the ability to reference some
additional metadata about a template that Heat does not care about.
There
are many possible use cases for this need but the primary point is that
we
need a place in the template where we can iterate on the schema of the
metadata without going through a lengthy design review. As far as I
know,
we are the only team attempting to actually productize Heat at the
moment
and this means that we are encountering requirements and requests that
do
not affect Heat directly but simply require Heat to allow a little
wiggle
room to flesh out a great user experience.


Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.

Clint, can you be more specific on what is not clear about the use case?
What I am seeing is that the use case of meta data is not what is being
contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs.  The Blueprint for
in-template metadata was already approved for Icehouse, but now that work
has been delivered on the implementation of that blueprint, the blueprint
itself is being contested:
https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata
I'd like to propose that th

Re: [openstack-dev] [Ceilometer][qa] Tenant isolation - IntegrityError exception

[Eoghan Glynn]

Hi Nejc,

Apologies for the delay in responding, I'm just getting to grips with
Tempest myself.

So the problem here is nothing to do with whether the tenant
exists in keystone, in fact creating an alarm with a completely
fictitious project_id will work just fine in general.

Rather it appears to be an artifact of how the alarm creation
logic was added to the sqlalchemy driver in such a way as to rely
on sqlalchemy session merge to create the corresponding entries
in the project & user tables[1].

Then subsequently a *later* migration[2] was added to assert
foreign key constraints for those project & user IDs.

I'm no sqlalchemy expert, but I don't think session merge is a
reliable way to ensure creation of the corresponding rows in the
related tables in order to satisfy the foreign key constraints.

I've filed a bug[3] and will propose a patch to explicitly create
the project & user IDs. This should address the intermittent
failure you're seeing.

Cheers,
Eoghan

[1] https://github.com/openstack/ceilometer/commit/2c84007b
[2] https://github.com/openstack/ceilometer/commit/fa6f9807
[3] https://bugs.launchpad.net/ceilometer/+bug/1255107

- Original Message -
> Hey,
> 
> still trying to get https://review.openstack.org/#/c/39237/ through the gate
> :)
> 
> As per David Kranz's request, I am now handling client isolation, but about
> 50% of the time the tests fail because of an integrity error, see
> http://logs.openstack.org/37/39237/13/check/check-tempest-devstack-vm-full/53c0fc1/console.html.gz
> .
> 
> The tenant does get created in keystone and the ids do match up, so I have no
> clue what is causing this. Any ideas?
> 
> Cheers,
> Nejc
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Javascript development improvement

[Maxime Vidori]

I made a little POC about Nodejs integration with its task runner Grunt 
https://review.openstack.org/58525

It is easy to configure and override, we have more flexibility with this 
solution.

Running Selenium which will run Firefox which will launch an html page with js 
embedded seems really overkill. It provides a lot of complexity and we have to 
manipulate the file launched by Firefox if we want a little modification or 
just test a single file. 
Currently all files are tested together with all the tests without any control. 
Imagine testing the backend this way, launching all the tests just for looking 
at your modifications. No command line support in development implies a lack of 
automatisation, and a lack of automatisation lead to a lose of time. 

In the other hand, grunt allows us to launch tests on a specific file or all 
libraries. We can make specific tasks really fast with a better readability. I 
encourage you to think of the further developments and to think of all the pro 
and cons of these solutions. Just test it and look at the documentation with 
all the plugins (unit testing, less compilation, jshint checking, angular 
testing), this is just configuration and no development, with a great community 
which will allow us to focus on the Horizon development and not wasting times 
on external tools.

Horizon will need more and more development on the client side, currently 
javascript is a mess and we need great tools to improve our work. Developing 
our tools will take time and during this time developers will continue 
developing with no tools to automate or check their work.

Maxime

- Original Message -
From: "Imre Farkas" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, November 26, 2013 1:42:26 PM
Subject: Re: [openstack-dev] [horizon] Javascript development improvement

On 11/22/2013 06:13 PM, Julie Pichon wrote:
> "Imre Farkas"  wrote:
>> On 11/22/2013 02:49 PM, Maxime Vidori wrote:
 It seems a bit crazy to me to introduce NodeJS as a dependency just for
 the sake of an easy way to run jslint. There are other options
 available that run without NodeJS as a dependency.
>>>
>>> Sadly, the only solutions which try to implement jslint in pure python are
>>> in alpha or abandoned. If you have a python library which has the same
>>> quality as jslint (which is written by Douglas Crockford himself), I will
>>> be glad to take a look at it.
>>
>> There's a jslint fork called jshint which is able to run in the browser
>> without any node.js dependency.
>>
>> I created a POC patch [1] long time ago to demonstrate its capabilities.
>> It's integrated with qunit and runs automatically with the horizon test
>> suite.
>
> Thanks Imre, this is interesting. Would you mind restoring the patch? If
> you don't have time to work on it please indicate so (I don't think it's
> possible to pick up a patch if the status is 'Abandoned') and someone else
> can look into the test failures.

Julie, Matthias,
I restored the patch, rebased, fixed the tests, added the test files as 
Radomir suggested and removed the .jshintrc file.

The original patch was WIP and I left the failing tests intentionally, 
so that it was easier to compare the two solutions (node.js vs pure 
qunit). But as I wrote, it's cleaned up by now and only contains the latter.

Imre

>
>> The patch also contains a .jshintrc file for the node.js package but you
>> can remove it since it's not used by the qunit+jshint test at all.
>
> Sounds good.
>
> Julie
>
>> Imre
>>
>> [1] https://review.openstack.org/#/c/41087/
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Bob Ball]

> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 26 November 2013 13:56
> To: openstack-dev@lists.openstack.org
> Cc: Sean Dague
> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
> deprecation plan
> 
> On 11/26/2013 04:48 AM, Bob Ball wrote:
> >
> > I hope we can safely say that we should run against all "gating" tests which
> require Nova?  Currently we run quite a number of tests in the gate that
> succeed even when Nova is not running as the gate isn't just for Nova but
> for all projects.
> 
> Would you like to come up with a more detailed proposal?  What tests
> would you cut, and how much time does it save?

I don't have a detailed proposal yet - but it's very possible that we'll want 
one in the coming weeks. 

In terms of the time saved, I noticed that a tempest smoke run with Nova absent 
took 400 seconds on one of my machines (a particularly slow one) - so I imagine 
that would translate to maybe a 300 second / 5 minute reduction in overall 
time.  Total smoke took approximately 800 seconds on the same machine.

If the approach could be acceptable then yes, I'm happy to come up with a 
detailed set of tests that I would propose cutting.

My primary hesitation with the approach is it would need Tempest reviewers to 
be aware of this extra type of test, and flag up if a test is added to the full 
tempest suite which should also be in the nova tempest suite.

Bob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Russell Bryant]

On 11/26/2013 09:38 AM, Bob Ball wrote:
>> -Original Message-
>> From: Russell Bryant [mailto:rbry...@redhat.com]
>> Sent: 26 November 2013 13:56
>> To: openstack-dev@lists.openstack.org
>> Cc: Sean Dague
>> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
>> deprecation plan
>>
>> On 11/26/2013 04:48 AM, Bob Ball wrote:
>>>
>>> I hope we can safely say that we should run against all "gating" tests which
>> require Nova?  Currently we run quite a number of tests in the gate that
>> succeed even when Nova is not running as the gate isn't just for Nova but
>> for all projects.
>>
>> Would you like to come up with a more detailed proposal?  What tests
>> would you cut, and how much time does it save?
> 
> I don't have a detailed proposal yet - but it's very possible that we'll want 
> one in the coming weeks. 
> 
> In terms of the time saved, I noticed that a tempest smoke run with Nova 
> absent took 400 seconds on one of my machines (a particularly slow one) - so 
> I imagine that would translate to maybe a 300 second / 5 minute reduction in 
> overall time.  Total smoke took approximately 800 seconds on the same machine.

I don't think the smoke tests are really relevant here.  That's not
related to Nova vs non-Nova tests, right?

> If the approach could be acceptable then yes, I'm happy to come up with a 
> detailed set of tests that I would propose cutting.
> 
> My primary hesitation with the approach is it would need Tempest reviewers to 
> be aware of this extra type of test, and flag up if a test is added to the 
> full tempest suite which should also be in the nova tempest suite.

Right now I don't think it's acceptable.  I was suggesting a more
detailed proposal to help convince me.  :-)

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Adding notifications to Horizon

[Florent Flament]

Thanks for your feedback. 

Sandy, thank you for the link. I agree that the .start/.end 
notification pattern that you propose seems to be the most appropriate 
to monitor actions launched through the Horizon dashboard. 

In the case of .start/.end notifications, the decorator should do the 
job and has the advantage of being less intrusive than the function 
call. Specific notifications may then be sent through ad-hoc 
functions. 

Lance, I agree with you that generic notification patterns should be 
moved to Oslo-incubator. While Keystone's `notifications.py` module 
implements the CrUD pattern, I believe that the .start/.end pattern 
makes more sense in the case of Horizon. 

I'll try and propose a generic .start/.end pattern implementation to 
the Oslo-incubator, that will be based on Keystone's decorator 
implementation. 

Regards, 
Florent Flament 

- Original Message -

From: "Lance D Bragstad"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Monday, November 25, 2013 6:21:55 PM 
Subject: Re: [openstack-dev] Adding notifications to Horizon 



Sandy Walsh  wrote on 11/25/2013 10:30:05 AM: 

> From: Sandy Walsh  
> To: , 
> Date: 11/25/2013 10:34 AM 
> Subject: Re: [openstack-dev] Adding notifications to Horizon 
> 
> +1 on the inline method. It makes it clear when a notification should be 
> emitted and, as you say, handles the exception handling better. 

This might be a good opportunity to add the decorator from Keystone's 
notification module to Oslo-incubator, and recycle some of that code. 

https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L26 

I know some projects may require more information to be sent in the event 
payload: 
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L783 

but a general case (like Keystone) that requires only a UUID of the resource 
and the type of action being created, the current decorator does this pretty 
well. 
https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L66
 

If this is the direction of event notifications in Horizon, it would be nice to 
settle on one implementation. 

> 
> Also, if it makes sense for Horizon, consider bracketing long-running 
> operations in .start/.end pairs. This will help with performance tuning 
> and early error detection. 
> 
> More info on "well behaved notifications" in here: 
> http://www.sandywalsh.com/2013/09/notification-usage-in-openstack-report.html 
> 
> Great to see! 
> 
> -S 
> 
> 
> On 11/25/2013 11:58 AM, Florent Flament wrote: 
> > Hi, 
> > 
> > I am interested in adding AMQP notifications to the Horizon dashboard, 
> > as described in the following blueprint: 
> > https://blueprints.launchpad.net/horizon/+spec/horizon-notifications 
> > 
> > There are currently several implementations in Openstack. While 
> > Nova and Cinder define `notify_about_*` methods that are called 
> > whenever a notification has to be sent, Keystone uses decorators, 
> > which send appropriate notifications when decorated methods are 
> > called. 
> > 
> > I fed the blueprint's whiteboard with an implementation proposal, 
> > based on Nova and Cinder implementation. I would be interested in 
> > having your opinion about which method would fit best, and whether 
> > these notifications make sense at all. 
> > 
> > Cheers, 
> > Florent Flament 
> > 
> > ___ 
> > OpenStack-dev mailing list 
> > OpenStack-dev@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> ___ 
> OpenStack-dev mailing list 
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 



Best Regards, 

Lance Bragstad 

___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic][Ceilometer] get IPMI data for ceilometer

[Gordon Chung]

> 2. Not sure if our Ceilometer only accept the signed-message, if it is 
case, how Ironic get the message trust for Ceilometer, and send the valid 
message which can be accepted by Ceilometer Collector?

> I'm not sure it's appropriate for ironic to be sending messages using 
ceilometer's sample format. We receive data from the other projects using 
the more generic notification system, and that seems like the right tool 
to use here, too. Unless the other ceilometer devs disagree?

agreed, depending on your target milestone i'd suggest keeping an eye on 
this bp as well: 
https://blueprints.launchpad.net/oslo/+spec/notification-structured 

cheers,
gordon chung

openstack, ibm software standards
email: chungg [at] ca.ibm.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Steven Hardy]

On Tue, Nov 26, 2013 at 03:04:12PM +0100, Ladislav Smola wrote:
> Hello,
> 
> seems too big to do the inline comments, so just a few notes here:
> 
> If we truly want to have Templates portable, it would mean to have
> the 'metadata' somehow standardised, right?
> Otherwise if every UI will add their own metadata, then I hardly see
> the templates as portable. I think first step would be then to
> delete
> the metadata and add your own, unless you are fine to have 80% of
> the template some metadata you don't use. That also won't
> help the readability. What will help a readability are the verbose comments.

I completely agree, and allowing free-form metadata will invariably tempt
some folks to implement other provider specific stuff besides the UI in the
metadata block, which is obviously really bad for cross-provider
template portability.

> I am not really sure how long it can take to add new specialized
> tags, that are used only in Horizon and are well documented. I think
> showing
> this, should get the patch merged very quickly. That seems to me
> like a portable solution.

Yes - I'm not opposed to having metadata in the template which is useful to
users, I'm opposed to having a provider-specific magic-metadata block.

> IMO for the template catalogue we would probably need a new service,
> something like Glance, so that's probably a more distant future.
> 
> For the use-cases:
> ---
> 
> ad 1)
> Something more general next to Description may be more useful, like
> keywords, packages or components.
> Example:
> 
> Description...
> Keywords: wordpress, mysql...

+1, I was thinking "tags", but keywords works too and is possibly clearer.

> ad 2)
> Maybe adding something like 'author' tag may be a good idea, though
> you can find all the history in git repo,
> given you use https://github.com/openstack/heat-templates . If you
> have different repo, adding something like
> Origin: https://github.com/openstack/heat-templates maybe?

Yep, adding an optional "author" and "creation_date" would probably be OK,
although it's a slippery slope towards duplicating all the info already
available in a revision control system.

As you say, all the info is in git (which is what I've been arguing since
we started discussing this in HK)

If we added a keyword which could contain a string related to the exact
template version, would that solve this use-case?

It could be "origin", "source", whatever, but you could then specify any
identifier you want, a URL containing the git SHA would probably be a good
plan, e.g:

https://raw.github.com/openstack/heat-templates/623ee7fa04492772eeae1fa5559802eabd11558e/hot/F18/WordPress_Native.yaml

This then tells you much more than some static in-template metadata can:
- Where the template came from
- What version it is
- All the history related to modifications and who wrote it etc.

More stuff like who to wake up when it breaks could easily be added as git
notes, and you gain the capability to expose different data to
users/operators/admins without having to put it all in the template (the
unique URL could be visible to users, but not necessarily the git repo with
all the data if a provider wants to publish templates but not the repo)

> ad 3)
> So having a fix and documented schema seems to be a good way to be
> portable, at least to me. I am not
> against UI only tags inside the template, that are really useful for
> everybody. We will find out by collectively
> reviewing that, which usually brings some easier solution.
> 
> Or you don't think, it will get too wild to have some 'metadata'
> section completely ignored by Heat? Seems
> to me like there will be a lot of cases, when people won't push
> their template to upstream, because of the
> metadata they have added to their templates, that nobody else will
> ever use. Is somebody else concerned
> about this?

Yes, you've summarised my own concerns pretty well there.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & ESX similar to KVM instantiated VMs?

[Vijay Venkatachalam]

It is basically used to tailor the boot sequence if the VM gets booted in 
OpenStack. For ex. it could do the following


1.   Get IP through DHCP if booted in OpenStack

2.   Read config drive or contact metadata service and init the system if 
booted in OpenStack


Thanks,
Vijay V.

From: Bob Ball [mailto:bob.b...@citrix.com]
Sent: Tuesday, November 26, 2013 7:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & 
ESX similar to KVM instantiated VMs?

It's not certain that this will be implemented for the XenAPI driver.

Our view is that the BIOS strings shouldn't be relied upon - the hypervisor can 
clearly set them to anything so it's not really a reliable way to configure the 
application.  Also note that in some scenarios, such as PV guests in Xen 
clouds, you will not have any BIOS to query.  Finally we're not clear on the 
use case here - What's the use case for needing to know whether you VM is 
running under OpenStack or not?

Bob

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 26 November 2013 01:44
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & ESX 
similar to KVM instantiated VMs?

Hi,

In a KVM instantiated VM the following signature is present in the BIOS of the 
VM
The 'Manufacturer ' field in 'System Information' group is set to "OpenStack 
Foundation"



This helps the VM to identify that it is getting used in an OpenStack 
environment.



As far as I know XenServer is planning to set the BIOS Strings in IceHouse 
release.



Is this functionality available in other Hypervisors, especially Hyper-V & ESX?



Thanks,

Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

[Evgeny Fedoruk]

Hi,
I've updated the wiki page
Please see and comment
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL

Thanks,
Evg

-Original Message-
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] 
Sent: Wednesday, November 20, 2013 4:17 PM
To: Samuel Bercovici; OpenStack Development Mailing List (not for usage 
questions); stephen.g...@guardian.co.uk
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

Yes. The following can be added

1. Certificate Chain as you already observed 2. Backend certificates for trust, 
basically CA certs.
  These certificates will be used by loadbalancer to validate the 
certificate presented by the backend services.

Thanks,
Vijay V.


> -Original Message-
> From: Samuel Bercovici [mailto:samu...@radware.com]
> Sent: Wednesday, November 20, 2013 5:40 PM
> To: OpenStack Development Mailing List (not for usage questions); 
> stephen.g...@guardian.co.uk; Vijay Venkatachalam
> Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
> 
> HI,
> 
> Besides a forward looking model do you see other differences?
> 
> -Sam.
> 
> -Original Message-
> From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
> Sent: Wednesday, November 20, 2013 1:22 PM
> To: stephen.g...@guardian.co.uk; OpenStack Development Mailing List 
> (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
> 
> 
> 
> > -Original Message-
> > From: Stephen Gran [mailto:stephen.g...@guardian.co.uk]
> > Sent: Wednesday, November 20, 2013 3:01 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination 
> > write-up
> >
> > Hi,
> >
> > On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote:
> > > Hi,
> > >
> > >
> > >
> > > Evgeny has outlined the wiki for the proposed change at:
> > > https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line 
> > > with what was discussed during the summit.
> > >
> > > The
> > >
> >
> https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
> > YTvMkMJ_inbo/edit discuss in addition Certificate Chains.
> > >
> > >
> > >
> > > What would be the benefit of having a certificate that must be 
> > > connected to VIP vs. embedding it in the VIP?
> >
> > You could reuse the same certificate for multiple loadbalancer VIPs.
> > This is a fairly common pattern - we have a dev wildcard cert that 
> > is
> > self- signed, and is used for lots of VIPs.
> >
> If certificates can be totally independent and can be reused, it will 
> be awesome.
> But even otherwise, certificate connected to VIP is just better 
> modeling and provides an easier migration path towards an independent 
> certificate resource.
> 
> > > When we get a system that can store certificates (ex: Barbican), 
> > > we will add support to it in the LBaaS model.
> >
> > It probably doesn't need anything that complicated, does it?
> >
> > Cheers,
> > --
> > Stephen Gran
> > Senior Systems Integrator - The Guardian
> >
> > Please consider the environment before printing this email.
> > --
> > Visit theguardian.com
> >
> > On your mobile, download the Guardian iPhone app 
> > theguardian.com/iphone and our iPad edition theguardian.com/iPad 
> > Save up to 33% by subscribing to the Guardian and Observer - choose 
> > the papers you want and get full digital access.
> > Visit subscribe.theguardian.com
> >
> > This e-mail and all attachments are confidential and may also be 
> > privileged. If you are not the named recipient, please notify the 
> > sender and delete the e- mail and all attachments immediately.
> > Do not disclose the contents to another person. You may not use the 
> > information for any purpose, or store, or copy, it in any way.
> >
> > Guardian News & Media Limited is not liable for any computer viruses 
> > or other material transmitted with or as part of this e-mail. You 
> > should employ virus checking software.
> >
> > Guardian News & Media Limited
> >
> > A member of Guardian Media Group plc Registered Office PO Box 68164 
> > Kings Place
> > 90 York Way
> > London
> > N1P 2AP
> >
> > Registered in England Number 908396
> >
> > 
> > --
> > 
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev maili

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Sean Dague]

On 11/26/2013 09:56 AM, Russell Bryant wrote:
> On 11/26/2013 09:38 AM, Bob Ball wrote:
>>> -Original Message-
>>> From: Russell Bryant [mailto:rbry...@redhat.com]
>>> Sent: 26 November 2013 13:56
>>> To: openstack-dev@lists.openstack.org
>>> Cc: Sean Dague
>>> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
>>> deprecation plan
>>>
>>> On 11/26/2013 04:48 AM, Bob Ball wrote:

 I hope we can safely say that we should run against all "gating" tests 
 which
>>> require Nova?  Currently we run quite a number of tests in the gate that
>>> succeed even when Nova is not running as the gate isn't just for Nova but
>>> for all projects.
>>>
>>> Would you like to come up with a more detailed proposal?  What tests
>>> would you cut, and how much time does it save?
>>
>> I don't have a detailed proposal yet - but it's very possible that we'll 
>> want one in the coming weeks. 
>>
>> In terms of the time saved, I noticed that a tempest smoke run with Nova 
>> absent took 400 seconds on one of my machines (a particularly slow one) - so 
>> I imagine that would translate to maybe a 300 second / 5 minute reduction in 
>> overall time.  Total smoke took approximately 800 seconds on the same 
>> machine.
> 
> I don't think the smoke tests are really relevant here.  That's not
> related to Nova vs non-Nova tests, right?
> 
>> If the approach could be acceptable then yes, I'm happy to come up with a 
>> detailed set of tests that I would propose cutting.
>>
>> My primary hesitation with the approach is it would need Tempest reviewers 
>> to be aware of this extra type of test, and flag up if a test is added to 
>> the full tempest suite which should also be in the nova tempest suite.
> 
> Right now I don't think it's acceptable.  I was suggesting a more
> detailed proposal to help convince me.  :-)

So we already have the beginnings of service tags in Tempest, that would
let you slice exactly like this. I don't think the infrastructure is
fully complete yet, but the idea being that you could run the subset of
tests that interact with "compute" or "networking" in any real way.

Realize... that's not going to drop that many tests for something like
compute, it's touched a lot.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tempest] Drop python 2.6 support

[Giulio Fidente]

On 11/25/2013 09:37 PM, Matt Riedemann wrote:

On Monday, November 25, 2013 7:35:51 AM, Zhi Kun Liu wrote:

Does that mean Tempest could not run on python 2.6 in the future?


Well so if you're running a single-node setup of OpenStack on a VM on
top of RHEL 6 and running Tempest from there, yeah, this is an
inconvenience, but it's a pretty simple fix, right?  I just run my
OpenStack RHEL 6 VM and have an Ubuntu 12.04 or Fedora 19 or whatever
distro-that-supports-py27 I want running Tempest against it.  Am I
missing something?

FWIW, trying to keep up with the changes in Tempest when you're running
on python 2.6 is no fun, especially with how tests are skipped
(skipException causes a test failure if you don't have a special
environment variable set).  Plus you don't get parallel execution of the
tests.

So I agree with the approach even though it's going to hurt me in the
short-term.


I'd second this, the benefits are worth it!

Plus, with RHEL you can use "software collections" (1) which allow you 
to install multiple versions of say, python (including 27 and 33), using 
yum (or scl) so you just have to launch tempest with something like:


$ scl enable python27 ./run_tests.sh

1. http://red.ht/1aRdx32
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: giulivo

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Core pinning

[Roman Verchikov]

Tuomas,

> I haven't but I will write a blueprint for the core pinning part.
Can’t wait to see it!

> Are you using extra specs for carrying cpuset attributes in your 
> implementation?
Yes, exactly. 

Although we're using slightly different syntax to update flavor, for example:
$ nova flavor-key set  set vcpupin:0=1-5,12-17
In here ‘0’ is vCPU, and '1-5,12-17' - pCPUs. Basically this command results in 
the following libvirt xml:

   


We’re also using the ‘placement’ attribute of  set to ‘static’:
$ nova flavor-key  set vcpu:placement=static
Which results in the following libvirt xml:
…

Otherwise, the functionality and implementation seem to be identical.

[offtopic] 
Apologies for delayed answer, for some reason I thought your email would arrive 
to my personal mailbox 
[/offtopic]

-Roman

On Nov 19, 2013, at 14:35, Tuomas Paappanen  wrote:

> Hi Roman,
> 
> I haven't but I will write a blueprint for the core pinning part.
> I considered vcpu element usage as well but in that case you can not set e.g. 
> vcpu-0 to run on pcpu-0. Vcpus and emulator are sharing all pcpus defined in 
> cpuset so I decided to use cputune element.
> 
> Are you using extra specs for carrying cpuset attributes in your 
> implementation?
> 
> Br,Tuomas
> 
> On 18.11.2013 17:14, Roman Verchikov wrote:
>> Tuomas,
>> 
>> Have you published your code/blueprints anywhere? Looks like we’re working 
>> on the same stuff. I have implemented almost the same feature set (haven’t 
>> published anything yet because of this thread), except for the scheduler 
>> part. The main goal is to be able to pin VCPUs in NUMA environment.
>> 
>> Have you considered adding placement and cpuset attributes to  
>> element? For example:
>> 
>> 
>> Thanks,
>> Roman
>> 
>> On Nov 13, 2013, at 14:46, Tuomas Paappanen  
>> wrote:
>> 
>>> Hi all,
>>> 
>>> I would like to hear your thoughts about core pinning in Openstack. 
>>> Currently nova(with qemu-kvm) supports usage of cpu set of PCPUs what can 
>>> be used by instances. I didn't find blueprint, but I think this feature is 
>>> for isolate cpus used by host from cpus used by instances(VCPUs).
>>> 
>>> But, from performance point of view it is better to exclusively dedicate 
>>> PCPUs for VCPUs and emulator. In some cases you may want to guarantee that 
>>> only one instance(and its VCPUs) is using certain PCPUs.  By using core 
>>> pinning you can optimize instance performance based on e.g. cache sharing, 
>>> NUMA topology, interrupt handling, pci pass through(SR-IOV) in multi socket 
>>> hosts etc.
>>> 
>>> We have already implemented feature like this(PoC with limitations) to Nova 
>>> Grizzly version and would like to hear your opinion about it.
>>> 
>>> The current implementation consists of three main parts:
>>> - Definition of pcpu-vcpu maps for instances and instance spawning
>>> - (optional) Compute resource and capability advertising including free 
>>> pcpus and NUMA topology.
>>> - (optional) Scheduling based on free cpus and NUMA topology.
>>> 
>>> The implementation is quite simple:
>>> 
>>> (additional/optional parts)
>>> Nova-computes are advertising free pcpus and NUMA topology in same manner 
>>> than host capabilities. Instances are scheduled based on this information.
>>> 
>>> (core pinning)
>>> admin can set PCPUs for VCPUs and for emulator process, or select NUMA cell 
>>> for instance vcpus, by adding key:value pairs to flavor's extra specs.
>>> 
>>> EXAMPLE:
>>> instance has 4 vcpus
>>> :
>>> vcpus:1,2,3,4 --> vcpu0 pinned to pcpu1, vcpu1 pinned to pcpu2...
>>> emulator:5 --> emulator pinned to pcpu5
>>> or
>>> numacell:0 --> all vcpus are pinned to pcpus in numa cell 0.
>>> 
>>> In nova-compute, core pinning information is read from extra specs and 
>>> added to domain xml same way as cpu quota values(cputune).
>>> 
>>> 
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>> 
>>> What do you think? Implementation alternatives? Is this worth of blueprint? 
>>> All related comments are welcome!
>>> 
>>> Regards,
>>> Tuomas
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Dolph Mathews]

On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez wrote:

> Dolph Mathews wrote:
> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
> > mailto:robe...@robertcollins.net>> wrote:
> >
> > So my proposal is that we make it part of the base hygiene for a
> > project that any recheck bugs being seen (either by elastic-recheck
> or
> > manual inspection) be considered critical and prioritised above
> > feature work.
> >
> > I agree with the notion here (that fixing transient failures is
> > critically high priority work for the community) -- but marking the bug
> > as "critical" priority is just a subjective abuse of the priority field.
> > A non-critical bug is not necessarily non-critical work. The "critical"
> > status should be reserved for issues that are actually non-shippable,
> > catastrophically breaking issues.
>
> It's a classic bugtracking dilemma where the "Importance" field is both
> used to describe bug impact and priority... while they don't always match.
>

++


> That said, the "impact" of those bugs, considering potential development
> activity breakage, *is* quite critical (they all are timebombs which
> will create future gate fails if not handled at top priority).
>

I generally agree, but I don't think it's fair to say that the impact of a
transient is universally a single priority, either. Some transient issues
occur more frequently and therefore have higher impact.


> So I think marking them Critical + tagging them is not that much of an
> abuse, if we start including the gate impact in our bug Impact
> assessments. That said, I'm also fine with High+Tag, as long as it
> triggers the appropriate fast response everywhere.
>

I'm fine with starting them at High, and elevating to Critical as
appropriate.

Is the idea here to automatically apply a tag + priority as a result of
"recheck/reverify bug X" ? (as long as existing priority isn't overwritten!)


>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Matt Riedemann]

On Tuesday, November 26, 2013 10:07:02 AM, Sean Dague wrote:

On 11/26/2013 09:56 AM, Russell Bryant wrote:

On 11/26/2013 09:38 AM, Bob Ball wrote:

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com]
Sent: 26 November 2013 13:56
To: openstack-dev@lists.openstack.org
Cc: Sean Dague
Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
deprecation plan

On 11/26/2013 04:48 AM, Bob Ball wrote:


I hope we can safely say that we should run against all "gating" tests which

require Nova?  Currently we run quite a number of tests in the gate that
succeed even when Nova is not running as the gate isn't just for Nova but
for all projects.

Would you like to come up with a more detailed proposal?  What tests
would you cut, and how much time does it save?


I don't have a detailed proposal yet - but it's very possible that we'll want 
one in the coming weeks.

In terms of the time saved, I noticed that a tempest smoke run with Nova absent 
took 400 seconds on one of my machines (a particularly slow one) - so I imagine 
that would translate to maybe a 300 second / 5 minute reduction in overall 
time.  Total smoke took approximately 800 seconds on the same machine.


I don't think the smoke tests are really relevant here.  That's not
related to Nova vs non-Nova tests, right?


If the approach could be acceptable then yes, I'm happy to come up with a 
detailed set of tests that I would propose cutting.

My primary hesitation with the approach is it would need Tempest reviewers to 
be aware of this extra type of test, and flag up if a test is added to the full 
tempest suite which should also be in the nova tempest suite.


Right now I don't think it's acceptable.  I was suggesting a more
detailed proposal to help convince me.  :-)


So we already have the beginnings of service tags in Tempest, that would
let you slice exactly like this. I don't think the infrastructure is
fully complete yet, but the idea being that you could run the subset of
tests that interact with "compute" or "networking" in any real way.

Realize... that's not going to drop that many tests for something like
compute, it's touched a lot.

-Sean



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Good to know about the service tags, I think I remember being broken at 
some point after those tempest.conf.sample changes. :)


My overall concern, and I think the other guys doing this for virt 
drivers will agree, is trying to scope down the exposure to unrelated 
failures.  For example, if there is a bug in swift breaking the gate, 
it could start breaking the nova virt driver CI as well.  When things 
get bad in the gate, it takes some monstrous effort to rally people 
across the projects to come together to unblock it (like what Joe 
Gordon was doing last week).


I'm running Tempest internally about once per day when we rebase code 
with the community and that's to cover running with the PowerVM driver 
for nova, Storwize driver for cinder, OVS for neutron, with qpid and 
DB2.  We're running almost a full run except for the third party boto 
tests and swift API tests.  The thing is, when something fails, I have 
to figure out if it's environmental (infra), a problem with tempest 
(think instability with neutron in the gate), a configuration issue, or 
a code bug.  That's a lot for one person to have to cover, even a small 
team.  That's why at some points we just have to ignore/exclude tests 
that continuously fail but we can't figure out (think intermittent gate 
breaker bugs that are open for months).  Now multiply this out across 
all the nova virt drivers, the neutron plugins and I'm assuming at some 
point the various glance backends and cinder drivers (haven't heard if 
they are planning on the same types of CI requirements yet).  I think 
either we're going to have a lot of flaky/instable driver CI going on 
so the scores can't be trusted, or we're going to develop a lot of 
people that get really good at infra/QA (which would be a plus in the 
long-run, but maybe not what those teams set out to be).


I don't have any good answers, I'm just trying to raise the issue since 
this is complicated.  I think it's also hard for people that aren't 
forced to invest in infra/QA on a daily basis to understand and 
appreciate the amount of effort it takes just to keep the wheels 
spinning, so I want to keep expectations at a reasonable level.


Don't get me wrong, I absolutely agree with requiring third party CI 
for the various vendor-specific drivers and plugins, that's a 
no-brainer for openstack to scale.  I think it will just be very 
interesting to see the kinds of results coming out of all of these 
disconnected teams come icehouse-3.


--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.or

Re: [openstack-dev] [Keystone][Marconi][Oslo] Discoverable home document for APIs (Was: Re: [Nova][Glance] Support of v1 and v2 glance APIs in Nova)

[Dolph Mathews]

On Tue, Nov 26, 2013 at 2:47 AM, Flavio Percoco  wrote:

> On 25/11/13 16:50 -0600, Dolph Mathews wrote:
>
>>
>> On Mon, Nov 25, 2013 at 2:41 AM, Flavio Percoco 
>> wrote:
>>
>>On 25/11/13 09:28 +1000, Jamie Lennox wrote:
>>
>>So the way we have this in keystone at least is that querying GET /
>>will
>>return all available API versions and querying /v2.0 for example
>> is a
>>similar result with just the v2 endpoint. So you can hard pin a
>> version
>>by using the versioned URL.
>>
>>I spoke to somebody the other day about the discovery process in
>>services. The long term goal should be that the service catalog
>>contains
>>unversioned endpoints and that all clients should do discovery. For
>>keystone the review has been underway for a while now:
>>https://review.openstack.org/#/c/38414/ the basics of this should
>> be
>>able to be moved into OSLO for other projects if required.
>>
>>
>>Did you guys create your own 'home document' language? or did you base
>>it on some existing format? Is it documented somewhere? IIRC, there's
>>a thread where part of this was discussed, it was related to horizon.
>>
>>I'm curious to know what you guys did and if you knew about
>>JSON-Home[0] when you started working on this.
>>
>>
>> It looks like our multiple choice response might predate Nottingham's
>> proposal,
>> but not by much. In keystone, it's been stable since I joined the project,
>> midway through the diablo cycle (summer 2011). I don't know any more
>> history
>> than that, but I've CC'd Jorge Williams, who probably knows.
>>
>> I really like Nottingham's approach of adding relational links from the
>> base
>> endpoint, I've been thinking about doing the same for keystone for quite a
>> while.
>>
>
> As crazy as it sounds, have you guys considered migrating to
> Nottingham's approach?
>
>
It only sounds crazy because I have no idea how to "migrate" an unversioned
endpoint :) Skimming through his proposal, it looks like it might actually
be compatible with ours to include side by side? If so, we could support
both for a couple releases before moving on.

Does this proposal have much traction outside the OpenStack community? (and
how much traction does it have within the community already?)


> We picked this approach because we didn't want to invent it ourselves
> and this happens to have a well defined RFC as well.
>
> If there's something Nottingham's proposal lacks of, I think we could
> provide some feedback and help making it better.
>
>
>
>>We used json-home for Marconi v1 and we'd want the client to work in a
>>'follow your nose' way. Since, I'd prefer OpenStack modules to use the
>>same language for this, I'm curious to know why - if so - you
>>created your own spec, what are the benefits and if it's documented
>>somewhere.
>>
>>
>> Then why didn't Marconi follow the lead of one of the other projects? ;)
>>
>
> LOOOL, I knew you were going to say that. I think I knew about you
> guys having something similar but at some point I most have forgotten
> about it. That being said, the main rationals were:
>
>1) Using something documented and known upstream made more sense
>and it also helps getting more contributions from the community.
>2) We already knew it, which falls back in point 1.
>
>
Hey, you set yourself up! Seriously though, I welcome the innovation.


>
>
>  I completely agree though - standardized version discovery across the
>> ecosystem
>> would be fantastic.
>>
>
> All that being said, I don't think it would be very hard to migrate
> Marconi to something common if we agree that json-home is not good
> enough for OpenStack. Nonetheless, it'd be a shame not to provide
> feedback to Mark Nottingham about it. So far, his approach has been
> good enough for us - but, you know, Marconi is still way too small.
>
> Is keystone's home schema spec documented somewhere?
>

It's actually documented as part of the v2.0 API for keystone, although I
really believe it should be it's own API specification (e.g. Nottingham's
approach):

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v2.0/src/docbkx/wadl/identity-admin.wadl#L185

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v2.0/src/docbkx/xsd/version.xsd#L35

We use the same basic structure to serve the multiple choice response and
versioned endpoints:

  GET /
  GET /v2.0/
  GET /v3/

However, the multiple choice response contains the details for both
versions.


> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/c

[openstack-dev] [Neutron] Rename 'tenant' to 'project' as per Keystone?

[Maru Newby]

Keystone is almost finished replacing the term 'tenant' with 'project' (see 
recent thread 
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html)  
and we might want to think about how and when Neutron makes a similar 
transition.  It's an unlikely priority in the near term given the focus on 
stability, but I wanted to broach the topic for discussion in case people think 
it might be worth attempting later in the cycle.  I've filed a preliminary 
blueprint in any case: 
https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project 


Maru


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Hyper-V meeting cancelled.

[Peter Pouliot]

Hi All,

Key individuals are out on vacation this week.  We will resume next week.

p

Peter J. Pouliot CISSP
Sr. SDET OpenStack
Microsoft
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tempest] Drop python 2.6 support

[Peter Portante]

Giulio, are you speaking for Red Hat here, or is this just your
opinion?  And have you actually tried to doing what you propose?
Regards, -peter

On Tue, Nov 26, 2013 at 11:18 AM, Giulio Fidente  wrote:
> On 11/25/2013 09:37 PM, Matt Riedemann wrote:
>>
>> On Monday, November 25, 2013 7:35:51 AM, Zhi Kun Liu wrote:
>>>
>>> Does that mean Tempest could not run on python 2.6 in the future?
>>
>>
>> Well so if you're running a single-node setup of OpenStack on a VM on
>> top of RHEL 6 and running Tempest from there, yeah, this is an
>> inconvenience, but it's a pretty simple fix, right?  I just run my
>> OpenStack RHEL 6 VM and have an Ubuntu 12.04 or Fedora 19 or whatever
>> distro-that-supports-py27 I want running Tempest against it.  Am I
>> missing something?
>>
>> FWIW, trying to keep up with the changes in Tempest when you're running
>> on python 2.6 is no fun, especially with how tests are skipped
>> (skipException causes a test failure if you don't have a special
>> environment variable set).  Plus you don't get parallel execution of the
>> tests.
>>
>> So I agree with the approach even though it's going to hurt me in the
>> short-term.
>
>
> I'd second this, the benefits are worth it!
>
> Plus, with RHEL you can use "software collections" (1) which allow you to
> install multiple versions of say, python (including 27 and 33), using yum
> (or scl) so you just have to launch tempest with something like:
>
> $ scl enable python27 ./run_tests.sh
>
> 1. http://red.ht/1aRdx32
> --
> Giulio Fidente
> GPG KEY: 08D733BA | IRC: giulivo
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Interested in a mid-Icehouse Glance mini-summit?

[Mark Washenberger]

On Mon, Nov 25, 2013 at 10:47 PM, Boris Pavlovic wrote:

> Mark,
>
>
> Why we are not able to combine this and Nova meetup in the same place in
> the same time?
>
>
The two events are being planned and sponsored separately. Maybe in the
future it will make sense to merge them to ease travel difficulties for
some. But there are likely some tradeoffs to consider.

Thanks for your interest


>
> Best regards,
> Boris Pavlovic
>
>
> On Wed, Nov 20, 2013 at 11:23 PM, Mark Washenberger <
> mark.washenber...@markwash.net> wrote:
>
>>
>>
>>
>> On Thu, Nov 14, 2013 at 1:35 PM, Mark Washenberger <
>> mark.washenber...@markwash.net> wrote:
>>
>>> Hi folks,
>>>
>>> There's been some talk about copying Nova for a mid-cycle meetup to
>>> reorganize around our development priorities in Glance.
>>>
>>> So far, the plan is still tentative, but we're focusing on late January
>>> and the Washington, DC area. If you're interested and think you may be able
>>> to attend, please fill out this survey.
>>>
>>>
>>> https://docs.google.com/forms/d/11DjkNAzVAdtMCPrsLiyjA7ck33jnexmKqlqaCl5olO8/viewform
>>>
>>> <3,
>>> markwash
>>>
>>
>>
>> As a reminder, please fill out the form above if you are interested in a
>> Glance mid-cycle meetup. Depending on interest, this meetup could serve a
>> lot of purposes. For one, it will be an opportunity for Glance developers
>> to meet face to face and hammer out the details for finishing the Icehouse
>> release. For another, it can be a good opportunity to discover and plan
>> longer term features for the product. Finally, we may also have the chance
>> for developers to spend time together hacking or even learn about a few new
>> techniques that may be relevant to future development. But it need not be
>> restricted to current Glance developers--indeed some representation from
>> other projects would be appreciated to help us improve how we serve the
>> overall suite of projects.
>>
>> Thanks for your interest!
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance] Meeting cancelled this week

[Mark Washenberger]

Hi folks,

Our normally scheduled meeting this week will not be held, since it would
coincide with a major U.S. holiday and I'll be busy at that time stuffing
my face with turkey and a wide variety of starches.

We'll pick up where we left off next week during our normal timeslot (which
is at 1400 UTC).

Happy what-have-you!
markwash
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Tempest] Heat template for services

[Nachi Ueno]

Hi Summit, Eugene

We have submitted a Heat template for advanced services.
This is combination of LBaaS, FWaaS and VPN.
This is a also good demo for how to use neutron services.

https://review.openstack.org/#/c/58496/1

It is great if we could get feedback from yours.

FYI, here is existing heat & neutron test.
https://github.com/openstack/tempest/blob/master/tempest/api/orchestration/stacks/test_neutron_resources.py

Best
Nachi

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate broken right now

[James E. Blair]

Chmouel Boudjnah  writes:

> On Tue, Nov 26, 2013 at 9:52 AM, Flavio Percoco  wrote:
>
>> This seems to be the issue you're talking about, is it?
>>
>> http://logs.openstack.org/49/57049/2/gate/gate-swift-
>> python26/c1aedf1/console.html
>>
>
> Thanks for the heads up indeed, I was wondering if there was somebody on
> shift/awake from infra during european hours?

There is not, currently, though we would love to have more people on the
infra-core (and infra-root) teams.  If you know someone, or you
yourself, or your company are interested in contributing in this area,
please get in contact and we can help.  There is a significant time
commitment to working on infra due to the wide range of complex systems,
however, a number of companies are working with these systems internally
and should be able to spare some expertise in contributing to their
upstream development and operation without undue burden.

> This seems to be a pure infrastructure issue with the python26 gate as
> this is happen for all py26 tests.

Monty corrected the problem with the bad Jenkins slave around 14:22 UTC.

In the short term, we plan to start running unit tests on single-use
slaves, just as we do for devstack jobs, which should mean single-node
errors will auto-correct (also, it makes the system more auto-scalable
according to workload).

In the long term we're looking at using non-Jenkins test runners which
should avoid this sort of problem by being significantly less complex.

-Jim

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2013-11-26 03:23:51 -0800:
> Dolph Mathews wrote:
> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
> > mailto:robe...@robertcollins.net>> wrote:
> > 
> > So my proposal is that we make it part of the base hygiene for a
> > project that any recheck bugs being seen (either by elastic-recheck or
> > manual inspection) be considered critical and prioritised above
> > feature work.
> > 
> > I agree with the notion here (that fixing transient failures is
> > critically high priority work for the community) -- but marking the bug
> > as "critical" priority is just a subjective abuse of the priority field.
> > A non-critical bug is not necessarily non-critical work. The "critical"
> > status should be reserved for issues that are actually non-shippable,
> > catastrophically breaking issues.
> 
> It's a classic bugtracking dilemma where the "Importance" field is both
> used to describe bug impact and priority... while they don't always match.
> 

If I'm on the fence between 1 importance or the other, I look at the bug
list of the two importance lists:

For instance, there are all 122 High importance bugs in Nova, and 6
Critical bugs.

If we are comfortable with developers choosing to fix all 122 of the other
High bugs before this bug, then make it High. If not, make it Critical.
Likewise, if we are uncomfortable with this bug being chosen before any
of the 6 Critical bugs, then make it High.

I realize those two choices could make a person uncomfortable and wish for
something in-between like "Hitical" or "Criticigh", but micro-management
is no way to actually get things done and it does only take a few seconds
to reprioritize as we add insight and data over time.

> That said, the "impact" of those bugs, considering potential development
> activity breakage, *is* quite critical (they all are timebombs which
> will create future gate fails if not handled at top priority).
> 
> So I think marking them Critical + tagging them is not that much of an
> abuse, if we start including the gate impact in our bug Impact
> assessments. That said, I'm also fine with High+Tag, as long as it
> triggers the appropriate fast response everywhere.
> 

IMO the tags are a distraction to triage. Critical or High is enough of
a conundrum to resolve. The tags will certainly help guide trackers, and
they should add them, but the person doing triage should mostly focus on
"will the patient die?" type questions.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Zane Bitter]

On 26/11/13 03:26, Keith Bray wrote:



On 11/25/13 5:46 PM, "Clint Byrum"  wrote:


Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:

Hi Steve,

As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you and the rest of the
Openstack community that the primary purpose of pushing these
requirements
out to the community is to help improve the User Experience for Heat for
everyone. Every major UI feature that I have implemented for Heat has
been
included in Horizon, see the Heat Topology, and these requirements
should
improve the value of Heat, regardless of the UI.


Stack/template metadata
We have a fundamental need to have the ability to reference some
additional metadata about a template that Heat does not care about.
There
are many possible use cases for this need but the primary point is that
we
need a place in the template where we can iterate on the schema of the
metadata without going through a lengthy design review. As far as I
know,
we are the only team attempting to actually productize Heat at the
moment
and this means that we are encountering requirements and requests that
do
not affect Heat directly but simply require Heat to allow a little
wiggle
room to flesh out a great user experience.



Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.


Clint, can you be more specific on what is not clear about the use case?


The part where it's used for something. What I'm hearing in this thread 
is "We need this for a template catalog, but we're not going to talk 
about that until later. Trust us, though, we really need it."


That's a problem, because none of this stuff makes sense except in the 
context of the template catalog. What does the template catalog do? Who 
writes the templates in the catalog? Why is the template catalog not 
backed by git? Who can say which parts of the solution belong in the 
template catalog and which in Heat when we don't even know what it's a 
solution to?



What I am seeing is that the use case of meta data is not what is being


I'm contesting it:

https://review.openstack.org/#/c/56703/7/doc/source/template_guide/hot_spec.rst

The problem here isn't that the process wasn't followed, it's that all 
of these things - one-shot outputs, operator-specific structured 
metadata sections in templates, APIs to report versions of randomly 
selected daemons - are fundamentally bad ideas. And they're all bad in 
exactly the same way: they demand that Heat implement something that it 
can only do in a half-baked manner, because it's slightly easier (or 
seems slightly easier) than implementing something in some external tool 
that can work.


It's difficult to escape the conclusion that these features have been 
decided upon behind closed doors with the community excluded, by people 
who are not especially familiar with Heat, with a view to minimising the 
effort required to implement some other (proprietary?) thing and not 
necessarily to coming up with the best implementation. If this is your 
development process then you are Doing Open Source Wrong. At a very 
minimum you need to work about 10x harder to explain all of these design 
decisions - in particular the reasons why the obvious alternatives that 
don't appear to have been considered are insufficient - to the 
community. It's much, much easier, though, to just do your design in the 
open with community involvement.


Take this metadata section idea. (Please!) Let's step back and examine 
the very last decision in the chain - assume for a moment that we accept 
that this metadata needs to be included in the template. There are three 
obvious ways to do that:


 1) Include them as YAML comments
 2) Include them in the body of the template
 3) Include them as a separate YAML document in the same file

How many of those were actually considered? My bet is only #2. It 
doesn't really matter though, because there is not one word of design 
documentation that would help me understand the reasons for rejecting #1 
& #3 (neither of which require any changes to Heat or the template 
format). How can I have confidence that #2 is the correct solution to 
the problem? Especially if I don't agree (I don't)?


The number of options not considered grows (and my confidence in the 
solution shrinks) exponentially as you step all the way back through the 
chain of undocumented decisions to the actual thing that drove this idea.



contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs.  The Blueprint for


I contested that first because without knowing what the feature is even 
for, there's nothing else to contest.



in-template metadata was already approved for Icehouse, but now that wo

Re: [openstack-dev] tenant or project

[Tim Bell]

Can we get a TC policy that 'project' is the standard and that all projects 
using tenant should plan a smooth migration path to project along with the 
timescales for implementation and retirement of tenant ?

Tim

From: Christopher Yeoh [mailto:cbky...@gmail.com] 
Sent: 26 November 2013 12:48
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] tenant or project

On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco  wrote:
On 24/11/13 12:47 -0500, Doug Hellmann wrote:



On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg  wrote:

   In all honesty it doesn't matter which term we go with.  As long as we are
   consistent and define the meaning.  I think we can argue intuitive vs
   non-intuitive in this case unto the ground.  I prefer "project" to tenant,
   but beyond being a bit of an "overloaded" term, I really don't think anyone
   will really notice one way or another as long as everything is using the
   same terminology.  We could call it "grouping-of-openstack-things" if we
   wanted to (though I might have to pull some hair out if we go to that
   terminology).      However, with all that in mind, we have made the choice 
to move toward
   project (horizon, keystone, OSC, keystoneclient) and have some momentum
   behind that push (plus newer projects already use the project
   nomenclature).   Making a change back to tenant might prove a worse UX than
   moving everything else in line (nova I think is the one real major hurdle
   to get converted over, and deprecation of keystone v2 API). 

FWIW, ceilometer also uses project in our API (although some of our docs use
the terms interchangeably).

And, FWIW, Marconi uses project as well.

Well project seems to be the way everyone is heading long term.  So we'll do 
this for the Nova
V3 API.  As others have mentioned, I think the most important this is that we 
all end up using
the same terminology (though with the long life of APIs we're stuck with the 
both for a few years
at least).

Chris


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Russell Bryant]

Greetings,

I would like to propose that we re-add Dan Prince to the nova-core
review team.

Dan Prince has been involved with Nova since early in OpenStack's
history (Bexar timeframe).  He was a member of the nova-core review team
from May 2011 to June 2013.  He has since picked back up with nova
reviews [1].  We always say that when people leave nova-core, we would
love to have them back if they are able to commit the time in the
future.  I think this is a good example of that.

Please respond with +1s or any concerns.

Thanks,

[1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Michael Still]

+1

On Wed, Nov 27, 2013 at 6:32 AM, Russell Bryant  wrote:
> Greetings,
>
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
>
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe).  He was a member of the nova-core review team
> from May 2011 to June 2013.  He has since picked back up with nova
> reviews [1].  We always say that when people leave nova-core, we would
> love to have them back if they are able to commit the time in the
> future.  I think this is a good example of that.
>
> Please respond with +1s or any concerns.
>
> Thanks,
>
> [1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Interested in a mid-Icehouse Glance mini-summit?

[Russell Bryant]

On 11/26/2013 12:39 PM, Mark Washenberger wrote:
> 
> 
> 
> On Mon, Nov 25, 2013 at 10:47 PM, Boris Pavlovic  > wrote:
> 
> Mark,
> 
> 
> Why we are not able to combine this and Nova meetup in the same
> place in the same time?
> 
> 
> The two events are being planned and sponsored separately. Maybe in the
> future it will make sense to merge them to ease travel difficulties for
> some. But there are likely some tradeoffs to consider.
> 
> Thanks for your interest

Yep, planning this stuff isn't trivial.  If we're not careful, it will
turn out to be just as complex as organizing the design summit itself.

These events really should be seen as optional, especially as compared
to the regular design summit.  Traveling twice a year just for the
regular design summits is a lot for many.  So, don't stress if you can't
make it.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Yuriy Taraday]

Hello.


On Fri, Nov 22, 2013 at 1:11 PM, Flavio Percoco  wrote:

>1) Store the commit sha from which the module was copied from.
>

I would suggest we don't duplicate this in every project's repo. It is
possible to find using the contents of the modules currently in project's
repo the corresponding commit from oslo-incubator (see [1] for a hint, feel
free to ask me about Git details). So there's no need to store this
information in a separate file.

   2) Add an 'auto-commit' parameter to the update script that will
>generate a commit message with the short log of the commits where
>the modules being updated were modified. Soemthing like:
>
>Syncing oslo-incubator modules
>
>log.py:
>commit1: short-message
>commit2: short-message
>commit3: short-message
>
>lockutils:
>commit4: short-message
>commit5: short-message
>

The script can use this information as well to get the last synced commit
for each module. We should to agree to use this format for all commit
messages and make commit detection easier.

I would drop the colon though to make it look like the usual 'git log
--oneline' output.

[1] http://stackoverflow.com/questions/223678/which-commit-has-this-blob

-- 

Kind regards, Yuriy.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Patil, Tushar]

+1

>-Original Message-
>From: Russell Bryant [mailto:rbry...@redhat.com]
>Sent: Tuesday, November 26, 2013 11:33 AM
>To: OpenStack Development Mailing List
>Subject: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-
>core
>
>Greetings,
>
>I would like to propose that we re-add Dan Prince to the nova-core
>review team.
>
>Dan Prince has been involved with Nova since early in OpenStack's
>history (Bexar timeframe).  He was a member of the nova-core review team
>from May 2011 to June 2013.  He has since picked back up with nova
>reviews [1].  We always say that when people leave nova-core, we would
>love to have them back if they are able to commit the time in the
>future.  I think this is a good example of that.
>
>Please respond with +1s or any concerns.
>
>Thanks,
>
>[1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
>
>--
>Russell Bryant
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Meeting Tuesday November 26th at 19:00 UTC

[Elizabeth Krumbach Joseph]

On Mon, Nov 25, 2013 at 11:02 AM, Elizabeth Krumbach Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting tomorrow, Tuesday November 26th, at 19:00 UTC in
> #openstack-meeting

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-11-26-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-11-26-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-11-26-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Solum] Definition feedback

[Tom Deckers (tdeckers)]

Hi All,

Few comments on the Definitions blueprint [1]:

1. I'd propose to alter the term 'Application' to either 'Application Package' 
or 'Package'.  Application isn't very descriptive and can be confusing to some 
with the actual deployed instance, etc.

2. It should be possible for the package to be self-contained, in order to 
distribute application definitions.   As such, instead of using a repo, source 
code might come with the package itself.  Has this been considered as a 
blueprint: deploy code/binaries that are in a zip, rather than a repo?  Maybe 
Artifact serves this purpose?

3. Artifact has not been called out as a top-level noun.  It probably should 
and get a proper definition.

4. Plan is described as deployment plan, but then it's also referenced in the 
description of 'Build'.  Plan seems to have a dual meaning, which is fine, but 
that should be called out explicitly.  Plan is not synonymous with deployment 
plan, rather we have a deployment plan and a build plan.  Those two together 
can be 'the plan'. 

5. Operations.  The definition states that definitions can be added to a 
Service too.  Since the Service is provided by the platform, I assume it 
already comes with operations predefined.

6. Operations. A descriptor should exist that can be used for registration of 
the deployed assembly into a catalog.  The descriptor should contain basic 
information about the exposed functional API and management API (e.g. 
Operations too).  This leads to the next point:

7. Package blueprint.  The Application Package might require its own blueprint 
to define how it's composed.  I can see how the Package is used to 
distribute/share an application.  The blueprint should define a well-known 
format. 

If the above makes sense, I can take a stab at an revised diagram.

Regards,
Tom Deckers.

[1] https://blueprints.launchpad.net/solum/+spec/definitions



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Joe Gordon]

On Nov 26, 2013 8:48 AM, "Dolph Mathews"  wrote:
>
>
> On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez 
wrote:
>>
>> Dolph Mathews wrote:
>> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
>> > mailto:robe...@robertcollins.net>> wrote:
>> >
>> > So my proposal is that we make it part of the base hygiene for a
>> > project that any recheck bugs being seen (either by
elastic-recheck or
>> > manual inspection) be considered critical and prioritised above
>> > feature work.
>> >
>> > I agree with the notion here (that fixing transient failures is
>> > critically high priority work for the community) -- but marking the bug
>> > as "critical" priority is just a subjective abuse of the priority
field.
>> > A non-critical bug is not necessarily non-critical work. The "critical"
>> > status should be reserved for issues that are actually non-shippable,
>> > catastrophically breaking issues.
>>
>> It's a classic bugtracking dilemma where the "Importance" field is both
>> used to describe bug impact and priority... while they don't always
match.
>
>
> ++
>
>>
>> That said, the "impact" of those bugs, considering potential development
>> activity breakage, *is* quite critical (they all are timebombs which
>> will create future gate fails if not handled at top priority).
>
>
> I generally agree, but I don't think it's fair to say that the impact of
a transient is universally a single priority, either. Some transient issues
occur more frequently and therefore have higher impact.
>
>>
>> So I think marking them Critical + tagging them is not that much of an
>> abuse, if we start including the gate impact in our bug Impact
>> assessments. That said, I'm also fine with High+Tag, as long as it
>> triggers the appropriate fast response everywhere.
>
>
> I'm fine with starting them at High, and elevating to Critical as
appropriate.
>
> Is the idea here to automatically apply a tag + priority as a result of
"recheck/reverify bug X" ? (as long as existing priority isn't overwritten!)

I certainly hope we don't automatically set priority based on raw recheck
data. We have a second list of bugs that we feed to elastic-recheck this
list is reviewed for duplicates and include fingerprints see we can better
assess the bug frequency.  I think the idea is to mark bugs from that list
as critical.  I also think it should be a manual process. As a bug should
be reviewed (does it have enough detail etc) before setting it to critical.

>
>>
>>
>> --
>> Thierry Carrez (ttx)
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
>
> -Dolph
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Nikola Đipanov]

+1

On 26/11/13 20:32, Russell Bryant wrote:
> Greetings,
> 
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
> 
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe).  He was a member of the nova-core review team
> from May 2011 to June 2013.  He has since picked back up with nova
> reviews [1].  We always say that when people leave nova-core, we would
> love to have them back if they are able to commit the time in the
> future.  I think this is a good example of that.
> 
> Please respond with +1s or any concerns.
> 
> Thanks,
> 
> [1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Chris Behrens]

+1

On Nov 26, 2013, at 11:32 AM, Russell Bryant  wrote:

> Greetings,
> 
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
> 
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe).  He was a member of the nova-core review team
> from May 2011 to June 2013.  He has since picked back up with nova
> reviews [1].  We always say that when people leave nova-core, we would
> love to have them back if they are able to commit the time in the
> future.  I think this is a good example of that.
> 
> Please respond with +1s or any concerns.
> 
> Thanks,
> 
> [1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
> 
> -- 
> Russell Bryant
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Joe Gordon]

On Nov 26, 2013 11:37 AM, "Russell Bryant"  wrote:
>
> Greetings,
>
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
>
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe).  He was a member of the nova-core review team
> from May 2011 to June 2013.  He has since picked back up with nova
> reviews [1].  We always say that when people leave nova-core, we would
> love to have them back if they are able to commit the time in the
> future.  I think this is a good example of that.
>
> Please respond with +1s or any concerns.

+1

>
> Thanks,
>
> [1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Dan Smith]

> My overall concern, and I think the other guys doing this for virt
> drivers will agree, is trying to scope down the exposure to unrelated
> failures.

But, if it's not related to your driver, then it also failed in the
upstream gate, right? If it didn't fail the upstream gate, then it is
some weird interaction. Of course, for spurious failures, you'll still
have the case where you recheck something and it passes the next time,
but that's exactly what we have today. I don't see a new CI job for a
given driver being a "monstrous" amount of work above and beyond what we
have to do today to triage the issues. Of course, driver CI is not a
single-time task that you never have to babysit...

I think that running as close as possible to the upstream gate is
crucial for us to gain the level of comfort we have with the stuff that
is actually tested upstream. If you pass more often because you don't
include any of the tests you don't strictly have to run, and don't have
a set of folks ready to triage failures, then you don't have quality
parity with the other stuff. That's kinda the whole point of us doing
this, no?

--Dan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [QA] Triaging Bugs during Review

[Vishvananda Ishaya]

Hi Everyone,

I tend to follow merges and look for valuable havana backports. A few bug
fixes have merged recently where the associated bug is untriaged (i.e. the
severity is listed as 'Unknown'). I assume that reviewers of a bugfix
patch are viewing the associated bugs. It makes sense for core-reviewers
to do some related bug triaging work in the process. It also would be
very helpful if they could be tagged for potential backport at the same time.

So I'm suggesting two things during review:

1. If you are reviewing a patch and the severity of the associated bug is
   set as unknown, then you set an appropriate severity[1].
2. If the bug is important and seems relatively self-contained that you
   mark it with the havana-backport-potential tag during review.

These two things should only take a matter of seconds, and will greatly help
the stable-maintainers team.

I will add these responsibilities to the review checklist[2] unless I hear
some disagreement here.

Thanks,
Vish

[1] 
https://wiki.openstack.org/wiki/BugTriage#Task_2:_Prioritize_confirmed_bugs_.28bug_supervisors.29
[2] https://wiki.openstack.org/wiki/ReviewChecklist


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Tim Schnell]

So the originally question that I attempted to pose was, "Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?". It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called "keywords" that contains this template type.

keywords: wordpress, mysql, etcŠ


Use Case #2
The template author should also be able to explicitly define a help string
that is distinct and separate from the description of an individual
parameter. An example where this use case originated was with Nova
Keypairs. The description of a keypair parameter might be something like,
"This is the name of a nova key pair that will be used to ssh to the
compute instance." A help string for this same parameter would be, "To
learn more about nova keypairs click on this help article."

I propose adding an additional field to the parameter definition:

Parameters:
:
description: This is the name of a nova key pair that 
will be used to
ssh to the compute instance.
help: To learn more about nova key pairs click on this 
help article.

Use Case #3
Grouping parameters would help the client make smarter decisions about how
to display the parameters for input to the end-user. This is so that all
parameters related to some database resource can be intelligently grouped
together. In addition to grouping these parameters together, there should
be a method to ensuring that the order within the group of parameters can
be explicitly stated. This way, the client can return a group of database
parameters and the template author can indicate that the database instance
name should be first, then the username, then the password, instead of
that group being returned in a random order.

Parameters:
db_name:
group: db
order: 0
db_username:
group: db
order: 1
db_password:
group: db
order: 2
web_node_name:
group: web_node
order: 0
keypair:
group: web_node
order: 1

These are the use cases that have been clearly defined. The original
purpose of the metadata section was to "future-proof" (I say future-proof,
you say pre-optimize ;) ) rapid iterations to potential client design. The
intent of the strategy was so that we did not overburden the Heat Core
team with requirements that may fluctuate or change as we attempt to
improve the user experience of Heat for the community. In hindsight I can
see how that intent was misconstrued and may have come off as
condescending and I apologize for that.

I think that these proposed use cases will add real value to Heat and
would require only changes to the HOT specification. If these are
acceptable please let me know and I will drop the existing blueprint and
patches in favor of something that implements this design. If there are
issues to discuss here please suggest alternative solutions so that we can
continue to move forward with these improvements.

I have no doubt that this is just the beginning of plenty of requirements
being driven from an attempt to improve the overall end user experience of
Heat and I will continue to vet the use cases and proposed implementations
with the community before suggesting a solution. I know that this proposal
leaves out a few use cases that have been discussed like template
author/version and that is because I believe that some of the arguments
made are valid and should be looked into before proposing changes to Heat.
Most of those other use cases probably can be served from some other
solution like git or the future template catalog.

Thanks, 
Tim





On 11/26/13 12:31 PM, "Zane Bitter"  wrote:

>

Re: [openstack-dev] [Neutron][Tempest] Heat template for services

[Steve Baker]

On 11/27/2013 07:16 AM, Nachi Ueno wrote:
> Hi Summit, Eugene
>
> We have submitted a Heat template for advanced services.
> This is combination of LBaaS, FWaaS and VPN.
> This is a also good demo for how to use neutron services.
>
> https://review.openstack.org/#/c/58496/1
>
> It is great if we could get feedback from yours.
This template is fine as an example template for heat-templates, but not
for a tempest test.

I think installing apache, mysql and wordpress is not appropriate when
the aim is a functional test of LBaaS, FWaaS and VPN

These should probably be 3 different scenario tests using heatclient, an
separate yaml template, and written in this style:
https://github.com/openstack/tempest/tree/stable/havana/tempest/scenario/orchestration

For the LBaaS test, using SimpleHTTPServer[1] instead of apache would
mean no packages would need to be installed (which would be slow, and
risks transient errors). Each web server can return something unique, so
the test can assert that the load balancer is balancing all servers.

For FWaaS and VPN it would be handy if the templates required no nova
servers, or servers that require only cirros, since then they can run in
the standard gate jobs.

> FYI, here is existing heat & neutron test.
> https://github.com/openstack/tempest/blob/master/tempest/api/orchestration/stacks/test_neutron_resources.py
>

[1] http://docs.python.org/2/library/simplehttpserver.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fw: [Neutron][IPv6] Meeting logs from the first IRC meeting

[Collins, Sean (Contractor)]

On Tue, Nov 26, 2013 at 06:07:07PM +0800, Da Zhao Y Yu wrote:
> Sean, what about your progress? I saw your code change jekins still in 
> failed status.

Hi,

I've been busy tracking down the IPv6 issue in our lab environment -
we were using the Hybrid OVS driver in our Nova.conf and that was
breaking IPv6 - so we changed over to the Generic VIF driver,
only to hit the bug https://bugs.launchpad.net/devstack/+bug/1252620 
where the Security Group API doesn't work.

Which leaves you with the following choices:

A) Working V6 with the Generic VIF driver, but no Security Groups
B) Working Security Groups but no V6, with the hybrid VIF driver.

I'm going to try and see if I can make some of the patches against the
hybrid driver work and get V6 working.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [QA] Triaging Bugs during Review

[Michael Still]

I wonder how hard it would be to add bug information to gerrit to make
the state of the bug being fixed more obvious?

Just a random idea.

Michael

On Wed, Nov 27, 2013 at 8:06 AM, Vishvananda Ishaya
 wrote:
> Hi Everyone,
>
> I tend to follow merges and look for valuable havana backports. A few bug
> fixes have merged recently where the associated bug is untriaged (i.e. the
> severity is listed as 'Unknown'). I assume that reviewers of a bugfix
> patch are viewing the associated bugs. It makes sense for core-reviewers
> to do some related bug triaging work in the process. It also would be
> very helpful if they could be tagged for potential backport at the same time.
>
> So I'm suggesting two things during review:
>
> 1. If you are reviewing a patch and the severity of the associated bug is
>set as unknown, then you set an appropriate severity[1].
> 2. If the bug is important and seems relatively self-contained that you
>mark it with the havana-backport-potential tag during review.
>
> These two things should only take a matter of seconds, and will greatly help
> the stable-maintainers team.
>
> I will add these responsibilities to the review checklist[2] unless I hear
> some disagreement here.
>
> Thanks,
> Vish
>
> [1] 
> https://wiki.openstack.org/wiki/BugTriage#Task_2:_Prioritize_confirmed_bugs_.28bug_supervisors.29
> [2] https://wiki.openstack.org/wiki/ReviewChecklist
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Tempest] Heat template for services

[Nachi Ueno]

Hi Steve

Thank you for your input.
I agree with you.
We added "apache, mysql and wordpress" for this review, because
heat-template is a show-case for example template.

I agree with you, we can start a process of simplehttpserver in meta
data script for LBaaS test.

Best
Nachi


2013/11/26 Steve Baker :
> On 11/27/2013 07:16 AM, Nachi Ueno wrote:
>
> Hi Summit, Eugene
>
> We have submitted a Heat template for advanced services.
> This is combination of LBaaS, FWaaS and VPN.
> This is a also good demo for how to use neutron services.
>
> https://review.openstack.org/#/c/58496/1
>
> It is great if we could get feedback from yours.
>
> This template is fine as an example template for heat-templates, but not for
> a tempest test.
>
> I think installing apache, mysql and wordpress is not appropriate when the
> aim is a functional test of LBaaS, FWaaS and VPN
>
> These should probably be 3 different scenario tests using heatclient, an
> separate yaml template, and written in this style:
> https://github.com/openstack/tempest/tree/stable/havana/tempest/scenario/orchestration
>
> For the LBaaS test, using SimpleHTTPServer[1] instead of apache would mean
> no packages would need to be installed (which would be slow, and risks
> transient errors). Each web server can return something unique, so the test
> can assert that the load balancer is balancing all servers.
>
> For FWaaS and VPN it would be handy if the templates required no nova
> servers, or servers that require only cirros, since then they can run in the
> standard gate jobs.
>
>
> FYI, here is existing heat & neutron test.
> https://github.com/openstack/tempest/blob/master/tempest/api/orchestration/stacks/test_neutron_resources.py
>
>
> [1] http://docs.python.org/2/library/simplehttpserver.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Christopher Armstrong]

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell wrote:

> So the originally question that I attempted to pose was, "Can we add a
> schema-less metadata section to the template that can be used for a
> variety of purposes?". It looks like the answer is no, we need to discuss
> the features that would go in the metadata section and add them to the HOT
> specification if they are viable. I don't necessarily agree with this
> answer but I accept it as viable and take responsibility for the
> long-winded process that it took to get to this point.
>
> I think some valid points have been made and I have re-focused my efforts
> into the following proposed solution.
>
> I am fine with getting rid of the concept of a schema-less metadata
> section. If we can arrive at a workable design for a few use cases then I
> think that we won't need to discuss any of the options that Zane mentioned
> for handling the metadata section, comments, separate file, or in the
> template body.
>
> Use Case #1
> I see valid value in being able to group templates based on a type or
> keyword. This would allow any client, Horizon or a Template Catalog
> service, to better organize and handle display options for an end-user.
>
> I believe that Ladislav initially proposed a solution that will work here.
> So I will second a proposal that we add a new top-level field to the HOT
> specification called "keywords" that contains this template type.
>
> keywords: wordpress, mysql, etc
>
>
>
My immediate inclination would be to just make keywords/tags out-of-band
metadata managed by the template repository. I imagine this would be
something that would be very useful to change without having to edit the
template anyway.



> Use Case #2
> The template author should also be able to explicitly define a help string
> that is distinct and separate from the description of an individual
> parameter. An example where this use case originated was with Nova
> Keypairs. The description of a keypair parameter might be something like,
> "This is the name of a nova key pair that will be used to ssh to the
> compute instance." A help string for this same parameter would be, "To
> learn more about nova keypairs click on this help article."
>
> I propose adding an additional field to the parameter definition:
>
> Parameters:
> :
> description: This is the name of a nova key pair
> that will be used to
> ssh to the compute instance.
> help: To learn more about nova key pairs click on
> this  href="/some/url/">help article.
>
>
This one seems a bit weirder. I don't really understand what's wrong with
just adding this content to the description field. However, if there are
currently any objects in HOT that don't have any mechanism for providing a
description, we should definitely add them where they're missing. Do you
think we need to extend the semantics of the "description" field to allow
HTML?



> Use Case #3
> Grouping parameters would help the client make smarter decisions about how
> to display the parameters for input to the end-user. This is so that all
> parameters related to some database resource can be intelligently grouped
> together. In addition to grouping these parameters together, there should
> be a method to ensuring that the order within the group of parameters can
> be explicitly stated. This way, the client can return a group of database
> parameters and the template author can indicate that the database instance
> name should be first, then the username, then the password, instead of
> that group being returned in a random order.
>
> Parameters:
> db_name:
> group: db
> order: 0
> db_username:
> group: db
> order: 1
> db_password:
> group: db
> order: 2
> web_node_name:
> group: web_node
> order: 0
> keypair:
> group: web_node
> order: 1
>
>
>
>
Have you considered just rendering them in the order that they appear in
the template? I realize it's not the name (since you don't have any group
names that you could use as a title for "boxes" around groups of
parameters), but it might be a good enough compromise. If you think it's
absolutely mandatory to be able to group them in named groups, then I would
actually propose a prettier syntax:

ParameterGroups:
db:
name: ...
username: ...
password: ...
web_node:
name: ...
keypair: ...

The ordering would be based on the ordering that they appear within the
template, and you wouldn't have to repeat yourself naming the group for
each parameter.

Thanks very much for writing up these use cases!

-- 
IRC: radix
Christopher Armstrong
Rackspace
__

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Sean Dague]

On 11/26/2013 02:32 PM, Russell Bryant wrote:
> Greetings,
> 
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
> 
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe).  He was a member of the nova-core review team
> from May 2011 to June 2013.  He has since picked back up with nova
> reviews [1].  We always say that when people leave nova-core, we would
> love to have them back if they are able to commit the time in the
> future.  I think this is a good example of that.
> 
> Please respond with +1s or any concerns.
> 
> Thanks,
> 
> [1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
> 

+1

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

[Mark McLoughlin]

On Tue, 2013-11-26 at 14:32 -0500, Russell Bryant wrote:
> Greetings,
> 
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
> 
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe).  He was a member of the nova-core review team
> from May 2011 to June 2013.  He has since picked back up with nova
> reviews [1].  We always say that when people leave nova-core, we would
> love to have them back if they are able to commit the time in the
> future.  I think this is a good example of that.
> 
> Please respond with +1s or any concerns.

Nice, definitely agree.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Steve Baker]

On 11/27/2013 10:24 AM, Tim Schnell wrote:
> So the originally question that I attempted to pose was, "Can we add a
> schema-less metadata section to the template that can be used for a
> variety of purposes?". It looks like the answer is no, we need to discuss
> the features that would go in the metadata section and add them to the HOT
> specification if they are viable. I don't necessarily agree with this
> answer but I accept it as viable and take responsibility for the
> long-winded process that it took to get to this point.
>
> I think some valid points have been made and I have re-focused my efforts
> into the following proposed solution.
>
> I am fine with getting rid of the concept of a schema-less metadata
> section. If we can arrive at a workable design for a few use cases then I
> think that we won't need to discuss any of the options that Zane mentioned
> for handling the metadata section, comments, separate file, or in the
> template body.
>
> Use Case #1
> I see valid value in being able to group templates based on a type or
> keyword. This would allow any client, Horizon or a Template Catalog
> service, to better organize and handle display options for an end-user.
>
> I believe that Ladislav initially proposed a solution that will work here.
> So I will second a proposal that we add a new top-level field to the HOT
> specification called "keywords" that contains this template type.
>
>   keywords: wordpress, mysql, etcŠ
+1, but lets make the most of yaml and give it structure:
keywords: [wordpress, mysql, lamp]
keywords:
- wordpress
- mysql
- lamp

>
> Use Case #2
> The template author should also be able to explicitly define a help string
> that is distinct and separate from the description of an individual
> parameter. An example where this use case originated was with Nova
> Keypairs. The description of a keypair parameter might be something like,
> "This is the name of a nova key pair that will be used to ssh to the
> compute instance." A help string for this same parameter would be, "To
> learn more about nova keypairs click on this help article."
>
> I propose adding an additional field to the parameter definition:
>   
>   Parameters:
>   :
>   description: This is the name of a nova key pair that 
> will be used to
> ssh to the compute instance.
>   help: To learn more about nova key pairs click on this 
>  href="/some/url/">help article.
+1, this could be used today in the stack create screens of horizon.

> Use Case #3
> Grouping parameters would help the client make smarter decisions about how
> to display the parameters for input to the end-user. This is so that all
> parameters related to some database resource can be intelligently grouped
> together. In addition to grouping these parameters together, there should
> be a method to ensuring that the order within the group of parameters can
> be explicitly stated. This way, the client can return a group of database
> parameters and the template author can indicate that the database instance
> name should be first, then the username, then the password, instead of
> that group being returned in a random order.
>
>   Parameters:
>   db_name:
>   group: db
>   order: 0
>   db_username:
>   group: db
>   order: 1
>   db_password:
>   group: db
>   order: 2
>   web_node_name:
>   group: web_node
>   order: 0
>   keypair:
>   group: web_node
>   order: 1
>
> These are the use cases that have been clearly defined. The original
> purpose of the metadata section was to "future-proof" (I say future-proof,
> you say pre-optimize ;) ) rapid iterations to potential client design. The
> intent of the strategy was so that we did not overburden the Heat Core
> team with requirements that may fluctuate or change as we attempt to
> improve the user experience of Heat for the community. In hindsight I can
> see how that intent was misconstrued and may have come off as
> condescending and I apologize for that.
We *need* a solution for grouping and ordering in horizon for generating
the parameter fields. All that is being done currently (I think) is
sorting by mandatory, then parameter name, which often pushes important
parameters to the bottom of the screen. I'd prefer explicit attributes
rather than inferring from a special parser that preserves the order of
parameters in the template. The parameter fields are built from the
results of a template-validate call.

Also, a group should really have its own order and description to
display, so we may need a new top-level section, eg
parameter-groups:
  db:
description: Database configuration options
order: 1
  web_node:
description: Web server configuration
order: 0

Re: [openstack-dev] [nova] [QA] Triaging Bugs during Review

[Russell Bryant]

On 11/26/2013 04:06 PM, Vishvananda Ishaya wrote:
> Hi Everyone,
> 
> I tend to follow merges and look for valuable havana backports. A
> few bug fixes have merged recently where the associated bug is
> untriaged (i.e. the severity is listed as 'Unknown'). I assume that
> reviewers of a bugfix patch are viewing the associated bugs. It
> makes sense for core-reviewers to do some related bug triaging work
> in the process. It also would be very helpful if they could be
> tagged for potential backport at the same time.
> 
> So I'm suggesting two things during review:
> 
> 1. If you are reviewing a patch and the severity of the associated
> bug is set as unknown, then you set an appropriate severity[1]. 2.
> If the bug is important and seems relatively self-contained that
> you mark it with the havana-backport-potential tag during review.
> 
> These two things should only take a matter of seconds, and will
> greatly help the stable-maintainers team.
> 
> I will add these responsibilities to the review checklist[2] unless
> I hear some disagreement here.

+1

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [QA] Triaging Bugs during Review

[Mark McLoughlin]

On Tue, 2013-11-26 at 13:06 -0800, Vishvananda Ishaya wrote:
> Hi Everyone,
> 
> I tend to follow merges and look for valuable havana backports. A few bug
> fixes have merged recently where the associated bug is untriaged (i.e. the
> severity is listed as 'Unknown'). I assume that reviewers of a bugfix
> patch are viewing the associated bugs. It makes sense for core-reviewers
> to do some related bug triaging work in the process. It also would be
> very helpful if they could be tagged for potential backport at the same time.
> 
> So I'm suggesting two things during review:
> 
> 1. If you are reviewing a patch and the severity of the associated bug is
>set as unknown, then you set an appropriate severity[1].
> 2. If the bug is important and seems relatively self-contained that you
>mark it with the havana-backport-potential tag during review.
> 
> These two things should only take a matter of seconds, and will greatly help
> the stable-maintainers team.
> 
> I will add these responsibilities to the review checklist[2] unless I hear
> some disagreement here.

FWIW, I totally agree and do this out of habit. Thanks for raising it.

But ... oh wow! We have 103 Nova bugs tagged with
havana-backport-potential?

  https://bugs.launchpad.net/nova/+bugs?field.tag=havana-backport-potential

Are some of these getting backported but the tag isn't being removed?
The thinking originally was that the tag would be removed as soon as a
havana task for the bug was opened.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Steve Baker]

On 11/27/2013 11:02 AM, Christopher Armstrong wrote:
> On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell
> mailto:tim.schn...@rackspace.com>> wrote:
>
>  
>
> Use Case #3
> Grouping parameters would help the client make smarter decisions
> about how
> to display the parameters for input to the end-user. This is so
> that all
> parameters related to some database resource can be intelligently
> grouped
> together. In addition to grouping these parameters together, there
> should
> be a method to ensuring that the order within the group of
> parameters can
> be explicitly stated. This way, the client can return a group of
> database
> parameters and the template author can indicate that the database
> instance
> name should be first, then the username, then the password, instead of
> that group being returned in a random order.
>
> Parameters:
> db_name:
> group: db
> order: 0
> db_username:
> group: db
> order: 1
> db_password:
> group: db
> order: 2
> web_node_name:
> group: web_node
> order: 0
> keypair:
> group: web_node
> order: 1
>
>
>
>
> Have you considered just rendering them in the order that they appear
> in the template? I realize it's not the name (since you don't have any
> group names that you could use as a title for "boxes" around groups of
> parameters), but it might be a good enough compromise. If you think
> it's absolutely mandatory to be able to group them in named groups,
> then I would actually propose a prettier syntax:
>
> ParameterGroups:
> db:
> name: ...
> username: ...
> password: ...
> web_node:
> name: ...
> keypair: ...
>
> The ordering would be based on the ordering that they appear within
> the template, and you wouldn't have to repeat yourself naming the
> group for each parameter.
>
> Thanks very much for writing up these use cases!
>
Good point, I'd like to revise my previous parameter-groups example:

parameter-groups:
- name: db
  description: Database configuration options
  parameters: [db_name, db_username, db_password]
- name: web_node
  description: Web server configuration
  parameters: [web_node_name, keypair]
parameters:
  # as above, but without requiring any order or group attributes

Here, parameter-groups is a list which implies the order, and parameters are 
specified in the group as a list, so we get the order from that too. This means 
a new parameter-groups section which contains anything required to build a good 
parameters form, and no modifications required to the parameters section at 
all. 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Tim Schnell]

From: Christopher Armstrong 
mailto:chris.armstr...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & 
roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
mailto:tim.schn...@rackspace.com>> wrote:
So the originally question that I attempted to pose was, "Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?". It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called "keywords" that contains this template type.

keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band 
metadata managed by the template repository. I imagine this would be something 
that would be very useful to change without having to edit the template anyway.

I'm not exactly sure what you are suggesting here, but I think that adding 
these keywords to the template will be less error prone than attempting to 
derive them some other way.


Use Case #2
The template author should also be able to explicitly define a help string
that is distinct and separate from the description of an individual
parameter. An example where this use case originated was with Nova
Keypairs. The description of a keypair parameter might be something like,
"This is the name of a nova key pair that will be used to ssh to the
compute instance." A help string for this same parameter would be, "To
learn more about nova keypairs click on this help article."

I propose adding an additional field to the parameter definition:

Parameters:
:
description: This is the name of a nova key pair that 
will be used to
ssh to the compute instance.
help: To learn more about nova key pairs click on this 
help article.


This one seems a bit weirder. I don't really understand what's wrong with just 
adding this content to the description field. However, if there are currently 
any objects in HOT that don't have any mechanism for providing a description, 
we should definitely add them where they're missing. Do you think we need to 
extend the semantics of the "description" field to allow HTML?

Description and help are separate things from a UI perspective. A description 
might be displayed as a label in a form or in a paragraph somewhere around the 
input. A help string is typically displayed as hover text when focusing on the 
input or hovering/clicking on a question mark icon next to the field. We could 
technically separate these things in the code but because they serve separate 
purposes I would prefer to have them be defined explicitly.


Use Case #3
Grouping parameters would help the client make smarter decisions about how
to display the parameters for input to the end-user. This is so that all
parameters related to some database resource can be intelligently grouped
together. In addition to grouping these parameters together, there should
be a method to ensuring that the order within the group of parameters can
be explicitly stated. This way, the client can return a group of database
parameters and the template author can indicate that the database instance
name should be first, then the username, then the password, instead of
that group being returned in a random order.

Parameters:
db_name:
group: db
order: 0
db_username:
group: db
order: 1
db_password:
group: db
order: 2
web_node_name:
group: web_node
  

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Tim Schnell]

From: Steve Baker mailto:sba...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:29 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & 
roadmap

On 11/27/2013 11:02 AM, Christopher Armstrong wrote:
On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
mailto:tim.schn...@rackspace.com>> wrote:


Use Case #3
Grouping parameters would help the client make smarter decisions about how
to display the parameters for input to the end-user. This is so that all
parameters related to some database resource can be intelligently grouped
together. In addition to grouping these parameters together, there should
be a method to ensuring that the order within the group of parameters can
be explicitly stated. This way, the client can return a group of database
parameters and the template author can indicate that the database instance
name should be first, then the username, then the password, instead of
that group being returned in a random order.

Parameters:
db_name:
group: db
order: 0
db_username:
group: db
order: 1
db_password:
group: db
order: 2
web_node_name:
group: web_node
order: 0
keypair:
group: web_node
order: 1




Have you considered just rendering them in the order that they appear in the 
template? I realize it's not the name (since you don't have any group names 
that you could use as a title for "boxes" around groups of parameters), but it 
might be a good enough compromise. If you think it's absolutely mandatory to be 
able to group them in named groups, then I would actually propose a prettier 
syntax:

ParameterGroups:
db:
name: ...
username: ...
password: ...
web_node:
name: ...
keypair: ...

The ordering would be based on the ordering that they appear within the 
template, and you wouldn't have to repeat yourself naming the group for each 
parameter.

Thanks very much for writing up these use cases!

Good point, I'd like to revise my previous parameter-groups example:

parameter-groups:
- name: db
  description: Database configuration options
  parameters: [db_name, db_username, db_password]
- name: web_node
  description: Web server configuration
  parameters: [web_node_name, keypair]
parameters:
  # as above, but without requiring any order or group attributes

Here, parameter-groups is a list which implies the order, and parameters are 
specified in the group as a list, so we get the order from that too. This means 
a new parameter-groups section which contains anything required to build a good 
parameters form, and no modifications required to the parameters section at all.


+1 This structure gives me all of the information that I would need for 
organizing the parameters on the screen in an exact way.

Thanks,
Tim

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

[Mark McLoughlin]

On Tue, 2013-11-26 at 12:29 -0800, Joe Gordon wrote:
> On Nov 26, 2013 8:48 AM, "Dolph Mathews"  wrote:
> >
> >
> > On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez 
> wrote:
> >>
> >> Dolph Mathews wrote:
> >> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
> >> > mailto:robe...@robertcollins.net>> wrote:
> >> >
> >> > So my proposal is that we make it part of the base hygiene for a
> >> > project that any recheck bugs being seen (either by
> elastic-recheck or
> >> > manual inspection) be considered critical and prioritised above
> >> > feature work.
> >> >
> >> > I agree with the notion here (that fixing transient failures is
> >> > critically high priority work for the community) -- but marking the bug
> >> > as "critical" priority is just a subjective abuse of the priority
> field.
> >> > A non-critical bug is not necessarily non-critical work. The "critical"
> >> > status should be reserved for issues that are actually non-shippable,
> >> > catastrophically breaking issues.
> >>
> >> It's a classic bugtracking dilemma where the "Importance" field is both
> >> used to describe bug impact and priority... while they don't always
> match.
> >
> >
> > ++
> >
> >>
> >> That said, the "impact" of those bugs, considering potential development
> >> activity breakage, *is* quite critical (they all are timebombs which
> >> will create future gate fails if not handled at top priority).
> >
> >
> > I generally agree, but I don't think it's fair to say that the impact of
> a transient is universally a single priority, either. Some transient issues
> occur more frequently and therefore have higher impact.
> >
> >>
> >> So I think marking them Critical + tagging them is not that much of an
> >> abuse, if we start including the gate impact in our bug Impact
> >> assessments. That said, I'm also fine with High+Tag, as long as it
> >> triggers the appropriate fast response everywhere.
> >
> >
> > I'm fine with starting them at High, and elevating to Critical as
> appropriate.
> >
> > Is the idea here to automatically apply a tag + priority as a result of
> "recheck/reverify bug X" ? (as long as existing priority isn't overwritten!)
> 
> I certainly hope we don't automatically set priority based on raw recheck
> data. We have a second list of bugs that we feed to elastic-recheck this
> list is reviewed for duplicates and include fingerprints see we can better
> assess the bug frequency.  I think the idea is to mark bugs from that list
> as critical.  I also think it should be a manual process. As a bug should
> be reviewed (does it have enough detail etc) before setting it to critical.

[Just to circle back and clarify my €0.02c during the TC and project
meetings tonight]

Any recheck bug which appears regularly in the graphs here:

  http://status.openstack.org/elastic-recheck/

means that a human has looked at it, determined a fingerprint for it, we
have a bunch of details about it and we have data as to it's regularity.
Any such bug is fair game to be marked Critical.

If it is still there a month later, but no-one is making any progress on
it and it's happening pretty irregularly ... then I think we'll see a
desire to move it back from Critical to High again so that the Critical
list isn't cluttered with stuff people are no longer paying close
attention to.

So, yeah - the intent sounds good to me.

Thanks,
Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Christopher Armstrong]

On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell wrote:

>
>From: Christopher Armstrong 
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, November 26, 2013 4:02 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
> & roadmap
>
>On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell  > wrote:
>
>> So the originally question that I attempted to pose was, "Can we add a
>> schema-less metadata section to the template that can be used for a
>> variety of purposes?". It looks like the answer is no, we need to discuss
>> the features that would go in the metadata section and add them to the HOT
>> specification if they are viable. I don't necessarily agree with this
>> answer but I accept it as viable and take responsibility for the
>> long-winded process that it took to get to this point.
>>
>> I think some valid points have been made and I have re-focused my efforts
>> into the following proposed solution.
>>
>> I am fine with getting rid of the concept of a schema-less metadata
>> section. If we can arrive at a workable design for a few use cases then I
>> think that we won't need to discuss any of the options that Zane mentioned
>> for handling the metadata section, comments, separate file, or in the
>> template body.
>>
>> Use Case #1
>> I see valid value in being able to group templates based on a type or
>> keyword. This would allow any client, Horizon or a Template Catalog
>> service, to better organize and handle display options for an end-user.
>>
>> I believe that Ladislav initially proposed a solution that will work here.
>> So I will second a proposal that we add a new top-level field to the HOT
>> specification called "keywords" that contains this template type.
>>
>> keywords: wordpress, mysql, etc
>>
>>
>>
>  My immediate inclination would be to just make keywords/tags out-of-band
> metadata managed by the template repository. I imagine this would be
> something that would be very useful to change without having to edit the
> template anyway.
>
>  *I'm not exactly sure what you are suggesting here, but I think that
> adding these keywords to the template will be less error prone than
> attempting to derive them some other way.*
>
>
Basically, I'm just suggesting putting the tags outside of template. Not
deriving them -- I still think they should be explicitly specified, but
just putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being
based on third-party or moderator input, instead of just based on what the
template author says.  Keeping them outside of the template would allow
content moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough
desire to see tags in the template, then I won't argue against it.



>
>
>> Use Case #2
>> The template author should also be able to explicitly define a help string
>> that is distinct and separate from the description of an individual
>> parameter. An example where this use case originated was with Nova
>> Keypairs. The description of a keypair parameter might be something like,
>> "This is the name of a nova key pair that will be used to ssh to the
>> compute instance." A help string for this same parameter would be, "To
>> learn more about nova keypairs click on this help article."
>>
>> I propose adding an additional field to the parameter definition:
>>
>> Parameters:
>> :
>> description: This is the name of a nova key pair
>> that will be used to
>> ssh to the compute instance.
>> help: To learn more about nova key pairs click on
>> this > href="/some/url/">help article.
>>
>>
>  This one seems a bit weirder. I don't really understand what's wrong
> with just adding this content to the description field. However, if there
> are currently any objects in HOT that don't have any mechanism for
> providing a description, we should definitely add them where they're
> missing. Do you think we need to extend the semantics of the "description"
> field to allow HTML?
>
>  *Description and help are separate things from a UI perspective. A
> description might be displayed as a label in a form or in a paragraph
> somewhere around the input. A help string is typically displayed as hover
> text when focusing on the input or hovering/clicking on a question mark
> icon next to the field. We could technically separate these things in the
> code but because they serve separate purposes I would prefer to have them
> be defined explicitly.*
>

Okay, fair enough.


>
>
>
>> Use Case #3
>> Grouping parameters would help the client make smarter decisions about how
>> to display the parameters for input to the end-

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Tim Schnell]

On 11/26/13 4:16 PM, "Steve Baker"  wrote:

>On 11/27/2013 10:24 AM, Tim Schnell wrote:
>> So the originally question that I attempted to pose was, "Can we add a
>> schema-less metadata section to the template that can be used for a
>> variety of purposes?". It looks like the answer is no, we need to
>>discuss
>> the features that would go in the metadata section and add them to the
>>HOT
>> specification if they are viable. I don't necessarily agree with this
>> answer but I accept it as viable and take responsibility for the
>> long-winded process that it took to get to this point.
>>
>> I think some valid points have been made and I have re-focused my
>>efforts
>> into the following proposed solution.
>>
>> I am fine with getting rid of the concept of a schema-less metadata
>> section. If we can arrive at a workable design for a few use cases then
>>I
>> think that we won't need to discuss any of the options that Zane
>>mentioned
>> for handling the metadata section, comments, separate file, or in the
>> template body.
>>
>> Use Case #1
>> I see valid value in being able to group templates based on a type or
>> keyword. This would allow any client, Horizon or a Template Catalog
>> service, to better organize and handle display options for an end-user.
>>
>> I believe that Ladislav initially proposed a solution that will work
>>here.
>> So I will second a proposal that we add a new top-level field to the HOT
>> specification called "keywords" that contains this template type.
>>
>>  keywords: wordpress, mysql, etcŠ
>+1, but lets make the most of yaml and give it structure:
>keywords: [wordpress, mysql, lamp]
>keywords:
>- wordpress
>- mysql
>- lamp
>
>>
>> Use Case #2
>> The template author should also be able to explicitly define a help
>>string
>> that is distinct and separate from the description of an individual
>> parameter. An example where this use case originated was with Nova
>> Keypairs. The description of a keypair parameter might be something
>>like,
>> "This is the name of a nova key pair that will be used to ssh to the
>> compute instance." A help string for this same parameter would be, "To
>> learn more about nova keypairs click on this help article."
>>
>> I propose adding an additional field to the parameter definition:
>>  
>>  Parameters:
>>  :
>>  description: This is the name of a nova key pair that 
>> will be used to
>> ssh to the compute instance.
>>  help: To learn more about nova key pairs click on this 
>> > href="/some/url/">help article.
>+1, this could be used today in the stack create screens of horizon.
>
>> Use Case #3
>> Grouping parameters would help the client make smarter decisions about
>>how
>> to display the parameters for input to the end-user. This is so that all
>> parameters related to some database resource can be intelligently
>>grouped
>> together. In addition to grouping these parameters together, there
>>should
>> be a method to ensuring that the order within the group of parameters
>>can
>> be explicitly stated. This way, the client can return a group of
>>database
>> parameters and the template author can indicate that the database
>>instance
>> name should be first, then the username, then the password, instead of
>> that group being returned in a random order.
>>
>>  Parameters:
>>  db_name:
>>  group: db
>>  order: 0
>>  db_username:
>>  group: db
>>  order: 1
>>  db_password:
>>  group: db
>>  order: 2
>>  web_node_name:
>>  group: web_node
>>  order: 0
>>  keypair:
>>  group: web_node
>>  order: 1
>>
>> These are the use cases that have been clearly defined. The original
>> purpose of the metadata section was to "future-proof" (I say
>>future-proof,
>> you say pre-optimize ;) ) rapid iterations to potential client design.
>>The
>> intent of the strategy was so that we did not overburden the Heat Core
>> team with requirements that may fluctuate or change as we attempt to
>> improve the user experience of Heat for the community. In hindsight I
>>can
>> see how that intent was misconstrued and may have come off as
>> condescending and I apologize for that.
>We *need* a solution for grouping and ordering in horizon for generating
>the parameter fields. All that is being done currently (I think) is
>sorting by mandatory, then parameter name, which often pushes important
>parameters to the bottom of the screen. I'd prefer explicit attributes
>rather than inferring from a special parser that preserves the order of
>parameters in the template. The parameter fields are built from the
>results of a template-validate call.
>
>Also, a group should really have its own order and description to
>display, so we may need a new top-level sect

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Tim Schnell]

On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell 
mailto:tim.schn...@rackspace.com>> wrote:

From: Christopher Armstrong 
mailto:chris.armstr...@rackspace.com>>

Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:02 PM

To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & 
roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
mailto:tim.schn...@rackspace.com>> wrote:
So the originally question that I attempted to pose was, "Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?". It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called "keywords" that contains this template type.

keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band 
metadata managed by the template repository. I imagine this would be something 
that would be very useful to change without having to edit the template anyway.

I'm not exactly sure what you are suggesting here, but I think that adding 
these keywords to the template will be less error prone than attempting to 
derive them some other way.


Basically, I'm just suggesting putting the tags outside of template. Not 
deriving them -- I still think they should be explicitly specified, but just 
putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being based 
on third-party or moderator input, instead of just based on what the template 
author says.  Keeping them outside of the template would allow content 
moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough 
desire to see tags in the template, then I won't argue against it.
---

The primary reason I would like to see this live inside of the template is 
because these keywords should be tied to the current state of the template that 
is saved by Heat on Stack Create and Stack Update. If someone performs a Stack 
Update that changes the content of the template, they should be responsible for 
updating the keywords in the template. If the keywords live outside of the 
template, it will be difficult to keep them in sync with the actual content of 
the template.

I guess what I'm saying is that the keywords should follow the instantiation of 
the template which could morph into something that may not match the original 
keywords that may be saved into a database of templates somewhere.

Tim
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Mark McLoughlin]

On Fri, 2013-11-22 at 12:39 -0500, Doug Hellmann wrote:
> On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco  wrote:
> 
> > Greetings,
> >
> > Based on the recent discussion that came out about not having enough
> > information in the commit message when syncing oslo-incubator modules,
> > I was thinking that besides encouraging people to write better commit
> > messages, we could also improve the script we use to sync those
> > modules.
> >
> > Some of the changes that I've been thinking of:
> >
> >1) Store the commit sha from which the module was copied from.
> >Every project using oslo, currently keeps the list of modules it
> >is using in `openstack-modules.conf` in a `module` parameter. We
> >could store, along with the module name, the sha of the commit it
> >was last synced from:
> >
> >module=log,commit
> >
> >or
> >
> >module=log
> >log=commit
> >
> 
> The second form will be easier to manage. Humans edit the module field and
> the script will edit the others.

How about adding it as a comment at the end of the python files
themselves and leaving openstack-common.conf for human editing?

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Mark McLoughlin]

On Fri, 2013-11-22 at 16:24 +, Duncan Thomas wrote:
> On 22 November 2013 14:59, Ben Nemec  wrote:
> 
> > One other thought I had was to add the ability to split one Oslo sync up
> > into multiple commits, either one per module, or even one per Oslo commit
> > for some really large module changes (I'm thinking of the 1000 line db sync
> > someone mentioned recently).  It would be more review churn, but at least it
> > would keep the changes per review down to a more reasonable level.   I'm not
> > positive it would be beneficial, but I thought I'd mention it.
> 
> Cinder (often but not always me) tends to reject merges that do more
> that one module at a time, because it makes it far harder to review
> and spot problems, so some from of automation of this would be great.

Yes, it's good practice to sync related changes in individual commits,
rather than one big oslo sync.

An example from a previous sync I did in Cinder:

  https://review.openstack.org/#/c/12409/ (cfg)
  https://review.openstack.org/#/c/12411/ (zmq)
  https://review.openstack.org/#/c/12410/ (notifier)
  https://review.openstack.org/#/c/12412/ (misc)

These were all proposed at the same time, but I split related notable
changes into their own commits and then had a "misc" sync for more
trivial stuff.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Summit session wrapup

[Robert Collins]

On 26 November 2013 07:41, Jaromir Coufal  wrote:
> Hey Rob,
>
> can we add 'Slick Overcloud deployment through the UI' to the list? There
> was no session about that, but we discussed it afterwords and agreed that it
> is high priority for Icehouse as well.
>
> I just want to keep it on the list, so we are aware of that.

Certainly. Please add a blueprint for that and I'll mark itup appropriately.

Related to that we had a long chat in IRC that I was to follow up here, so - ...

Tuskar is refocusing on getting the basics really right - slick basic
install, and then work up. At the same time, just about every nova
person I've spoken too (a /huge/ sample of three, but meh :)) has
expressed horror that Tuskar is doing it's own scheduling, and
confusion about the need to manage flavors in such detail.

So the discussion on IRC was about getting back to basics - a clean
core design and something that we aren't left with technical debt that
we need to eliminate in order to move forward - which the scheduler
stuff would be.

So: my question/proposal was this: lets set a couple of MVPs.

0: slick install homogeneous nodes:
 - ask about nodes and register them with nova baremetal / Ironic (can
use those APIs directly)
 - apply some very simple heuristics to turn that into a cloud:
   - 1 machine - all in one
   - 2 machines - separate hypervisor and the rest
   - 3 machines - two hypervisors and the rest
   - 4 machines - two hypervisors, HA the rest
   - 5 + scale out hypervisors
 - so total forms needed = 1 gather hw details
 - internals: heat template with one machine flavor used

1: add support for heterogeneous nodes:
 - for each service (storage compute etc) supply a list of flavors
we're willing to have that run on
 - pass that into the heat template
 - teach heat to deal with flavor specific resource exhaustion by
asking for a different flavor (or perhaps have nova accept multiple
flavors and 'choose one that works'): details to be discussed with
heat // nova at the right time.

2: add support for anti-affinity for HA setups:
 - here we get into the question about short term deliverables vs long
term desire, but at least we'll have a polished installer already.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Service scoped role definition

[Tiwari, Arvind]

Hi David,

Thanks for your time and valuable comments. I have replied to your comments and 
try to explain why I am advocating to this BP.

Let me know your thoughts, please feel free to update below etherpad   
https://etherpad.openstack.org/p/service-scoped-role-definition

Thanks again,
Arvind

-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Monday, November 25, 2013 12:12 PM
To: Tiwari, Arvind; OpenStack Development Mailing List
Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi Arvind

I have just added some comments to your blueprint page

regards

David


On 19/11/2013 00:01, Tiwari, Arvind wrote:
> Hi,
> 
>  
> 
> Based on our discussion in design summit , I have redone the service_id
> binding with roles BP
> .
> I have added a new BP (link below) along with detailed use case to
> support this BP.
> 
> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
> 
> Below etherpad link has some proposals for Role REST representation and
> pros and cons analysis
> 
>  
> 
> https://etherpad.openstack.org/p/service-scoped-role-definition
> 
>  
> 
> Please take look and let me know your thoughts.
> 
>  
> 
> It would be awesome if we can discuss it in tomorrow's meeting.
> 
>  
> 
> Thanks,
> 
> Arvind
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [QA] Triaging Bugs during Review

[Vishvananda Ishaya]

On Nov 26, 2013, at 2:26 PM, Mark McLoughlin  wrote:

> On Tue, 2013-11-26 at 13:06 -0800, Vishvananda Ishaya wrote:
>> Hi Everyone,
>> 
>> I tend to follow merges and look for valuable havana backports. A few bug
>> fixes have merged recently where the associated bug is untriaged (i.e. the
>> severity is listed as 'Unknown'). I assume that reviewers of a bugfix
>> patch are viewing the associated bugs. It makes sense for core-reviewers
>> to do some related bug triaging work in the process. It also would be
>> very helpful if they could be tagged for potential backport at the same time.
>> 
>> So I'm suggesting two things during review:
>> 
>> 1. If you are reviewing a patch and the severity of the associated bug is
>>   set as unknown, then you set an appropriate severity[1].
>> 2. If the bug is important and seems relatively self-contained that you
>>   mark it with the havana-backport-potential tag during review.
>> 
>> These two things should only take a matter of seconds, and will greatly help
>> the stable-maintainers team.
>> 
>> I will add these responsibilities to the review checklist[2] unless I hear
>> some disagreement here.
> 
> FWIW, I totally agree and do this out of habit. Thanks for raising it.
> 
> But ... oh wow! We have 103 Nova bugs tagged with
> havana-backport-potential?
> 
>  https://bugs.launchpad.net/nova/+bugs?field.tag=havana-backport-potential
> 
> Are some of these getting backported but the tag isn't being removed?
> The thinking originally was that the tag would be removed as soon as a
> havana task for the bug was opened.


Ideally the flow is to target the bug to havanna and remove the tag
before proposing the backport. I expect it is a combination of both:
a) the target / untag step being skipped
b) bugs that haven't been backported yet

Looks like we have some cleanup to do!

Vish

> 
> Mark.
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Angus Salkeld]

On 26/11/13 22:55 +, Tim Schnell wrote:


On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell 
mailto:tim.schn...@rackspace.com>> wrote:

From: Christopher Armstrong 
mailto:chris.armstr...@rackspace.com>>

Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:02 PM

To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & 
roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
mailto:tim.schn...@rackspace.com>> wrote:
So the originally question that I attempted to pose was, "Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?". It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called "keywords" that contains this template type.

   keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band 
metadata managed by the template repository. I imagine this would be something 
that would be very useful to change without having to edit the template anyway.

I'm not exactly sure what you are suggesting here, but I think that adding 
these keywords to the template will be less error prone than attempting to 
derive them some other way.


Basically, I'm just suggesting putting the tags outside of template. Not 
deriving them -- I still think they should be explicitly specified, but just 
putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being based 
on third-party or moderator input, instead of just based on what the template 
author says.  Keeping them outside of the template would allow content 
moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough 
desire to see tags in the template, then I won't argue against it.
---

The primary reason I would like to see this live inside of the template is 
because these keywords should be tied to the current state of the template that 
is saved by Heat on Stack Create and Stack Update. If someone performs a Stack 
Update that changes the content of the template, they should be responsible for 
updating the keywords in the template. If the keywords live outside of the 
template, it will be difficult to keep them in sync with the actual content of 
the template.

I guess what I'm saying is that the keywords should follow the instantiation of 
the template which could morph into something that may not match the original 
keywords that may be saved into a database of templates somewhere.


You have moved into a different use case now:
"I want a mechanism to tag particular versions of templates"


I'd suggest your heat-template-tag does something like this:

hash=$(git hash-object )
store_tag  $hash 

then you can query if a template has a particular tag by hashing
the given template and looking the tags by hash.

So you could have a tag that is "supported", that will be impossible
to fake. I don't see how you are going to do that by inserting
metadata into the template (a user could do that too).

-Angus



Tim



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Definition feedback

[Adrian Otto]

Tom, 

On Nov 26, 2013, at 12:09 PM, "Tom Deckers (tdeckers)" 
 wrote:

> Hi All,
> 
> Few comments on the Definitions blueprint [1]:
> 
> 1. I'd propose to alter the term 'Application' to either 'Application 
> Package' or 'Package'.  Application isn't very descriptive and can be 
> confusing to some with the actual deployed instance, etc.

I think that's a sensible suggestion. I'm open to using Package, as that's an 
accurate description of what an Application is currently conceived of.
> 
> 2. It should be possible for the package to be self-contained, in order to 
> distribute application definitions.   As such, instead of using a repo, 
> source code might come with the package itself.  Has this been considered as 
> a blueprint: deploy code/binaries that are in a zip, rather than a repo?  
> Maybe Artifact serves this purpose?

The API should allow you to deploy something directly from a source code repo 
without packaging anything up. It should also allow you to present some static 
deployment artifacts (container image, zip file, etc.) for code that has 
already been built/tested.

> 3. Artifact has not been called out as a top-level noun.  It probably should 
> and get a proper definition.

Good idea, I will add a definition for it.

> 4. Plan is described as deployment plan, but then it's also referenced in the 
> description of 'Build'.  Plan seems to have a dual meaning, which is fine, 
> but that should be called out explicitly.  Plan is not synonymous with 
> deployment plan, rather we have a deployment plan and a build plan.  Those 
> two together can be 'the plan'. 

Currently Plan does have a dual meaning, but it may make sense to split each 
out if they are different enough. I'm open to considering ideas on this.

> 5. Operations.  The definition states that definitions can be added to a 
> Service too.  Since the Service is provided by the platform, I assume it 
> already comes with operations predefined.

Yes, the service provider owns services that are provided by the Platform, and 
can extend them, where users may not. However, a user may register his/her own 
Services within the context of a given tenant account, and those can be 
extended and managed. In that case, you can actually connect Operations to 
Services as a tenant. So this is really a question of what scope the Service 
belongs to.

> 6. Operations. A descriptor should exist that can be used for registration of 
> the deployed assembly into a catalog.  The descriptor should contain basic 
> information about the exposed functional API and management API (e.g. 
> Operations too).  

An Assembly is a running group of cloud resources (a whole networked 
application). A listing of those is exposed through the Assemblies resource.

A Plan is a rubber stamp for producing new Assemblies, and can also be listed 
through the Plans resource. Any plan can be easily converted to an Assembly 
with an API call.

Were you thinking that we should have a catalog beyond these listings? Please 
elaborate on what you have in mind. I agree that any catalog should provide a 
way to resolve through to a resources registered Operations. If the current 
design prohibits this in any way, then I'd like to revise that.

> This leads to the next point:
> 
> 7. Package blueprint.  The Application Package might require its own 
> blueprint to define how it's composed.  I can see how the Package is used to 
> distribute/share an application.  The blueprint should define a well-known 
> format. 

Yes, we have a concept of this that I'm working to express in writing. Think of 
the relation between HOT files and Heat. We will have a similar relation of 
Plan files to Solum. I will be borrowing concepts from CAMP, which has fully 
specified a format from an open standards perspective that should be well 
suited for this purpose.

Thanks,

Adrian

> If the above makes sense, I can take a stab at an revised diagram.
> 
> Regards,
> Tom Deckers.
> 
> [1] https://blueprints.launchpad.net/solum/+spec/definitions
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to best make User Experience a priority in every project

[Mark McLoughlin]

On Wed, 2013-11-20 at 11:06 -0600, Dean Troyer wrote:
> On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez wrote:
> 
> > However, as was apparent in the Technical Committee meeting discussion
> >
> about it yesterday, most of us are not convinced that establishing and
> > blessing a separate team is the most efficient way to give UX the
> > attention it deserves. Ideally, UX-minded folks would get active
> > *within* existing project teams rather than form some sort of
> > counter-power as a separate team. In the same way we want scalability
> > and security mindset to be present in every project, we want UX to be
> > present in every project. It's more of an advocacy group than a
> > "program" imho.
> >
> 
> Having been working on a cross-project project for a while now I can
> confirm that there is a startling lack of coordination between projects on
> the same/similar tasks.  Oslo was a HUGE step toward reducing that and
> providing a good reference for code and libraries.  There is nothing today
> for the intangible parts that are both user and developer facing such as
> common message (log) formats, common terms (tenant vs project) and so on.
> 
> I think the model of the OSSG is a good one.  After reading the log of
> yesterday's meeting I think I would have thrown in that the need from my
> perspective is for a coordination role as much as anything.
> 
> The deliverables in the UX Program proposal seem a bit fuzzy to me as far
> as what might go into the repo.  If it is interface specs, those should be
> in either the project code repos docs/ tree or in the docs project
> directly.  Same for a Human Interface Guide (HIG) that both Horizon and OSC
> have (well, I did steal a lot of OSC's guide from Horizon's).

One straightforward example I could imagine from a UX Program is a REST
API design guide which captures the current common patterns between our
current APIs and points the way for common patterns new APIs should aim
to adopt. Same for our CLIs.

Or you could imagine a set of terminology/concept definitions - project
vs tenant anyone? :)

But, I think the basic point is that a group with common interests
should work on producing some concrete deliverables before being asked
to be recognized as an official program.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

[Tim Schnell]

On 11/26/13 5:24 PM, "Angus Salkeld"  wrote:

>On 26/11/13 22:55 +, Tim Schnell wrote:
>>
>>On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell
>>mailto:tim.schn...@rackspace.com>> wrote:
>>
>>From: Christopher Armstrong
>>mailto:chris.armstr...@rackspace.com>>
>>
>>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>mailto:openstack-dev@lists.openstack.o
>>rg>>
>>Date: Tuesday, November 26, 2013 4:02 PM
>>
>>To: "OpenStack Development Mailing List (not for usage questions)"
>>mailto:openstack-dev@lists.openstack.o
>>rg>>
>>Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
>>& roadmap
>>
>>On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell
>>mailto:tim.schn...@rackspace.com>> wrote:
>>So the originally question that I attempted to pose was, "Can we add a
>>schema-less metadata section to the template that can be used for a
>>variety of purposes?". It looks like the answer is no, we need to discuss
>>the features that would go in the metadata section and add them to the
>>HOT
>>specification if they are viable. I don't necessarily agree with this
>>answer but I accept it as viable and take responsibility for the
>>long-winded process that it took to get to this point.
>>
>>I think some valid points have been made and I have re-focused my efforts
>>into the following proposed solution.
>>
>>I am fine with getting rid of the concept of a schema-less metadata
>>section. If we can arrive at a workable design for a few use cases then I
>>think that we won't need to discuss any of the options that Zane
>>mentioned
>>for handling the metadata section, comments, separate file, or in the
>>template body.
>>
>>Use Case #1
>>I see valid value in being able to group templates based on a type or
>>keyword. This would allow any client, Horizon or a Template Catalog
>>service, to better organize and handle display options for an end-user.
>>
>>I believe that Ladislav initially proposed a solution that will work
>>here.
>>So I will second a proposal that we add a new top-level field to the HOT
>>specification called "keywords" that contains this template type.
>>
>>keywords: wordpress, mysql, etc
>>
>>
>>
>>My immediate inclination would be to just make keywords/tags out-of-band
>>metadata managed by the template repository. I imagine this would be
>>something that would be very useful to change without having to edit the
>>template anyway.
>>
>>I'm not exactly sure what you are suggesting here, but I think that
>>adding these keywords to the template will be less error prone than
>>attempting to derive them some other way.
>>
>>
>>Basically, I'm just suggesting putting the tags outside of template. Not
>>deriving them -- I still think they should be explicitly specified, but
>>just putting them in e.g. the database instead of directly in the
>>template.
>>
>>Basically, in a public repository of templates, I can imagine tags being
>>based on third-party or moderator input, instead of just based on what
>>the template author says.  Keeping them outside of the template would
>>allow content moderators to do that without posting a new version of the
>>template.
>>
>>Anyway, I don't feel that strongly about this - if there's a strong
>>enough desire to see tags in the template, then I won't argue against it.
>>---
>>
>>The primary reason I would like to see this live inside of the template
>>is because these keywords should be tied to the current state of the
>>template that is saved by Heat on Stack Create and Stack Update. If
>>someone performs a Stack Update that changes the content of the
>>template, they should be responsible for updating the keywords in the
>>template. If the keywords live outside of the template, it will be
>>difficult to keep them in sync with the actual content of the template.
>>
>>I guess what I'm saying is that the keywords should follow the
>>instantiation of the template which could morph into something that may
>>not match the original keywords that may be saved into a database of
>>templates somewhere.
>
>You have moved into a different use case now:
>"I want a mechanism to tag particular versions of templates"
>
>
>I'd suggest your heat-template-tag does something like this:
>
>hash=$(git hash-object )
>store_tag  $hash 
>
>then you can query if a template has a particular tag by hashing
>the given template and looking the tags by hash.
>
>So you could have a tag that is "supported", that will be impossible
>to fake. I don't see how you are going to do that by inserting
>metadata into the template (a user could do that too).
>
>-Angus

That is not the use case that I'm attempting to make, let me try again.
For what it's worth I agree, that in this use case "I want a mechanism to
tag particular versions of templates" your solution makes sense and will
probably be necessary as the requirements for the template catalog start
to become defined.

What I am attempting to explain is actually much simpler than that. There
are 2 times in a UI that I would b

Re: [openstack-dev] [keystone] Service scoped role definition

[Tiwari, Arvind]

Hi Adam,

Based on our discussion over IRC, I have updated the below etherpad with 
proposal for nested role definition

https://etherpad.openstack.org/p/service-scoped-role-definition 

Please take a look @ "Proposal (Ayoung) - Nested role definitions", I am sorry 
if I could not catch your idea. 

Feel free to update the etherpad.

Regards,
Arvind


-Original Message-
From: Tiwari, Arvind 
Sent: Tuesday, November 26, 2013 4:08 PM
To: David Chadwick; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi David,

Thanks for your time and valuable comments. I have replied to your comments and 
try to explain why I am advocating to this BP.

Let me know your thoughts, please feel free to update below etherpad   
https://etherpad.openstack.org/p/service-scoped-role-definition

Thanks again,
Arvind

-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Monday, November 25, 2013 12:12 PM
To: Tiwari, Arvind; OpenStack Development Mailing List
Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi Arvind

I have just added some comments to your blueprint page

regards

David


On 19/11/2013 00:01, Tiwari, Arvind wrote:
> Hi,
> 
>  
> 
> Based on our discussion in design summit , I have redone the service_id
> binding with roles BP
> .
> I have added a new BP (link below) along with detailed use case to
> support this BP.
> 
> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
> 
> Below etherpad link has some proposals for Role REST representation and
> pros and cons analysis
> 
>  
> 
> https://etherpad.openstack.org/p/service-scoped-role-definition
> 
>  
> 
> Please take look and let me know your thoughts.
> 
>  
> 
> It would be awesome if we can discuss it in tomorrow's meeting.
> 
>  
> 
> Thanks,
> 
> Arvind
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Definition feedback

[Clayton Coleman]

> On Nov 26, 2013, at 6:30 PM, Adrian Otto  wrote:
> 
> Tom, 
> 
> On Nov 26, 2013, at 12:09 PM, "Tom Deckers (tdeckers)" 
> wrote:
> 
>> Hi All,
>> 
>> Few comments on the Definitions blueprint [1]:
>> 
>> 1. I'd propose to alter the term 'Application' to either 'Application 
>> Package' or 'Package'.  Application isn't very descriptive and can be 
>> confusing to some with the actual deployed instance, etc.
> 
> I think that's a sensible suggestion. I'm open to using Package, as that's an 
> accurate description of what an Application is currently conceived of.

Package is a bit fraught given its overlap with other programming concepts:

Python Dev: How do I get my django app up in production?
Admin: You can create a new package for it.
Python Dev: You mean with an __init__.py file?

Admin: Go create your package in horizon so you can deploy it.
Java Dev: Ok, I ran Create Package from eclipse
(Hours of humorous miscommunication ensue)

Solum Admin: Go update the package for Bob's app.
Other Admin: I ran "yum update" but nothing happened...

If application is generic, that might be a good thing.  I'm not sure there are 
too many words that can accurately describe a Java WAR, a Ruby on Rails site, a 
Jenkins server, a massive service oriented architecture, or a worker queue 
processing log data at the same time.  Server and site are too specific or in 
use in openstack already, program is too singular.

At the end of the day someone has to explain these terms to a large number of 
end users (developers) - would hope we can pick a name that is recognizable to 
most of them immediately, because they're going to pick the option that looks 
the most familiar to them and try it first.

>> 
>> 2. It should be possible for the package to be self-contained, in order to 
>> distribute application definitions.   As such, instead of using a repo, 
>> source code might come with the package itself.  Has this been considered as 
>> a blueprint: deploy code/binaries that are in a zip, rather than a repo?  
>> Maybe Artifact serves this purpose?
> 
> The API should allow you to deploy something directly from a source code repo 
> without packaging anything up. It should also allow you to present some 
> static deployment artifacts (container image, zip file, etc.) for code that 
> has already been built/tested.
> 
>> 3. Artifact has not been called out as a top-level noun.  It probably should 
>> and get a proper definition.
> 
> Good idea, I will add a definition for it.
> 
>> 4. Plan is described as deployment plan, but then it's also referenced in 
>> the description of 'Build'.  Plan seems to have a dual meaning, which is 
>> fine, but that should be called out explicitly.  Plan is not synonymous with 
>> deployment plan, rather we have a deployment plan and a build plan.  Those 
>> two together can be 'the plan'.
> 
> Currently Plan does have a dual meaning, but it may make sense to split each 
> out if they are different enough. I'm open to considering ideas on this.
> 
>> 5. Operations.  The definition states that definitions can be added to a 
>> Service too.  Since the Service is provided by the platform, I assume it 
>> already comes with operations predefined.
> 
> Yes, the service provider owns services that are provided by the Platform, 
> and can extend them, where users may not. However, a user may register 
> his/her own Services within the context of a given tenant account, and those 
> can be extended and managed. In that case, you can actually connect 
> Operations to Services as a tenant. So this is really a question of what 
> scope the Service belongs to.
> 
>> 6. Operations. A descriptor should exist that can be used for registration 
>> of the deployed assembly into a catalog.  The descriptor should contain 
>> basic information about the exposed functional API and management API (e.g. 
>> Operations too).  
> 
> An Assembly is a running group of cloud resources (a whole networked 
> application

Or a part of one.

> ). A listing of those is exposed through the Assemblies resource.
> 
> A Plan is a rubber stamp for producing new Assemblies, and can also be listed 
> through the Plans resource. Any plan can be easily converted to an Assembly 
> with an API call.
> 
> Were you thinking that we should have a catalog beyond these listings? Please 
> elaborate on what you have in mind. I agree that any catalog should provide a 
> way to resolve through to a resources registered Operations. If the current 
> design prohibits this in any way, then I'd like to revise that.
> 
>> This leads to the next point:
>> 
>> 7. Package blueprint.  The Application Package might require its own 
>> blueprint to define how it's composed.  I can see how the Package is used to 
>> distribute/share an application.  The blueprint should define a well-known 
>> format.
> 
> Yes, we have a concept of this that I'm working to express in writing. Think 
> of the relation between HOT files and Heat. We will have a similar re

[openstack-dev] [Nova] Is there a way for the VM to identify that it is getting booted in OpenStack

[Vijay Venkatachalam]

Hi,
Is there a way for the VM to identify that it is getting booted 
in OpenStack?
As said in the below mail, once the VM knows it is booting in 
OpenStack it will alter the boot sequence.

AWS provides signatures in the BIOS strings.

PS:
Changed the title to be more friendly.

Thanks,
Vijay V.


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Tuesday, November 26, 2013 8:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & 
ESX similar to KVM instantiated VMs?

It is basically used to tailor the boot sequence if the VM gets booted in 
OpenStack. For ex. it could do the following


1.   Get IP through DHCP if booted in OpenStack

2.   Read config drive or contact metadata service and init the system if 
booted in OpenStack


Thanks,
Vijay V.

From: Bob Ball [mailto:bob.b...@citrix.com]
Sent: Tuesday, November 26, 2013 7:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & 
ESX similar to KVM instantiated VMs?

It's not certain that this will be implemented for the XenAPI driver.

Our view is that the BIOS strings shouldn't be relied upon - the hypervisor can 
clearly set them to anything so it's not really a reliable way to configure the 
application.  Also note that in some scenarios, such as PV guests in Xen 
clouds, you will not have any BIOS to query.  Finally we're not clear on the 
use case here - What's the use case for needing to know whether you VM is 
running under OpenStack or not?

Bob

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 26 November 2013 01:44
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & ESX 
similar to KVM instantiated VMs?

Hi,

In a KVM instantiated VM the following signature is present in the BIOS of the 
VM
The 'Manufacturer ' field in 'System Information' group is set to "OpenStack 
Foundation"



This helps the VM to identify that it is getting used in an OpenStack 
environment.



As far as I know XenServer is planning to set the BIOS Strings in IceHouse 
release.



Is this functionality available in other Hypervisors, especially Hyper-V & ESX?



Thanks,

Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Infra] Support for PCI Passthrough

[yongli he]

On 2013年11月23日 03:43, Jeremy Stanley wrote:
Hi, Jeremy

for currently, we need setup it up asap, so the third party seems the 
right way. but i have some concern,


if you post -1, you should post testing log somewhere for people to 
debug it, so does third party testing can

post testing log to the infra log server?


Yongli h...@intel.com

On 2013-11-22 08:59:16 + (+), Tan, Lin wrote:
[...]

Our module only works on the compute node that enables VT-d and
contains special PCIs which support the SR-IOV.

So is it possible to

1. setup compute node which enables pci passthrough.

2. modify the testing schedule logic allow the pci testing case
be scheduled to that machine

[...]

If you're asking about our official test infrastructure for the
OpenStack project, I believe this is infeasible for now. We
currently perform testing within generic virtual machines provided
by HPCloud and Rackspace, so the Nova compute nodes we build and
test are already running under virtualization and in turn manage
only paravirtualized QEMU instances.

In the near term, your best bet is to run your own test
infrastructure supporting the hardware features you require and
report advisory results back on proposed changes:

 http://ci.openstack.org/third_party.html

For a longer term solution, you may want to consult with the TripleO
project with regards to their bare-metal test plan:

 https://wiki.openstack.org/wiki/TripleO/TripleOCloud




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [ml2] Proposing a new time for the ML2 sub-team meeting

[Kyle Mestery (kmestery)]

Folks:

I'd like to propose moving the weekly ML2 meeting [1]. The new
proposed time is Wednesdays at 1600 UTC, and will be in the
#openstack-meeting-alt channel. Please respond back if this time
conflicts for you, otherwise starting next week on 12-4-2013
we'll have the meeting at the new time.

We will have a short meeting tomorrow at 1400 UTC in the
#openstack-meeting channel to cover action items from last
week and some proposed VIF changes.

Thanks!
Kyle

[1] https://wiki.openstack.org/wiki/Meetings/ML2

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Definition feedback

[Adrian Otto]

> On Nov 26, 2013, at 4:20 PM, "Clayton Coleman"  wrote:
> 
> 
> 
>> On Nov 26, 2013, at 6:30 PM, Adrian Otto  wrote:
>> 
>> Tom, 
>> 
>> On Nov 26, 2013, at 12:09 PM, "Tom Deckers (tdeckers)" 
>> wrote:
>> 
>>> Hi All,
>>> 
>>> Few comments on the Definitions blueprint [1]:
>>> 
>>> 1. I'd propose to alter the term 'Application' to either 'Application 
>>> Package' or 'Package'.  Application isn't very descriptive and can be 
>>> confusing to some with the actual deployed instance, etc.
>> 
>> I think that's a sensible suggestion. I'm open to using Package, as that's 
>> an accurate description of what an Application is currently conceived of.
> 
> Package is a bit fraught given its overlap with other programming concepts:
> 
> Python Dev: How do I get my django app up in production?
> Admin: You can create a new package for it.
> Python Dev: You mean with an __init__.py file?
> 
> Admin: Go create your package in horizon so you can deploy it.
> Java Dev: Ok, I ran Create Package from eclipse
> (Hours of humorous miscommunication ensue)
> 
> Solum Admin: Go update the package for Bob's app.
> Other Admin: I ran "yum update" but nothing happened...
> 
> If application is generic, that might be a good thing.  I'm not sure there 
> are too many words that can accurately describe a Java WAR, a Ruby on Rails 
> site, a Jenkins server, a massive service oriented architecture, or a worker 
> queue processing log data at the same time.  Server and site are too specific 
> or in use in openstack already, program is too singular.
> 
> At the end of the day someone has to explain these terms to a large number of 
> end users (developers) - would hope we can pick a name that is recognizable 
> to most of them immediately, because they're going to pick the option that 
> looks the most familiar to them and try it first.

All good points. This is why I like having these discussions with such a 
diverse group. I am still open to considering different terminology, accepting 
that whatever we pick to call things it will feel like a compromise for some of 
us. Any other thoughts on revisiting this name, or should we stick with 
application for now, and address this with more documentation to further 
clarify the meaning of the various abstracts?

>>> 2. It should be possible for the package to be self-contained, in order to 
>>> distribute application definitions.   As such, instead of using a repo, 
>>> source code might come with the package itself.  Has this been considered 
>>> as a blueprint: deploy code/binaries that are in a zip, rather than a repo? 
>>>  Maybe Artifact serves this purpose?
>> 
>> The API should allow you to deploy something directly from a source code 
>> repo without packaging anything up. It should also allow you to present some 
>> static deployment artifacts (container image, zip file, etc.) for code that 
>> has already been built/tested.
>> 
>>> 3. Artifact has not been called out as a top-level noun.  It probably 
>>> should and get a proper definition.
>> 
>> Good idea, I will add a definition for it.
>> 
>>> 4. Plan is described as deployment plan, but then it's also referenced in 
>>> the description of 'Build'.  Plan seems to have a dual meaning, which is 
>>> fine, but that should be called out explicitly.  Plan is not synonymous 
>>> with deployment plan, rather we have a deployment plan and a build plan.  
>>> Those two together can be 'the plan'.
>> 
>> Currently Plan does have a dual meaning, but it may make sense to split each 
>> out if they are different enough. I'm open to considering ideas on this.
>> 
>>> 5. Operations.  The definition states that definitions can be added to a 
>>> Service too.  Since the Service is provided by the platform, I assume it 
>>> already comes with operations predefined.
>> 
>> Yes, the service provider owns services that are provided by the Platform, 
>> and can extend them, where users may not. However, a user may register 
>> his/her own Services within the context of a given tenant account, and those 
>> can be extended and managed. In that case, you can actually connect 
>> Operations to Services as a tenant. So this is really a question of what 
>> scope the Service belongs to.
>> 
>>> 6. Operations. A descriptor should exist that can be used for registration 
>>> of the deployed assembly into a catalog.  The descriptor should contain 
>>> basic information about the exposed functional API and management API (e.g. 
>>> Operations too).  
>> 
>> An Assembly is a running group of cloud resources (a whole networked 
>> application
> 
> Or a part of one.
> 
>> ). A listing of those is exposed through the Assemblies resource.
>> 
>> A Plan is a rubber stamp for producing new Assemblies, and can also be 
>> listed through the Plans resource. Any plan can be easily converted to an 
>> Assembly with an API call.
>> 
>> Were you thinking that we should have a catalog beyond these listings? 
>> Please elaborate on what you have in mind. I agree that 

Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing "request identification"

[Takahiro Shida]

Hi all,

I'm also interested in this issue.

> Create a unified request identifier
> https://blueprints.launchpad.net/nova/+spec/cross-service-request-id

I checked this BP and the following review.
https://review.openstack.org/#/c/29480/

There are many comments. Finally, this review looks rejected by "user
specified correlation-id" is useless and insecure.

>> 3. Enable keystone to generate "request identification" (we can call it
'request-token', for example).
> -2

So, this idea will be helpful to solve the "cross-service-request-id"
problem.
Because the correlation-id specified by keystone.

How about nova guys and keystone guys ?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev