Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

2014-06-03 Thread Radomir Dopieralski
On 05/31/2014 11:13 PM, Jeremy Stanley wrote:
 On 2014-05-29 20:55:01 + (+), Lyle, David wrote:
 [...]
 There are several more xstatic packages that horizon will pull in that are
 maintained outside openstack. The packages added are only those that did
 not have existing xstatic packages. These packages will be updated very
 sparingly, only when updating say bootstrap or jquery versions.
 [...]
 
 I'll admit that my Web development expertise is probably almost 20
 years stale at this point, so forgive me if this is a silly
 question: what is the reasoning against working with the upstreams
 who do not yet distribute needed Javascript library packages to help
 them participate in the distribution channels you need?

There is nothing stopping us from doing that. On the other hand,
I don't expect much success with that. Those are JavaScript and/or
style/resources libraries, and the authors usually don't know or
care about python packaging. Some of those libraries don't even have
proper releases or versioning! We can reach out and ask them to
include the packages in their releases (where they have them), but
we need the packages now -- we are already using those libraries and
we need to clean up how we bundle them.

 This strikes
 me as similar to forking a Python library which doesn't publish to
 PyPI, just so you can publish it to PyPI.

There is no fork, as we are not modifying the source code.

 When some of these
 dependencies begin to publish xstatic packages themselves, do the
 equivalent repositories in Gerrit get decommissioned at that point?

Yes, we will hand over the keys to the pypi entries, and get rid of the
repositories on our side.
-- 
Radomir Dopieralski

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


Re: [openstack-dev] [Nova] [Ironic] [Infra] Making Ironic vote as a third-party Nova driver

2014-06-03 Thread Joshua Hesketh

Howdy,

Here is my first pass at allowing different voters for different pipelines.
https://review.openstack.org/#/c/97391/2

Cheers,
Josh

Rackspace Australia

On 5/30/14 3:30 AM, Devananda van der Veen wrote:
On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh 
joshua.hesk...@rackspace.com mailto:joshua.hesk...@rackspace.com 
wrote:


On 5/29/14 8:52 AM, James E. Blair wrote:

Devananda van der Veen devananda@gmail.com
mailto:devananda@gmail.com writes:

Hi all!

This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of the plan
forward, a call to
raise awareness of the project's status, and hopefully
gain some interest
from folks on nova-core to help with spec and code reviews.

The nova.virt.ironic driver lives in Ironic's git tree
today [1]. We're
cleaning it up and submitting it to Nova again this cycle.
I've posted
specs [2] outlining the design and planned upgrade
process. Earlier today,
we enabled voting in Ironic's check and gate queues for the
tempest-dsvm-virtual-ironic job. This runs a tempest
scenario test [3]
against devstack, exercising Nova with the Ironic driver
to PXE boot a
virtual machine. It has been running for a few months on
Ironic, and has
been stable for more than a month. However, because Ironic
is not
integrated, we also can't vote in check/gate queues on
integrated projects
(like Nova). We can - and do - report the test result in a
non-voting way,
though that's easy to miss, since it looks like every
other non-voting test.

At the summit [4], it was suggested that we make this job
report as though
it were a third-party CI test for a Nova driver. This
would be removed at
the time that Ironic graduates and the job is allowed to
vote in the gate.
Until that time, I'm happy to have the nova.virt.ironic
driver reporting as
a third-party driver (even though it's not) simply to help
raise awareness
(third-party CI jobs are watched more closely than
non-voting jobs) and
decrease the likelihood that Nova developers will
inadvertently break
Ironic's gate.

Given that there's a concrete plan forward, why am I
sending this email to
all three teams? A few reasons:
- document the plan that we discussed
- many people from infra and nova were not present during
the discussion
and may not be aware of the details
- I may have gotten something wrong (it was a long week)
- and mostly because I don't technically know how to make
an upstream job
report as though it's a third-party job, and am hoping
someone wants to
volunteer to help figure that out

I think it's a reasonable plan.  To elaborate a bit, I think we
identified three categories of jobs that we run:

a) jobs that are voting
b) jobs that are non-voting because they are advisory
c) jobs that are non-voting for policy reasons but we feel fairly
strongly about

There's a pretty subtle distinction between b and c.  Ideally,
there
shouldn't be any.  We've tried to minimize the number of
non-voting jobs
to make sure that people don't ignore them.  Nonetheless, it
seems that
a large enough number of people still do that non-voting jobs are
considered ineffective in Nova.  I think it's worth noting the
potential
danger of de-emphasizing the actual results.  It may make other
non-voting jobs even less effective than they already are.

The intent is to make the jobs described by (c) into voting
jobs, but in
a way that they can still be overridden if need be.  The aim
is to help
new (eg, incubated) projects join the integrated gate in a way
that lets
them prove they are sufficiently mature to do so without
impacting the
currently integrated projects.  I believe we're currently
thinking that
point is after their integration approval.  If we are
comfortable with
incubated projects being able to block the integrated gate
earlier, we
could simply make the non-voting jobs voting instead.

Back to the proposal at hand.  I think we should call the
kinds of jobs
described in (c) as non-binding.

The best way to do that is to register a second 

[openstack-dev] [sahara] 2014.1.1 preparation

2014-06-03 Thread Sergey Lukjanov
Hey folks,

this Thu, June 5 is the date for 2014.1.1 release. We already have
some back ported patches to the stable/icehouse branch, so, the
question is do we need some more patches to back port? Please, propose
them here.

2014.1 - stable/icehouse diff:
https://github.com/openstack/sahara/compare/2014.1...stable/icehouse

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

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


Re: [openstack-dev] [sahara] 2014.1.1 preparation

2014-06-03 Thread Sergey Lukjanov
/me proposing to backport:

Docs:

https://review.openstack.org/#/c/87531/ Change IRC channel name to
#openstack-sahara
https://review.openstack.org/#/c/96621/ Added validate_edp method to
Plugin SPI doc
https://review.openstack.org/#/c/89647/ Updated architecture diagram in docs

EDP:

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

On Tue, Jun 3, 2014 at 10:03 AM, Sergey Lukjanov slukja...@mirantis.com wrote:
 Hey folks,

 this Thu, June 5 is the date for 2014.1.1 release. We already have
 some back ported patches to the stable/icehouse branch, so, the
 question is do we need some more patches to back port? Please, propose
 them here.

 2014.1 - stable/icehouse diff:
 https://github.com/openstack/sahara/compare/2014.1...stable/icehouse

 Thanks.

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

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


Re: [openstack-dev] [Fuel] Review blueprint specs on gerrit

2014-06-03 Thread Mike Scherbakov
Thanks Dmitry.
I'm walking through one of the proposed designs:
https://review.openstack.org/#/c/96429/,
http://docs-draft.openstack.org/29/96429/4/check/gate-fuel-specs-docs/4590dac/doc/build/html/specs/5.1/access-control-master-node.html

I've noticed a few things in the process which I'd propose for changing
(let's keep this email thread to discuss process itself, and not the
content of the blueprint, which I'll comment in a separate thread):

   1. It is unclear who are mandatory people to review the blueprint.
   For example, we have two +1th in the review, can I merge it now?
   Probably not... I think core developers need to come up with ideas who is
   mandatory to review a design, and put their names into changeset. For any
   feature, we must have QA lead approving it (whether QA lead reviews it
   itself, or puts +1 on behalf of other QA team expert. In the latter case,
   that person has to be in a list of reviewers.)
   2. As we want to have more agile-like model with 2 week iterations, in
   order to get feedback sooner on where we are in the release cycle and keep
   some teams working on stuff which will come up in the release after current
   one, then it makes sense to split the work onto iterations. It is great to
   see that this design reflects multiple stages, which can be considered as
   iterations. I'm not sure that every stage can fit into 2 week cycle, but
   that's what I would love to achieve - when we have a clear scope for every
   iteration, and ability to re-arrange things after every iteration. See
   proposed schedule with iterations at
   https://wiki.openstack.org/wiki/Fuel/5.1_Release_Schedule
   3. While I'm Ok with anyone ++ing review request while it's not yet
   completed, I don't think mandatory core reviewer should do that - and I'd
   suggest that core reviewer should rather -1 it, providing comments and
   marking areas which are not yet complete. In this particular review we have
   few sections empty.

Anyone has an opinion on this?

Thanks,


On Wed, May 28, 2014 at 5:35 AM, Dmitry Pyzhov dpyz...@mirantis.com wrote:

 Guys,

 from now on we should keep all our 5.1 blueprint specs in one place: 
 fuel-specs
 repo https://github.com/stackforge/fuel-specs. We do it same way as
 nova, so you can use their instruction
 https://wiki.openstack.org/wiki/Blueprints#Nova as a guideline.

 Once again. All specifications for 5.1 blueprints need to be moved to
 stackforge. Here is example link:
 https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst.

 Jenkins builds every request and adds link to html docs to the comments.
 For example: https://review.openstack.org/#/c/96145/.

 I propose to send feedback for this workflow into this mailing thread.

 Also, take a look on review guidelines
 https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria.
 It contains some useful information, you know.

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




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


Re: [openstack-dev] [Solum] PTL Candidacy Open

2014-06-03 Thread Noorul Islam K M
Anita Kuno ante...@anteaya.info writes:

 On 05/27/2014 06:25 PM, Adrian Otto wrote:

 Team,
 
 If you would like to declare a candidacy for PTL for Solum, you may send an 
 email with the subject [Solum] Solum PTL Candidacy” to this mailing list 
 declaring your candidacy. Please respond with candidacy notices no later 
 than 00:00 UTC on 2014-06-02. 
 
 The following rules apply:
 
 https://wiki.openstack.org/wiki/Solum/Elections
 
 Thanks,
 
 Adrian
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 According to the election guidelines set out in the above wiki url, no
 candidate came forward for the Solum PTL position and the current PTL
 retains his position.

 https://review.openstack.org/#/admin/groups/231,members

 Congratulations to Adrian Otto!


Congratulations Adrian!

Regards,
Noorul

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


Re: [openstack-dev] [Horizon] Use of AngularJS

2014-06-03 Thread Matthias Runge
On Tue, Jun 03, 2014 at 07:49:04AM +0200, Radomir Dopieralski wrote:
 On 06/02/2014 05:13 PM, Adam Nelson wrote:
  I think that you would use the PyPI version anyway:
  
  https://pypi.python.org/pypi/django-angular/0.7.2
  
  That's how most of the other Python dependencies work, even in the
  distribution packages.
 
 That is not true. As all components of OpenStack, Horizon has to be
 packaged at the end of the cycle, with all of its dependencies.
 

I already packaged python-django-angular for Fedora (and EPEL), it's
just waiting for review [1]. 

From a distro standpoint, every dependency needs to be packaged, and
this is not limited to Horizon dependencies as well.
On the other side, we don't break each time, when someone releases a new
setuptools or keystoneclient to pypi.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1099473
-- 
Matthias Runge mru...@redhat.com

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


Re: [openstack-dev] [sahara] 2014.1.1 preparation

2014-06-03 Thread Andrew Lazarev
correction: https://review.openstack.org/#/c/96621/ (Added validate_edp
method to
Plugin SPI doc) has no sense without https://review.openstack.org/#/c/87573
(Fix running EDP job on transient cluster) where validate_edp was
introduced.

Andrew.


On Mon, Jun 2, 2014 at 11:34 PM, Andrew Lazarev alaza...@mirantis.com
wrote:

 https://review.openstack.org/#/c/93564/ has no sense without
 https://review.openstack.org/#/c/87573

 +1 on merging DOC bugs you listed and these 2 EDP bugs

 Andrew.


 On Mon, Jun 2, 2014 at 11:08 PM, Sergey Lukjanov slukja...@mirantis.com
 wrote:

 /me proposing to backport:

 Docs:

 https://review.openstack.org/#/c/87531/ Change IRC channel name to
 #openstack-sahara
 https://review.openstack.org/#/c/96621/ Added validate_edp method to
 Plugin SPI doc
 https://review.openstack.org/#/c/89647/ Updated architecture diagram in
 docs

 EDP:

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

 On Tue, Jun 3, 2014 at 10:03 AM, Sergey Lukjanov slukja...@mirantis.com
 wrote:
  Hey folks,
 
  this Thu, June 5 is the date for 2014.1.1 release. We already have
  some back ported patches to the stable/icehouse branch, so, the
  question is do we need some more patches to back port? Please, propose
  them here.
 
  2014.1 - stable/icehouse diff:
  https://github.com/openstack/sahara/compare/2014.1...stable/icehouse
 
  Thanks.
 
  --
  Sincerely yours,
  Sergey Lukjanov
  Sahara Technical Lead
  (OpenStack Data Processing)
  Principal Software Engineer
  Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.

 ___
 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] [sahara] 2014.1.1 preparation

2014-06-03 Thread Andrew Lazarev
https://review.openstack.org/#/c/93564/ has no sense without
https://review.openstack.org/#/c/87573

+1 on merging DOC bugs you listed and these 2 EDP bugs

Andrew.


On Mon, Jun 2, 2014 at 11:08 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 /me proposing to backport:

 Docs:

 https://review.openstack.org/#/c/87531/ Change IRC channel name to
 #openstack-sahara
 https://review.openstack.org/#/c/96621/ Added validate_edp method to
 Plugin SPI doc
 https://review.openstack.org/#/c/89647/ Updated architecture diagram in
 docs

 EDP:

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

 On Tue, Jun 3, 2014 at 10:03 AM, Sergey Lukjanov slukja...@mirantis.com
 wrote:
  Hey folks,
 
  this Thu, June 5 is the date for 2014.1.1 release. We already have
  some back ported patches to the stable/icehouse branch, so, the
  question is do we need some more patches to back port? Please, propose
  them here.
 
  2014.1 - stable/icehouse diff:
  https://github.com/openstack/sahara/compare/2014.1...stable/icehouse
 
  Thanks.
 
  --
  Sincerely yours,
  Sergey Lukjanov
  Sahara Technical Lead
  (OpenStack Data Processing)
  Principal Software Engineer
  Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.

 ___
 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] [ServiceVM] IRC meeting minutes June 3, 2014 5:00(AM)UTC-)

2014-06-03 Thread Isaku Yamahata
Here is the meeting minutes of the meeting.

ServiceVM/device manager
meeting minutes on June 3, 2014:
  https://wiki.openstack.org/wiki/Meetings/ServiceVM

next meeting:
  June 10, 2014 5:00AM UTC (Tuesday)

agreement:
- include NFV conformance to servicevm project into servicevm project
  = will continue discuss on nomenclature at gerrit. tacker-specs
- we have to define the relationship between NFV team and servicevm team
- consolidate floating implementations

Action Items:
- everyone add your name/bio to contributor of incubation page
- yamahata create tacker-specs repo in stackforge for further discussion
  on terminology
- yamahata update draft to include NFV conformance
- s3wong look into vif creation/network connection
- everyone review incubation page

Detailed logs:
  
http://eavesdrop.openstack.org/meetings/servicevm_device_manager/2014/servicevm_device_manager.2014-06-03-05.04.html
  
http://eavesdrop.openstack.org/meetings/servicevm_device_manager/2014/servicevm_device_manager.2014-06-03-05.04.log.html

thanks,
-- 
Isaku Yamahata isaku.yamah...@gmail.com

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


Re: [openstack-dev] [neutron] blueprint ovs-firewall-driver: OVS implementation of security groups

2014-06-03 Thread Salvatore Orlando
I would like to understand how did we get to this 80%/20% distinction.
In other terms, it seems conntrack's RELATED features won't be supported
for non-tcp traffic. What about the ESTABLISHED feature? The blueprint
specs refers to tcp_flags=ack.
Or will that be supported through the source port matching extension which
is being promoted?

More comments inline.

On 3 June 2014 01:22, Amir Sadoughi amir.sadou...@rackspace.com wrote:

  Hi all,

  In the Neutron weekly meeting today[0], we discussed the
 ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will
 give us 80% of the iptables security groups behavior. Specifically, OVS
 lacks connection tracking so it won’t have a RELATED feature or stateful
 rules for non-TCP flows. (OVS connection tracking is currently under
 development, to be released by 2015[2]). To make the “20% difference more
 explicit to the operator and end user, we have proposed feature
 configuration to provide security group rules API validation that would
 validate based on connection tracking ability, for example.


I am stilly generally skeptic of API changes which surface backend details
on user-facing APIs. I understand why you are proposing this however, and I
think it would be good to get first an assessment of the benefits brought
by such a change before making a call on changing API behaviour to reflect
security group implementation on the backend.



  Several ideas floated up during the chat today, I wanted to expand the
 discussion to the mailing list for further debate. Some ideas include:
 - marking ovs-firewall-driver as experimental in Juno
 - What does it mean to be marked as “experimental”?


In this case experimental would be a way to say not 100% functional.  You
would not expect a public service provider exposing neutron APIs backed by
this driver, but maybe in some private deployments where the missing
features are not a concern it could be used.

- performance improvements under a new OVS firewall driver untested so far
 (vthapar is working on this)


From the last comment in your post it seems you already have proof of the
performance improvement, perhaps you can add those to the Performance
Impact section on the spec.


 - incomplete implementation will cause confusion, educational burden


It's more about technical debt in my opinion, but this is not necessarily
the case.


 - debugging OVS is new to users compared to debugging old iptables


This won't be a concern as long as we have good documentation to back the
implementation.
As Neutron is usually sloppy with documentation - then it's a concern.


 - waiting for upstream OVS to implement (OpenStack K- or even L- cycle)

  In my humble opinion, merging the blueprint for Juno will provide us a
 viable, more performant security groups implementation than what we have
 available today.


  Amir


  [0]
 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html
 [1] https://review.openstack.org/#/c/89712/
 [2] http://openvswitch.org/pipermail/dev/2014-May/040567.html

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


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


[openstack-dev] [Cinder] DRBD integration as volume driver

2014-06-03 Thread Philipp Marek
Hi everybody,

at the Juno Design Summit we held a presentation about using DRBD 9 
within OpenStack.

Here's an overview about the situation; I apologize in advance that the 
mail got a bit longer, but I think it makes sense to capture all that 
information in a single piece.



 WHAT WE HAVE


Design Summit notes:
https://etherpad.openstack.org/p/juno-cinder-DRBD


As promised we've got a proof-of-concept implementation for the simplest 
case, using DRBD to access data on all nodes - the DRBDmanage volume 
driver as per the Etherpad notes (link see below).


As both DRBD 9 and DRBDmanage are still in heavy development, there are 
quite a few rough edges; in case anyone's interested in setting that up 
on some testsystem, I can offer RPMs and DEBs of drbd-utils and 
drbdmanage, and for the DRBD 9 kernel module for a small set of kernel 
versions:

Ubuntu 12.043.8.0-34-generic
RHEL6 ( compat)2.6.32_431.11.2.el6.x86_64

If there's consensus that some specific kernel version should be used 
for testing instead I can try to build packages for that, too.


There's a cinder git clone with our changes at
https://github.com/phmarek/cinder
so that all developments can be discussed easily.
(Should I use some branch in github.com/OpenStack/Cinder instead?)



 FUTURE PLANS


The (/our) plans are:

 * LINBIT will continue DRBD 9 and DRBDmanage development,
   so that these get production-ready ASAP.
   Note: DRBDmanage is heavily influenced by outside
   requirements, eg. OpenStack Cinder Consistency Groups...
   So the sooner we're aware of such needs the better;
   I'd like to avoid changing the DBUS api multiple times ;)

 * LINBIT continues to work on the DRBD Cinder volume driver,
   as this is 

 * LINBIT starts to work to provide DRBD 9 integration
   between the LVM and iSCSI layer.
   That needs the Replication API to be more or less finished.

There are a few dependencies, though ... please see below.


All help - ideas, comments (both for design and code), all feedback, 
and, last but not least, patches resp. pull requests - are *really* 
welcome, of course.

(For real-time communication I'm available in the #openstack-cinder 
channel too, mostly during European working hours; I'm flip\d+.)



 WHAT WE NEED


Now, while I filled out the CLA, I haven't read through all the 
documentation regarding Processes  Workflow yet ... and that'll take 
some time, I gather.


Furthermore, on the technical side there's a lot to discuss, too;
eg. regarding snapshots there are quite a few things to decide.

 * Should snapshots be taken on _one_ of the storage nodes,
 * on some subnet, or
 * on all of them?

I'm not sure whether the same redundancy that's defined for the volume 
is wanted for the snapshots, too.
(I guess one usecase that should be possible is to take at least one 
snapshot of the volume in _each_ data center?)


Please note that having volume groups would be good-to-have (if not 
essential) for a DRBD integration, because only then DRBD could ensure 
data integrity *across* volumes (by using a single resource for all of 
them).
See also 
https://etherpad.openstack.org/p/juno-cinder-cinder-consistency-groups; 
basically, the volume driver just needs to get an 
additional value associate into this group.



 EULA


Now, there'll be quite a few things I forgot to mention, or that I'm 
simply missing. Please bear with me, I'm fairly new to OpenStack.


So ... ideas, comments, other feedback?


Regards,

Phil

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


Re: [openstack-dev] [Horizon] Use of AngularJS

2014-06-03 Thread Jiri Tomasek

On 05/29/2014 05:30 PM, Musso, Veronica A wrote:

Hello,

During the last Summit the use of AngularJS in Horizon was discussed and there 
is the intention to do a better use of it in the dashboards.
  I think this blueprint could help 
https://blueprints.launchpad.net/horizon/+spec/django-angular-integration, 
since it proposes the integration of Django-Angular 
(http://django-angular.readthedocs.org/en/latest/index.html).
I would like to know the community opinion about it, due I could start its 
implementation.

Thanks!

Best Regards,
Verónica Musso

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thanks for bringing this up. We have been discussing including this lib 
before and I think using it's features are beneficial. I'll have a 
broader look at it.


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


[openstack-dev] [Glance]: V2 api support for download_image policy?

2014-06-03 Thread Kekane, Abhishek
Hi All,

Can anyone let me know whether is download_image policy applicable only for V1 
api and not for V2 api?

Thanks  Regards,

Abhishek

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Introducing task oriented workflows

2014-06-03 Thread Hirofumi Ichihara
Hi, Salvatore

 It is totally correct that most Neutron resources have a sloppy status 
 management. Mostly because, as already pointed out, the 'status' for most 
 resource was conceived to be a 'network fabric' status rather than a resource 
 synchronisation status.
Exactly, I reckon that neutron needs resource synchronization status.

 As it emerged from previous posts in this thread, I reckon we have three 
 choices:
 1) Add a new attribute for describing configuration state. For instance 
 this will have values such as PENDING_UPDATE, PENDING_DELETE, IN_SYNC, 
 OUT_OF_SYNC, etc.
 2) Merge status and configuration statuses in a single attribute. This will 
 probably result simpler from a client perspective, but there are open 
 questions such as whether a resource for which a task is in progress and is 
 down should be reported as 'down' or 'pending_updage'.
 3) Not use any new flags, and use tasks to describe whether there are 
 operations in progress on a resource.
 The status attribute will describe exclusively the 'fabric' status of a 
 resources; however tasks will be exposed through the API - and a resource in 
 sync will be a resource with no PENDING or FAILED task active on it.
Good suggestions.
I reckon that choice (3) is discussion about new API and choice (1) (2) are 
discussion about current API.
It is not good the problem of current API continues remaining in the future.
So they should be discussed individually and improve the fabric status by (1) 
or (2). 
When (3) will be achieved, if neutron has same fabric status problem, users may 
be confused about the difference between resource status and task status. 
Additionally, to be exact, the task show not resource status but API process 
status.

I reckon we should improve the fabric status, then add task to neutron.
Also, I think (2) is good. Because there is performance of LBaaS model.

thanks,
Hirofumi

-
市原 裕史 (Ichihara Hirofumi)
NTTソフトウェアイノベーションセンタ
Tel:0422-59-2843  Fax:0422-59-2699
Email:ichihara.hirof...@lab.ntt.co.jp
-


On 2014/05/30, at 17:57, Salvatore Orlando sorla...@nicira.com wrote:

 Hi Hirofumi,
 
 I reckon this has been immediately recognised as a long term effort.
 However, I just want to clarify that by long term I don't mean pushing it 
 back until we get to the next release cycle and we realize we are in the same 
 place where we are today!
 
 It is totally correct that most Neutron resources have a sloppy status 
 management. Mostly because, as already pointed out, the 'status' for most 
 resource was conceived to be a 'network fabric' status rather than a resource 
 synchronisation status.
 
 As it emerged from previous posts in this thread, I reckon we have three 
 choices:
 1) Add a new attribute for describing configuration state. For instance 
 this will have values such as PENDING_UPDATE, PENDING_DELETE, IN_SYNC, 
 OUT_OF_SYNC, etc.
 2) Merge status and configuration statuses in a single attribute. This will 
 probably result simpler from a client perspective, but there are open 
 questions such as whether a resource for which a task is in progress and is 
 down should be reported as 'down' or 'pending_updage'.
 3) Not use any new flags, and use tasks to describe whether there are 
 operations in progress on a resource.
 The status attribute will describe exclusively the 'fabric' status of a 
 resources; however tasks will be exposed through the API - and a resource in 
 sync will be a resource with no PENDING or FAILED task active on it.
 
 The above are just options at the moment; I tend to lean toward the latter, 
 but it would be great to have your feedback.
 
 Salvatore
 
 
 
 On 28 May 2014 11:20, Hirofumi Ichihara ichihara.hirof...@lab.ntt.co.jp 
 wrote:
 Hi, Salvatore
 
 I think neutron needs the task management too.
 
 IMO, the problem of neutron resource status should be discussed individually.
 Task management enable neutron to roll back API operation and delete trash of 
 resource, try API operation again in one API process.
 Of course, we can use task to correct inconsistency between neutron 
 DB(resource status) and actual resource configuration.
 But, we should add resource status management to some resources before task.
 For example, LBaaS has resource status management[1].
 Neutron router, port don't mange status is basic problem.
 
 For instance a port is UP if it's been wired by the OVS agent; it often 
 does not tell us whether the actual resource configuration is exactly the 
 desired one in the database. For instance, if the ovs agent fails to apply 
 security groups to a port, the port stays ACTIVE and the user might never 
 know there was an error and the actual state diverged from the desired one.
 So, we should solve this problem by resource status management such LBaaS 
 rather than task.
 
 I don't deny task, but we need to discuss for task long term, I hope the 
 status management will be 

Re: [openstack-dev] [sahara] 2014.1.1 preparation

2014-06-03 Thread Sergey Lukjanov
Here is etherpad to track preparation -
https://etherpad.openstack.org/p/sahara-2014.1.1

On Tue, Jun 3, 2014 at 10:08 AM, Sergey Lukjanov slukja...@mirantis.com wrote:
 /me proposing to backport:

 Docs:

 https://review.openstack.org/#/c/87531/ Change IRC channel name to
 #openstack-sahara
 https://review.openstack.org/#/c/96621/ Added validate_edp method to
 Plugin SPI doc
 https://review.openstack.org/#/c/89647/ Updated architecture diagram in docs

 EDP:

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

 On Tue, Jun 3, 2014 at 10:03 AM, Sergey Lukjanov slukja...@mirantis.com 
 wrote:
 Hey folks,

 this Thu, June 5 is the date for 2014.1.1 release. We already have
 some back ported patches to the stable/icehouse branch, so, the
 question is do we need some more patches to back port? Please, propose
 them here.

 2014.1 - stable/icehouse diff:
 https://github.com/openstack/sahara/compare/2014.1...stable/icehouse

 Thanks.

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

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


Re: [openstack-dev] [Neutron] Introducing task oriented workflows

2014-06-03 Thread Robert Collins
On 23 May 2014 10:34, Salvatore Orlando sorla...@nicira.com wrote:
 As most of you probably know already, this is one of the topics discussed
 during the Juno summit [1].
 I would like to kick off the discussion in order to move towards a concrete
 design.

 Preamble: Considering the meat that's already on the plate for Juno, I'm not
 advocating that whatever comes out of this discussion should be put on the
 Juno roadmap. However, preparation (or yak shaving) activities that should
 be identified as pre-requisite might happen during the Juno time frame
 assuming that they won't interfere with other critical or high priority
 activities.
 This is also a very long post; the TL;DR summary is that I would like to
 explore task-oriented communication with the backend and how it should be
 reflected in the API - gauging how the community feels about this, and
 collecting feedback regarding design, constructs, and related
 tools/techniques/technologies.

Hi, thanks for writing this up.

A few thoughts:

 - if there can be only one task on a resource at a time, you're
essentially forcing all other clients to poll for task completion
before coming back to do *their* change. Its kindof a pathological
edge case of no in-flight-conflicts :).
 - Please please please don't embed polling into the design - use
webhooks or something similar so that each client (be that Nova,
Ironic, Horizon or what-have-you - can get a push response when the
thing they want to happen has happened).
 - I'd think very very carefully about whether you're actually
modelling /tasks/ or whether tasks are the implementation and really
the core issue is modelling the desired vs obtained resource state
 - Ironic has a debate going on right now about very much the same
problem - the latency involved in some API tasks, and whether the API
should return when complete, or when the work his guaranteed to start,
or even immediately and maybe the work isn't guaranteed to start.

My feeling is that we need to balance ease and correctness of
implementation, ease (and efficiency/correctness) of use, and
robustness - an entirely non-blocking API might end up being the
polling nightmare of nightmares if not done carefully, for instance.

-Rob

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


Re: [openstack-dev] [sahara] 2014.1.1 preparation

2014-06-03 Thread Dmitry Mescheryakov
I agree with Andrew and actually think that we do need to have
https://review.openstack.org/#/c/87573 (Fix running EDP job on
transient cluster) fixed in stable branch.

We also might want to add https://review.openstack.org/#/c/93322/
(Create trusts for admin user with correct tenant name). This is
another fix for transient clusters, but it is not even merged into
master branch yet.

Thanks,

Dmitry

2014-06-03 13:27 GMT+04:00 Sergey Lukjanov slukja...@mirantis.com:
 Here is etherpad to track preparation -
 https://etherpad.openstack.org/p/sahara-2014.1.1

 On Tue, Jun 3, 2014 at 10:08 AM, Sergey Lukjanov slukja...@mirantis.com 
 wrote:
 /me proposing to backport:

 Docs:

 https://review.openstack.org/#/c/87531/ Change IRC channel name to
 #openstack-sahara
 https://review.openstack.org/#/c/96621/ Added validate_edp method to
 Plugin SPI doc
 https://review.openstack.org/#/c/89647/ Updated architecture diagram in docs

 EDP:

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

 On Tue, Jun 3, 2014 at 10:03 AM, Sergey Lukjanov slukja...@mirantis.com 
 wrote:
 Hey folks,

 this Thu, June 5 is the date for 2014.1.1 release. We already have
 some back ported patches to the stable/icehouse branch, so, the
 question is do we need some more patches to back port? Please, propose
 them here.

 2014.1 - stable/icehouse diff:
 https://github.com/openstack/sahara/compare/2014.1...stable/icehouse

 Thanks.

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.

 ___
 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] [sahara] 2014.1.1 preparation

2014-06-03 Thread Sergey Lukjanov
Okay, it makes sense, I've updated the etherpad -
https://etherpad.openstack.org/p/sahara-2014.1.1

Here is the chain of backports for 2014.1.1 -
https://review.openstack.org/#/q/topic:sahara-2014.1.1,n,z

Review appreciate, all changes are cherry-picked and only one conflict
was in https://review.openstack.org/#/c/97458/1/sahara/swift/swift_helper.py,cm
due to the multi-region support addition.

Thanks.

On Tue, Jun 3, 2014 at 1:48 PM, Dmitry Mescheryakov
dmescherya...@mirantis.com wrote:
 I agree with Andrew and actually think that we do need to have
 https://review.openstack.org/#/c/87573 (Fix running EDP job on
 transient cluster) fixed in stable branch.

 We also might want to add https://review.openstack.org/#/c/93322/
 (Create trusts for admin user with correct tenant name). This is
 another fix for transient clusters, but it is not even merged into
 master branch yet.

 Thanks,

 Dmitry

 2014-06-03 13:27 GMT+04:00 Sergey Lukjanov slukja...@mirantis.com:
 Here is etherpad to track preparation -
 https://etherpad.openstack.org/p/sahara-2014.1.1

 On Tue, Jun 3, 2014 at 10:08 AM, Sergey Lukjanov slukja...@mirantis.com 
 wrote:
 /me proposing to backport:

 Docs:

 https://review.openstack.org/#/c/87531/ Change IRC channel name to
 #openstack-sahara
 https://review.openstack.org/#/c/96621/ Added validate_edp method to
 Plugin SPI doc
 https://review.openstack.org/#/c/89647/ Updated architecture diagram in docs

 EDP:

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

 On Tue, Jun 3, 2014 at 10:03 AM, Sergey Lukjanov slukja...@mirantis.com 
 wrote:
 Hey folks,

 this Thu, June 5 is the date for 2014.1.1 release. We already have
 some back ported patches to the stable/icehouse branch, so, the
 question is do we need some more patches to back port? Please, propose
 them here.

 2014.1 - stable/icehouse diff:
 https://github.com/openstack/sahara/compare/2014.1...stable/icehouse

 Thanks.

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.

 ___
 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



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

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


Re: [openstack-dev] [Horizon] How to conditionally modify attributes in CreateNetwork class.

2014-06-03 Thread Timur Sufiev
Hello, Nader!

As for `contributes` attribute, you could override `contribute(self,
data, context)` method in your descendant of `workflows.Step` which by
default simply iterates over all keys in `contributes`.

Either you could use even more flexible approach (which also fits for
`default_steps`): define in your `workflows.Step` descendants methods
`contributes(self)` and `default_steps(self)` (with the conditional
logic you need) and then decorate them with @property.

On Fri, May 30, 2014 at 10:15 AM, Nader Lahouti nader.laho...@gmail.com wrote:
 Hi All,

 Currently in the
 horizon/openstack_dashboard/dashboards/project/networks/workflows.py in
 classes such as CreateNetwork, CreateNetworkInfo and CreateSubnetInfo, the
 contributes or default_steps as shown below are fixed. Is it possible to add
 entries to those attributes conditionally?

 156class CreateSubnetInfo(workflows.Step):
 157action_class = CreateSubnetInfoAction
 158contributes = (with_subnet, subnet_name, cidr,
 159   ip_version, gateway_ip, no_gateway)
 160

 262class CreateNetwork(workflows.Workflow):
 263slug = create_network
 264name = _(Create Network)
 265finalize_button_name = _(Create)
 266success_message = _('Created network %s.')
 267failure_message = _('Unable to create network %s.')
 268default_steps = (CreateNetworkInfo,
 269 CreateSubnetInfo,
 270 CreateSubnetDetail)

 Thanks for your input.

 Nader.


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




-- 
Timur Sufiev

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


[openstack-dev] [nova] Libvirt Sub-Team Meeting: Call for agenda June 3rd, 2014

2014-06-03 Thread Daniel P. Berrange
If anyone has agenda items they'd like to discuss in today's Nova Libvirt
sub-team meeting[1] please add them to the etherpad:

   https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda

Regards,
Daniel

[1] https://wiki.openstack.org/wiki/Meetings/Libvirt
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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


Re: [openstack-dev] [neutron] blueprint ovs-firewall-driver: OVS implementation of security groups

2014-06-03 Thread CARVER, PAUL

Amir Sadoughi wrote:

Specifically, OVS lacks connection tracking so it won't have a RELATED feature 
or stateful rules
for non-TCP flows. (OVS connection tracking is currently under development, to 
be released by 2015

It definitely needs a big obvious warning label on this. A stateless firewall 
hasn't been acceptable in serious
security environments for at least a decade. Real firewalls do things like 
TCP sequence number validation
to ensure that someone isn't hi-jacking an existing connection and TCP flag 
validation to make sure that someone
isn't fuzzing by sending invalid combinations of flags in order to uncover 
bugs in servers behind the firewall.


- debugging OVS is new to users compared to debugging old iptables

This one is very important in my opinion. There absolutely needs to be a 
section in the documentation
on displaying and interpreting the rules generated by Neutron. I'm pretty sure 
that if you tell anyone
with Linux admin experience that Neutron security groups are iptables based, 
they should be able to
figure their way around iptables -L or iptables -S without much help.

If they haven't touched iptables in a while, five minutes reading man 
iptables should be enough
for them to figure out the important options and they can readily see the 
relationship between
what they put in a security group and what shows up in the iptables chain. I 
don't think there's
anywhere near that ease of use on how to list the OvS ruleset for a VM and see 
how it corresponds
to the Neutron security group.


Finally, logging of packets (including both dropped and permitted connections) 
is mandatory in many
environments. Does OvS have the ability to do the necessary logging? Although 
Neutron
security groups don't currently enable logging, the capabilities are present in 
the underlying
iptables and can be enabled with some work. If OvS doesn't support logging of 
connections then
this feature definitely needs to be clearly marked as not a firewall 
substitute so that admins
are clearly informed that they still need a real firewall for audit 
compliance and may only
consider OvS based Neutron security groups as an additional layer of protection 
behind the
real firewall.

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


Re: [openstack-dev] [Glance]: V2 api support for download_image policy?

2014-06-03 Thread stuart . mclaren

Hi Abishek,

download_image *should* apply to v2 in the same way as v1 I think.

If that's not what you're seeing can you enter a bug (with details) in 
launchpad?

https://bugs.launchpad.net/glance

Typically you'd mark it with 'private security' but 'public security'
makes sense now.

Thanks!

-Stuart


Hi All,

Can anyone let me know whether is download_image policy applicable only for V1 
api and not for V2 api?

Thanks  Regards,

Abhishek

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.
If you are not the intended recipient, please advise the sender by replying 
promptly to this email and then delete and destroy this email and any 
attachments without any further use,
copying or forwarding
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openstack.org/pipermail/openstack-dev/attachments/20140603/b4236c77/attachment-0001.html


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


Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

2014-06-03 Thread Jaromir Coufal


Yeah, Robert is right. I think, everybody who is approved by his 
employer (or is expected to be approved) should enter his constraints. 
So realistically enter dates when you would be able to attend.


Personal view: after Aug 11th, we will have about 3 weeks to feature 
freeze which is very late I would say. I would better target the meetup 
to July.


-- Jarda



On 2014/02/06 22:52, Robert Collins wrote:

I think you should add the constraints you have.

Realistically though, not every will be there, and thats fine. There
are some folk we'll need there (e.g. I suspect I'm one of those, but
maybe not!)

My constraints are:
- need to be in Sydney for the 1st-5th, remembering there is an
international date line between NC and Sydney.
- need to be home for most of a week between the mid cycle meetup and
PyCon AU (family).

So I can do anytime from Aug 11th on, or anytime ending before or on
July the 25th - and I'm going to put that in the etherpad now :0

-Rob



On 3 June 2014 04:51, Ben Nemec openst...@nemebean.com wrote:

On 05/30/2014 06:58 AM, Jaromir Coufal wrote:

On 2014/30/05 10:00, Thomas Spatzier wrote:

Excerpt from Zane Bitter's message on 29/05/2014 20:57:10:


From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org
Date: 29/05/2014 20:59
Subject: Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle
collaborative meetup

snip

BTW one timing option I haven't seen mentioned is to follow Pycon-AU's
model of running e.g. Friday-Tuesday (July 25-29). I know nobody wants
to be stuck in Raleigh, NC on a weekend (I've lived there, I understand
;), but for folks who have a long ways to travel it's one weekend lost
instead of two.


+1 - excellent idea!


It looks that there is an interest in these dates, so I added 3rd option
to the etherpad [0].

For one more time, I would like to ask potential attendees to put
yourselves to dates which would work for you.

-- Jarda

[0] https://etherpad.openstack.org/p/juno-midcycle-meetup


Just to clarify, I should add my name to the list if I _can_ make it to
a given proposal, even if I don't know for sure that I will be going?

I don't know what the travel situation is yet so I can't commit to being
there on any dates, but I can certainly say which dates would work for
me if I can make it.

-Ben


___
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] [Rally] Tempest + Rally: first success

2014-06-03 Thread om prakash pandey
Hi Andrey,

Thanks a ton for putting together this blog on using tempest + rally.

I followed all the steps listed and managed to get tempest successfully
installed.

However, I was not able to proceed beyond and couldn't manage to run
tempest even once. I am getting the below error:

om@desktop2:~/rally$ rally verify start --set image
Command failed, please check log for more info
2014-06-03 18:14:56.029 8331 CRITICAL rally [-] IndexError: list index out
of range

What did I mess up while following the blog?

Regards
Om


On Sat, May 31, 2014 at 3:46 AM, Andrey Kurilin akuri...@mirantis.com
wrote:

 Hi stackers,

 I would like to share with you great news.
 We all know that it's quite hard to use Tempest out of gates, especially
 when you are going to benchmark different clouds, run just part of tests
 and would like to store somewhere results. As all this stuff doesn't belong
 to Tempest, we decided to make it in Rally.

 More details about how to use Tempest in one click in my tutorial:
 http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/

 --
 Best regards,
 Andrey Kurilin.

 ___
 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] [Barbican] KMIP support

2014-06-03 Thread Nathan Reller
 I was wondering about the progress of KMIP support in Barbican?

As John pointed out, JHU/APL is working on adding KMIP support to Barbican.
We submitted the first CR to add a Secret Store interface into Barbican.
The next step is to add a KMIP implementation of the Secret Store.

 Is this waiting on an open python KMIP support?

We are working in parallel to add KMIP support to Barbican and to release
an open source version of a Python KMIP library. We would like to have both
out by Juno.

 Also, is the “OpenStack KMIP Client” ever going to be a thing?
 (https://wiki.openstack.org/wiki/KMIPclient)

That work was not proposed by us, so I can't comment on the status of that.
Right now our path forward is to support Barbican by adding a KMIP Secret
Store.

-Nate

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


[openstack-dev] [Trove] Configurable DB Plugins - BP flushed out

2014-06-03 Thread boden

Guys,
In the BP meeting yesterday we briefly discussed the 'Configurable DB 
Plugins' BP: 
https://blueprints.launchpad.net/trove/+spec/configurable-db-plugins


It was clear I needed to hash this one out in greater detail to 
optimally discuss the feature with the group - I've done that and you 
can find the details here: 
https://wiki.openstack.org/wiki/Trove/ConfigurableDBPlugins


Given I will be traveling next week, I won't be at the BP meeting. 
Therefore I look forward to any feedback / comments / etc via the BP 
wiki or email. Otherwise this one will have to wait until the BP meeting 
on the 16th.


Thanks


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


[openstack-dev] [compute] Server parameters for Create Server

2014-06-03 Thread Sam Harwell
I'm having trouble determining which parameters may be included in the Create 
Server request. In particular, I'm interested in the JSON properties which are 
supported by a base installation of Compute V2.

The documentation on the following page is not clear:
http://docs.openstack.org/api/openstack-compute/2/content/POST_createServer__v2__tenant_id__servers_CreateServers.html

The examples in that documentation include properties like max_count and 
min_count that I could not find a description for, and security_groups which 
appears to be a property added by an extension as opposed to being part of the 
base implementation of Create Server.

The separation of every JSON property according to the location where they are 
defined (base OpenStack installation, OpenStack-defined extension, or 
vendor-specific extension is a key design aspect of the SDK I am working on. 
How can I determine this information according to the documentation?

Thank you,
Sam Harwell
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [neutron] Port leak when instance fails to boot normally

2014-06-03 Thread Matthew Gilliard
Bug report: https://bugs.launchpad.net/nova/+bug/1324934

TL;DR version of the bug report:  A dropped connection during nova-neutron
call to create a port will result in nova deciding that the instance can't
be booted, and therefore terminating it.  Nova calls get_ports() from
neutron during this termination, but an empty list is returned so no ports
are deleted.  However, the port actually is created, and associated to the
now-deleted instance.

I suspect there is a race condition between create_port and get_ports in
neutron, which could be fixed by using
@lockutils.synchronized(nstance_uuid) on those 2 methods.

I'm not very familiar with the neutron codebase though, and would
appreciate some feedback or discussion on how likely people think my
diagnosis and suggested fix are, and whether similar problems have been
found in the past.

  Thanks,

Matthew Gilliard
(HP Cloud)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] request for review

2014-06-03 Thread Kyle Mestery
On Tue, Jun 3, 2014 at 12:49 AM, YAMAMOTO Takashi
yamam...@valinux.co.jp wrote:
 can anyone please review this small fix for ofagent?
 https://review.openstack.org/#/c/88224/
 it's unfortunate a simple fix like this taking months to be merged.

Done, looks like Nachi beat me to it but it's in the check queue
again.

 YAMAMOTO Takashi

 ___
 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-compute rpc version

2014-06-03 Thread abhishek jain
Hi Russell

Thanks
I'm able to solve it now by switching onto havana release on both the
controller node and compute node.







On Tue, Jun 3, 2014 at 10:56 AM, abhishek jain ashujain9...@gmail.com
wrote:

 Hi Russell

 Below are the details...

 controller node...

 nova --version
 2.17.0.122

 nova-compute  --version
 2014.2

 compute node.

 nova --version
 2.17.0.122

 nova-compute --version
 2013.2.4

 Can you help me what i need to change in order to achieve the desired
 functioonality.



 Thaks


 On Tue, Jun 3, 2014 at 2:16 AM, Russell Bryant rbry...@redhat.com wrote:

 On 06/02/2014 08:20 AM, abhishek jain wrote:
  |Hi
  |
 
  |
  I'm getting following error in nova-compute logs when trying to boot VM
 from controller node onto compute node ...
 
   Specified RPC version, 3.23, not supported
 
  Please help regarding this.

 It sounds like you're using an older nova-compute with newer controller
 services (without the configuration to allow a live ugprade).  Check the
 versions of Nova services you have running.

 --
 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] [Neutron] Introducing task oriented workflows

2014-06-03 Thread Sam Harwell
When considering user interfaces, the choice of task and/or status reporting 
methods can have a big impact on the ability to communicate with the user. In 
particular, status properties (e.g. in the manner of compute V2 servers) 
prevent user interfaces from associating the result of an operation with a 
description of an executed action. Even though a REST API is a theoretically a 
set of synchronous operations to transform basic data resources, in reality 
users are initiating actions against their account that do not reach their 
final state immediately.

In designing an API, the ability to provide users with relevant information 
about decisions and actions they take is of utmost importance. Since a separate 
task representation (e.g. glance) does support providing users with information 
about the ongoing and final result of specific actions they perform, where a 
status field does not, we will eventually need to use a task representation in 
order to properly support our users.

Also, the specific detail of whether a resource supports more than one 
asynchronous operation concurrently (or supports queueing of task operations) 
is not applicable to this decision. Cloud resources are inherently a 
distributed system, and individual clients are not able to determine which 
status is associated with particular actions. For example, consider the 
following:

1. Client A request operation X be performed
2. Operation X completes successfully
3. Client B requests operation Y be performed
4. Operation Y results in the resource entering an error state
5. Client A checks the status of the resource

In this scenario, Client A is unable to report to the user which operation 
resulted in the resource entering its current error state. If it attempts to 
report the information according to the information available to it, the user 
would be under the impression that Operation X caused the resource to enter the 
error state, with clearly negative impacts on their ability to understand the 
problem(s) encountered and steps they should take to resolve the situation 
during their use of the API.

Please keep in mind that this message is not related to particular 
implementation, storage mechanism, or the manner in which clients communicate 
with the server. I am simply pointing out that the needs of end users can only 
be properly met by ensuring that particular information is available through 
the API their applications are using. This is (or should be) the primary driver 
for design decisions made during the creation of each API.

Thank you,
Sam Harwell

-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net] 
Sent: Tuesday, June 03, 2014 4:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Introducing task oriented workflows

On 23 May 2014 10:34, Salvatore Orlando sorla...@nicira.com wrote:
 As most of you probably know already, this is one of the topics discussed
 during the Juno summit [1].
 I would like to kick off the discussion in order to move towards a concrete
 design.

 Preamble: Considering the meat that's already on the plate for Juno, I'm not
 advocating that whatever comes out of this discussion should be put on the
 Juno roadmap. However, preparation (or yak shaving) activities that should
 be identified as pre-requisite might happen during the Juno time frame
 assuming that they won't interfere with other critical or high priority
 activities.
 This is also a very long post; the TL;DR summary is that I would like to
 explore task-oriented communication with the backend and how it should be
 reflected in the API - gauging how the community feels about this, and
 collecting feedback regarding design, constructs, and related
 tools/techniques/technologies.

Hi, thanks for writing this up.

A few thoughts:

 - if there can be only one task on a resource at a time, you're
essentially forcing all other clients to poll for task completion
before coming back to do *their* change. Its kindof a pathological
edge case of no in-flight-conflicts :).
 - Please please please don't embed polling into the design - use
webhooks or something similar so that each client (be that Nova,
Ironic, Horizon or what-have-you - can get a push response when the
thing they want to happen has happened).
 - I'd think very very carefully about whether you're actually
modelling /tasks/ or whether tasks are the implementation and really
the core issue is modelling the desired vs obtained resource state
 - Ironic has a debate going on right now about very much the same
problem - the latency involved in some API tasks, and whether the API
should return when complete, or when the work his guaranteed to start,
or even immediately and maybe the work isn't guaranteed to start.

My feeling is that we need to balance ease and correctness of
implementation, ease (and efficiency/correctness) of use, and
robustness - an entirely non-blocking API might end up 

[openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler

2014-06-03 Thread Jay Pipes

Hi Stackers,

tl;dr
=

Move CPU and RAM allocation ratio definition out of the Nova scheduler 
and into the resource tracker. Remove the calculations for overcommit 
out of the core_filter and ram_filter scheduler pieces.


Details
===

Currently, in the Nova code base, the thing that controls whether or not 
the scheduler places an instance on a compute host that is already 
full (in terms of memory or vCPU usage) is a pair of configuration 
options* called cpu_allocation_ratio and ram_allocation_ratio.


These configuration options are defined in, respectively, 
nova/scheduler/filters/core_filter.py and 
nova/scheduler/filters/ram_filter.py.


Every time an instance is launched, the scheduler loops through a 
collection of host state structures that contain resource consumption 
figures for each compute node. For each compute host, the core_filter 
and ram_filter's host_passes() method is called. In the host_passes() 
method, the host's reported total amount of CPU or RAM is multiplied by 
this configuration option, and the product is then subtracted from the 
reported used amount of CPU or RAM. If the result is greater than or 
equal to the number of vCPUs needed by the instance being launched, True 
is returned and the host continues to be considered during scheduling 
decisions.


I propose we move the definition of the allocation ratios out of the 
scheduler entirely, as well as the calculation of the total amount of 
resources each compute node contains. The resource tracker is the most 
appropriate place to define these configuration options, as the resource 
tracker is what is responsible for keeping track of total and used 
resource amounts for all compute nodes.


Benefits:

 * Allocation ratios determine the amount of resources that a compute 
node advertises. The resource tracker is what determines the amount of 
resources that each compute node has, and how much of a particular type 
of resource have been used on a compute node. It therefore makes sense 
to put calculations and definition of allocation ratios where they 
naturally belong.
 * The scheduler currently needlessly re-calculates total resource 
amounts on every call to the scheduler. This isn't necessary. The total 
resource amounts don't change unless either a configuration option is 
changed on a compute node (or host aggregate), and this calculation can 
be done more efficiently once in the resource tracker.

 * Move more logic out of the scheduler
 * With the move to an extensible resource tracker, we can more easily 
evolve to defining all resource-related options in the same place 
(instead of in different filter files in the scheduler...)


Thoughts?

Best,
-jay

* Host aggregates may also have a separate allocation ratio that 
overrides any configuration setting that a particular host may have


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


[openstack-dev] [OSSG][OSSN] Cinder wipe fails in an insecure manner on Grizzly

2014-06-03 Thread Nathan Kinder
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cinder wipe fails in an insecure manner on Grizzly
- ---

### Summary ###
A configuration error can prevent the secure erase of volumes in Cinder
on Grizzly, potentially allowing a user to recover another user’s data.

### Affected Services / Software ###
Cinder, Grizzly

### Discussion ###
In Cinder on Grizzly, a configurable method to perform a secure erase of
volumes was added. In the event of a misconfiguration no secure erase
will be performed.

The default code path in Cinder’s clear_volume() method, which is taken
in the event of a configuration error, results in no wiping of the
volume - even in the event that the user had flagged the volume for
wiping.

This is the same behaviour as if the volume_clear = ‘none’ option was
selected. This could let an attacker recover data from a volume that was
intended to be securely erased. Examples of possible incorrect
configuration options include values that would appear to result in a
secure erase, for example “volume_clear = true” or “volume_clear =
yes”.

In the event of a misconfiguration resulting in this issue, the message
“Error unrecognized volume_clear option” should be present in log
files.

### Recommended Actions ###
- - Create and clear a volume (cinder create --display_name erasetest 10;
cinder delete erasetest)
- - Review log files for the above error message (grep “Error unrecognized
volume_clear option” logfile)
- - Review configuration files to ensure that the valid options ‘zero’ or
‘shred’ are specified.


### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0016
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1322766
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTjc5hAAoJEJa+6E7Ri+EVm6EH/i0IseGxSHb0il1ryDUu56K7
GwX0P72pBQ90BGaJdaLR0t/w68o9hZXFmGJxVZk/8nq0cI+FriEXa8QDCuNwWe2X
vgJ4YoqlvD9jy2V5MUV/WaP99QBnCVClj9Gr0h21YzFJe+mvyAFLKY8HMbhrxUgv
dkhtYUodDQnjSNjVO6s5hzsCYDjti78aPnzgiP2Y7bsHrOkVgRy4a1qt281btPWd
ZklXviqvvO2hI1ZSsH5JkjzLTD3THN260TIkIrVThUOm0TK3iC3JOu+f+FoTOXGg
gHXR0DyIoVldqtn1Nmcd4OY/Wx9bav6jPyPPhfcAAsbbipCzUY/WtRe9pm/gJI0=
=W3y3
-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] [Rally] Tempest + Rally: first success

2014-06-03 Thread Andrey Kurilin
Hey, Om!
Can you launch Rally in debug mode and share logs?
 rally -vd verify start --set image


On Tue, Jun 3, 2014 at 3:49 PM, om prakash pandey pande...@gmail.com
wrote:

 Hi Andrey,

 Thanks a ton for putting together this blog on using tempest + rally.

 I followed all the steps listed and managed to get tempest successfully
 installed.

 However, I was not able to proceed beyond and couldn't manage to run
 tempest even once. I am getting the below error:

 om@desktop2:~/rally$ rally verify start --set image
 Command failed, please check log for more info
 2014-06-03 18:14:56.029 8331 CRITICAL rally [-] IndexError: list index out
 of range

 What did I mess up while following the blog?

 Regards
 Om


 On Sat, May 31, 2014 at 3:46 AM, Andrey Kurilin akuri...@mirantis.com
 wrote:

 Hi stackers,

 I would like to share with you great news.
 We all know that it's quite hard to use Tempest out of gates, especially
 when you are going to benchmark different clouds, run just part of tests
 and would like to store somewhere results. As all this stuff doesn't belong
 to Tempest, we decided to make it in Rally.

 More details about how to use Tempest in one click in my tutorial:
 http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/

 --
 Best regards,
 Andrey Kurilin.

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



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




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


Re: [openstack-dev] Glance

2014-06-03 Thread Evgeny Kozhemyakin
Hi,

Tizy Ninan wrote :
 We have an openstack deployment (Havana on CentOS) in HA mode with
 nova-network service deployed using Mirantis Fuel v4.0 .
 When uploading images with large filesize (more than 1 GB) from dashboard,
 after upload is done the dashboard is showing 504 Gateway Timeout. What
 could be the problem? Can anyone please help me on resolving this issue?

Your problem is not a glance's or dashboard's bug. It's because of
timeouts configured for haproxy.
It doesn't have any impact on your deployment, the images are still
uploading. But you can adjust this parameters in
/etc/haproxy/haproxy.conf on your nodes. There are several ones, I think
you need the server timeout.


ps:
 This is a discussion that definitely belongs on the users list:
sorry for replying here

-- 
Regards,
Evgeny Kozhemyakin (EVK-RIPE)

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


Re: [openstack-dev] [neutron] blueprint ovs-firewall-driver: OVS implementation of security groups

2014-06-03 Thread Carl Baldwin
How does ovs handle tcp flows?  Does it include stateful tracking of tcp --
as your wording below implies -- or does it do stateless inspection of
returning tcp packets?  It appears it is the latter.  This isn't the same
as providing a stateful ESTABLISHED feature.  Many users may not fully
understand the differences.

One of the most basic use cases, which is to ping an outside Ip address
from inside a nova instance would not work without connection tracking with
the default security groups which don't allow ingress except related and
established.  This may surprise many.

Carl
 Hi all,

 In the Neutron weekly meeting today[0], we discussed the
ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will
give us 80% of the iptables security groups behavior. Specifically, OVS
lacks connection tracking so it won’t have a RELATED feature or stateful
rules for non-TCP flows. (OVS connection tracking is currently under
development, to be released by 2015[2]). To make the “20% difference more
explicit to the operator and end user, we have proposed feature
configuration to provide security group rules API validation that would
validate based on connection tracking ability, for example.

 Several ideas floated up during the chat today, I wanted to expand the
discussion to the mailing list for further debate. Some ideas include:
- marking ovs-firewall-driver as experimental in Juno
- What does it mean to be marked as “experimental”?
- performance improvements under a new OVS firewall driver untested so far
(vthapar is working on this)
- incomplete implementation will cause confusion, educational burden
- debugging OVS is new to users compared to debugging old iptables
- waiting for upstream OVS to implement (OpenStack K- or even L- cycle)

 In my humble opinion, merging the blueprint for Juno will provide us a
viable, more performant security groups implementation than what we have
available today.

 Amir


 [0]
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html
[1] https://review.openstack.org/#/c/89712/
[2] http://openvswitch.org/pipermail/dev/2014-May/040567.html

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


Re: [openstack-dev] [gantt] scheduler sub-group meeting agenda 6/3

2014-06-03 Thread Khanh-Toan Tran
Dear all,

If we have time, I would like to take your attention to my new patch:
Policy-based Scheduling engine

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

This patch implements Policy-Based Scheduler blueprint:

https://blueprints.launchpad.net/nova/+spec/policy-based-scheduler

I presented its prototype at Atlanta summit:

http://openstacksummitmay2014atlanta.sched.org/event/b4313b37de4645079e3d5
506b1d725df#.U43VqPl_tm4

It's a pity that the video of the demo is not yet available on OpenStack
channel. We've contacted the foundation on this topic.

Best regards,

Toan

 -Message d'origine-
 De : Dugger, Donald D [mailto:donald.d.dug...@intel.com]
 Envoyé : mardi 3 juin 2014 04:38
 À : OpenStack Development Mailing List (not for usage questions)
 Objet : [openstack-dev] [gantt] scheduler sub-group meeting agenda 6/3

 1) Forklift (tasks  status)
 2) No-db scheduler discussion (BP ref -
https://review.openstack.org/#/c/92128/
 )
 3) Opens

 --
 Don Dugger
 Censeo Toto nos in Kansa esse decisse. - D. Gale
 Ph: 303/443-3786


 ___
 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] RE: Compute capabilities filter

2014-06-03 Thread Maldonado, Facundo N
Hi all,

I have a patch for this bug ready for review: 
https://review.openstack.org/#/c/89844/
I also want to know your thought about Santiago's question.
Some time ago I found this bug (https://review.openstack.org/#/c/62088/) where 
the decision of deprecate the use
of instance_type_extra_specs configuration option was made 
(https://review.openstack.org/#/c/62088/).
As far as I understand, it only deprecate the ability to setup additional 
capabilities to each compute node thru the config file, not the filter. Am I 
right?
Thanks,
Facundo

From: Baldassin, Santiago B [mailto:santiago.b.baldas...@intel.com]
Sent: Monday, April 14, 2014 11:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Compute capabilities filter [openstack] [nova]

Hey folks,

I have a question regarding the ComputeCapabilitiesFilter. Such filter is not 
currently working https://bugs.launchpad.net/nova/+bug/1279719 and I'd like to 
know if, the filter is not working due to the mentioned bug but it should work 
or if there's any plan to deprecate that filter or to replace it with the 
AggregateInstanceExtraSpecsFilter

Thanks

Santiago B. Baldassin
ASDC Argentina
Software Development Center
Email: santiago.b.baldas...@intel.commailto:santiago.b.baldas...@intel.com
P Save a tree. Print only when necessary.

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


[openstack-dev] [NFV] Sub-team Meeting Reminder - Wednesday June 4 @ 1400 utc

2014-06-03 Thread Steve Gordon
Hi all,

Just a reminder that the first post-summit meeting of the sub-team is scheduled 
for Wednesday June 4 @ 1400 UTC in #openstack-meeting. 

Agenda:

First meeting!
Meet and greet
Review Mission
Review our current blueprint list and fill in anything we're not tracking 
yet
Review use case prioritization
Discuss tracking approaches:
Use cases
Blueprints
Bugs

The agenda is also available at https://wiki.openstack.org/wiki/Meetings/NFV 
for editing.

Thanks!

Steve

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


Re: [openstack-dev] [Neutron] Introducing task oriented workflows

2014-06-03 Thread Andrew Laski


On 05/22/2014 08:16 PM, Nachi Ueno wrote:

Hi Salvatore

Thank you for your posting this.

IMO, this topic shouldn't be limited for Neutron only.
Users wants consistent API between OpenStack project, right?

In Nova, a server has task_state, so Neutron should do same way.


We're moving away from the simple task_state field in Nova towards a 
more comprehensive task model.  See 
https://review.openstack.org/#/c/86938/ for the nova-spec around this.





2014-05-22 15:34 GMT-07:00 Salvatore Orlando sorla...@nicira.com:

As most of you probably know already, this is one of the topics discussed
during the Juno summit [1].
I would like to kick off the discussion in order to move towards a concrete
design.

Preamble: Considering the meat that's already on the plate for Juno, I'm not
advocating that whatever comes out of this discussion should be put on the
Juno roadmap. However, preparation (or yak shaving) activities that should
be identified as pre-requisite might happen during the Juno time frame
assuming that they won't interfere with other critical or high priority
activities.
This is also a very long post; the TL;DR summary is that I would like to
explore task-oriented communication with the backend and how it should be
reflected in the API - gauging how the community feels about this, and
collecting feedback regarding design, constructs, and related
tools/techniques/technologies.

At the summit a broad range of items were discussed during the session, and
most of them have been reported in the etherpad [1].

First, I think it would be good to clarify whether we're advocating a
task-based API, a workflow-oriented operation processing, or both.

-- About a task-based API

In a task-based API, most PUT/POST API operations would return tasks rather
than neutron resources, and users of the API will interact directly with
tasks.
I put an example in [2] to avoid cluttering this post with too much text.
As the API operation simply launches a task - the database state won't be
updated until the task is completed.

Needless to say, this would be a radical change to Neutron's API; it should
be carefully evaluated and not considered for the v2 API.
Even if it is easily recognisable that this approach has a few benefits, I
don't think this will improve usability of the API at all. Indeed this will
limit the ability of operating on a resource will a task is in execution on
it, and will also require neutron API users to change the paradigm the use
to interact with the API; for not mentioning the fact that it would look
weird if neutron is the only API endpoint in Openstack operating in this
way.
For the Neutron API, I think that its operations should still be
manipulating the database state, and possibly return immediately after that
(*) - a task, or to better say a workflow will then be started, executed
asynchronously, and update the resource status on completion.

-- On workflow-oriented operations

The benefits of it when it comes to easily controlling operations and
ensuring consistency in case of failures are obvious. For what is worth, I
have been experimenting introducing this kind of capability in the NSX
plugin in the past few months. I've been using celery as a task queue, and
writing the task management code from scratch - only to realize that the
same features I was implementing are already supported by taskflow.

I think that all parts of Neutron API can greatly benefit from introducing a
flow-based approach.
Some examples:
- pre/post commit operations in the ML2 plugin can be orchestrated a lot
better as a workflow, articulating operations on the various drivers in a
graph
- operation spanning multiple plugins (eg: add router interface) could be
simplified using clearly defined tasks for the L2 and L3 parts
- it would be finally possible to properly manage resources' operational
status, as well as knowing whether the actual configuration of the backend
matches the database configuration
- synchronous plugins might be converted into asynchronous thus improving
their API throughput

Now, the caveats:
- during the sessions it was correctly pointed out that special care is
required with multiple producers (ie: api servers) as workflows should be
always executed in the correct order
- it is probably be advisable to serialize workflows operating on the same
resource; this might lead to unexpected situations (potentially to
deadlocks) with workflows operating on multiple resources
- if the API is asynchronous, and multiple workflows might be queued or in
execution at a given time, rolling back the DB operation on failures is
probably not advisable (it would not be advisable anyway in any asynchronous
framework). If the API instead stays synchronous the revert action for a
failed task might also restore the db state for a resource; but I think that
keeping the API synchronous missed a bit the point of this whole work - feel
free to show your disagreement here!
- some neutron workflows are actually initiated 

Re: [openstack-dev] [Marconi] Adopt Spec

2014-06-03 Thread Kurt Griffiths
I think it becomes more useful the larger your team. With a smaller team it is 
easier to keep everyone on the same page just through the mailing list and IRC. 
As for where to document design decisions, the trick there is more one of being 
diligent about capturing and recording the why of every decision made in 
discussions and such; gerrit review history can help with that, but it isn’t 
free.

If we’d like to give the specs process a try, I think we could do an experiment 
in j-2 with a single bp. Depending on how that goes, we may do more in the K 
cycle. What does everyone think?

From: Malini Kamalambal 
malini.kamalam...@rackspace.commailto:malini.kamalam...@rackspace.com
Reply-To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, June 2, 2014 at 2:45 PM
To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Marconi] Adopt Spec

+1 – Requiring specs for every blueprint is going to make the development 
process very cumbersome, and will take us back to waterfall days.
I like how the Marconi team operates now, with design decisions being made in 
IRC/ team meetings.
So Spec might become more of an overhead than add value, given how our team 
functions.

'If' we agree to use Specs, we should use that only for the blue prints that 
make sense.
For example, the unit test decoupling that we are working on now – this one 
will be a good candidate to use specs, since there is a lot of back and forth 
going on how to do this.
On the other hand something like Tempest Integration for Marconi will not 
warrant a spec, since it is pretty straightforward what needs to be done.
In the past we have had discussions around where to document certain design 
decisions (e.g. Which endpoint/verb is the best fit for pop operation?)
Maybe spec is the place for these?

We should leave it to the implementor to decide, if the bp warrants a spec or 
not  what should be in the spec.


From: Kurt Griffiths 
kurt.griffi...@rackspace.commailto:kurt.griffi...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, June 2, 2014 1:33 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Marconi] Adopt Spec

I’ve been in roles where enormous amounts of time were spent on writing specs, 
and in roles where specs where non-existent. Like most things, I’ve become 
convinced that success lies in moderation between the two extremes.

I think it would make sense for big specs, but I want to be careful we use it 
judiciously so that we don’t simply apply more process for the sake of more 
process. It is tempting to spend too much time recording every little detail in 
a spec, when that time could be better spent in regular communication between 
team members and with customers, and on iterating the code (short iterations 
between demo/testing, so you ensure you are on staying on track and can address 
design problems early, often).

IMO, specs are best used more as summaries, containing useful big-picture 
ideas, diagrams, and specific “memory pegs” to help us remember what was 
discussed and decided, and calling out specific “promises” for future 
conversations where certain design points are TBD.

From: Malini Kamalambal 
malini.kamalam...@rackspace.commailto:malini.kamalam...@rackspace.com
Reply-To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, June 2, 2014 at 9:51 AM
To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Marconi] Adopt Spec

Hello all,

We are seeing more  more design questions in #openstack-marconi.
It will be a good idea to formalize our design process a bit more  start using 
spec.
We are kind of late to the party –so we already have a lot of precedent ahead 
of us.

Thoughts?

Malini

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


[openstack-dev] [Neutron] test configuration for ml2/ovs L2 and L3 agents

2014-06-03 Thread Carlino, Chuck
Hi all,

I'm struggling a bit to get a test set up working for L2/L3 work (ml2/ovs).  
I've been trying multi-host devstack (just controller node for now), and I must 
be missing something important because n-sch bombs out.  Single node devstack 
works fine, but it's not very useful for L2/L3.

Any suggestions, or maybe someone has some local.conf files they'd care to 
share?

Many thanks,
Chuck

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


Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler

2014-06-03 Thread Scott Devoid

 It may be useful to have an API query which tells you all the numbers you
 may need - real hardware values, values after using the configured
 overcommit ratios and currently used values.


+1 to an exposed admin-API for host resource state and calculations,
especially if this allowed you to dynamically change the ratios.


On Tue, Jun 3, 2014 at 10:20 AM, Jesse Pretorius jesse.pretor...@gmail.com
wrote:

 On 3 June 2014 15:29, Jay Pipes jaypi...@gmail.com wrote:

 Move CPU and RAM allocation ratio definition out of the Nova scheduler
 and into the resource tracker. Remove the calculations for overcommit out
 of the core_filter and ram_filter scheduler pieces.


 Makes sense to me.

 I especially like the idea of being able to have different allocation
 ratios for host aggregates.

 It may be useful to have an API query which tells you all the numbers you
 may need - real hardware values, values after using the configured
 overcommit ratios and currently used values.

 ___
 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] [Cinder] How to mock the LOG inside cinder driver

2014-06-03 Thread Deepak Shetty
deepakcs Hi, whats the right way to mock the LOG variable inside the
driver ? I am mocking mock.patch.object(glusterfs, 'LOG') as mock_logger
deepakcs and then doing...
deepakcs mock_logger.warning.assert_called_once() - which passes and is
expected to pass per my code
deepakcs but
deepakcs mock_logger.debug.assert_called_once() - shud fail , but this
also passes !
deepakcs any idea why ?

I feel that I am not mocking the LOG inside the driver correctly.

I also tried
   mock.patch.object(glusterfs.LOG, 'warning'),
mock.patch.object(glusterfs.LOG, 'debug')
as mock_logger_warn and mock_logger_debug respectively

But here too
.debug and .warning both passes.. while the expected result is for .warning
to pass and .debug to fail

So somehow I am unable to mock LOG properly

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


Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler

2014-06-03 Thread Chris Friesen

On 06/03/2014 07:29 AM, Jay Pipes wrote:

Hi Stackers,

tl;dr
=

Move CPU and RAM allocation ratio definition out of the Nova scheduler
and into the resource tracker. Remove the calculations for overcommit
out of the core_filter and ram_filter scheduler pieces.


Makes sense to me.

Chris


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


[openstack-dev] [horizon] Name proposals

2014-06-03 Thread Radomir Dopieralski
We decided that we need to pick the name for the splitting of Horizon
properly. From now up to the next meeting on June 10 we will be
collecting name proposals at:

https://etherpad.openstack.org/p/horizon-name-proposals

After that, until next meeting on June 17, we will be voting for
the proposed names. In case the most popular name is impossible to use
(due to trademark issues), we will use the next most popular. In case of
a tie, we will pick randomly.
-- 
Radomir Dopieralski

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


Re: [openstack-dev] [Horizon] Use of AngularJS

2014-06-03 Thread Musso, Veronica A
Great, thanks Matthias!

Then, if django-angular is approved for Fedora, do we need to wait for Ubuntu 
packages? Or can it  be used?

Thanks!
Veronica





Date: Tue, 3 Jun 2014 08:32:43 +0200
From: Matthias Runge mru...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon] Use of AngularJS
Message-ID: 20140603063243.gb28...@turing.berg.ol
Content-Type: text/plain; charset=us-ascii

On Tue, Jun 03, 2014 at 07:49:04AM +0200, Radomir Dopieralski wrote:
 On 06/02/2014 05:13 PM, Adam Nelson wrote:
  I think that you would use the PyPI version anyway:
  
  https://pypi.python.org/pypi/django-angular/0.7.2
  
  That's how most of the other Python dependencies work, even in the
  distribution packages.
 
 That is not true. As all components of OpenStack, Horizon has to be
 packaged at the end of the cycle, with all of its dependencies.
 

I already packaged python-django-angular for Fedora (and EPEL), it's
just waiting for review [1]. 

From a distro standpoint, every dependency needs to be packaged, and
this is not limited to Horizon dependencies as well.
On the other side, we don't break each time, when someone releases a new
setuptools or keystoneclient to pypi.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1099473
-- 
Matthias Runge mru...@redhat.com


*

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


Re: [openstack-dev] [sahara] summit wrap-up: Future of EDP

2014-06-03 Thread Sergey Lukjanov
Cool, thank you for wrapping up design summit session!

On Tue, Jun 3, 2014 at 7:24 PM, Trevor McKay tmc...@redhat.com wrote:
 Hi folks,

   Here is a summary of priorities from Summit and some action items for
 high the high priority issues.  The link to the pad is here:

 https://etherpad.openstack.org/p/juno-summit-sahara-edp

   We really did not have any leftover questions from summit, but we need
 investigation and development work in several areas.  Please respond with any
 comments/questions, and feel free to work on action items :)

 High priority
 Fix hive support
 minimal EDP for spark via spark plugin (may be possible w Oozie)
 Design pluggable job model and investigate Spark / Storm integration

 Medium priority
 Error reporting improvements

 Low priority
 Raw Oozie workflows
 coordinated jobs
 preparation tags for workflows
 files and archives tags (need clear use cases)
 streamline copying of job binaries from swift to hdfs (dscp)

 Action items for high priority issues:
 Hive:
 We need to flesh out existing blueprints:
 
 https://blueprints.launchpad.net/sahara/+spec/hive-vanilla2-support
 
 https://blueprints.launchpad.net/sahara/+spec/hive-integration-tests
 Additional blueprint needed for swift support in Hive
 Hive is not fully implemented in HDP plugin

 Investigate Spark job execution via Oozie
 Underway.  Produce a blueprint after initial investigation.

 Design a pluggable job model
 We need to review current EDP and think about how operations can be
 abstracted.  For instance, what are the essential operations on a job,
 and where has the Oozie implementation leaked knowledge into the EDP 
 code?

 Can we develop an abstraction that maps to other models in a 
 believable way?
storm, spark, scalding, others

 How will the UI deal with a pluggable job model assuming we have one?








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



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

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


[openstack-dev] [Ironic] Review dashboard update

2014-06-03 Thread Dmitry Tantsur
Hi everyone!

It's hard to stop polishing things, and today I got an updated review
dashboard. It's sources are merged to Sean Dague's repository [1], so I
expect this to be the final version. Thank you everyone for numerous
comments and suggestions, especially Ruby Loo.

Here is nice link to it: http://perm.ly/ironic-review-dashboard

Major changes since previous edition:
- My Patches Requiring Attention section - all your patches that are
either WIP or have any -1.
- Needs Reverify - approved changes that failed Jenkins verification
- Added last section with changes that either WIP or got -1 from Jenkins
(all other sections do not include these).
- Specs section show also WIP specs

I know someone requesting dashboard with IPA subproject highlighted - I
can do such things on case-by-case base - ping me on IRC.

Hope this will be helpful :)

Dmitry.

[1] https://github.com/sdague/gerrit-dash-creator


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


Re: [openstack-dev] [Cinder] How to mock the LOG inside cinder driver

2014-06-03 Thread Mike Perez
On 21:46 Tue 03 Jun , Deepak Shetty wrote:
 deepakcs Hi, whats the right way to mock the LOG variable inside the
 driver ? I am mocking mock.patch.object(glusterfs, 'LOG') as mock_logger

Please provide a paste[1] of the patch.

[1] - http://paste.openstack.org

-- 
Mike Perez

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


Re: [openstack-dev] Glance

2014-06-03 Thread Evgeny Kozhemyakin
Tizy Ninan wrote :
 When uploading images with large filesize (more than 1 GB) from dashboard,
 after upload is done the dashboard is showing 504 Gateway Timeout. What

Anyway we've launched a bug for fuel, thank you for the notice.
https://bugs.launchpad.net/fuel/+bug/1326082

-- 
Regards,
Evgeny Kozhemyakin (EVK-RIPE)

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


Re: [openstack-dev] [Cinder] How to mock the LOG inside cinder driver

2014-06-03 Thread Joshua Harlow
Why is mocking the LOG object useful/being used?

Testing functionality which depends on LOG triggers/calls imho is bad practice 
(and usually means something needs to be refactored).

LOG statements, and calls should be expected to move/be removed often so 
testing functionality in tests with them seems like the wrong approach.

My 2 cents.

From: Deepak Shetty dpkshe...@gmail.commailto:dpkshe...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, June 3, 2014 at 9:16 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Cinder] How to mock the LOG inside cinder driver

deepakcs Hi, whats the right way to mock the LOG variable inside the driver ? 
I am mocking mock.patch.object(glusterfs, 'LOG') as mock_logger
deepakcs and then doing...
deepakcs mock_logger.warning.assert_called_once() - which passes and is 
expected to pass per my code
deepakcs but
deepakcs mock_logger.debug.assert_called_once() - shud fail , but this also 
passes !
deepakcs any idea why ?

I feel that I am not mocking the LOG inside the driver correctly.

I also tried
   mock.patch.object(glusterfs.LOG, 'warning'),
mock.patch.object(glusterfs.LOG, 'debug')
as mock_logger_warn and mock_logger_debug respectively

But here too
.debug and .warning both passes.. while the expected result is for .warning to 
pass and .debug to fail

So somehow I am unable to mock LOG properly

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


[openstack-dev] [Horizon] [UX] Design for Alarming and Alarm Management

2014-06-03 Thread Liz Blanchard
Hi All,

I’ve recently put together a set of wireframes[1] around Alarm Management that 
would support the following blueprint:
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page

If you have a chance it would be great to hear any feedback that folks have on 
this direction moving forward with Alarms.

Best,
Liz

[1] 
http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][ML2] Modular agent architecture

2014-06-03 Thread Mathieu Rohon
Hi mohammad,

What I meant in my email is totaly in line with your proposal. My dataplane
driver is your resource driver, whereas my controlplane driver is your
agent driver!
I totally agree that the real challenge is defining a common abstract class
for every resource driver.
My proposal was to bind a port to a resource driver, so that we can have
several resource driver on the same agent. This seems to be the goal the
method * ResourceDriver**.port_bound() *in [3], am I wrong?

Tahnks for the etherpad, I will try to participate through it.

Mathieu


On Sat, May 31, 2014 at 5:10 AM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Hi Mathieu,

 Thanks for the email. As discussed during the ML2 IRC meeting [2], we have
 not decided on a design. That is why we do not have a spec for review yet.
 The idea is that we spend a bit more time and figure out the details and
 try out some possible options before we go ahead with the spec. So new
 comments/suggestions are much appreciated.

 In addition to having different drivers we want to reduce the code
 replication across current agents. I am wondering if with what you are
 proposing as dataplane drivers, we will end up with having different
 drivers which look like the current agents and we do not deal with reducing
 code replication across agents. If this is not a correct assessment could
 you describe how we can avoid code replication across agents/drivers.

 Let me briefly explain what I have outlined in [3] (also mentioned in
 [2]). We are thinking of having drivers for each extension or probably
 better said each functionality. So we can have a base l2 connectivity
 driver, an l2pop driver, a sg driver (not to be confused with sq drivers),
 so on so forth. I think in your email you are referring to these drivers
 (or something close to them) as Extension drivers. In [3] they are called
 Agent Drivers.

 Then we have the Resource Drivers which will be essentially used for
 realizing these features depending on the technology/resource being used
 (e.g., using  OVS switches, or Linux Bridges, or some other technology).
 The main reason for using such a organization is to be able to have
 different agent drivers utilize the same resource and reuse code. The
 challenge is figuring out the api for such a driver. Any thoughts on this?

 Mohammad

 [3] https://etherpad.openstack.org/p/modular-l2-agent-outline


 [image: Inactive hide details for Mathieu Rohon ---05/30/2014 06:25:29
 AM---Hi all, Modular agent seems to have to choose between two t]Mathieu
 Rohon ---05/30/2014 06:25:29 AM---Hi all, Modular agent seems to have to
 choose between two type of architecture [1].

 From: Mathieu Rohon mathieu.ro...@gmail.com
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org,
 Mohammad Banikazemi/Watson/IBM@IBMUS,
 Date: 05/30/2014 06:25 AM
 Subject: [openstack-dev][Neutron][ML2] Modular agent architecture
 --



 Hi all,

 Modular agent seems to have to choose between two type of architecture [1].

 As I understood during the last ML2 meeting [2], Extension driver
 seems to be the most reasonnable choice.
 But I think that those two approaches are complementory : Extension
 drivers will deal with RPC callbacks form the plugin, wheras Agent
 drivers will deal with controlling the underlying technology to
 interpret those callbacks.

 It looks like a controlPlane/Dataplane architecture. Could we have a
 control plane manager on which each Extension driver should register
 (and register callbacks it is listening at), and a data plane manager,
 on which each dataplane controller will register (ofagent, ovs, LB..),
 and which implement a common abastract class.
 A port will be managed by only one dataplane controller, and when a
 control plane driver wants to apply a modification on a port, it will
 retrieve the correct dataplane controller for this port in order to
 call one of the abstracted method to modify the dataplane.


 [1]
 https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions
 [2]
 http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-05-28-16.02.log.html



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


[openstack-dev] [Neutron] Implementing new LBaaS API

2014-06-03 Thread Brandon Logan
This is an LBaaS topic bud I'd like to get some Neutron Core members to
give their opinions on this matter so I've just directed this to Neutron
proper.

The design for the new API and object model for LBaaS needs to be locked
down before the hackathon in a couple of weeks and there are some
questions that need answered.  This is pretty urgent to come on to a
decision on and to get a clear strategy defined so we can actually do
real code during the hackathon instead of wasting some of that valuable
time discussing this.


Implementation must be backwards compatible

There are 2 ways that have come up on how to do this:

1) New API and object model are created in the same extension and plugin
as the old.  Any API requests structured for the old API will be
translated/adapted to the into the new object model.
PROS:
-Only one extension and plugin
-Mostly true backwards compatibility
-Do not have to rename unchanged resources and models
CONS:
-May end up being confusing to an end-user.
-Separation of old api and new api is less clear
-Deprecating and removing old api and object model will take a bit more
work
-This is basically API versioning the wrong way

2) A new extension and plugin are created for the new API and object
model.  Each API would live side by side.  New API would need to have
different names for resources and object models from Old API resources
and object models.
PROS:
-Clean demarcation point between old and new
-No translation layer needed
-Do not need to modify existing API and object model, no new bugs
-Drivers do not need to be immediately modified
-Easy to deprecate and remove old API and object model later
CONS:
-Separate extensions and object model will be confusing to end-users
-Code reuse by copy paste since old extension and plugin will be
deprecated and removed.
-This is basically API versioning the wrong way

Now if #2 is chosen to be feasible and acceptable then there are a
number of ways to actually do that.  I won't bring those up until a
clear decision is made on which strategy above is the most acceptable.

Thanks,
Brandon






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


Re: [openstack-dev] [Horizon] [UX] Design for Alarming and Alarm Management

2014-06-03 Thread Martinez, Christian
Hi Liz,
The designs look really cool and I think that we should consider a couple of 
things (more related to the alarm's implementation made at Ceilometer):

* There are combined alarms, which are a combination of two or more 
alarms. We need to see how they work and how we can show/modify them (or even 
if we want to show them)

* Currently, the alarms doesn't have a severity field. Which will be 
the intention to have this? Is to be able to filter by alarm severity? Is to 
have a way to distinguish the not-so-critical alarms that the ones that are 
critical?

* The alarms have a list of actions to be executed based on their 
current state. I think that the intention of that feature was to create alarms 
that could manage and trigger different actions based on their alarm state. 
For instance, if an alarm is created but doesn't have enough data to be 
evaluated, the state is insufficient data, and you can add actions to be 
triggered when this happens, for instance writing a LOG file or calling an URL. 
Maybe we could use this functionality that to notify the user whenever an alarm 
is triggered and we also should consider that when creating or updating the 
alarms as well.

More related to Alarms in general :

* What are the ideas around the alarm notifications? I saw that your 
intention is to have some sort of g+ notifications but what about other 
solutions/options, like email (using Mistral, perhaps'), logs. What do you guys 
think about that?

* The alarms could be created by the users as well.. I would add that 
CRUD functionality on the alarms tab on the overview section as well.

Hope it helps

Regards,
H
From: Liz Blanchard [mailto:lsure...@redhat.com]
Sent: Tuesday, June 3, 2014 3:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Horizon] [UX] Design for Alarming and Alarm Management

Hi All,

I've recently put together a set of wireframes[1] around Alarm Management that 
would support the following blueprint:
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page

If you have a chance it would be great to hear any feedback that folks have on 
this direction moving forward with Alarms.

Best,
Liz

[1] 
http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Use of AngularJS

2014-06-03 Thread Matthias Runge
On Tue, Jun 03, 2014 at 05:14:16PM +, Musso, Veronica A wrote:
 Great, thanks Matthias!
 
 Then, if django-angular is approved for Fedora, do we need to wait for Ubuntu 
 packages? Or can it  be used?
 
 Thanks!
 Veronica

I can not speak for other distributions. My 2ct here:

you'd need a package, when a release is being made. If your favourite
distro provides e.g packages for each snapshot, you'd need a package
around June 12th.
This is for django-angular not different to any other dependency.

So: I'd say: we don't need to wait here with a implementation for any
distribution. 
-- 
Matthias Runge mru...@redhat.com

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


Re: [openstack-dev] [Neutron] test configuration for ml2/ovs L2 and L3 agents

2014-06-03 Thread Carl Baldwin
Chuck,

I accidentally uploaded by local.conf changes to gerrit [1].  I
immediately abandoned them so that reviewers wouldn't waste time
thinking I was trying to get changes upstream.  But, since they're up
there now, you could take a look.

I am currently running a multi-node devstack on a couple of cloud VMs
with these changes.

Carl

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

On Tue, Jun 3, 2014 at 9:23 AM, Carlino, Chuck chuck.carl...@hp.com wrote:
 Hi all,

 I'm struggling a bit to get a test set up working for L2/L3 work (ml2/ovs).  
 I've been trying multi-host devstack (just controller node for now), and I 
 must be missing something important because n-sch bombs out.  Single node 
 devstack works fine, but it's not very useful for L2/L3.

 Any suggestions, or maybe someone has some local.conf files they'd care to 
 share?

 Many thanks,
 Chuck

 ___
 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] [Rally] Tempest + Rally: first success

2014-06-03 Thread om prakash pandey
Thanks Andrey! Please see below the logs(Environment specific output has
been snipped):

2014-06-04 02:32:07.303 1939 DEBUG rally.cmd.cliutils [-] INFO logs from
urllib3 and requests module are hide. run
/usr/local/lib/python2.7/dist-packages/rally/cmd/cliutils.py:137
2014-06-04 02:32:07.363 1939 INFO rally.orchestrator.api [-] Starting
verification of deployment: 9c023039-211e-4794-84df-4ada68c656dd
2014-06-04 02:32:07.378 1939 INFO
rally.verification.verifiers.tempest.tempest [-] Verification
d596caf4-feb7-455c-832e-b6b77b1dcb9c | Starting:  Run verification.
2014-06-04 02:32:07.378 1939 DEBUG
rally.verification.verifiers.tempest.tempest [-] Tempest config file:
/home/om/.rally/tempest/for-deployment-9c023039-211e-4794-84df-4ada68c656dd/tempest.conf
 generate_config_file
/usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/tempest.py:90
2014-06-04 02:32:07.379 1939 INFO
rally.verification.verifiers.tempest.tempest [-] Starting: Creation of
configuration file for tempest.
2014-06-04 02:32:07.385 1939 DEBUG keystoneclient.session [-] REQ: curl -i
-X POST
---
2014-06-04 02:32:09.003 1939 DEBUG glanceclient.common.http [-]
HTTP/1.1 200 OK
content-length: 9276
via: 1.1 xyzcloud.com
server: Apache/2.4.9 (Ubuntu)
connection: close
date: Tue, 03 Jun 2014 21:02:08 GMT
content-type: application/json; charset=UTF-8
x-openstack-request-id: req-5fe73b11-85c7-49b7-bf31-34a44ceaaf6b

2014-06-04 02:32:13.399 1939 DEBUG neutronclient.client [-]
REQ: curl -i
https://xyzcloud.com:443//v2.0/subnets.json?network_id=13d63b58-57c9-4ba2-ae63-733836257636
-X GET -H X-Auth-Token: bc604fb2a258429f99ed8940064fb1cb -H
Content-Type: application/json -H Accept: application/json -H
User-Agent: python-neutronclient
 http_log_req
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:173
2014-06-04 02:32:14.068 1939 DEBUG neutronclient.client [-] RESP:{'date':
'Tue, 03 Jun 2014 21:02:14 GMT', 'status': '200', 'content-length': '15',
'content-type': 'application/json; charset=UTF-8', 'content-location': '
https://xyzcloud.com:443//v2.0/subnets.json?network_id=13d63b58-57c9-4ba2-ae63-733836257636'}
{subnets: []}
 http_log_resp
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:179
2014-06-04 02:32:14.071 1939 CRITICAL rally [-] IndexError: list index out
of range
2014-06-04 02:32:14.071 1939 TRACE rally Traceback (most recent call last):
2014-06-04 02:32:14.071 1939 TRACE rally   File /usr/local/bin/rally,
line 10, in module
2014-06-04 02:32:14.071 1939 TRACE rally sys.exit(main())
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/cmd/main.py, line 44, in main
2014-06-04 02:32:14.071 1939 TRACE rally return cliutils.run(sys.argv,
categories)
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/cmd/cliutils.py, line 193,
in run
2014-06-04 02:32:14.071 1939 TRACE rally ret = fn(*fn_args, **fn_kwargs)
2014-06-04 02:32:14.071 1939 TRACE rally   File string, line 2, in start
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/cmd/envutils.py, line 63, in
default_from_global
2014-06-04 02:32:14.071 1939 TRACE rally return f(*args, **kwargs)
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/cmd/commands/verify.py, line
58, in start
2014-06-04 02:32:14.071 1939 TRACE rally api.verify(deploy_id,
set_name, regex)
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/orchestrator/api.py, line
150, in verify
2014-06-04 02:32:14.071 1939 TRACE rally
verifier.verify(set_name=set_name, regex=regex)
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/tempest.py,
line 271, in verify
2014-06-04 02:32:14.071 1939 TRACE rally
self._prepare_and_run(set_name, regex)
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/utils.py, line 162, in
wrapper
2014-06-04 02:32:14.071 1939 TRACE rally result = f(self, *args,
**kwargs)
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/tempest.py,
line 153, in _prepare_and_run
2014-06-04 02:32:14.071 1939 TRACE rally self.generate_config_file()
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/tempest.py,
line 95, in generate_config_file
2014-06-04 02:32:14.071 1939 TRACE rally conf =
config.TempestConf(self.deploy_id).generate()
2014-06-04 02:32:14.071 1939 TRACE rally   File
/usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/config.py,
line 

Re: [openstack-dev] [QA] Tests for Custom roles in keystone v3

2014-06-03 Thread Frittoli, Andrea (HP Cloud)
Hi Ajaya,

 

Thanks for offer to help :)

 

Are you talking about tempest tests or in-tree keystone tests?

 

Verifying custom roles can be challenging via  API only driven tests such as 
tempest – as it requires to have the policies configured accordingly in the 
cloud under test (i.e. devstack).

It should be possible to prepare support for custom roles in the policy at 
deployment time. If tempest what you’re aiming at, it would be good if you 
could file a bp to describe what kind of use cases you have in mind, and why 
you’d like to run them in tempest.

 

As these would be keystone only tests, I wonder if they would be more fitting 
as unit / functional tests in the keystone tree? This approach would give you 
more flexibility in changing the policies.

 

If you are interested in contributing to tempest tests in the keystone area, 
below are some ideas.

 

A few bp which are related to tempest and keystone identity API v3:

-  Refactor tempest so that it may run consuming identity v3 only (or 
greater, when available) [1]

-  Setup dsvm tests which rely on identity v3 only (including 
intra-service communication) [2]

-  Cross domain testing: write tests to verify the impact of the domain 
scope on keystone itself and on the services [3]

-  Tempest without admin account (David Kranz’s blueprint): run tempest 
tests without the need of an “admin” account [4]

 

Your very welcome to contribute to any of those. [3] and [4] are still in the 
design phase.

 

The non-admin blueprint is loosely related to custom roles: it raised the 
question of how to run as many tests as possible without the need of an 
identity-admin account, which in certain deployments may be not available to 
the person running the tests.

The concept of domain introduced in identity v3 may be helpful here, as a 
domain admin could be able to have full control within the boundaries of the 
domain.  

That can be true for keystone, as long as roles is defined and the policy in 
keystone is configured correctly.  

 

For services I believe there is no combination of custom roles / service 
policies that will allow to achieve this – to make an example use case, allow 
the domain admin to list all the VMs, images, containers and networks defined 
within projects that belong to the domain. I believe that for this to be 
possible we’ll have to wait for the hierarchical multi-tenancy in every 
projects. [5]

 

Andrea

 

p.s.

Please use the openstack-dev list, openstack-qa is only used for reporting of 
periodic job test results. 

 

[1] 
https://github.com/openstack/qa-specs/blob/master/specs/multi-keystone-api-version-tests.rst

[2] https://github.com/openstack/qa-specs/blob/master/specs/keystone-v3-jobs.rst

[3] 
http://docs-draft.openstack.org/98/83898/5/check/gate-qa-specs-docs/4372c5f/doc/build/html/specs/cross-domain-testing.html
 

[4] 
http://docs-draft.openstack.org/67/86967/6/check/gate-qa-specs-docs/d0c8170/doc/build/html/specs/run-without-admin.html
 

[5] 
https://etherpad.openstack.org/p/juno-cross-project-hierarchical-multitenancy 

 

From: Ajaya Agrawal [mailto:ajku@gmail.com] 
Sent: 03 June 2014 20:38
To: openstack-qa
Subject: [openstack-qa] Tests for Custom roles in keystone v3

 

Hi,

 

Is someone writing tests for custom roles and policies in keystone v3. for e.g. 
one could create a role called project_admin who would allowed to create/delete 
users in his project only.

 

Andrea, Sean said in irc that you are working on this thing. Would you like to 
have one more pair of hands on this? :)




Cheers,

Ajaya



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] [Neutron][LBaaS] Requirements around statistics and billing

2014-06-03 Thread Eichberger, German
Hi Stephen,

We would like all those numbers as well ☺

Additionally, we measure:

· When a lb instance was created, deleted, etc.

· For monitoring we “ping” a load balancers health check and report/act 
on the results

· For user’s troubleshooting we make the haproxy logs available. Which 
contain connection information like from, to, duration, protocol, status 
(though we frequently have been told that this is not really useful for 
debugging…) and of course having that more gui-fied would be neat

German



From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, May 27, 2014 8:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Requirements around statistics and 
billing

Hi folks!

We have yet to have any kind of meaningful discussion on this list around load 
balancer stats (which, I presume to include data that will eventually need to 
be consumed by a billing system). I'd like to get the discussion started here, 
as this will have significant meaning for how we both make this data available 
to users, and how we implement back-end systems to be able to provide this data.

So!  What kinds of data are people looking for, as far as load balancer 
statistics.

For our part, as an absolute minimum we need the following per loadbalancer + 
listener combination:

* Total bytes transferred in for a given period
* Total bytes transferred out for a given period

Our product and billing people I'm sure would like the following as well:

* Some kind of peak connections / second data (95th percentile or average over 
a period, etc.)
* Total connections for a given period
* Total HTTP / HTTPS requests served for a given period

And the people who work on UIs and put together dashboards would like:

* Current requests / second (average for last X seconds, either on-demand, or 
simply dumped regularly).
* Current In/Out bytes throughput

And our monitoring people would like this:

* Errors / second
* Current connections / second and bytes throughput secant slope (ie. like 
derivative but easier to calculate from digital data) for last X seconds (ie. 
detecting massive spikes or drops in traffic, potentially useful for detecting 
a problem before it becomes critical)

And some of our users would like all of the above data per pool, and not just 
for loadbalancer + listener. Some would also like to see it per member (though 
I'm less inclined to make this part of our standard).

I'm also interested in hearing vendor capabilities here, as it doesn't make 
sense to design stats that most can't implement, and I imagine vendors also 
have valuable data on what their customer ask for / what stats are most useful 
in troubleshooting.

What other statistics data for load balancing are meaningful and hopefully not 
too arduous to calculate? What other data are your users asking for or 
accustomed to seeing?

Thanks,
Stephen

--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

2014-06-03 Thread Eichberger, German
Hi,

From deep below in the e-mail chain:
Same here. Cascade-deleting of shared objects should not be allowed in any case.

Being able to delete all lbs and related constructs after a customer leaves 
and/or for tests is a pretty important requirements for us. It does not 
necessarily have to be accomplished by a cascading delete on the user api (we 
could use an admin api for that) but it is important in  our data model to 
avoid  constraint violation when we want to clean everything out…

I am still with Jorge that sharing of objects in whatever form might confuse 
customers who will then use up costly customer support time and hence not 
entirely in the interest of us public cloud providers. The examples with the 
status is another example for that…

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, May 30, 2014 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships 
for Pools and Listeners

Hi y'all!

Re-responses inline:

On Fri, May 30, 2014 at 8:25 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

 § Where can a user check the success of the update?




 Depending on the object... either the status of the child object
 itself or all of its affected parent(s). Since we're allowing reusing
 of the pool object, when getting the status of a pool, maybe it makes
 sense to produce a list showing the status of all the pool's members,
 as well as the update status of all the listeners using the pool?
This is confusing to me.  Will there be a separate provisioning status
field on the loadbalancer and just a generic status on the child
objects?  I get the idea of a pool having a status the reflects the
state of all of its members.  Is that what you mean by status of a child
object?

It seems to me that we could use the 'generic status' field on the load 
balancer to show provisioning status as well. :/  Is there a compelling reason 
we couldn't do this? (Sam?)

And yes, I think that's what I mean with one addition. For example:

If I have Listener A and B which use pool X which has members M and N...  if I 
set member 'M' to be 'ADMIN_STATE_DISABLED', then what I would expect to see, 
if I ask for the status of pool X immediately after this change is:
* An array showing N is 'UP' and 'M' is in state 'ADMIN_STATE_DISABLED' and
* An array showing that listeners 'A' and 'B' are in 'PENDING_UPDATE' state (or 
something similar).

I would also expect listeners 'A' and 'B' to go back to 'UP' state shortly 
thereafter.

Does this make sense?

Note that there is a problem with my suggestion: What does the status of a 
member mean when the member is referenced indirectly by several listeners?  
(For example, listener A could see member N as being UP, whereas listener B 
could see member N as being DOWN.)  Should member statuses also be an array 
from the perspective of each listener? (in other words, we'd have a 
two-dimensional array here.)

If we do this then perhaps the right thing to do is just list the pool members' 
statuses in context of the listeners.  In other words, if we're reporting this 
way, then given the same scenario above, if we set member 'M' to be 
'ADMIN_STATE_DISABLED', then asking for the status of pool X immediately after 
this change is:
* (Possibly?) an array for each listener status showing them as 'PENDING_UPDATE'
* An array for member statuses which contain:
** An array which shows member N is 'UP' for listener 'A' and 'DOWN' for 
listener 'B'
** An array which shows member M is 'PENDING_DISABLED' for both listener 'A' 
and 'B'

...and then shortly thereafter we would see member M's status for each listener 
change to 'DISABLED' at the same time the listeners' statuses change to 'UP'.

So... this second way of looking at it is less intuitive to me, though it is 
probably more correct. Isn't object re-use fun?



 ·Operation status/state – this refers to information
 returning from the load balancing back end / driver

 o  How is member status that failed health monitor reflected,
 on which LBaaS object and how can a user understand the
 failure?


 Assuming you're not talking about an alert which would be generated by
 a back-end load balancer and get routed to some notification system...
 I think you should be able to get the status of a member by just
 checking the member status directly (ie.  GET /members/[UUID]) or, if
 people like my suggestion above, by checking the status of the pool to
 which the member belongs (ie. GET /pools/[UUID]).


 ·Administrator state management

 o  How is a change in admin_state on member, pool, listener
 get managed


 I'm thinking that disabling members, pools, and listeners should
 propagate to all parent objects. (For example, disabling a member
 should propagate to all affected pools and listeners, which
 

Re: [openstack-dev] Glance

2014-06-03 Thread Dmitry Borodaenko
Here's a fix that increases haproxy server timeout for Horizon to 48h:
https://review.openstack.org/#/c/97645/

I've marked the bug as Incomplete for now: we need a confirmation that
only Horizon is affected and Glance isn't. Please try the current
version of the fix, if gateway timeouts disappear, it will confirm
that timeout value for Glance doesn't need to be changed.

Thanks,
-DmitryB



On Tue, Jun 3, 2014 at 11:14 AM, Evgeny Kozhemyakin
ekozhemya...@mirantis.com wrote:
 Tizy Ninan wrote :
 When uploading images with large filesize (more than 1 GB) from dashboard,
 after upload is done the dashboard is showing 504 Gateway Timeout. What

 Anyway we've launched a bug for fuel, thank you for the notice.
 https://bugs.launchpad.net/fuel/+bug/1326082

 --
 Regards,
 Evgeny Kozhemyakin (EVK-RIPE)

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



-- 
Dmitry Borodaenko

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


Re: [openstack-dev] nova-compute rpc version

2014-06-03 Thread Matt Riedemann



On 6/3/2014 8:15 AM, abhishek jain wrote:

Hi Russell

Thanks
I'm able to solve it now by switching onto havana release on both the
controller node and compute node.







On Tue, Jun 3, 2014 at 10:56 AM, abhishek jain ashujain9...@gmail.com
mailto:ashujain9...@gmail.com wrote:

Hi Russell

Below are the details...

controller node...

nova --version
2.17.0.122

nova-compute  --version
2014.2

compute node.

nova --version
2.17.0.122

nova-compute --version
2013.2.4

Can you help me what i need to change in order to achieve the
desired functioonality.



Thaks


On Tue, Jun 3, 2014 at 2:16 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:

On 06/02/2014 08:20 AM, abhishek jain wrote:
  |Hi
  |
 
  |
  I'm getting following error in nova-compute logs when trying
to boot VM from controller node onto compute node ...
 
   Specified RPC version, 3.23, not supported
 
  Please help regarding this.

It sounds like you're using an older nova-compute with newer
controller
services (without the configuration to allow a live ugprade).
  Check the
versions of Nova services you have running.

--
Russell Bryant

___
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



See the 2nd to last bullet here:

https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#Upgrade_Notes_2

--

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] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler

2014-06-03 Thread ChangBo Guo
Jay, thanks for raising this up .
+1 for this .
 A related question about the CPU and RAM allocation ratio, shall we apply
them when get hypervisor information with command nova hypervisor-show
${hypervisor-name}
The output  shows like
| memory_mb |
15824
|
| memory_mb_used|
1024
|
| running_vms   |
1
|
| service_host  |
node-6
|
| service_id|
39
|
| vcpus |
4
|
| vcpus_used| 1

vcpus is showing the number of physical CPU, I think that's not correct.
Any thoughts ?


2014-06-03 21:29 GMT+08:00 Jay Pipes jaypi...@gmail.com:

 Hi Stackers,

 tl;dr
 =

 Move CPU and RAM allocation ratio definition out of the Nova scheduler and
 into the resource tracker. Remove the calculations for overcommit out of
 the core_filter and ram_filter scheduler pieces.

 Details
 ===

 Currently, in the Nova code base, the thing that controls whether or not
 the scheduler places an instance on a compute host that is already full
 (in terms of memory or vCPU usage) is a pair of configuration options*
 called cpu_allocation_ratio and ram_allocation_ratio.

 These configuration options are defined in, respectively,
 nova/scheduler/filters/core_filter.py and nova/scheduler/filters/ram_
 filter.py.

 Every time an instance is launched, the scheduler loops through a
 collection of host state structures that contain resource consumption
 figures for each compute node. For each compute host, the core_filter and
 ram_filter's host_passes() method is called. In the host_passes() method,
 the host's reported total amount of CPU or RAM is multiplied by this
 configuration option, and the product is then subtracted from the reported
 used amount of CPU or RAM. If the result is greater than or equal to the
 number of vCPUs needed by the instance being launched, True is returned and
 the host continues to be considered during scheduling decisions.

 I propose we move the definition of the allocation ratios out of the
 scheduler entirely, as well as the calculation of the total amount of
 resources each compute node contains. The resource tracker is the most
 appropriate place to define these configuration options, as the resource
 tracker is what is responsible for keeping track of total and used resource
 amounts for all compute nodes.

 Benefits:

  * Allocation ratios determine the amount of resources that a compute node
 advertises. The resource tracker is what determines the amount of resources
 that each compute node has, and how much of a particular type of resource
 have been used on a compute node. It therefore makes sense to put
 calculations and definition of allocation ratios where they naturally
 belong.
  * The scheduler currently needlessly re-calculates total resource amounts
 on every call to the scheduler. This isn't necessary. The total resource
 amounts don't change unless either a configuration option is changed on a
 compute node (or host aggregate), and this calculation can be done more
 efficiently once in the resource tracker.
  * Move more logic out of the scheduler
  * With the move to an extensible resource tracker, we can more easily
 evolve to defining all resource-related options in the same place (instead
 of in different filter files in the scheduler...)

 Thoughts?

 Best,
 -jay

 * Host aggregates may also have a separate allocation ratio that overrides
 any configuration setting that a particular host may have

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




-- 
ChangBo Guo(gcb)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] nova-compute deadlock

2014-06-03 Thread Zhu Zhu
Hi Qin Zhao,

Thanks for raising this issue and analysis. According to the issue description 
and happen 
scenario(https://docs.google.com/drawings/d/1pItX9urLd6fmjws3BVovXQvRg_qMdTHS-0JhYfSkkVc/pub?w=960h=720),
  if that's the case,  concurrent mutiple KVM spawn instances(with both config 
drive and data injection enabled) are triggered, the issue can be very likely 
to happen. 
As in libvirt/driver.py _create_image method, right after iso making 
cdb.make_drive, the driver will attempt data injection which will call the 
libguestfs launch in another thread. 

Looks there were also a couple of libguestfs hang issues from Launch pad as 
below. . I am not sure if libguestfs itself can have certain mechanism to 
free/close the fds that inherited from parent process instead of require 
explicitly calling the tear down. Maybe open a defect to libguestfs to see what 
their thoughts? 

https://bugs.launchpad.net/nova/+bug/1286256
https://bugs.launchpad.net/nova/+bug/1270304 



Zhu Zhu
Best Regards
 
From: Qin Zhao
Date: 2014-05-31 01:25
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Nova] nova-compute deadlock
Hi all,

When I run Icehouse code, I encountered a strange problem. The nova-compute 
service becomes stuck, when I boot instances. I report this bug in 
https://bugs.launchpad.net/nova/+bug/1313477.

After thinking several days, I feel I know its root cause. This bug should be a 
deadlock problem cause by pipe fd leaking.  I draw a diagram to illustrate this 
problem. 
https://docs.google.com/drawings/d/1pItX9urLd6fmjws3BVovXQvRg_qMdTHS-0JhYfSkkVc/pub?w=960h=720

However, I have not find a very good solution to prevent this deadlock. This 
problem is related with Python runtime, libguestfs, and eventlet. The situation 
is a little complicated. Is there any expert who can help me to look for a 
solution? I will appreciate for your help!

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


[openstack-dev] [ironic bare metal installation issue]

2014-06-03 Thread 严超
Hi, All :
I've deployed my ironic following this link:
http://ma.ttwagner.com/bare-metal-deploys-with-devstack-and-ironic/ , all
steps is completed.
Now one of my node-show provision_state is active. But why is this
node still in installation state as follow ?
 [image: 内嵌图片 1]



*Best Regards!*


*Chao Yan--**My twitter:Andy Yan @yanchao727
https://twitter.com/yanchao727*


*My Weibo:http://weibo.com/herewearenow
http://weibo.com/herewearenow--*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Ironic]Need to know the process to make changes to nova ironic virt driver

2014-06-03 Thread Faizan Barmawer
Hi All,

I am currently looking at UEFI support for ironic driver blueprints and
writing a design spec for the same.
https://blueprints.launchpad.net/ironic/+spec/uefi-boot-for-ironic
https://blueprints.launchpad.net/ironic/+spec/uefi-gpt-support

I anticipate changes in nova ironic virt driver and may be adding ironic
specific filters in this space for the above feature.

Just wanted to check with you folks, if we need to file a separate
blueprint in nova to make those changes or can we add changes in the nova
virt driver placed in ironic tree itself?

Please clarify.

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


[openstack-dev] Fwd: [Cinder] How to mock the LOG inside cinder driver

2014-06-03 Thread Deepak Shetty
Wrongly sent to Joshua only, hence fwding to the list.

--

Joshua,
  If my code has logs warning, error, debug based on diff exceptions or
conditions, its good to test them  have a unit test around it
so that we can catch scenarios where we modified code that ideally shud
have just put a warn but wrongly put a debug/error. Thats my only intention
here


On Tue, Jun 3, 2014 at 11:54 PM, Joshua Harlow harlo...@yahoo-inc.com
wrote:

  Why is mocking the LOG object useful/being used?

  Testing functionality which depends on LOG triggers/calls imho is bad
 practice (and usually means something needs to be refactored).

  LOG statements, and calls should be expected to move/be removed *often*
 so testing functionality in tests with them seems like the wrong approach.

  My 2 cents.

   From: Deepak Shetty dpkshe...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Tuesday, June 3, 2014 at 9:16 AM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Cinder] How to mock the LOG inside cinder driver

  deepakcs Hi, whats the right way to mock the LOG variable inside
 the driver ? I am mocking mock.patch.object(glusterfs, 'LOG') as mock_logger
 deepakcs and then doing...
 deepakcs mock_logger.warning.assert_called_once() - which passes and is
 expected to pass per my code
 deepakcs but
 deepakcs mock_logger.debug.assert_called_once() - shud fail , but this
 also passes !
 deepakcs any idea why ?

  I feel that I am not mocking the LOG inside the driver correctly.

 I also tried
mock.patch.object(glusterfs.LOG, 'warning'),
 mock.patch.object(glusterfs.LOG, 'debug')
  as mock_logger_warn and mock_logger_debug respectively

  But here too
  .debug and .warning both passes.. while the expected result is for
 .warning to pass and .debug to fail

  So somehow I am unable to mock LOG properly

 thanx,
 deepak


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


Re: [openstack-dev] [Cinder] [solved] How to mock the LOG inside cinder driver

2014-06-03 Thread Deepak Shetty
The below issue was resolved (thanks to akerr on IRC).
It seems called_once_with is not a function of mock and doesn't work
properly
Need to use assertTrue(mock_func.called) and thats working for me.

thanx,
deepak


On Tue, Jun 3, 2014 at 9:46 PM, Deepak Shetty dpkshe...@gmail.com wrote:

 deepakcs Hi, whats the right way to mock the LOG variable inside the
 driver ? I am mocking mock.patch.object(glusterfs, 'LOG') as mock_logger
 deepakcs and then doing...
 deepakcs mock_logger.warning.assert_called_once() - which passes and is
 expected to pass per my code
 deepakcs but
 deepakcs mock_logger.debug.assert_called_once() - shud fail , but this
 also passes !
 deepakcs any idea why ?

 I feel that I am not mocking the LOG inside the driver correctly.

 I also tried
mock.patch.object(glusterfs.LOG, 'warning'),
 mock.patch.object(glusterfs.LOG, 'debug')
 as mock_logger_warn and mock_logger_debug respectively

 But here too
 .debug and .warning both passes.. while the expected result is for
 .warning to pass and .debug to fail

 So somehow I am unable to mock LOG properly

 thanx,
 deepak

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