date:20131212

On 12/11/2013 11:08 PM, Bryan D. Payne wrote:
 We can involve people in security reviews without having them on the
 core review team.  They are separate concerns.
 
 
 Yes, but those people can't ultimately approve the patch.  So you'd need
 to have a security reviewer do their review, and then someone who isn't
 a security person be able to offer the +1/+2 based on the opinion of the
 security reviewer.  This doesn't make any sense to me.  You're involving
 an extra person needlessly, and creating extra work.

I don't want someone not regularly looking at changes going into the
code able to do the ultimate approval of any patch.  I think this is
working as designed.  Including the extra person in this case is a good
thing.

 
  
 
 This has been discussed quite a bit.  We can't handle security patches
 on gerrit right now while they are embargoed because we can't completely
 hide them.
 
 
 I think that you're confusing security reviews of new code changes with
 reviews of fixes to security problems.  In this part of my email, I'm
 talking about the former.  These are not embargoed.  They are just the
 everyday improvements to the system.  That is the best time to identify
 and gate on security issues.  Without someone on core that can give a -2
 when there's a problem, this will basically never happen.  Then we'll be
 back to fixing a greater number of things as bugs.

Anyone can offer a -1, and that will be paid attention to.  If that ever
doesn't happen, let's talk about 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] [TripleO] Tuskar CLI after architecture changes

2013-12-12 Thread Ladislav Smola


Agree with this.

Though I am an optimist,  I believe that this time, we can avoid calling 
multiple services in one request that depend on each other.
About the multiple users at once, this should be solved inside the API 
calls of the services.


So I think we should forbid building these complex API calls composites 
in the Tuskar-API. If we will want something like this, we should implement
it properly inside the services itself. If we will not be able to 
convince the community about it, maybe it's just not that good feature. :-D


Ladislav

On 12/12/2013 02:35 PM, Jiří Stránský wrote:

On 12.12.2013 14:26, Jiří Stránský wrote:

On 12.12.2013 11:49, Radomir Dopieralski wrote:

On 11/12/13 13:33, Jiří Stránský wrote:

[snip]

TL;DR: I believe that As an infrastructure administrator, Anna 
wants a
CLI for managing the deployment providing the same fundamental 
features
as UI. With the planned architecture changes (making tuskar-api 
thinner

and getting rid of proxying to other services), there's not an obvious
way to achieve that. We need to figure this out. I present a few 
options

and look forward for feedback.


[snip]

2) Make a thicker tuskar-api and put the business logic there. 
(This is
the original approach with consuming other services from 
tuskar-api. The

feedback on this approach was mostly negative though.)


This is a very simple issue, actualy. We don't have any choice. We need
locks. We can't make the UI, CLI and API behave in consistent and
predictable manner when multiple people (and cron jobs on top of that)
are using them, if we don't have locks for the more complex operations.
And in order to have locks, we need to have a single point where the
locks are applied. We can't have it on the client side, or in the UI --
it has to be a single, shared place. It has to be Tuskar-API, and I
really don't see any other option.



You're right that we should strive for atomicity, but I'm afraid putting
the complex operations (which call other services) into tuskar-api will
not solve the problem for us. (Jay and Ladislav already discussed the
issue.)

If we have to do multiple API calls to perform a complex action, then
we're in the same old situation. Should i get back to the rack creation
example that Ladislav posted, it could still happen that Tuskar API
would return error to the UI like: We haven't created the rack in
Tuskar because we tried to modifiy info about 8 nodes in Ironic, but
only 5 modifications succeeded. So we've tried to revert those 5
modifications but we only managed to revert 2. Please figure this out
and come back. We moved the problem, but didn't solve it.

I think that if we need something to be atomic, we'll need to make sure
that one operation only writes to one service, where the single
source of truth for that data lies, and make sure that the operation is
atomic within that service. (See Ladislav's example with overcloud
deployment via Heat in this thread.)

Thanks :)

Jirka



And just to make it clear how that relates to locking: Even if i can 
lock something within Tuskar API, i cannot lock the related data 
(which i need to use in the complex operation) in the other API (say 
Ironic). Things can still change under Tuskar API's hands. Again, we 
just move the unpredictability, but not remove it.


Jirka

___
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] [Oslo] First steps towards amqp 1.0

2013-12-12 Thread Flavio Percoco


On 11/12/13 09:31 -0500, Andrew Laski wrote:

On 12/10/13 at 11:09am, Flavio Percoco wrote:

On 09/12/13 17:37 -0500, Russell Bryant wrote:

On 12/09/2013 05:16 PM, Gordon Sim wrote:

On 12/09/2013 07:15 PM, Russell Bryant wrote:


[...]


One other pattern that can benefit from intermediated message flow is in
load balancing. If the processing entities are effectively 'pulling'
messages, this can more naturally balance the load according to capacity
than when the producer of the workload is trying to determine the best
balance.


Yes, that's another factor.  Today, we rely on the message broker's
behavior to equally distribute messages to a set of consumers.


Sometimes you even _want_ message distribution to be 'unequal', if the
load varies by message or the capacity by consumer. E.g. If one consumer
is particularly slow (or is given a particularly arduous task), it may
not be optimal for it to receive the same portion of subsequent messages
as other less heavily loaded or more powerful consumers.


Indeed.  We haven't tried to do that anywhere, but it would be an
improvement for some cases.


Agreed, this is something that worths experimenting.

[...]


I'm very interested in diving deeper into how Dispatch would fit into
the various ways OpenStack is using messaging today.  I'd like to get
a better handle on how the use of Dispatch as an intermediary would
scale out for a deployment that consists of 10s of thousands of
compute nodes, for example.

Is it roughly just that you can have a network of N Dispatch routers
that route messages from point A to point B, and for notifications we
would use a traditional message broker (qpidd or rabbitmq) ?


For scaling the basic idea is that not all connections are made to the
same process and therefore not all messages need to travel through a
single intermediary process.

So for N different routers, each have a portion of the total number of
publishers and consumers connected to them. Though client can
communicate even if they are not connected to the same router, each
router only needs to handle the messages sent by the publishers directly
attached, or sent to the consumer directly attached. It never needs to
see messages between publishers and consumer that are not directly
attached.

To address your example, the 10s of thousands of compute nodes would be
spread across N routers. Assuming these were all interconnected, a
message from the scheduler would only travel through at most two of
these N routers (the one the scheduler was connected to and the one the
receiving compute node was connected to). No process needs to be able to
handle 10s of thousands of connections itself (as contrasted with full
direct, non-intermediated communication, where the scheduler would need
to manage connections to each of the compute nodes).

This basic pattern is the same as networks of brokers, but Dispatch
router has been designed from the start to simply focus on that problem
(and not deal with all other broker related features, such as
transactions, durability, specialised queueing etc).


Soudns awesome.  :-)


The other difference is that Dispatch Router does not accept
responsibility for messages, i.e. it does not offer any
store-and-forward behaviour. Any acknowledgement is end-to-end. This
avoids it having to replicate messages. On failure they can if needed by
replayed by the original sender.


I think the lack of store-and-forward is OK.

Right now, all of the Nova code is written to assume that the messaging
is unreliable and that any message could get lost.  It may result in an
operation failing, but it should fail gracefully.  Doing end-to-end
acknowledgement may actually be an improvement.


This is interesting and a very important point. I wonder what the
reliability expectations of other services w.r.t OpenStack messaging
are.

I agree on the fact that p2p acknowledgement could be an improvement
but I'm also wondering how this (if ever) will affect projects - in
terms of requiring changes. One of the goals of this new driver is to
not require any changes on the existing projects.

Also, a bit different but related topic, are there cases where tasks
are re-scheduled in nova? If so, what does nova do in this case? Are
those task sent back to `nova-scheduler` for re-scheduling?


Yes, there are certain build failures that can occur which will cause 
a re-schedule.  That's currently accomplished by the compute node 
sending a message back to the scheduler so it can pick a new host.  
I'm trying to shift that a bit so we're messaging the conductor rather 
than the scheduler, but the basic structure of it is going to remain 
the same for now.


If you mean in progress operations being restarted after a service is 
restarted, then no.  We're working towards making that possible but at 
the moment it doesn't exist.



This is very valuable information. I wonder if the same applies for
other projects. I'd expect cinder to behave pretty much the same way
nova does in

Re: [openstack-dev] OpenStack Icehouse milestone 1 packages for Ubuntu

2013-12-12 Thread Martinx - ジェームズ

AWESOME! Do you know if we can start testing IPv6 tenants networks?

Tks!

On 12 December 2013 07:38, James Page james.p...@ubuntu.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi All

 As OpenStack Icehouse milestone 1 is now out, I thought it worth
 updating everyone on Ubuntu activities during the Icehouse development
 cycle.

 For release, Ubuntu will be providing Icehouse packages for both
 Ubuntu 14.04 and for Ubuntu 12.04 via the Ubuntu Cloud Archive (see
 [0]).  Right now, icehouse-1 can be tested either using the current
 Ubuntu development release (trusty) or using the icehouse-proposed
 pocket in the Cloud Archive for Ubuntu 12.04, which can be enabled on
 Ubuntu 12.04 systems by running:

  sudo add-apt-repository cloud-archive:icehouse-proposed

 The packages are currently a straight refresh of the Havana packages
 with any mandatory changes for Icehouse; expect more changes between
 now and Icehouse milestone 2, including switching to the ML2 plugin in
 Neutron as default and some re-jigging of the nova-compute-* packages
 to make installs for off-host non-libvirt hypervisors a little easier
 (see [1]).

 You can report any bugs on these packages on 12.04 and trusty using
 the ‘ubuntu-bug’ tool, for example:

 ubuntu-bug neutron-server

 Other notable upgrades alongside Icehouse include new versions of qemu
 (1.7.x), Ceph (0.72.x) and Open vSwitch (2.0.x).  If you are using
 Ubuntu trusty, you won’t need to use the openvswitch-datapath-dkms
 package any longer - the 3.12 kernel currently shipping supports both
 GRE and VXLAN overlay networking via the in-tree openvswitch kernel
 module.

 In addition to the milestone packaging that the Ubuntu Server team
 pushes to the development release and the Cloud Archive, you can
 always test with the latest trunk build packages and dependencies
 using the OpenStack Ubuntu Testing PPA:

 sudo add-apt-repository ppa:openstack-ubuntu-testing/icehouse

 This PPA publishes packages for 12.04 and trusty as well.  They are
 bleeding edge so may not always work - but hey - some folks like to
 live on the edge!

 Enjoy and happy testing!

 James (on behalf of the Ubuntu Server Team)

 - --
 James Page
 Technical Lead, Ubuntu Server Team

 [0] http://wiki.ubuntu.com/ServerTeam/CloudArchive
 [1]
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1311-openstack
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSqYQTAAoJEL/srsug59jDYzIP/2pN6Xs8dh0phrwXnaB3mHBM
 48H6aoM4BRscTApYFscQO6aWNz+z0nSJhTI72YaRJOulKPgHtYlJgp7hTPOUPbLs
 Qwo6QrsuSlmvgchBlFmYTWw3iAg2SX0Wz0UPFjWcg4Ru/qK+4+j8xkIonErO0Lnp
 KVGi43nL4DtvJs4ji2+wnGV4op7ETLENbSzQJRD+cenUkawTp5Y5xamn+fxo9Vzq
 I82/I5SYW6brUjGo3FbxxepHKwFnWjy/i4YiLa/GqjoRQ+cDY+Ayo3aFJN5J6VV8
 XaxRJk3/Yf7nSaAGEbhr2J9r/3+ztafviSEoJMiTPrUMyieN57ihhnvGKLeVwuuS
 QlAnNzgrhOwZf+sjdGgcbLml1d9Vto6G1+j79i/y0OE+Ke7EYxod8IToAELfrgNo
 VPww0zfTgs1Ip224quGylrtWEdnG+f9awtj/fKU0qqECQ+/6igQPnaAvCI19KN+N
 LJMN40yQeswcLW2VJ4PYRo3ZW/BKzB8IEq5H7Sdcl2jqSckjbCjnyLt6MwiIz6b2
 XXNR/wHM1dWyWwmhAB7vLbo1+A4CMCBIW4LhS/CC7WEfnyYTAzosuuWrb+KQv+77
 69e2Ir5CbdGEigea8XO+lPtgrzoBejyRrPBCVoGJZSUaMqQjmkh7k6WTpqwCOe7H
 3pnhE0lJD5QBkAUk/XwG
 =fRXG
 -END PGP SIGNATURE-

 ___
 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] [TripleO] Tuskar CLI after architecture changes

2013-12-12 Thread Hugh O. Brock

On Thu, Dec 12, 2013 at 03:11:14PM +0100, Ladislav Smola wrote:
 Agree with this.
 
 Though I am an optimist,  I believe that this time, we can avoid
 calling multiple services in one request that depend on each other.
 About the multiple users at once, this should be solved inside the
 API calls of the services.
 
 So I think we should forbid building these complex API calls
 composites in the Tuskar-API. If we will want something like this,
 we should implement
 it properly inside the services itself. If we will not be able to
 convince the community about it, maybe it's just not that good
 feature. :-D
 

It's worth adding that in the particular case Radomir sites (the
Deploy button), even with all the locks in the world, the resources
that we have supposedly requisitioned in the undercloud for the user may
have already been allocated to someone else by Nova -- because Nova
currently doesn't allow reservation of resources. (There is work under
way to allow this but it is quite a way off.) So we could find ourselves
claiming for the user that we're going to deploy an overcloud at a
certain scale and then find ourselves unable to do so.

Frankly I think the whole multi-user case for Tuskar is far enough off
that I would consider wrapping a single-login restriction around the
entire thing and calling it a day... except that that would be
crazy. I'm just trying to make the point that making these operations
really safe for multiple users is way harder than just putting a lock on
the tuskar API.

--H

 
 On 12/12/2013 02:35 PM, Jiří Stránský wrote:
 On 12.12.2013 14:26, Jiří Stránský wrote:
 On 12.12.2013 11:49, Radomir Dopieralski wrote:
 On 11/12/13 13:33, Jiří Stránský wrote:
 
 [snip]
 
 TL;DR: I believe that As an infrastructure administrator,
 Anna wants a
 CLI for managing the deployment providing the same
 fundamental features
 as UI. With the planned architecture changes (making
 tuskar-api thinner
 and getting rid of proxying to other services), there's not an obvious
 way to achieve that. We need to figure this out. I present a
 few options
 and look forward for feedback.
 
 [snip]
 
 2) Make a thicker tuskar-api and put the business logic
 there. (This is
 the original approach with consuming other services from
 tuskar-api. The
 feedback on this approach was mostly negative though.)
 
 This is a very simple issue, actualy. We don't have any choice. We need
 locks. We can't make the UI, CLI and API behave in consistent and
 predictable manner when multiple people (and cron jobs on top of that)
 are using them, if we don't have locks for the more complex operations.
 And in order to have locks, we need to have a single point where the
 locks are applied. We can't have it on the client side, or in the UI --
 it has to be a single, shared place. It has to be Tuskar-API, and I
 really don't see any other option.
 
 
 You're right that we should strive for atomicity, but I'm afraid putting
 the complex operations (which call other services) into tuskar-api will
 not solve the problem for us. (Jay and Ladislav already discussed the
 issue.)
 
 If we have to do multiple API calls to perform a complex action, then
 we're in the same old situation. Should i get back to the rack creation
 example that Ladislav posted, it could still happen that Tuskar API
 would return error to the UI like: We haven't created the rack in
 Tuskar because we tried to modifiy info about 8 nodes in Ironic, but
 only 5 modifications succeeded. So we've tried to revert those 5
 modifications but we only managed to revert 2. Please figure this out
 and come back. We moved the problem, but didn't solve it.
 
 I think that if we need something to be atomic, we'll need to make sure
 that one operation only writes to one service, where the single
 source of truth for that data lies, and make sure that the operation is
 atomic within that service. (See Ladislav's example with overcloud
 deployment via Heat in this thread.)
 
 Thanks :)
 
 Jirka
 
 
 And just to make it clear how that relates to locking: Even if i
 can lock something within Tuskar API, i cannot lock the related
 data (which i need to use in the complex operation) in the other
 API (say Ironic). Things can still change under Tuskar API's
 hands. Again, we just move the unpredictability, but not remove
 it.
 
 Jirka
 
 ___
 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

-- 
== Hugh Brock, hbr...@redhat.com   ==
== Senior Engineering Manager, Cloud Engineering   ==
== Tuskar: Elastic Scaling for OpenStack   ==
== http://github.com/tuskar==

I know that you

[openstack-dev] [Nova] All I want for Christmas is one more +2 ...

2013-12-12 Thread Day, Phil

Hi Cores,

The Stop, Rescue, and Delete should give guest a chance to shutdown change 
https://review.openstack.org/#/c/35303/ was approved a couple of days ago, but 
failed to merge because the RPC version had moved on.   Its rebased and sitting 
there with one +2 and a bunch of +1s  -would be really nice if it could land 
before it needs another rebase please ?

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

[openstack-dev] Announcing Fuel

2013-12-12 Thread Mike Scherbakov

Folks,

Most of you by now have heard of Fuel, which we’ve been working on as a
related OpenStack project for a period of time -
https://github.com/stackforge/fuel-mainsee https://launchpad.net/fuel and
https://wiki.openstack.org/wiki/Fuel. The aim of the project is to provide
a distribution agnostic and plug-in agnostic engine for preparing,
configuring and ultimately deploying various “flavors” of OpenStack in
production. We’ve also used Fuel in most of our customer engagements to
stand up an OpenStack cloud.

 At the same time, we’ve been actively involved with TripleO, which we
believe to be a great effort in simplifying deployment, operations, scaling
(and eventually upgrading) of OpenStack.

Per our discussions with core TripleO team during the Icehouse summit,
we’ve uncovered that while there are certain areas of collision, most of
the functionality in TripleO and Fuel is complementary. In general, Fuel
helps solve many problems around “step zero” of setting up an OpenStack
environment, such as auto-discovery and inventory of bare metal hardware,
pre-deployment  post-deployment environment  checks, and wizard-driven
web-based configuration of OpenStack flavors. At the same time, TripleO has
made great progress in deployment, scaling and operations (with Tuskar).

We’d like to propose an effort for community consideration to bring the two
initiatives closer together to eventually arrive at a distribution
agnostic, community supported framework covering the entire spectrum of
deployment, management and upgrades; from “step zero” to a fully functional
and manageable production-grade OpenStack environment.

To that effect, we propose the following high-level roadmap plans for this
effort:


   -

   Keep and continue to evolve bare-metal discovery and inventory module of
   Fuel, tightly integrating it with Ironic.
   -

   Keep and continue to evolve Fuel’s wizard-driven OpenStack flavor
   configurator. In the near term we’ll work with the UX team to unify the
   user experience across Fuel, TripleO and Tuskar. We are also thinking about
   leveraging diskimagebuilder.
   -

   Continue to evolve Fuel’s pre-deployment (DHCP, L2 connectivity checks)
   and post-deployment validation checks in collaboration with the TripleO and
   Tempest teams.
   -

   Eventually replace Fuel’s current orchestration engine
   https://github.com/stackforge/fuel-astute/ with Heat


We’d love to open discussion on this and hear everybody’s thoughts on this
direction.

-- 
Mike Scherbakov
Fuel Engineering Lead
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] State of the Gate - Dec 12

2013-12-12 Thread Anita Kuno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/2013 08:20 AM, Sean Dague wrote:
Current Gate Length: 12hrs*, 41 deep

(top of gate entered 12hrs ago)

It's been an *exciting* week this week. For people not paying
attention we had 2 external events which made things terrible
earlier in the week.

== Event 1: sphinx 1.2 complete breakage -
MOSTLY RESOLVED ==

It turns out sphinx 1.2 + distutils (which pbr magic call through)
means total sadness. The fix for this was a requirements pin to
sphinx 1.2, and until a project has taken that they will fail in
the gate.

It also turns out that tox installs pre-released software by
default (a terrible default behavior), so you also need a tox.ini
change like this -
https://github.com/openstack/nova/blob/master/tox.ini#L9 otherwise
local users will install things like sphinx 1.2b3. They will also
break in other ways.

Not all projects have merged this. If you are a project that
hasn't, please don't send any other jobs to the gate until you do.
A lot of delay was added to the gate yesterday by Glance patches
being pushed to the gate before their doc jobs were done.

== Event 2: apt.puppetlabs.com outage -
RESOLVED ==

We use that apt repository to setup the devstack nodes in nodepool
with puppet. We were triggering an issue with grenade where it's
apt-get calls were failing, because it does apt-get update once to
make sure life is good. This only triggered in grenade (noth other
devstack runs) because we do set -o errexit aggressively.

A fix in grenade to ignore these errors was merged yesterday
afternoon (the purple line -
http://status.openstack.org/elastic-recheck/ you can see where it
showed up).

== Top Gate Bugs
==

We normally do this as a list, and you can see the whole list here
- http://status.openstack.org/elastic-recheck/ (now sorted by
number of FAILURES in the last 2 weeks)

That being said, our bigs race bug is currently this one bug -
https://bugs.launchpad.net/tempest/+bug/1253896 - and if you want
to merge patches, fixing that one bug will be huge.

Basically, you can't ssh into guests that get created. That's sort
of a fundamental property of a cloud. It shows up more frequently
on neutron jobs, possibly due to actually testing the metadata
server path. There have been many attempts on retry logic on this,
we actually retry for 196 seconds to get in and only fail once we
can't get in, so waiting isn't helping. It doesn't seem like the
env is under that much load.

Until we resolve this, life will not be good in landing patches.

-Sean

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

Thanks Sean:

This is a terrific summary which really makes my task of confirming
and following up much more manageable.

Just by way of preempting the its neutron's fault pile-on, just in
case anyone is tempted, a few facts:

We were paying attention, as it happens to the sphinx pin. Patches to
neutron and neutronclient have merged:
http://git.openstack.org/cgit/openstack/neutron/tree/test-requirements.txt#n9
http://git.openstack.org/cgit/openstack/python-neutronclient/tree/test-requirements.txt#n9

The addition of the -U flag for pip install in tox.ini for
neutronclient https://review.openstack.org/#/c/60825/4 is in the check
queue, it tripped on the sphinx pin for neutronclient. Here is the one
for neutron: https://review.openstack.org/#/c/60825/4 I've just
alerted all neutron-core to refrain from +A'ing until these are merged.

We had been tracking 1253896 quite closely and I at least was working
wtih the belief we had done the work we needed to do for that bug.
Since it now comes to light that I am in error with regards to
neutron's responsibility to 1253896, I welcome all interested parties
to #openstack-neutron so that we can again work together to submit a
patch that addresses this issue.

Thanks Sean,
Anita.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSqcpnAAoJELmKyZugNFU0X40H/0GX6zpTEdyQJVgDLDmOlo7v
X5W3ioRfjQL28Rm+ISAoq/CTHuekggimhIsTz/TIJpYeS+657Bg+rPE2BE4S6Aag
IdyMOQcMVfjUxcit9UTssMueSsw7VcnLJSbi7hEcBAtIRkf6IA2gxZ/lvrx7VmD5
Odfg3mdUrnckVdv7Y6/7tWCMY+3sXuqLQwat3a83mP13jRjgbQw9QnVhib9yoHg3
+qJnDoH9BT3+PWig42u7893qaasCzqFiiyjlGnjg9YznrRRZvq0Szwqux/JgzWy4
ypmX5Xo4ueZGuLMpmb2Sb8RbE83q3u9nx15nTWFdC+IUxa12DnX1sid27YCDva4=
=oVW8
-END PGP SIGNATURE-

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

Re: [openstack-dev] What's Up Doc? Dec 11 2013

2013-12-12 Thread Anne Gentle

On Wed, Dec 11, 2013 at 5:31 PM, Anne Gentle a...@openstack.org wrote:

 Thanks to new doc patchers Shilla Saebi and Thomas Herve for their clean
 up work, especially for the Identity API docs and Heat install!

 Be ready for 12/20/13 Doc Bug Day! Looking forward to it.

 1. In review and merged this past week:

 The Install Guide is still the most worked-on document. I'd like to shift
 from that now that we're past milestone-1 and work harder on the Cloud
 Administrator Guide and Operations Guide, to separate out items from the
 Configuration Reference that are how to and move them to the Cloud
 Administrator Guide. Nermina made progress on the Cloud Administrator Guide
 additions from the Configuration Reference, her analysis is here:
 http://lists.openstack.org/pipermail/openstack-docs/2013-December/003459.html

 Lana Brindley was in Texas this week, and she's going to take on
 maintenance of the User Guide and Admin User Guide with some additions of
 scripts that are common user/admin user tasks with CLIs. She's also looking
 into our processes and reviews and making good strides towards bringing in
 developer teams for reviews after they use the DocImpact flag. Thanks Lana!

 2. High priority doc work:

 To me, one high priority is to get the config options done for milestone 1
 release.

 Another priority is for me to write a content spec for each book that we
 currently maintain, so that incoming projects can easily plug in to each
 deliverable. If I had to write a short description of each book, it'd be:

 Installation Guide - Describes a manual install process for multiple
 distributions including CentOS, Debian, Fedora, OpenSUSE, RedHat Enterprise
 Linux, SUSE Enterprise Linux, and Ubuntu.

 Configuration Reference - Contains a reference listing of all
 configuration options for core and integrated OpenStack services.

 Cloud Administrator Guide - Contains how-to information for managing an
 OpenStack cloud as needed for your use cases, described in this document.

 High Availability Guide - Describes potential strategies for making your
 OpenStack services and related controllers and data stores highly available.

 Operations Guide - Offers information for designing and operating
 OpenStack private or public clouds plus best practices for day-to-day
 operations.

 Security Guide - Provide best practices and conceptual information about
 securing an OpenStack cloud

 Virtual Machine Image Guide - Shows you how to obtain, create, and modify
 virtual machine images that are compatible with OpenStack.
 End User Guide - Shows OpenStack end users how to create and manage
 resources in an OpenStack cloud with the OpenStack dashboard and OpenStack
 client commands.

 Admin User Guide - Shows OpenStack admin users how to create and manage
 resources in an OpenStack cloud with the OpenStack dashboard and OpenStack
 client commands.

 API Quick Start - A brief overview of how to send requests to endpoints
 for OpenStack services.

 I'd like for projects to understand what goes where and be able to write
 sections that fit into these titles. I'm not recommending that you create
 your own title, but understand where your section can go in the wider
 picture of OpenStack docs.

 3. Doc work going on that I know of:

 See below for the developmental edit of the O'Reilly edition of the
 Operations Guide.

 Shaun's working on the autodoc for configuration option tables for the
 icehouse-1 milestone.

 4. New incoming doc requests:

 The Triple-O team would like to talk about how to plug into the OpenStack
 existing docs. Feel free to reach out on details, while we are going to
 stick with the manual install for this release (Icehouse), perhaps the
 Triple-O team can get a head start. Open to ideas after hearing from them
 in the weekly project meeting.

 5. Doc tools updates:

I left out an important update for doc tools -- Sphinx 1.2 was just
released and it is incompatible with distutils in python 2.7. This means
that all projects need to fix their doc builds either by subscribing to
openstack/requirements which already has the correct version of Sphinx
pinned, or by pinning sphinx=1.1.2,1.2 in your own requirements file. See
the thread on openstack-dev at
http://lists.openstack.org/pipermail/openstack-dev/2013-December/021863.htmlor
ask a friendly infrastructure dev for help.
Anne


  The infra team is working on ways to version and deploy the
 clouddocs-maven-plugin (wow, that's verbing a noun).

 6. Other doc news:

 The development edit for the Operations Guide from O'Reilly has begun, and
 by tomorrow we should have input on a few more chapters. Here are some
 overarching comments from Brian Anderson you may like to help us dig into:

 ---

 - an expanded Preface which situates the Operations Guide in relation to
 other, related guides (like the Admin guide you mentioned). A taxonomy of
 user roles would be helpful here.
 - an introductory chapter about OpenStack, showing, in particular, a
 high-level

Re: [openstack-dev] [Nova] All I want for Christmas is one more +2 ...

On 12/12/2013 09:22 AM, Day, Phil wrote:
 Hi Cores,
 
  
 
 The “Stop, Rescue, and Delete should give guest a chance to shutdown”
 change https://review.openstack.org/#/c/35303/ was approved a couple of
 days ago, but failed to merge because the RPC version had moved on.  
 Its rebased and sitting there with one +2 and a bunch of +1s  -would be
 really nice if it could land before it needs another rebase please ?

Approved.

FWIW, I'm fine with folks approving with a single +2 for cases where a
patch is approved but needed a simple rebase.  This happens pretty
often.  We even have a script that generates a list of patches still
open that were previously approved:

http://russellbryant.net/openstack-stats/nova-openapproved.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] [keystone] domain admin role query

2013-12-12 Thread Adam Young


On 12/11/2013 10:11 PM, Paul Belanger wrote:

On 13-12-11 11:18 AM, Lyle, David wrote:

+1 on moving the domain admin role rules to the default policy.json

-David Lyle

From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, December 11, 2013 9:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] domain admin role query


On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox 
jamielen...@redhat.com wrote:
Using the default policies it will simply check for the admin role 
and not care about the domain that admin is limited to. This is 
partially a left over from the V2 api when there wasn't domains to 
worry  about.


A better example of policies are in the file 
etc/policy.v3cloudsample.json. In there you will see the rule for 
create_project is:


 identity:create_project: rule:admin_required and 
domain_id:%(project.domain_id)s,


as opposed to (in policy.json):

 identity:create_project: rule:admin_required,

This is what you are looking for to scope the admin role to a domain.

We need to start moving the rules from policy.v3cloudsample.json to 
the default policy.json =)



Jamie

- Original Message -

From: Ravi Chunduru ravi...@gmail.com
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.org

Sent: Wednesday, 11 December, 2013 11:23:15 AM
Subject: [openstack-dev] [keystone] domain admin role query

Hi,
I am trying out Keystone V3 APIs and domains.
I created an domain, created a project in that domain, created an 
user in

that domain and project.
Next, gave an admin role for that user in that domain.

I am assuming that user is now admin to that domain.
Now, I got a scoped token with that user, domain and project. With that
token, I tried to create a new project in that domain. It worked.

But, using the same token, I could also create a new project in a 
'default'
domain too. I expected it should throw authentication error. Is it a 
bug?


Thanks,
--
Ravi



One of the issues I had this week while using the 
policy.v3cloudsample.json was I had no easy way of creating a domain 
with the id of 'admin_domain_id'.  I basically had to modify the SQL 
directly to do it.
You should not have to edit the SQL.  You should be able, at a minimum, 
to re-enable the ADMIN_TOKEN in the config file to create any object 
inside of Keystone.


 open a bug for the problem, and describe what you did step by step?



Any chance we can create a 2nd domain using 'admin_domain_id' via 
keystone-manage sync_db?





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

Re: [openstack-dev] State of the Gate - Dec 12

2013-12-12 Thread Steven Hardy

On Thu, Dec 12, 2013 at 08:20:09AM -0500, Sean Dague wrote:
 Current Gate Length: 12hrs*, 41 deep
 
 (top of gate entered 12hrs ago)
 
 It's been an *exciting* week this week. For people not paying attention
 we had 2 external events which made things terrible earlier in the week.
 
 ==
 Event 1: sphinx 1.2 complete breakage - MOSTLY RESOLVED
 ==
 
 It turns out sphinx 1.2 + distutils (which pbr magic call through) means
 total sadness. The fix for this was a requirements pin to sphinx  1.2,
 and until a project has taken that they will fail in the gate.

Additional info, bug reference is below (took me a while to find it..):

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

 It also turns out that tox installs pre-released software by default (a
 terrible default behavior), so you also need a tox.ini change like this
 - https://github.com/openstack/nova/blob/master/tox.ini#L9 otherwise
 local users will install things like sphinx 1.2b3. They will also break
 in other ways.

What's the bug # for this one?

 Not all projects have merged this. If you are a project that hasn't,
 please don't send any other jobs to the gate until you do. A lot of
 delay was added to the gate yesterday by Glance patches being pushed to
 the gate before their doc jobs were done.

Note to Heat devs, we are impacted by this, we need to nurse this through
the gate, so please don't approve anything until it lands:

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

Steve

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

Re: [openstack-dev] State of the Gate - Dec 12

2013-12-12 Thread Anita Kuno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/2013 09:39 AM, Anita Kuno wrote:
On 12/12/2013 08:20 AM, Sean Dague wrote:
Current Gate Length: 12hrs*, 41 deep

(top of gate entered 12hrs ago)

It's been an *exciting* week this week. For people not paying
attention we had 2 external events which made things terrible
earlier in the week.

== Event 1: sphinx 1.2 complete breakage
- MOSTLY RESOLVED ==

It turns out sphinx 1.2 + distutils (which pbr magic call
through) means total sadness. The fix for this was a requirements
pin to sphinx 1.2, and until a project has taken that they will
fail in the gate.

It also turns out that tox installs pre-released software by
default (a terrible default behavior), so you also need a
tox.ini change like this -
https://github.com/openstack/nova/blob/master/tox.ini#L9
otherwise local users will install things like sphinx 1.2b3. They
will also break in other ways.

Not all projects have merged this. If you are a project that
hasn't, please don't send any other jobs to the gate until you
do. A lot of delay was added to the gate yesterday by Glance
patches being pushed to the gate before their doc jobs were
done.

== Event 2: apt.puppetlabs.com outage -
RESOLVED ==

We use that apt repository to setup the devstack nodes in
nodepool with puppet. We were triggering an issue with grenade
where it's apt-get calls were failing, because it does apt-get
update once to make sure life is good. This only triggered in
grenade (noth other devstack runs) because we do set -o errexit
aggressively.

A fix in grenade to ignore these errors was merged yesterday
afternoon (the purple line -
http://status.openstack.org/elastic-recheck/ you can see where
it showed up).

== Top Gate Bugs
==

We normally do this as a list, and you can see the whole list
here - http://status.openstack.org/elastic-recheck/ (now sorted
by number of FAILURES in the last 2 weeks)

That being said, our bigs race bug is currently this one bug -
https://bugs.launchpad.net/tempest/+bug/1253896 - and if you
want to merge patches, fixing that one bug will be huge.

Basically, you can't ssh into guests that get created. That's
sort of a fundamental property of a cloud. It shows up more
frequently on neutron jobs, possibly due to actually testing the
metadata server path. There have been many attempts on retry
logic on this, we actually retry for 196 seconds to get in and
only fail once we can't get in, so waiting isn't helping. It
doesn't seem like the env is under that much load.

Until we resolve this, life will not be good in landing patches.

-Sean

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

Thanks Sean:

This is a terrific summary which really makes my task of
confirming and following up much more manageable.

Just by way of preempting the its neutron's fault pile-on, just
in case anyone is tempted, a few facts:

We were paying attention, as it happens to the sphinx pin. Patches
to neutron and neutronclient have merged:
http://git.openstack.org/cgit/openstack/neutron/tree/test-requirements.txt#n9

http://git.openstack.org/cgit/openstack/python-neutronclient/tree/test-requirements.txt#n9

A post to the mailing list isn't complete it appears unless I make a
mistake in it.
Here is our patch for neutronclient:
https://review.openstack.org/#/c/61508/

The addition of the -U flag for pip install in tox.ini for
neutronclient https://review.openstack.org/#/c/60825/4 is in the
check queue, it tripped on the sphinx pin for neutronclient. Here
is the one for neutron: https://review.openstack.org/#/c/60825/4
I've just alerted all neutron-core to refrain from +A'ing until
these are merged.

We had been tracking 1253896 quite closely and I at least was
working wtih the belief we had done the work we needed to do for
that bug. Since it now comes to light that I am in error with
regards to neutron's responsibility to 1253896, I welcome all
interested parties to #openstack-neutron so that we can again work
together to submit a patch that addresses this issue.

Thanks Sean, Anita.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSqdRnAAoJELmKyZugNFU0H80IAMnjI4r3ulePeZ3eenAwOYlY
TEC6hAClr374oq1B7Tk3JYP0dl+qMed7TaCSYI32wB9sVbYKsjKrjsNXARDpqqUe
r1Mb05jknDZtwfwBYNsoPtsn/sf9mtXm8T+Czk7ojMVogwjng8ps4juyG4ZveUNl
+zDkPtFgoWrzKA/pmUIfue5RgaH0MfX14ftojUmSroYfTuMK5fxSPc9mhV//2ZBw
JyNowczOdhOVf4pBZ7JFDDd1potoi+CtrOHxW13aUC5XyPLN/HU3ZoZRoWVeLzDT
FWgHgWo1DoK49+R12KsjzX0xhUVs2YV3oVrraPnXsMSqiWzWOU1xNglGwa6qWdg=
=PIFo
-END PGP SIGNATURE-

Re: [openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?

2013-12-12 Thread Doug Hellmann

Ok, that sounds like it would do what you want. Thanks for clarifying. :-)

Doug


On Thu, Dec 12, 2013 at 4:06 AM, Nadya Privalova nprival...@mirantis.comwrote:

 Doug,

 Sorry for confusing you with 'local' term. I meant that collector is up on
 the node which is one of the Galera-nodes. Data will be replicated and all
 the Galera nodes will be synced.

 Nadya


 On Thu, Dec 12, 2013 at 2:01 AM, Doug Hellmann 
 doug.hellm...@dreamhost.com wrote:




 On Tue, Dec 10, 2013 at 9:47 AM, Nadya Privalova nprival...@mirantis.com
  wrote:

 Julien,

 Yes, I use the same SQL for Nova and Ceilometer. Thanks for pointing
 this out. My bad, I didn't take it into account. So if we want to use
 Ceilometer + MySQL in production (in theory :) ) we need to use separate
 controllers with Ceilometer's MySQL only. And each controller may run it's
 own collector which will write data into local MySQL. Am I right that
 only one instance of central-agent may be started (WIP
 https://wiki.openstack.org/wiki/Ceilometer/blueprints/tasks-distribution)?
 Please Julien correct me if I'm wrong. And maybe Ceilometer has
 recommendations for production deployment and I just missed it?


 You will want all of the ceilometer collectors writing to the same
 database, rather than having a local database for each one. Otherwise when
 you query the ceilometer API you won't see all of the results.

 Doug





 On Tue, Dec 10, 2013 at 4:25 PM, Boris Pavlovic 
 bpavlo...@mirantis.comwrote:

 Nadya, Julien,


 We are working around profiling system based on logs. This will allows
 us to detect bottlenecks.
 We should make a couple of small patches in each project to support
 profiling.

 As we are going to be well integrated with OpenStack infrastructure we
 are going to use Ceilometer as a log collector.
 And we already made patch for this in Ceilometer:
 https://review.openstack.org/#/c/60262/
 So it will be nice to get it reviewed/merged.


 Thanks.


 Best regards,
 Boris Pavlovic






 On Tue, Dec 10, 2013 at 3:19 PM, Julien Danjou jul...@danjou.infowrote:

 On Tue, Dec 10 2013, Nadya Privalova wrote:

 Hi Nadya,

  Guys, if you have any questions or comments you are welcome! I think
 that
  2x difference between avg time in empty lab and 5 sec polling
 scenario
  is not a bad result. But 100 instances that were being monitored
 during the
  test is not a real load for the lab. What do you think? Should I
 repeat the
  test with 1000 instances?

 You didn't mention where you were storing the metrics. If you store
 them
 in the same MySQL DB that's used by Nova for example, it's likely
 that's
 the problem is the load Ceilometer puts on the MySQL cluster slows Nova
 down.

 I don't think it's worth running the test with more instances for now.
 The results are clear, the next action should be to see why things are
 slowed down that much. It shouldn't happen.

 --
 Julien Danjou
 # Free Software hacker # independent consultant
 # http://julien.danjou.info

 ___
 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


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

[openstack-dev] Stackalytics 0.4 released!

2013-12-12 Thread Ilya Shakhat

Hello everyone!

Stackalytics team is happy to announce the release of version 0.4. This
release is completely dedicated to different types of reports. We added
highly demanded top reviewers chart acknowledged as an essential tool for
finding most active reviewers (ex.
http://stackalytics.com/report/reviews/neutron-group/30). Open reviews
report to help core engineers with tracking the backlog and reviews that
stay for too long (http://stackalytics.com/report/reviews/nova/open). And
activity report, the one to show all work done by engineer and another by
company. Also this report includes nice punch-card and the one can find
that there are really world-wide never-sleeping contributors like
http://stackalytics.com/report/companies/red%20hat :)

In details, total changes are:

   - Added review stats
reporthttp://stackalytics.com/report/reviews/neutron-group/30that
shows top reviewers with breakdown by marks and disagreement ratio
   against core's decision
   - Added open reviews
reporthttp://stackalytics.com/report/reviews/nova/openthat shows top
longest reviews and backlog summary
   - Added activity report
http://stackalytics.com/report/users/boris-42with engineer's
activity log and punch-card of usual online hours (in UTC).
   The same report is available for companies
   - Fixed review stats calculation, now Approve marks are counted
   separately
   - Fixed commit date calculation, now it is date of merge, not commit
   - Minor improvements in filter selectors
   - Incorporated 21 updates to user and company profiles in default data

The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
#openstack-meeting. Come and join us, we have somemore things for the next
release.

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

2013-12-12 Thread Doug Hellmann

On Wed, Dec 11, 2013 at 6:29 PM, Christopher Yeoh cbky...@gmail.com wrote:

 On Thu, Dec 12, 2013 at 7:11 AM, Ryan Petrello 
 ryan.petre...@dreamhost.com wrote:

 Hello,

 I’ve spent the past week experimenting with using Pecan for Nova’s API,
 and have opened an experimental review:

 https://review.openstack.org/#/c/61303/6

 …which implements the `versions` v3 endpoint using pecan (and paves the
 way for other extensions to use pecan).  This is a *potential* approach
 I've considered for gradually moving the V3 API, but I’m open to other
 suggestions (and feedback on this approach).  I’ve also got a few open
 questions/general observations:

 1.  It looks like the Nova v3 API is composed *entirely* of extensions
 (including “core” API calls), and that extensions and their routes are
 discoverable and extensible via installed software that registers itself
 via stevedore.  This seems to lead to an API that’s composed of installed
 software, which in my opinion, makes it fairly hard to map out the API (as
 opposed to how routes are manually defined in other WSGI frameworks).  I
 assume at this time, this design decision has already been solidified for
 v3?


 Yes, from an implementation view everything is an extension, even core
 functionality. One issue with the V2 API is that because core is hard coded
 and separate from the plugin framework there were things you could do in
 core API code that you couldn't do in extensions and other things which you
 could do in both, but had to do in different ways. Which is bad from a
 maintainability/readability point of view. And inevitably we ended up with
 extension specific code sitting in what should have been only core code. So
 we ended up deciding to make everything a plugin to consistency of how API
 code is written and also ensured that the framework didn't treat core API
 code in any special way.


OK, I can completely see how that problem would lead to this solution.
I'll try to keep that in mind, and start thinking of extension in the way
it is actually used. :-)

Doug






 2.  The approach in my review would allow us to translate extensions to
 pecan piecemeal.  To me, this seems like a more desirable and manageable
 approach than moving everything to pecan at once, given the scale of Nova’s
 API.  Do others agree/disagree?  Until all v3 extensions are translated,
 this means the v3 API is composed of two separate WSGI apps.


 Yes, I think this is the way to go. Attempting to get a big-bang patch
 merged would be rather challenging.



 3.  Can somebody explain the purpose of the wsgi.deserializer decorator?
  It’s something I’ve not accounted for yet in my pecan implementation.  Is
 the goal to deserialize the request *body* from e.g., XML into a usable
 data structure?  Is there an equivalent for JSON handling?  How does this
 relate to the schema validation that’s being done in v3?


 Yes the deserializer decorator specifies and XML deserializer which is
 used when the default one is not suitable. schema validation is done on the
 deserialized output so essentially covers both JSON and XML (eg XML is not
 directly validated, but what we end up interpreting in the api code is).

 Chris


 ___
 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] Incubation Request for Barbican

2013-12-12 Thread Bryan D. Payne


 $ git shortlog -s -e | sort -n -r
172 John Wood john.w...@rackspace.com
150 jfwood john.w...@rackspace.com
 65 Douglas Mendizabal douglas.mendiza...@rackspace.com
 39 Jarret Raim jarret.r...@rackspace.com
 17 Malini K. Bhandaru malini.k.bhand...@intel.com
 10 Paul Kehrer paul.l.keh...@gmail.com
 10 Jenkins jenk...@review.openstack.org
  8 jqxin2006 jqxin2...@gmail.com
  7 Arash Ghoreyshi arashghorey...@gmail.com
  5 Chad Lung chad.l...@gmail.com
  3 Dolph Mathews dolph.math...@gmail.com
  2 John Vrbanac john.vrba...@rackspace.com
  1 Steven Gonzales stevendgonza...@gmail.com
  1 Russell Bryant rbry...@redhat.com
  1 Bryan D. Payne bdpa...@acm.org
 
 It appears to be an effort done by a group, and not an individual.  Most
 commits by far are from Rackspace, but there is at least one non-trivial
 contributor (Malini) from another company (Intel), so I think this is OK.

 There has been some interest from some quarters (RedHat, HP and others) in
 additional support. I hope that the incubation process will help
 accelerate external contributions.


For what it's worth, I just wanted to express my intent to get more
involved in Barbican in the near future.  I plan to be helping out with
both reviews and coding on a variety of pieces.  So that will help (a
little) with the diversification situation.  I would also mention that
there has been great interest in Barbican among the OSSG crowd and it
wouldn't surprise me to see more people from that group getting involved in
the future.

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

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

2013-12-12 Thread Mark McLoughlin

On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
 Hi all,
 
 TL;DR: I believe that As an infrastructure administrator, Anna wants a 
 CLI for managing the deployment providing the same fundamental features 
 as UI. With the planned architecture changes (making tuskar-api thinner 
 and getting rid of proxying to other services), there's not an obvious 
 way to achieve that. We need to figure this out. I present a few options 
 and look forward for feedback.
..

 1) Make a thicker python-tuskarclient and put the business logic there. 
 Make it consume other python-*clients. (This is an unusual approach 
 though, i'm not aware of any python-*client that would consume and 
 integrate other python-*clients.)
 
 2) Make a thicker tuskar-api and put the business logic there. (This is 
 the original approach with consuming other services from tuskar-api. The 
 feedback on this approach was mostly negative though.)

FWIW, I think these are the two most plausible options right now.

My instinct is that tuskar could be a stateless service which merely
contains the business logic between the UI/CLI and the various OpenStack
services.

That would be a first (i.e. an OpenStack service which doesn't have a
DB) and it is somewhat hard to justify. I'd be up for us pushing tuskar
as a purely client-side library used by the UI/CLI (i.e. 1) as far it
can go until we hit actual cases where we need (2).

One example worth thinking through though - clicking deploy my
overcloud will generate a Heat template and sent to the Heat API.

The Heat template will be fairly closely tied to the overcloud images
(i.e. the actual image contents) we're deploying - e.g. the template
will have metadata which is specific to what's in the images.

With the UI, you can see that working fine - the user is just using a UI
that was deployed with the undercloud.

With the CLI, it is probably not running on undercloud machines. Perhaps
your undercloud was deployed a while ago and you've just installed the
latest TripleO client-side CLI from PyPI. With other OpenStack clients
we say that newer versions of the CLI should support all/most older
versions of the REST APIs.

Having the template generation behind a (stateless) REST API could allow
us to define an API which expresses deploy my overcloud and not have
the client so tied to a specific undercloud version.

Mark.


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

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

2013-12-12 Thread Bryan D. Payne

I just wanted to close the loop here.  I understand the position that
others are taking and it appears that I'm outnumbered :-)  While I disagree
with this approach, it sounds like that's where we are at today.  Even with
this decision, I would encourage the horizon dev team to utilize Paul as a
security resource.

Perhaps the best way to flag something as needing a security review in
gerrit is to tag your PRs by writing SecurityImpact in the commit
message.  This will trigger a message to the openstack-security mailing
list.  Which should (hopefully!) result in some additional eyes on the code.

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

[openstack-dev] [Nova] cross-project bug fixes

2013-12-12 Thread Hamilton, Peter A.

I am in the process of getting a bug fix approved for a bug found in 
openstack.common:

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

The bug is present in both nova and cinder. The above patch is under nova; do I 
need to submit a separate cinder patch covering the same fix, or does the 
shared nature of the openstack.common module allow for updates across projects 
without needing separate project patches?

Thanks,
Peter Hamilton


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

[openstack-dev] Generic question: Any tips for 'keeping up' with the mailing lists?

2013-12-12 Thread Justin Hammond

I am a developer who is currently having troubles keeping up with the
mailing list due to volume, and my inability to organize it in my client.
I am nearly forced to use Outlook 2011 for Mac and I have read and
attempted to implement
https://wiki.openstack.org/wiki/MailingListEtiquette but it is still a lot
to deal with. I read once a topic or wiki page on using X-Topics but I
have no idea how to set that in outlook (google has told me that the
feature was removed).

I'm not sure if this is a valid place for this question, but I *am* having
difficulty as a developer.

Thank you for anyone who takes the time to read this.


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

Re: [openstack-dev] Generic question: Any tips for 'keeping up' with the mailing lists?

On 12/12/2013 11:23 AM, Justin Hammond wrote:
 I am a developer who is currently having troubles keeping up with the
 mailing list due to volume, and my inability to organize it in my client.
 I am nearly forced to use Outlook 2011 for Mac and I have read and
 attempted to implement
 https://wiki.openstack.org/wiki/MailingListEtiquette but it is still a lot
 to deal with. I read once a topic or wiki page on using X-Topics but I
 have no idea how to set that in outlook (google has told me that the
 feature was removed).
 
 I'm not sure if this is a valid place for this question, but I *am* having
 difficulty as a developer.
 
 Thank you for anyone who takes the time to read this.

The trick is defining what keeping up means for you.  I doubt anyone
reads everything.  I certainly don't.

First, I filter all of openstack-dev into its own folder.  I'm sure
others filter more aggressively based on topic, but I don't since I know
I may be interested in threads in any of the topics.  Figure out what
filtering works for you.

I scan subjects for the threads I'd probably be most interested in.
While I'm scanning, I'm first looking for topic tags, like [Nova], then
I read the subject and decide whether I want to dive in and read the
rest.  It happens very quickly, but that's roughly my thought process.

With whatever is left over: mark all as read.  :-)

-- 
Russell Bryant

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

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-12 Thread Keith Basil

On Dec 10, 2013, at 5:09 PM, Robert Collins wrote:

 On 11 December 2013 05:42, Jaromir Coufal jcou...@redhat.com wrote:
 On 2013/09/12 23:38, Tzu-Mainn Chen wrote:
 The disagreement comes from whether we need manual node assignment or not.
 I would argue that we
 need to step back and take a look at the real use case: heterogeneous
 nodes.  If there are literally
 no characteristics that differentiate nodes A and B, then why do we care
 which gets used for what?  Why
 do we need to manually assign one?
 
 
 Ideally, we don't. But with this approach we would take out the possibility
 to change something or decide something from the user.
 
 So, I think this is where the confusion is. Using the nova scheduler
 doesn't prevent change or control. It just ensures the change and
 control happen in the right place: the Nova scheduler has had years of
 work, of features and facilities being added to support HPC, HA and
 other such use cases. It should have everything we need [1], without
 going down to manual placement. For clarity: manual placement is when
 any of the user, Tuskar, or Heat query Ironic, select a node, and then
 use a scheduler hint to bypass the scheduler.
 
 The 'easiest' way is to support bigger companies with huge deployments,
 tailored infrastructure, everything connected properly.
 
 But there are tons of companies/users who are running on old heterogeneous
 hardware. Very likely even more than the number of companies having already
 mentioned large deployments. And giving them only the way of 'setting up
 rules' in order to get the service on the node - this type of user is not
 gonna use our deployment system.
 
 Thats speculation. We don't know if they will or will not because we
 haven't given them a working system to test.
 
 Lets break the concern into two halves:
 A) Users who could have their needs met, but won't use TripleO because
 meeting their needs in this way is too hard/complex/painful.
 
 B) Users who have a need we cannot meet with the current approach.
 
 For category B users, their needs might be specific HA things - like
 the oft discussed failure domains angle, where we need to split up HA
 clusters across power bars, aircon, switches etc. Clearly long term we
 want to support them, and the undercloud Nova scheduler is entirely
 capable of being informed about this, and we can evolve to a holistic
 statement over time. Lets get a concrete list of the cases we can
 think of today that won't be well supported initially, and we can
 figure out where to do the work to support them properly.
 
 For category A users, I think that we should get concrete examples,
 and evolve our design (architecture and UX) to make meeting those
 needs pleasant.
 
 What we shouldn't do is plan complex work without concrete examples
 that people actually need. Jay's example of some shiny new compute
 servers with special parts that need to be carved out was a great one
 - we can put that in category A, and figure out if it's easy enough,
 or obvious enough - and think about whether we document it or make it
 a guided workflow or $whatever.
 
 Somebody might argue - why do we care? If user doesn't like TripleO
 paradigm, he shouldn't use the UI and should use another tool. But the UI is
 not only about TripleO. Yes, it is underlying concept, but we are working on
 future *official* OpenStack deployment tool. We should care to enable people
 to deploy OpenStack - large/small scale, homo/heterogeneous hardware,
 typical or a bit more specific use-cases.
 
 The difficulty I'm having is that the discussion seems to assume that
 'heterogeneous implies manual', but I don't agree that that
 implication is necessary!
 
 As an underlying paradigm of how to install cloud - awesome idea, awesome
 concept, it works. But user doesn't care about how it is being deployed for
 him. He cares about getting what he wants/needs. And we shouldn't go that
 far that we violently force him to treat his infrastructure as cloud. I
 believe that possibility to change/control - if needed - is very important
 and we should care.
 
 I propose that we make concrete use cases: 'Fred cannot use TripleO
 without manual assignment because XYZ'. Then we can assess how
 important XYZ is to our early adopters and go from there.
 
 And what is key for us is to *enable* users - not to prevent them from using
 our deployment tool, because it doesn't work for their requirements.
 
 Totally agreed :)
 
 If we can agree on that, then I think it would be sufficient to say that
 we want a mechanism to allow
 UI users to deal with heterogeneous nodes, and that mechanism must use
 nova-scheduler.  In my mind,
 that's what resource classes and node profiles are intended for.
 
 
 Not arguing on this point. Though that mechanism should support also cases,
 where user specifies a role for a node / removes node from a role. The rest
 of nodes which I don't care about should be handled by nova-scheduler.
 
 Why! What is a use case for removing a

Re: [openstack-dev] Stackalytics 0.4 released!

2013-12-12 Thread Monty Taylor



On 12/12/2013 04:49 PM, Ilya Shakhat wrote:
 Hello everyone!
 
 Stackalytics team is happy to announce the release of version 0.4. This
 release is completely dedicated to different types of reports. We added
 highly demanded top reviewers chart acknowledged as an essential tool
 for finding most active reviewers
 (ex. http://stackalytics.com/report/reviews/neutron-group/30). Open
 reviews report to help core engineers with tracking the backlog and
 reviews that stay for too long
 (http://stackalytics.com/report/reviews/nova/open). And activity report,
 the one to show all work done by engineer and another by company. Also
 this report includes nice punch-card and the one can find that there are
 really world-wide never-sleeping contributors
 like http://stackalytics.com/report/companies/red%20hat :)

Nice work. On the activity chart, it shows an activity graph of time and
day. What timezone are those hours shown in?

 In details, total changes are:
 
   * Added review stats report
 http://stackalytics.com/report/reviews/neutron-group/30 that shows
 top reviewers with breakdown by marks and disagreement ratio against
 core's decision
   * Added open reviews report
 http://stackalytics.com/report/reviews/nova/open that shows top
 longest reviews and backlog summary
   * Added activity report
 http://stackalytics.com/report/users/boris-42 with engineer's
 activity log and punch-card of usual online hours (in UTC). The same
 report is available for companies
   * Fixed review stats calculation, now Approve marks are counted
 separately
   * Fixed commit date calculation, now it is date of merge, not commit
   * Minor improvements in filter selectors
   * Incorporated 21 updates to user and company profiles in default data 
 
 The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
 #openstack-meeting. Come and join us, we have somemore things for the
 next release.
 
 Thanks,
 Ilya
 
 
 ___
 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] Generic question: Any tips for 'keeping up' with the mailing lists?

Excerpts from Justin Hammond's message of 2013-12-12 08:23:24 -0800:
 I am a developer who is currently having troubles keeping up with the
 mailing list due to volume, and my inability to organize it in my client.
 I am nearly forced to use Outlook 2011 for Mac and I have read and
 attempted to implement
 https://wiki.openstack.org/wiki/MailingListEtiquette but it is still a lot
 to deal with. I read once a topic or wiki page on using X-Topics but I
 have no idea how to set that in outlook (google has told me that the
 feature was removed).

Justin I'm sorry that the volume is catching up with you. I have a highly
optimized email-list-reading work-flow using sup-mail and a few filters,
and I still spend 2 hours a day sifting through all of the lists I am on
(not just openstack lists). It is worth it to keep aware and to avoid
duplicating efforts, even if it means I have to hit the kill this thread
button a lot.

Whomever is forcing you to use this broken client, I suggest that you
explain to them your situation. It is the reason for your problems. Note
that you can just subscribe to the list from a different address than
you post from, and configure a good e-mail client like Thunderbird to set
your From: address so that you still are representing your organization
the way you'd like to. So if it is just a mail server thing, that is
one way around it.

Also the setup I use makes use of offlineimap, which can filter things
for you, so if you have IMAP access to your inbox, you can use that and
then just configure your client for local access (I believe Thunderbird
even supports a local Maildir mode).

Anyway, you _MUST_ have a threaded email client that quotes well for
replies. If not, I'm afraid it will remain unnecessarily difficult to
participate on this list.

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

[openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?

I've been chasing quite a few bugs in the TripleO automated bring-up
lately that have to do with failures because either there are no valid
hosts ready to have servers scheduled, or there are hosts listed and
enabled, but they can't bind to the network because for whatever reason
the L2 agent has not checked in with Neutron yet.

This is only a problem in the first few minutes of a nova-compute host's
life. But it is critical for scaling up rapidly, so it is important for
me to understand how this is supposed to work.

So I'm asking, is there a standard way to determine whether or not a
nova-compute is definitely ready to have things scheduled on it? This
can be via an API, or even by observing something on the nova-compute
host itself. I just need a definitive signal that the compute host is
ready.

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

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?

On 12/12/2013 12:02 PM, Clint Byrum wrote:
 I've been chasing quite a few bugs in the TripleO automated bring-up
 lately that have to do with failures because either there are no valid
 hosts ready to have servers scheduled, or there are hosts listed and
 enabled, but they can't bind to the network because for whatever reason
 the L2 agent has not checked in with Neutron yet.
 
 This is only a problem in the first few minutes of a nova-compute host's
 life. But it is critical for scaling up rapidly, so it is important for
 me to understand how this is supposed to work.
 
 So I'm asking, is there a standard way to determine whether or not a
 nova-compute is definitely ready to have things scheduled on it? This
 can be via an API, or even by observing something on the nova-compute
 host itself. I just need a definitive signal that the compute host is
 ready.

If a nova compute host has registered itself to start having instances
scheduled to it, it *should* be ready.  AFAIK, we're not doing any
network sanity checks on startup, though.

We already do some sanity checks on startup.  For example, nova-compute
requires that it can talk to nova-conductor.  nova-compute will block on
startup until nova-conductor is responding if they happened to be
brought up at the same time.

We could do something like this with a networking sanity check if
someone could define what that check should look like.

-- 
Russell Bryant

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

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-12 Thread Keith Basil

On Dec 11, 2013, at 3:42 PM, Robert Collins wrote:

 On 12 December 2013 01:17, Jaromir Coufal jcou...@redhat.com wrote:
 On 2013/10/12 23:09, Robert Collins wrote:
 
 The 'easiest' way is to support bigger companies with huge deployments,
 tailored infrastructure, everything connected properly.
 
 But there are tons of companies/users who are running on old
 heterogeneous
 hardware. Very likely even more than the number of companies having
 already
 mentioned large deployments. And giving them only the way of 'setting up
 rules' in order to get the service on the node - this type of user is not
 gonna use our deployment system.
 
 
 Thats speculation. We don't know if they will or will not because we
 haven't given them a working system to test.
 
 Some part of that is speculation, some part of that is feedback from people
 who are doing deployments (of course its just very limited audience).
 Anyway, it is not just pure theory.
 
 Sure. Let be me more precise. There is a hypothesis that lack of
 direct control will be a significant adoption blocker for a primary
 group of users.
 
 I think it's safe to say that some users in the group 'sysadmins
 having to deploy an OpenStack cloud' will find it a bridge too far and
 not use a system without direct control. Call this group A.
 
 I think it's also safe to say that some users will not care in the
 slightest, because their deployment is too small for them to be
 particularly worried (e.g. about occasional downtime (but they would
 worry a lot about data loss)). Call this group B.
 
 I suspect we don't need to consider group C - folk who won't use a
 system if it *has* manual control, but thats only a suspicion. It may
 be that the side effect of adding direct control is to reduce
 usability below the threshold some folk need...
 
 To assess 'significant adoption blocker' we basically need to find the
 % of users who will care sufficiently that they don't use TripleO.
 
 How can we do that? We can do questionnaires, and get such folk to
 come talk with use, but that suffers from selection bias - group B can
 use the system with or without direct manual control, so have little
 motivation to argue vigorously in any particular direction. Group A
 however have to argue because they won't use the system at all without
 that feature, and they may want to use the system for other reasons,
 so that because a crucial aspect for them.
 
 A much better way IMO is to test it - to get a bunch of volunteers and
 see who responds positively to a demo *without* direct manual control.
 
 To do that we need a demoable thing, which might just be mockups that
 show a set of workflows (and include things like Jay's
 shiny-new-hardware use case in the demo).
 
 I rather suspect we're building that anyway as part of doing UX work,
 so maybe what we do is put a tweet or blog post up asking for
 sysadmins who a) have not yet deployed openstack, b) want to, and c)
 are willing to spend 20-30 minutes with us, walk them through a demo
 showing no manual control, and record what questions they ask, and
 whether they would like to have that product to us, and if not, then
 (a) what use cases they can't address with the mockups and (b) what
 other reasons they have for not using it.
 
 This is a bunch of work though!
 
 So, do we need to do that work?
 
 *If* we can layer manual control on later, then we could defer this
 testing until we are at the point where we can say 'the nova scheduled
 version is ready, now lets decide if we add the manual control'.
 
 OTOH, if we *cannot* layer manual control on later - if it has
 tentacles through too much of the code base, then we need to decide
 earlier, because it will be significantly harder to add later and that
 may be too late of a ship date for vendors shipping on top of TripleO.
 
 So with that as a prelude, my technical sense is that we can layer
 manual scheduling on later: we provide an advanced screen, show the
 list of N instances we're going to ask for and allow each instance to
 be directly customised with a node id selected from either the current
 node it's running on or an available node. It's significant work both
 UI and plumbing, but it's not going to be made harder by the other
 work we're doing AFAICT.
 
 - My proposal is that we shelve this discussion until we have the
 nova/heat scheduled version in 'and now we polish' mode, and then pick
 it back up and assess user needs.
 
 An alternative argument is to say that group A is a majority of the
 userbase and that doing an automatic version is entirely unnecessary.
 Thats also possible, but I'm extremely skeptical, given the huge cost
 of staff time, and the complete lack of interest my sysadmin friends
 (and my former sysadmin self) have in doing automatable things by
 hand.
 
 Lets break the concern into two halves:
 A) Users who could have their needs met, but won't use TripleO because
 meeting their needs in this way is too hard/complex/painful.
 
 B) Users who have a

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?

2013-12-12 Thread Chris Friesen


On 12/12/2013 11:02 AM, Clint Byrum wrote:


So I'm asking, is there a standard way to determine whether or not a
nova-compute is definitely ready to have things scheduled on it? This
can be via an API, or even by observing something on the nova-compute
host itself. I just need a definitive signal that the compute host is
ready.


Is it not sufficient that nova service-list shows the compute service 
as up?


If not, then maybe we should call that a bug in nova...

Chris


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

Re: [openstack-dev] Incubation Request for Barbican

2013-12-12 Thread Clark, Robert Graham

From: Bryan D. Payne [mailto:bdpa...@acm.org] 
Sent: 12 December 2013 16:12
To: OpenStack Development Mailing List (not for usage questions)
Cc: openstack...@lists.openstack.org; cloudkeep@googlegroups. com;
barbi...@lists.rackspace.com
Subject: Re: [openstack-dev] Incubation Request for Barbican

$ git shortlog -s -e | sort -n -r
   172 John Wood john.w...@rackspace.com
   150 jfwood john.w...@rackspace.com
65 Douglas Mendizabal douglas.mendiza...@rackspace.com
39 Jarret Raim jarret.r...@rackspace.com
17 Malini K. Bhandaru malini.k.bhand...@intel.com
10 Paul Kehrer paul.l.keh...@gmail.com
10 Jenkins jenk...@review.openstack.org
 8 jqxin2006 jqxin2...@gmail.com
 7 Arash Ghoreyshi arashghorey...@gmail.com
 5 Chad Lung chad.l...@gmail.com
 3 Dolph Mathews dolph.math...@gmail.com
 2 John Vrbanac john.vrba...@rackspace.com
 1 Steven Gonzales stevendgonza...@gmail.com
 1 Russell Bryant rbry...@redhat.com
 1 Bryan D. Payne bdpa...@acm.org

It appears to be an effort done by a group, and not an individual.
Most
commits by far are from Rackspace, but there is at least one
non-trivial
contributor (Malini) from another company (Intel), so I think this is
OK.

There has been some interest from some quarters (RedHat, HP and others)
in
additional support. I hope that the incubation process will help
accelerate external contributions.

For what it's worth, I just wanted to express my intent to get more
involved in Barbican in the near future.  I plan to be helping out with
both reviews and coding on a variety of pieces.  So that will help (a
little) with the diversification situation.  I would also mention that
there has been great interest in Barbican among the OSSG crowd and it
wouldn't surprise me to see more people from that group getting involved
in the future.

Cheers,

-bryan

Just adding a +1 here from HP.

We're very excited about some of the capabilities that Barbican will
bring and will be engaging with the development of the project.

Cheers,

-Rob

smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Agenda for the meeting today

2013-12-12 Thread Collins, Sean

The agenda for today is pretty light - if there is anything that people
would like to discuss, please feel free to add.

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_12._2013

-- 
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] [Neutron] How do we know a host is ready to have servers scheduled onto it?

2013-12-12 Thread Stephen Gran

On 12/12/13 17:19, Chris Friesen wrote:

On 12/12/2013 11:02 AM, Clint Byrum wrote:

So I'm asking, is there a standard way to determine whether or not a
nova-compute is definitely ready to have things scheduled on it? This
can be via an API, or even by observing something on the nova-compute
host itself. I just need a definitive signal that the compute host is
ready.

Is it not sufficient that nova service-list shows the compute service
as up?

If not, then maybe we should call that a bug in nova...

The nova-compute service does not, currently, know about the health of,
say, the neutron openvswitch agent running on the same hardware,
although that being in good shape is necessary to be able to start
instances and have them be useful. This kind of cross-project state
coordination doesn't exist right now, AFAIK.

Cheers,
--
Stephen Gran
Senior Systems Integrator - theguardian.com
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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-12 Thread Dmitry Mescheryakov

Clint, Kevin,

Thanks for reassuring me :-) I just wanted to make sure that having direct
access from VMs to a single facility is not a dead end in terms of security
and extensibility. And since it is not, I agree it is much simpler (and
hence better) than hypervisor-dependent design.


Then returning to two major suggestions made:
 * Salt
 * Custom solution specific to our needs

The custom solution could be made on top of oslo.messaging. That gives us
RPC working on different messaging systems. And that is what we really need
- an RPC into guest supporting various transports. What it lacks at the
moment is security - it has neither authentication nor ACL.

Salt also provides RPC service, but it has a couple of disadvantages: it is
tightly coupled with ZeroMQ and it needs a server process to run. A single
transport option (ZeroMQ) is a limitation we really want to avoid.
OpenStack could be deployed with various messaging providers, and we can't
limit the choice to a single option in the guest agent. Though it could be
changed in the future, it is an obstacle to consider.

Running yet another server process within OpenStack, as it was already
pointed out, is expensive. It means another server to deploy and take care
of, +1 to overall OpenStack complexity. And it does not look it could be
fixed any time soon.

For given reasons I give favor to an agent based on oslo.messaging.

Thanks,

Dmitry



2013/12/11 Fox, Kevin M kevin@pnnl.gov

 Yeah. Its likely that the metadata server stuff will get more
 scalable/hardened over time. If it isn't enough now, lets fix it rather
 then coming up with a new system to work around it.

 I like the idea of using the network since all the hypervisors have to
 support network drivers already. They also already have to support talking
 to the metadata server. This keeps OpenStack out of the hypervisor driver
 business.

 Kevin

 
 From: Clint Byrum [cl...@fewbar.com]
 Sent: Tuesday, December 10, 2013 1:02 PM
 To: openstack-dev
 Subject: Re: [openstack-dev] Unified Guest Agent proposal

 Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:
   What is the exact scenario you're trying to avoid?
 
  It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server
  (Salt / Our own self-written server). Looking at the design, it doesn't
  look like the attack could be somehow contained within a tenant it is
  coming from.
 

 We can push a tenant-specific route for the metadata server, and a tenant
 specific endpoint for in-agent things. Still simpler than hypervisor-aware
 guests. I haven't seen anybody ask for this yet, though I'm sure if they
 run into these problems it will be the next logical step.

  In the current OpenStack design I see only one similarly vulnerable
  component - metadata server. Keeping that in mind, maybe I just
  overestimate the threat?
 

 Anything you expose to the users is vulnerable. By using the localized
 hypervisor scheme you're now making the compute node itself vulnerable.
 Only now you're asking that an already complicated thing (nova-compute)
 add another job, rate limiting.

 ___
 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] [keystone] domain admin role query

On Thu, Dec 12, 2013 at 8:50 AM, Adam Young ayo...@redhat.com wrote:

 On 12/11/2013 10:11 PM, Paul Belanger wrote:

 On 13-12-11 11:18 AM, Lyle, David wrote:

 +1 on moving the domain admin role rules to the default policy.json

 -David Lyle

 From: Dolph Mathews [mailto:dolph.math...@gmail.com]
 Sent: Wednesday, December 11, 2013 9:04 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [keystone] domain admin role query


 On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox jamielen...@redhat.com
 wrote:
 Using the default policies it will simply check for the admin role and
 not care about the domain that admin is limited to. This is partially a
 left over from the V2 api when there wasn't domains to worry  about.

 A better example of policies are in the file
 etc/policy.v3cloudsample.json. In there you will see the rule for
 create_project is:

  identity:create_project: rule:admin_required and
 domain_id:%(project.domain_id)s,

 as opposed to (in policy.json):

  identity:create_project: rule:admin_required,

 This is what you are looking for to scope the admin role to a domain.

 We need to start moving the rules from policy.v3cloudsample.json to the
 default policy.json =)


 Jamie

 - Original Message -

 From: Ravi Chunduru ravi...@gmail.com
 To: OpenStack Development Mailing List openstack-dev@lists.
 openstack.org
 Sent: Wednesday, 11 December, 2013 11:23:15 AM
 Subject: [openstack-dev] [keystone] domain admin role query

 Hi,
 I am trying out Keystone V3 APIs and domains.
 I created an domain, created a project in that domain, created an user
 in
 that domain and project.
 Next, gave an admin role for that user in that domain.

 I am assuming that user is now admin to that domain.
 Now, I got a scoped token with that user, domain and project. With that
 token, I tried to create a new project in that domain. It worked.

 But, using the same token, I could also create a new project in a
 'default'
 domain too. I expected it should throw authentication error. Is it a
 bug?

 Thanks,
 --
 Ravi


 One of the issues I had this week while using the
 policy.v3cloudsample.json was I had no easy way of creating a domain with
 the id of 'admin_domain_id'.  I basically had to modify the SQL directly to
 do it.

 You should not have to edit the SQL.  You should be able, at a minimum, to
 re-enable the ADMIN_TOKEN in the config file to create any object inside of
 Keystone.

  open a bug for the problem, and describe what you did step by step?



 Any chance we can create a 2nd domain using 'admin_domain_id' via
 keystone-manage sync_db?


I totally forgot about this piece -- this is just another incarnation of
this bug at the domain level which we should avoid furthering:

  https://bugs.launchpad.net/keystone/+bug/968696

But, to answer your question: no. It's intended to be a placeholder in the
policy file for an actual domain ID (modify the policy file, don't hack at
the SQL backend).





 ___
 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] [TripleO][Tuskar] Icehouse Requirements

2013-12-12 Thread Will Foster


On 12/12/13 09:42 +1300, Robert Collins wrote:

On 12 December 2013 01:17, Jaromir Coufal jcou...@redhat.com wrote:

On 2013/10/12 23:09, Robert Collins wrote:



The 'easiest' way is to support bigger companies with huge deployments,
tailored infrastructure, everything connected properly.

But there are tons of companies/users who are running on old
heterogeneous
hardware. Very likely even more than the number of companies having
already
mentioned large deployments. And giving them only the way of 'setting up
rules' in order to get the service on the node - this type of user is not
gonna use our deployment system.



Thats speculation. We don't know if they will or will not because we
haven't given them a working system to test.


Some part of that is speculation, some part of that is feedback from people
who are doing deployments (of course its just very limited audience).
Anyway, it is not just pure theory.


Sure. Let be me more precise. There is a hypothesis that lack of
direct control will be a significant adoption blocker for a primary
group of users.

I think it's safe to say that some users in the group 'sysadmins
having to deploy an OpenStack cloud' will find it a bridge too far and
not use a system without direct control. Call this group A.

I think it's also safe to say that some users will not care in the
slightest, because their deployment is too small for them to be
particularly worried (e.g. about occasional downtime (but they would
worry a lot about data loss)). Call this group B.

I suspect we don't need to consider group C - folk who won't use a
system if it *has* manual control, but thats only a suspicion. It may
be that the side effect of adding direct control is to reduce
usability below the threshold some folk need...

To assess 'significant adoption blocker' we basically need to find the
% of users who will care sufficiently that they don't use TripleO.

How can we do that? We can do questionnaires, and get such folk to
come talk with use, but that suffers from selection bias - group B can
use the system with or without direct manual control, so have little
motivation to argue vigorously in any particular direction. Group A
however have to argue because they won't use the system at all without
that feature, and they may want to use the system for other reasons,
so that because a crucial aspect for them.

A much better way IMO is to test it - to get a bunch of volunteers and
see who responds positively to a demo *without* direct manual control.

To do that we need a demoable thing, which might just be mockups that
show a set of workflows (and include things like Jay's
shiny-new-hardware use case in the demo).

I rather suspect we're building that anyway as part of doing UX work,
so maybe what we do is put a tweet or blog post up asking for
sysadmins who a) have not yet deployed openstack, b) want to, and c)
are willing to spend 20-30 minutes with us, walk them through a demo
showing no manual control, and record what questions they ask, and
whether they would like to have that product to us, and if not, then
(a) what use cases they can't address with the mockups and (b) what
other reasons they have for not using it.

This is a bunch of work though!

So, do we need to do that work?

*If* we can layer manual control on later, then we could defer this
testing until we are at the point where we can say 'the nova scheduled
version is ready, now lets decide if we add the manual control'.

OTOH, if we *cannot* layer manual control on later - if it has
tentacles through too much of the code base, then we need to decide
earlier, because it will be significantly harder to add later and that
may be too late of a ship date for vendors shipping on top of TripleO.

So with that as a prelude, my technical sense is that we can layer
manual scheduling on later: we provide an advanced screen, show the
list of N instances we're going to ask for and allow each instance to
be directly customised with a node id selected from either the current
node it's running on or an available node. It's significant work both
UI and plumbing, but it's not going to be made harder by the other
work we're doing AFAICT.

- My proposal is that we shelve this discussion until we have the
nova/heat scheduled version in 'and now we polish' mode, and then pick
it back up and assess user needs.

An alternative argument is to say that group A is a majority of the
userbase and that doing an automatic version is entirely unnecessary.
Thats also possible, but I'm extremely skeptical, given the huge cost
of staff time, and the complete lack of interest my sysadmin friends
(and my former sysadmin self) have in doing automatable things by
hand.


I just wanted to add a few thoughts:

For some comparative information here from the field I work
extensively on deployments of large OpenStack implementations,
most recently with a ~220node/9rack deployment (scaling up to 
42racks / 1024 nodes soon).  My primary role is of a Devops/Sysadmin

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-12 Thread Dmitry Mescheryakov

Vladik,

Thanks for the suggestion, but hypervisor-dependent solution is exactly
what scares off people in the thread :-)

Thanks,

Dmitry



2013/12/11 Vladik Romanovsky vladik.romanov...@enovance.com


 Maybe it will be useful to use Ovirt guest agent as a base.

 http://www.ovirt.org/Guest_Agent
 https://github.com/oVirt/ovirt-guest-agent

 It is already working well on linux and windows and has a lot of
 functionality.
 However, currently it is using virtio-serial for communication, but I
 think it can be extended for other bindings.

 Vladik

 - Original Message -
  From: Clint Byrum cl...@fewbar.com
  To: openstack-dev openstack-dev@lists.openstack.org
  Sent: Tuesday, 10 December, 2013 4:02:41 PM
  Subject: Re: [openstack-dev] Unified Guest Agent proposal
 
  Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:
What is the exact scenario you're trying to avoid?
  
   It is DDoS attack on either transport (AMQP / ZeroMQ provider) or
 server
   (Salt / Our own self-written server). Looking at the design, it doesn't
   look like the attack could be somehow contained within a tenant it is
   coming from.
  
 
  We can push a tenant-specific route for the metadata server, and a tenant
  specific endpoint for in-agent things. Still simpler than
 hypervisor-aware
  guests. I haven't seen anybody ask for this yet, though I'm sure if they
  run into these problems it will be the next logical step.
 
   In the current OpenStack design I see only one similarly vulnerable
   component - metadata server. Keeping that in mind, maybe I just
   overestimate the threat?
  
 
  Anything you expose to the users is vulnerable. By using the localized
  hypervisor scheme you're now making the compute node itself vulnerable.
  Only now you're asking that an already complicated thing (nova-compute)
  add another job, rate limiting.
 
  ___
  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] [Neutron] How do we know a host is ready to have servers scheduled onto it?

Excerpts from Chris Friesen's message of 2013-12-12 09:19:42 -0800:
 On 12/12/2013 11:02 AM, Clint Byrum wrote:
 
  So I'm asking, is there a standard way to determine whether or not a
  nova-compute is definitely ready to have things scheduled on it? This
  can be via an API, or even by observing something on the nova-compute
  host itself. I just need a definitive signal that the compute host is
  ready.
 
 Is it not sufficient that nova service-list shows the compute service 
 as up?
 

I could spin waiting for at least one. Not a bad idea actually. However,
I suspect that will only handle the situations I've gotten where the
scheduler returns NoValidHost.

I say that because I think if it shows there, it matches the all hosts
filter and will have things scheduled on it. With one compute host I
get failures after scheduling because neutron has no network segment to
bind to. That is because the L2 agent on the host has not yet registered
itself with Neutron.

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

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?

Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:
 On 12/12/2013 12:02 PM, Clint Byrum wrote:
  I've been chasing quite a few bugs in the TripleO automated bring-up
  lately that have to do with failures because either there are no valid
  hosts ready to have servers scheduled, or there are hosts listed and
  enabled, but they can't bind to the network because for whatever reason
  the L2 agent has not checked in with Neutron yet.
  
  This is only a problem in the first few minutes of a nova-compute host's
  life. But it is critical for scaling up rapidly, so it is important for
  me to understand how this is supposed to work.
  
  So I'm asking, is there a standard way to determine whether or not a
  nova-compute is definitely ready to have things scheduled on it? This
  can be via an API, or even by observing something on the nova-compute
  host itself. I just need a definitive signal that the compute host is
  ready.
 
 If a nova compute host has registered itself to start having instances
 scheduled to it, it *should* be ready.  AFAIK, we're not doing any
 network sanity checks on startup, though.
 
 We already do some sanity checks on startup.  For example, nova-compute
 requires that it can talk to nova-conductor.  nova-compute will block on
 startup until nova-conductor is responding if they happened to be
 brought up at the same time.
 
 We could do something like this with a networking sanity check if
 someone could define what that check should look like.
 

Could we ask Neutron if our compute host has an L2 agent yet? That seems
like a valid sanity check.

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova


On 12/11/2013 11:47 PM, Mike Perez wrote:

On 10:06 Thu 12 Dec , Christopher Yeoh wrote:

On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
doug.hellm...@dreamhost.com
mailto:doug.hellm...@dreamhost.comwrote:






On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello 
ryan.petre...@dreamhost.com
mailto:ryan.petre...@dreamhost.com

wrote:



Hello,

I’ve spent the past week experimenting with using Pecan for
Nova’s

API,

and have opened an experimental review:

https://review.openstack.org/#/c/61303/6

…which implements the `versions` v3 endpoint using pecan (and

paves the

way for other extensions to use pecan).  This is a *potential*


approach

I've considered for gradually moving the V3 API, but I’m open
to other suggestions (and feedback on this approach).  I’ve
also got a few open questions/general observations:

1.  It looks like the Nova v3 API is composed *entirely* of
extensions (including “core” API calls), and that extensions
and their routes are discoverable and extensible via installed
software that registers

itself

via stevedore.  This seems to lead to an API that’s composed of


installed

software, which in my opinion, makes it fairly hard to map out
the

API (as

opposed to how routes are manually defined in other WSGI

frameworks).  I

assume at this time, this design decision has already been

solidified for

v3?



Yeah, I brought this up at the summit. I am still having some
trouble understanding how we are going to express a stable core
API for compatibility testing if the behavior of the API can be
varied so significantly by deployment decisions. Will we just
list each

required

extension, and forbid any extras for a compliant cloud?




Maybe the issue is caused by me misunderstanding the term
extension, which (to me) implies an optional component but is
perhaps reflecting a technical implementation detail instead?



Yes and no :-) As Ryan mentions, all API code is a plugin in the V3
API. However, some must be loaded or the V3 API refuses to start
up. In nova/api/openstack/__init__.py we have
API_V3_CORE_EXTENSIONS which hard codes which extensions must be
loaded and there is no config option to override this (blacklisting
a core plugin will result in the V3 API not starting up).

So for compatibility testing I think what will probably happen is
that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS) that
must be implemented and clients can rely on that always being

present

on a compliant cloud. But clients can also then query through
/extensions what other functionality (which is backwards compatible
with respect to core) may also be present on that specific cloud.


This really seems similar to the idea of having a router class, some
controllers and you map them. From my observation at the summit,
calling everything an extension creates confusion. An extension
extends something. For example, Chrome has extensions, and they
extend the idea of the core features of a browser. If you want to do
more than back/forward, go to an address, stop, etc, that's an
extension. If you want it to play an audio clip stop, hammer time
after clicking the stop button, that's an example of an extension.

In OpenStack, we use extensions to extend core. Core are the
essential feature(s) of the project. In Cinder for example, core is
volume. In core you can create a volume, delete a volume, attach a
volume, detach a volume, etc. If you want to go beyond that, that's
an extension. If you want to do volume encryption, that's an example
of an extension.

I'm worried by the discrepancies this will create among the programs.
You mentioned maintainability being a plus for this. I don't think
it'll be great from the deployers perspective when you have one
program that thinks everything is an extension and some of them have
to be enabled that the deployer has to be mindful of, while the rest
of the programs consider all extensions to be optional.


+1. I agree with most of what Mike says above. The idea that there are 
core extensions in Nova's v3 API doesn't make a whole lot of sense to me.


Best,
-jay

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

[openstack-dev] [neutron] [third-party-testing] Meeting Minutes for our first meeting

2013-12-12 Thread Kyle Mestery

Hi everyone:

We had a meeting around Neutron Third-Party testing today on IRC.
The logs are available here [1]. We plan to host another meeting
next week, and it will be at 2200 UTC on Wednesday in the
#openstack-meeting-alt channel on IRC. Please attend and update
the etherpad [2] with any items relevant to you before then.

Thanks again!
Kyle

[1] http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/
[2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?


On 12/12/2013 12:36 PM, Clint Byrum wrote:

Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:

On 12/12/2013 12:02 PM, Clint Byrum wrote:

I've been chasing quite a few bugs in the TripleO automated bring-up
lately that have to do with failures because either there are no valid
hosts ready to have servers scheduled, or there are hosts listed and
enabled, but they can't bind to the network because for whatever reason
the L2 agent has not checked in with Neutron yet.

This is only a problem in the first few minutes of a nova-compute host's
life. But it is critical for scaling up rapidly, so it is important for
me to understand how this is supposed to work.

So I'm asking, is there a standard way to determine whether or not a
nova-compute is definitely ready to have things scheduled on it? This
can be via an API, or even by observing something on the nova-compute
host itself. I just need a definitive signal that the compute host is
ready.


If a nova compute host has registered itself to start having instances
scheduled to it, it *should* be ready.  AFAIK, we're not doing any
network sanity checks on startup, though.

We already do some sanity checks on startup.  For example, nova-compute
requires that it can talk to nova-conductor.  nova-compute will block on
startup until nova-conductor is responding if they happened to be
brought up at the same time.

We could do something like this with a networking sanity check if
someone could define what that check should look like.


Could we ask Neutron if our compute host has an L2 agent yet? That seems
like a valid sanity check.


++

-jay


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

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Dmitry Mescheryakov's message of 2013-12-12 09:24:13 -0800:
 Clint, Kevin,
 
 Thanks for reassuring me :-) I just wanted to make sure that having direct
 access from VMs to a single facility is not a dead end in terms of security
 and extensibility. And since it is not, I agree it is much simpler (and
 hence better) than hypervisor-dependent design.
 
 
 Then returning to two major suggestions made:
  * Salt
  * Custom solution specific to our needs
 
 The custom solution could be made on top of oslo.messaging. That gives us
 RPC working on different messaging systems. And that is what we really need
 - an RPC into guest supporting various transports. What it lacks at the
 moment is security - it has neither authentication nor ACL.
 

I bet salt would be super open to modularizing their RPC. Since
oslo.messaging includes ZeroMQ, and is a library now, I see no reason to
avoid opening that subject with our fine friends in the Salt community.
Perhaps a few of them are even paying attention right here. :)

The benefit there is that we get everything except the plugins we want
to write already done. And we could start now with the ZeroMQ-only
salt agent if we could at least get an agreement on principle that Salt
wouldn't mind using an abstraction layer for RPC.

That does make the poke a hole out of private networks conversation
_slightly_ more complex. It is one thing to just let ZeroMQ out, another
to let all of oslo.messaging's backends out. But I think in general
they'll all share the same thing: you want an address+port to be routed
intelligently out of the private network into something running under
the cloud.

Next steps (all can be done in parallel, as all are interdependent):

* Ask Salt if oslo.messaging is a path they'll walk with us
* Experiment with communicating with salt agents from an existing
  OpenStack service (Savanna, Trove, Heat, etc)
* Deep-dive into Salt to see if it is feasible

As I have no cycles for this, I can't promise to do any, but I will
try to offer assistance if I can.

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

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?

2013-12-12 Thread Kyle Mestery

On Dec 12, 2013, at 11:44 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/12/2013 12:36 PM, Clint Byrum wrote:
 Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:
 On 12/12/2013 12:02 PM, Clint Byrum wrote:
 I've been chasing quite a few bugs in the TripleO automated bring-up
 lately that have to do with failures because either there are no valid
 hosts ready to have servers scheduled, or there are hosts listed and
 enabled, but they can't bind to the network because for whatever reason
 the L2 agent has not checked in with Neutron yet.
 
 This is only a problem in the first few minutes of a nova-compute host's
 life. But it is critical for scaling up rapidly, so it is important for
 me to understand how this is supposed to work.
 
 So I'm asking, is there a standard way to determine whether or not a
 nova-compute is definitely ready to have things scheduled on it? This
 can be via an API, or even by observing something on the nova-compute
 host itself. I just need a definitive signal that the compute host is
 ready.
 
 If a nova compute host has registered itself to start having instances
 scheduled to it, it *should* be ready.  AFAIK, we're not doing any
 network sanity checks on startup, though.
 
 We already do some sanity checks on startup.  For example, nova-compute
 requires that it can talk to nova-conductor.  nova-compute will block on
 startup until nova-conductor is responding if they happened to be
 brought up at the same time.
 
 We could do something like this with a networking sanity check if
 someone could define what that check should look like.
 
 Could we ask Neutron if our compute host has an L2 agent yet? That seems
 like a valid sanity check.
 
 ++
 
This makes sense to me as well. Although, not all Neutron plugins have
an L2 agent, so I think the check needs to be more generic than that.
For example, the OpenDaylight MechanismDriver we have developed
doesn't need an agent. I also believe the Nicira plugin is agent-less,
perhaps there are others as well.

And I should note, does this sort of integration also happen with cinder,
for example, when we're dealing with storage? Any other services which
have a requirement on startup around integration with nova as well?

Thanks,
Kyle

 -jay
 
 
 ___
 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] Introducing the new OpenStack service for Containers

2013-12-12 Thread Rick Harris

Hi all,

Was wondering if there's been any more work done on the proposed
Container-Service (Capsule?) API?

Haven't seen much on the ML on this, so just want to make sure the current
plan is still to have a draft of the Capsule API, compare the delta to the
existing Nova API, and determine whether a separate service still makes
sense for the current use-cases.

Thanks!

Rick


On Fri, Nov 22, 2013 at 2:35 PM, Russell Bryant rbry...@redhat.com wrote:

 On 11/22/2013 02:29 PM, Krishna Raman wrote:
 
  On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com
  mailto:e...@cloudscaling.com wrote:
 
  On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com
  mailto:kra...@gmail.com wrote:
  Reminder: We are meting in about 15 minutes on #openstack-meeting
  channel.
 
  I wasn't able to make it. Was meeting-bot triggered? Is there a log of
  today's discussion?
 
  Yes. Logs are
  here:
 http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html

 Yep, I used the 'nova' meeting topic for this one.  If the meeting turns
 in to a regular thing, we should probably switch it to some sort of
 sub-team type name ... like nova-containers.

 --
 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] Stackalytics 0.4 released!

2013-12-12 Thread chandan kumar

Hello ,

On Thu, Dec 12, 2013 at 10:11 PM, Monty Taylor mord...@inaugust.com wrote:


 On 12/12/2013 04:49 PM, Ilya Shakhat wrote:
 Hello everyone!

 Stackalytics team is happy to announce the release of version 0.4. This
 release is completely dedicated to different types of reports. We added
 highly demanded top reviewers chart acknowledged as an essential tool
 for finding most active reviewers
 (ex. http://stackalytics.com/report/reviews/neutron-group/30). Open
 reviews report to help core engineers with tracking the backlog and
 reviews that stay for too long
 (http://stackalytics.com/report/reviews/nova/open). And activity report,
 the one to show all work done by engineer and another by company. Also
 this report includes nice punch-card and the one can find that there are
 really world-wide never-sleeping contributors
 like http://stackalytics.com/report/companies/red%20hat :)

 Nice work. On the activity chart, it shows an activity graph of time and
 day. What timezone are those hours shown in?

 In details, total changes are:

   * Added review stats report
 http://stackalytics.com/report/reviews/neutron-group/30 that shows
 top reviewers with breakdown by marks and disagreement ratio against
 core's decision
   * Added open reviews report
 http://stackalytics.com/report/reviews/nova/open that shows top
 longest reviews and backlog summary
   * Added activity report
 http://stackalytics.com/report/users/boris-42 with engineer's
 activity log and punch-card of usual online hours (in UTC). The same
 report is available for companies
   * Fixed review stats calculation, now Approve marks are counted
 separately
   * Fixed commit date calculation, now it is date of merge, not commit
   * Minor improvements in filter selectors
   * Incorporated 21 updates to user and company profiles in default data

 The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
 #openstack-meeting. Come and join us, we have somemore things for the
 next release.

 Thanks,
 Ilya


Thank you Ilya for bringing lots of changes in the stackalytics.
I would like to help in the development of stackalytics. Last time i
have missed.
This time i will not.

Thanks,
Chandan Kumar

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

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?


On 12/12/2013 12:53 PM, Kyle Mestery wrote:

On Dec 12, 2013, at 11:44 AM, Jay Pipes jaypi...@gmail.com wrote:

On 12/12/2013 12:36 PM, Clint Byrum wrote:

Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:

On 12/12/2013 12:02 PM, Clint Byrum wrote:

I've been chasing quite a few bugs in the TripleO automated bring-up
lately that have to do with failures because either there are no valid
hosts ready to have servers scheduled, or there are hosts listed and
enabled, but they can't bind to the network because for whatever reason
the L2 agent has not checked in with Neutron yet.

This is only a problem in the first few minutes of a nova-compute host's
life. But it is critical for scaling up rapidly, so it is important for
me to understand how this is supposed to work.

So I'm asking, is there a standard way to determine whether or not a
nova-compute is definitely ready to have things scheduled on it? This
can be via an API, or even by observing something on the nova-compute
host itself. I just need a definitive signal that the compute host is
ready.


If a nova compute host has registered itself to start having instances
scheduled to it, it *should* be ready.  AFAIK, we're not doing any
network sanity checks on startup, though.

We already do some sanity checks on startup.  For example, nova-compute
requires that it can talk to nova-conductor.  nova-compute will block on
startup until nova-conductor is responding if they happened to be
brought up at the same time.

We could do something like this with a networking sanity check if
someone could define what that check should look like.


Could we ask Neutron if our compute host has an L2 agent yet? That seems
like a valid sanity check.


++


This makes sense to me as well. Although, not all Neutron plugins have
an L2 agent, so I think the check needs to be more generic than that.
For example, the OpenDaylight MechanismDriver we have developed
doesn't need an agent. I also believe the Nicira plugin is agent-less,
perhaps there are others as well.

And I should note, does this sort of integration also happen with cinder,
for example, when we're dealing with storage? Any other services which
have a requirement on startup around integration with nova as well?


Right, it's more general than is the L2 agent alive and running. It's 
more about having each service understand the relative dependencies it 
has on other supporting services.


For instance, have each service implement a:

GET /healthcheck

that would return either a 200 OK or 409 Conflict with the body 
containing a list of service types that it is waiting to hear back from 
in order to provide a 200 OK for itself.


Anyway, just some thoughts...

-jay



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

Re: [openstack-dev] Unified Guest Agent proposal


On 12/10/2013 03:49 PM, Ian Wells wrote:

On 10 December 2013 20:55, Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:

If it is just a network API, it works the same for everybody. This
makes it simpler, and thus easier to scale out independently of compute
hosts. It is also something we already support and can very easily
expand
by just adding a tiny bit of functionality to neutron-metadata-agent.

In fact we can even push routes via DHCP to send agent traffic through
a different neutron-metadata-agent, so I don't see any issue where we
are piling anything on top of an overstressed single resource. We can
have neutron route this traffic directly to the Heat API which hosts it,
and that can be load balanced and etc. etc. What is the exact scenario
you're trying to avoid?


You may be making even this harder than it needs to be.  You can create
multiple networks and attach machines to multiple networks.  Every point
so far has been 'why don't we use idea as a backdoor into our VM
without affecting the VM in any other way' - why can't that just be one
more network interface set aside for whatever management  instructions
are appropriate?  And then what needs pushing into Neutron is nothing
more complex than strong port firewalling to prevent the slaves/minions
talking to each other.  If you absolutely must make the communication
come from a system agent and go to a VM, then that can be done by
attaching the system agent to the administrative network - from within
the system agent, which is the thing that needs this, rather than within
Neutron, which doesn't really care how you use its networks.  I prefer
solutions where other tools don't have to make you a special case.


I've read through this email thread with quite a bit of curiosity, and I 
have to say what Ian says above makes a lot of sense to me. If Neutron 
can handle the creation of a management vNIC that has some associated 
iptables rules governing it that provides a level of security for guest 
- host and guest - $OpenStackService, then the transport problem 
domain is essentially solved, and Neutron can be happily ignorant (as it 
should be) of any guest agent communication with anything else.


Best,
-jay


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

Re: [openstack-dev] State of the Gate - Dec 12

2013-12-12 Thread Matt Riedemann




On 12/12/2013 7:20 AM, Sean Dague wrote:

Current Gate Length: 12hrs*, 41 deep

(top of gate entered 12hrs ago)

It's been an *exciting* week this week. For people not paying attention
we had 2 external events which made things terrible earlier in the week.

==
Event 1: sphinx 1.2 complete breakage - MOSTLY RESOLVED
==

It turns out sphinx 1.2 + distutils (which pbr magic call through) means
total sadness. The fix for this was a requirements pin to sphinx  1.2,
and until a project has taken that they will fail in the gate.

It also turns out that tox installs pre-released software by default (a
terrible default behavior), so you also need a tox.ini change like this
- https://github.com/openstack/nova/blob/master/tox.ini#L9 otherwise
local users will install things like sphinx 1.2b3. They will also break
in other ways.

Not all projects have merged this. If you are a project that hasn't,
please don't send any other jobs to the gate until you do. A lot of
delay was added to the gate yesterday by Glance patches being pushed to
the gate before their doc jobs were done.

==
Event 2: apt.puppetlabs.com outage - RESOLVED
==

We use that apt repository to setup the devstack nodes in nodepool with
puppet. We were triggering an issue with grenade where it's apt-get
calls were failing, because it does apt-get update once to make sure
life is good. This only triggered in grenade (noth other devstack runs)
because we do set -o errexit aggressively.

A fix in grenade to ignore these errors was merged yesterday afternoon
(the purple line - http://status.openstack.org/elastic-recheck/ you can
see where it showed up).

==
Top Gate Bugs
==

We normally do this as a list, and you can see the whole list here -
http://status.openstack.org/elastic-recheck/ (now sorted by number of
FAILURES in the last 2 weeks)

That being said, our bigs race bug is currently this one bug -
https://bugs.launchpad.net/tempest/+bug/1253896 - and if you want to
merge patches, fixing that one bug will be huge.

Basically, you can't ssh into guests that get created. That's sort of a
fundamental property of a cloud. It shows up more frequently on neutron
jobs, possibly due to actually testing the metadata server path. There
have been many attempts on retry logic on this, we actually retry for
196 seconds to get in and only fail once we can't get in, so waiting
isn't helping. It doesn't seem like the env is under that much load.

Until we resolve this, life will not be good in landing patches.

-Sean



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



There have been a few threads [1][2] on gate failures and the process 
around what happens when we go about identifying, tracking and fixing them.


I couldn't find anything outside of the mailing list to keep a record of 
this so started a page here [3].


Feel free to contribute so we can point people to how they can easily 
help in working these faster.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2013-November/020280.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019931.html

[3] https://wiki.openstack.org/wiki/ElasticRecheck

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Keystone] policy has no effect because of hard coded assert_admin?

The policy file is protecting v3 API calls at the controller layer, but
you're calling the v2 API. The policy decorators should be moved to the
manager layer to protect both APIs equally... but we'd have to be very
careful not to break deployments depending on the trivial assert_admin
behavior (hence the reason we only wrapped v3 with the new policy
decorators).


On Thu, Dec 12, 2013 at 1:41 AM, Qiu Yu unic...@gmail.com wrote:

 Hi,

 I was trying to fine tune some keystone policy rules. Basically I want to
 grant create_project action to user in ops role. And following are my
 steps.

 1. Adding a new user usr1
 2. Creating new role ops
 3. Granting this user a ops role in service tenant
 4. Adding new lines to keystone policy file

 ops_required: [[role:ops]],
 admin_or_ops: [[rule:admin_required], [rule:ops_required]],

 5. Change

 identity:create_project: [[rule:admin_required]],
 to
 identity:create_project: [[rule:admin_or_ops]],

 6. Restart keystone service

 keystone tenant-create with credential of user usr1 still returns 403
 Forbidden error.
 “You are not authorized to perform the requested action, admin_required.
 (HTTP 403)”

 After some quick scan, it seems that create_project function has a
 hard-coded assert_admin call[1], which does not respect settings in the
 policy file.

 Any ideas why? Is it a bug to fix? Thanks!
 BTW, I'm running keystone havana release with V2 API.

 [1]
 https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L105

 Thanks,
 --
 Qiu Yu

 ___
 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] How to best make User Experience a priority in every project

On Wed, Dec 11, 2013 at 4:25 PM, Stefano Maffulli stef...@openstack.orgwrote:

 On 12/06/2013 02:19 AM, Jaromir Coufal wrote:
  We are growing. At the moment we are 4 core members and others are
  coming in. But honestly, contributors are not coming to specific
  projects - they go to reach UX community in a sense - OK this is awesome
  effort, how can I help? What can I work on?

 It seems to me that from the comments in the thread, we may have these
 fresh energies directed at reviewing code from the UX perspective. Do
 you think that code reviews across all projects are something in scope
 for the UX team? If so, how do you think we can make it easier for the
 UX team to discover reviews that may require comments?


Unfortunately, that's probably most patches. However, I imagine most
commits with DocImpact also have very obvious UX impact - so I'd start by
directing attention to those patches before they merge.




 /stef

 --
 Ask and answer questions on https://ask.openstack.org

 ___
 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] [Neutron] How do we know a host is ready to have servers scheduled onto it?

Excerpts from Kyle Mestery's message of 2013-12-12 09:53:57 -0800:
 On Dec 12, 2013, at 11:44 AM, Jay Pipes jaypi...@gmail.com wrote:
  On 12/12/2013 12:36 PM, Clint Byrum wrote:
  Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:
  On 12/12/2013 12:02 PM, Clint Byrum wrote:
  I've been chasing quite a few bugs in the TripleO automated bring-up
  lately that have to do with failures because either there are no valid
  hosts ready to have servers scheduled, or there are hosts listed and
  enabled, but they can't bind to the network because for whatever reason
  the L2 agent has not checked in with Neutron yet.
  
  This is only a problem in the first few minutes of a nova-compute host's
  life. But it is critical for scaling up rapidly, so it is important for
  me to understand how this is supposed to work.
  
  So I'm asking, is there a standard way to determine whether or not a
  nova-compute is definitely ready to have things scheduled on it? This
  can be via an API, or even by observing something on the nova-compute
  host itself. I just need a definitive signal that the compute host is
  ready.
  
  If a nova compute host has registered itself to start having instances
  scheduled to it, it *should* be ready.  AFAIK, we're not doing any
  network sanity checks on startup, though.
  
  We already do some sanity checks on startup.  For example, nova-compute
  requires that it can talk to nova-conductor.  nova-compute will block on
  startup until nova-conductor is responding if they happened to be
  brought up at the same time.
  
  We could do something like this with a networking sanity check if
  someone could define what that check should look like.
  
  Could we ask Neutron if our compute host has an L2 agent yet? That seems
  like a valid sanity check.
  
  ++
  
 This makes sense to me as well. Although, not all Neutron plugins have
 an L2 agent, so I think the check needs to be more generic than that.
 For example, the OpenDaylight MechanismDriver we have developed
 doesn't need an agent. I also believe the Nicira plugin is agent-less,
 perhaps there are others as well.
 
 And I should note, does this sort of integration also happen with cinder,
 for example, when we're dealing with storage? Any other services which
 have a requirement on startup around integration with nova as well?
 

Does cinder actually have per-compute-host concerns? I admit to being a
bit cinder-stupid here.

Anyway, it seems to me that any service that is compute-host aware
should be able to respond to the compute host whether or not it is a)
aware of it, and b) ready to serve on it.

For agent-less drivers that is easy, you just always return True. And
for drivers with agents, you return false unless you can find an agent
for the host.

So something like:

GET /host/%(compute-host-name)

And then in the response include a ready attribute that would signal
whether all networks that should work there, can work there.

As a first pass, just polling until that is ready before nova-compute
enables itself would solve the problems I see (and that I think users
would see as a cloud provider scales out compute nodes). Longer term
we would also want to aim at having notifications available for this
so that nova-compute could subscribe to that notification bus and then
disable itself if its agent ever goes away.

I opened this bug to track the issue. I suspect there are duplicates of
it already reported, but would like to start clean to make sure it is
analyzed fully and then we can use those other bugs as test cases and
confirmation:

https://bugs.launchpad.net/nova/+bug/1260440

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

Re: [openstack-dev] [Keystone] policy has no effect because of hard coded assert_admin?

2013-12-12 Thread Morgan Fainberg

As Dolph stated, V3 is where the policy file protects.  This is one of the many 
reasons why I would encourage movement to using V3 Keystone over V2.

The V2 API is officially deprecated in the Icehouse cycle, I think that moving 
the decorator potentially could cause more issues than not as stated for 
compatibility.  I would be very concerned about breaking compatibility with 
deployments and maintaining the security behavior with the encouragement to 
move from V2 to V3.  I am also not convinced passing the context down to the 
manager level is the right approach.  Making a move on where the protection 
occurs likely warrants a deeper discussion (perhaps in Atlanta?).

Cheers,
Morgan Fainberg

On December 12, 2013 at 10:32:40, Dolph Mathews (dolph.math...@gmail.com) wrote:

The policy file is protecting v3 API calls at the controller layer, but you're 
calling the v2 API. The policy decorators should be moved to the manager layer 
to protect both APIs equally... but we'd have to be very careful not to break 
deployments depending on the trivial assert_admin behavior (hence the reason 
we only wrapped v3 with the new policy decorators).


On Thu, Dec 12, 2013 at 1:41 AM, Qiu Yu unic...@gmail.com wrote:
Hi,

I was trying to fine tune some keystone policy rules. Basically I want to grant 
create_project action to user in ops role. And following are my steps.

1. Adding a new user usr1
2. Creating new role ops
3. Granting this user a ops role in service tenant
4. Adding new lines to keystone policy file

        ops_required: [[role:ops]],
        admin_or_ops: [[rule:admin_required], [rule:ops_required]],

5. Change

        identity:create_project: [[rule:admin_required]],
    to
        identity:create_project: [[rule:admin_or_ops]],

6. Restart keystone service

keystone tenant-create with credential of user usr1 still returns 403 
Forbidden error.
“You are not authorized to perform the requested action, admin_required. (HTTP 
403)”

After some quick scan, it seems that create_project function has a hard-coded 
assert_admin call[1], which does not respect settings in the policy file.

Any ideas why? Is it a bug to fix? Thanks!
BTW, I'm running keystone havana release with V2 API.

[1] 
https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L105

Thanks,
--
Qiu Yu

___
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] Performance Regression in Neutron/Havana compared to Quantum/Grizzly

2013-12-12 Thread Nathani, Sreedhar (APS)

Hello Salvatore,

Thanks for your feedback. Does the patch 
https://review.openstack.org/#/c/57420/ which you are working on bug 
https://bugs.launchpad.net/neutron/+bug/1253993
will help to correct the OVS agent loop slowdown issue?
Does this patch address the DHCP agent updating the host file once in a minute 
and finally sending SIGKILL to dnsmasq process?

I have tested with Marun's patch https://review.openstack.org/#/c/61168/ 
regarding 'Send DHCP notifications regardless of agent status' but this patch
Also observed the same behavior.


Thanks  Regards,
Sreedhar Nathani

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Thursday, December 12, 2013 6:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Performance Regression in Neutron/Havana compared 
to Quantum/Grizzly


I believe your analysis is correct and inline with the findings reported in the 
bug concerning OVS agent loop slowdown.

The issue has become even more prominent with the ML2 plugin due to an 
increased number of notifications sent.

Another issue which makes delays on the DHCP agent worse is that instances send 
a discover message once a minute.

Salvatore
Il 11/dic/2013 11:50 Nathani, Sreedhar (APS) 
sreedhar.nath...@hp.commailto:sreedhar.nath...@hp.com ha scritto:
Hello Peter,

Here are the tests I have done. Already have 240 instances active across all 
the 16 compute nodes. To make the tests and data collection easy,
I have done the tests on single compute node

First Test -
*   240 instances already active,  16 instances on the compute node where I 
am going to do the tests
*   deploy 10 instances concurrently using nova boot command with 
num-instances option in single compute node
*   All the instances could get IP during the instance boot time.

-   Instances are created at  2013-12-10 13:41:01
-   From the compute host, DHCP requests are sent from 13:41:20 but those 
are not reaching the DHCP server
Reply from the DHCP server got at 13:43:08 (A delay of 108 seconds)
-   DHCP agent updated the host file from 13:41:06 till 13:42:54. Dnsmasq 
process got SIGHUP message every time the hosts file is updated
-   In compute node tap devices are created between 13:41:08 and 13:41:18
Security group rules are received between 13:41:45 and 13:42:56
IP table rules were updated between 13:41:50 and 13:43:04

Second Test -
*   Deleted the newly created 10 instances.
*   240 instances already active,  16 instances on the compute node where I 
am going to do the tests
*   Deploy 30 instances concurrently using nova boot command with 
num-instances option in single compute node
*   None  of the instances could get the IP during the instance boot.


-   Instances are created at  2013-12-10 14:13:50

-   From the compute host, DHCP Requests are sent from  14:14:14 but those 
are not reaching the DHCP Server
(don't see any DHCP requests are reaching the DHCP server 
from the tcpdump on the network node)

-   Reply from the DHCP server only got at 14:22:10 ( A delay of 636 
seconds)

-   From the strace of the DHCP agent process, it first updated the hosts 
file at 14:14:05, after this there is a gap of close to 60 min for
Updating next instance address, it repeated till 7th 
instance which was updated at 14:19:50.  30th instance updated at 14:20:00

-   During the 30 instance creation, dnsmasq process got SIGHUP after the 
host file is updated, but at 14:19:52 it got SIGKILL and new process
   created - 14:19:52.881088 +++ killed by 
SIGKILL +++

-   In the compute node, tap devices are created between 14:14:03 and 
14:14:38
From the strace of L2 agent log, can see security group related 
messages are received from 14:14:27 till 14:20:02
During this period in the L2 agent log see many rpc timeout messages 
like below
Timeout: Timeout while waiting on RPC response - topic: q-plugin, RPC 
method: security_group_rules_for_devices info: unknown

Due to security group related messages received by this compute 
node with delay, it's taking very long time to update the iptable rules
(Can see it was updated till 14:20) which is causing the DHCP 
packets to be dropped at compute node itself without reaching to DHCP server


Here is my understanding based on the tests.
Instances are creating fast and so its TAP devices. But there is a considerable 
delay in updating the network port details in dnsmasq host file and sending
The security group related info to the compute nodes due to which compute nodes 
are not able to update the iptable rules fast enough which is causing
Instance not able to get the IP.

I have collected the tcpdump from controller node, compute nodes + strace of 
dhcp, dnsmasq, OVS L2 agents incase if you are interested to look at it

Thanks  Regards,
Sreedhar

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Jay Pipes's message of 2013-12-12 10:15:13 -0800:
 On 12/10/2013 03:49 PM, Ian Wells wrote:
  On 10 December 2013 20:55, Clint Byrum cl...@fewbar.com
  mailto:cl...@fewbar.com wrote:
 
  If it is just a network API, it works the same for everybody. This
  makes it simpler, and thus easier to scale out independently of compute
  hosts. It is also something we already support and can very easily
  expand
  by just adding a tiny bit of functionality to neutron-metadata-agent.
 
  In fact we can even push routes via DHCP to send agent traffic through
  a different neutron-metadata-agent, so I don't see any issue where we
  are piling anything on top of an overstressed single resource. We can
  have neutron route this traffic directly to the Heat API which hosts it,
  and that can be load balanced and etc. etc. What is the exact scenario
  you're trying to avoid?
 
 
  You may be making even this harder than it needs to be.  You can create
  multiple networks and attach machines to multiple networks.  Every point
  so far has been 'why don't we use idea as a backdoor into our VM
  without affecting the VM in any other way' - why can't that just be one
  more network interface set aside for whatever management  instructions
  are appropriate?  And then what needs pushing into Neutron is nothing
  more complex than strong port firewalling to prevent the slaves/minions
  talking to each other.  If you absolutely must make the communication
  come from a system agent and go to a VM, then that can be done by
  attaching the system agent to the administrative network - from within
  the system agent, which is the thing that needs this, rather than within
  Neutron, which doesn't really care how you use its networks.  I prefer
  solutions where other tools don't have to make you a special case.
 
 I've read through this email thread with quite a bit of curiosity, and I 
 have to say what Ian says above makes a lot of sense to me. If Neutron 
 can handle the creation of a management vNIC that has some associated 
 iptables rules governing it that provides a level of security for guest 
 - host and guest - $OpenStackService, then the transport problem 
 domain is essentially solved, and Neutron can be happily ignorant (as it 
 should be) of any guest agent communication with anything else.
 

Indeed I think it could work, however I think the NIC is unnecessary.

Seems likely even with a second NIC that said address will be something
like 169.254.169.254 (or the ipv6 equivalent?).

If we want to attach that network as a second NIC instead of pushing a
route to it via DHCP, that is fine. But I don't think it actually gains
much, and the current neutron-metadata-agent already facilitates the
conversation between private guests and 169.254.169.254. We just need to
make sure we can forward more than port 80 through that.

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

Re: [openstack-dev] [Nova] cross-project bug fixes

2013-12-12 Thread Matt Riedemann




On Thursday, December 12, 2013 10:29:11 AM, Russell Bryant wrote:

On 12/12/2013 11:21 AM, Hamilton, Peter A. wrote:

I am in the process of getting a bug fix approved for a bug found in 
openstack.common:

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

The bug is present in both nova and cinder. The above patch is under nova; do I 
need to submit a separate cinder patch covering the same fix, or does the 
shared nature of the openstack.common module allow for updates across projects 
without needing separate project patches?


The part under nova/openstack/common needs to be fixed in the
oslo-incubator git repository first.  From there you sync the fix into
nova and cinder.



Peter,

FYI: https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] State of the Gate - Dec 12

2013-12-12 Thread Joe Gordon

On Thu, Dec 12, 2013 at 7:19 PM, Matt Riedemann
mrie...@linux.vnet.ibm.comwrote:



 On 12/12/2013 7:20 AM, Sean Dague wrote:

 Current Gate Length: 12hrs*, 41 deep

 (top of gate entered 12hrs ago)

 It's been an *exciting* week this week. For people not paying attention
 we had 2 external events which made things terrible earlier in the week.

 ==
 Event 1: sphinx 1.2 complete breakage - MOSTLY RESOLVED
 ==

 It turns out sphinx 1.2 + distutils (which pbr magic call through) means
 total sadness. The fix for this was a requirements pin to sphinx  1.2,
 and until a project has taken that they will fail in the gate.

 It also turns out that tox installs pre-released software by default (a
 terrible default behavior), so you also need a tox.ini change like this
 - https://github.com/openstack/nova/blob/master/tox.ini#L9 otherwise
 local users will install things like sphinx 1.2b3. They will also break
 in other ways.

 Not all projects have merged this. If you are a project that hasn't,
 please don't send any other jobs to the gate until you do. A lot of
 delay was added to the gate yesterday by Glance patches being pushed to
 the gate before their doc jobs were done.

 ==
 Event 2: apt.puppetlabs.com outage - RESOLVED
 ==

 We use that apt repository to setup the devstack nodes in nodepool with
 puppet. We were triggering an issue with grenade where it's apt-get
 calls were failing, because it does apt-get update once to make sure
 life is good. This only triggered in grenade (noth other devstack runs)
 because we do set -o errexit aggressively.

 A fix in grenade to ignore these errors was merged yesterday afternoon
 (the purple line - http://status.openstack.org/elastic-recheck/ you can
 see where it showed up).

 ==
 Top Gate Bugs
 ==

 We normally do this as a list, and you can see the whole list here -
 http://status.openstack.org/elastic-recheck/ (now sorted by number of
 FAILURES in the last 2 weeks)

 That being said, our bigs race bug is currently this one bug -
 https://bugs.launchpad.net/tempest/+bug/1253896 - and if you want to
 merge patches, fixing that one bug will be huge.

 Basically, you can't ssh into guests that get created. That's sort of a
 fundamental property of a cloud. It shows up more frequently on neutron
 jobs, possibly due to actually testing the metadata server path. There
 have been many attempts on retry logic on this, we actually retry for
 196 seconds to get in and only fail once we can't get in, so waiting
 isn't helping. It doesn't seem like the env is under that much load.

 Until we resolve this, life will not be good in landing patches.

 -Sean



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


 There have been a few threads [1][2] on gate failures and the process
 around what happens when we go about identifying, tracking and fixing them.

 I couldn't find anything outside of the mailing list to keep a record of
 this so started a page here [3].


Thanks for writing down all that content! but we are trying to keep all the
elastic-recheck documentation in elastic-recheck.  So a patch to
elastic-recheck docs would be very welcome.

https://review.openstack.org/#/c/61300/1
https://review.openstack.org/#/c/61298/


The one big thing that wiki doesn't mention, is one of the most important
parts, actually fixing the bugs from
http://status.openstack.org/elastic-recheck/.



 Feel free to contribute so we can point people to how they can easily help
 in working these faster.

 [1] http://lists.openstack.org/pipermail/openstack-dev/2013-
 November/020280.html
 [2] http://lists.openstack.org/pipermail/openstack-dev/2013-
 November/019931.html
 [3] https://wiki.openstack.org/wiki/ElasticRecheck

 --

 Thanks,

 Matt Riedemann



 ___
 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] Stackalytics 0.4 released! [metrics]

2013-12-12 Thread Stefano Maffulli

On 12/12/2013 07:49 AM, Ilya Shakhat wrote:
 Stackalytics team is happy to announce the release of version 0.4.
[...]

Good job Ilya, congratulations on the release. I may not be able to join
the meeting (too early for me) so I leave here some feedback for you.

I like the new punchcards in the personal activity pages: good way to
see when people are mostly active during the day/week. I think it would
be good to have one comprehensive view of the activity of a person or
company in one page. Do you already have plans to merge this view
http://stackalytics.com/?user_id=project_type=allrelease=allcompany=Red+Hatmetric=all
with http://stackalytics.com/report/companies/red%20hat?

Just yesterday I noticed another incident where people take all our
reported numbers as 'solid gold' while they are subject to
interpretation and verification. I think there should be a warning on
every page, especially the pages reporting companies activity (and a
link to how to fix the data if somebody finds a mistake would be good
too). I and Tom filed a bug for stackalytics and Activity Board:
https://bugs.launchpad.net/stackalytics/+bug/1260135

I think you're doing a very good job with the reporting. We may want to
start discussing how to improve the company-person affiliation problem
in the long term. There is a bug filed for this topic too:
https://bugs.launchpad.net/openstack-community/+bug/1260140

let's keep this going, we want to have good data available automatically
all the time :)

/stef

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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-12 Thread Ian Wells

On 12 December 2013 19:48, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Jay Pipes's message of 2013-12-12 10:15:13 -0800:
  On 12/10/2013 03:49 PM, Ian Wells wrote:
   On 10 December 2013 20:55, Clint Byrum cl...@fewbar.com
   mailto:cl...@fewbar.com wrote:
  I've read through this email thread with quite a bit of curiosity, and I
  have to say what Ian says above makes a lot of sense to me. If Neutron
  can handle the creation of a management vNIC that has some associated
  iptables rules governing it that provides a level of security for guest
  - host and guest - $OpenStackService, then the transport problem
  domain is essentially solved, and Neutron can be happily ignorant (as it
  should be) of any guest agent communication with anything else.
 

 Indeed I think it could work, however I think the NIC is unnecessary.

 Seems likely even with a second NIC that said address will be something
 like 169.254.169.254 (or the ipv6 equivalent?).


There *is* no ipv6 equivalent, which is one standing problem.  Another is
that (and admittedly you can quibble about this problem's significance) you
need a router on a network to be able to get to 169.254.169.254 - I raise
that because the obvious use case for multiple networks is to have a net
which is *not* attached to the outside world so that you can layer e.g. a
private DB service behind your app servers.

Neither of these are criticisms of your suggestion as much as they are
standing issues with the current architecture.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Plan files and resources

2013-12-12 Thread Clayton Coleman



- Original Message -
 
  On Dec 11, 2013, at 4:45 PM, Clayton Coleman ccole...@redhat.com wrote:
  - Original Message -
  Devdatta,
  
  On Dec 10, 2013, at 12:37 PM, devdatta kulkarni
  devdatta.kulka...@rackspace.com wrote:
  
  Hi Adrian,
  
  Thanks for creating https://etherpad.openstack.org/p/solum-demystified
  
  I am really excited to see the examples. Especially cool is how
  examples 2 and 3 demonstrate using a component (solum_glance_id)
  created
  as part of example 1.
  
  
  Some questions/comments:
  
  1) Summarizing the sequence of events just to make sure I understand them
  correctly:
   a) User selects a language pack and specifies its id in the plan file
  
  They could put the language pack reference into a Plan file, or we could
  generate a Plan file with a CLI command that feeds an auto-generated file
  to
  the API for the user. That might reduce the user complexity a bit for the
  general case.
  
  It seems like the reasonable M1 and M2 scenarios are to get the bones of an
  integration working that allow a flexible Plan to exist (but not
  necessarily something an average user would edit).
 
 To be clear, are you suggesting that we ask users to place stock plan files
 in their code repos as a first step? This would certainly minimize work for
 us to get to milestone-1.

Possibly - or that plan generation is as absolutely simple as possible (we 
either take a plan as input in the client, or pregenerate one with 1-2 
replacement variables).  

 
  M2 and M3 can focus on the support around making Plans that mere mortals
  can throw together (whether generated or precreated by an operator), and a
  lot of how that evolves depends on the other catalog work.
 
 This would mean revisiting the simplicity of the plan file, documenting lots
 of examples of them so the are well understood. At that point we could
 demonstrate ways to tweak them to accommodate a variety of workload types
 with Solum, not just deploy simple web apps fitting a single system
 architecture.
 
  You could argue the resistance from some quarters to the current PaaS model
  is that the Plan equivalent is hardcoded and non-flexible - what is
  being done differently here is to offer the concepts necessary to allow
  other types of plans and application models to coexist in a single system.
 
 Agreed 100%.
 
   b) User creates repo with the plan file in it.
  
  We could scan the repo for a Plan file to override the auto-generation
  step,
  to allow a method for customization.
  
   After this the flow could be:
   c.1) User uses solum cli to 'create' an application by giving reference
   to
  the repo uri
  
  I view this as the use of the cli app create command as the first step.
  They can optionally specify a Plan file to use for either the build
  sequence, or the app deployment sequence, or both (for a total of TWO Plan
  files). We could also allow plan files to be placed in the Git repo, and
  picked up there in the event that none are specified on the command line.
  
  Note that they may also put a HOT file in their repo, and bypass HOT file
  generation/catalog-lookup and cause Solum to use the supplied template.
  This
  would be useful for power users who want the ability to further influence
  the arrangement of the Heat stack.
  
   c.1.1) Solum creates a plan resource
   c.1.2) Solum model interpreter creates a Heat stack and does the
   rest
   of the
things needed to create a assembly.
   (The created plan resource does not play any part in assembly
   creation as such.
Its only role is being a 'trackback' to track the plan from which
the assembly was created.)
  
  It's also a way to find out what services the given requirements were
  mapped
  to. In a Plan file, the services array contains ServiceSpecfications (see
  the EX[1-3] YAML examples under the services node for an example of what
  those look like. In a Plan resource, the services array includes a list of
  service resources so you can see what Solum's model interpreter mapped
  your
  requirements to.
  
   or,
   c.2) User uses solum cli to 'create/register' a plan by providing
   reference to the repo uri.
c.2.1) Solum creates the plan resource.
   c.2) User uses solum cli to 'create' an application by specifying the
   created plan
resource uri
(In this flow, the plan is actively used).
  
  Yes, this would be another option. I expect that this approach may be used
  by
  users who want to create multitudes of Assemblies from a given Plan
  resource.
  
  2) Addition of new solum specific attributes in a plan specification is
  interesting.
   I imagine those can be contributed back as Solum profile to CAMP spec?
  
  If we want, that input would certainly be welcomed.
  
  3) Model interpreter for generating Heat stack from a plan is a nice
  idea.
   For all: Are there any recommended libraries for this?
  
  Good question. There are

Re: [openstack-dev] [Neutron][IPv6] Agenda for the meeting today

2013-12-12 Thread Ian Wells

Can we go over the use cases for the multiple different address allocation
techniques, per my comment on the blueprint that suggests we expose
different dnsmasq modes?

And perhaps also what we're going to do with routers in terms of equivalent
behaviour for the current floating-ip versus no-floating-ip systems.  One
idea is that we would offer tenants a routeable address regardless of which
network they're on (something itself which is not what we do in v4 and
which doesn't really fit with current subnet-create) and rather than NAT we
have two default firewalling schemes in routers for an externally
accessible versus an inaccessible address, but I'd really like to hear what
other ideas there are out there.
-- 
Ian.


On 12 December 2013 18:22, Collins, Sean sean_colli...@cable.comcast.comwrote:

 The agenda for today is pretty light - if there is anything that people
 would like to discuss, please feel free to add.


 https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_12._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] [Tempest][Production] Tempest / the gate / real world load

2013-12-12 Thread Robert Collins

A few times now we've run into patches for devstack-gate / devstack
that change default configuration to handle 'tempest load'.

For instance - https://review.openstack.org/61137 (Sorry Salvatore I'm
not picking on you really!)

So there appears to be a meme that the gate is particularly stressful
- a bad environment - and that real world situations have less load.

This could happen a few ways: (a) deployers might separate out
components more; (b) they might have faster machines; (c) they might
have less concurrent activity.

(a) - unlikely! Deployers will cram stuff together as much as they can
to save overheads. Big clouds will have components split out - yes,
but they will also have correspondingly more load to drive that split
out.

(b) Perhaps, but not orders of magnitude faster, the clouds we run on
are running on fairly recent hardware, and by using big instances we
don't get crammed it with that many other tenants.

(c) Almost certainly not. Tempest currently does a maximum of four
concurrent requests. A small business cloud could easily have 5 or 6
people making concurrent requests from time to time, and bigger but
not huge clouds will certainly have that. Their /average/ rate of API
requests may be much lower, but when they point service orchestration
tools at it -- particularly tools that walk their dependencies in
parallel - load is going to be much much higher than what we generate
with Tempest.

tl;dr : if we need to change a config file setting in devstack-gate or
devstack *other than* setting up the specific scenario, think thrice -
should it be a production default and set in the relevant projects
default config setting.

Cheers,
Rob
-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [barbican] Meeting Today at 20:00 UTC (2 Central)

2013-12-12 Thread Jarret Raim

The barbican meeting today will cover our progress on the incubation
issues brought up by the TC, test planning and any other issues.


If you are interested in barbican and have questions, stop on by
#openstack-meeting-alt in 20 minutes.




Thanks,

--
Jarret Raim 
@jarretraim




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-12 Thread Vladik Romanovsky

Dmitry,

I understand that :)
The only hypervisor dependency it has is how it communicates with the host, 
while this can be extended and turned into a binding, so people could connect 
to it in multiple ways.

The real value, as I see it, is which features this guest agent already 
implements and the fact that this is a mature code base.

Thanks,
Vladik 

- Original Message -
 From: Dmitry Mescheryakov dmescherya...@mirantis.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Thursday, 12 December, 2013 12:27:47 PM
 Subject: Re: [openstack-dev] Unified Guest Agent proposal
 
 Vladik,
 
 Thanks for the suggestion, but hypervisor-dependent solution is exactly what
 scares off people in the thread :-)
 
 Thanks,
 
 Dmitry
 
 
 2013/12/11 Vladik Romanovsky  vladik.romanov...@enovance.com 
 
 
 
 Maybe it will be useful to use Ovirt guest agent as a base.
 
 http://www.ovirt.org/Guest_Agent
 https://github.com/oVirt/ovirt-guest-agent
 
 It is already working well on linux and windows and has a lot of
 functionality.
 However, currently it is using virtio-serial for communication, but I think
 it can be extended for other bindings.
 
 Vladik
 
 - Original Message -
  From: Clint Byrum  cl...@fewbar.com 
  To: openstack-dev  openstack-dev@lists.openstack.org 
  Sent: Tuesday, 10 December, 2013 4:02:41 PM
  Subject: Re: [openstack-dev] Unified Guest Agent proposal
  
  Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:
What is the exact scenario you're trying to avoid?
   
   It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server
   (Salt / Our own self-written server). Looking at the design, it doesn't
   look like the attack could be somehow contained within a tenant it is
   coming from.
   
  
  We can push a tenant-specific route for the metadata server, and a tenant
  specific endpoint for in-agent things. Still simpler than hypervisor-aware
  guests. I haven't seen anybody ask for this yet, though I'm sure if they
  run into these problems it will be the next logical step.
  
   In the current OpenStack design I see only one similarly vulnerable
   component - metadata server. Keeping that in mind, maybe I just
   overestimate the threat?
   
  
  Anything you expose to the users is vulnerable. By using the localized
  hypervisor scheme you're now making the compute node itself vulnerable.
  Only now you're asking that an already complicated thing (nova-compute)
  add another job, rate limiting.
  
  ___
  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

[openstack-dev] [Nova] New official bugtag 'Ironic' ?

2013-12-12 Thread Robert Collins

We have official tags for most of the hypervisors, but not ironic as
yet - any objections to adding one?

-Rob

-- 
Robert Collins rbtcoll...@hp.com
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] [Nova] New official bugtag 'Ironic' ?

On 12/12/2013 03:03 PM, Robert Collins wrote:
 We have official tags for most of the hypervisors, but not ironic as
 yet - any objections to adding one?

Nope, go ahead.  For reference, to add it we need to:

1) Make it an official tag in launchpad

2) Update https://wiki.openstack.org/wiki/BugTags

3) Update https://wiki.openstack.org/wiki/Nova/BugTriage

-- 
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] [Neutron] How do we know a host is ready to have servers scheduled onto it?

On 12/12/2013 12:35 PM, Clint Byrum wrote:
 Excerpts from Chris Friesen's message of 2013-12-12 09:19:42 -0800:
 On 12/12/2013 11:02 AM, Clint Byrum wrote:

 So I'm asking, is there a standard way to determine whether or not a
 nova-compute is definitely ready to have things scheduled on it? This
 can be via an API, or even by observing something on the nova-compute
 host itself. I just need a definitive signal that the compute host is
 ready.

 Is it not sufficient that nova service-list shows the compute service 
 as up?

 
 I could spin waiting for at least one. Not a bad idea actually. However,
 I suspect that will only handle the situations I've gotten where the
 scheduler returns NoValidHost.

Right it solves this case

 I say that because I think if it shows there, it matches the all hosts
 filter and will have things scheduled on it. With one compute host I
 get failures after scheduling because neutron has no network segment to
 bind to. That is because the L2 agent on the host has not yet registered
 itself with Neutron.

but not this one.

-- 
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] [Neutron] How do we know a host is ready to have servers scheduled onto it?

On 12/12/2013 01:36 PM, Clint Byrum wrote:
 Excerpts from Kyle Mestery's message of 2013-12-12 09:53:57 -0800:
 On Dec 12, 2013, at 11:44 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/12/2013 12:36 PM, Clint Byrum wrote:
 Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:
 On 12/12/2013 12:02 PM, Clint Byrum wrote:
 I've been chasing quite a few bugs in the TripleO automated bring-up
 lately that have to do with failures because either there are no valid
 hosts ready to have servers scheduled, or there are hosts listed and
 enabled, but they can't bind to the network because for whatever reason
 the L2 agent has not checked in with Neutron yet.

 This is only a problem in the first few minutes of a nova-compute host's
 life. But it is critical for scaling up rapidly, so it is important for
 me to understand how this is supposed to work.

 So I'm asking, is there a standard way to determine whether or not a
 nova-compute is definitely ready to have things scheduled on it? This
 can be via an API, or even by observing something on the nova-compute
 host itself. I just need a definitive signal that the compute host is
 ready.

 If a nova compute host has registered itself to start having instances
 scheduled to it, it *should* be ready.  AFAIK, we're not doing any
 network sanity checks on startup, though.

 We already do some sanity checks on startup.  For example, nova-compute
 requires that it can talk to nova-conductor.  nova-compute will block on
 startup until nova-conductor is responding if they happened to be
 brought up at the same time.

 We could do something like this with a networking sanity check if
 someone could define what that check should look like.

 Could we ask Neutron if our compute host has an L2 agent yet? That seems
 like a valid sanity check.

 ++

 This makes sense to me as well. Although, not all Neutron plugins have
 an L2 agent, so I think the check needs to be more generic than that.
 For example, the OpenDaylight MechanismDriver we have developed
 doesn't need an agent. I also believe the Nicira plugin is agent-less,
 perhaps there are others as well.

 And I should note, does this sort of integration also happen with cinder,
 for example, when we're dealing with storage? Any other services which
 have a requirement on startup around integration with nova as well?

 
 Does cinder actually have per-compute-host concerns? I admit to being a
 bit cinder-stupid here.

No, it doesn't.

 Anyway, it seems to me that any service that is compute-host aware
 should be able to respond to the compute host whether or not it is a)
 aware of it, and b) ready to serve on it.
 
 For agent-less drivers that is easy, you just always return True. And
 for drivers with agents, you return false unless you can find an agent
 for the host.
 
 So something like:
 
 GET /host/%(compute-host-name)
 
 And then in the response include a ready attribute that would signal
 whether all networks that should work there, can work there.
 
 As a first pass, just polling until that is ready before nova-compute
 enables itself would solve the problems I see (and that I think users
 would see as a cloud provider scales out compute nodes). Longer term
 we would also want to aim at having notifications available for this
 so that nova-compute could subscribe to that notification bus and then
 disable itself if its agent ever goes away.
 
 I opened this bug to track the issue. I suspect there are duplicates of
 it already reported, but would like to start clean to make sure it is
 analyzed fully and then we can use those other bugs as test cases and
 confirmation:
 
 https://bugs.launchpad.net/nova/+bug/1260440

Sounds good.  I'm happy to do this in Nova, but we'll have to get the
Neutron API bit sorted out first.

-- 
Russell Bryant

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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-12 Thread Steven Dake


On 12/12/2013 10:24 AM, Dmitry Mescheryakov wrote:

Clint, Kevin,

Thanks for reassuring me :-) I just wanted to make sure that having 
direct access from VMs to a single facility is not a dead end in terms 
of security and extensibility. And since it is not, I agree it is much 
simpler (and hence better) than hypervisor-dependent design.



Then returning to two major suggestions made:
 * Salt
 * Custom solution specific to our needs

The custom solution could be made on top of oslo.messaging. That gives 
us RPC working on different messaging systems. And that is what we 
really need - an RPC into guest supporting various transports. What it 
lacks at the moment is security - it has neither authentication nor ACL.


Salt also provides RPC service, but it has a couple of disadvantages: 
it is tightly coupled with ZeroMQ and it needs a server process to 
run. A single transport option (ZeroMQ) is a limitation we really want 
to avoid. OpenStack could be deployed with various messaging 
providers, and we can't limit the choice to a single option in the 
guest agent. Though it could be changed in the future, it is an 
obstacle to consider.


Running yet another server process within OpenStack, as it was already 
pointed out, is expensive. It means another server to deploy and take 
care of, +1 to overall OpenStack complexity. And it does not look it 
could be fixed any time soon.


For given reasons I give favor to an agent based on oslo.messaging.



An agent based on oslo.messaging is a potential security attack vector 
and a possible scalability problem.  We do not want the guest agents 
communicating over the same RPC servers as the rest of OpenStack

Thanks,

Dmitry



2013/12/11 Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov

Yeah. Its likely that the metadata server stuff will get more
scalable/hardened over time. If it isn't enough now, lets fix it
rather then coming up with a new system to work around it.

I like the idea of using the network since all the hypervisors
have to support network drivers already. They also already have to
support talking to the metadata server. This keeps OpenStack out
of the hypervisor driver business.

Kevin


From: Clint Byrum [cl...@fewbar.com mailto:cl...@fewbar.com]
Sent: Tuesday, December 10, 2013 1:02 PM
To: openstack-dev
Subject: Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37
-0800:
  What is the exact scenario you're trying to avoid?

 It is DDoS attack on either transport (AMQP / ZeroMQ provider)
or server
 (Salt / Our own self-written server). Looking at the design, it
doesn't
 look like the attack could be somehow contained within a tenant
it is
 coming from.


We can push a tenant-specific route for the metadata server, and a
tenant
specific endpoint for in-agent things. Still simpler than
hypervisor-aware
guests. I haven't seen anybody ask for this yet, though I'm sure
if they
run into these problems it will be the next logical step.

 In the current OpenStack design I see only one similarly vulnerable
 component - metadata server. Keeping that in mind, maybe I just
 overestimate the threat?


Anything you expose to the users is vulnerable. By using the
localized
hypervisor scheme you're now making the compute node itself
vulnerable.
Only now you're asking that an already complicated thing
(nova-compute)
add another job, rate limiting.

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto: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] Incubation Request for Barbican

2013-12-12 Thread Adam Young


On 12/04/2013 08:58 AM, Jarret Raim wrote:

While I am all for adding a new program, I think we should only add one
if we
rule out all existing programs as a home. With that in mind why not add
this
to the  keystone program? Perhaps that may require a tweak to keystones
mission
statement, but that is doable. I saw a partial answer to this somewhere
but not a full one.

 From our point of view, Barbican can certainly help solve some problems
related to identity like SSH key management and client certs. However,
there is a wide array of functionality that Barbican will handle that is
not related to identity.


Some examples, there is some additional detail in our application if you
want to dig deeper [1].


* Symmetric key management - These keys are used for encryption of data at
rest in various places including Swift, Nova, Cinder, etc. Keys are
resources that roll up to a project, much like servers or load balancers,
but they have no direct relationship to an identity.

* SSL / TLS certificates - The management of certificate authorities and
the issuance of keys for SSL / TLS. Again, these are resources rather than
anything attached to identity.

* SSH Key Management - These could certainly be managed through keystone
if we think that¹s the right way to go about it, but from Barbican¹s point
of view, these are just another type of a key to be generated and tracked
that roll up to an identity.


* Client certificates - These are most likely tied to an identity, but
again, just managed as resources from a Barbican point of view.

* Raw Secret Storage - This functionality is usually used by applications
residing on an Cloud. An app can use Barbican to store secrets such as
sensitive configuration files, encryption keys and the like. This data
belongs to the application rather than any particular user in Keystone.
For example, some Rackspace customers don¹t allow their application dev /
maintenance teams direct access to the Rackspace APIs.

* Boot Verification - This functionality is used as part of the trusted
boot functionality for transparent disk encryption on Nova.

* Randomness Source - Barbican manages HSMs which allow us to offer a
source of true randomness.



In short (ha), I would encourage everyone to think of keys / certificates
as resources managed by an API in much the same way we think of VMs being
managed by the Nova API. A consumer of Barbican (either as an OpenStack
service or a consumer of an OpenStack cloud) will have an API to create
and manage various types of secrets that are owned by their project.


My reason for keeping them separate is more practical:  the Keystone 
team is already somewhat overloaded.  I know that a couple of us have 
interest in contributing to Barbican, the question is time and 
prioritization.


Unless there is some benefit to having both projects in the same program 
with essentially different teams, I think Barbican should proceed as 
is.  I personally plan on contributing to Barbican.






Keystone plays a critical role for us (as it does with every service) in
authenticating the user to a particular project and storing the roles that
the user has for that project. Barbican then enforces these restrictions.
However, keys / secrets are fundamentally divorced from identities in much
the same way that databases in Trove are, they are owned by a project, not
a particular user.

Hopefully our thought process makes some sense, let me know if I can
provide more detail.



Jarret





[1] https://wiki.openstack.org/wiki/Barbican/Incubation


___
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] [Neutron] How do we know a host is ready to have servers scheduled onto it?

2013-12-12 Thread Joshua Harlow

Maybe time to revive something like:

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


From experience, all sites (and those internal to yahoo) provide a /status
(or equivalent) that is used for all sorts of things (from basic
load-balancing up/down) to other things like actually introspecting the
state of the process (or to get basics about what the process is doing).
Typically this is not exposed to the public (its why
http://www.yahoo.com/status works for me but not for u). It seems like
something like that could help (but of course not completely solve) the
type of response jay mentioned.

-Josh

On 12/12/13 10:10 AM, Jay Pipes jaypi...@gmail.com wrote:

On 12/12/2013 12:53 PM, Kyle Mestery wrote:
 On Dec 12, 2013, at 11:44 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/12/2013 12:36 PM, Clint Byrum wrote:
 Excerpts from Russell Bryant's message of 2013-12-12 09:09:04 -0800:
 On 12/12/2013 12:02 PM, Clint Byrum wrote:
 I've been chasing quite a few bugs in the TripleO automated bring-up
 lately that have to do with failures because either there are no
valid
 hosts ready to have servers scheduled, or there are hosts listed and
 enabled, but they can't bind to the network because for whatever
reason
 the L2 agent has not checked in with Neutron yet.

 This is only a problem in the first few minutes of a nova-compute
host's
 life. But it is critical for scaling up rapidly, so it is important
for
 me to understand how this is supposed to work.

 So I'm asking, is there a standard way to determine whether or not a
 nova-compute is definitely ready to have things scheduled on it?
This
 can be via an API, or even by observing something on the
nova-compute
 host itself. I just need a definitive signal that the compute host
is
 ready.

 If a nova compute host has registered itself to start having
instances
 scheduled to it, it *should* be ready.  AFAIK, we're not doing any
 network sanity checks on startup, though.

 We already do some sanity checks on startup.  For example,
nova-compute
 requires that it can talk to nova-conductor.  nova-compute will
block on
 startup until nova-conductor is responding if they happened to be
 brought up at the same time.

 We could do something like this with a networking sanity check if
 someone could define what that check should look like.

 Could we ask Neutron if our compute host has an L2 agent yet? That
seems
 like a valid sanity check.

 ++

 This makes sense to me as well. Although, not all Neutron plugins have
 an L2 agent, so I think the check needs to be more generic than that.
 For example, the OpenDaylight MechanismDriver we have developed
 doesn't need an agent. I also believe the Nicira plugin is agent-less,
 perhaps there are others as well.

 And I should note, does this sort of integration also happen with
cinder,
 for example, when we're dealing with storage? Any other services which
 have a requirement on startup around integration with nova as well?

Right, it's more general than is the L2 agent alive and running. It's
more about having each service understand the relative dependencies it
has on other supporting services.

For instance, have each service implement a:

GET /healthcheck

that would return either a 200 OK or 409 Conflict with the body
containing a list of service types that it is waiting to hear back from
in order to provide a 200 OK for itself.

Anyway, just some thoughts...

-jay



___
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] firmware security

2013-12-12 Thread Devananda van der Veen

On Thu, Dec 12, 2013 at 12:50 AM, Lu, Lianhao lianhao...@intel.com wrote:

 Hi Ironic folks,

 I remembered once seeing that ironic was calling for firmware security.
 Can anyone elaborate with a little bit details about what Ironic needs for
 this firmware security? I'm wondering if there are some existing
 technologies(e.g. TPM, TXT, etc) that can be used for this purpose.

 Best Regards,
 -Lianhao


Hi Lianhao,

The topic of firmware support in Ironic has lead to very interesting
discussions: questions about scope, multi-vendor support, and, invariably,
questions about how we might validate / ensure the integrity of existing
firmware or the firmware Ironic would be loading onto a machine. A proposal
was put forward at the last summit to add a generic mechanism for flashing
firmware, as part of a generic utility ramdisk. Other work is taking
priority this cycle, but here are the blueprints / discussion.
  https://blueprints.launchpad.net/ironic/+spec/firmware-update
  https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk

To get back to your question about security, UEFI + hardware TPM is, as far
as I know, the commonly-acknowledged best approach today, even though it is
not necessarily available on all hardware. I believe Ironic will need to
support interacting with these both locally (eg, via CPU bus) and remotely
(eg, via vendor's OOB management controllers).

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

2013-12-12 Thread Christopher Yeoh

On Thu, Dec 12, 2013 at 3:17 PM, Mike Perez thin...@gmail.com wrote:

 On 10:06 Thu 12 Dec , Christopher Yeoh wrote:
  On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
  doug.hellm...@dreamhost.comwrote:
 
  So for compatibility testing I think what will probably happen is that
  we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)
  that must be implemented and clients can rely on that always being
 present
  on a compliant cloud. But clients can also then query through /extensions
  what other functionality (which is backwards compatible with respect to
  core) may also be present on that specific cloud.

 I'm worried by the discrepancies this will create among the programs. You
 mentioned maintainability being a plus for this. I don't think it'll be
 great
 from the deployers perspective when you have one program that thinks
 everything
 is an extension and some of them have to be enabled that the deployer has
 to be
 mindful of, while the rest of the programs consider all extensions to be


Just to be clear, the deployer doesn't have to enable these, they are
enabled automatically,
but it will complain if a deployer attempts to disable them. Also anything
not core has a
os- prefix, while core plugins don't so it is easy to distinguish between
them. But yes I'd agree
that from a deployers point of view its not useful to talk about extensions
which have
to be enabled.

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

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Steven Dake's message of 2013-12-12 12:32:55 -0800:
 On 12/12/2013 10:24 AM, Dmitry Mescheryakov wrote:
  Clint, Kevin,
 
  Thanks for reassuring me :-) I just wanted to make sure that having 
  direct access from VMs to a single facility is not a dead end in terms 
  of security and extensibility. And since it is not, I agree it is much 
  simpler (and hence better) than hypervisor-dependent design.
 
 
  Then returning to two major suggestions made:
   * Salt
   * Custom solution specific to our needs
 
  The custom solution could be made on top of oslo.messaging. That gives 
  us RPC working on different messaging systems. And that is what we 
  really need - an RPC into guest supporting various transports. What it 
  lacks at the moment is security - it has neither authentication nor ACL.
 
  Salt also provides RPC service, but it has a couple of disadvantages: 
  it is tightly coupled with ZeroMQ and it needs a server process to 
  run. A single transport option (ZeroMQ) is a limitation we really want 
  to avoid. OpenStack could be deployed with various messaging 
  providers, and we can't limit the choice to a single option in the 
  guest agent. Though it could be changed in the future, it is an 
  obstacle to consider.
 
  Running yet another server process within OpenStack, as it was already 
  pointed out, is expensive. It means another server to deploy and take 
  care of, +1 to overall OpenStack complexity. And it does not look it 
  could be fixed any time soon.
 
  For given reasons I give favor to an agent based on oslo.messaging.
 
 
 An agent based on oslo.messaging is a potential security attack vector 
 and a possible scalability problem.  We do not want the guest agents 
 communicating over the same RPC servers as the rest of OpenStack

I don't think we're talking about agents talking to the exact same
RabbitMQ/Qpid/etc. bus that things under the cloud are talking to. That
would definitely raise some eyebrows. No doubt it will be in the realm
of possibility if deployers decide to do that, but so is letting your
database server sit on the same flat network as your guests.

I have a hard time seeing how using the same library is a security
risk though.

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

Re: [openstack-dev] [TripleO][Tuskar] Terminology

2013-12-12 Thread Tzu-Mainn Chen

Thanks for all the replies so far!  Let me try and distill the thread down to 
the points of
interest and contention:

1) NODE vs INSTANCE

This is a distinction that Robert brings up, and I think it's a good one that 
people agree
with.  The various ROLES can apply to either.

What isn't clear to me (and it's orthogonal to this particular thread) is 
whether the
wireframes are correct in classifying things by NODES, when it feels like we 
might want
to classify things by INSTANCE?

2) UNDEPLOYED NODE - a node that has not been deployed with an instance

Other suggestions included  UNASSIGED, UNMAPPED, FREE, and AVAILABLE.  Some 
people (I'm one of them)
find AVAILABLE to be a bit of an overloaded term, as it can also be construed 
to mean that, say,
a service instance is now running on a node and is now available for use.  
I'm in favor of an
UN word, and it sounds like UNDEPLOYED was the most generally acceptable?

3) SIZE THE DEPLOYMENT - the act of deciding how many nodes will need to be 
assigned to each role in a deployment

Other suggestions included SET NODE COUNT, DESIGN THE DEPLOYMENT, SIZE THE 
CLOUD.  SIZE THE DEPLOYMENT
sounds like the suggested option that used the most words from the other 
choices, so I picked it as a likely
candidate :)  I also like that it uses the word deployment, as that's what 
we're calling the end result.

4) SERVICE CLASS/RESOURCE CLASS/ROLE CONFIGURATION

So, an example of this was

 KVM Compute is a role configuration. KVM compute(GPU) might be another

I'm personally somewhat averse to role configuration.  Although there are 
aspects of configuration to
this, configuration seems somewhat misleading to me when the purpose of this 
classification is something
more like - a subrole?

5) NODE PROFILE/FLAVOR

Flavor seemed generally acceptable, although there was some mention of it being 
an overloaded term.  Is there
a case for using a more user-friendly term in the UI (like node profile or 
hardware configuration or. . .)?
Or should we just expect users to be familiar with OpenStack terminology?


Please feel free to correct me if I've left anything out or misrepresented 
anything!

Mainn



- Original Message -
 Hi,
 
 I'm trying to clarify the terminology being used for Tuskar, which may be
 helpful so that we're sure
 that we're all talking about the same thing :)  I'm copying responses from
 the requirements thread
 and combining them with current requirements to try and create a unified
 view.  Hopefully, we can come
 to a reasonably rapid consensus on any desired changes; once that's done, the
 requirements can be
 updated.
 
 * NODE a physical general purpose machine capable of running in many roles.
 Some nodes may have hardware layout that is particularly
useful for a given role.
 
  * REGISTRATION - the act of creating a node in Ironic
 
  * ROLE - a specific workload we want to map onto one or more nodes.
  Examples include 'undercloud control plane', 'overcloud control
plane', 'overcloud storage', 'overcloud compute' etc.
 
  * MANAGEMENT NODE - a node that has been mapped with an undercloud
  role
  * SERVICE NODE - a node that has been mapped with an overcloud role
 * COMPUTE NODE - a service node that has been mapped to an
 overcloud compute role
 * CONTROLLER NODE - a service node that has been mapped to an
 overcloud controller role
 * OBJECT STORAGE NODE - a service node that has been mapped to an
 overcloud object storage role
 * BLOCK STORAGE NODE - a service node that has been mapped to an
 overcloud block storage role
 
  * UNDEPLOYED NODE - a node that has not been mapped with a role
   * another option - UNALLOCATED NODE - a node that has not been
   allocated through nova scheduler (?)
- (after reading lifeless's explanation, I
agree that allocation may be a
   misleading term under TripleO, so I
   personally vote for UNDEPLOYED)
 
  * INSTANCE - A role deployed on a node - this is where work actually
  happens.
 
 * DEPLOYMENT
 
  * SIZE THE ROLES - the act of deciding how many nodes will need to be
  assigned to each role
* another option - DISTRIBUTE NODES (?)
  - (I think the former is more accurate, but
  perhaps there's a better way to say it?)
 
  * SCHEDULING - the process of deciding which role is deployed on which
  node
 
  * SERVICE CLASS - a further categorization within a service role for a
  particular deployment.
 
   * NODE PROFILE - a set of requirements that specify what attributes
   a node must have in order to be mapped to
a service class

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

2013-12-12 Thread devdatta kulkarni

We followed on the Zuul question in this week's git-integration working group 
meeting.

mordred has created an etherpad with a high-level description of Zuul and how 
it might
fit with Solum't git integration workflow

https://etherpad.openstack.org/p/ZuulSolum

The working group seemed to be coming to the consensus that we want to use a 
single workflow
engine, as far as possible, for all of Solum's workflow needs.
This brought up the question about, what are really Solum's workflow 
requirements. 

At a high-level, I think that Solum has three different kinds of workflows.

1) Workflow around getting user code into Solum
   - This is the git integration piece being worked out in the git-integration
 working group.

2) Workflow around creating language pack(s).
   - The main workflow requirement here involves ability to run tests before 
creating a language pack.
 There was some discussion in language-pack working group about this 
requirement.

3) Workflow around deploying created language pack(s) in order to instantiate 
an assembly.
   - The deployment may potentially contain several steps, some of which may be 
long running, such as
   populating a database. Further, there may be a need to checkpoint 
intermediate steps
   and retry the workflow from the failed point.


mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and 
pull-by-solum)
We want to know if #2 and #3 can also be achieved by Zuul.
If not, we want to know what are the available options.

mordred, thanks for the etherpad; looking forward to the digram :)


thanks,
devkulkarni


-Original Message-
From: Roshan Agrawal roshan.agra...@rackspace.com
Sent: Monday, December 9, 2013 10:57am
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint


 -Original Message-
 From: Krishna Raman [mailto:kra...@gmail.com]
 Sent: Sunday, December 08, 2013 11:24 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
 
 Hi all,
 
 We had a very good meeting last week around the git-pull blueprint. During
 the discussion, Monty suggested using Zuul to manage the git repository
 access and workflow.
 While he is working on sending the group a diagram and description of what
 he has in mind, I had a couple of other questions which I am hoping the
 extended group will be able to answer.
 
 1) Zuul is currently an infrastructure project.
   - Is there anything that prevents us from using it in Solum?
   - Does it need to be moved to a normal OpenStack project?
 
 2) Zuul provides a sort of workflow engine. This workflow engine could
 potentially be used to initiate and manage: API Post - git flow - lang pack
 flow.
   - Have there been any discussion after the F2F where we have
 discussed using some other workflow engine?

There hasn't been further discussion since F2F.
Most of the processes in Solum will really be customizable workflows, and use 
of a generic workflow engine is definitely worth discussing. We may still use 
to leverage Zuul for the gerrit/git/checkin piece, but Solum will have workflow 
needs beyond that. 

   - Is Zuul's engine generic enough to be used in Solum? (Hoping
 Monty can help with this one)
   - Perhaps only use it to manage the API post - git flow
 stages?
 
 Thanks
 -Krishna
 ___
 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] Support for Pecan in Nova

2013-12-12 Thread Jonathan LaCour


On December 11, 2013 at 2:34:07 PM, Doug Hellmann (doug.hellm...@dreamhost.com) 
wrote:

 On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello wrote:
 
  1. It looks like the Nova v3 API is composed *entirely* of
  extensions (including “core” API calls), and that extensions and
  their routes are discoverable and extensible via installed
  software that registers itself via stevedore. This seems to lead
  to an API that’s composed of installed software, which in my
  opinion, makes it fairly hard to map out the API (as opposed to
  how routes are manually defined in other WSGI frameworks). I
  assume at this time, this design decision has already been
  solidified for v3?
 
 Yeah, I brought this up at the summit. I am still having some
 trouble understanding how we are going to express a stable core API
 for compatibility testing if the behavior of the API can be varied
 so significantly by deployment decisions. Will we just list each
 required extension, and forbid any extras for a compliant cloud?
 
 Maybe the issue is caused by me misunderstanding the term
 extension, which (to me) implies an optional component but is
 perhaps reflecting a technical implementation detail instead?

After taking a close look at how the API is constructed, I
actually think that the current approach of having the API be
defined purely through extensions is flawed, for a few reasons:

1. The code is extremely difficult to read and follow, because the API
   structure is entirely built at runtime based upon what is
   installed, rather than expressed declaratively in code.

2. As a company providing a public cloud based upon OpenStack, with a
   desire to express compatibility with the OpenStack API, its
   difficult to document the standard baseline Nova API. I shouldn't
   have to say it depends in API documentation.

3. Based upon my read, extensions are in no way quarantined from the
   the baseline/standard/required API. In fact, they seem to be able
   to pollute the standard API with additional parameters and
   functionality. I can not envision a world in which this is sane.

In my opinion, a well-designed and architected API should have the
core functionality declaratively defined in the code itself, so as to
give a good, well-documented, standard, and unchanging baseline. Then,
an extension capability should be layered on in such a way that it
doesn't alter the core API or serialized data.

Note: my opinion isn’t altered by the fact that some of the “core” 
API involves “required” extensions. The result is still difficult to
read and document.

That said, I don’t want to diminish or minimize the hard work that
has been done on the V3 API thus far! Lots of thinking and heavy
lifting has already been done, and its much appreciated. I am just
concerned that we lost our way somewhere. Major API revisions only
come along so often, and I’d prefer to raise my objections now 
rather than to hold them in and regret it!

-- 
Jonathan LaCour



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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-12 Thread Steven Dake


On 12/12/2013 02:19 PM, Clint Byrum wrote:

Excerpts from Steven Dake's message of 2013-12-12 12:32:55 -0800:

On 12/12/2013 10:24 AM, Dmitry Mescheryakov wrote:

Clint, Kevin,

Thanks for reassuring me :-) I just wanted to make sure that having
direct access from VMs to a single facility is not a dead end in terms
of security and extensibility. And since it is not, I agree it is much
simpler (and hence better) than hypervisor-dependent design.


Then returning to two major suggestions made:
  * Salt
  * Custom solution specific to our needs

The custom solution could be made on top of oslo.messaging. That gives
us RPC working on different messaging systems. And that is what we
really need - an RPC into guest supporting various transports. What it
lacks at the moment is security - it has neither authentication nor ACL.

Salt also provides RPC service, but it has a couple of disadvantages:
it is tightly coupled with ZeroMQ and it needs a server process to
run. A single transport option (ZeroMQ) is a limitation we really want
to avoid. OpenStack could be deployed with various messaging
providers, and we can't limit the choice to a single option in the
guest agent. Though it could be changed in the future, it is an
obstacle to consider.

Running yet another server process within OpenStack, as it was already
pointed out, is expensive. It means another server to deploy and take
care of, +1 to overall OpenStack complexity. And it does not look it
could be fixed any time soon.

For given reasons I give favor to an agent based on oslo.messaging.


An agent based on oslo.messaging is a potential security attack vector
and a possible scalability problem.  We do not want the guest agents
communicating over the same RPC servers as the rest of OpenStack

I don't think we're talking about agents talking to the exact same
RabbitMQ/Qpid/etc. bus that things under the cloud are talking to. That
would definitely raise some eyebrows. No doubt it will be in the realm
of possibility if deployers decide to do that, but so is letting your
database server sit on the same flat network as your guests.


This is my concern.


I have a hard time seeing how using the same library is a security
risk though.
Yes, unless the use of the library is abused by the deployer, is itself 
not a security risk.


Regards
-steve


___
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] [TripleO][Tuskar] Icehouse Requirements

2013-12-12 Thread Jay Dobies




On 12/12/2013 04:25 PM, Keith Basil wrote:

On Dec 12, 2013, at 4:05 PM, Jay Dobies wrote:


Maybe this is a valid use case?

Cloud operator has several core service nodes of differing configuration
types.

[node1]  -- balanced mix of disk/cpu/ram for general core services
[node2]  -- lots of disks for Ceilometer data storage
[node3]  -- low-end appliance like box for a specialized/custom core service
 (SIEM box for example)

All nodes[1,2,3] are in the same deployment grouping (core services).  As 
such,
this is a heterogenous deployment grouping.  Heterogeneity in this case defined 
by
differing roles and hardware configurations.

This is a real use case.

How do we handle this?


This is the sort of thing I had been concerned with, but I think this is just a 
variation on Robert's GPU example. Rather than butcher it by paraphrasing, I'll 
just include the relevant part:


The basic stuff we're talking about so far is just about saying each
role can run on some set of undercloud flavors. If that new bit of kit
has the same coarse metadata as other kit, Nova can't tell it apart.
So the way to solve the problem is:
- a) teach Ironic about the specialness of the node (e.g. a tag 'GPU')
- b) teach Nova that there is a flavor that maps to the presence of
that specialness, and
   c) teach Nova that other flavors may not map to that specialness

then in Tuskar whatever Nova configuration is needed to use that GPU
is a special role ('GPU compute' for instance) and only that role
would be given that flavor to use. That special config is probably
being in a host aggregate, with an overcloud flavor that specifies
that aggregate, which means at the TripleO level we need to put the
aggregate in the config metadata for that role, and the admin does a
one-time setup in the Nova Horizon UI to configure their GPU compute
flavor.



Yes, the core services example is a variation on the above.  The idea
of _undercloud_ flavor assignment (flavor to role mapping) escaped me
when I read that earlier.

It appears to be very elegant and provides another attribute for Tuskar's
notion of resource classes.  So +1 here.



You mention three specific nodes, but what you're describing is more likely 
three concepts:
- Balanced Nodes
- High Disk I/O Nodes
- Low-End Appliance Nodes

They may have one node in each, but I think your example of three nodes is 
potentially *too* simplified to be considered as proper sample size. I'd guess 
there are more than three in play commonly, in which case the concepts 
breakdown starts to be more appealing.


Correct - definitely more than three, I just wanted to illustrate the use case.


I not sure I explained what I was getting at properly. I wasn't implying 
you thought it was limited to just three. I do the same thing, simplify 
down for discussion purposes (I've done so in my head about this very 
topic).


But I think this may be a rare case where simplifying actually masks the 
concept rather than exposes it. Manual feels a bit more desirable in 
small sample groups but when looking at larger sets of nodes, the flavor 
concept feels less odd than it does when defining a flavor for a single 
machine.


That's all. :) Maybe that was clear already, but I wanted to make sure I 
didn't come off as attacking your example. It certainly wasn't my 
intention. The balanced v. disk machine thing is the sort of thing I'd 
been thinking for a while but hadn't found a good way to make concrete.



I think the disk flavor in particular has quite a few use cases, especially until SSDs 
are ubiquitous. I'd want to flag those (in Jay terminology, the disk hotness) 
as hosting the data-intensive portions, but where I had previously been viewing that as 
manual allocation, it sounds like the approach is to properly categorize them for what 
they are and teach Nova how to use them.

Robert - Please correct me if I misread any of what your intention was, I don't 
want to drive people down the wrong path if I'm misinterpretting anything.


-k


___
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] Nominations to Horizon Core

2013-12-12 Thread Paul McMillan

 From: Russell Bryant rbry...@redhat.com
 We can involve people in security reviews without having them on the
 core review team.  They are separate concerns.

As I noted in my original mail, this was my primary concern. I just didn't want 
not core to stand in the way of is appropriate to provide security review 
for private patches on Launchpad. If that is the case, I want to be sure that 
there is someone on core who has the appropriate domain-specific knowledge to 
make sure the patch is thorough and correct.

I'll leave the rest of the argument about why this is important for after I 
finish filing the tickets and fixes are released so we can publicly talk about 
it.

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

Re: [openstack-dev] Incubation Request for Barbican

On Thu, Dec 12, 2013 at 2:58 PM, Adam Young ayo...@redhat.com wrote:

On 12/04/2013 08:58 AM, Jarret Raim wrote:

While I am all for adding a new program, I think we should only add one
if we
rule out all existing programs as a home. With that in mind why not add
this
to the keystone program? Perhaps that may require a tweak to keystones
mission
statement, but that is doable. I saw a partial answer to this somewhere
but not a full one.

From our point of view, Barbican can certainly help solve some problems
related to identity like SSH key management and client certs. However,
there is a wide array of functionality that Barbican will handle that is
not related to identity.

Some examples, there is some additional detail in our application if you
want to dig deeper [1].

* Symmetric key management - These keys are used for encryption of data at
rest in various places including Swift, Nova, Cinder, etc. Keys are
resources that roll up to a project, much like servers or load balancers,
but they have no direct relationship to an identity.

* SSL / TLS certificates - The management of certificate authorities and
the issuance of keys for SSL / TLS. Again, these are resources rather than
anything attached to identity.

* SSH Key Management - These could certainly be managed through keystone
if we think that¹s the right way to go about it, but from Barbican¹s point
of view, these are just another type of a key to be generated and tracked
that roll up to an identity.

* Client certificates - These are most likely tied to an identity, but
again, just managed as resources from a Barbican point of view.

* Raw Secret Storage - This functionality is usually used by applications
residing on an Cloud. An app can use Barbican to store secrets such as
sensitive configuration files, encryption keys and the like. This data
belongs to the application rather than any particular user in Keystone.
For example, some Rackspace customers don¹t allow their application dev /
maintenance teams direct access to the Rackspace APIs.

* Boot Verification - This functionality is used as part of the trusted
boot functionality for transparent disk encryption on Nova.

* Randomness Source - Barbican manages HSMs which allow us to offer a
source of true randomness.

In short (ha), I would encourage everyone to think of keys / certificates
as resources managed by an API in much the same way we think of VMs being
managed by the Nova API. A consumer of Barbican (either as an OpenStack
service or a consumer of an OpenStack cloud) will have an API to create
and manage various types of secrets that are owned by their project.

My reason for keeping them separate is more practical: the Keystone team
is already somewhat overloaded. I know that a couple of us have interest
in contributing to Barbican, the question is time and prioritization.

Unless there is some benefit to having both projects in the same program
with essentially different teams, I think Barbican should proceed as is. I
personally plan on contributing to Barbican.

/me puts PTL hat on

++ I don't want Russel's job.

Keystone has a fairly narrow mission statement in my mind (come to think of
it, I need to propose it to governance..), and that's basically to abstract
away the problem of authenticating and authorizing the API users of other
openstack services. Everything else, including identity management, key
management, key distribution, quotas, etc, is just secondary fodder that we
tend to help with along the way... but they should be first class problems
in someone else's mind.

If we rolled everything together that kind of looks related to keystone
under a big keystone program for the sake of organizational tidiness, I
know I would be less effective as a PTL and that's a bit disheartening.
That said, I'm always happy to help where I can.

Keystone plays a critical role for us (as it does with every service) in
authenticating the user to a particular project and storing the roles that
the user has for that project. Barbican then enforces these restrictions.
However, keys / secrets are fundamentally divorced from identities in much
the same way that databases in Trove are, they are owned by a project, not
a particular user.

Hopefully our thought process makes some sense, let me know if I can
provide more detail.

Jarret

[1] https://wiki.openstack.org/wiki/Barbican/Incubation

___
OpenStack-dev mailing
listOpenStack-dev@lists.openstack.orghttp://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

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] Announcing Fuel

2013-12-12 Thread Andrew Woodward

Mike,

It's great that we are continuing to align fuel with TripleO. I've been
toying with the idea of using TripleO components and CEPH to enhance our CI
infra for a while now, and this announcement has encouraged me to write it
down. I've proposed a BP for Super fast deploy CI that would help us
perform CI better by accelerate fuel CI testing by taking reasonable
shortcuts integrating with several existing components like TripleO and
CEPH.

Blueprint:
https://blueprints.launchpad.net/fuel/+spec/fuel-superfastdeploy-ci
Pad Spec: https://etherpad.openstack.org/p/bp-fuel-superfastdeploy-ci

--
Andrew Woodward
Mirantis


On Thu, Dec 12, 2013 at 6:31 AM, Mike Scherbakov
mscherba...@mirantis.comwrote:

 Folks,

 Most of you by now have heard of Fuel, which we’ve been working on as a
 related OpenStack project for a period of time -
 https://github.com/stackforge/fuel-mainsee https://launchpad.net/fueland
 https://wiki.openstack.org/wiki/Fuel. The aim of the project is to
 provide a distribution agnostic and plug-in agnostic engine for preparing,
 configuring and ultimately deploying various “flavors” of OpenStack in
 production. We’ve also used Fuel in most of our customer engagements to
 stand up an OpenStack cloud.

  At the same time, we’ve been actively involved with TripleO, which we
 believe to be a great effort in simplifying deployment, operations, scaling
 (and eventually upgrading) of OpenStack.

 Per our discussions with core TripleO team during the Icehouse summit,
 we’ve uncovered that while there are certain areas of collision, most of
 the functionality in TripleO and Fuel is complementary. In general, Fuel
 helps solve many problems around “step zero” of setting up an OpenStack
 environment, such as auto-discovery and inventory of bare metal hardware,
 pre-deployment  post-deployment environment  checks, and wizard-driven
 web-based configuration of OpenStack flavors. At the same time, TripleO has
 made great progress in deployment, scaling and operations (with Tuskar).

 We’d like to propose an effort for community consideration to bring the
 two initiatives closer together to eventually arrive at a distribution
 agnostic, community supported framework covering the entire spectrum of
 deployment, management and upgrades; from “step zero” to a fully functional
 and manageable production-grade OpenStack environment.

 To that effect, we propose the following high-level roadmap plans for this
 effort:


-

Keep and continue to evolve bare-metal discovery and inventory module
of Fuel, tightly integrating it with Ironic.
-

Keep and continue to evolve Fuel’s wizard-driven OpenStack flavor
configurator. In the near term we’ll work with the UX team to unify the
user experience across Fuel, TripleO and Tuskar. We are also thinking about
leveraging diskimagebuilder.
-

Continue to evolve Fuel’s pre-deployment (DHCP, L2 connectivity
checks) and post-deployment validation checks in collaboration with the
TripleO and Tempest teams.
-

Eventually replace Fuel’s current orchestration engine
https://github.com/stackforge/fuel-astute/ with Heat


 We’d love to open discussion on this and hear everybody’s thoughts on this
 direction.

 --
 Mike Scherbakov
 Fuel Engineering Lead
 #mihgen

 ___
 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] [bugs] definition of triaged

On Thu, Dec 12, 2013 at 3:46 PM, Robert Collins
robe...@robertcollins.netwrote:

 Hi, I'm trying to overhaul the bug triage process for nova (initially)
 to make it much lighter and more effective.

 I'll be sending a more comprehensive mail shortly but one thing that
 has been giving me pause is this:
 
 Confirmed The bug was reproduced or confirmed as a genuine bug
 Triaged The bug comments contain a full analysis on how to properly
 fix the issue
 

 From wiki.openstack.org/wiki/Bugs

 Putting aside the difficulty of complete reproduction sometimes, I
 don't understand the use of Triaged here.

 In LP they mean:

 Confirmed Verified by someone other than the reporter.
 Triaged Verified by the bug supervisor.

 So our meaning is very divergent. I'd like us to consolidate on the
 standard meaning - which is that the relative priority of having a
 doctor [developer] attack the problem has been assessed.

 Specifically:
  - we should use Triaged to indicate that:
 - we have assigned a priority
 - we believe it's a genuine bug
 - we have routed[tagged] it to what is probably the right place


++ that's exactly how I use it, with some emphasis on believe which I use
to differentiate from this from Confirmed ...


 [vendor driver/low-hanging-fruit etc]
  - we should use Incomplete if we aren't sure that its a bug and need
 the reporter to tell us more to be sure
  - triagers shouldn't ever set 'confirmed' - thats reserved solely for
 end users to tell us that more than one user is encountering the
 problem.


As a triager, if I put my user hat on and am able to reproduce a bug,
I'll mark Confirmed, otherwise it's just Triaged.



 -Rob



 --
 Robert Collins rbtcoll...@hp.com
 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

Re: [openstack-dev] [Keystone] policy has no effect because of hard coded assert_admin?