date:20160112


On 01/11/2016 11:09 PM, Tzu-Mainn Chen wrote:

- Original Message -

Background info:

We've got a problem in TripleO at the moment where many of our
workflows can be driven by the command line only. This causes some
problems for those trying to build a UI around the workflows in that
they have to duplicate deployment logic in potentially multiple places.
There are specs up for review which outline how we might solve this
problem by building what is called TripleO API [1].

Late last year I began experimenting with an OpenStack service called
Mistral which contains a generic workflow API. Mistral supports
defining workflows in YAML and then creating, managing, and executing
them via an OpenStack API. Initially the effort was focused around the
idea of creating a workflow in Mistral which could supplant our
"baremetal introspection" workflow which currently lives in python-
tripleoclient. I create a video presentation which outlines this effort
[2]. This particular workflow seemed to fit nicely within the Mistral
tooling.



More recently I've turned my attention to what it might look like if we
were to use Mistral as a replacement for the TripleO API entirely. This
brings forth the question of would TripleO be better off building out
its own API... or would relying on existing OpenStack APIs be a better
solution?

Some things I like about the Mistral solution:

- The API already exists and is generic.

- Mistral already supports interacting with many of the OpenStack API's
we require [3]. Integration with keystone is baked in. Adding support
for new clients seems straightforward (I've had no issues in adding
support for ironic, inspector, and swift actions).

- Mistral actions are pluggable. We could fairly easily wrap some of
our more complex workflows (perhaps those that aren't easy to replicate
with pure YAML workflows) by creating our own TripleO Mistral actions.
This approach would be similar to creating a custom Heat resource...
something we have avoided with Heat in TripleO but I think it is
perhaps more reasonable with Mistral and would allow us to again build
out our YAML workflows to drive things. This might allow us to build
off some of the tripleo-common consolidation that is already underway
...

- We could achieve a "stable API" by simply maintaining input
parameters for workflows in a stable manner. Or perhaps workflows get
versioned like a normal API would be as well.

- The purist part of me likes Mistral quite a bit. It fits nicely with
the deploy OpenStack with OpenStack. I sort of feel like if we have to
build our own API in TripleO part of this vision has failed and could
even be seen as a massive technical debt which would likely be hard to
build a community around outside of TripleO.

- Some of the proposed validations could perhaps be implemented as new
Mistral actions as well. I'm not convinced we require TripleO API just
to support a validations mechanism yet. Perhaps validations seem hard
because we are simply trying to do them in the wrong places anyway?
(like for example perhaps we should validate network connectivity at
inspection time rather than during provisioning).

- Power users might find a workflow built around a Mistral API more
easy to interact with and expand upon. Perhaps this ends up being
something that gets submitted as a patchset back to the TripleO that we
accept into our upstream "stock" workflow sets.



Hiya!  Thanks for putting down your thoughts.

I think I fundamentally disagree with the idea of using Mistral, simply
because many of the actions we'd like to expose through a REST API
(described in the tripleo-common deployment library spec [1]) aren't
workflows; they're straightforward get/set methods.


Right, because this spec describes nearly nothing from what is present 
in tripleoclient now. And what we realistically have now is workflows, 
which we'll have to reimplement in API somehow. So maybe we need both: 
the get/set TripleO API for deployment plans and Mistral for workflows.


> Putting a workflow

engine in front of that feels like overkill and an added complication
that simply isn't needed.  And added complications can lead to unneeded
complications: for instance, one open Mistral bug details how it may
not scale well [2].


Let's not talk about scaling in the context of what we have in 
tripleoclient now ;)




The Mistral solution feels like we're trying to force a circular peg
into a round-ish hole.  In a vacuum, if we were to consider the
engineering problem of exposing a code base to outside consumers in a
non-language specific fashion - I'm pretty sure we'd just suggest the
creation of a REST API and be done with it; the thought of using a
workflow engine as the frontend would not cross our minds.

I don't really agree with the 'purist' argument.  We already have custom
business logic written in the TripleO CLI; accepting that within TripleO,
but not a very thin API layer, feels like an arbitrary line to me.  And
if that

Re: [openstack-dev] [Openstack-dev][Manila] status=NONE when share is created

2016-01-12 Thread nidhi.hada

Hi All,

Could you please reply to below mail...

Thanks
Nidhi

From: Nidhi Mittal Hada (WT01 - Product Engineering Service)
Sent: Thursday, January 07, 2016 12:42 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 

Subject: RE: [Openstack-dev][Manila] status=NONE when share is created

Hi All,

Could someone please reply to the mail below ..

Is this an expected state to get created share status as None?

As we are intentionally not creating "share instance" while creating
share..

For details please see mail below..

Thanks
Nidhi

From: Nidhi Mittal Hada (WT01 - Product Engineering Service)
Sent: Wednesday, January 06, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [Openstack-dev][Manila] status=NONE when share is created

Hi All,

https://bugs.launchpad.net/manila/+bug/1526284

stack@controller:~/devstack$ manila create NFS 1 --name share5 --share-type 
GENERAL_Storage
+-+--+
| Property | Value |
+-+--+
| status | None 

 |
| share_type_name | GENERAL_Storage |
| description | None |
| availability_zone | None |
| share_network_id | None |
| export_locations | [] |
| share_server_id | None |
| host | None |
| snapshot_id | None |
| is_public | False |
| task_state | None |
| snapshot_support | True |
| id | 6572a26a-2313-4a1d-8765-4a031ec0ae3a |
| size | 1 |
| name | share5 |
| share_type | 961b767b-b8e4-4769-884f-7214af944f29 |
| created_at | 2015-12-15T11:31:23.818642 |
| export_location | None |
| share_proto | NFS |
| consistency_group_id | None |
| source_cgsnapshot_member_id | None |
| project_id | 0e15488bc7a14ce5b530920c95357457 |
| metadata | {} |
+-+--+

status should be "creating".. but it's being shown as "NONE" which is not right.

I am working on this bug. I have a doubt. code is as below.
In file manila/share/api.py

try:
234 share = self.db.share_create(context, options,
235  
create_share_instance=False)>>
236 QUOTAS.commit(context, reservations)
237 except Exception:
238 with excutils.save_and_reraise_exception():
239 try:
240 self.db.share_delete(context, share['id'])
241 finally:
242 QUOTAS.rollback(context, reservations)

Where we are intentionally giving create_share_instance=False that means in db 
function
share_create(), share Instance will not be created And status is a field in 
share_instances table only.

Hence it will come as "None" only till instance is created.

Is this an "intentional step" to show status as "None"..

is this bug not valid?

Please suggest.

Thanks
Nidhi
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ironic] ironic-python-agent release 1.1.0 (mitaka)

Gate is not working right now, as we still use preversioning in 
setup.cfg, and we have a version mismatch, e.g. 
http://logs.openstack.org/74/264274/1/check/gate-ironic-python-agent-pep8/8d6ef18/console.html.


Patch to remove the version from setup.cfg:
https://review.openstack.org/#/c/266267/
Will backport to liberty as soon as it merges.

On 01/11/2016 10:01 PM, d...@doughellmann.com wrote:

We are glad to announce the release of:

ironic-python-agent 1.1.0: Ironic Python Agent Ramdisk

This release is part of the mitaka release series.

With package available at:

 https://pypi.python.org/pypi/ironic-python-agent

For more details, please see below.


1.1.0
^


New Features


* The CoreOS image builder now uses the latest CoreOS stable version
   when building images.

* IPA now supports Linux-IO as an alternative to tgtd. The iSCSI
   extension will try to use Linux-IO first, and fall back to tgtd if
   Linux-IO is not found or cannot be used.

* Adds support for setting proxy info for downloading images. This
   is controlled by the *proxies* and *no_proxy* keys in the
   *image_info* dict of the *prepare_image* command.

* Adds support for streaming raw images directly onto the disk. This
   avoids writing the image to a tmpfs partition before writing it to
   disk, which also enables using images larger than the usable amount
   of RAM on the machine IPA runs on. Pass *stream_raw_images=True* to
   the *prepare_image* command to enable this; it is disabled by
   default.

* CoreOS image builder now runs IPA in a chroot, instead of a
   container. systemd-nspawn has been adding more security features
   that break several things IPA needs to do (after all, IPA
   manipulates hardware), such as using sysrq triggers or writing to
   /sys.

* Root device hints now also inspect ID_WWN_WITH_EXTENSION and
   ID_WWN_VENDOR_EXTENSION from udev.


Upgrade Notes
*

* Now that IPA runs in a chroot, any operator tooling built around
   the container may need to change (for example, methods of getting a
   shell inside the container).


Bug Fixes
*

* Raw images larger than available of RAM may now be used by passing
   *stream_raw_images=True* to the *prepare_image* command; these will
   be streamed directly to disk.

* Fixes an issue using the "logs" inspection collector when logs
   contain non-ascii characters.

* Makes tgtd ready status detection more robust.

* Fixes configdrive creation for MBR disks greater than 2TB.


Other Notes
***

* System random is now used where applicable, rather than the
   default python random library.


Changes in ironic-python-agent 1.0.0..1.1.0
---

43a149d Updated from global requirements
dcdb06d Replace deprecated LOG.warn with LOG.warning
4b561f1 Updated from global requirements
943d2c0 Revert "Use latest CoreOS stable when building"
a39dfbd Updated from global requirements
ffcdcd4 Add mitaka reno page
cfcef97 Replace assertEqual(None, *) with assertIsNone in tests
b9df861 Catch up release notes for Mitaka
e8488c2 Add reno for release notes management
d185927 Fix trivial typo in docs
5bac998 Updated from global requirements
4cd64e2 Delete the Linux-IO target before setting up local boot
056bb42 CoreOS: Ensure /run is mounted before starting
6dc7f34 Deprecated tox -downloadcache option removed
a253e50 Use latest CoreOS stable when building
84fc428 Updated from global requirements
b5b0b63 Run IPA in chroot instead of container in CoreOS
5fa258b Fix "logs" inspection collector when logs contain non-ascii symbols
2fc6ce2 pyudev exception has changed for from_device_file
c474a5a Support Linux-IO in addition to tgtd
f4ad4d7 Updated from global requirements
863b47b Updated from global requirements
e320bb8 Add support for streaming raw images directly onto the disk
65053b7 Refactor the image download and checksum computation bits
c21409e Follow up patch for da9c3b0adc67efa916fc534d975823c0a45948a1
a01c4c9 Create partition at max msdos limit for disks > 2TB
54c901e Support proxies for image download
d97dbf2 Updated from global requirements
da9c3b0 Extend root device hints for different types of WWN
505b345 Fix to preserve double dashes of command line option in HTML.
59630d4 Updated from global requirements
9e75ba5 Use oslo.log instead of original logging
037e391 Updated from global requirements
18d5d6a Replace deprecated LOG.warn with LOG.warning
e51ccbe avoid duplicate text in ISCSIError message
fb920f4 determine tgtd ready status through tgtadm
f042be5 Updated from global requirements
1aeef4d Updated from global requirements
f01 Add param docstring into the normalize func
06d34ae Make calling arguments easier to understand
6131b2e Ensure all methods in utils.py have docstrings
7823240 Updated from global requirements
af20875 Update gitignore
5f7bc48 Reduce size of CoreOS ramdisk
deb50ac Add LOG.debug() if requested device type not found
d538f5e Babel is not a direct dependency

Re: [openstack-dev] [Nova] notification subteam meeting

2016-01-12 Thread Balázs Gibizer

Hi, 

The next meeting of the nova notification subteam will happen 2016-01-12 
Tuesday 20:00 UTC [1] on #openstack-meeting-alt on freenode 

Agenda:
- Status of the outstanding specs and code reviews
- AOB

See you there.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160112T20  
[2] https://wiki.openstack.org/wiki/Meetings/NovaNotification


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][tests] approach to functional/integration tests

On 01/11/2016 03:49 PM, Serge Kovaleff wrote:

Hi All,

Last week I had a noble goal to write "one-more" functional test in Ironic.
I did find a folder "func" but it was empty.

Friends helped me to find a WIP patch
https://review.openstack.org/#/c/235612/

and here comes the question of this email: what approach we would like
to implement:
Option 1 - write infrastructure code that starts/configure/stops the
services
Option 2 - rely on installed DevStack and run the tests over it

Both options have their Cons and Pros. Both options are implemented
across the OpenStack umbrella.
Option 1 - Glance, Nova, the patch above
Option 2 - HEAT and my favorite at the moment.

Any ideas?

I think we should eventually end up with supporting both standalone
functional tests (#1) and tempest-based (#3).

A bit of context on #1. We've been using it in ironic-inspector since
nearly its inception, when devstack plugins didn't exist and our project
was on stackforge, so we had no way of implementing our dsvm gate. The
basic idea is to start a full-featured service with mocked access to
other services and simplified environment. We've written a decorator [1]
that starts the service in __enter__ and stops in __exit__. It uses a
temporary configuration file [2] with authentication disabled and
database in temporary SQLite file. The service is started in a new green
thread and exits when the test exits. We mock ironicclient with the
usual 'mock' library to avoid requirements on a running ironic instance.

We do 2 kinds of tests: just an API test like [3] or full-flow
introspection tests like [4]. In the latter case we first start
introspection via API, verify that status is "in progress", then call
the ramdisk callback endpoint with a fake data, and verify that
introspection ends successfully.

Applying the same thing to ironic might be somewhat trickier. We can run
conductor and API in the same process and use oslo.messaging fake driver
[5] to avoid AMQP dependency. We'll have to use a fake network
implementation and either mock glance or make sure we use local file
system URL's for all images (IIRC we do support it).

Going further, if we create a simple fake IPA, we can even do a
full-flow test with fake_agent driver. We will start deployment, make
sure fake IPA was called with a right image, make it report success and
see deployment finish. We might want to modify fake interfaces to record
all calls, so that we can verify that boot interface was called properly.

[1]
https://github.com/openstack/ironic-inspector/blob/master/ironic_inspector/test/functional.py#L358-L393
[2]
https://github.com/openstack/ironic-inspector/blob/master/ironic_inspector/test/functional.py#L36-L51
[3]
https://github.com/openstack/ironic-inspector/blob/master/ironic_inspector/test/functional.py#L249-L291
[4]
https://github.com/openstack/ironic-inspector/blob/master/ironic_inspector/test/functional.py#L177-L196

[5] http://docs.openstack.org/developer/oslo.messaging/drivers.html#fake

Cheers,
Serge Kovaleff
http://www.mirantis.com
cell: +38 (063) 83-155-70

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break



> Doug Wiegley  wrote:
> >
> >
> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
> wrote:
> >>
> >> Sean M. Collins  wrote:
> >>
>  On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
> > On Fri, 8 Jan 2016, Gary Kotton wrote:
> >
> > The commit
> > https://github.com/openstack/neutron/commit/5d53dfb8d64186-
> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that
> > make use of the method _get_tenant_id_for_create
> 
>  Just out of curiosity, is it not standard practice that a plugin
>  shouldn't use a private method?
> >>>
> >>> +1 - hopefully decomposed plugins will audit their code and look for
> >>> other calls to private methods.
> >>
> >> The fact that it broke *aas repos too suggests that we were not
> >> showing a proper example to those decomposed. I think it can be
> >> reasonable to restore the method until N, with a deprecation message,
> >> as Garry suggested in his patch. Especially since there is no actual
> >> burden to keep the method for another cycle.
> >
> > The neutron community has been really lax about enforcing private
> methods.
> > And while we should absolutely reverse that trend, likely we should
> > give some warning. I agree with not going whole hog on that until N.
> >
> > I'd suggest putting in a debtcollector reference when putting the method
> back.
> 
> Done. https://review.openstack.org/265315


Do we have any consensus about treating private methods? Any general tips about 
it, or every time should it be left for author decision?

Should we use deprecation warning for all refactored private methods, treating 
it as "API" and rewriting underneath code?

Thanks, Dariusz (dasm) Smigiel

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC


> On 2016/01/12 7:14, Armando M. wrote:
>   On 11 January 2016 at 13:54, Hirofumi Ichihara
>  >
> wrote:
>   On 2016/01/12 5:14, Armando M. wrote:
>   On 11 January 2016 at 12:04, Carl Baldwin <
>  c...@ecbaldwin.net
>  > wrote:
> 
> 
>   What do we do?  My calendar was set up
> with the sane bi-weekly thing
>   and it shows the meeting for tomorrow.  The
> last word from our
>   fearless leader is that we'll have it today.  
> So,
> I'll be there today
>   unless instructed otherwise.
> 
>   The ics file now seems to reset the cadence
> beginning today at 2100
>   and next Tuesday, the 19th, at 1400.  I guess
> we should either hold
>   the meeting today and reset the cadence or
> fix the ics file.
> 
> 
> 
> 
>   This is what I would like to do now:
> 
>   https://review.openstack.org/#/c/266019
> 
>   I personally haven't seen that much of an attendance
> difference anyway, and at this point, it'll simplify our lives and avoid grief
> going forward.
> 
>   I like it.
> 
>   However, we have gathered from all over the world because
> neutron is big project. Should we have the choice so that more people get
> attendance opportunity?
> 
> 
>   This time, the return to the normal schedule was a disaster, plus
> every time we switch to daylight savings, or every time there's a holiday
> break/summit we have twice the chances to screw up if we keep the bi-
> weekly schedule.
> 
>   If I go and look at the logs [1] I don't have hard evidence that the bi-
> weekly schedule does indeed help the attendance of friendlier timezones,
> so I wonder...what's the point?
> 
> You're right. My reply was just general opinion. I think that most regular 
> folks
> probably attend both days now. I actually do as well.
> 
> I was worried that sometimes there are developers who introduce his bug or
> ask core to review although they usually don't attend. However, we have
> openstack-neutron channel for it.
> 
> 

In this case, we have Today's meeting, and from now on, just one weekly at 
Mondays 2100 UTC?

Dariusz (dasm) Smigiel

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

Hi,
I personally liked that fact that there were two times. It was reasonable to 
make an effort to stay up very late to attend the one and then have the 
privileged of the other being at a reasonable time. Now it is back to the crazy 
hours.
Thanks
Gary

From: Hirofumi Ichihara 
>
Reply-To: OpenStack List 
>
Date: Tuesday, January 12, 2016 at 1:39 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On 2016/01/12 7:14, Armando M. wrote:

On 11 January 2016 at 13:54, Hirofumi Ichihara 
> wrote:

On 2016/01/12 5:14, Armando M. wrote:

On 11 January 2016 at 12:04, Carl Baldwin 
<c...@ecbaldwin.net> 
wrote:
What do we do?  My calendar was set up with the sane bi-weekly thing
and it shows the meeting for tomorrow.  The last word from our
fearless leader is that we'll have it today.  So, I'll be there today
unless instructed otherwise.

The ics file now seems to reset the cadence beginning today at 2100
and next Tuesday, the 19th, at 1400.  I guess we should either hold
the meeting today and reset the cadence or fix the ics file.

This is what I would like to do now:

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

I personally haven't seen that much of an attendance difference anyway, and at 
this point, it'll simplify our lives and avoid grief going forward.
I like it.

However, we have gathered from all over the world because neutron is big 
project. Should we have the choice so that more people get attendance 
opportunity?

This time, the return to the normal schedule was a disaster, plus every time we 
switch to daylight savings, or every time there's a holiday break/summit we 
have twice the chances to screw up if we keep the bi-weekly schedule.

If I go and look at the logs [1] I don't have hard evidence that the bi-weekly 
schedule does indeed help the attendance of friendlier timezones, so I 
wonder...what's the point?
You're right. My reply was just general opinion. I think that most regular 
folks probably attend both days now. I actually do as well.

I was worried that sometimes there are developers who introduce his bug or ask 
core to review although they usually don't attend. However, we have 
openstack-neutron channel for it.

A.

[1] http://eavesdrop.openstack.org/meetings/networking/

Carl

On Mon, Jan 11, 2016 at 12:09 PM, Kevin Benton 
<blak...@gmail.com> wrote:
> The issue is simply that you have a sane bi-weekly thing setup in your
> calendar. What we have for Neutron is apparently defined as “odd and even
> weeks when weeks are represented as an short integer counting from the first
> of the year”, a.k.a. “bi-weekly” as a robot might define it. :)
>
>
> On Jan 11, 2016, at 11:00 AM, Kyle Mestery 
> <mest...@mestery.com> 
> wrote:
>
> On Mon, Jan 11, 2016 at 12:57 PM, Kyle Mestery 
> <mest...@mestery.com> 
> wrote:
>>
>> On Mon, Jan 11, 2016 at 12:45 PM, Armando M. 
>> <arma...@gmail.com> 
>> wrote:
>>>
>>> Disregard the email subject.
>>>
>>> I stand corrected. Let's meet today.
>>>
>>
>> Something is wrong, I have the meeting on my google calendar, and it shows
>> up as tomorrow for this week. I've had these setup as rotating for a while
>> now, so something is fishy with the .ics files.
>
>
> If you look here [1], the meeting cadence was:
>
> 12-15-2015: Tuesday
> 12-21-2015: Monday
> 12-29-2015: Tuesday (skipped)
> 01-04-2016: Monday (skipped)
> 01-12-2016 Tuesday
>
> The meeting is tomorrow.
>
> [1] http://eavesdrop.openstack.org/meetings/networking/2015/
>>
>>
>>>
>>> On 11 January 2016 at 10:24, Ihar Hrachyshka 
>>> <ihrac...@redhat.com>
>>>  wrote:

 Armando M. 
 <arma...@gmail.com> 
 wrote:

> Hi neutrinos,
>
> A kind reminder for tomorrow's meeting at 1400UTC.
>
> Cheers,
> Armando
>
> [1]  
> https://wiki.openstack.org/wiki/Network/Meetings
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
>  
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

2016-01-12 Thread Aleksandr Didenko

Hi,

> b) Make the snapshot location share the diskspace of /var/log?

+1 for that. And +1 for using hard links to save space during snapshot
creation.

Regards,
Alex

On Tue, Jan 12, 2016 at 12:12 PM, Artem Panchenko 
wrote:

> Hi,
>
> doesn't matter how /var partition is big, diagnostic snapshot still could
> occupy all its space if there are lots of logs on slave nodes. Although, we
> can try to control disk space usage by snapshot in shotgun, but IMHO it's
> much safer to keep all related to logs staff away from critical system
> files, so I'm voting for 2nd (b) option. By the way it will allow us to use
> hard links for fast copying of files before creating tarball, because one
> partition for storing logs and snapshot will be used.
>
> Thanks!
>
>
> On 12.01.16 12:47, Maciej Kwiek wrote:
>
> Hi!
>
> I need some advice on how to tackle this issue. There is a bug [1]
> describing the problem with creating a diagnostic snapshot. The issue is
> that /var/log has 100GB available, while /var (where diagnostic snapshot is
> being generated - /var/www/nailgun/dump/fuel-snapshot according to [2]) has
> 10GB available, so dumping the logs can be an issue when logs size exceed
> free space in /var.
>
> There are several things we could do, but I am unsure on which course to
> take. Should we
> a) Allocate more disk space for /var/www (or for whole /var)?
> b) Make the snapshot location share the diskspace of /var/log?
> c) Something else? What?
>
> Please share your thoughts on this.
>
> Cheers,
> Maciej Kwiek
>
> [1] https://bugs.launchpad.net/fuel/+bug/1529182
> [2]
> https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Artem Panchenko
> QA Engineer
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Routing in Horizon

2016-01-12 Thread Matthias Runge

On 12/01/16 11:22, Matthias Runge wrote:

> 
> https://launchpad.net/bugs/1532759
> 
> Unfortunately, that even hasn't been detected by tests.
> 
https://github.com/openstack/horizon/commit/871505c130cf1fd02aae41aeb8f6062af4a5fe88

fixes this issue (another revert).

Matthias


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

2016-01-12 Thread Miguel Angel Ajo

I agree with Gary here,

   The 21:00 UTC time here is a difficult time for me, because it's 
exactly the time of getting kids to sleep

at home. It's generally very unpredictable for me.

I missed last meeting exactly because of that, laptop was ready, I 
was ready, kids didn't cooperate.

I will do my best to be there every 21:00 UTC if it's finally 
changed, but, I can't guarantee.

Ihar Hrachyshka wrote:
Agreed with Gary on behalf of my European compatriots. (Note that I 
*personally* +1’d the patch because I don’t mind, doing late hours 
anyway; but it’s sad it was ninja merged without giving any chance for 
those from affected timezones to express their concerns).

Ihar

Gary Kotton  wrote:

Hi,
I personally liked that fact that there were two times. It was 
reasonable to make an effort to stay up very late to attend the one 
and then have the privileged of the other being at a reasonable time. 
Now it is back to the crazy hours.

Thanks
Gary

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Tuesday, January 12, 2016 at 1:39 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On 2016/01/12 7:14, Armando M. wrote:
On 11 January 2016 at 13:54, Hirofumi Ichihara 
 wrote:

On 2016/01/12 5:14, Armando M. wrote:

On 11 January 2016 at 12:04, Carl Baldwin  wrote:

What do we do?  My calendar was set up with the sane bi-weekly thing
and it shows the meeting for tomorrow.  The last word from our
fearless leader is that we'll have it today.  So, I'll be there 
today

unless instructed otherwise.

The ics file now seems to reset the cadence beginning today at 2100
and next Tuesday, the 19th, at 1400.  I guess we should either hold
the meeting today and reset the cadence or fix the ics file.

This is what I would like to do now:

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

I personally haven't seen that much of an attendance difference 
anyway, and at this point, it'll simplify our lives and avoid 
grief going forward.

I like it.

However, we have gathered from all over the world because neutron 
is big project. Should we have the choice so that more people get 
attendance opportunity?

This time, the return to the normal schedule was a disaster, plus 
every time we switch to daylight savings, or every time there's a 
holiday break/summit we have twice the chances to screw up if we 
keep the bi-weekly schedule.

If I go and look at the logs [1] I don't have hard evidence that the 
bi-weekly schedule does indeed help the attendance of friendlier 
timezones, so I wonder...what's the point?
You're right. My reply was just general opinion. I think that most 
regular folks probably attend both days now. I actually do as well.

I was worried that sometimes there are developers who introduce his 
bug or ask core to review although they usually don't attend. 
However, we have openstack-neutron channel for it.

A.

[1] http://eavesdrop.openstack.org/meetings/networking/

Carl

On Mon, Jan 11, 2016 at 12:09 PM, Kevin Benton 
 wrote:
> The issue is simply that you have a sane bi-weekly thing setup 
in your
> calendar. What we have for Neutron is apparently defined as 
“odd and even
> weeks when weeks are represented as an short integer counting 
from the first

> of the year”, a.k.a. “bi-weekly” as a robot might define it. :)
>
>
> On Jan 11, 2016, at 11:00 AM, Kyle Mestery 
 wrote:

>
> On Mon, Jan 11, 2016 at 12:57 PM, Kyle Mestery 
 wrote:

>>
>> On Mon, Jan 11, 2016 at 12:45 PM, Armando M. 
 wrote:

>>>
>>> Disregard the email subject.
>>>
>>> I stand corrected. Let's meet today.
>>>
>>
>> Something is wrong, I have the meeting on my google calendar, 
and it shows
>> up as tomorrow for this week. I've had these setup as rotating 
for a while

>> now, so something is fishy with the .ics files.
>
>
> If you look here [1], the meeting cadence was:
>
> 12-15-2015: Tuesday
> 12-21-2015: Monday
> 12-29-2015: Tuesday (skipped)
> 01-04-2016: Monday (skipped)
> 01-12-2016 Tuesday
>
> The meeting is tomorrow.
>
> [1] http://eavesdrop.openstack.org/meetings/networking/2015/
>>
>>
>>>
>>> On 11 January 2016 at 10:24, Ihar Hrachyshka 
 wrote:

 Armando M.  wrote:

> Hi neutrinos,
>
> A kind reminder for tomorrow's meeting at 1400UTC.
>
> Cheers,
> Armando
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
>
> 
__ 

> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

2016-01-12 Thread Simon Pasquier

Hello Alicja,

Comments inline.

On Tue, Jan 12, 2016 at 1:19 PM, Kwasniewska, Alicja <
alicja.kwasniew...@intel.com> wrote:

> Unfortunately I do not have any experience in working or testing Heka, so
> it’s hard for me to compare its performance vs Logstash performance.
> However I’ve read that Heka possess a lot advantages over Logstash in this
> scope.
>
>
> But which version of Logstash did you test? One guy from the Logstash
> community said that: *“The next release of logstash (1.2.0 is in beta)
> has a 3.5x improvement in event throughput. For numbers: on my workstation
> at home (6 vcpu on virtualbox, host OS windows, 8 GB ram, host cpu is
> FX-8150) - with logstash 1.1.13, I can process roughly 31,000 events/sec
> parsing apache logs. With logstash 1.2.0.beta1, I can process 102,000
> events/sec.”*
>
>
> You also said that Heka is a unified data processing, but do we need this?
> Heka seems to address stream processing needs, while Logstash focuses
> mainly on processing logs. We want to create a central logging service, and
> Logstash was created especially for it and seems to work well for this
> application.
>
>
> One thing that is obvious is the fact that the Logstash is better known,
> more popular and tested. Maybe it has some performance disadvantages, but
> at least we know what we can expect from it. Also, it has more pre-built
> plugins and has a lot examples of usage, while Heka doesn’t have many of
> them yet and is nowhere near the range of plugins and integrations provided
> by Logstash.
>

>From my experience, Heka has already a large number of plugins that cover
most of the use cases. But I understand your concerns regarding the
adoption of Heka vs Logstash.


>
>
> In the case of adding plugins, I’ve read that in order to add Go plugins,
> the binary has to be recompiled, what is a little bit frustrating (static
> linking - to wire in new plugins, have to recompile). On the other hand,
> the Lua plugins do not require it, but the question is whether Lua plugins
> are sufficient? Or maybe adding Go plugins is not so bad?
>

For the reason that you pointed, Lua plugins are first-class citizens and
the Heka developers encourage their use over writing custom Go plugins. In
terms of performances, Lua and Go plugins are usually equivalent.


>
>
> You also said that you didn’t test the Heka with Docker, right? But do you
> have any experience in setting up Heka in Docker container? I saw that with
> Heka 0.8.0 new Docker features were implemented (included Dockerfiles to
> generate Heka Docker containers for both development and deployment), but
> did you test it? If you didn’t, we could not be sure whether there are any
> issues with it.
>

>From my experience, Heka runs in Docker without problem.


>
>
> Moreover you will have to write your own Dockerfile for Heka that inherits
> from Kolla base image (as we discussed during last meeting, we would like
> to have our own images), you won’t be able to inherit from
> ianneub/heka:0.10 as specified in the link that you sent
> http://www.ianneubert.com/wp/2015/03/03/how-to-use-heka-docker-and-tutum/.
>

Since the Heka binary embeds all its dependencies, writing the Dockerfile
shouldn't be hard.


>
>
> There are also some issues with DockerInput Module which you want to use.
> For example splitters are not available in DockerInput (
> https://github.com/mozilla-services/heka/issues/1643). I can’t say that
> it will affect us, but we also don’t know which new issues may arise during
> first tests, as any of us has ever tried Heka in and with Dockers.
>

Good point. This should be investigated by Eric in his specification.


>
>
> I am not stick to any specific solution, however just not sure whether
> Heka won’t surprise us with something hard to solve, configure, etc.
>

I just wanted to mention that Heka powers the Firefox Telemetry Data
Pipeline [1] which collects and processes many data.

Simon

[1] https://people.mozilla.org/~rmiller/heka-monitorama-2015-06/#/41


>
>
>
> * Alicja Kwaśniewska*
>
>
>
> *From:* Sam Yaple [mailto:sam...@yaple.net]
> *Sent:* Monday, January 11, 2016 11:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [kolla] Introduction of Heka in Kolla
>
>
>
> Here is why I am on board with this. As we have discovered, the logging
> with the syslog plugin leaves alot to be desired. It (to my understanding)
> still can't save tracebacks/stacktraces to the log files for whatever
> reason. stdout/stderr however works perfectly fine. That said the Docker
> log stuff has been a source of pain in the past, but it has gotten better.
> It does have the limitation of being only able to log one output at a time.
> This means, as an example, the neutron-dhcp-agent could send its logs to
> stdout/err but the dnsmasq process that it launch (that also has logs)
> would have to mix its logs in with the neutron logs in stdout/err. Can Heka
> handle this and separate them

Re: [openstack-dev] [Horizon] Routing in Horizon

2016-01-12 Thread Itxaka Serrano Garcia


> El 12 ene 2016, a las 11:22, Matthias Runge  escribió:
> 
> On 12/01/16 03:33, Richard Jones wrote:
>> The  tag addition has had to be reverted as it broke other parts
>> of the application (notably lazy loaded tabs like Instance Details), sadly.
>> 
>> Regarding which router to use - I've used the built-in router in the
>> past quite successfully. I think I'd want to see a solid reason for
>> using a 3rd party one. It could be that nested routes are part of that,
>> but I kinda see that as a convenience thing, unless I'm missing
>> something core to how routing is planned to be done. Then again we
>> really haven't had any discussion about how we see routing work. The one
>> patch that's up that uses routing seems perfectly able to do so without
>> needing extended capabilities of 3rd party routers.
> 
> I believe, there has been something else messing up with routing,
> causing pagination to be broken now.
> 
> https://launchpad.net/bugs/1532759
> 
> Unfortunately, that even hasn't been detected by tests.
> 
> Matthias
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Also see https://bugs.launchpad.net/horizon/+bug/1532265

Any link that has an href="#" is probably broken.

If I'm not mistaken, the # is what angular uses as locationprovider?

Itxaka
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

> 
> Hi,
> At the moment private methods are used all over the place. Examples for
> this are the address pairs and the security groups. If you do a grep of the 
> ML2
> plugin you will see these innocent private methods being used.
> The end goal would be for us to have these as public methods.
> Thanks
> Gary
> 

OK, get it. But just wanted to know, what is the outcome from email discussion.
Do we need to match changed/removed private methods with deprecation warning,
or just modify and tell plugins: "deal with it" :)

BR,
Dariusz (dasm) Smigiel

> 
> 
> 
> On 1/12/16, 11:52 AM, "Smigiel, Dariusz"  wrote:
> 
> >
> >
> >> Doug Wiegley  wrote:
> >> >
> >> >
> >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
> >> wrote:
> >> >>
> >> >> Sean M. Collins  wrote:
> >> >>
> >>  On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
> >> > On Fri, 8 Jan 2016, Gary Kotton wrote:
> >> >
> >> > The commit
> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com
> >> > _openstack_neutron_commit_5d53dfb8d64186-
> 2D=BQICAg=Sqcl0Ez6
> >> > M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
> uEs=VlZxHpZBmzzkWT5jqz9JYBk8Y
> >> > Teq9N3-
> diTlNj4GyNc=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
> >> > w=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8=
> >> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
> >> > that make use of the method _get_tenant_id_for_create
> >> 
> >>  Just out of curiosity, is it not standard practice that a plugin
> >>  shouldn't use a private method?
> >> >>>
> >> >>> +1 - hopefully decomposed plugins will audit their code and look
> >> >>> +for
> >> >>> other calls to private methods.
> >> >>
> >> >> The fact that it broke *aas repos too suggests that we were not
> >> >> showing a proper example to those decomposed. I think it can be
> >> >> reasonable to restore the method until N, with a deprecation
> >> >> message, as Garry suggested in his patch. Especially since there
> >> >> is no actual burden to keep the method for another cycle.
> >> >
> >> > The neutron community has been really lax about enforcing private
> >> methods.
> >> > And while we should absolutely reverse that trend, likely we should
> >> > give some warning. I agree with not going whole hog on that until N.
> >> >
> >> > I'd suggest putting in a debtcollector reference when putting the
> >> > method
> >> back.
> >>
> >> Done. https://review.openstack.org/265315
> >
> >
> >Do we have any consensus about treating private methods? Any general
> tips about it, or every time should it be left for author decision?
> >
> >Should we use deprecation warning for all refactored private methods,
> treating it as "API" and rewriting underneath code?
> >
> >Thanks, Dariusz (dasm) Smigiel
> >

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Enabling Graphana GUI from Horizon

2016-01-12 Thread Pradip Mukhopadhyay

Hello,


We're using the following fullsetup to install Monasca (python):

https://github.com/openstack/monasca-api/tree/master/devstack



Most likely we need to do something more to see the "Monitoring" tab in
left hand side that takes us to Monasca graphana GUI.


Can anyone please point me?


We do see it when do a vagrant setup with mini-mon and devstack VMs.


Any help is highly solicited.


--pradip
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

2016-01-12 Thread Esra Celik

- Orijinal Mesaj -

> Kimden: "Markus Zoeller" 
> Kime: "OpenStack Development Mailing List"
> 
> Gönderilenler: 12 Ocak Salı 2016 10:58:28
> Konu: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

> Esra Celik  wrote on 01/12/2016 08:21:34 AM:

> > From: Esra Celik 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > , Markus Zoeller/Germany/IBM@IBMDE
> > Date: 01/12/2016 08:21 AM
> > Subject: Re: [openstack-dev] [nova] config options: IRC meeting at Jan.
> 11th
> >
> > Hi Markus
> >
> > I am sorry that I missed the meeting. Bu it seems like sfinucan
> > already asked what was in my mind, like getting the patches merged
> faster..
> > From the logs I finally understood what "single point of entry for
> > sample config generation" is for. So I will wait that to be merged and
> > rebase my patches [1],[2],[3], is it ok?

> OK, cool, that's what I hoped for :)
> It got merged yesterday evening. A rebase of your open patches makes
> sense now. Don't forget to adjust the return value of "list_opts" in
> your modules.

OK, I adjusted the return value of list_opts.. 

> > Now should I work on some other patches? nova/compute/manager.py
> > options seem nice :)
> > Or should I focus on later patches that will improve the help texts?
> >
> > [1] https://review.openstack.org/#/c/254092/
> > [2] https://review.openstack.org/#/c/255124/
> > [3] https://review.openstack.org/#/c/260181/
> >
> > Best Regards,
> > esracelik

> I think we have the technical and organizational issues solved now
> and we should focus on enhancing the help texts of the config options
> you have moved in other patches to give the core reviewers a single
> bucket of a finished piece of work to review.
We will wait for the moved config options to be merged to prepare another 
patchset with improved help texts, right? 
I could actually commit a patch with improved help texts that depends on the 
first patch.. 

> I do also realize now that I didn't make you aware of the possibility
> to prevent a re-introduction of options in the modules you already
> cleaned [1]. I think that could be useful.

I am not sure if I understood this correctly. Do you mean we should check if 
any changes to the options occurred since we moved them to nove/conf directory? 

> References:
> [1]
> https://github.com/openstack/nova/blob/928813ca2b23690b4468830dd70a6cc6048181fa/nova/hacking/checks.py#L567

> Regards, Markus Zoeller (markus_z)

> > Kimden: "Markus Zoeller" 
> > Kime: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Gönderilenler: 11 Ocak Pazartesi 2016 17:47:23
> > Konu: Re: [openstack-dev] [nova] config options: IRC meeting at Jan.
> 11th
> >
> > Markus Zoeller/Germany/IBM@IBMDE wrote on 01/08/2016 03:21:28 PM:
> >
> > > From: Markus Zoeller/Germany/IBM@IBMDE
> > > To: "OpenStack Development Mailing List (not for usage questions)"
> > > 
> > > Date: 01/08/2016 03:22 PM
> > > Subject: [openstack-dev] [nova] config options: IRC meeting at Jan.
> 11th
> > >
> > > First things first, I'd like to thank those people who are
> contributing
> > > to this task very much! It's good to see the progress we already made
> > > and that the knowledge of this area is now spread amongst more people.
> > >
> > > The second thing I'd like to talk about is the next steps.
> > > It would be great if we could have a short realtime conversation in
> IRC
> > > to:
> > > * make clear that the help text changes are necessary for a patch
> series
> > > * clarify open questions from your side
> > > * discuss the impact of [1] which should be the last piece in place
> > > which reduces the merge conflicts we faced to a very minimum.
> > >
> > > Let's use the channel #openstack-meeting-3 at coming Monday,
> > > January the 11th, at 15:00 UTC for that.
> > >
> > > References:
> > > [1] "single point of entry for sample config generation"
> > > https://review.openstack.org/#/c/260015
> > >
> > > Regards, Markus Zoeller (markus_z)
> >
> > In case you missed it (it was on short notice), here are the logs:
> > http://eavesdrop.openstack.org/meetings/nova_config_options/2016/
> > nova_config_options.2016-01-11-15.01.log.html
> >
> > Let me know if you have questions.
> >
> > Regards, Markus Zoeller (markus_z)
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

2016-01-12 Thread Oleg Gelbukh

I think we need to find a way to:

1) verify the size of snapshot without actually making it and compare to
the available disk space beforehand.
2) refuse to create snapshot if space is insufficient and notify user
(otherwise it breaks Admin node as we have seen)
3) provide a way to prioritize elements of the snapshot and exclude them
based on the priorities or user choice.

This will allow for better and safer UX with the snapshot.

--
Best regards,
Oleg Gelbukh

On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek  wrote:

> Hi!
>
> I need some advice on how to tackle this issue. There is a bug [1]
> describing the problem with creating a diagnostic snapshot. The issue is
> that /var/log has 100GB available, while /var (where diagnostic snapshot is
> being generated - /var/www/nailgun/dump/fuel-snapshot according to [2]) has
> 10GB available, so dumping the logs can be an issue when logs size exceed
> free space in /var.
>
> There are several things we could do, but I am unsure on which course to
> take. Should we
> a) Allocate more disk space for /var/www (or for whole /var)?
> b) Make the snapshot location share the diskspace of /var/log?
> c) Something else? What?
>
> Please share your thoughts on this.
>
> Cheers,
> Maciej Kwiek
>
> [1] https://bugs.launchpad.net/fuel/+bug/1529182
> [2]
> https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] InvalidRequestError: This session is in 'prepared' state; no further SQL can be emitted within this transaction.

2016-01-12 Thread Koteswar

I tried rollback but still it didn't work. This issue is reproduced
sometimes only when
1. neutron port created
2. enable fixed looping in conf, stop neutron and start
3. delete neutron port

and looping interval is very lesss say 20 secs.
source code where it fails:
--
def get_bnp_neutron_port(context, neutron_port_id):
"""Get bnp neutron port that matches neutron_port_id."""
try:
query = context.session.query(models.BNPNeutronPort)
port_map = query.filter_by(neutron_port_id=neutron_port_id).one()
except exc.NoResultFound:
LOG.error(_LE('no port map found with id: %s'), port_map)
return
except Exception as e:
LOG.error("BNP Exception: %s", e)
context.session.rollback()
return
return port_map

trace:
-
2016-01-12 07:00:54.421 ERROR
baremetal_network_provisioning.db.bm_nw_provision_db
[req-79c61136-2f15-40b6-a0c7-074848d87d6e admin
1395aaf0481f4bc9b8fbbe555fe1] BNP Exception: This se
ssion is in 'prepared' state; no further SQL can be emitted within this
transaction.
2016-01-12 07:00:54.421 ERROR oslo_db.sqlalchemy.exc_filters
[req-79c61136-2f15-40b6-a0c7-074848d87d6e admin
1395aaf0481f4bc9b8fbbe555fe1] DB exception wrapped.
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters Traceback
(most recent call last):
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters   File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line
668, in _rollback_impl
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters
self.engine.dialect.do_rollback(self.connection)
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters   File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/dialects/mysql/base.py",
line 2519, in do_rollback
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters
dbapi_connection.rollback()
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters   File
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 724,
in rollback
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters
self._read_ok_packet()
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters   File
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 698,
in _read_ok_packet
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters pkt =
self._read_packet()
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters   File
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 895,
in _read_packet
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters
packet_header = self._read_bytes(4)
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters   File
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 912,
in _read_bytes
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters data =
self._rfile.read(num_bytes)
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters RuntimeError:
reentrant call inside <_io.BufferedReader name=3>
2016-01-12 07:00:54.421 TRACE oslo_db.sqlalchemy.exc_filters
2016-01-12 07:00:54.433 ERROR neutron.plugins.ml2.managers
[req-79c61136-2f15-40b6-a0c7-074848d87d6e admin
1395aaf0481f4bc9b8fbbe555fe1] Mechanism driver 'hp' failed in
delete_port_pr
ecommit


On Mon, Jan 11, 2016 at 7:39 PM, Koteswar  wrote:

> thanks a lot. I will try this.
>
> On Mon, Jan 11, 2016 at 7:26 PM, Mike Bayer  wrote:
>
>>
>>
>> On 01/11/2016 03:58 AM, Koteswar wrote:
>> > Hi All,
>> >
>> >
>> >
>> > In my mechanism driver, I am reading/writing into sql db in a fixed
>> > interval looping call. Sometimes I get the following error when I stop
>> > and start neutron server
>> >
>> > InvalidRequestError: This session is in 'prepared' state; no further SQL
>> > can be emitted within this transaction.
>> >
>> >
>> >
>> > I am using context.session.query() for add, delete, update and get.
>> > Please help me if any one resolved an issue like this.
>>
>> the stack trace is unfortunately re-thrown from the ml2.managers code
>> without retaining the original traceback; use this form to reraise with
>> original tb:
>>
>> exc_info = sys.exc_info()
>> raise type(e), e, exc_info[2]
>>
>> There's likely helpers somewhere in oslo that do this.
>>
>> The cause of this error is that a transaction commit is failing, the
>> error is being caught and this same Session is being used again without
>> rollback called first.   The code below illustrates the problem and how
>> to solve.
>>
>> from sqlalchemy import create_engine
>> from sqlalchemy.orm import Session
>>
>>
>> e = create_engine("sqlite://")
>>
>> s = Session(e)
>>
>>
>> conn = s.connection()
>>
>>
>> def boom():
>> raise Exception("sqlite commit failed")
>>
>> # "break" connection.commit(),
>> # so that the commit fails
>> conn.connection.commit = boom
>> try:
>> # fail
>> s.commit()
>> except Exception, e:
>> # uncomment this to fix

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Michał Dulko

On 01/12/2016 03:02 PM, Chris Dent wrote:
> On Tue, 12 Jan 2016, Amrith Kumar wrote:
>
>> if var > 0:
>> ... something ...
>>
>> To
>>
>> if var:
>> ... something ...
>
> I may be missing something but the above is not a stylistic change
> if var can ever be negative. In one of the ceilometer changes[1] for
> example, this change will change the flow of the code. In this
> particular example if some caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope
> of the damage is limited, but I prefer the more explicit > 0.
>
> I've not checked all the reviews but if it is showing up in one
> place seems like it could in others.
>
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py
>

Same thing for Cinder change - it's failing multiple unit tests because
this changes the logic of the statement.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread gord chung

not a fan of these changes since it messes up git blame and it becomes 
harder to track down author if you have questions relating to bug/code.


that said, "if var > 0" is not the same as "if var". in the latter, var 
can be any number (negative or positive) or any other datatype and it'll 
evaluate to True. so... don't blindly do this.


On 12/01/2016 8:51 AM, Amrith Kumar wrote:

I've tagged this message with the projects impacted by a series of change sets:

[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how to 
proceed with this change, and changes like this.

The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something ...

In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.

For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable.

Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron]{l2-gateway] is this project alive

Its like a desert out here trying to get a review…
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Ihar Hrachyshka


Amrith Kumar  wrote:

I've tagged this message with the projects impacted by a series of change  
sets:


[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how  
to proceed with this change, and changes like this.


The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something …


The change is not stylistic. F.e. before the change, var == -1 would not  
result in triggering the conditional body; while in the new version, it  
does trigger it. Unless the assumption that var is >= 0 is always true,  
it’s just a wrong change. F.e. I suspect in *, you effectively make error  
code returned by fork() (-1) to be considered as successful value.


* https://review.openstack.org/#/c/266156/1/neutron/agent/linux/daemon.py

I also don’t see any value in such a change.



In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be  
handled in a consistent way across all projects, maybe with a hacking  
rule and some discussion on the ML first? After all, if this change is  
worthwhile, it is worth ensuring that this construct that we are seeking  
to eliminate, does not reenter the code base.




If a stylistic change is worth it and can be automated, yes, it’s better to  
have a hacking rule for that. Though I doubt that’s the case here.


For what it is worth, I agree with Vitaly Grindev [sahara, in review  
https://review.openstack.org/#/c/266230/1]. I think the code before the  
change was more intuitive and readable.


Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Chris Dent


On Tue, 12 Jan 2016, Amrith Kumar wrote:


if var > 0:
... something ...

To

if var:
... something ...


I may be missing something but the above is not a stylistic change
if var can ever be negative. In one of the ceilometer changes[1] for
example, this change will change the flow of the code. In this
particular example if some caller do _do_test_iter_images sends
page_size=-1 bad things will happen. Since it is test code the scope
of the damage is limited, but I prefer the more explicit > 0.

I've not checked all the reviews but if it is showing up in one
place seems like it could in others.

[1] 
https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

2016-01-12 Thread Vikram Choudhary

21:00 UTC is too difficult for me to attend. It's early morning (2:30 AM) ;(

On Tue, Jan 12, 2016 at 6:17 PM, Miguel Angel Ajo 
wrote:

> I agree with Gary here,
>
>The 21:00 UTC time here is a difficult time for me, because it's
> exactly the time of getting kids to sleep
> at home. It's generally very unpredictable for me.
>
> I missed last meeting exactly because of that, laptop was ready, I was
> ready, kids didn't cooperate.
>
> I will do my best to be there every 21:00 UTC if it's finally changed,
> but, I can't guarantee.
>
>
> Ihar Hrachyshka wrote:
>
>> Agreed with Gary on behalf of my European compatriots. (Note that I
>> *personally* +1’d the patch because I don’t mind, doing late hours anyway;
>> but it’s sad it was ninja merged without giving any chance for those from
>> affected timezones to express their concerns).
>>
>> Ihar
>>
>> Gary Kotton  wrote:
>>
>> Hi,
>>> I personally liked that fact that there were two times. It was
>>> reasonable to make an effort to stay up very late to attend the one and
>>> then have the privileged of the other being at a reasonable time. Now it is
>>> back to the crazy hours.
>>> Thanks
>>> Gary
>>>
>>> From: Hirofumi Ichihara 
>>> Reply-To: OpenStack List 
>>> Date: Tuesday, January 12, 2016 at 1:39 AM
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC
>>>
>>>
>>>
>>> On 2016/01/12 7:14, Armando M. wrote:
>>>
 On 11 January 2016 at 13:54, Hirofumi Ichihara <
 ichihara.hirof...@lab.ntt.co.jp> wrote:

> On 2016/01/12 5:14, Armando M. wrote:
>
>> On 11 January 2016 at 12:04, Carl Baldwin  wrote:
>>
>>> What do we do?  My calendar was set up with the sane bi-weekly thing
>>> and it shows the meeting for tomorrow.  The last word from our
>>> fearless leader is that we'll have it today.  So, I'll be there today
>>> unless instructed otherwise.
>>>
>>> The ics file now seems to reset the cadence beginning today at 2100
>>> and next Tuesday, the 19th, at 1400.  I guess we should either hold
>>> the meeting today and reset the cadence or fix the ics file.
>>>
>>
>> This is what I would like to do now:
>>
>> https://review.openstack.org/#/c/266019
>>
>> I personally haven't seen that much of an attendance difference
>> anyway, and at this point, it'll simplify our lives and avoid grief going
>> forward.
>>
> I like it.
>
> However, we have gathered from all over the world because neutron is
> big project. Should we have the choice so that more people get attendance
> opportunity?
>

 This time, the return to the normal schedule was a disaster, plus every
 time we switch to daylight savings, or every time there's a holiday
 break/summit we have twice the chances to screw up if we keep the bi-weekly
 schedule.

 If I go and look at the logs [1] I don't have hard evidence that the
 bi-weekly schedule does indeed help the attendance of friendlier timezones,
 so I wonder...what's the point?

>>> You're right. My reply was just general opinion. I think that most
>>> regular folks probably attend both days now. I actually do as well.
>>>
>>> I was worried that sometimes there are developers who introduce his bug
>>> or ask core to review although they usually don't attend. However, we have
>>> openstack-neutron channel for it.
>>>
>>> A.

 [1] http://eavesdrop.openstack.org/meetings/networking/

> Carl
>>>
>>> On Mon, Jan 11, 2016 at 12:09 PM, Kevin Benton 
>>> wrote:
>>> > The issue is simply that you have a sane bi-weekly thing setup in
>>> your
>>> > calendar. What we have for Neutron is apparently defined as “odd
>>> and even
>>> > weeks when weeks are represented as an short integer counting from
>>> the first
>>> > of the year”, a.k.a. “bi-weekly” as a robot might define it. :)
>>> >
>>> >
>>> > On Jan 11, 2016, at 11:00 AM, Kyle Mestery 
>>> wrote:
>>> >
>>> > On Mon, Jan 11, 2016 at 12:57 PM, Kyle Mestery <
>>> mest...@mestery.com> wrote:
>>> >>
>>> >> On Mon, Jan 11, 2016 at 12:45 PM, Armando M. 
>>> wrote:
>>> >>>
>>> >>> Disregard the email subject.
>>> >>>
>>> >>> I stand corrected. Let's meet today.
>>> >>>
>>> >>
>>> >> Something is wrong, I have the meeting on my google calendar, and
>>> it shows
>>> >> up as tomorrow for this week. I've had these setup as rotating
>>> for a while
>>> >> now, so something is fishy with the .ics files.
>>> >
>>> >
>>> > If you look here [1], the meeting cadence was:
>>> >
>>> > 12-15-2015: Tuesday
>>> > 12-21-2015: Monday

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread David Stanek

On Tue, Jan 12, 2016 at 8:51 AM, Amrith Kumar  wrote:

> I've tagged this message with the projects impacted by a series of change
> sets:
>
> [trove] https://review.openstack.org/#/c/266220/
> [neutron] https://review.openstack.org/#/c/266156/1
> [cinder] https://review.openstack.org/#/c/266099/2
> [swift] https://review.openstack.org/#/c/266185/1
> [ceilometer] https://review.openstack.org/#/c/266211/1
> [nova] https://review.openstack.org/#/c/266143/2
> [keystone] https://review.openstack.org/#/c/266203/2
> [sahara] https://review.openstack.org/#/c/266230/1
> [glance] https://review.openstack.org/#/c/266192/1
> [neutron-lbaas] https://review.openstack.org/#/c/266181/1
>
> I would like the guidance of the developer community in figuring out how
> to proceed with this change, and changes like this.
>
> The change, in essence changes a construct of the kind:
>
> if var > 0:
> ... something ...
>
> To
>
> if var:
> ... something ...
>
> In a couple of cases, it also changes messages from (for example, in Trove)
>
> "Limit value must be > 0" to
> "Limit value must be greater than zero"
>
> My question to the ML is this, should stylistic changes of this kind be
> handled in a consistent way across all projects, maybe with a hacking rule
> and some discussion on the ML first? After all, if this change is
> worthwhile, it is worth ensuring that this construct that we are seeking to
> eliminate, does not reenter the code base.
>

The code above is not stylistic in nature.  It actually changes the
semantics of the check. This should not be done blindly across the board.

In the first case it looks for a value to be greater than a constant. In
the second case it looks for a value to have a truthy value.


> For what it is worth, I agree with Vitaly Grindev [sahara, in review
> https://review.openstack.org/#/c/266230/1]. I think the code before the
> change was more intuitive and readable.
>

Only if the code is correct. In that review I saw you changing "len(x) > 0"
to "len(x)" and that's fine. But you also changed a check looking at the
status code from a conductor call to no longer allow negative return
values. I have no idea if it returns negative numbers, but in this case I
would guess the "> 0" had a purpose.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone][Neutron][Nova] Keystone v3 with "old" clients

Hello,
I'm trying to gather all the info necessary to migrate to keystone v3 in 
Neutron.
When I've started to looking through possible problems with clients, it 
occurred that 'neutron' and 'nova' clients do not want to operate with Keystone 
v3.
For keystone client, it's explicit written, that this version is deprecated and 
not supported, so it's not working with Keystone API v3. But for nova and 
neutron, there is nothing.
I didn't see any place where I can find info, that "old" clients shouldn't be 
used with Keystone API v3.

Am I doing something wrong?

http://paste.openstack.org/show/483568/

-- 
 Dariusz (dasm) Smigiel
 Intel Technology Poland



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

2016-01-12 Thread Dan Prince

On Tue, 2016-01-12 at 12:52 +0100, Jiri Tomasek wrote:
> On 01/11/2016 04:51 PM, Dan Prince wrote:
> > Background info:
> > 
> > We've got a problem in TripleO at the moment where many of our
> > workflows can be driven by the command line only. This causes some
> > problems for those trying to build a UI around the workflows in
> > that
> > they have to duplicate deployment logic in potentially multiple
> > places.
> > There are specs up for review which outline how we might solve this
> > problem by building what is called TripleO API [1].
> > 
> > Late last year I began experimenting with an OpenStack service
> > called
> > Mistral which contains a generic workflow API. Mistral supports
> > defining workflows in YAML and then creating, managing, and
> > executing
> > them via an OpenStack API. Initially the effort was focused around
> > the
> > idea of creating a workflow in Mistral which could supplant our
> > "baremetal introspection" workflow which currently lives in python-
> > tripleoclient. I create a video presentation which outlines this
> > effort
> > [2]. This particular workflow seemed to fit nicely within the
> > Mistral
> > tooling.
> > 
> > 
> > 
> > More recently I've turned my attention to what it might look like
> > if we
> > were to use Mistral as a replacement for the TripleO API entirely.
> > This
> > brings forth the question of would TripleO be better off building
> > out
> > its own API... or would relying on existing OpenStack APIs be a
> > better
> > solution?
> > 
> > Some things I like about the Mistral solution:
> > 
> > - The API already exists and is generic.
> > 
> > - Mistral already supports interacting with many of the OpenStack
> > API's
> > we require [3]. Integration with keystone is baked in. Adding
> > support
> > for new clients seems straightforward (I've had no issues in adding
> > support for ironic, inspector, and swift actions).
> > 
> > - Mistral actions are pluggable. We could fairly easily wrap some
> > of
> > our more complex workflows (perhaps those that aren't easy to
> > replicate
> > with pure YAML workflows) by creating our own TripleO Mistral
> > actions.
> > This approach would be similar to creating a custom Heat
> > resource...
> > something we have avoided with Heat in TripleO but I think it is
> > perhaps more reasonable with Mistral and would allow us to again
> > build
> > out our YAML workflows to drive things. This might allow us to
> > build
> > off some of the tripleo-common consolidation that is already
> > underway
> > ...
> > 
> > - We could achieve a "stable API" by simply maintaining input
> > parameters for workflows in a stable manner. Or perhaps workflows
> > get
> > versioned like a normal API would be as well.
> > 
> > - The purist part of me likes Mistral quite a bit. It fits nicely
> > with
> > the deploy OpenStack with OpenStack. I sort of feel like if we have
> > to
> > build our own API in TripleO part of this vision has failed and
> > could
> > even be seen as a massive technical debt which would likely be hard
> > to
> > build a community around outside of TripleO.
> > 
> > - Some of the proposed validations could perhaps be implemented as
> > new
> > Mistral actions as well. I'm not convinced we require TripleO API
> > just
> > to support a validations mechanism yet. Perhaps validations seem
> > hard
> > because we are simply trying to do them in the wrong places anyway?
> > (like for example perhaps we should validate network connectivity
> > at
> > inspection time rather than during provisioning).
> > 
> > - Power users might find a workflow built around a Mistral API more
> > easy to interact with and expand upon. Perhaps this ends up being
> > something that gets submitted as a patchset back to the TripleO
> > that we
> > accept into our upstream "stock" workflow sets.
> > 
> > 
> > 
> > Last week we landed the last patches [4] to our undercloud to
> > enable
> > installing Mistral by simply setting: enable_mistral = true in
> > undercloud.conf. NOTE: you'll need to be using a recent trunk repo
> > from
> > Delorean so that you have the recently added Mistral packages for
> > this
> > to work. Although the feature is disable by default this should
> > enable
> > those wishing to tinker with Mistral as a new TripleO undercloud
> > service an easy path forwards.
> > 
> > [1] https://review.openstack.org/#/c/230432
> > [2] https://www.youtube.com/watch?v=bnAT37O-sdw
> > [3] http://git.openstack.org/cgit/openstack/mistral/tree/mistral/ac
> > tion
> > s/openstack/mapping.json
> > [4] https://etherpad.openstack.org/p/tripleo-undercloud-workflow
> > 
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Hi, I have a few questions:
> 
> Is Mistral action able to

Re: [openstack-dev] [release][ironic] ironic-python-agent release 1.1.0 (mitaka)


On 01/12/2016 10:56 AM, Dmitry Tantsur wrote:

Gate is not working right now, as we still use preversioning in
setup.cfg, and we have a version mismatch, e.g.
http://logs.openstack.org/74/264274/1/check/gate-ironic-python-agent-pep8/8d6ef18/console.html.


Patch to remove the version from setup.cfg:
https://review.openstack.org/#/c/266267/
Will backport to liberty as soon as it merges.


Master change has merged, liberty was already fine, so the gate should 
be fine now.




On 01/11/2016 10:01 PM, d...@doughellmann.com wrote:

We are glad to announce the release of:

ironic-python-agent 1.1.0: Ironic Python Agent Ramdisk

This release is part of the mitaka release series.

With package available at:

 https://pypi.python.org/pypi/ironic-python-agent

For more details, please see below.


1.1.0
^


New Features


* The CoreOS image builder now uses the latest CoreOS stable version
   when building images.

* IPA now supports Linux-IO as an alternative to tgtd. The iSCSI
   extension will try to use Linux-IO first, and fall back to tgtd if
   Linux-IO is not found or cannot be used.

* Adds support for setting proxy info for downloading images. This
   is controlled by the *proxies* and *no_proxy* keys in the
   *image_info* dict of the *prepare_image* command.

* Adds support for streaming raw images directly onto the disk. This
   avoids writing the image to a tmpfs partition before writing it to
   disk, which also enables using images larger than the usable amount
   of RAM on the machine IPA runs on. Pass *stream_raw_images=True* to
   the *prepare_image* command to enable this; it is disabled by
   default.

* CoreOS image builder now runs IPA in a chroot, instead of a
   container. systemd-nspawn has been adding more security features
   that break several things IPA needs to do (after all, IPA
   manipulates hardware), such as using sysrq triggers or writing to
   /sys.

* Root device hints now also inspect ID_WWN_WITH_EXTENSION and
   ID_WWN_VENDOR_EXTENSION from udev.


Upgrade Notes
*

* Now that IPA runs in a chroot, any operator tooling built around
   the container may need to change (for example, methods of getting a
   shell inside the container).


Bug Fixes
*

* Raw images larger than available of RAM may now be used by passing
   *stream_raw_images=True* to the *prepare_image* command; these will
   be streamed directly to disk.

* Fixes an issue using the "logs" inspection collector when logs
   contain non-ascii characters.

* Makes tgtd ready status detection more robust.

* Fixes configdrive creation for MBR disks greater than 2TB.


Other Notes
***

* System random is now used where applicable, rather than the
   default python random library.


Changes in ironic-python-agent 1.0.0..1.1.0
---

43a149d Updated from global requirements
dcdb06d Replace deprecated LOG.warn with LOG.warning
4b561f1 Updated from global requirements
943d2c0 Revert "Use latest CoreOS stable when building"
a39dfbd Updated from global requirements
ffcdcd4 Add mitaka reno page
cfcef97 Replace assertEqual(None, *) with assertIsNone in tests
b9df861 Catch up release notes for Mitaka
e8488c2 Add reno for release notes management
d185927 Fix trivial typo in docs
5bac998 Updated from global requirements
4cd64e2 Delete the Linux-IO target before setting up local boot
056bb42 CoreOS: Ensure /run is mounted before starting
6dc7f34 Deprecated tox -downloadcache option removed
a253e50 Use latest CoreOS stable when building
84fc428 Updated from global requirements
b5b0b63 Run IPA in chroot instead of container in CoreOS
5fa258b Fix "logs" inspection collector when logs contain non-ascii
symbols
2fc6ce2 pyudev exception has changed for from_device_file
c474a5a Support Linux-IO in addition to tgtd
f4ad4d7 Updated from global requirements
863b47b Updated from global requirements
e320bb8 Add support for streaming raw images directly onto the disk
65053b7 Refactor the image download and checksum computation bits
c21409e Follow up patch for da9c3b0adc67efa916fc534d975823c0a45948a1
a01c4c9 Create partition at max msdos limit for disks > 2TB
54c901e Support proxies for image download
d97dbf2 Updated from global requirements
da9c3b0 Extend root device hints for different types of WWN
505b345 Fix to preserve double dashes of command line option in HTML.
59630d4 Updated from global requirements
9e75ba5 Use oslo.log instead of original logging
037e391 Updated from global requirements
18d5d6a Replace deprecated LOG.warn with LOG.warning
e51ccbe avoid duplicate text in ISCSIError message
fb920f4 determine tgtd ready status through tgtadm
f042be5 Updated from global requirements
1aeef4d Updated from global requirements
f01 Add param docstring into the normalize func
06d34ae Make calling arguments easier to understand
6131b2e Ensure all methods in utils.py have docstrings
7823240 Updated from global requirements
af20875 Update gitignore
5f7bc48

[openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Amrith Kumar

I've tagged this message with the projects impacted by a series of change sets:

[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how to 
proceed with this change, and changes like this.

The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something ...

In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to 
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.

For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable. 

Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Sergey Lukjanov

Hi,

IMO if you want to do the stylistic changes - make the hacking rule for it
first. Not all of this particular changes are useful and even correct. The
explicit comparison with zero in Python where we have number of implicit
casts to bool is much better in such cases.

Thanks.

On Tue, Jan 12, 2016 at 5:02 PM, Chris Dent  wrote:

> On Tue, 12 Jan 2016, Amrith Kumar wrote:
>
> if var > 0:
>> ... something ...
>>
>> To
>>
>> if var:
>> ... something ...
>>
>
> I may be missing something but the above is not a stylistic change
> if var can ever be negative. In one of the ceilometer changes[1] for
> example, this change will change the flow of the code. In this
> particular example if some caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope
> of the damage is limited, but I prefer the more explicit > 0.
>
> I've not checked all the reviews but if it is showing up in one
> place seems like it could in others.
>
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py
>
> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Amrith Kumar

Chris, Ihar,

I assumed that this was stylistic based on the fact that in the places where I 
was seeing it, it seemed to be the case that the LHS was intuitively positive 
(a length, for example). I did not exhaustively verify this but yes, you are 
correct, the construct 

If var 

is the same as  (I believe)

if var is not None

and therefore the change does change the semantic of the code. Modulo my 
assumption though, it would be strictly stylistic which is why I phrased it as 
such.

Thanks for the quick responses, so far it sounds like the tally is:

Not-Worthwhile: 3
Changes semantics: 1
Others: 0

I created a quick poll to tally results

https://www.surveymonkey.com/r/DLRN9TP

Thanks,

-amrith




> -Original Message-
> From: Chris Dent [mailto:cdent...@anticdent.org]
> Sent: Tuesday, January 12, 2016 9:03 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev]
> [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance
> ][neutron-lbaas][imm] stylistic changes to code, how do we handle them?
> 
> On Tue, 12 Jan 2016, Amrith Kumar wrote:
> 
> > if var > 0:
> > ... something ...
> >
> > To
> >
> > if var:
> > ... something ...
> 
> I may be missing something but the above is not a stylistic change if var can
> ever be negative. In one of the ceilometer changes[1] for example, this
> change will change the flow of the code. In this particular example if some
> caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope of the
> damage is limited, but I prefer the more explicit > 0.
> 
> I've not checked all the reviews but if it is showing up in one place seems 
> like
> it could in others.
> 
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/te
> st_glance.py
> 
> --
> Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
> freenode: cdent tw: @anticdent
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread David Stanek

On Tue, Jan 12, 2016 at 9:13 AM, Amrith Kumar  wrote:

> Chris, Ihar,
>
> I assumed that this was stylistic based on the fact that in the places
> where I was seeing it, it seemed to be the case that the LHS was
> intuitively positive (a length, for example). I did not exhaustively verify
> this but yes, you are correct, the construct
>
> If var
>
> is the same as  (I believe)
>
> if var is not None

Those two statements are also not the same. 'if var' will be True is 'var'
is *only* True values. 'if var is not None' will be True *everything*
except None, so 0, '', [], etc. will not pass the first test, but will pass
the second.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][bugs] help needed: volunteers for bug skimming (1 week)

2016-01-12 Thread Markus Zoeller

Fahri Cihan Demirci  wrote on 01/12/2016 09:58:10 AM:

> From: Fahri Cihan Demirci 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 01/12/2016 10:01 AM
> Subject: Re: [openstack-dev] [nova][bugs] help needed: volunteers for 
> bug skimming (1 week)
> 
> On Mon, Jan 11, 2016 at 11:21:29AM +0100, Markus Zoeller wrote:
> > Augustina Ragwitz  wrote on 01/08/2016 07:50:23 
PM:
> > 
> > > From: Augustina Ragwitz 
> > > To: "OpenStack Development Mailing List (not for usage questions)" 
> > > 
> > > Date: 01/08/2016 08:00 PM
> > > Subject: Re: [openstack-dev] [nova][bugs] help needed: volunteers 
for 
> > > bug skimming (1 week)
> > > 
> > > I signed up for the week before the Nova Midcycle meeting. Even 
though 
> > > I'm still new, I feel capable of at least getting the tags mostly 
right. 
> > 
> > > When I'm not quite sure which tag it would fall under, I search for 
> > > similar bugs and see how they were tagged.
> > 
> > Thanks for signing up! 
> > That's a valid approach.
> > 
> > > I did have one clarifying question, what exactly are the 
expectations of 
> > 
> > > the bug skimming duty? I assumed it was just tagging bugs to get 
them 
> > > into the appropriate queues for triaging. Do we also need to confirm 
the 
> > 
> > > bugs once they've been tagged or does that fall under "triage" and 
not 
> > > "skimming"?
> > > 
> > > Thanks!
> > > Augustina
> > 
> > In short, do as much as possible before the expertise of the subteams
> > is needed. Also, if you spot potential critical bugs, shout out in the 

> > #openstack-nova channel (for me or one of the core reviewers [1]).
> > 
> > As a longer clarification, the duty includes:
> > * Switch the bug to "incomplete" when crucial information is missing
> >   and ask the reporter to provide more information. This includes:
> > * steps to reproduce
> > * the version of Nova and the novaclient (or os-client)
> > * logs (on debug level)
> > * environment details depending on the bug
> > * libvirt/kvm versions, VMWare version, ...
> > * storage type (ceph, LVM, GPFS, ...) 
> > * network type (nova-network or neutron)
> >   I subscribe myself to bugs when I switch them to "incomplete" to see
> >   when responses come in. See "You are not directly subscribed to this 

> >   bug's notifications." on the right hand side of a Launchpad bug 
report.
> > * Close as "invalid" if it is a support request or feature request.
> > * Switch to "confirm" if you could reproduce the described issue. This
> >   is not always possible for you because of missing resources like a 
> >   ceph storage or something like that. 
> > * Add a tag (or more tags) if the report allows you to narrow down the
> >   area which potentially contains the issue. This should be the entry
> >   point for subteams to dig deeper to find the root cause and 
potential
> >   solutions.
> > * Bring critical bugs to the attention of the other contributors. The
> >   #openstack-nova channel and/or a ML post is useful.
> > 
> > I usually explained in a comment *why* I changed a status and which
> > next steps I expect from whom. For example, if I switch to 
"incomplete",
> > tell the reporter to add this and that piece of information and to 
switch
> > the bug back to "new" when the reporter has done this. Another 
example, 
> > if it was a feature request, I switched to "invalid" and added the 
links
> > to the blueprint process.
> > 
> > I used the term "skimming" because each day there are new bugs where
> > nobody took a look at. They "float" on top of all the other bug 
reports 
> > which should have been looked at before. 
> > 
> > I see the whole process in 3 levels:
> > * level 1: bug skimming duty => keep the input sane, prepares the
> >report for level 2
> > * level 2: subteam digs deeper, finds the issue, proposes solution 
> >ideas for level 3
> > * level 3: contributor provides a change in gerrit based on level 2
> > 
> > Does this clarify some of the open questions?
> 
> Thank you for these guidelines. Regarding reports which may be 
> considered as feature requests; there are some reports which were in 
> that vein and were marked with 'Wishlist' importance. Therefore I 
> assumed that classifying feature requests as wishlist items was a 
> valid approach. Was that wrong? Should marking those types of reports 
> as 'Invalid' be the way to go? Thank you.

Nova is too complex to specify a new feature in a few sentences in
a bug report. I tend to close those as "invalid" with links to the
blueprint process. The (WIP) proposal [1]  I have pushed today also
wants to omit the usage of the "wishlist" prio but there is not yet
concensus about it.

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

Regards, Markus Zoeller (markus_z)

> Best regards,
> 
> Fahri

[openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

2016-01-12 Thread Evgeniy L

Hi,

For the last several weeks I've been working on algorithm (and prototype)
for dynamic allocation of volumes on disks.

I have some results [0] and would like to ask you to review it and provide
some feedback.

Our plan is to implement it as an external driver for Bareon [1].

Thanks,

[0] http://bareon-allocator.readthedocs.org/en/latest/architecture.html
[1] https://wiki.openstack.org/wiki/Bareon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][stable][keystone] keystoneauth release 1.1.1 (liberty)

2016-01-12 Thread doug

We are chuffed to announce the release of:

keystoneauth 1.1.1: Authentication Library for OpenStack Identity

This release is part of the liberty stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.


Changes in keystoneauth1 1.1.0..1.1.1
-

0d9fcb0 Updated from global requirements
8f21658 Fix stable/liberty branch
9959f63 Updated from global requirements
359a50c Updated from global requirements
e0ade9a Update .gitreview for stable/liberty

Diffstat (except docs and test files)
-

.gitreview|   1 +
keystoneauth1/access/access.py|  35 +++-
keystoneauth1/fixture/v2.py   |   3 +
keystoneauth1/fixture/v3.py   |   3 +
keystoneauth1/loading/opts.py |   2 +-
requirements.txt  |   2 +-
test-requirements.txt |   2 +-
11 files changed, 487 insertions(+), 8 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index f1e4df1..8af648e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ iso8601>=0.1.9
-requests>=2.5.2
+requests!=2.8.0,!=2.9.0,>=2.5.2
diff --git a/test-requirements.txt b/test-requirements.txt
index dc735af..a82c098 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -21 +21 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2
-tempest-lib>=0.6.1
+tempest-lib>=0.8.0



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Status of python-kollaclient

2016-01-12 Thread Steven Dake (stdake)

Ok folks, this is a bit of bad news, but I'll come out with it.

Because of the addition of Mesos at the Mitaka design summit, the main 
engineers working on the CLI decided they want to wait to provide a unified 
experience with Mesos and Ansible.  Nobody is beating us up for a CLI or ReST 
API, although I think these things would be useful and necessary additions.

The short of it is, it looks as if the CLI work for the short term will be 
abandoned because the current cli codebase as is will have to be rewritten 
a-fresh.  I will make a change to the governance repository to remove it from 
our list of deliverables.  My apologies for the false start, but as with 
everything OpenStack, big changes happen at Summit, and the introduction of 
Mesos as an alternative orchestration engine (although not the one we lead 
with, which is Ansible), was one of our big decision points.

In the future, if we do make a CLI, hopefully in the N cycle, I would highly 
prefer it be done from the start completely upstream rather then a code drop so 
the entire community is engaged in the process.

If there are any thoughts or concerns from the CR team or other community 
members in general, fire away.

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Stefano Maffulli

On 01/12/2016 06:13 AM, Amrith Kumar wrote:
[...]
> I did not exhaustively verify this but 
[...]

A fair question to ask then is, why are you proposing these patches?

> I created a quick poll to tally results

oh no, not another survey! :) Sometimes I feel that survey-itis[1] is a
consequence of the chronic meeting-itis[2] that OpenStack suffers from.

/stef

[1] a disease of online communities whose leaders are afraid to take
actions and revert to online polls before making any decision. It's
caused by the same pathogens that forces governments to appeal to the
interests and conceptions (such as hopes and fears) of the general
population (see populism).
[2] another disease

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][bugs] help needed: volunteers for bug skimming (1 week)

2016-01-12 Thread Fahri Cihan Demirci

On Tue, Jan 12, 2016 at 06:39:22PM +0100, Markus Zoeller wrote:
> Fahri Cihan Demirci  wrote on 01/12/2016 09:58:10 AM:
> 
> > From: Fahri Cihan Demirci 
> > To: "OpenStack Development Mailing List (not for usage questions)" 
> > 
> > Date: 01/12/2016 10:01 AM
> > Subject: Re: [openstack-dev] [nova][bugs] help needed: volunteers for 
> > bug skimming (1 week)
> > 
> > On Mon, Jan 11, 2016 at 11:21:29AM +0100, Markus Zoeller wrote:
> > > Augustina Ragwitz  wrote on 01/08/2016 07:50:23 
> PM:
> > > 
> > > [... snipped for easier viewing ...]
> > > 
> > > Does this clarify some of the open questions?
> > 
> > Thank you for these guidelines. Regarding reports which may be 
> > considered as feature requests; there are some reports which were in 
> > that vein and were marked with 'Wishlist' importance. Therefore I 
> > assumed that classifying feature requests as wishlist items was a 
> > valid approach. Was that wrong? Should marking those types of reports 
> > as 'Invalid' be the way to go? Thank you.
> 
> Nova is too complex to specify a new feature in a few sentences in
> a bug report. I tend to close those as "invalid" with links to the
> blueprint process. The (WIP) proposal [1]  I have pushed today also
> wants to omit the usage of the "wishlist" prio but there is not yet
> concensus about it.

Ok, understood, thank you. For what it's worth, the draft already does a good 
job of summarizing the bug skimming proccess for someone not familiar with the 
workflow.

> 
> [1] https://review.openstack.org/#/c/266453/
> 
> Regards, Markus Zoeller (markus_z)
> 
> > Best regards,
> > 
> > Fahri Cihan Demirci
> > 
> > > 
> > > References:
> > > [1] Nova core reviewers list:
> > > https://review.openstack.org/#/admin/groups/25,members
> > > 
> > > Regards, Markus Zoeller (markus_z)
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Amrith Kumar

Stefano, 

I didn't propose the changes. They are largely -1'ed or -2'ed now.

Fair point on the survey!

-amrith

> -Original Message-
> From: Stefano Maffulli [mailto:stef...@openstack.org]
> Sent: Tuesday, January 12, 2016 1:00 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev]
> [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance
> ][neutron-lbaas][imm] stylistic changes to code, how do we handle them?
> 
> On 01/12/2016 06:13 AM, Amrith Kumar wrote:
> [...]
> > I did not exhaustively verify this but
> [...]
> 
> A fair question to ask then is, why are you proposing these patches?
> 
> > I created a quick poll to tally results
> 
> oh no, not another survey! :) Sometimes I feel that survey-itis[1] is a
> consequence of the chronic meeting-itis[2] that OpenStack suffers from.
> 
> /stef
> 
> [1] a disease of online communities whose leaders are afraid to take
> actions and revert to online polls before making any decision. It's
> caused by the same pathogens that forces governments to appeal to the
> interests and conceptions (such as hopes and fears) of the general
> population (see populism).
> [2] another disease
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][stable][keystone] python-keystoneclient release 1.7.3 (liberty)

2016-01-12 Thread doug

We are delighted to announce the release of:

python-keystoneclient 1.7.3: Client Library for OpenStack Identity

This release is part of the liberty stable release series.

With source available at:

https://git.openstack.org/cgit/openstack/python-keystoneclient

With package available at:

https://pypi.python.org/pypi/python-keystoneclient

Please report issues through launchpad:

https://bugs.launchpad.net/python-keystoneclient

For more details, please see below.


Changes in python-keystoneclient 1.7.2..1.7.3
-

4552013 Updated from global requirements
6125040 Remove hardcoded endpoint filter for update password
116195a Updated from global requirements
b54203b Updated from global requirements

Diffstat (except docs and test files)
-

keystoneclient/v3/users.py |  3 +--
requirements.txt   |  4 ++--
3 files changed, 25 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0e58c7e..a637915 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -15 +15 @@ oslo.serialization>=1.4.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils!=2.6.0,>=2.0.0 # Apache-2.0
@@ -17 +17 @@ PrettyTable<0.8,>=0.7
-requests>=2.5.2
+requests!=2.8.0,!=2.9.0,>=2.5.2



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Routing in Horizon

2016-01-12 Thread Matthias Runge

On 12/01/16 03:33, Richard Jones wrote:
> The  tag addition has had to be reverted as it broke other parts
> of the application (notably lazy loaded tabs like Instance Details), sadly.
> 
> Regarding which router to use - I've used the built-in router in the
> past quite successfully. I think I'd want to see a solid reason for
> using a 3rd party one. It could be that nested routes are part of that,
> but I kinda see that as a convenience thing, unless I'm missing
> something core to how routing is planned to be done. Then again we
> really haven't had any discussion about how we see routing work. The one
> patch that's up that uses routing seems perfectly able to do so without
> needing extended capabilities of 3rd party routers.

I believe, there has been something else messing up with routing,
causing pagination to be broken now.

https://launchpad.net/bugs/1532759

Unfortunately, that even hasn't been detected by tests.

Matthias


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

2016-01-12 Thread Maciej Kwiek

Hi!

I need some advice on how to tackle this issue. There is a bug [1]
describing the problem with creating a diagnostic snapshot. The issue is
that /var/log has 100GB available, while /var (where diagnostic snapshot is
being generated - /var/www/nailgun/dump/fuel-snapshot according to [2]) has
10GB available, so dumping the logs can be an issue when logs size exceed
free space in /var.

There are several things we could do, but I am unsure on which course to
take. Should we
a) Allocate more disk space for /var/www (or for whole /var)?
b) Make the snapshot location share the diskspace of /var/log?
c) Something else? What?

Please share your thoughts on this.

Cheers,
Maciej Kwiek

[1] https://bugs.launchpad.net/fuel/+bug/1529182
[2]
https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] new branch stable/2.9 for fuel-devops

2016-01-12 Thread Dennis Dmitriev

+ mos-dev & mos-qa

12.01.2016 13:26, Dennis Dmitriev пишет:
> Hi all!
>
>   Framework QA team is going to merge a lot of changes to the
> fuel-devops repository [0] , to complete support for template-based
> creation of virtual environments [1].
>   Current fuel-devops data object model will be modified to support
> additional data, that will be required for more flexible virtual
> environments or additional fuel-devops drivers like baremetal driver.
>
>   So we would like to make a stable/2.9 branch for current fuel-devops
> code with version 2.9.x, and implement our changes in master branch with
> fuel-devops version 3.0.
>
> This changes should not affect CI because fuel-devops updates on CI use
> tags instead of branches. For further fuel-devops updates/bugfixes we
> will continue to use tags.
>
>
> [0] - https://github.com/openstack/fuel-devops/
> [1] -
> https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst
>

-- 
Regards,
Dennis Dmitriev
QA Engineer,
Mirantis Inc. http://www.mirantis.com
e-mail/jabber: dis.x...@gmail.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Hi,
At the moment private methods are used all over the place. Examples for this 
are the address pairs and the security groups. If you do a grep of the ML2 
plugin you will see these innocent private methods being used.
The end goal would be for us to have these as public methods.
Thanks
Gary




On 1/12/16, 11:52 AM, "Smigiel, Dariusz"  wrote:

>
>
>> Doug Wiegley  wrote:
>> >
>> >
>> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
>> wrote:
>> >>
>> >> Sean M. Collins  wrote:
>> >>
>>  On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
>> > On Fri, 8 Jan 2016, Gary Kotton wrote:
>> >
>> > The commit
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron_commit_5d53dfb8d64186-2D=BQICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9w=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8=
>> >  
>> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that
>> > make use of the method _get_tenant_id_for_create
>> 
>>  Just out of curiosity, is it not standard practice that a plugin
>>  shouldn't use a private method?
>> >>>
>> >>> +1 - hopefully decomposed plugins will audit their code and look for
>> >>> other calls to private methods.
>> >>
>> >> The fact that it broke *aas repos too suggests that we were not
>> >> showing a proper example to those decomposed. I think it can be
>> >> reasonable to restore the method until N, with a deprecation message,
>> >> as Garry suggested in his patch. Especially since there is no actual
>> >> burden to keep the method for another cycle.
>> >
>> > The neutron community has been really lax about enforcing private
>> methods.
>> > And while we should absolutely reverse that trend, likely we should
>> > give some warning. I agree with not going whole hog on that until N.
>> >
>> > I'd suggest putting in a debtcollector reference when putting the method
>> back.
>> 
>> Done. https://review.openstack.org/265315
>
>
>Do we have any consensus about treating private methods? Any general tips 
>about it, or every time should it be left for author decision?
>
>Should we use deprecation warning for all refactored private methods, treating 
>it as "API" and rewriting underneath code?
>
>Thanks, Dariusz (dasm) Smigiel
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] new branch stable/2.9 for fuel-devops

2016-01-12 Thread Dennis Dmitriev

Hi all!

  Framework QA team is going to merge a lot of changes to the
fuel-devops repository [0] , to complete support for template-based
creation of virtual environments [1].
  Current fuel-devops data object model will be modified to support
additional data, that will be required for more flexible virtual
environments or additional fuel-devops drivers like baremetal driver.

  So we would like to make a stable/2.9 branch for current fuel-devops
code with version 2.9.x, and implement our changes in master branch with
fuel-devops version 3.0.

This changes should not affect CI because fuel-devops updates on CI use
tags instead of branches. For further fuel-devops updates/bugfixes we
will continue to use tags.


[0] - https://github.com/openstack/fuel-devops/
[1] -
https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst

-- 
Regards,
Dennis Dmitriev
QA Engineer,
Mirantis Inc. http://www.mirantis.com
e-mail/jabber: dis.x...@gmail.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][libvirt] VIR_MIGRATE_NON_SHARED_INC works more like full copy in block migration ?

2016-01-12 Thread Kashyap Chamarthy

On Sun, Jan 10, 2016 at 06:07:33PM +0800, Luo Gangyi wrote:
> Hi devs,
> 
> 
> Do you test the difference between within and without
> VIR_MIGRATE_NON_SHARED_INC ?
> 
> 
> When I add VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in
> nova, nova block migration behaves more like a full copy of disk.  The
> disk in destination nodes is large(10GB+) and the process of live
> migration is slow.
> 
> 
> However, when I remove  VIR_MIGRATE_NON_SHARED_INC in
> block_migration_flags in nova, nova block migration behaves more like
> a incremental copy of disk.  The disk in destination nodes is
> small(10MB-) and the process of live migration is very fast.
> 
> 
> So I was confused about what VIR_MIGRATE_NON_SHARED_INC really means.

There are two flags that are related, that might be helpful to be clear
about: VIR_MIGRATE_NON_SHARED_DISK and VIR_MIGRATE_NON_SHARED_INC.

Below is an explanation[1] with example, by Eric Blake, from
libvirt-users list.

NB: It is talking in terms of `virsh` commands, where
'--copy-storage-all' means VIR_MIGRATE_NON_SHARED_DISK and
'--copy-storage-inc' means VIR_MIGRATE_NON_SHARED_INC:

"If you use qcow2 backing chains for thin provisioning, as in:

base.qcow2 <- active.qcow2

then --copy-storage-all copies the entire disk over to the
destination (both base.qcow2 and active.qcow2 contents), while
--copy-storage-inc copies only active.qcow2 (and assumes you have
manually copied base.qcow2 in some other means - since it is
read-only, it won't change from the last migration, and there are
some storage arrays where you can very efficiently copy files
around).  Thus, --copy-storage-inc can be MUCH faster if
active.qcow2 represents a small delta in relation to base.qcow2."


[1] https://www.redhat.com/archives/libvirt-users/2015-April/msg00172.html
Semantics of "virsh migrate --copy-storage-all" vs.
--copy-storage-inc



-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] new branch stable/2.9 for fuel-devops

2016-01-12 Thread Timur Nurlygayanov

Good news :)

Thank you!

On Tue, Jan 12, 2016 at 2:28 PM, Dennis Dmitriev 
wrote:

> + mos-dev & mos-qa
>
> 12.01.2016 13:26, Dennis Dmitriev пишет:
> > Hi all!
> >
> >   Framework QA team is going to merge a lot of changes to the
> > fuel-devops repository [0] , to complete support for template-based
> > creation of virtual environments [1].
> >   Current fuel-devops data object model will be modified to support
> > additional data, that will be required for more flexible virtual
> > environments or additional fuel-devops drivers like baremetal driver.
> >
> >   So we would like to make a stable/2.9 branch for current fuel-devops
> > code with version 2.9.x, and implement our changes in master branch with
> > fuel-devops version 3.0.
> >
> > This changes should not affect CI because fuel-devops updates on CI use
> > tags instead of branches. For further fuel-devops updates/bugfixes we
> > will continue to use tags.
> >
> >
> > [0] - https://github.com/openstack/fuel-devops/
> > [1] -
> >
> https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst
> >
>
> --
> Regards,
> Dennis Dmitriev
> QA Engineer,
> Mirantis Inc. http://www.mirantis.com
> e-mail/jabber: dis.x...@gmail.com
>
>


-- 

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

2016-01-12 Thread Jiri Tomasek


On 01/11/2016 04:51 PM, Dan Prince wrote:

Background info:

We've got a problem in TripleO at the moment where many of our
workflows can be driven by the command line only. This causes some
problems for those trying to build a UI around the workflows in that
they have to duplicate deployment logic in potentially multiple places.
There are specs up for review which outline how we might solve this
problem by building what is called TripleO API [1].

Late last year I began experimenting with an OpenStack service called
Mistral which contains a generic workflow API. Mistral supports
defining workflows in YAML and then creating, managing, and executing
them via an OpenStack API. Initially the effort was focused around the
idea of creating a workflow in Mistral which could supplant our
"baremetal introspection" workflow which currently lives in python-
tripleoclient. I create a video presentation which outlines this effort
[2]. This particular workflow seemed to fit nicely within the Mistral
tooling.



More recently I've turned my attention to what it might look like if we
were to use Mistral as a replacement for the TripleO API entirely. This
brings forth the question of would TripleO be better off building out
its own API... or would relying on existing OpenStack APIs be a better
solution?

Some things I like about the Mistral solution:

- The API already exists and is generic.

- Mistral already supports interacting with many of the OpenStack API's
we require [3]. Integration with keystone is baked in. Adding support
for new clients seems straightforward (I've had no issues in adding
support for ironic, inspector, and swift actions).

- Mistral actions are pluggable. We could fairly easily wrap some of
our more complex workflows (perhaps those that aren't easy to replicate
with pure YAML workflows) by creating our own TripleO Mistral actions.
This approach would be similar to creating a custom Heat resource...
something we have avoided with Heat in TripleO but I think it is
perhaps more reasonable with Mistral and would allow us to again build
out our YAML workflows to drive things. This might allow us to build
off some of the tripleo-common consolidation that is already underway
...

- We could achieve a "stable API" by simply maintaining input
parameters for workflows in a stable manner. Or perhaps workflows get
versioned like a normal API would be as well.

- The purist part of me likes Mistral quite a bit. It fits nicely with
the deploy OpenStack with OpenStack. I sort of feel like if we have to
build our own API in TripleO part of this vision has failed and could
even be seen as a massive technical debt which would likely be hard to
build a community around outside of TripleO.

- Some of the proposed validations could perhaps be implemented as new
Mistral actions as well. I'm not convinced we require TripleO API just
to support a validations mechanism yet. Perhaps validations seem hard
because we are simply trying to do them in the wrong places anyway?
(like for example perhaps we should validate network connectivity at
inspection time rather than during provisioning).

- Power users might find a workflow built around a Mistral API more
easy to interact with and expand upon. Perhaps this ends up being
something that gets submitted as a patchset back to the TripleO that we
accept into our upstream "stock" workflow sets.



Last week we landed the last patches [4] to our undercloud to enable
installing Mistral by simply setting: enable_mistral = true in
undercloud.conf. NOTE: you'll need to be using a recent trunk repo from
Delorean so that you have the recently added Mistral packages for this
to work. Although the feature is disable by default this should enable
those wishing to tinker with Mistral as a new TripleO undercloud
service an easy path forwards.

[1] https://review.openstack.org/#/c/230432
[2] https://www.youtube.com/watch?v=bnAT37O-sdw
[3] http://git.openstack.org/cgit/openstack/mistral/tree/mistral/action
s/openstack/mapping.json
[4] https://etherpad.openstack.org/p/tripleo-undercloud-workflow


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hi, I have a few questions:

Is Mistral action able to access/manipulate local files? E.g. access the 
templates installed at undercloud's 
/usr/share/openstack-tripleo-heat-templates?


I Mistral action able to call either OpenStack service python client or 
OpenStack service API directly?


What is the response from the Mistral action in the workflow? Lets say 
we'd use Mistral to get a list of available environments (we do this in 
tripleo-common now) So we call Mistral API to trigger a workflow that 
has single action which gets the list of environments. Is mistral able 
to provide this list as a response, or it

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

2016-01-12 Thread Ihar Hrachyshka

Agreed with Gary on behalf of my European compatriots. (Note that I  
*personally* +1’d the patch because I don’t mind, doing late hours anyway;  
but it’s sad it was ninja merged without giving any chance for those from  
affected timezones to express their concerns).

Ihar

Gary Kotton  wrote:

Hi,
I personally liked that fact that there were two times. It was reasonable  
to make an effort to stay up very late to attend the one and then have  
the privileged of the other being at a reasonable time. Now it is back to  
the crazy hours.

Thanks
Gary

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Tuesday, January 12, 2016 at 1:39 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On 2016/01/12 7:14, Armando M. wrote:
On 11 January 2016 at 13:54, Hirofumi Ichihara  
 wrote:

On 2016/01/12 5:14, Armando M. wrote:

On 11 January 2016 at 12:04, Carl Baldwin  wrote:

What do we do?  My calendar was set up with the sane bi-weekly thing
and it shows the meeting for tomorrow.  The last word from our
fearless leader is that we'll have it today.  So, I'll be there today
unless instructed otherwise.

The ics file now seems to reset the cadence beginning today at 2100
and next Tuesday, the 19th, at 1400.  I guess we should either hold
the meeting today and reset the cadence or fix the ics file.

This is what I would like to do now:

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

I personally haven't seen that much of an attendance difference  
anyway, and at this point, it'll simplify our lives and avoid grief  
going forward.

I like it.

However, we have gathered from all over the world because neutron is  
big project. Should we have the choice so that more people get  
attendance opportunity?

This time, the return to the normal schedule was a disaster, plus every  
time we switch to daylight savings, or every time there's a holiday  
break/summit we have twice the chances to screw up if we keep the  
bi-weekly schedule.

If I go and look at the logs [1] I don't have hard evidence that the  
bi-weekly schedule does indeed help the attendance of friendlier  
timezones, so I wonder...what's the point?
You're right. My reply was just general opinion. I think that most  
regular folks probably attend both days now. I actually do as well.

I was worried that sometimes there are developers who introduce his bug  
or ask core to review although they usually don't attend. However, we  
have openstack-neutron channel for it.

A.

[1] http://eavesdrop.openstack.org/meetings/networking/

Carl

On Mon, Jan 11, 2016 at 12:09 PM, Kevin Benton   
wrote:
> The issue is simply that you have a sane bi-weekly thing setup in  
your
> calendar. What we have for Neutron is apparently defined as “odd  
and even
> weeks when weeks are represented as an short integer counting from  
the first

> of the year”, a.k.a. “bi-weekly” as a robot might define it. :)
>
>
> On Jan 11, 2016, at 11:00 AM, Kyle Mestery   
wrote:

>
> On Mon, Jan 11, 2016 at 12:57 PM, Kyle Mestery  
 wrote:

>>
>> On Mon, Jan 11, 2016 at 12:45 PM, Armando M.   
wrote:

>>>
>>> Disregard the email subject.
>>>
>>> I stand corrected. Let's meet today.
>>>
>>
>> Something is wrong, I have the meeting on my google calendar, and  
it shows
>> up as tomorrow for this week. I've had these setup as rotating for  
a while

>> now, so something is fishy with the .ics files.
>
>
> If you look here [1], the meeting cadence was:
>
> 12-15-2015: Tuesday
> 12-21-2015: Monday
> 12-29-2015: Tuesday (skipped)
> 01-04-2016: Monday (skipped)
> 01-12-2016 Tuesday
>
> The meeting is tomorrow.
>
> [1] http://eavesdrop.openstack.org/meetings/networking/2015/
>>
>>
>>>
>>> On 11 January 2016 at 10:24, Ihar Hrachyshka  
 wrote:

 Armando M.  wrote:

> Hi neutrinos,
>
> A kind reminder for tomorrow's meeting at 1400UTC.
>
> Cheers,
> Armando
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
>
>  
__

> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 Is it just me, or when you use .ics file from eavesdrop, it says  
the

 meeting is today?

 http://eavesdrop.openstack.org/calendars/neutron-team-meeting.ics

 Is it the same issue as described in:

http://lists.openstack.org/pipermail/openstack-dev/2015-December/082902.html

 and that is suggested to fix by readding your events from

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

2016-01-12 Thread Artem Panchenko


Hi,

doesn't matter how /var partition is big, diagnostic snapshot still 
could occupy all its space if there are lots of logs on slave nodes. 
Although, we can try to control disk space usage by snapshot in shotgun, 
but IMHO it's much safer to keep all related to logs staff away from 
critical system files, so I'm voting for 2nd (b) option. By the way it 
will allow us to use hard links for fast copying of files before 
creating tarball, because one partition for storing logs and snapshot 
will be used.


Thanks!

On 12.01.16 12:47, Maciej Kwiek wrote:

Hi!

I need some advice on how to tackle this issue. There is a bug [1] 
describing the problem with creating a diagnostic snapshot. The issue 
is that /var/log has 100GB available, while /var (where diagnostic 
snapshot is being generated - /var/www/nailgun/dump/fuel-snapshot 
according to [2]) has 10GB available, so dumping the logs can be an 
issue when logs size exceed free space in /var.


There are several things we could do, but I am unsure on which course 
to take. Should we

a) Allocate more disk space for /var/www (or for whole /var)?
b) Make the snapshot location share the diskspace of /var/log?
c) Something else? What?

Please share your thoughts on this.

Cheers,
Maciej Kwiek

[1] https://bugs.launchpad.net/fuel/+bug/1529182
[2] 
https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Artem Panchenko
QA Engineer

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Hi,
I have drafted 
https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have up 
as an example (https://review.openstack.org/266304) 
for people to chew on...
Thanks
Gary



On 1/12/16, 1:08 PM, "Smigiel, Dariusz"  wrote:

>> 
>> Hi,
>> At the moment private methods are used all over the place. Examples for
>> this are the address pairs and the security groups. If you do a grep of the 
>> ML2
>> plugin you will see these innocent private methods being used.
>> The end goal would be for us to have these as public methods.
>> Thanks
>> Gary
>> 
>
>OK, get it. But just wanted to know, what is the outcome from email discussion.
>Do we need to match changed/removed private methods with deprecation warning,
>or just modify and tell plugins: "deal with it" :)
>
>BR,
>Dariusz (dasm) Smigiel
>
>> 
>> 
>> 
>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz"  wrote:
>> 
>> >
>> >
>> >> Doug Wiegley  wrote:
>> >> >
>> >> >
>> >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
>> >> wrote:
>> >> >>
>> >> >> Sean M. Collins  wrote:
>> >> >>
>> >>  On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
>> >> > On Fri, 8 Jan 2016, Gary Kotton wrote:
>> >> >
>> >> > The commit
>> >> > https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__github.com
>> >> > _openstack_neutron_commit_5d53dfb8d64186-
>> 2D=BQICAg=Sqcl0Ez6
>> >> > M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
>> uEs=VlZxHpZBmzzkWT5jqz9JYBk8Y
>> >> > Teq9N3-
>> diTlNj4GyNc=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
>> >> > w=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8=
>> >> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
>> >> > that make use of the method _get_tenant_id_for_create
>> >> 
>> >>  Just out of curiosity, is it not standard practice that a plugin
>> >>  shouldn't use a private method?
>> >> >>>
>> >> >>> +1 - hopefully decomposed plugins will audit their code and look
>> >> >>> +for
>> >> >>> other calls to private methods.
>> >> >>
>> >> >> The fact that it broke *aas repos too suggests that we were not
>> >> >> showing a proper example to those decomposed. I think it can be
>> >> >> reasonable to restore the method until N, with a deprecation
>> >> >> message, as Garry suggested in his patch. Especially since there
>> >> >> is no actual burden to keep the method for another cycle.
>> >> >
>> >> > The neutron community has been really lax about enforcing private
>> >> methods.
>> >> > And while we should absolutely reverse that trend, likely we should
>> >> > give some warning. I agree with not going whole hog on that until N.
>> >> >
>> >> > I'd suggest putting in a debtcollector reference when putting the
>> >> > method
>> >> back.
>> >>
>> >> Done. https://review.openstack.org/265315
>> >
>> >
>> >Do we have any consensus about treating private methods? Any general
>> tips about it, or every time should it be left for author decision?
>> >
>> >Should we use deprecation warning for all refactored private methods,
>> treating it as "API" and rewriting underneath code?
>> >
>> >Thanks, Dariusz (dasm) Smigiel
>> >
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

2016-01-12 Thread Ihar Hrachyshka


Clark Boylan  wrote:


On Mon, Jan 11, 2016, at 12:35 PM, Sean M. Collins wrote:

Nice find. I actually pushed a patch recently that we should be
advertising the MTU by default. I think this really shows that it should
be enabled by default.

https://review.openstack.org/263486l

++ Neutron should be able to determine what the outer MTU is and adjust
the advertised inner MTU automatically based on the overhead required
for whatever tunnel protocol is in use all without the deployer or cloud
user needing to know anything special.


Let me clarify: there is still requirement for the image you boot to honour  
one of the ways we advertise MTU from neutron (DHCP MTU opton; RA for IPv6  
networks; …) Neutron cannot change mtu for the device that is seen from  
inside of the instance.


That said, most real images, including cirros since last year, should  
support the DHCP option.


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Removing unused/deprecated template parameters?

2016-01-12 Thread Steven Hardy

Hi all,

I've noticed that we have a fairly large number of unused parameters in
t-h-t, some of which are marked deprecated, some aren't.

Since we moved tripleoclient to use parameter_defaults everywhere, I think
it should be safe to remove these unused parameters, even in
overcloud.yaml.

See:

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

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

Since those, we can pass removed/deprecated parameters from the client and
they will be ignored, even if they're removed from the template (unlike if
you use "parameters", where a validation error would occur.

I'd like to go ahead and clean these up (only on the master branch), is
that reasonable?  We can document the change via a mitaka release note?

Ideally, we'd have user-visible warnings for a deprecation period, but
there's no way to output such warnings atm via heat, so we'd need to wire
them in via tripleoclient or tripleo-common, which seems a bit backwards
given that we can just remove the parameters there instead.

Thoughts?

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

2016-01-12 Thread Clark Boylan

On Tue, Jan 12, 2016, at 04:19 AM, Kwasniewska, Alicja wrote:
> Unfortunately I do not have any experience in working or testing Heka, so
> it’s hard for me to compare its performance vs Logstash performance.
> However I’ve read that Heka possess a lot advantages over Logstash in
> this scope.
> 
> 
> But which version of Logstash did you test? One guy from the Logstash
> community said that: “The next release of logstash (1.2.0 is in beta) has
> a 3.5x improvement in event throughput. For numbers: on my workstation at
> home (6 vcpu on virtualbox, host OS windows, 8 GB ram, host cpu is
> FX-8150) - with logstash 1.1.13, I can process roughly 31,000 events/sec
> parsing apache logs. With logstash 1.2.0.beta1, I can process 102,000
> events/sec.”
In addition to the version of Logstash that is used, the specific grok
rules and file inputs can make a big difference with performance. I
would make sure that your 500 input files are representative of the log
files you will generate running Kolla/OpenStack and that you write grok
rules that would actually be useful. If you need to you can always grab
them from the CI logs.

For the Elasticsearch indexing that we expose at
http://logstash.openstack.org we ended up going with Logstash because
many of the alternate tools (Heka and Fluentd and friends) seemed more
appropriate for moving logs from point A to point B with little to no
modification. With Jenkins build logs we needed to be able to accept
many different log formats (libvirt, oslo, swift, apache, devstack
console logs, and so on) and collapse them into a mostly common event
format. That said if you can get structured logs and keep the number of
formats to a minimum using a tool like Heka or Fluentd makes a lot of
sense.
> 
> 
> You also said that Heka is a unified data processing, but do we need
> this? Heka seems to address stream processing needs, while Logstash
> focuses mainly on processing logs. We want to create a central logging
> service, and Logstash was created especially for it and seems to work
> well for this application.
> 
> 
> One thing that is obvious is the fact that the Logstash is better known,
> more popular and tested. Maybe it has some performance disadvantages, but
> at least we know what we can expect from it. Also, it has more pre-built
> plugins and has a lot examples of usage, while Heka doesn’t have many of
> them yet and is nowhere near the range of plugins and integrations
> provided by Logstash.
Not only that but the OpenStack Infra team and others have written rules
for handling OpenStack logs. In theory you can just drop them into place
and it will all work.
> 
> 
> In the case of adding plugins, I’ve read that in order to add Go plugins,
> the binary has to be recompiled, what is a little bit frustrating (static
> linking - to wire in new plugins, have to recompile). On the other hand,
> the Lua plugins do not require it, but the question is whether Lua
> plugins are sufficient? Or maybe adding Go plugins is not so bad?
> 
> 
> You also said that you didn’t test the Heka with Docker, right? But do
> you have any experience in setting up Heka in Docker container? I saw
> that with Heka 0.8.0 new Docker features were implemented (included
> Dockerfiles to generate Heka Docker containers for both development and
> deployment), but did you test it? If you didn’t, we could not be sure
> whether there are any issues with it.
> 
> 
> Moreover you will have to write your own Dockerfile for Heka that
> inherits from Kolla base image (as we discussed during last meeting, we
> would like to have our own images), you won’t be able to inherit from
> ianneub/heka:0.10 as specified in the link that you sent
> http://www.ianneubert.com/wp/2015/03/03/how-to-use-heka-docker-and-tutum/.
> 
> 
> There are also some issues with DockerInput Module which you want to use.
> For example splitters are not available in DockerInput
> (https://github.com/mozilla-services/heka/issues/1643). I can’t say that
> it will affect us, but we also don’t know which new issues may arise
> during first tests, as any of us has ever tried Heka in and with Dockers.
> 
> 
> I am not stick to any specific solution, however just not sure whether
> Heka won’t surprise us with something hard to solve, configure, etc.
> 
> 
> Alicja Kwaśniewska
> 

Happy to answer any other questions about how the Infra team runs
Logstash (we don't centralize it for example).

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

2016-01-12 Thread Tzu-Mainn Chen

> On 01/11/2016 11:09 PM, Tzu-Mainn Chen wrote:
> > - Original Message -
> >> Background info:
> >>
> >> We've got a problem in TripleO at the moment where many of our
> >> workflows can be driven by the command line only. This causes some
> >> problems for those trying to build a UI around the workflows in that
> >> they have to duplicate deployment logic in potentially multiple places.
> >> There are specs up for review which outline how we might solve this
> >> problem by building what is called TripleO API [1].
> >>
> >> Late last year I began experimenting with an OpenStack service called
> >> Mistral which contains a generic workflow API. Mistral supports
> >> defining workflows in YAML and then creating, managing, and executing
> >> them via an OpenStack API. Initially the effort was focused around the
> >> idea of creating a workflow in Mistral which could supplant our
> >> "baremetal introspection" workflow which currently lives in python-
> >> tripleoclient. I create a video presentation which outlines this effort
> >> [2]. This particular workflow seemed to fit nicely within the Mistral
> >> tooling.
> >>
> >> 
> >>
> >> More recently I've turned my attention to what it might look like if we
> >> were to use Mistral as a replacement for the TripleO API entirely. This
> >> brings forth the question of would TripleO be better off building out
> >> its own API... or would relying on existing OpenStack APIs be a better
> >> solution?
> >>
> >> Some things I like about the Mistral solution:
> >>
> >> - The API already exists and is generic.
> >>
> >> - Mistral already supports interacting with many of the OpenStack API's
> >> we require [3]. Integration with keystone is baked in. Adding support
> >> for new clients seems straightforward (I've had no issues in adding
> >> support for ironic, inspector, and swift actions).
> >>
> >> - Mistral actions are pluggable. We could fairly easily wrap some of
> >> our more complex workflows (perhaps those that aren't easy to replicate
> >> with pure YAML workflows) by creating our own TripleO Mistral actions.
> >> This approach would be similar to creating a custom Heat resource...
> >> something we have avoided with Heat in TripleO but I think it is
> >> perhaps more reasonable with Mistral and would allow us to again build
> >> out our YAML workflows to drive things. This might allow us to build
> >> off some of the tripleo-common consolidation that is already underway
> >> ...
> >>
> >> - We could achieve a "stable API" by simply maintaining input
> >> parameters for workflows in a stable manner. Or perhaps workflows get
> >> versioned like a normal API would be as well.
> >>
> >> - The purist part of me likes Mistral quite a bit. It fits nicely with
> >> the deploy OpenStack with OpenStack. I sort of feel like if we have to
> >> build our own API in TripleO part of this vision has failed and could
> >> even be seen as a massive technical debt which would likely be hard to
> >> build a community around outside of TripleO.
> >>
> >> - Some of the proposed validations could perhaps be implemented as new
> >> Mistral actions as well. I'm not convinced we require TripleO API just
> >> to support a validations mechanism yet. Perhaps validations seem hard
> >> because we are simply trying to do them in the wrong places anyway?
> >> (like for example perhaps we should validate network connectivity at
> >> inspection time rather than during provisioning).
> >>
> >> - Power users might find a workflow built around a Mistral API more
> >> easy to interact with and expand upon. Perhaps this ends up being
> >> something that gets submitted as a patchset back to the TripleO that we
> >> accept into our upstream "stock" workflow sets.
> >>
> >
> > Hiya!  Thanks for putting down your thoughts.
> >
> > I think I fundamentally disagree with the idea of using Mistral, simply
> > because many of the actions we'd like to expose through a REST API
> > (described in the tripleo-common deployment library spec [1]) aren't
> > workflows; they're straightforward get/set methods.
> 
> Right, because this spec describes nearly nothing from what is present
> in tripleoclient now. And what we realistically have now is workflows,
> which we'll have to reimplement in API somehow. So maybe we need both:
> the get/set TripleO API for deployment plans and Mistral for workflows.
> 

This would make sense to me.  I have no objections to using Mistral for the
bits where we have actual workflows, only for the get/set-type methods
proposed in the spec.  Using it for a latter seems like a major stretch,
as I argued in my previous email.

Mainn

>
>  > Putting a workflow
> > engine in front of that feels like overkill and an added complication
> > that simply isn't needed.  And added complications can lead to unneeded
> > complications: for instance, one open Mistral bug details how it may
> > not scale well [2].
> 
> Let's not talk about scaling in the context of what we have in
>

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Flavio Percoco


On 12/01/16 15:01 +0100, Ihar Hrachyshka wrote:

Amrith Kumar  wrote:

I've tagged this message with the projects impacted by a series of 
change sets:


[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out 
how to proceed with this change, and changes like this.


The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something …


The change is not stylistic. F.e. before the change, var == -1 would 
not result in triggering the conditional body; while in the new 
version, it does trigger it. Unless the assumption that var is >= 0 is 
always true, it’s just a wrong change. F.e. I suspect in *, you 
effectively make error code returned by fork() (-1) to be considered 
as successful value.


* https://review.openstack.org/#/c/266156/1/neutron/agent/linux/daemon.py

I also don’t see any value in such a change.



In addition to the above, I believe `if var > 0` is faster than `if var` just
like `if x is None` is (normally?) faster than `if not x`.



In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind 
be handled in a consistent way across all projects, maybe with a 
hacking rule and some discussion on the ML first? After all, if this 
change is worthwhile, it is worth ensuring that this construct that 
we are seeking to eliminate, does not reenter the code base.




If a stylistic change is worth it and can be automated, yes, it’s 
better to have a hacking rule for that. Though I doubt that’s the case 
here.


For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before 
the change was more intuitive and readable.


Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

2016-01-12 Thread Flavio Percoco


On 08/01/16 08:36 -0430, Flavio Percoco wrote:

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?

[0] https://review.openstack.org/#/c/234340/


FWIW, we've decided to give jazzband[0] a try and host prettytable there. If
that doesn't work out well, we might revisit this option (unless the tabulate
migration happens before that).

[0] https://jazzband.co

Thanks everyone and Doug for suggesting jazzband!
Flavio



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron][os-vif] os-vif core review team membership

2016-01-12 Thread Daniel P. Berrange

So far myself & Jay Pipes have been working on the initial os-vif
prototype and setting up infrastructure for the project. Obviously
we need more then just 2 people on a core team, and after looking
at those who've expressed interest in os-vif, we came up with a
cross-section of contributors across the Nova, Neutron and NFV
spaces to be the initial core team:

  Jay Pipes
  Daniel Berrange
  Sean Mooney
  Moshe Levi
  Russell Bryant
  Sahid Ferdjaoui
  Maxime Leroy

So unless anyone wishes to decline the offer, once infra actually add
me to the os-vif-core team I'll be making these people os-vif core, so
we can move forward with the work on the library...

Regards,
Daniel
-- 
|: 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

2016-01-12 Thread Ryan Brown


On 01/12/2016 08:24 AM, Dan Prince wrote:

On Tue, 2016-01-12 at 12:52 +0100, Jiri Tomasek wrote:

On 01/11/2016 04:51 PM, Dan Prince wrote:

Background info:
[snip]




In similar manner, is Mistral able to provide a way to get workflow
in
progress data? E.g. We have a Mistral workflow for nodes
introspection.
This workflow contains several actions calling to ironic and
ironic-inspector apis. GUI calls Mistral API to trigger the workflow
and
now it needs to have a way to track the progress of that workflow.
How
would this be achieved?


I've been running 'mistral execution-list' and then you can watch
(poll) for the relevant execution items to finish running. Sure,
polling isn't great but I'd say lets start with this perhaps.


I think forcing GUI to poll the APIs that are
called in the actions and try to implement logic that estimates what
state the workflow is to report about it is not a valid solution. We
need the workflow API (Mistral) to provide a lets say web sockets
connection and push the status of actions along with relevant data,
so
GUI can listen to those.


I don't think Mistral has a websockets implementation. I think Zaqar
does though, and I think perhaps one way we could go about this sort of
notification might be to integrate our workflows with a Zaqar queue or
something. GUI would listen to a Zaqar queue for example... and the
workflow (as it executes) would post things to a specific queue.
Perhaps this is opt-in, only if a Zaqar queue is provided to a given
workflow. FWIW, integrating Mistral w/ Zaqar actions would likely be
quite easy.


Heat currently has a similar system for stack actions. The user provides 
a zaqar queue in the environment file, and every resource action 
generates a notification on that queue. I think a similar system would 
work for Mistral jobs.


For "domain-specific" notifications like receiving a notification for 
certain discovery stages, the TripleO custom actions could also publish 
messages to a queue so users get something more granular than "this 
Mistral job finished."



Alternately we could look at what it would take to add websocket
support to Mistral directly.


I really don't think adding websockets to Mistral would be worth it - 
Zaqar is a much better solution for notifications since it already has 
websocket, webhook, and even email (yes, that's right) notification options.




I am about to implement your nodes workflow in the GUI to test how it
works.

Jirka


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Spam of patches (was: [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?)

2016-01-12 Thread Julien Danjou

On Tue, Jan 12 2016, Amrith Kumar wrote:

> My question to the ML is this, should stylistic changes of this kind be 
> handled
> in a consistent way across all projects, maybe with a hacking rule and some
> discussion on the ML first? After all, if this change is worthwhile, it is
> worth ensuring that this construct that we are seeking to eliminate, does not
> reenter the code base.

This is not stylistic, these are actual changes that can break the code
for no good reason. I've already -2'ed the Ceilometer one.

Honestly, this kind of change are getting more and more a problem to us.
People invent a false bug, maybe report it to LP and mass-assign
projects, and then spam all the projects without any discussion before.
The worse thing is that most of these patches are wrong or incorrect,
add code-churn that just pollutes project history for no benefit.

At the beginning, I had hope, and was being patient and tried to mentor
these new people with the hope that they'll learn and stick around. None
stayed. Is it just a "get me an free ATC pass" behavior, like someone
suggested?

Now the spam amount is getting so high (several of these patches per
week these days) that I can't afford to be so patient and gentle
anymore, and I just -2 the patch with a brief explanation. I also have
to use the "mute bug mail" feature of Launchpad a lot, since I get
spammed by all the changes done the mass-assigned Launchpad bugs.

So, how what can we do to fix that? It seems we're not communicating
proper behavior on how to jump into OpenStack to contribute and that
those "contributors" are not used to FOSS communities.

Cheers,
-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread michael mccune


On 01/12/2016 08:51 AM, Amrith Kumar wrote:

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.


in general, i would prefer to leave these stylistic choices up to 
individual projects. the specific change that is being proposed may make 
sense for some projects but not for others.


i like the idea of a "hacking rule" or some sort of coding style guides, 
but i'm sceptical about creating some sort of openstack coding guide. 
i'm happy with us continuing to use pep8 and the individual projects' 
guidance as the bar.



For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable.


+1

regards,
mike

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

2016-01-12 Thread McPeak, Travis

One issue to be aware of is the use of this as a Denial of Service
vector.  Basically an attacker can use this to lock out key accounts
by continuously sending invalid passwords.

Doing this might have unexpected and undesirable results,
particularly in automated tasks.

I think this feature has some definite uses, but we should definitely
think through use and abuse cases, and probably allow a list of
accounts that this should not be active for.


-Travis

On 1/12/16, 3:11 AM, "openstack-dev-requ...@lists.openstack.org" 
 wrote:

>I have registered a new bp for keystone with the capability of anti brute force
>
>
>Problem Description:
>the attacks of account are increasing in the cloud
>the attacker steals the account information by guessing the password in brute 
>force.
>therefore, the ability of account in anti brute force is necessary.
>
>proposed Change:
>1. add two configure properties for keystone: threshold for times of password 
>error consecutively, time of locked when password error number reaches the 
>threshold.
>2. add two properties of user information in times of password consecutive 
>errors, and last password error time. when the password of an account error 
>consecutively reaches threshold, the account will be locked with a few time.
>3. locked account will unlock automatically when locked status time out
>4. the APIs of keystone which use user_name and password for authentication, 
>the message of response will add an error description when the account is 
>locked

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Spam of patches

2016-01-12 Thread Eric Harney

On 01/12/2016 09:32 AM, Julien Danjou wrote:
> On Tue, Jan 12 2016, Amrith Kumar wrote:
> 
>> My question to the ML is this, should stylistic changes of this kind be 
>> handled
>> in a consistent way across all projects, maybe with a hacking rule and some
>> discussion on the ML first? After all, if this change is worthwhile, it is
>> worth ensuring that this construct that we are seeking to eliminate, does not
>> reenter the code base.
> 
> This is not stylistic, these are actual changes that can break the code
> for no good reason. I've already -2'ed the Ceilometer one.
> 
> Honestly, this kind of change are getting more and more a problem to us.
> People invent a false bug, maybe report it to LP and mass-assign
> projects, and then spam all the projects without any discussion before.
> The worse thing is that most of these patches are wrong or incorrect,
> add code-churn that just pollutes project history for no benefit.
> 

For anyone interested here, this is the most recent example of this that
I've seen (and not the first time this same faulty change has been
discussed in Cinder):

https://bugs.launchpad.net/cinder/+bug/1512207

The change suggested here makes unit tests weaker, but many projects
have already landed this change.

I'd just like to be another voice to say: these changes are often not as
simple as they look, and really need careful review.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Spam of patches

2016-01-12 Thread Anita Kuno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/12/2016 09:32 AM, Julien Danjou wrote:
> On Tue, Jan 12 2016, Amrith Kumar wrote:
> 
>> My question to the ML is this, should stylistic changes of this
>> kind be handled in a consistent way across all projects, maybe
>> with a hacking rule and some discussion on the ML first? After
>> all, if this change is worthwhile, it is worth ensuring that this
>> construct that we are seeking to eliminate, does not reenter the
>> code base.
> 
> This is not stylistic, these are actual changes that can break the
> code for no good reason. I've already -2'ed the Ceilometer one.
> 
> Honestly, this kind of change are getting more and more a problem
> to us. People invent a false bug, maybe report it to LP and
> mass-assign projects, and then spam all the projects without any
> discussion before. The worse thing is that most of these patches
> are wrong or incorrect, add code-churn that just pollutes project
> history for no benefit.
> 
> At the beginning, I had hope, and was being patient and tried to
> mentor these new people with the hope that they'll learn and stick
> around. None stayed. Is it just a "get me an free ATC pass"
> behavior, like someone suggested?
> 
> Now the spam amount is getting so high (several of these patches
> per week these days) that I can't afford to be so patient and
> gentle anymore, and I just -2 the patch with a brief explanation. I
> also have to use the "mute bug mail" feature of Launchpad a lot,
> since I get spammed by all the changes done the mass-assigned
> Launchpad bugs.
> 
> So, how what can we do to fix that? It seems we're not
> communicating proper behavior on how to jump into OpenStack to
> contribute and that those "contributors" are not used to FOSS
> communities.

I think Julien raises a very important point here. This kind of
contribution and the way it is communicated is sub optimal for the
effective operation of our developer's workflow.

I too have tried to mentor many new folks hoping they would learn open
source workflows and even though some of them understood and
implemented (one or two even payed it forward) most of them have moved o
n.

This kind of behaviour puts a lot of load on developers and each
person addresses it in their own way. One of the things I see is a
fragmentation of what I had believed to be camaraderie as everyone is
forced to come up with their own individual solution to deal with this
demand.

I don't have a solution but I agree with Julien that it is a problem.

Thanks Julien,
Anita.

> 
> Cheers,
> 
> 
> 
> __

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWlRSwAAoJELmKyZugNFU02QQIAK/kojQBGbfqtoqMTdlmhg+b
ah/Sz5761Z8xL6p7DSsJPPJQN3WpwxkJt06pzGog1QfGNDb5nRGLeqBk2YxkEqFm
eqH5vraDDqzkijo3kg1kLd4e8N3BkfxWNzGnlnbppp8o6T2bh7qWuXzlkDiTF9Zh
iL+6jvBmmoFkc5nXEeACLcEsQ7gw4Sz/pEv+1Y9UX6XJGlsy75eRMwLxGNU7T5Cp
2fMIzOH2+mpMApmjyZYU65BNqj/WralweUrBhMkMBIss8381kH1AtqvzSei32Lvb
lOX6Rh6Wq7cD5+aacg4HbxbXcMnudAK47N7ZBoDtF7au+UBzI8oC+RKpNiXE2OI=
=Mdxr
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron][os-vif] os-vif core review team membership

2016-01-12 Thread Russell Bryant

On 01/12/2016 10:15 AM, Daniel P. Berrange wrote:
> So far myself & Jay Pipes have been working on the initial os-vif
> prototype and setting up infrastructure for the project. Obviously
> we need more then just 2 people on a core team, and after looking
> at those who've expressed interest in os-vif, we came up with a
> cross-section of contributors across the Nova, Neutron and NFV
> spaces to be the initial core team:
> 
>   Jay Pipes
>   Daniel Berrange
>   Sean Mooney
>   Moshe Levi
>   Russell Bryant
>   Sahid Ferdjaoui
>   Maxime Leroy
> 
> So unless anyone wishes to decline the offer, once infra actually add
> me to the os-vif-core team I'll be making these people os-vif core, so
> we can move forward with the work on the library...

Thanks, I'm happy to help.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

2016-01-12 Thread Doug Wiegley

Hi Gary,

Thanks for filing.  Take a look at 
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html
 , which is work in progress to address the same issue. At the end of that, no 
one should be importing directly from neutron.

Thanks,
doug


> On Jan 12, 2016, at 5:31 AM, Gary Kotton  wrote:
> 
> Hi,
> I have drafted 
> https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have 
> up as an example (https://review.openstack.org/266304) 
> for people to chew on...
> Thanks
> Gary
> 
> 
> 
> On 1/12/16, 1:08 PM, "Smigiel, Dariusz"  wrote:
> 
>>> 
>>> Hi,
>>> At the moment private methods are used all over the place. Examples for
>>> this are the address pairs and the security groups. If you do a grep of the 
>>> ML2
>>> plugin you will see these innocent private methods being used.
>>> The end goal would be for us to have these as public methods.
>>> Thanks
>>> Gary
>>> 
>> 
>> OK, get it. But just wanted to know, what is the outcome from email 
>> discussion.
>> Do we need to match changed/removed private methods with deprecation warning,
>> or just modify and tell plugins: "deal with it" :)
>> 
>> BR,
>> Dariusz (dasm) Smigiel
>> 
>>> 
>>> 
>>> 
>>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz"  wrote:
>>> 
 
 
> Doug Wiegley  wrote:
>> 
>> 
>>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
> wrote:
>>> 
>>> Sean M. Collins  wrote:
>>> 
> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
>> On Fri, 8 Jan 2016, Gary Kotton wrote:
>> 
>> The commit
>> https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__github.com
>> _openstack_neutron_commit_5d53dfb8d64186-
>>> 2D=BQICAg=Sqcl0Ez6
>> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
>>> uEs=VlZxHpZBmzzkWT5jqz9JYBk8Y
>> Teq9N3-
>>> diTlNj4GyNc=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
>> w=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8=
>> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
>> that make use of the method _get_tenant_id_for_create
> 
> Just out of curiosity, is it not standard practice that a plugin
> shouldn't use a private method?
 
 +1 - hopefully decomposed plugins will audit their code and look
 +for
 other calls to private methods.
>>> 
>>> The fact that it broke *aas repos too suggests that we were not
>>> showing a proper example to those decomposed. I think it can be
>>> reasonable to restore the method until N, with a deprecation
>>> message, as Garry suggested in his patch. Especially since there
>>> is no actual burden to keep the method for another cycle.
>> 
>> The neutron community has been really lax about enforcing private
> methods.
>> And while we should absolutely reverse that trend, likely we should
>> give some warning. I agree with not going whole hog on that until N.
>> 
>> I'd suggest putting in a debtcollector reference when putting the
>> method
> back.
> 
> Done. https://review.openstack.org/265315
 
 
 Do we have any consensus about treating private methods? Any general
>>> tips about it, or every time should it be left for author decision?
 
 Should we use deprecation warning for all refactored private methods,
>>> treating it as "API" and rewriting underneath code?
 
 Thanks, Dariusz (dasm) Smigiel
 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

2016-01-12 Thread Ryan Brown


On 01/12/2016 06:52 AM, Jiri Tomasek wrote:

On 01/11/2016 04:51 PM, Dan Prince wrote:

Background info:

We've got a problem in TripleO at the moment where many of our
workflows can be driven by the command line only. This causes some
problems for those trying to build a UI around the workflows in that
they have to duplicate deployment logic in potentially multiple places.
There are specs up for review which outline how we might solve this
problem by building what is called TripleO API [1].

Late last year I began experimenting with an OpenStack service called
Mistral which contains a generic workflow API. Mistral supports
defining workflows in YAML and then creating, managing, and executing
them via an OpenStack API. Initially the effort was focused around the
idea of creating a workflow in Mistral which could supplant our
"baremetal introspection" workflow which currently lives in python-
tripleoclient. I create a video presentation which outlines this effort
[2]. This particular workflow seemed to fit nicely within the Mistral
tooling.



More recently I've turned my attention to what it might look like if we
were to use Mistral as a replacement for the TripleO API entirely. This
brings forth the question of would TripleO be better off building out
its own API... or would relying on existing OpenStack APIs be a better
solution?

Some things I like about the Mistral solution:

- The API already exists and is generic.

- Mistral already supports interacting with many of the OpenStack API's
we require [3]. Integration with keystone is baked in. Adding support
for new clients seems straightforward (I've had no issues in adding
support for ironic, inspector, and swift actions).

- Mistral actions are pluggable. We could fairly easily wrap some of
our more complex workflows (perhaps those that aren't easy to replicate
with pure YAML workflows) by creating our own TripleO Mistral actions.
This approach would be similar to creating a custom Heat resource...
something we have avoided with Heat in TripleO but I think it is
perhaps more reasonable with Mistral and would allow us to again build
out our YAML workflows to drive things. This might allow us to build
off some of the tripleo-common consolidation that is already underway
...

- We could achieve a "stable API" by simply maintaining input
parameters for workflows in a stable manner. Or perhaps workflows get
versioned like a normal API would be as well.

- The purist part of me likes Mistral quite a bit. It fits nicely with
the deploy OpenStack with OpenStack. I sort of feel like if we have to
build our own API in TripleO part of this vision has failed and could
even be seen as a massive technical debt which would likely be hard to
build a community around outside of TripleO.

- Some of the proposed validations could perhaps be implemented as new
Mistral actions as well. I'm not convinced we require TripleO API just
to support a validations mechanism yet. Perhaps validations seem hard
because we are simply trying to do them in the wrong places anyway?
(like for example perhaps we should validate network connectivity at
inspection time rather than during provisioning).

- Power users might find a workflow built around a Mistral API more
easy to interact with and expand upon. Perhaps this ends up being
something that gets submitted as a patchset back to the TripleO that we
accept into our upstream "stock" workflow sets.



Last week we landed the last patches [4] to our undercloud to enable
installing Mistral by simply setting: enable_mistral = true in
undercloud.conf. NOTE: you'll need to be using a recent trunk repo from
Delorean so that you have the recently added Mistral packages for this
to work. Although the feature is disable by default this should enable
those wishing to tinker with Mistral as a new TripleO undercloud
service an easy path forwards.

[1] https://review.openstack.org/#/c/230432
[2] https://www.youtube.com/watch?v=bnAT37O-sdw
[3] http://git.openstack.org/cgit/openstack/mistral/tree/mistral/action
s/openstack/mapping.json
[4] https://etherpad.openstack.org/p/tripleo-undercloud-workflow


__

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hi, I have a few questions:

Is Mistral action able to access/manipulate local files? E.g. access the
templates installed at undercloud's
/usr/share/openstack-tripleo-heat-templates?


I believe with mistral there would be an intermediate step of uploading 
the templates to Swift first. Heat can read templates from swift, and 
any mistral workflows would be able to read the templates out, modify 
them, and save back to swift.


Object stores FTW


I Mistral action able to call either OpenStack service python client or
OpenStack service API directly?

What is the response

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break