Re: [openstack-dev] [sahara] Asia friendly IRC meeting time

2014-12-03 Thread Sergey Lukjanov
There were no objections, so, we'll make a meeting tomorrow at 1400 UTC

On Thu, Nov 27, 2014 at 1:43 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 If there will be no objections till the next week, we'll try the new time
 (14:00UTC) next week.

 On Thu, Nov 27, 2014 at 4:06 AM, Zhidong Yu zdyu2...@gmail.com wrote:

 Thank you all!

 On Thu, Nov 27, 2014 at 1:15 AM, Sergey Lukjanov slukja...@mirantis.com
 wrote:

 I think that 6 am for US west works much better than 3 am for Saratov.

 So, I'm ok with keeping current time and add 1400 UTC.

18:00UTC: Moscow (9pm)  China(2am)  US West(10am)/US East (1pm)
14:00UTC: Moscow (5pm)  China(10pm)  US (W 6am / E 9am)

 I think it's the best option to make all of us able to join.


 On Wed, Nov 26, 2014 at 8:33 AM, Zhidong Yu zdyu2...@gmail.com wrote:

 If 6am works for people in US west, then I'm fine with Matt's
 suggestion (UTC14:00).

 Thanks, Zhidong

 On Tue, Nov 25, 2014 at 11:26 PM, Matthew Farrellee m...@redhat.com
 wrote:

 On 11/25/2014 02:37 AM, Zhidong Yu wrote:

  Current meeting time:
  18:00UTC: Moscow (9pm)China(2am) US West(10am)

 My proposal:
  18:00UTC: Moscow (9pm)China(2am) US West(10am)
  00:00UTC: Moscow (3am)China(8am) US West(4pm)


 fyi, a number of us are UW East (US West + 3 hours), so...

 current meeting time:
  18:00UTC: Moscow (9pm)  China(2am)  US West(10am)/US East (1pm)

 and during daylight savings it's US West(11am)/US East(2pm)

 so the proposal is:
  18:00UTC: Moscow (9pm)  China(2am)  US (W 10am / E 1pm)
  00:00UTC: Moscow (3am)  China(8am)  US (W 4pm / E 7pm)

 given it's literally impossible to schedule a meeting during business
 hours across saratov, china and the us, that's a pretty reasonable
 proposal. my concern is that 00:00UTC may be thin on saratov  US
 participants.

 also consider alternating the existing schedule w/ something that's ~4
 hours earlier...
  14:00UTC: Moscow (5pm)  China(10pm)  US (W 6am / E 9am)

 best,


 matt


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



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




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

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



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




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




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

2014-12-03 Thread Omri Marcovitch
Hello Anteaya,

A meeting between 8:00 - 16:00 UTC time will be great (Israel).


Thanks
Omri

-Original Message-
From: Joshua Hesketh [mailto:joshua.hesk...@rackspace.com] 
Sent: Wednesday, December 03, 2014 9:04 AM
To: He, Yongli; OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional 
Meeting for third-party

Hey,

0700 - 1000 UTC would work for me most weeks fwiw.

Cheers,
Josh

Rackspace Australia

On 12/3/14 11:17 AM, He, Yongli wrote:
 anteaya,

 UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for china.

 if there is no time slot there, just pick up any time between UTC 7:00 AM to 
 UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and dinner.)

 Yongi He
 -Original Message-
 From: Anita Kuno [mailto:ante...@anteaya.info]
 Sent: Tuesday, December 02, 2014 4:07 AM
 To: openstack Development Mailing List; openstack-in...@lists.openstack.org
 Subject: [openstack-dev] [third-party]Time for Additional Meeting for 
 third-party

 One of the actions from the Kilo Third-Party CI summit session was to start 
 up an additional meeting for CI operators to participate from non-North 
 American time zones.

 Please reply to this email with times/days that would work for you. The 
 current third party meeting is on Mondays at 1800 utc which works well since 
 Infra meetings are on Tuesdays. If we could find a time that works for Europe 
 and APAC that is also on Monday that would be ideal.

 Josh Hesketh has said he will try to be available for these meetings, he is 
 in Australia.

 Let's get a sense of what days and timeframes work for those interested and 
 then we can narrow it down and pick a channel.

 Thanks everyone,
 Anita.

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

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


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

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


Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

2014-12-03 Thread Anton Zemlyanov
The confirmation modal on the top of the other modal is weird and
cumbersome. I think disabling clicking outside space (staic backdrop) is
the right way to go.

Anton

On Tue, Dec 2, 2014 at 8:30 PM, Thai Q Tran tqt...@us.ibm.com wrote:

 I like David's approach, but having two modals (one for the form, one for
 the confirmation) on top of each other is a bit weird and would require
 constant checks for input.
 We already have three ways to close the dialog today: via the cancel
 button, X button, and ESC key. It's more important to me that I don't lose
 work by accidentally clicking outside. So from this perspective, I think
 that having a static behavior is the way to go. Regardless of what approach
 we pick, its an improvement over what we have today.


 [image: Inactive hide details for Timur Sufiev ---12/02/2014 04:22:00
 AM---Hello, Horizoneers and UX-ers! The default behavior of modal]Timur
 Sufiev ---12/02/2014 04:22:00 AM---Hello, Horizoneers and UX-ers! The
 default behavior of modals in Horizon (defined in turn by Bootstr

 From: Timur Sufiev tsuf...@mirantis.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 12/02/2014 04:22 AM
 Subject: [openstack-dev] [horizon] [ux] Changing how the modals are
 closed in Horizon
 --



 Hello, Horizoneers and UX-ers!

 The default behavior of modals in Horizon (defined in turn by Bootstrap
 defaults) regarding their closing is to simply close the modal once user
 clicks somewhere outside of it (on the backdrop element below and around
 the modal). This is not very convenient for the modal forms containing a
 lot of input - when it is closed without a warning all the data the user
 has already provided is lost. Keeping this in mind, I've made a patch [1]
 changing default Bootstrap 'modal_backdrop' parameter to 'static', which
 means that forms are not closed once the user clicks on a backdrop, while
 it's still possible to close them by pressing 'Esc' or clicking on the 'X'
 link at the top right border of the form. Also the patch [1] allows to
 customize this behavior (between 'true'-current one/'false' - no backdrop
 element/'static') on a per-form basis.

 What I didn't know at the moment I was uploading my patch is that David
 Lyle had been working on a similar solution [2] some time ago. It's a bit
 more elaborate than mine: if the user has already filled some some inputs
 in the form, then a confirmation dialog is shown, otherwise the form is
 silently dismissed as it happens now.

 The whole point of writing about this in the ML is to gather opinions
 which approach is better:
 * stick to the current behavior;
 * change the default behavior to 'static';
 * use the David's solution with confirmation dialog (once it'll be rebased
 to the current codebase).

 What do you think?

 [1] *https://review.openstack.org/#/c/113206/*
 https://review.openstack.org/#/c/113206/
 [2] *https://review.openstack.org/#/c/23037/*
 https://review.openstack.org/#/c/23037/

 P.S. I remember that I promised to write this email a week ago, but better
 late than never :).

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


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


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


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Oleg Bondarev
+1! Congrats, Henry and Kevin!

On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery mest...@mestery.com wrote:

 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.

 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.

 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.

 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/180

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

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


Re: [openstack-dev] [stable] Proposal to add Dave Walker back to stable-maint-core

2014-12-03 Thread Thierry Carrez
Ihar Hrachyshka wrote:
 +2

OK, lots of +2s and no objection, Daviey is back in !
Thanks,

-- 
Thierry Carrez (ttx)



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


[openstack-dev] [nova] Adding temporary code to nova to work around bugs in system utilities

2014-12-03 Thread Tony Breeds
Hi All,
I'd like to accomplish 2 things with this message:
1) Unblock (one way or another) https://review.openstack.org/#/c/123957
2) Create some form of consensus on when it's okay to add temporary code to
   nova to work around bugs in external utilities.

So some background on this specific issue.  The issue was first reported in
July 2014 at [1] and then clarified at [2].  The synopsis of the bug is that
calling qemu-img convert -O raw /may/ generate a corrupt output file if the
source image isn't fully flushed to disk.  The coreutils folk discovered
something similar in 2011 *sigh*

The clear and correct solution is to ensure that qemu-img uses
FIEMAP_FLAG_SYNC.  This in turn produces a measurable slowdown in that code
path, so additionally it's best if qemu-img uses an alternate method to
determine data status in a disk image.  This has been done and will be included
in qemu 2.2.0 when it's released.  These fixes prompted a more substantial
rework of that code in qemu.  Which is awesome but not *required* to fix the
bug in qemu.

While we wait for $distros to get the fixed qemu nova is still vulnerable to
the bug.  To that end I proposed a work around in nova that forces images
retrieved from glance to disk with an fsync() prior to calling qemu-img on
them.  I admit that this is ugly and has a performance impact.

In order to reduce the impact of the fsync() I considered:
1) Testing the qemu version and only fsync()ing on affected versions.
   - Vendors will backport the fix to there version of qemu.  The fixed version
 will still claim to be 2.1.0 (for example) and therefore trigger the
 fsync() when not required.  Given how unreliable this will be I dismissed
 it as an option

2) API Change
   - In the case of this specific bug we only need to fsync() in certain
 scenarios.  It would be easy to add a flag to IMAGE_API.download() to
 determine if this fsync() is required.  This has the nice property of only
 having a performance impact in the suspect case (personally I'll take
 slow-and-correct over fast-and-buggy any day).  My hesitation is that
 after we've modified the API it's very hard to remove that change when we
 decide the work around is redundant.

3) Config file option
   - For many of the same reasons as the API change this seemed like a bad
 idea.

Does anyone have any other ideas?

One thing that I haven't done is measure the impact of the fsync() on any
reasonable workload.  This is mainly because I don't really know how.  Sure I
could do some statistics in devstack but I don't really think they'd be
meaningful.  Also the size of the image in glance is fairly important.  An
fsync() of an 100Gb image is many times more painful than an 1Gb image.

While in Paris I was asked to look at other code paths in nova where we use
qemu-img convert.  I'm doing this analysis.  To date I have some suspicions
that snapshot (and migration) are affected, but no data that confirms or
debases that.  I continue to look at the appropriate code in nova, libvirt and
qemu.

I understand that there is more work to be done in this area, and I'm happy to
do it.  Having said that from where I sit that work is not directly related to
the bug that started this.

As the idea is to remove this code as soon as all the distros we care about
have a fixed qemu I started an albeit brief discussion here[3] on which distros
are in that list.  Armed with that list I have opened (or am in the process of
opening) bugs for each version of each distribution to make them aware of the
issue and the fix.  I have a status page at [4].

okay I think I'm done raving.

So moving forward:

1) So what should I do with the open review?
2) What can we learn from this in terms of how we work around key utilities
   that are not in our direct power to change.
   - Is taking ugly code for some time okay?  I understand that this is a
 complex issue as we're relying on $developer to be around (or leave enough
 information for those that follow) to determine when it's okay to remove
 the ugliness.

If you made it this far bravo!

Yours Tony.

[1] https://bugs.launchpad.net/nova/+bug/1350766
[2] https://bugs.launchpad.net/qemu/+bug/1368815
[3] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050526.html
[4] https://wiki.openstack.org/wiki/Bug1368815



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


Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

2014-12-03 Thread Sahid Orentino Ferdjaoui
On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote:
 Hi all
 
 I have submitted a small blueprint to allow filtering of available memory 
 pages 
 Reported by libvirt.

Can you address this with aggregate? this will also avoid to do
something specific in the driver libvirt. Which will have to be
extended to other drivers at the end.

 https://blueprints.launchpad.net/nova/+spec/libvirt-allowed-mempage-sizes
 
 I believe that this change is small enough to not require a spec as per
 http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html
 
 if a core (and others are welcome too :)) has time to review my blueprint and 
 confirm
 that a spec is not required I would be grateful as the spd is rapidly 
 approaching
 
 I have wip code developed which I hope to make available for review once
 I add unit tests.
 
 All relevant detail (copied below) are included in the whiteboard for the 
 blueprint.
 
 Regards
 Sean
 
 Problem description
 ===
 
 In the Kilo cycle, the virt drivers large pages feature[1] was introduced
 to allow a guests to request the type of memory backing that they desire
 via a flavor or image metadata.
 
 In certain configurations, it may be desired or required to filter the
 memory pages available to vms booted on a node. At present no mechanism
 exists to allow filtering of reported memory pages.
 
 Use Cases
 --
 
 On a host that only supports vhost-user or ivshmem,
 all VMs are required to use large page memory.
 If a vm is booted with standard pages with these interfaces,
 network connectivity will not available.
 
 In this case it is desirable to filter out small/4k pages when reporting
 available memory to the scheduler.
 
 Proposed change
 ===
 
 This blueprint proposes adding a new config variable (allowed_memory_pagesize)
 to the libvirt section of the nova.conf.
 
 cfg.ListOpt('allowed_memory_pagesize',
 default=['any'],
 help='List of allowed memory page sizes'
  'Syntax is SizeA,SizeB e.g. small,large'
  'valid sizes are: small,large,any,4,2048,1048576')
 
 The _get_host_capabilities function in nova/nova/virt/libvirt/driver.py
 will be modified to filter the mempages reported for each cell based on the
 value of CONF.libvirt.allowed_memory_pagesize
 
 If small is set then only 4k pages will be reported.
 If large is set 2MB and 1GB will be reported.
 If any is set no filtering will be applied.
 
 The default value of any was chosen to ensure that this change has no 
 effect on
 existing deployment.
 
 References
 ==
 [1] - https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


[openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

2014-12-03 Thread Li Junhong
Hi All,

Is it possible for Kilo nova controller to control the Juno compute nodes?
Is this scenario supported naturally by the nova mechanism in the design
and codes level?

-- 
Best Regards!

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


Re: [openstack-dev] [NFV][Telco] pxe-boot

2014-12-03 Thread Pasquale Porreca
The use case we were thinking about is a Network Function (e.g. IMS 
Nodes) implementation in which the high availability is based on 
OpenSAF. In this scenario there is an Active/Standby cluster of 2 System 
Controllers (SC) plus several Payloads (PL) that boot from network, 
controlled by the SC. The logic of which service to deploy on each 
payload is inside the SC.


In OpenStack both SCs and PLs will be instances running in the cloud, 
anyway the PLs should still boot from network under the control of the 
SC. In fact to use Glance to store the image for the PLs and keep the 
control of the PLs in the SC, the SC should trigger the boot of the PLs 
with requests to Nova/Glance, but an application running inside an 
instance should not directly interact with a cloud infrastructure 
service like Glance or Nova.


We know that it is yet possible to achieve network booting in OpenStack 
using an image stored in Glance that acts like a pxe client, anyway this 
workaround has some drawbacks, mainly due to the fact it won't be 
possible to choose the specific virtual NIC on which the network boot 
will happen, causing DHCP requests to flow on networks where they don't 
belong to and possible delays in the boot of the instances.


On 11/27/14 00:32, Steve Gordon wrote:

- Original Message -

From: Angelo Matarazzo angelo.matara...@dektech.com.au
To: OpenStack Development Mailing openstack-dev@lists.openstack.org, 
openstack-operat...@lists.openstack.org


Hi all,
my team and I are working on pxe boot feature very similar to the
Discless VM one  in Active blueprint list[1]
The blueprint [2] is no longer active and we created a new spec [3][4].

Nova core reviewers commented our spec and the first and the most
important objection is that there is not a compelling reason to
provide this kind of feature : booting from network.

Aside from the specific implementation, I think that some members of
TelcoWorkingGroup could be interested in  and provide a use case.
I would also like to add this item to the agenda of next meeting

Any thought?

We did discuss this today, and granted it is listed as a blueprint someone in 
the group had expressed interest in at a point in time - though I don't believe 
any further work was done. The general feeling was that there isn't anything 
really NFV or Telco specific about this over and above the more generic use 
case of legacy applications. Are you able to further elaborate on the reason 
it's NFV or Telco specific other than because of who is requesting it in this 
instance?

Thanks!

-Steve

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


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


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


[openstack-dev] [Ceilometer]Unit test failed on branch stable/icehouse

2014-12-03 Thread sam song
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, folks:

I clone the stable/icehouse branch of ceilometer project from github,
use tox -r -e py26 to run unit tests on CentOS 6.5 system.
Unfortunately there are many cases failed. You can find the output in
test.log, and pip.log is the output of pip list in py26 virtualenv.
All python packages are download from pypi.douban.com in China, which is
fresh according to http://www.pypi-mirrors.org/.

Any ideas to fix it are appreciated.
Thanks in advance.

Sam


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

iQEcBAEBAgAGBQJUftk7AAoJEPDWvv0r0XeReC4IAKh+cN2JHGsOEd3/VUsdBnMi
Bxlvjp0uzMB8vs2zOljLntf9XZGjPBoOWZcwArYHL3aLe1A+cHxXqm6Y+i0zLmJ2
jf0oV4War+MliptaJNE6BH9URBZ4p2WqxL2k6+V9SP+9dkCHjzTIOZ4zO31jbZy3
P7lfTzQELYAys4CFl3kEV/hm2JIPZXvpVUYGdCEYBc3CVcopCq+wDBChnQx3tIhh
ao4KXzx/fOHQK2HLSiv+p2y4XNWDIMA8wpGyjn97JL/eF+lckrVIBd3zFlpT+VtE
nidK+rjzWpSDdObEKdEXh+C0jy0S5uBrSU+5hba0GNRVUbnnXP5jHrsP7HZ6900=
=mwtP
-END PGP SIGNATURE-


log.tar.gz
Description: GNU Zip compressed data
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

2014-12-03 Thread Joe Gordon
On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com wrote:

 Hi All,

 Is it possible for Kilo nova controller to control the Juno compute nodes?
 Is this scenario supported naturally by the nova mechanism in the design
 and codes level?


Yes,

We gate on making sure we can run Kilo nova with Juno compute nodes.




 --
 Best Regards!
 
 Junhong, Li

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


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


Re: [openstack-dev] [Ceilometer]Unit test failed on branch stable/icehouse

2014-12-03 Thread Dina Belova
Sam,

It really looks like you're having old *.pyc files locally in this repo
(probably left from other branch testing)... As I understood, you just
cloned clean repo and first tests you've ran were these ones? If no,
removing all *.pyc files will help you, otherwise I have no clear idea why
you might have unit tests failing in the new just cloned repository... Need
to investigate.

Cheers,
Dina

On Wed, Dec 3, 2014 at 12:34 PM, sam song samsong8...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi, folks:

 I clone the stable/icehouse branch of ceilometer project from github,
 use tox -r -e py26 to run unit tests on CentOS 6.5 system.
 Unfortunately there are many cases failed. You can find the output in
 test.log, and pip.log is the output of pip list in py26 virtualenv.
 All python packages are download from pypi.douban.com in China, which is
 fresh according to http://www.pypi-mirrors.org/.

 Any ideas to fix it are appreciated.
 Thanks in advance.

 Sam


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

 iQEcBAEBAgAGBQJUftk7AAoJEPDWvv0r0XeReC4IAKh+cN2JHGsOEd3/VUsdBnMi
 Bxlvjp0uzMB8vs2zOljLntf9XZGjPBoOWZcwArYHL3aLe1A+cHxXqm6Y+i0zLmJ2
 jf0oV4War+MliptaJNE6BH9URBZ4p2WqxL2k6+V9SP+9dkCHjzTIOZ4zO31jbZy3
 P7lfTzQELYAys4CFl3kEV/hm2JIPZXvpVUYGdCEYBc3CVcopCq+wDBChnQx3tIhh
 ao4KXzx/fOHQK2HLSiv+p2y4XNWDIMA8wpGyjn97JL/eF+lckrVIBd3zFlpT+VtE
 nidK+rjzWpSDdObEKdEXh+C0jy0S5uBrSU+5hba0GNRVUbnnXP5jHrsP7HZ6900=
 =mwtP
 -END PGP SIGNATURE-

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




-- 

Best regards,

Dina Belova

Software Engineer

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


Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

2014-12-03 Thread Li Junhong
Hi Joe,

Thank you for your confirmative answer and the wonderful gate testing
pipeline.

On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com wrote:

 Hi All,

 Is it possible for Kilo nova controller to control the Juno compute
 nodes? Is this scenario supported naturally by the nova mechanism in the
 design and codes level?


 Yes,

 We gate on making sure we can run Kilo nova with Juno compute nodes.




 --
 Best Regards!
 
 Junhong, Li

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



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




-- 
Best Regards!

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


Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Thierry Carrez
Alan Pevec wrote:
 General: cap Oslo and client library versions - sync from
 openstack/requirements stable/juno, would be good to include in the
 release.
 https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z

So it looks like we should hold on that, and revert the recent capping
before release (see further down on this thread).

 Ceilometer (all proposed by Ceilo PTL)
 https://review.openstack.org/138315
Already in

 https://review.openstack.org/138317
+1

 https://review.openstack.org/138320
+1

 https://review.openstack.org/138321
Impact a bit unclear, but then the fix is basic

 https://review.openstack.org/138322
+1

 Cinder
 https://review.openstack.org/137537 - small change and limited to the
 VMWare driver
+1

 Glance
 https://review.openstack.org/137704 - glance_store is backward
 compatible, but not sure about forcing version bump on stable
-1 for 2014.2.1 exception, also needs to be revisited in light of recent
capping revert proposal

 https://review.openstack.org/137862 - Disable osprofiler by default to
 prevent upgrade issues, disabled by default in other services
Sounds like something we'd rather have in the point release than after.
I don't think it's aversion incompatibility issue, but more of an
upgrade potential pain.

 Horizon
 standing-after-freeze translation update, coming on Dec 3
 https://review.openstack.org/138018 - visible issue, no translation
 string changes
+1

 https://review.openstack.org/138313 - low risk patch for a highly
 problematic issue
Already in

 Neutron
 https://review.openstack.org/136294 - default SNAT, see review for
 details, I cannot distil 1liner :)
-1: I would rather fix the doc to match behavior, than change behavior
to match the doc and lose people that were relying on it.

 https://review.openstack.org/136275 - self-contained to the vendor
 code, extensively tested in several deployments
+0: Feels a bit large for a last-minute exception.

 Nova
 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/juno+topic:1386236/juno,n,z
 - soaked more than a week in master, makes numa actually work in Juno
+0: Also feels a bit large for a last-minute exception

 Sahara
 https://review.openstack.org/135549 - fix for auto security groups,
 there were some concerns, see review for details
Already in

-- 
Thierry Carrez (ttx)

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


Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

2014-12-03 Thread Li Junhong
Hi Joe,

Just want to confirm one more question, in the gate testing, is the
neutron/cinder/glance Kilo or Juno. Or in another word, is the controller
in gate testing an all-in-one controller?

On Wed, Dec 3, 2014 at 5:49 PM, Li Junhong lijh.h...@gmail.com wrote:

 Hi Joe,

 Thank you for your confirmative answer and the wonderful gate testing
 pipeline.

 On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com wrote:

 Hi All,

 Is it possible for Kilo nova controller to control the Juno compute
 nodes? Is this scenario supported naturally by the nova mechanism in the
 design and codes level?


 Yes,

 We gate on making sure we can run Kilo nova with Juno compute nodes.




 --
 Best Regards!
 
 Junhong, Li

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



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




 --
 Best Regards!
 
 Junhong, Li




-- 
Best Regards!

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Alexander Kislitsky
We had used Flask in the fuel-stats. It was easy and pleasant and all
project requirements was satisfied. And I saw difficulties and workarounds
with Pecan, when Nick integrated it into Nailgun.
So +1 for Flask.


On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com
wrote:

 Michael, we already solved all issues I described, and I just don't
 want to solve them once again after moving to another framework. Also,
 I think, nothing of these wishes contradicts with good API design.

 On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
 krotsch...@gmail.com wrote:
  This sounds more like you need to pay off technical debt and clean up
 your
  API.
 
  Michael
 
  On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com
  wrote:
 
  Hello all,
 
  I actually tried to use Pecan and even created a couple of PoCs, but
  there due to historical reasons of how our API is organized it will
  take much more time to implement all workarounds we need to issues
  Pecan doesn't solve out of the box, like working with non-RESTful
  URLs, reverse URL lookup, returning custom body in 404 response,
  wrapping errors to JSON automatically, etc.
 
  As far as I see, each OpenStack project implements its own workarounds
  for these issues, but still it requires much less men and hours for us
  to move to Flask-Restful instead of Pecan, because all these problems
  are already solved there.
 
  BTW, I know a lot of pretty big projects using Flask (it's the second
  most popular Web framework after Django in Python Web community), they
  even have their own hall of fame:
  http://flask.pocoo.org/community/poweredby/ .
 
  On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote:
   On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
   Hi, Sebastian,
  
   Thank you for raising this topic again.
  
   [snip]
  
   Personally, I'd like to use Flask instead of Pecan, because first one
   is more production-ready tool and I like its design. But I believe
   this should be resolved by voting.
  
   Thanks,
   Igor
  
   On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
   skalinow...@mirantis.com wrote:
   Hi all,
  
   [snip explanation+history]
  
   Best,
   Sebastian
  
   Given that Pecan is used for other OpenStack projects and has plenty
 of
   builtin functionality (REST support, sessions, etc) I'd prefer it for
 a
   number of reasons.
  
   1) Wouldn't have to pull in plugins for standard (in Pecan) things
   2) Pecan is built for high traffic, where Flask is aimed at much
 smaller
   projects
   3) Already used by other OpenStack projects, so common patterns can be
   reused as oslo libs
  
   Of course, the Flask community seems larger (though the average flask
   project seems pretty small).
  
   I'm not sure what determines production readiness, but it seems to
 me
   like Fuel developers fall more in Pecan's target audience than in
   Flask's.
  
   My $0.02,
   Ryan
  
   --
   Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  --
  Best regards,
  Nick Markov
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



 --
 Best regards,
 Nick Markov

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

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


Re: [openstack-dev] [neutron] Private external network

2014-12-03 Thread Andrew Ruthven
Hi,

I'm picking up this thread from a few months ago, as I have a
requirement for a private external network and after doing some testing
today came to the conclusion that this isn't currently possible. Rats.

On Tue, 2014-10-14 at 17:42 +, A, Keshava wrote:
 Hi,
 
 Across these private External network/tenant :: floating IP can be
 shared ? 

I would think not. The external network and associated floating IPs
should only be accessible by the tenant (or tenants?) which are granted
to use it.

At a guess that tenants thought above is where the RBAC considerations
come in.

Does anyone have any pointers to the previous discussions on this? The
BP [0] which Édouard linked to states it was untargetted due to
community discussions but has no links or other references to those
discussions. 

Cheers,
Andrew

[0]
https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks


-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2015 
  New Zealand's only Cloud:   |  BeAwesome in Auckland, NZ
https://catalyst.net.nz/cloud | http://lca2015.linux.org.au



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


Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Thierry Carrez
Doug Hellmann wrote:
 
 On Dec 2, 2014, at 5:41 PM, Alan Pevec ape...@gmail.com wrote:
 
 General: cap Oslo and client library versions - sync from
 openstack/requirements stable/juno, would be good to include in
 the release.
 https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z

 +2,

 let's keep all deps in sync. Those updates do not break anything
 for existing users.

 Just spotted it, there is now proposal to revert caps in Juno:

 https://review.openstack.org/138546

 Doug, shall we stop merging caps to projects in Juno?
 
 Today we found that when we have caps in place that do not overlap with the 
 versions used in master, we can’t upgrade services one at a time on a host 
 running multiple services. We didn’t have this problem between icehouse and 
 juno because I used the same cap values for both releases, so we didn’t 
 trigger any problems with grenade.
 
 One solution is to undo the caps and then add caps when we discover issues in 
 new versions of libraries and stable branches. Another is to require 
 applications to work with “old” versions of libraries and degrade their 
 feature set, so that we can keep the lower bounds overlapping.
 
 In retrospect, this issue with caps was obvious, but I don’t remember it 
 being raise in the planning. As Sean pointed out on IRC today, we should have 
 someone write a spec for changing the way we deal with requirements so we can 
 think about it before deciding what to do.
 
 After the releases today, the “no more alpha versions for Oslo” ship has 
 sailed. Removing the caps will at least let us move ahead while we figure out 
 what to do for stable branches.

Yes, looks like we need to think a bit deeper about it, and at the very
least not ship them in the point release.

+2 on the requirements revert.

-- 
Thierry Carrez (ttx)

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


Re: [openstack-dev] [neutron] Private external network

2014-12-03 Thread Kevin Benton
There is a current blueprint under discussion[1] which would have covered
the external network access control as well, however it looks like the
scope is going to have to be reduced for this cycle so it will be limited
to shared networks if it's accepted at all.

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

On Wed, Dec 3, 2014 at 1:59 AM, Andrew Ruthven and...@etc.gen.nz wrote:

 Hi,

 I'm picking up this thread from a few months ago, as I have a
 requirement for a private external network and after doing some testing
 today came to the conclusion that this isn't currently possible. Rats.

 On Tue, 2014-10-14 at 17:42 +, A, Keshava wrote:
  Hi,
 
  Across these private External network/tenant :: floating IP can be
  shared ?

 I would think not. The external network and associated floating IPs
 should only be accessible by the tenant (or tenants?) which are granted
 to use it.

 At a guess that tenants thought above is where the RBAC considerations
 come in.

 Does anyone have any pointers to the previous discussions on this? The
 BP [0] which Édouard linked to states it was untargetted due to
 community discussions but has no links or other references to those
 discussions.

 Cheers,
 Andrew

 [0]

 https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks


 --
 Andrew Ruthven, Wellington, New Zealand
 and...@etc.gen.nz | linux.conf.au 2015
   New Zealand's only Cloud:   |  BeAwesome in Auckland, NZ
 https://catalyst.net.nz/cloud | http://lca2015.linux.org.au



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




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


[openstack-dev] [tripleo] Managing no-mergepy template duplication

2014-12-03 Thread Steven Hardy
Hi all,

Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent puppet-software-config implementations mature (as well as
improving overcloud updates via heat).

Since Tomas's patch landed[1] to enable --no-mergepy in
tripleo-heat-templates, it's become apparent that frequently patches are
submitted which only update overcloud-source.yaml, so I've been trying to
catch these and ask for a corresponding change to e.g controller.yaml.

This raises the following questions:

1. Is it reasonable to -1 a patch and ask folks to update in both places?
2. How are we going to handle this duplication and divergence?
3. What's the status of getting gating CI on the --no-mergepy templates?
4. What barriers exist (now that I've implemented[2] the eliding functionality
requested[3] for ResourceGroup) to moving to the --no-mergepy
implementation by default?

Thanks for any clarification you can provide! :)

Steve

[1] https://review.openstack.org/#/c/123100/
[2] https://review.openstack.org/#/c/128365/
[3] https://review.openstack.org/#/c/123713/

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


Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

2014-12-03 Thread Daniel P. Berrange
On Wed, Dec 03, 2014 at 10:03:06AM +0100, Sahid Orentino Ferdjaoui wrote:
 On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote:
  Hi all
  
  I have submitted a small blueprint to allow filtering of available memory 
  pages 
  Reported by libvirt.
 
 Can you address this with aggregate? this will also avoid to do
 something specific in the driver libvirt. Which will have to be
 extended to other drivers at the end.

Agreed, I think you can address this by setting up host aggregates
and then using setting the desired page size on the flavour.

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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Miguel Ángel Ajo
Congratulations to Henry and Kevin, very well deserved!,
keep up the good work! :)


Miguel Ángel Ajo


On Wednesday, 3 de December de 2014 at 09:44, Oleg Bondarev wrote:

 +1! Congrats, Henry and Kevin!
  
 On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery mest...@mestery.com 
 (mailto:mest...@mestery.com) wrote:
  Now that we're in the thick of working hard on Kilo deliverables, I'd
  like to make some changes to the neutron core team. Reviews are the
  most important part of being a core reviewer, so we need to ensure
  cores are doing reviews. The stats for the 180 day period [1] indicate
  some changes are needed for cores who are no longer reviewing.
   
  First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
  neutron-core. Bob and Nachi have been core members for a while now.
  They have contributed to Neutron over the years in reviews, code and
  leading sub-teams. I'd like to thank them for all that they have done
  over the years. I'd also like to propose that should they start
  reviewing more going forward the core team looks to fast track them
  back into neutron-core. But for now, their review stats place them
  below the rest of the team for 180 days.
   
  As part of the changes, I'd also like to propose two new members to
  neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
  been very active in reviews, meetings, and code for a while now. Henry
  lead the DB team which fixed Neutron DB migrations during Juno. Kevin
  has been actively working across all of Neutron, he's done some great
  work on security fixes and stability fixes in particular. Their
  comments in reviews are insightful and they have helped to onboard new
  reviewers and taken the time to work with people on their patches.
   
  Existing neutron cores, please vote +1/-1 for the addition of Henry
  and Kevin to the core team.
   
  Thanks!
  Kyle
   
  [1] http://stackalytics.com/report/contribution/neutron-group/180
   
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  


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


Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

2014-12-03 Thread Joe Gordon
On Wed, Dec 3, 2014 at 11:53 AM, Li Junhong lijh.h...@gmail.com wrote:

 Hi Joe,

 Just want to confirm one more question, in the gate testing, is the
 neutron/cinder/glance Kilo or Juno. Or in another word, is the controller
 in gate testing an all-in-one controller?


Great question. In our current test neutron/cinder/glance are Kilo. But we
do want to support the case where neutron/cinder/glance are Juno, as you
should be able to upgrade each service independently. While we don't test
it, we design around that goal, so with some testing and bug fixing it
should work.



 On Wed, Dec 3, 2014 at 5:49 PM, Li Junhong lijh.h...@gmail.com wrote:

 Hi Joe,

 Thank you for your confirmative answer and the wonderful gate testing
 pipeline.

 On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com wrote:

 Hi All,

 Is it possible for Kilo nova controller to control the Juno compute
 nodes? Is this scenario supported naturally by the nova mechanism in the
 design and codes level?


 Yes,

 We gate on making sure we can run Kilo nova with Juno compute nodes.




 --
 Best Regards!
 
 Junhong, Li

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



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




 --
 Best Regards!
 
 Junhong, Li




 --
 Best Regards!
 
 Junhong, Li

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


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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Ivan Kliuk
Well, I think if the general direction is to make Fuel using OpenStack 
tools and libraries as much as it's possible, that makes sense to use 
Pecan. Otherwise I'd prefer to swap web.py with Flask.


Sincerely yours,
Ivan Kliuk

On 12/2/14 16:55, Igor Kalnitsky wrote:

Hi, Sebastian,

Thank you for raising this topic again.

Yes, indeed, we need to move out from web.py as soon as possible and
there are a lot of reasons why we should do it. But this topic is not
about Why, this topic is about Flask or Pecan.

Well, currently Fuel uses both of this frameworks:

* OSTF is using Pecan
* Fuel Stats is using Flask

Personally, I'd like to use Flask instead of Pecan, because first one
is more production-ready tool and I like its design. But I believe
this should be resolved by voting.

Thanks,
Igor

On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:

Hi all,

Some time ago we had a discussion about moving Nailgun to new web framework
[1].

There was comparison [2] of two possible options: Pecan [3] and Flask [4].
We came to conclusion that we need to move Nailgun on some alive web
framework
instead of web.py [5] (some of the reasons: [6]) but there was no clear
agreement
on what framework (there were strong voices for Flask).

I would like to bring this topic up again so we could discuss with broader
audience and
make final decision what will be our next web framework.

I think that we should also consider to make that framework our weapon of
choice (or so
called standard) when creating new web services in Fuel.

Best,
Sebastian


[1] https://lists.launchpad.net/fuel-dev/msg01397.html
[2]
https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
[3] http://www.pecanpy.org/
[4] http://flask.pocoo.org/
[5] http://webpy.org/
[6] https://lists.launchpad.net/fuel-dev/msg01501.html

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


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



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


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Mathieu Rohon
Hi all,

It seems that a process with a survey for neutron core
election/removal was about to take place [1]. Has it been applied for
this proposal?
This proposal has been hardly discussed during neutron meetings
[2][3]. Many cores agree that the number of reviews shouldn't be the
only metrics. And this statement is reflected in the Survey Questions.
So I'm surprised to see such a proposal based on stackalitics figures.

[1]https://etherpad.openstack.org/p/neutron-peer-review
[2]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-13-21.02.log.html
[3]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-21-14.00.log.html

On Wed, Dec 3, 2014 at 9:44 AM, Oleg Bondarev obonda...@mirantis.com wrote:
 +1! Congrats, Henry and Kevin!

 On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery mest...@mestery.com wrote:

 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.

 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.

 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.

 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/180

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



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


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


Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

2014-12-03 Thread Chris Jones
Hi

I am very sympathetic to this view. We have a patch in hand that improves the 
situation. We also have disagreement about the ideal situation.

I +2'd Ian's patch because it makes things work better than they do now. If we 
can arrive at an ideal solution later, great, but the more I think about 
logging from a multitude of bash scripts, and tricks like XTRACE_FD, the more I 
think it's crazy and we should just incrementally improve the non-trace logging 
as a separate exercise, leaving working tracing for true debugging situations.

Cheers,
--
Chris Jones

 On 3 Dec 2014, at 05:00, Ian Wienand iwien...@redhat.com wrote:
 
 On 12/03/2014 09:30 AM, Clint Byrum wrote:
 I for one find the idea of printing every cp, cat, echo and ls command out
 rather frustratingly verbose when scanning logs from a normal run.
 
 I for one find this ongoing discussion over a flag whose own help says
 -x -- turn on tracing not doing the blindly obvious thing of turning
 on tracing and the seeming inability to reach to a conclusion on a
 posted review over 3 months a troubling narrative for potential
 consumers of diskimage-builder.
 
 -i
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [neutron] force_gateway_on_subnet, please don't deprecate

2014-12-03 Thread Miguel Ángel Ajo
I will spend some time on it during tonight/weekend to make sure
it’s removed and that we have reference implementation working at once.

I propose following the bug fix way, as it’s a tiny change.

https://bugs.launchpad.net/neutron/+bug/1398768

@amuller, I’m not sure I understand why does it need to be covered in the 
dhcp-agent side. Pushing extra routes to guest-vms?, I think we don’t cover the 
case of instances connected to an external network where we provide dhcp, but 
we may do that if we are or if we start covering that case anytime.


Miguel Ángel Ajo


On Tuesday, 2 de December de 2014 at 15:48, Ihar Hrachyshka wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
  
 On 01/12/14 21:19, Kyle Mestery wrote:
  On Mon, Dec 1, 2014 at 6:12 AM, Assaf Muller amul...@redhat.com 
  (mailto:amul...@redhat.com)
  wrote:


   - Original Message -
 
My proposal here, is, _let’s not deprecate this setting_, as
it’s a valid use case of a gateway configuration, and let’s
provide it on the reference implementation.
 


   I agree. As long as the reference implementation works with the
   setting off there's no need to deprecate it. I still think the
   default should be set to True though.

   Keep in mind that the DHCP agent will need changes as well.
  ++ to both suggestions Assaf. Thanks for bringing this up Miguel!
   
  
  
 Miguel, how about sending a patch that removes deprecation warning
 from the help text then?
  
   
  Kyle
   
 
TL;DR
 
I’ve been looking at this yesterday, during a test deployment  
on a site where they provide external connectivity with the  
gateway outside subnet.
 
And I needed to switch it of, to actually be able to have any
external connectivity.
 
https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L121
 This is handled by providing an on-link route to the gateway first,
and then adding the default gateway.
 
It looks to me very interesting (not only because it’s the only
way to work on that specific site [2][3][4]), because you can
dynamically wire RIPE blocks to your server, without needing to
use an specific IP for external routing or broadcast purposes,
and instead use the full block in openstack.
 
 
I have a tiny patch to support this on the neutron l3-agent [1]
I yet need to add the logic to check “gateway outside subnet”,
then add the “onlink” route.
 
 
[1]
 
diff --git a/neutron/agent/linux/interface.py  
b/neutron/agent/linux/interface.py index 538527b..5a9f186
100644 --- a/neutron/agent/linux/interface.py +++
b/neutron/agent/linux/interface.py @@ -116,15 +116,16 @@ class
LinuxInterfaceDriver(object): namespace=namespace, ip=ip_cidr)
 
- if gateway: - device.route.add_gateway(gateway) -  
new_onlink_routes = set(s['cidr'] for s in extra_subnets) + if
gateway: + new_onlink_routes.update([gateway])  
existing_onlink_routes =
set(device.route.list_onlink_routes()) for route in
new_onlink_routes - existing_onlink_routes:  
device.route.add_onlink_route(route) for route in
existing_onlink_routes - new_onlink_routes:  
device.route.delete_onlink_route(route) + if gateway: +
device.route.add_gateway(gateway)
 
def delete_conntrack_state(self, root_helper, namespace, ip):  
Delete conntrack state associated with an IP address.
 
[2] http://www.soyoustart.com/ [3] http://www.ovh.co.uk/ [4]
http://www.kimsufi.com/
 
 
Miguel Ángel Ajo
 
 
 
 
___ OpenStack-dev
mailing list OpenStack-dev@lists.openstack.org 
(mailto:OpenStack-dev@lists.openstack.org)  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



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

   
   
  ___ OpenStack-dev
  mailing list OpenStack-dev@lists.openstack.org 
  (mailto:OpenStack-dev@lists.openstack.org)  
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   
  
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
  
 iQEcBAEBCgAGBQJUfdEsAAoJEC5aWaUY1u57a4QIANjx/wOJJKlHJ1kiE5DQ80La
 WP5DYwWj64MA+pDXPoE18+JZEV+7igHD7zeKb8pua4Ql+X/EDbLG5GK1ry4EV5RC
 uKnO2tht/bLfrniirqoOcL5TqybW86ZP4TLtTzV1PdAQBNGoOaRU8pox5oAkZOmm
 FrFVtBqoMtUAM9X8P7OHjkkvMLfoBinhWjlnyYWrzl6ZJtTCCipWJrVesHoWAL+F
 DcWotMsSMkkCAolnDE1AST4Z6pRvj7Y4lhQyZGaOtDGkYoMPBb7PTaGIltzX3ijB
 ZzDwz39o+kU9pY0/7Web6tFCEw+zFFr01rVBcQXDi5cJ2wRW7uT0J/9Aw0Rrn1M=
 =coN8
 -END PGP SIGNATURE-
  
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org 

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Flavio Percoco

On 02/12/14 14:22 +0100, Alan Pevec wrote:

Hi all,

here are exception proposal I have collected when preparing for the
2014.2.1 release,
stable-maint members please have a look!


General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in the
release.
https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z


+2

[snip]


Cinder
https://review.openstack.org/137537 - small change and limited to the
VMWare driver

+2


Glance
https://review.openstack.org/137704 - glance_store is backward
compatible, but not sure about forcing version bump on stable
https://review.openstack.org/137862 - Disable osprofiler by default to
prevent upgrade issues, disabled by default in other services


+2 to both

[snip]

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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


Re: [openstack-dev] [python-novaclient] Status of novaclient V3

2014-12-03 Thread Joe Gordon
On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin akuri...@mirantis.com
wrote:

 Hi!

 While working on fixing wrong import in novaclient v3 shell, I have found
 that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
 are broken, because appropriate managers are missed from V3
 client(novaclient.V3.client.Client).

 Template of error is ERROR (AttributeError): 'Client' object has no
 attribute 'attr', where attr can be floating_ip_pools,
 floating_ip, security_groups, dns_entries and etc.

 I know that novaclient V3 is not finished yet, and I guess it will be not
 finished. So the main question is:
  What we should do with implemented code of novaclient V3 ? Should it be
 ported to novaclient V2.1 or it can be removed?


I think it can be removed, as we are not going forward with the V3 API. But
I will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.




 --
 Best regards,
 Andrey Kurilin.

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


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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Przemyslaw Kaminski
The only useful paradigm to write in Flask is MethodView's for me [1] 
because decorators seem hard to refactor for large projects. Please look 
at adding URLs -- one has to additionally specify methods to match those 
from the MethodView -- this is code duplication and looks ugly.


It seems though that Fask-RESTful [2] fixes this but then we're 
dependent on 2 projects.


I don't like that Flask uses a global request object [3]. From Flask 
documentation


Basically you can completely ignore that this is the case unless you 
are doing something like unit testing. You will notice that code which 
depends on a request object will suddenly break because there is no 
request object. The solution is creating a request object yourself and 
binding it to the context.


Yeah, let's make testing even harder...

Pecan looks better in respect of RESTful services [4].
POST parameters are cleanly passed as arguments to the post method. It 
also provides custom JSON serialization hooks [5] so we can forget about 
explicit serialization in handlers.


So from these 2 choices I'm for Pecan.

[1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
[2] https://flask-restful.readthedocs.org/en/0.3.0/
[3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
[4] http://pecan.readthedocs.org/en/latest/rest.html
[5] http://pecan.readthedocs.org/en/latest/jsonify.html


P.

On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:
We had used Flask in the fuel-stats. It was easy and pleasant and all 
project requirements was satisfied. And I saw difficulties and 
workarounds with Pecan, when Nick integrated it into Nailgun.

So +1 for Flask.


On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com 
mailto:nmar...@mirantis.com wrote:


Michael, we already solved all issues I described, and I just don't
want to solve them once again after moving to another framework. Also,
I think, nothing of these wishes contradicts with good API design.

On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
krotsch...@gmail.com mailto:krotsch...@gmail.com wrote:
 This sounds more like you need to pay off technical debt and
clean up your
 API.

 Michael

 On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov
nmar...@mirantis.com mailto:nmar...@mirantis.com
 wrote:

 Hello all,

 I actually tried to use Pecan and even created a couple of
PoCs, but
 there due to historical reasons of how our API is organized it will
 take much more time to implement all workarounds we need to issues
 Pecan doesn't solve out of the box, like working with non-RESTful
 URLs, reverse URL lookup, returning custom body in 404 response,
 wrapping errors to JSON automatically, etc.

 As far as I see, each OpenStack project implements its own
workarounds
 for these issues, but still it requires much less men and hours
for us
 to move to Flask-Restful instead of Pecan, because all these
problems
 are already solved there.

 BTW, I know a lot of pretty big projects using Flask (it's the
second
 most popular Web framework after Django in Python Web
community), they
 even have their own hall of fame:
 http://flask.pocoo.org/community/poweredby/ .

 On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com
mailto:rybr...@redhat.com wrote:
  On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
  Hi, Sebastian,
 
  Thank you for raising this topic again.
 
  [snip]
 
  Personally, I'd like to use Flask instead of Pecan, because
first one
  is more production-ready tool and I like its design. But I
believe
  this should be resolved by voting.
 
  Thanks,
  Igor
 
  On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
  skalinow...@mirantis.com mailto:skalinow...@mirantis.com
wrote:
  Hi all,
 
  [snip explanation+history]
 
  Best,
  Sebastian
 
  Given that Pecan is used for other OpenStack projects and has
plenty of
  builtin functionality (REST support, sessions, etc) I'd
prefer it for a
  number of reasons.
 
  1) Wouldn't have to pull in plugins for standard (in Pecan)
things
  2) Pecan is built for high traffic, where Flask is aimed at
much smaller
  projects
  3) Already used by other OpenStack projects, so common
patterns can be
  reused as oslo libs
 
  Of course, the Flask community seems larger (though the
average flask
  project seems pretty small).
 
  I'm not sure what determines production readiness, but it
seems to me
  like Fuel developers fall more in Pecan's target audience than in
  Flask's.
 
  My $0.02,
  Ryan
 
  --
  Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
 
  ___
  OpenStack-dev 

Re: [openstack-dev] [python-novaclient] Status of novaclient V3

2014-12-03 Thread Christopher Yeoh



 On 3 Dec 2014, at 10:00 pm, Joe Gordon joe.gord...@gmail.com wrote:
 
 
 
 On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin akuri...@mirantis.com wrote:
 Hi!
 
 While working on fixing wrong import in novaclient v3 shell, I have found 
 that a lot of commands, which are listed in V3 shell(novaclient.v3.shell), 
 are broken, because appropriate managers are missed from V3 
 client(novaclient.V3.client.Client).
 
 Template of error is ERROR (AttributeError): 'Client' object has no 
 attribute 'attr', where attr can be floating_ip_pools, floating_ip, 
 security_groups, dns_entries and etc.
 
 I know that novaclient V3 is not finished yet, and I guess it will be not 
 finished. So the main question is:
  What we should do with implemented code of novaclient V3 ? Should it be 
 ported to novaclient V2.1 or it can be removed?
 
 I think it can be removed, as we are not going forward with the V3 API. But I 
 will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.


I think it can all just be removed now. We're going to need to enhance nova 
client to understand micro versions instead. But for now v2.1 should look just 
like v2

Chris

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


[openstack-dev] [Neutron] DVR Slides from Paris Summit

2014-12-03 Thread Andreas Scheuring
Hi, 
is there a way to get access to the slides from the DVR session of the
Paris summit? Unfortunately the slides in the video are not readable. 

Speakers were Swaminathan Vasudevan, Jack McCann, Vivekanandan,
Narasimhan, Rajeev Grover, Michael Smith. So maybe one of you can post
them on slideshare or somewhere else? That would be great.

This is the link to the related video

https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/architectural-overview-of-distributed-virtual-routers-in-openstack-neutron



Thanks

-- 
Andreas 
(irc: scheuran)




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


[openstack-dev] How to get openstack bugs data for research?

2014-12-03 Thread zfx0...@gmail.com
Hi, all

I am a graduate student in Peking University, our lab do some research on open 
source projects. 
This is our introduction: https://passion-lab.org/

Now we need openstack issues data for research, I found the issues list: 
https://bugs.launchpad.net/openstack/
I want to download the openstack issues data, Could anyone tell me how to 
download the data? Or is there some link or API for download the data?

And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ,is this all? 
why so few?

Many thanks!

Beat regards,
Feixue, Zhang



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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Kamil Sambor
Additionaly  to what Przemek wrote, also Pecan is released more often, IMHO
documentation is better written, and described a lot of possibilities of
modification, also as Lukasz wrote in previous thread that Pecan is used in
openstack.

So I'm also for Pecan

Best regards,
Kamil S.

On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski pkamin...@mirantis.com
 wrote:

  The only useful paradigm to write in Flask is MethodView's for me [1]
 because decorators seem hard to refactor for large projects. Please look at
 adding URLs -- one has to additionally specify methods to match those from
 the MethodView -- this is code duplication and looks ugly.

 It seems though that Fask-RESTful [2] fixes this but then we're dependent
 on 2 projects.

 I don't like that Flask uses a global request object [3]. From Flask
 documentation

 Basically you can completely ignore that this is the case unless you are
 doing something like unit testing. You will notice that code which depends
 on a request object will suddenly break because there is no request object.
 The solution is creating a request object yourself and binding it to the
 context.

 Yeah, let's make testing even harder...

 Pecan looks better in respect of RESTful services [4].
 POST parameters are cleanly passed as arguments to the post method. It
 also provides custom JSON serialization hooks [5] so we can forget about
 explicit serialization in handlers.

 So from these 2 choices I'm for Pecan.

 [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
 [2] https://flask-restful.readthedocs.org/en/0.3.0/
 [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
 [4] http://pecan.readthedocs.org/en/latest/rest.html
 [5] http://pecan.readthedocs.org/en/latest/jsonify.html


 P.


 On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:

  We had used Flask in the fuel-stats. It was easy and pleasant and all
 project requirements was satisfied. And I saw difficulties and workarounds
 with Pecan, when Nick integrated it into Nailgun.
 So +1 for Flask.


 On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com
 wrote:

 Michael, we already solved all issues I described, and I just don't
 want to solve them once again after moving to another framework. Also,
 I think, nothing of these wishes contradicts with good API design.

 On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
 krotsch...@gmail.com wrote:
  This sounds more like you need to pay off technical debt and clean up
 your
  API.
 
  Michael
 
  On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com
  wrote:
 
  Hello all,
 
  I actually tried to use Pecan and even created a couple of PoCs, but
  there due to historical reasons of how our API is organized it will
  take much more time to implement all workarounds we need to issues
  Pecan doesn't solve out of the box, like working with non-RESTful
  URLs, reverse URL lookup, returning custom body in 404 response,
  wrapping errors to JSON automatically, etc.
 
  As far as I see, each OpenStack project implements its own workarounds
  for these issues, but still it requires much less men and hours for us
  to move to Flask-Restful instead of Pecan, because all these problems
  are already solved there.
 
  BTW, I know a lot of pretty big projects using Flask (it's the second
  most popular Web framework after Django in Python Web community), they
  even have their own hall of fame:
  http://flask.pocoo.org/community/poweredby/ .
 
  On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote:
   On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
   Hi, Sebastian,
  
   Thank you for raising this topic again.
  
   [snip]
  
   Personally, I'd like to use Flask instead of Pecan, because first
 one
   is more production-ready tool and I like its design. But I believe
   this should be resolved by voting.
  
   Thanks,
   Igor
  
   On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
   skalinow...@mirantis.com wrote:
   Hi all,
  
   [snip explanation+history]
  
   Best,
   Sebastian
  
   Given that Pecan is used for other OpenStack projects and has plenty
 of
   builtin functionality (REST support, sessions, etc) I'd prefer it
 for a
   number of reasons.
  
   1) Wouldn't have to pull in plugins for standard (in Pecan) things
   2) Pecan is built for high traffic, where Flask is aimed at much
 smaller
   projects
   3) Already used by other OpenStack projects, so common patterns can
 be
   reused as oslo libs
  
   Of course, the Flask community seems larger (though the average flask
   project seems pretty small).
  
   I'm not sure what determines production readiness, but it seems to
 me
   like Fuel developers fall more in Pecan's target audience than in
   Flask's.
  
   My $0.02,
   Ryan
  
   --
   Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   

[openstack-dev] [python-novaclient] Status of novaclient V3

2014-12-03 Thread Andrey Kurilin
Thank for answers.
I sent a patch to novaclient : https://review.openstack.org/#/c/138694/

On Wed, Dec 3, 2014 at 1:59 PM, Christopher Yeoh cbky...@gmail.com
javascript:_e(%7B%7D,'cvml','cbky...@gmail.com'); wrote:




 On 3 Dec 2014, at 10:00 pm, Joe Gordon joe.gord...@gmail.com
 javascript:_e(%7B%7D,'cvml','joe.gord...@gmail.com'); wrote:



 On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin akuri...@mirantis.com
 javascript:_e(%7B%7D,'cvml','akuri...@mirantis.com'); wrote:

 Hi!

 While working on fixing wrong import in novaclient v3 shell, I have found
 that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
 are broken, because appropriate managers are missed from V3
 client(novaclient.V3.client.Client).

 Template of error is ERROR (AttributeError): 'Client' object has no
 attribute 'attr', where attr can be floating_ip_pools,
 floating_ip, security_groups, dns_entries and etc.

 I know that novaclient V3 is not finished yet, and I guess it will be not
 finished. So the main question is:
  What we should do with implemented code of novaclient V3 ? Should it be
 ported to novaclient V2.1 or it can be removed?


 I think it can be removed, as we are not going forward with the V3 API.
 But I will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.



 I think it can all just be removed now. We're going to need to enhance
 nova client to understand micro versions instead. But for now v2.1 should
 look just like v2

 Chris





 --
 Best regards,
 Andrey Kurilin.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.


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


Re: [openstack-dev] How to get openstack bugs data for research?

2014-12-03 Thread Louis Taylor
On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote:
 Hi, all
 
 I am a graduate student in Peking University, our lab do some research on 
 open source projects. 
 This is our introduction: https://passion-lab.org/
 
 Now we need openstack issues data for research, I found the issues list: 
 https://bugs.launchpad.net/openstack/
 I want to download the openstack issues data, Could anyone tell me how to 
 download the data? Or is there some link or API for download the data?
 
 And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ??is this 
 all? why so few?

That is the number of currently open bugs. There are 47733 bugs including
closed ones. Launchpad has an API [1], which can probably list the bugs filed
against a project.

[1] https://help.launchpad.net/API


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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Igor Kalnitsky
 I don't like that Flask uses a global request object [3].

Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.

 IMHO documentation is better written, and described a lot of possibilities of 
 modification

I disagree. Flask has rich documentation and more flexible, while
Pecan forces us to use only its patterns and code organization. There
are no possibilities to avoid this.

I'm afraid with Pecan we will have to rewrite a lot of code.

On Wed, Dec 3, 2014 at 2:21 PM, Kamil Sambor ksam...@mirantis.com wrote:
 Additionaly  to what Przemek wrote, also Pecan is released more often, IMHO
 documentation is better written, and described a lot of possibilities of
 modification, also as Lukasz wrote in previous thread that Pecan is used in
 openstack.

 So I'm also for Pecan

 Best regards,
 Kamil S.

 On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski
 pkamin...@mirantis.com wrote:

 The only useful paradigm to write in Flask is MethodView's for me [1]
 because decorators seem hard to refactor for large projects. Please look at
 adding URLs -- one has to additionally specify methods to match those from
 the MethodView -- this is code duplication and looks ugly.

 It seems though that Fask-RESTful [2] fixes this but then we're dependent
 on 2 projects.

 I don't like that Flask uses a global request object [3]. From Flask
 documentation

 Basically you can completely ignore that this is the case unless you are
 doing something like unit testing. You will notice that code which depends
 on a request object will suddenly break because there is no request object.
 The solution is creating a request object yourself and binding it to the
 context.

 Yeah, let's make testing even harder...

 Pecan looks better in respect of RESTful services [4].
 POST parameters are cleanly passed as arguments to the post method. It
 also provides custom JSON serialization hooks [5] so we can forget about
 explicit serialization in handlers.

 So from these 2 choices I'm for Pecan.

 [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
 [2] https://flask-restful.readthedocs.org/en/0.3.0/
 [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
 [4] http://pecan.readthedocs.org/en/latest/rest.html
 [5] http://pecan.readthedocs.org/en/latest/jsonify.html


 P.


 On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:

 We had used Flask in the fuel-stats. It was easy and pleasant and all
 project requirements was satisfied. And I saw difficulties and workarounds
 with Pecan, when Nick integrated it into Nailgun.
 So +1 for Flask.


 On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com
 wrote:

 Michael, we already solved all issues I described, and I just don't
 want to solve them once again after moving to another framework. Also,
 I think, nothing of these wishes contradicts with good API design.

 On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
 krotsch...@gmail.com wrote:
  This sounds more like you need to pay off technical debt and clean up
  your
  API.
 
  Michael
 
  On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com
  wrote:
 
  Hello all,
 
  I actually tried to use Pecan and even created a couple of PoCs, but
  there due to historical reasons of how our API is organized it will
  take much more time to implement all workarounds we need to issues
  Pecan doesn't solve out of the box, like working with non-RESTful
  URLs, reverse URL lookup, returning custom body in 404 response,
  wrapping errors to JSON automatically, etc.
 
  As far as I see, each OpenStack project implements its own workarounds
  for these issues, but still it requires much less men and hours for us
  to move to Flask-Restful instead of Pecan, because all these problems
  are already solved there.
 
  BTW, I know a lot of pretty big projects using Flask (it's the second
  most popular Web framework after Django in Python Web community), they
  even have their own hall of fame:
  http://flask.pocoo.org/community/poweredby/ .
 
  On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote:
   On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
   Hi, Sebastian,
  
   Thank you for raising this topic again.
  
   [snip]
  
   Personally, I'd like to use Flask instead of Pecan, because first
   one
   is more production-ready tool and I like its design. But I believe
   this should be resolved by voting.
  
   Thanks,
   Igor
  
   On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
   skalinow...@mirantis.com wrote:
   Hi all,
  
   [snip explanation+history]
  
   Best,
   Sebastian
  
   Given that Pecan is used for other OpenStack projects and has plenty
   of
   builtin functionality (REST support, sessions, etc) I'd prefer it
   for a
   number of reasons.
  
   1) Wouldn't have to pull in plugins for standard (in Pecan) things
   2) Pecan is built for high traffic, where Flask is aimed at much
   

Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Sebastian Kalinowski
2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:

  I don't like that Flask uses a global request object [3].

 Przemyslaw, actually Pecan does use global objects too. BTW, what's
 wrong with global objects? They are thread-safe in both Pecan and
 Flask.


To be fair, Pecan could also pass request and response explicit to method
[1]

[1] http://pecan.readthedocs.org/en/latest/contextlocals.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Przemyslaw Kaminski
Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as 
instance attributes just like in [1] but it's more of taste I guess.


[1] 
http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request


P.

On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:


2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com 
mailto:ikalnit...@mirantis.com:


 I don't like that Flask uses a global request object [3].

Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.


To be fair, Pecan could also pass request and response explicit to 
method [1]


[1] http://pecan.readthedocs.org/en/latest/contextlocals.html


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


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


Re: [openstack-dev] How to get openstack bugs data for research?

2014-12-03 Thread Angelo Matarazzo

Hi,
you could take a look at Stackalytics and how this website communicates 
with launchpad.


https://wiki.openstack.org/wiki/Stackalytics/HowToRun

Best,
Angelo

On 03/12/2014 13:41, Louis Taylor wrote:

On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote:

Hi, all

I am a graduate student in Peking University, our lab do some research on open 
source projects.
This is our introduction: https://passion-lab.org/

Now we need openstack issues data for research, I found the issues list: 
https://bugs.launchpad.net/openstack/
I want to download the openstack issues data, Could anyone tell me how to 
download the data? Or is there some link or API for download the data?

And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ??is this all? 
why so few?

That is the number of currently open bugs. There are 47733 bugs including
closed ones. Launchpad has an API [1], which can probably list the bugs filed
against a project.

[1] https://help.launchpad.net/API


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


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


Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

2014-12-03 Thread Rob Cresswell (rcresswe)
+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially 
slightly more useful, but looks messy and inconsistent, which I think outweighs 
the functionality.

Rob


On 2 Dec 2014, at 12:21, Timur Sufiev 
tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote:

Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by Bootstrap 
defaults) regarding their closing is to simply close the modal once user clicks 
somewhere outside of it (on the backdrop element below and around the modal). 
This is not very convenient for the modal forms containing a lot of input - 
when it is closed without a warning all the data the user has already provided 
is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 
'modal_backdrop' parameter to 'static', which means that forms are not closed 
once the user clicks on a backdrop, while it's still possible to close them by 
pressing 'Esc' or clicking on the 'X' link at the top right border of the form. 
Also the patch [1] allows to customize this behavior (between 'true'-current 
one/'false' - no backdrop element/'static') on a per-form basis.

What I didn't know at the moment I was uploading my patch is that David Lyle 
had been working on a similar solution [2] some time ago. It's a bit more 
elaborate than mine: if the user has already filled some some inputs in the 
form, then a confirmation dialog is shown, otherwise the form is silently 
dismissed as it happens now.

The whole point of writing about this in the ML is to gather opinions which 
approach is better:
* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be rebased to 
the current codebase).

What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but better late 
than never :).

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

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Nikolay Markov
Dear colleagues,

We surely may take into account the beauty of the code in both cases
(as for me, Pecan loses here, too) and argue about global objects and
stuff, but I'm trying to look at amount of men and time we need to
move to one of these frameworks.

I wouldn't say our API is badly designed, nevertheless Pecan still has
a lot of issues needed to be fixed by hand. We don't want to spend
much time to this task, because it is mostly the matter of convenience
and simplicity for developers, it changes nothing in features or
customer-facing behavior.

And if we take in account the amount of hours we need to move, based
on my experience Flask definitely wins here.

On Wed, Dec 3, 2014 at 4:03 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:

 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:

  I don't like that Flask uses a global request object [3].

 Przemyslaw, actually Pecan does use global objects too. BTW, what's
 wrong with global objects? They are thread-safe in both Pecan and
 Flask.


 To be fair, Pecan could also pass request and response explicit to method
 [1]

 [1] http://pecan.readthedocs.org/en/latest/contextlocals.html

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




-- 
Best regards,
Nick Markov

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


Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

2014-12-03 Thread Mooney, Sean K
Hi 

Unfortunately a flavor + aggregate is not enough for our use case as it is 
still possible for the tenant to misconfigure a vm.

The edge case not covered by flavor + aggregate that we are trying to prevent 
is as follows.

The operator creates an aggregate containing the  nodes that require all VMs to 
use large pages.
The operator creates flavors with and without memory backing specified.

The tenant selects the aggregate containing nodes that only supports hugepages 
and a flavor that requires small or any.
Or 
The tenant selects a flavor that requires small or any and does not select an 
aggregate.

In both cases because the nodes may have non huge page memory available, it is 
possible to schedule
A vm that will not use large pages to a node that requires large pages to be 
used.

If this happens the behavior is undefined.
The vm may boot and have not network connectivity in the case of vhost-user
The vm may fail to boot  or it may boot in some other error state.

It would be possible however to introduce a new filter 
(AggregateMemoryBackingFilter)

The AggregateMemoryBackingFilter would work as follows.
The AggregateMemoryBackingFilter  will compare the extra specifications 
associated with the instance and enforces the constraints set in the aggregate 
metadata.

A new MemoryBacking attribute will be added to the aggregate metadata.
The MemoryBacking  attribute can be set to 1 or more of the flowing: 
small,large,4,2048,1048576
Syntax is SizeA,SizeB e.g. 2048,1048576

If small is set then host will only be passed if the vm requests small or 4k 
pages.
If large is set then host will only be passed if the vm requests  2MB or 1GB.
If the MemoryBacking element is not set for an aggregate the 
AggregateMemoryBackingFilter  will pass all hosts

With this new filter the (flavor or image properties) + aggregate approach 
would work for all driver not just libvirt.

If this alternative is preferred I can resubmit as a new blueprint and mark the 
old blueprint as superseded.

Regards 
Sean.

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Wednesday, December 3, 2014 10:13 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of 
mempage sizes

On Wed, Dec 03, 2014 at 10:03:06AM +0100, Sahid Orentino Ferdjaoui wrote:
 On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote:
  Hi all
  
  I have submitted a small blueprint to allow filtering of available 
  memory pages Reported by libvirt.
 
 Can you address this with aggregate? this will also avoid to do 
 something specific in the driver libvirt. Which will have to be 
 extended to other drivers at the end.

Agreed, I think you can address this by setting up host aggregates and then 
using setting the desired page size on the flavour.

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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


[openstack-dev] [Nova][Cinder] Operations: adding new nodes in disabled state, allowed for test tenant only

2014-12-03 Thread Mike Scherbakov
Hi all,
enable_new_services in nova.conf seems to allow add new compute nodes in
disabled state:
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
so it would allow to check everything first, before allowing production
workloads host a VM on it. I've filed a bug to Fuel to use this by default
when we scale up the env (add more computes) [1].

A few questions:

   1. can we somehow enable compute service for test tenant first? So cloud
   administrator would be able to run test VMs on the node, and after ensuring
   that everything is fine - to enable service for all tenants
   2. What about Cinder? Is there a similar option / ability?
   3. What about other OpenStack projects?

What is your opinion, how we should approach the problem (if there is a
problem)?

[1] https://bugs.launchpad.net/fuel/+bug/1398817
-- 
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

2014-12-03 Thread Tomas Sedovic

On 12/03/2014 11:11 AM, Steven Hardy wrote:

Hi all,

Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent puppet-software-config implementations mature (as well as
improving overcloud updates via heat).

Since Tomas's patch landed[1] to enable --no-mergepy in
tripleo-heat-templates, it's become apparent that frequently patches are
submitted which only update overcloud-source.yaml, so I've been trying to
catch these and ask for a corresponding change to e.g controller.yaml.



You beat me to this. Thanks for writing it up!


This raises the following questions:

1. Is it reasonable to -1 a patch and ask folks to update in both places?


I'm in favour.


2. How are we going to handle this duplication and divergence?


I'm not sure we can. get_file doesn't handle structured data and I don't 
know what else we can do. Maybe we could split out all SoftwareConfig 
resources to separate files (like Dan did in [nova config])? But the 
SoftwareDeployments, nova servers, etc. have a different structure.


[nova config] https://review.openstack.org/#/c/130303/


3. What's the status of getting gating CI on the --no-mergepy templates?


Derek, can we add a job that's identical to 
check-tripleo-ironic-overcloud-{f20,precise}-nonha except it passes 
--no-mergepy to devtest.sh?



4. What barriers exist (now that I've implemented[2] the eliding functionality
requested[3] for ResourceGroup) to moving to the --no-mergepy
implementation by default?


I'm about to post a patch that moves us from ResourceGroup to 
AutoScalingGroup (for rolling updates), which is going to complicate 
this a bit.


Barring that, I think you've identified all the requirements: CI job, 
parity between the merge/non-merge templates and a process that 
maintains it going forward (or puts the old ones in a maintanence-only 
mode).


Anyone have anything else that's missing?



Thanks for any clarification you can provide! :)

Steve

[1] https://review.openstack.org/#/c/123100/
[2] https://review.openstack.org/#/c/128365/
[3] https://review.openstack.org/#/c/123713/

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





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


Re: [openstack-dev] [Nova][Cinder] Operations: adding new nodes in disabled state, allowed for test tenant only

2014-12-03 Thread Ivan Kolodyazhny
Hi Mike,

We've got the similar option in Cinder too:
https://github.com/openstack/cinder/blob/master/cinder/db/api.py#L58


Regards,
Ivan Kolodyazhny

On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 Hi all,
 enable_new_services in nova.conf seems to allow add new compute nodes in
 disabled state:

 https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
 so it would allow to check everything first, before allowing production
 workloads host a VM on it. I've filed a bug to Fuel to use this by default
 when we scale up the env (add more computes) [1].

 A few questions:

1. can we somehow enable compute service for test tenant first? So
cloud administrator would be able to run test VMs on the node, and after
ensuring that everything is fine - to enable service for all tenants
2. What about Cinder? Is there a similar option / ability?
3. What about other OpenStack projects?

 What is your opinion, how we should approach the problem (if there is a
 problem)?

 [1] https://bugs.launchpad.net/fuel/+bug/1398817
 --
 Mike Scherbakov
 #mihgen


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


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


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Kyle Mestery
Mathieu:

The peer review proposal was NOT about removing core reviewers, that
is very clear in the proposal. The peer review proposal was about
deciding as a team what it means to be a core reviewer, and ensuring
core reviewers are doing that. I still plan to do try out the peer
review process in the coming weeks. But even with that process,
reviews are the main thing a core reviewer must be doing. If you're
not doing reviews upstream, especially for long stretches, you're not
really a core reviewer.

Thanks,
Kyle

On Wed, Dec 3, 2014 at 4:41 AM, Mathieu Rohon mathieu.ro...@gmail.com wrote:
 Hi all,

 It seems that a process with a survey for neutron core
 election/removal was about to take place [1]. Has it been applied for
 this proposal?
 This proposal has been hardly discussed during neutron meetings
 [2][3]. Many cores agree that the number of reviews shouldn't be the
 only metrics. And this statement is reflected in the Survey Questions.
 So I'm surprised to see such a proposal based on stackalitics figures.

 [1]https://etherpad.openstack.org/p/neutron-peer-review
 [2]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-13-21.02.log.html
 [3]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-21-14.00.log.html

 On Wed, Dec 3, 2014 at 9:44 AM, Oleg Bondarev obonda...@mirantis.com wrote:
 +1! Congrats, Henry and Kevin!

 On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery mest...@mestery.com wrote:

 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.

 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.

 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.

 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/180

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



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


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

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


Re: [openstack-dev] oslo.concurrency 0.3.0 released

2014-12-03 Thread Doug Hellmann

On Dec 2, 2014, at 7:48 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:

 
 
 On 12/2/2014 12:33 PM, Ben Nemec wrote:
 We've discovered a couple of problems as a result of this release.  pep8
 in most/all of the projects using oslo.concurrency is failing due to the
 move out of the oslo namespace package and the fact that hacking doesn't
 know how to handle it, and nova unit tests are failing due to a problem
 with the way some mocking was done.
 
 Fixes for both of these problems are in progress and should hopefully be
 available soon.
 
 -Ben
 
 On 12/02/2014 10:29 AM, Ben Nemec wrote:
 The Oslo team is pleased to announce the release of oslo.concurrency 0.3.0.
 
 This release includes a number of fixes for problems found during the
 initial adoptions of the library, as well as some functionality
 improvements.
 
 For more details, please see the git log history below and
 https://launchpad.net/oslo.concurrency/+milestone/0.3.0
 
  Please report issues through launchpad:
 https://launchpad.net/oslo.concurrency
 
 openstack/oslo.concurrency  0.2.0..HEAD
 
 54c84da Add external lock fixture
 19f07c6 Add a TODO for retrying pull request #20
 46c836e Allow the lock delay to be provided
 3bda65c Allow for providing a customized semaphore container
 656f908 Move locale files to proper place
 faa30f8 Flesh out the README
 bca4a0d Move out of the oslo namespace package
 58de317 Improve testing in py3 environment
 fa52a63 Only modify autoindex.rst if it exists
 63e618b Imported Translations from Transifex
 d5ea62c lockutils-wrapper cleanup
 78ba143 Don't use variables that aren't initialized
 
   diffstat (except docs and test files):
 
  .gitignore |   1 +
  .testr.conf|   2 +-
  README.rst |   4 +-
  .../locale/en_GB/LC_MESSAGES/oslo.concurrency.po   |  16 +-
  oslo.concurrency/locale/oslo.concurrency.pot   |  16 +-
  oslo/concurrency/__init__.py   |  29 ++
  oslo/concurrency/_i18n.py  |  32 --
  oslo/concurrency/fixture/__init__.py   |  13 +
  oslo/concurrency/fixture/lockutils.py  |  51 --
  oslo/concurrency/lockutils.py  | 376 --
  oslo/concurrency/openstack/__init__.py |   0
  oslo/concurrency/openstack/common/__init__.py  |   0
  oslo/concurrency/openstack/common/fileutils.py | 146 --
  oslo/concurrency/opts.py   |  45 --
  oslo/concurrency/processutils.py   | 340 
  oslo_concurrency/__init__.py   |   0
  oslo_concurrency/_i18n.py  |  32 ++
  oslo_concurrency/fixture/__init__.py   |   0
  oslo_concurrency/fixture/lockutils.py  |  76 +++
  oslo_concurrency/lockutils.py  | 502 ++
  oslo_concurrency/openstack/__init__.py |   0
  oslo_concurrency/openstack/common/__init__.py  |   0
  oslo_concurrency/openstack/common/fileutils.py | 146 ++
  oslo_concurrency/opts.py   |  45 ++
  oslo_concurrency/processutils.py   | 340 
  requirements-py3.txt   |   1 +
  requirements.txt   |   1 +
  setup.cfg  |   9 +-
  tests/test_lockutils.py| 575
 
  tests/test_processutils.py | 519
 +++
  tests/test_warning.py  |  29 ++
  tests/unit/__init__.py |   0
  tests/unit/test_lockutils.py   | 543
 ---
  tests/unit/test_lockutils_eventlet.py  |  59 ---
  tests/unit/test_processutils.py| 518 --
  tox.ini|   8 +-
  42 files changed, 3515 insertions(+), 2135 deletions(-)
 
   Requirements updates:
 
  diff --git a/requirements-py3.txt b/requirements-py3.txt
  index b1a8722..a27b434 100644
  --- a/requirements-py3.txt
  +++ b/requirements-py3.txt
  @@ -13,0 +14 @@ six=1.7.0
  +retrying=1.2.2,!=1.3.0 # Apache-2.0
  diff --git a/requirements.txt b/requirements.txt
  index b1a8722..a27b434 100644
  --- a/requirements.txt
  +++ b/requirements.txt
  @@ -13,0 +14 @@ six=1.7.0
  +retrying=1.2.2,!=1.3.0 # Apache-2.0
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 Was a bug reported for the nova unit tests that were mocking out 
 external_lock in lockutils?  I didn't see one so I opened a bug [1] and wrote 
 the elastic-recheck query against that.  I'm working on fixing the tests in 
 the meantime but I'll gladly stop if someone else has a fix up for review.
 
 

Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Sebastian Kalinowski
I never used Flask and Pecan personally so I can only rely from what I saw
in this thread and in both projects docs.
I don't have strong opinion, just want to share some thoughts.

I think that as a part of OpenStack community we should stick with Pecan
and because of the same reason
we can have a bigger impact how future versions of Pecan will look.

If we will choose Flask I see is that we not only need to choose a
framework, but also decide which
extension will be used to provide REST support (I do not like that we just
assume flask-restful will be used).

To be honest right now I'm more convinced that we should choose Pecan.


2014-12-03 14:22 GMT+01:00 Nikolay Markov nmar...@mirantis.com:

 Dear colleagues,

 We surely may take into account the beauty of the code in both cases
 (as for me, Pecan loses here, too) and argue about global objects and
 stuff, but I'm trying to look at amount of men and time we need to
 move to one of these frameworks.


Agree that we should look on the man-hours for implementation, but I think
that it is as
important as all the small things like global object etc. since they could
make future development
painful or pleasant.


 I wouldn't say our API is badly designed, nevertheless Pecan still has
 a lot of issues needed to be fixed by hand. We don't want to spend
 much time to this task, because it is mostly the matter of convenience
 and simplicity for developers, it changes nothing in features or
 customer-facing behavior.

 And if we take in account the amount of hours we need to move, based
 on my experience Flask definitely wins here.


Cannot we reuse the PoC ([1]) with Pecan that was created? There was a lot
of work put into that piece of code.

[1] https://review.openstack.org/#/c/99069/6
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Roman Prykhodchenko
I don’t have an opinion for now but do have some thoughts instead.

We use Pecan in Ironic.
I could say that it’s pretty nice when one needs to make something simple but 
requires some manual job to be done in more or less sophisticated cases.
On the other hand we have that the Pecan team is quire agile and open to other 
developers so we were able to merge our patches without any problems.

However, if there is a framework that fits Nailgun's needs without being 
patched, that may be easier for us to just use it.

There’s a political side of the question as well but I’d rather touch it only 
if both Flask and Pecan have the same pros and cons.


- romcheg

 On 03 Dec 2014, at 14:22, Przemyslaw Kaminski pkamin...@mirantis.com wrote:
 
 Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as 
 instance attributes just like in [1] but it's more of taste I guess.
 
 [1] 
 http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request
  
 http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request
 
 P.
 
 On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:
 
 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com 
 mailto:ikalnit...@mirantis.com:
  I don't like that Flask uses a global request object [3].
 
 Przemyslaw, actually Pecan does use global objects too. BTW, what's
 wrong with global objects? They are thread-safe in both Pecan and
 Flask.
 
 To be fair, Pecan could also pass request and response explicit to method [1]
 
 [1] http://pecan.readthedocs.org/en/latest/contextlocals.html 
 http://pecan.readthedocs.org/en/latest/contextlocals.html
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


[openstack-dev] oslo.db 1.2.0 released

2014-12-03 Thread Victor Sergeyev
Hello Folks

The Oslo team is pleased to announce the release of oslo.db 1.2.0.

This release includes several bug fixes as well as many other changes:

$ git log --abbrev-commit --pretty=oneline --no-merges 1.1.0..1.2.0
f740e3b Imported Translations from Transifex
ca1ad56 Make test_models pass on py3
549ba15 Repair include_object to accommodate new objects
10e8d15 Add table name to foreign keys diff
ddd11df Updated from global requirements
2269848 Handle Galera deadlock on SELECT FOR UPDATE
4b2058b Add exception filter for _sqlite_dupe_key_error
b6d363d Add info on how to run unit tests
7f755bf Ensure is_backend_avail() doesn't leave open connections
c54d3a9 Updated from global requirements
2099177 Add pbr to installation requirements
135701b Fix python3.x scoping issues with removed 'de' variable

Thanks Doug Hellmann, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman
Podoliaka for contributing to this release.

For more details, please see the git log history below and
https://launchpad.net/oslo.db/+milestone/1.2.0
Please report issues through launchpad: https://launchpad.net/oslo.db


  diffstat (except docs and test files):

 CONTRIBUTING.rst   | 39 +++
 .../locale/en_GB/LC_MESSAGES/oslo.db-log-info.po   |  8 ++--
 oslo.db/locale/fr/LC_MESSAGES/oslo.db-log-error.po | 56
++
 oslo.db/locale/fr/LC_MESSAGES/oslo.db-log-info.po  | 33 +
 .../locale/fr/LC_MESSAGES/oslo.db-log-warning.po   | 40 
 oslo/db/sqlalchemy/exc_filters.py  | 21 ++--
 oslo/db/sqlalchemy/session.py  | 10 ++--
 oslo/db/sqlalchemy/test_migrations.py  |  2 +-
 oslo/db/sqlalchemy/utils.py|  3 +-
 requirements.txt   |  1 +
 test-requirements-py2.txt  |  2 +-
 test-requirements-py3.txt  |  2 +-
 tests/sqlalchemy/test_exc_filters.py   | 13 +
 tests/sqlalchemy/test_migrations.py|  7 ++-
 tests/sqlalchemy/test_models.py| 31 +---
 15 files changed, 233 insertions(+), 35 deletions(-)

  Requirements updates:

 diff --git a/requirements.txt b/requirements.txt
 index cc50660..f8a0d8c 100644
 --- a/requirements.txt
 +++ b/requirements.txt
 @@ -4,0 +5 @@
 +pbr=0.6,!=0.7,1.0
 diff --git a/test-requirements-py2.txt b/test-requirements-py2.txt
 index 13cea90..ac5c18a 100644
 --- a/test-requirements-py2.txt
 +++ b/test-requirements-py2.txt
 @@ -19 +19 @@ testscenarios=0.4
 -testtools=0.9.36
 +testtools=0.9.36,!=1.2.0
 diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
 index 4f195da..58b9a3d 100644
 --- a/test-requirements-py3.txt
 +++ b/test-requirements-py3.txt
 @@ -18 +18 @@ testscenarios=0.4
 -testtools=0.9.36
 +testtools=0.9.36,!=1.2.0
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [qa] branchless tempest and the use of 'all' for extensions in tempest.conf

2014-12-03 Thread David Kranz
A recent proposed test to tempest was making explicit calls to the nova 
extension discovery api rather than using test.requires_ext. The reason 
was because we configure tempest.conf in the gate as 'all' for 
extensions, and the test involved an extension that was new in Juno. So 
the icehouse run failed. Since the methodology of branchless tempest 
requires that new conf flags be added for new features, we should stop 
having devstack configure with 'all'. Does any one disagree with that, 
or have a better solution?


 -David

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Jay Pipes

On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:

I think that as a part of OpenStack community we should stick with
Pecan and because of the same reason we can have a bigger impact how
future versions of Pecan will look.


Yes, this. ++

-jay

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Nikolay Markov
It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle jump from
the cliff if everyone does works well in such cases.

On Wed, Dec 3, 2014 at 5:53 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:

 I think that as a part of OpenStack community we should stick with
 Pecan and because of the same reason we can have a bigger impact how
 future versions of Pecan will look.


 Yes, this. ++

 -jay


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



-- 
Best regards,
Nick Markov

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Roman Prykhodchenko
Being able to make some impact on Pecan is an advantage for sure. But there are 
other aspects in choosing a web framework and I’d rather discuss them.
Let’s not think about what is used in other OpenStack projects for a moment and 
discuss technical details.


 On 03 Dec 2014, at 15:53, Jay Pipes jaypi...@gmail.com wrote:
 
 On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:
 I think that as a part of OpenStack community we should stick with
 Pecan and because of the same reason we can have a bigger impact how
 future versions of Pecan will look.
 
 Yes, this. ++
 
 -jay
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


[openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

2014-12-03 Thread Sean Dague
We've hit two interesting issues this week around multiple projects
installing into the paste pipeline of a server.

1) the pkg_resources explosion in grenade. Basically ceilometer modified
swift paste.ini to add it's own code into swift (that's part of normal
ceilometer install in devstack -
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381

This meant when we upgraded and started swift, it turns out that we're
actually running old ceilometer code. A requirements mismatch caused an
explosion (which we've since worked around), however demonstrates a
clear problem with installing code in another project's pipeline.

2) keystone is having issues dropping XML api support. It turns out that
parts of it's paste pipeline are actually provided by keystone
middleware, which means that keystone can't provide a sane this is not
supported message in a proxy class for older paste config files.


I'm wondering if we need to be a lot more strict about paste
manipulations, and require that all classes in the paste pipeline are
owned by the project in question. They could be proxy classes to
external code, but at least that would allow the project to smooth out
upgrades. Otherwise everything with code in the paste.ini needs to be
atomically upgraded, and we're trying to get away from atomic upgrades.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Jay Pipes

On 12/03/2014 10:16 AM, Nikolay Markov wrote:

It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle jump from
the cliff if everyone does works well in such cases.


This is part of why the Fuel development team is viewed as not working 
with the OpenStack community in many ways. The Fuel team is doing a 
remarkable job in changing previously-all-internal-to-Mirantis 
communication patterns to instead be on a transparent basis in the 
mailing lists and on IRC. I sincerely applaud the Fuel team for that.


However, the OpenStack community is also about a shared set of tools, 
development methodologies, and common perspectives. It's expected that 
when you have an OpenStack REST API project, that you try to use the 
tools that the shared community uses, builds, and supports. Otherwise, 
you aren't being a team player.


In the past, certain teams have chosen to use something other than Pecan 
due to technical reasons. For example, Zaqar's team chose to use the 
Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a 
data API, not a control API, and raw performance is critical to the 
project's API endpoint). This is, incidentally, why the Swift team chose 
to use its swob framework over Webob (which Pecan uses).


However, the reason that these were chosen was definitely not it 
doesn't support the coding patterns I like. There's something that 
comes from being a team player. And one of those things is going with 
the flow when there isn't a real technical reason not to. All of us can 
and do find things we don't like about *all* of the projects that we 
work on. The difference between team players and non-team players is 
that team players strongly weigh their decisions and opinions based on 
what the team is doing and how the team can improve.


Best,
-jay

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


Re: [openstack-dev] [qa] branchless tempest and the use of 'all' for extensions in tempest.conf

2014-12-03 Thread Matthew Treinish
On Wed, Dec 03, 2014 at 09:43:41AM -0500, David Kranz wrote:
 A recent proposed test to tempest was making explicit calls to the nova
 extension discovery api rather than using test.requires_ext. The reason was
 because we configure tempest.conf in the gate as 'all' for extensions, and
 the test involved an extension that was new in Juno. So the icehouse run
 failed. Since the methodology of branchless tempest requires that new conf
 flags be added for new features, we should stop having devstack configure
 with 'all'. Does any one disagree with that, or have a better solution?
 


There is a BP in progress for doing this:

https://blueprints.launchpad.net/tempest/+spec/branchless-tempest-extensions

The patches are in progress here:

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

and

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


The solution is that we use 'all' on master devstack, but we want to have a
static list set for the stable branch devstacks. Until the bp is finished
patches that add tests which use new extensions will be blocked.

-Matt Treinish


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


[openstack-dev] [NFV][Telco] Use case discussion

2014-12-03 Thread Calum Loudon
Hello all

Unfortunately, my complete inability to process daylight savings time changes
meant I was one hour late for today's TelcoWG meeting so couldn't participate
in the discussion of use cases, including the one I submitted on Session Border
Control.  Thanks to eavesdrop.openstack.org I've been able to catch up.

Just to chip in to the discussion, I agree entirely that we should try to keep
the wiki vendor neutral, but at the same time I think use cases based on real
world implementations (which could of course be open source rather than from a
vendor) are more powerful illustrations for the Dev community of why particular 
bps are needed than the more abstract presentation of use cases in the ETSI
docs, which are aimed at a different purpose.  I don't think it's particularly
convincing or compelling as a developer to hear that some theoretical
implementation of a network function you may have never heard of might need
feature X, whereas understanding that there are real products out there that
genuinely depend on it brings the requirement home.  One of the goals of this
group is to help the rest of the OpenStack community understand NFV, and I
think concrete beats abstract for that.

However, as Steve noted, I did try to draw out general characteristics and 
relate them to specific gaps and requirements and I think that's important to
try to draw as much as possible that is general and vendor-neutral from specific
cases.

Someone asked about ability to test; I imagine most people in this group will
know of the OPNFV initiative, and they are working to put together test 
frameworks
and cases which may include real VNFs, including this specific Perimeta example.

regards

Calum

Calum Loudon 
Director, Architecture
+44 (0)208 366 1177
 
METASWITCH NETWORKS 
THE BRAINS OF THE NEW GLOBAL NETWORK
www.metaswitch.com




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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Nikolay Markov
 However, the OpenStack community is also about a shared set of tools,
 development methodologies, and common perspectives.

I completely agree with you, Jay, but the same principle may be
applied much wider. Why Openstack Community decided to use its own
unstable project instead of existing solution, which is widely used in
Python community? To avoid being a team player? Or, at least, why it's
recommended way even if it doesn't provide the same features other
frameworks have for a long time already? I mean, there is no doubt
everyone would use stable and technically advanced tool, but imposing
everyone to use it by force with a simple hope that it'll become
better from this is usually a bad approach.

I personally would surely contribute to Pecan in case we decide to use
it and there will be some gaps and uncovered cases. I'm just curious,
does it worth it?

On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/03/2014 10:16 AM, Nikolay Markov wrote:

 It would be great to look at some obvious points where Pecan is better
 than Flask despite of the fact that it's used by the community. I
 still don't see a single and I don't think the principle jump from
 the cliff if everyone does works well in such cases.


 This is part of why the Fuel development team is viewed as not working with
 the OpenStack community in many ways. The Fuel team is doing a remarkable
 job in changing previously-all-internal-to-Mirantis communication patterns
 to instead be on a transparent basis in the mailing lists and on IRC. I
 sincerely applaud the Fuel team for that.

 However, the OpenStack community is also about a shared set of tools,
 development methodologies, and common perspectives. It's expected that when
 you have an OpenStack REST API project, that you try to use the tools that
 the shared community uses, builds, and supports. Otherwise, you aren't being
 a team player.

 In the past, certain teams have chosen to use something other than Pecan due
 to technical reasons. For example, Zaqar's team chose to use the Falcon
 framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
 not a control API, and raw performance is critical to the project's API
 endpoint). This is, incidentally, why the Swift team chose to use its swob
 framework over Webob (which Pecan uses).

 However, the reason that these were chosen was definitely not it doesn't
 support the coding patterns I like. There's something that comes from being
 a team player. And one of those things is going with the flow when there
 isn't a real technical reason not to. All of us can and do find things we
 don't like about *all* of the projects that we work on. The difference
 between team players and non-team players is that team players strongly
 weigh their decisions and opinions based on what the team is doing and how
 the team can improve.

 Best,

 -jay

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



-- 
Best regards,
Nick Markov

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


[openstack-dev] [QA] Meeting Thursday December 4th at 17:00 UTC

2014-12-03 Thread Matthew Treinish
Hi everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, December 4th at 17:00 UTC in the #openstack-meeting
channel.

The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

It's also worth noting that a few weeks ago we started having a regular
dedicated Devstack topic during the meetings. So if anyone is interested in
Devstack development please join the meetings to be a part of the discussion.

To help people figure out what time 17:00 UTC is in other timezones tomorrow's
meeting will be at:

12:00 EST
02:00 JST
03:30 ACDT
18:00 CET
11:00 CST
9:00 PST

-Matt Treinish


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


Re: [openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

2014-12-03 Thread Lance Bragstad
On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague s...@dague.net wrote:

 We've hit two interesting issues this week around multiple projects
 installing into the paste pipeline of a server.

 1) the pkg_resources explosion in grenade. Basically ceilometer modified
 swift paste.ini to add it's own code into swift (that's part of normal
 ceilometer install in devstack -
 https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381

 This meant when we upgraded and started swift, it turns out that we're
 actually running old ceilometer code. A requirements mismatch caused an
 explosion (which we've since worked around), however demonstrates a
 clear problem with installing code in another project's pipeline.

 2) keystone is having issues dropping XML api support. It turns out that
 parts of it's paste pipeline are actually provided by keystone
 middleware, which means that keystone can't provide a sane this is not
 supported message in a proxy class for older paste config files.


I made an attempt to capture some of the information on the specific
grenade case we were hitting for XML removal in a bug report [1]. We can
keep the classes in keystone/middleware/core.py as a workaround for now
with essentially another deprecation message, but at some point we should
pull the plug on defining XmlBodyMiddleware in our keystone-paste.ini [2]
as it won't do anything anyway and shouldn't be in the configuration. Since
this deals with a configuration change, this could always break a
customer. What criteria should we follow for cases like this?

From visiting with Sean in -qa, typically service configurations don't
change for the grenade target on upgrade, but if we have to make a change
on upgrade (to clean out old cruft for example), how do we go about that?

[1] https://bugs.launchpad.net/grenade/+bug/1398833
[2]
https://github.com/openstack/keystone/blob/d82a3caa329e9b42c588e28f694bf847261d63d1/etc/keystone-paste.ini#L15-L22



 I'm wondering if we need to be a lot more strict about paste
 manipulations, and require that all classes in the paste pipeline are
 owned by the project in question. They could be proxy classes to
 external code, but at least that would allow the project to smooth out
 upgrades. Otherwise everything with code in the paste.ini needs to be
 atomically upgraded, and we're trying to get away from atomic upgrades.

 -Sean

 --
 Sean Dague
 http://dague.net

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

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Nikolay Markov
A month or two ago I started gathering differencies between Flask and
Pecan, let's take a look at technical details. Maybe there are some
things that are already fixed in current versions of Pecan, feel free
to comment. 
https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing

On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov nmar...@mirantis.com wrote:
 However, the OpenStack community is also about a shared set of tools,
 development methodologies, and common perspectives.

 I completely agree with you, Jay, but the same principle may be
 applied much wider. Why Openstack Community decided to use its own
 unstable project instead of existing solution, which is widely used in
 Python community? To avoid being a team player? Or, at least, why it's
 recommended way even if it doesn't provide the same features other
 frameworks have for a long time already? I mean, there is no doubt
 everyone would use stable and technically advanced tool, but imposing
 everyone to use it by force with a simple hope that it'll become
 better from this is usually a bad approach.

 I personally would surely contribute to Pecan in case we decide to use
 it and there will be some gaps and uncovered cases. I'm just curious,
 does it worth it?

 On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/03/2014 10:16 AM, Nikolay Markov wrote:

 It would be great to look at some obvious points where Pecan is better
 than Flask despite of the fact that it's used by the community. I
 still don't see a single and I don't think the principle jump from
 the cliff if everyone does works well in such cases.


 This is part of why the Fuel development team is viewed as not working with
 the OpenStack community in many ways. The Fuel team is doing a remarkable
 job in changing previously-all-internal-to-Mirantis communication patterns
 to instead be on a transparent basis in the mailing lists and on IRC. I
 sincerely applaud the Fuel team for that.

 However, the OpenStack community is also about a shared set of tools,
 development methodologies, and common perspectives. It's expected that when
 you have an OpenStack REST API project, that you try to use the tools that
 the shared community uses, builds, and supports. Otherwise, you aren't being
 a team player.

 In the past, certain teams have chosen to use something other than Pecan due
 to technical reasons. For example, Zaqar's team chose to use the Falcon
 framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
 not a control API, and raw performance is critical to the project's API
 endpoint). This is, incidentally, why the Swift team chose to use its swob
 framework over Webob (which Pecan uses).

 However, the reason that these were chosen was definitely not it doesn't
 support the coding patterns I like. There's something that comes from being
 a team player. And one of those things is going with the flow when there
 isn't a real technical reason not to. All of us can and do find things we
 don't like about *all* of the projects that we work on. The difference
 between team players and non-team players is that team players strongly
 weigh their decisions and opinions based on what the team is doing and how
 the team can improve.

 Best,

 -jay

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



 --
 Best regards,
 Nick Markov



-- 
Best regards,
Nick Markov

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


[openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-03 Thread Neil Jerram
Hi there.  I've been looking into a tricky point, and hope I can succeed
in expressing it clearly here...

I believe it is the case, even when using a committedly Neutron-based
networking implementation, that Nova is still involved a little bit in
the networking setup logic.  Specifically I mean the plug() and unplug()
operations, whose implementations are provided by *VIFDriver classes for
the various possible hypervisors.

For example, for the libvirt hypervisor, LibvirtGenericVIFDriver
typically implements plug() by calling create_tap_dev() to create the
TAP device, and then plugging into some form of L2 bridge.

Does this logic actually have to be in Nova?  For a Neutron-based
networking implementation, it seems to me that it should also be
possible to do this in a Neutron agent (obviously running on the compute
node concerned), and that - if so - that would be preferable because it
would enable more Neutron-based experimentation without having to modify
any Nova code.

Specifically, therefore, I wonder if we could/should add a do-nothing
value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement
plug()/unplug() for that value to do nothing at all, leaving all setup
to the Neutron agent?  And then hopefully it should never be necessary
to introduce further Nova VIF type support ever again...

Am I missing something that really makes that not fly?  Two possible
objections occurs to me, as follows, but I think they're both
surmountable.

1. When the port is created in the Neutron DB, and handled (bound etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.

   I think this is still OK because Neutron knows anyway what the TAP
   device name _will_ be, even if the actual TAP device hasn't been
   created yet.

2. With some agent implementations, there isn't a direct instruction,
   from the plugin to the agent, to say now look after this VM /
   port.  Instead the agents polls the OS for new TAP devices
   appearing.  Clearly, then, if there isn't something other than the
   agent that creates the TAP device, any logic in the agent will never
   be triggered.

   This is certain a problem.  For new networking experimentation,
   however, we can write agent code that is directly instructed by the
   plugin, and hence (a) doesn't need to poll (b) doesn't require the
   TAP device to have been previously created by Nova - which I'd argue
   is preferable.

Thoughts?

(FYI my context is that I've been working on a networking implementation
where the TAP device to/from a VM should _not_ be plugged into a bridge
- and for that I've had to make a Nova change even though my team's aim
was to do the whole thing in Neutron.

I've proposed a spec for the Nova change that plugs a TAP interface
without bridging it (https://review.openstack.org/#/c/130732/), but that
set me wondering about this wider question of whether such Nova changes
should still be necessary...)

Many thanks,
 Neil

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


Re: [openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

2014-12-03 Thread Sean Dague
On 12/03/2014 10:57 AM, Lance Bragstad wrote:
 
 
 On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague s...@dague.net
 mailto:s...@dague.net wrote:
 
 We've hit two interesting issues this week around multiple projects
 installing into the paste pipeline of a server.
 
 1) the pkg_resources explosion in grenade. Basically ceilometer modified
 swift paste.ini to add it's own code into swift (that's part of normal
 ceilometer install in devstack -
 https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381
 
 This meant when we upgraded and started swift, it turns out that we're
 actually running old ceilometer code. A requirements mismatch caused an
 explosion (which we've since worked around), however demonstrates a
 clear problem with installing code in another project's pipeline.
 
 2) keystone is having issues dropping XML api support. It turns out that
 parts of it's paste pipeline are actually provided by keystone
 middleware, which means that keystone can't provide a sane this is not
 supported message in a proxy class for older paste config files.
 
 
 I made an attempt to capture some of the information on the specific
 grenade case we were hitting for XML removal in a bug report [1]. We can
 keep the classes in keystone/middleware/core.py as a workaround for now
 with essentially another deprecation message, but at some point we
 should pull the plug on defining XmlBodyMiddleware in our
 keystone-paste.ini [2] as it won't do anything anyway and shouldn't be
 in the configuration. Since this deals with a configuration change, this
 could always break a customer. What criteria should we follow for
 cases like this? 
 
 From visiting with Sean in -qa, typically service configurations don't
 change for the grenade target on upgrade, but if we have to make a
 change on upgrade (to clean out old cruft for example), how do we go
 about that? 

Add content here -
https://github.com/openstack-dev/grenade/tree/master/from-juno

Note: you'll get a -2 unless you provide a link to Release Notes
somewhere that highlights this as an Upgrade Impact for users for the
next release.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Infra] Infra-manual documentation Sprint, December 1-2

2014-12-03 Thread Elizabeth K. Joseph
On Fri, Nov 7, 2014 at 5:57 AM, Elizabeth K. Joseph
l...@princessleia.com wrote:
 The OpenStack Infrastructure team will be hosting a virtual sprint in
 the Freenode IRC channel #openstack-sprint for the Infrastructure User
 Manual on December 1st starting at 15:00 UTC and going for 48 hours.

Thanks to everyone who participated in our online documentation sprint
this week!

We made major progress with our manual (published here:
http://docs.openstack.org/infra/manual/) and hope this push for core
content will help us continue to refine and update the content for
this valuable community resource moving forward.

Now, some numbers:

Sprint start:
Patches open for review: 10
Patches merged in repo history: 13

Sprint end:
Patches open for review: 3 (plus 2 WIP)
See: 
https://review.openstack.org/#/q/status:open+project:openstack-infra/infra-manual,n,z

Patches merged during sprint: 30
See: 
https://review.openstack.org/#/q/status:merged+project:openstack-infra/infra-manual,n,z

Reviews: Over 200
See http://stackalytics.com/?module=infra-manualrelease=kilo

We also have 16 patches for documentation in flight that were
initiated or reviewed elsewhere in the openstack-infra project during
this sprint, including the important reorganization of the git-review
documentation. See:
https://review.openstack.org/#/q/status:open+file:%255E.*%255C.rst+project:%255Eopenstack-infra/.*,n,z

Sprint participants (sorted chronologically by reviews): Elizabeth
Krumbach Joseph, Andreas Jaeger, James E. Blair, Anita Kuno, Clark
Boylan, Spencer Krum, Jeremy Stanley, Doug Hellmann, Khai Do, Antoine
Musso, Stefano Maffulli, Thierry Carrez and Yolanda Robla

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Jay Pipes

On 12/03/2014 10:53 AM, Nikolay Markov wrote:

However, the OpenStack community is also about a shared set of tools,
development methodologies, and common perspectives.


I completely agree with you, Jay, but the same principle may be
applied much wider. Why Openstack Community decided to use its own
unstable project instead of existing solution, which is widely used in
Python community? To avoid being a team player? Or, at least, why it's
recommended way even if it doesn't provide the same features other
frameworks have for a long time already? I mean, there is no doubt
everyone would use stable and technically advanced tool, but imposing
everyone to use it by force with a simple hope that it'll become
better from this is usually a bad approach.


This conversation was had a long time ago, was thoroughly thought-out 
and discussed at prior summits and the ML:


https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
https://etherpad.openstack.org/p/havana-common-wsgi

I think it's unfair to suggest that the OpenStack community decided to 
use its own unstable project instead of existing solution.


Best,
-jay

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Nikolay Markov
I didn't participate in that discussion, but here are topics on Flask
cons from your link. I added some comments.

- Cons
- db transactions a little trickier to manage, but possible  #
what is trickier? Flask uses pure SQLalchemy or a very thin wrapper
- JSON built-in but not XML # the only one I agree with, but does
Pecan have it?
- some issues, not updated in a while  # last commit was 3 days ago
- No Python 3 support  # full Python 3 support fro a year or so already
- Not WebOb  # can it even be considered as a con?

I'm not trying to argue with you or community principles, I'm just
trying to choose the right instrument for the job.

On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/03/2014 10:53 AM, Nikolay Markov wrote:

 However, the OpenStack community is also about a shared set of tools,
 development methodologies, and common perspectives.


 I completely agree with you, Jay, but the same principle may be
 applied much wider. Why Openstack Community decided to use its own
 unstable project instead of existing solution, which is widely used in
 Python community? To avoid being a team player? Or, at least, why it's
 recommended way even if it doesn't provide the same features other
 frameworks have for a long time already? I mean, there is no doubt
 everyone would use stable and technically advanced tool, but imposing
 everyone to use it by force with a simple hope that it'll become
 better from this is usually a bad approach.


 This conversation was had a long time ago, was thoroughly thought-out and
 discussed at prior summits and the ML:

 https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
 https://etherpad.openstack.org/p/havana-common-wsgi

 I think it's unfair to suggest that the OpenStack community decided to use
 its own unstable project instead of existing solution.


 Best,
 -jay

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



-- 
Best regards,
Nick Markov

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Fox, Kevin M
+1. Well said. I second the applauding of the Fuel's development team's for 
their changing of their communications patterns (that's never easy) and also 
the desire for closer integration with the rest of the OpenStack community.

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, December 03, 2014 7:32 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework

On 12/03/2014 10:16 AM, Nikolay Markov wrote:
 It would be great to look at some obvious points where Pecan is better
 than Flask despite of the fact that it's used by the community. I
 still don't see a single and I don't think the principle jump from
 the cliff if everyone does works well in such cases.

This is part of why the Fuel development team is viewed as not working
with the OpenStack community in many ways. The Fuel team is doing a
remarkable job in changing previously-all-internal-to-Mirantis
communication patterns to instead be on a transparent basis in the
mailing lists and on IRC. I sincerely applaud the Fuel team for that.

However, the OpenStack community is also about a shared set of tools,
development methodologies, and common perspectives. It's expected that
when you have an OpenStack REST API project, that you try to use the
tools that the shared community uses, builds, and supports. Otherwise,
you aren't being a team player.

In the past, certain teams have chosen to use something other than Pecan
due to technical reasons. For example, Zaqar's team chose to use the
Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a
data API, not a control API, and raw performance is critical to the
project's API endpoint). This is, incidentally, why the Swift team chose
to use its swob framework over Webob (which Pecan uses).

However, the reason that these were chosen was definitely not it
doesn't support the coding patterns I like. There's something that
comes from being a team player. And one of those things is going with
the flow when there isn't a real technical reason not to. All of us can
and do find things we don't like about *all* of the projects that we
work on. The difference between team players and non-team players is
that team players strongly weigh their decisions and opinions based on
what the team is doing and how the team can improve.

Best,
-jay

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

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Ryan Petrello
I've left some comments/corrections in this document re: pecan and what is
supports.

On 12/03/14 07:58 PM, Nikolay Markov wrote:
 A month or two ago I started gathering differencies between Flask and
 Pecan, let's take a look at technical details. Maybe there are some
 things that are already fixed in current versions of Pecan, feel free
 to comment. 
 https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
 
 On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov nmar...@mirantis.com wrote:
  However, the OpenStack community is also about a shared set of tools,
  development methodologies, and common perspectives.
 
  I completely agree with you, Jay, but the same principle may be
  applied much wider. Why Openstack Community decided to use its own
  unstable project instead of existing solution, which is widely used in
  Python community? To avoid being a team player? Or, at least, why it's
  recommended way even if it doesn't provide the same features other
  frameworks have for a long time already? I mean, there is no doubt
  everyone would use stable and technically advanced tool, but imposing
  everyone to use it by force with a simple hope that it'll become
  better from this is usually a bad approach.
 
  I personally would surely contribute to Pecan in case we decide to use
  it and there will be some gaps and uncovered cases. I'm just curious,
  does it worth it?
 
  On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes jaypi...@gmail.com wrote:
  On 12/03/2014 10:16 AM, Nikolay Markov wrote:
 
  It would be great to look at some obvious points where Pecan is better
  than Flask despite of the fact that it's used by the community. I
  still don't see a single and I don't think the principle jump from
  the cliff if everyone does works well in such cases.
 
 
  This is part of why the Fuel development team is viewed as not working with
  the OpenStack community in many ways. The Fuel team is doing a remarkable
  job in changing previously-all-internal-to-Mirantis communication patterns
  to instead be on a transparent basis in the mailing lists and on IRC. I
  sincerely applaud the Fuel team for that.
 
  However, the OpenStack community is also about a shared set of tools,
  development methodologies, and common perspectives. It's expected that when
  you have an OpenStack REST API project, that you try to use the tools that
  the shared community uses, builds, and supports. Otherwise, you aren't 
  being
  a team player.
 
  In the past, certain teams have chosen to use something other than Pecan 
  due
  to technical reasons. For example, Zaqar's team chose to use the Falcon
  framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
  not a control API, and raw performance is critical to the project's API
  endpoint). This is, incidentally, why the Swift team chose to use its swob
  framework over Webob (which Pecan uses).
 
  However, the reason that these were chosen was definitely not it doesn't
  support the coding patterns I like. There's something that comes from 
  being
  a team player. And one of those things is going with the flow when there
  isn't a real technical reason not to. All of us can and do find things we
  don't like about *all* of the projects that we work on. The difference
  between team players and non-team players is that team players strongly
  weigh their decisions and opinions based on what the team is doing and how
  the team can improve.
 
  Best,
 
  -jay
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  --
  Best regards,
  Nick Markov
 
 
 
 -- 
 Best regards,
 Nick Markov
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

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


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Akihiro Motoki
+1 for Kevin and Henry. Thanks for your continuous efforts so far and
it would be great additions to our community.

I also would like to say great thanks to Bob and Nachi.
It would be really nice if we see their activities in reviews soon.
We already understand your contributions and skills, so
I believe you all can be back cores even though what is the conclusion
(as nova team usually does).

Thanks,
Akihiro



On Wed, Dec 3, 2014 at 12:59 AM, Kyle Mestery mest...@mestery.com wrote:
 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.

 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.

 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.

 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/180

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



-- 
Akihiro Motoki amot...@gmail.com

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Fox, Kevin M
Choosing the right instrument for the job in an open source community involves 
choosing technologies that the community is familiar/comfortable with as well, 
as it will allow you access to a greater pool of developers.

With that in mind then, I'd add:
Pro Pecan, blessed by the OpenStack community, con Flask, not.

Kevin

From: Nikolay Markov [nmar...@mirantis.com]
Sent: Wednesday, December 03, 2014 9:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework

I didn't participate in that discussion, but here are topics on Flask
cons from your link. I added some comments.

- Cons
- db transactions a little trickier to manage, but possible  #
what is trickier? Flask uses pure SQLalchemy or a very thin wrapper
- JSON built-in but not XML # the only one I agree with, but does
Pecan have it?
- some issues, not updated in a while  # last commit was 3 days ago
- No Python 3 support  # full Python 3 support fro a year or so already
- Not WebOb  # can it even be considered as a con?

I'm not trying to argue with you or community principles, I'm just
trying to choose the right instrument for the job.

On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 12/03/2014 10:53 AM, Nikolay Markov wrote:

 However, the OpenStack community is also about a shared set of tools,
 development methodologies, and common perspectives.


 I completely agree with you, Jay, but the same principle may be
 applied much wider. Why Openstack Community decided to use its own
 unstable project instead of existing solution, which is widely used in
 Python community? To avoid being a team player? Or, at least, why it's
 recommended way even if it doesn't provide the same features other
 frameworks have for a long time already? I mean, there is no doubt
 everyone would use stable and technically advanced tool, but imposing
 everyone to use it by force with a simple hope that it'll become
 better from this is usually a bad approach.


 This conversation was had a long time ago, was thoroughly thought-out and
 discussed at prior summits and the ML:

 https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
 https://etherpad.openstack.org/p/havana-common-wsgi

 I think it's unfair to suggest that the OpenStack community decided to use
 its own unstable project instead of existing solution.


 Best,
 -jay

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



--
Best regards,
Nick Markov

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

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


Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

2014-12-03 Thread Matt Riedemann



On 12/3/2014 3:49 AM, Li Junhong wrote:

Hi Joe,

Thank you for your confirmative answer and the wonderful gate testing
pipeline.

On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:



On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com
mailto:lijh.h...@gmail.com wrote:

Hi All,

Is it possible for Kilo nova controller to control the Juno
compute nodes? Is this scenario supported naturally by the nova
mechanism in the design and codes level?


Yes,

We gate on making sure we can run Kilo nova with Juno compute nodes.



--
Best Regards!

Junhong, Li

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



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




--
Best Regards!

Junhong, Li


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



FYI, there are also documented upgrade plans now [1].

http://docs.openstack.org/developer/nova/devref/upgrade.html

--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

2014-12-03 Thread Clint Byrum
Excerpts from Chris Jones's message of 2014-12-03 02:47:30 -0800:
 Hi
 
 I am very sympathetic to this view. We have a patch in hand that improves the 
 situation. We also have disagreement about the ideal situation.
 
 I +2'd Ian's patch because it makes things work better than they do now. If 
 we can arrive at an ideal solution later, great, but the more I think about 
 logging from a multitude of bash scripts, and tricks like XTRACE_FD, the more 
 I think it's crazy and we should just incrementally improve the non-trace 
 logging as a separate exercise, leaving working tracing for true debugging 
 situations.
 

Forgive me, I am not pushing for an ideal situation, but I don't want a
regression.

Running without -x right now has authors xtracing as a rule. Meaning
that the moment this merges, the amount of output goes to almost nil
compared to what it is now.

Basically this is just more of the same OpenStack wrong-headed idea, you
have to run in DEBUG logging mode to be able to understand any issue.

I'm totally willing to compromise on the ideal for something that is
good enough, but I'm saying this is not good enough _if_ it turns off
tracing for all scripts.

What if the patch is reworked to leave the current trace-all-the-time
mode in place, and we iterate on each script to make tracing conditional
as we add proper logging?

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


Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

2014-12-03 Thread Mooney, Sean K
Hi Daniel thanks for your feedback.

After reading up a little more 
http://docs.openstack.org/openstack-ops/content/scaling.html#segragation_methods
I now understand your original suggestion.

I believe that if the operator  associates the aggregate directly to the flavor
As you suggested that yes this will cover my use case too as the tenant is 
selecting availability zones
Not host aggregates.

Sorry I had misconstrued the relationship between availability zones and host 
aggregates.
I believed that there was a one to one mapping ,so when you select an 
availability zone you were
Selecting the host aggregate directly.

Regards
Sean.

 -Original Message-
 From: Daniel P. Berrange [mailto:berra...@redhat.com]
 Sent: Wednesday, December 03, 2014 1:38 PM
 To: Mooney, Sean K
 Cc: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] [libvirt] enabling per node 
 filtering of mempage sizes
 
 On Wed, Dec 03, 2014 at 01:28:36PM +, Mooney, Sean K wrote:
  Hi
 
  Unfortunately a flavor + aggregate is not enough for our use case as 
  it is still
 possible for the tenant to misconfigure a vm.
 
  The edge case not covered by flavor + aggregate that we are trying 
  to prevent
 is as follows.
 
  The operator creates an aggregate containing the  nodes that require 
  all VMs
 to use large pages.
  The operator creates flavors with and without memory backing specified.
 
  The tenant selects the aggregate containing nodes that only supports
 hugepages and a flavor that requires small or any.
  Or
  The tenant selects a flavor that requires small or any and does not 
  select an
 aggregate.
 
 The tenant isn't responsible for selecting the aggregate. The operator 
 should be associating the aggregate directly to the flavour. So the 
 tenant merely has to select the right flavour.
 
 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-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Alan Pevec
2014-12-02 17:15 GMT+01:00 Jay S. Bryant jsbry...@electronicjungle.net:
 Cinder
 https://review.openstack.org/137537 - small change and limited to the
 VMWare driver

 +1 I think this is fine to make an exception for.

one more Cinder exception proposal was added in StableJuno etherpad
* https://review.openstack.org/#/c/138526/ (This is currently the
master version but I will be proposing to stable/juno as soon as it is
approved in Master)  The Brocade FS San Lookup facility is currently
broken and this revert is necessary to get it working again.

Jay, what's the status there, I see master change failed in gate?

Cheers,
Alan

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


Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Alan Pevec
 Horizon
 standing-after-freeze translation update, coming on Dec 3

This is now posted https://review.openstack.org/138798
David, Matthias, I'd appreciate one of you to have a quick look before
approving.

Cheers,
Alan

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


Re: [openstack-dev] [Ironic] A mascot for Ironic

2014-12-03 Thread Lucas Alvares Gomes
Hi,

Poll is closed! Everyone please welcome: Pixie Boots, the new Ironic mascot!

Thanks for everyone that voted!

Cheers,
Lucas

On Mon, Dec 1, 2014 at 4:47 PM, Lucas Alvares Gomes lucasago...@gmail.com
wrote:

 Ah forgot to say,

 Please add your launchpad ID on the Name Field. And I will close the poll
 on Wednesday at 18:00 UTC (I think it's enough time to everyone take a look
 at it)

 Cheers,
 Lucas

 On Mon, Dec 1, 2014 at 4:44 PM, Lucas Alvares Gomes lucasago...@gmail.com
  wrote:

 Hi all,

 I'm sorry for the long delay on this I've been dragged into some other
 stuff :) But anyway, now it's time

 I've asked the core Ironic team to narrow down the name options (we had
 too many, thanks to everyone that contributed) the list of finalists is in
 the poll right here: http://doodle.com/9h4ncgx4etkyfgdw. So please vote
 and help us choose the best name for the new mascot!

 Cheers,
 Lucas

 On Tue, Nov 18, 2014 at 7:44 PM, Nathan Kinder nkin...@redhat.com
 wrote:



 On 11/16/2014 10:51 AM, David Shrewsbury wrote:
 
  On Nov 16, 2014, at 8:57 AM, Chris K nobody...@gmail.com
  mailto:nobody...@gmail.com wrote:
 
  How cute.
 
  maybe we could call him bear-thoven.
 
  Chris
 
 
  I like Blaze Bearly, lead singer for Ironic Maiden.  :)
 
  https://en.wikipedia.org/wiki/Blaze_Bayley

 Good call!  I never thought I'd see a Blaze Bayley reference on this
 list. :) Just watch out for imposters...

 http://en.wikipedia.org/wiki/Slow_Riot_for_New_Zer%C3%B8_Kanada#BBF3

 
 
 
  On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes
  lucasago...@gmail.com mailto:lucasago...@gmail.com wrote:
 
  Hi Ironickers,
 
  I was thinking this weekend: All the cool projects does have a
 mascot
  so I thought that we could have one for Ironic too.
 
  The idea about what the mascot would be was easy because the RAX
 guys
  put bear metal their presentation[1] and that totally rocks! So
 I
  drew a bear. It also needed an instrument, at first I thought
 about a
  guitar, but drums is actually my favorite instrument so I drew a
 pair
  of drumsticks instead.
 
  The drawing thing wasn't that hard, the problem was to digitalize
 it.
  So I scanned the thing and went to youtube to watch some tutorials
  about gimp and inkspace to learn how to vectorize it. Magic, it
  worked!
 
  Attached in the email there's the original draw, the vectorized
  version without colors and the final version of it (with colors).
 
  Of course, I know some people does have better skills than I do,
 so I
  also attached the inkspace file of the final version in case
 people
  want to tweak it :)
 
  So, what you guys think about making this little drummer bear the
  mascot of the Ironic project?
 
  Ahh he also needs a name. So please send some suggestions and we
 can
  vote on the best name for him.
 
  [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
 
  Lucas
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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




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


Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Alan Pevec
 Neutron
 https://review.openstack.org/136294 - default SNAT, see review for
 details, I cannot distil 1liner :)
 -1: I would rather fix the doc to match behavior, than change behavior
 to match the doc and lose people that were relying on it.

Consensus is not to merge this and keep behavior.

 https://review.openstack.org/136275 - self-contained to the vendor
 code, extensively tested in several deployments
 +0: Feels a bit large for a last-minute exception.

Kyle, Ihar, I'd like to see +2 from Neutron stable-maint before
approving exception.


Cheers,
Alan

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


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Edgar Magana
I give +2 to Henry and Kevin. So, Congratulations Folks!
I have been working with both of them and great quality reviews are always
coming out from them.

Many thanks to Nachi and Bob for their hard work!

Edgar

On 12/2/14, 7:59 AM, Kyle Mestery mest...@mestery.com wrote:

Now that we're in the thick of working hard on Kilo deliverables, I'd
like to make some changes to the neutron core team. Reviews are the
most important part of being a core reviewer, so we need to ensure
cores are doing reviews. The stats for the 180 day period [1] indicate
some changes are needed for cores who are no longer reviewing.

First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
neutron-core. Bob and Nachi have been core members for a while now.
They have contributed to Neutron over the years in reviews, code and
leading sub-teams. I'd like to thank them for all that they have done
over the years. I'd also like to propose that should they start
reviewing more going forward the core team looks to fast track them
back into neutron-core. But for now, their review stats place them
below the rest of the team for 180 days.

As part of the changes, I'd also like to propose two new members to
neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
been very active in reviews, meetings, and code for a while now. Henry
lead the DB team which fixed Neutron DB migrations during Juno. Kevin
has been actively working across all of Neutron, he's done some great
work on security fixes and stability fixes in particular. Their
comments in reviews are insightful and they have helped to onboard new
reviewers and taken the time to work with people on their patches.

Existing neutron cores, please vote +1/-1 for the addition of Henry
and Kevin to the core team.

Thanks!
Kyle

[1] http://stackalytics.com/report/contribution/neutron-group/180

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


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


Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Matthias Runge
On 03/12/14 20:22, Alan Pevec wrote:
 Horizon
 standing-after-freeze translation update, coming on Dec 3
 
 This is now posted https://review.openstack.org/138798
 David, Matthias, I'd appreciate one of you to have a quick look before
 approving.
 
 Cheers,
 Alan
 
Alan, thanks for the heads-up here. Approved.

Matthias


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


Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

2014-12-03 Thread Chris Jones
Hi

 On 3 Dec 2014, at 18:41, Clint Byrum cl...@fewbar.com wrote:
 
 What if the patch is reworked to leave the current trace-all-the-time
 mode in place, and we iterate on each script to make tracing conditional
 as we add proper logging?

+1

Cheers,
--
Chris Jones

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


[openstack-dev] [Neutron] [Devstack] Devstack quantun-agent vlan error

2014-12-03 Thread Daniel Nobusada
Hi guys,

I'm using Devstack with vlan on the parameter Q_ML2_TENANT_NETWORK_TYPE and
while stacking, the quantun-agent (q-agt) breaks. I'm running it on an
Ubuntu Server 14.04.

For more details, here's my local.conf: http://pastebin.com/4scBGtpf.
The error that I recieve is the following: http://pastebin.com/TLq0safe

Could anyone help me?

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


[openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

2014-12-03 Thread John Griffith
Hey,

So this is a long running topic, but I want to bring it up again.
First, YES Cinder is still running a sample.conf.  A lot of Operators
spoke up and provided feedback that this was valuable and they
objected strongly to taking it away.  That being said we're going to
go the route of removing it from our unit tests and
generating/publishing periodically outside of tests.

That being said, one of the things that's driving me crazy and
breaking things on a regular basis is other OpenStack libs having a
high rate of change of config options.  This revolves around things
like fixing typos in the comments, reformatting of text etc.  All of
these things are good in the long run, but I wonder if we could
consider batching these sorts of efforts and communicating them?

The other issue that we hit today was a flat out removal of an option
in the oslo.messaging lib with no deprecation.  This patch here [1]
does a number of things that are probably great in terms of clean up
and housekeeping, but now that we're all in on shared/common libs I
think we should be a bit more careful about the changes we make.  Also
to me the commit message doesn't really make it easy for me to search
git logs to try and figure out what happened when things blew up.

Anyway, just wanted to send a note out asking people to keep in mind
the impact of conf changes, and a gentle reminder about depreciation
periods for the removal of options.

[1]: 
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586

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


[openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-03 Thread Sean Dague
So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.

I think that should be reverted, an oops release put out to fix it, and
then deprecate for 1.6.

If oslo libraries are going to include config options, they have to
follow the same config deprecation as that's a contract that projects
project up. Otherwise we need to rethink the ability for libraries to
use oslo config (which, honestly is worth rethinking).

-Sean

-- 
Sean Dague
http://dague.net

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


[openstack-dev] [third-party] Third-party CI account creation is now self-serve

2014-12-03 Thread Anita Kuno
As of now third-party CI account creation is now self-serve. I think
this makes everybody happy.

What does this mean?

Well for a new third-party account this means you follow the new
process, outlined here:
http://ci.openstack.org/third_party.html#creating-a-service-account

If you don't have enough information from these docs, please contact the
infra team then we will work on a patch once you learn what you needed,
to fill in the holes for others.

If you currently have a third-party CI account on Gerrit, this is what
will happen with your account:
http://ci.openstack.org/third_party.html#permissions-on-your-third-party-system

Short story is we will be moving voting accounts into project specific
voting groups. Your voting rights will not change, but will be directly
managed by project release groups.
Non voting accounts will be removed from the now redundant Third-Party
CI group and otherwise will not be changed.

If you are a member of a project-release group for a project currently
receiving third-party CI votes, you will find that you have access to
manage membership in a new group in Gerrit called project-ci.  To
allow a CI system to vote on your project, add it to the project-ci
group, and to disable voting on your project, remove them from that group.

We hope you are as excited about this change as we are.

Let us know if you have questions, do try to work with third-party
project representatives as much as you can.

Thank you,
Anita.

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


Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

2014-12-03 Thread Morgan Fainberg
Hi John,

Let me say first off that I 100% agree with the value of the sample config 
being in-tree. Keystone has not removed it due to similar feedback I’ve 
received. However, the issue is that *gating* on config changes for all 
libraries that are included in the sample config is just a process that leads 
to this frustration / breakage. I have thought about this, and I think the 
right answer is two fold:

1) immediately stop gating on sample config changes. I know the cinder team 
uses it as a “did we break some compat” and “are you changing config” in a 
patch that could adversely affect deployers/other systems. I don’t think you’re 
going to win the “don’t change config values in libraries we don’t control” (or 
even controlled by a separate project) argument. It’s very hard to release an 
updated oslo lib, clients, or keystonemiddleware.

2) Implement a check (I think I have a way of doing this, I’ll run it by Doug 
Hellman and you on IRC) that is programatically checking *only* for in-tree 
config values.

Alternative: A non-voting gate job that says “config has changed” [should be 
*really* easy to add] so at least you know the config has changed.

This should likely be something easy to get through the door (either the 
programatic one or the simple non-voting job). This however, needs the infra 
team buy-in as acceptable.

I know that most projects have moved away from gating on this since we now 
consume a lot of libraries that provide config options that the individual 
server-projects don’t control (it is the reason Keystone doesn’t gate 
explicitly on this).

Just my quick $0.002 on the topic,
—Morgan

 On Dec 3, 2014, at 12:44 PM, John Griffith john.griffi...@gmail.com wrote:
 
 Hey,
 
 So this is a long running topic, but I want to bring it up again.
 First, YES Cinder is still running a sample.conf.  A lot of Operators
 spoke up and provided feedback that this was valuable and they
 objected strongly to taking it away.  That being said we're going to
 go the route of removing it from our unit tests and
 generating/publishing periodically outside of tests.
 
 That being said, one of the things that's driving me crazy and
 breaking things on a regular basis is other OpenStack libs having a
 high rate of change of config options.  This revolves around things
 like fixing typos in the comments, reformatting of text etc.  All of
 these things are good in the long run, but I wonder if we could
 consider batching these sorts of efforts and communicating them?
 
 The other issue that we hit today was a flat out removal of an option
 in the oslo.messaging lib with no deprecation.  This patch here [1]
 does a number of things that are probably great in terms of clean up
 and housekeeping, but now that we're all in on shared/common libs I
 think we should be a bit more careful about the changes we make.  Also
 to me the commit message doesn't really make it easy for me to search
 git logs to try and figure out what happened when things blew up.
 
 Anyway, just wanted to send a note out asking people to keep in mind
 the impact of conf changes, and a gentle reminder about depreciation
 periods for the removal of options.
 
 [1]: 
 https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


Re: [openstack-dev] [Manila] Manila project use-cases

2014-12-03 Thread Ben Swartzlander

Reply to Valeriy below and to Marc further below...


On 12/03/2014 02:39 AM, Valeriy Ponomaryov wrote:
According to (2) - yes, analog of Cinder's manage/unmanage is not 
implemented in Manila yet.


Manage/unmanage is a feature I'm very interested in seeing in Manila. I 
suspect it will be harder to get right in Manila than it was for Cinder, 
however, and more importantly, getting it right will depend a lot on the 
work that's going on right now to support pools and driver modes. For 
Manila core it won't actually be that much work but for individual 
drivers, implementing manage/unmanage can be a huge amount of work, so 
we should try to define the semantics of manage/unmanage at the project 
level to strike a good balance between usefulness to administrators and 
making it practical to implement.


On Wed, Dec 3, 2014 at 9:03 AM, Marc Koderer m...@koderer.com 
mailto:m...@koderer.com wrote:


Hi Valeriy,

thanks for feedback. My answers see below.

Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryov
vponomar...@mirantis.com mailto:vponomar...@mirantis.com:

 Hello Marc,

 Here, I tried to cover mentioned use cases with implemented or
not notes:

 1) Implemented, but details of implementation are different for
different share drivers.
 2) Not clear for me. If you mean possibility to mount one share
to any amount of VMs, then yes.

That means you have an existing shared volume in your storage
system and import
it to manila (like cinder manage). I guess this is not implemented
yet.

 3) Nova is used only in one case - Generic Driver that uses
Cinder volumes. So, it can be said, that Manila interface does
allow to use flat network and a share driver just should have
implementation for it. I will assume you mean usage of generic
driver and possibility to mount shares to different machines
except Nova VMs. - In that case network architecture should allow
to make connection in general. If it is allowed, then should not
be any problems with mount to any machine. Just access-allow
operations should be performed.

This point was actually a copy from the wiki [1]. I just removed
the Bare-metal point
since for me it doesn’t matter whether the infrastructure service
is a Bare-metal machine or not.

 4) Access can be shared, but it is not as flexible as could be
wanted. Owner of a share can grant access to all, and if there is
network connectivity between user and share host, then user will
be able to mount having provided access.

Also a copy from the wiki.

 5) Manila can not remove some mount of some share, it can
remove access for possibility to mount in general. So, looks like
not implemented.
 6) Implemented.
 7) Not implemented yet.
 8) No cloning, but we have snapshot-approach as for volumes in
cinder.

Regards
Marc


 Regards,
 Valeriy Ponomaryov
 Mirantis

 On Tue, Dec 2, 2014 at 4:22 PM, Marc Koderer m...@koderer.com
mailto:m...@koderer.com wrote:
 Hello Manila Team,

 We identified use cases for Manila during an internal workshop
 with our operators. I would like to share them with you and
 update the wiki [1] since it seems to be outdated.

 Before that I would like to gather feedback and you might help me
 with identifying things that aren’t implemented yet.

 Our list:

  1.) Create a share and use it in a tenant
  Initial creation of a shared storage volume and assign it
to several VM’s



This is the basic use case for Manila and I hope it's obvious that this 
works.



  2.) Assign an preexisting share to a VM with Manila
  Import an existing Share with data and it to several VM’s
in case of
  migrating an existing production - services to Openstack.



Covered above.


  3.) External consumption of a share
  Accommodate and provide mechanisms for last-mile
consumption of shares by
  consumers of the service that aren't mediated by Nova.



Depending on how you look at this, it either already works or it's out 
of scope for Manila. Now that we're looking at mount automation we may 
be more involved in this area, but nothing about Manila prevents the use 
of shares by something other than nova.



  4.) Cross Tenant sharing
  Coordinate shares across tenants



As above, this is considered out of scope, but we believe it's easy to 
make this work with no changes to Manila.



  5.) Detach a share and don’t destroy data (deactivate)
  Share is flagged as inactive and data are not destroyed for
later
  usage or in case of legal requirements.



Can't this be achieved by simply removing all access? By default, the 
shares manila creates are not accessible to anyone. Access must be 
granted explicitly.



  6.) Unassign and delete data of a share
  

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-03 Thread Ben Nemec
On 12/03/2014 02:45 PM, Sean Dague wrote:
 So this -
 https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
 was clearly a violation of our 1 cycle for deprecation of config options.
 
 I think that should be reverted, an oops release put out to fix it, and
 then deprecate for 1.6.

+1.  That was definitely a no-no.

 
 If oslo libraries are going to include config options, they have to
 follow the same config deprecation as that's a contract that projects
 project up. Otherwise we need to rethink the ability for libraries to
 use oslo config (which, honestly is worth rethinking).

I don't see how that would help with this sort of thing.  Instead of one
project mistakenly removing an undeprecated opt, you would have dozens
potentially making the same error, which would also then make their
available configuration options inconsistent with all of the other
projects using oslo.messaging.  That way lies madness.


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


Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

2014-12-03 Thread Sean Dague
On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
 Hi John,
 
 Let me say first off that I 100% agree with the value of the sample config 
 being in-tree. Keystone has not removed it due to similar feedback I’ve 
 received. However, the issue is that *gating* on config changes for all 
 libraries that are included in the sample config is just a process that leads 
 to this frustration / breakage. I have thought about this, and I think the 
 right answer is two fold:
 
 1) immediately stop gating on sample config changes. I know the cinder team 
 uses it as a “did we break some compat” and “are you changing config” in a 
 patch that could adversely affect deployers/other systems. I don’t think 
 you’re going to win the “don’t change config values in libraries we don’t 
 control” (or even controlled by a separate project) argument. It’s very hard 
 to release an updated oslo lib, clients, or keystonemiddleware.
 
 2) Implement a check (I think I have a way of doing this, I’ll run it by Doug 
 Hellman and you on IRC) that is programatically checking *only* for in-tree 
 config values.
 
 Alternative: A non-voting gate job that says “config has changed” [should be 
 *really* easy to add] so at least you know the config has changed.
 
 This should likely be something easy to get through the door (either the 
 programatic one or the simple non-voting job). This however, needs the infra 
 team buy-in as acceptable.
 
 I know that most projects have moved away from gating on this since we now 
 consume a lot of libraries that provide config options that the individual 
 server-projects don’t control (it is the reason Keystone doesn’t gate 
 explicitly on this).

So I think there is a better way. The end game here is you want an up to
date sample config in your tree.

Ok, so as a post merge figure out if you need a config change, and if so
proposal bot that back in. Better yet, publish these somewhere on the
web so people can browse samples. Maybe even for a few different kinds
of configs.

Make it part of the release checklist for a milestone that the tool
which generates the config is run manually and make sure that the in
tree config is up to date. Which might mean in master it's behind a bit,
but at least it will be right for any releases.

-Sean


 
 Just my quick $0.002 on the topic,
 —Morgan
 
 On Dec 3, 2014, at 12:44 PM, John Griffith john.griffi...@gmail.com wrote:

 Hey,

 So this is a long running topic, but I want to bring it up again.
 First, YES Cinder is still running a sample.conf.  A lot of Operators
 spoke up and provided feedback that this was valuable and they
 objected strongly to taking it away.  That being said we're going to
 go the route of removing it from our unit tests and
 generating/publishing periodically outside of tests.

 That being said, one of the things that's driving me crazy and
 breaking things on a regular basis is other OpenStack libs having a
 high rate of change of config options.  This revolves around things
 like fixing typos in the comments, reformatting of text etc.  All of
 these things are good in the long run, but I wonder if we could
 consider batching these sorts of efforts and communicating them?

 The other issue that we hit today was a flat out removal of an option
 in the oslo.messaging lib with no deprecation.  This patch here [1]
 does a number of things that are probably great in terms of clean up
 and housekeeping, but now that we're all in on shared/common libs I
 think we should be a bit more careful about the changes we make.  Also
 to me the commit message doesn't really make it easy for me to search
 git logs to try and figure out what happened when things blew up.

 Anyway, just wanted to send a note out asking people to keep in mind
 the impact of conf changes, and a gentle reminder about depreciation
 periods for the removal of options.

 [1]: 
 https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586

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


-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

2014-12-03 Thread Morgan Fainberg

 On Dec 3, 2014, at 1:18 PM, Sean Dague s...@dague.net wrote:
 
 On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
 Hi John,
 
 Let me say first off that I 100% agree with the value of the sample config 
 being in-tree. Keystone has not removed it due to similar feedback I’ve 
 received. However, the issue is that *gating* on config changes for all 
 libraries that are included in the sample config is just a process that 
 leads to this frustration / breakage. I have thought about this, and I think 
 the right answer is two fold:
 
 1) immediately stop gating on sample config changes. I know the cinder team 
 uses it as a “did we break some compat” and “are you changing config” in a 
 patch that could adversely affect deployers/other systems. I don’t think 
 you’re going to win the “don’t change config values in libraries we don’t 
 control” (or even controlled by a separate project) argument. It’s very hard 
 to release an updated oslo lib, clients, or keystonemiddleware.
 
 2) Implement a check (I think I have a way of doing this, I’ll run it by 
 Doug Hellman and you on IRC) that is programatically checking *only* for 
 in-tree config values.
 
 Alternative: A non-voting gate job that says “config has changed” [should be 
 *really* easy to add] so at least you know the config has changed.
 
 This should likely be something easy to get through the door (either the 
 programatic one or the simple non-voting job). This however, needs the infra 
 team buy-in as acceptable.
 
 I know that most projects have moved away from gating on this since we now 
 consume a lot of libraries that provide config options that the individual 
 server-projects don’t control (it is the reason Keystone doesn’t gate 
 explicitly on this).
 
 So I think there is a better way. The end game here is you want an up to
 date sample config in your tree.
 
 Ok, so as a post merge figure out if you need a config change, and if so
 proposal bot that back in. Better yet, publish these somewhere on the
 web so people can browse samples. Maybe even for a few different kinds
 of configs.
 
 Make it part of the release checklist for a milestone that the tool
 which generates the config is run manually and make sure that the in
 tree config is up to date. Which might mean in master it's behind a bit,
 but at least it will be right for any releases.
 

This is actually what Keystone does. But last time I talked to John they used 
it for review of config changes purposes. I’m happy to be corrected and I’m a 
big advocate of “it’s part of the release checklist”.

—Morgan

   -Sean
 
 
 
 Just my quick $0.002 on the topic,
 —Morgan
 
 On Dec 3, 2014, at 12:44 PM, John Griffith john.griffi...@gmail.com wrote:
 
 Hey,
 
 So this is a long running topic, but I want to bring it up again.
 First, YES Cinder is still running a sample.conf.  A lot of Operators
 spoke up and provided feedback that this was valuable and they
 objected strongly to taking it away.  That being said we're going to
 go the route of removing it from our unit tests and
 generating/publishing periodically outside of tests.
 
 That being said, one of the things that's driving me crazy and
 breaking things on a regular basis is other OpenStack libs having a
 high rate of change of config options.  This revolves around things
 like fixing typos in the comments, reformatting of text etc.  All of
 these things are good in the long run, but I wonder if we could
 consider batching these sorts of efforts and communicating them?
 
 The other issue that we hit today was a flat out removal of an option
 in the oslo.messaging lib with no deprecation.  This patch here [1]
 does a number of things that are probably great in terms of clean up
 and housekeeping, but now that we're all in on shared/common libs I
 think we should be a bit more careful about the changes we make.  Also
 to me the commit message doesn't really make it easy for me to search
 git logs to try and figure out what happened when things blew up.
 
 Anyway, just wanted to send a note out asking people to keep in mind
 the impact of conf changes, and a gentle reminder about depreciation
 periods for the removal of options.
 
 [1]: 
 https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 -- 
 Sean Dague
 http://dague.net http://dague.net/
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
 

Re: [openstack-dev] [neutron] alembic 0.7.1 will break neutron's heal feature which assumes a fixed set of potential autogenerate types

2014-12-03 Thread Mike Bayer
So folks, I had to put Alembic 0.7.1 out as I realized that the “batch” mode 
was being turned on for autogenerate across the board in 0.7.0, and that was 
not the plan.

So it is now out, and the builds are failing due to 
https://launchpad.net/bugs/1397796 https://launchpad.net/bugs/1397796.

There’s some nits happening on the review  
https://review.openstack.org/#/c/137989/ 
https://review.openstack.org/#/c/137989/, so I’m hoping someone with some 
Neutron cred adjust the patch to their liking and get it merged.I’m just 
the messenger on this. 

- mike



 On Dec 1, 2014, at 5:43 PM, Salvatore Orlando sorla...@nicira.com wrote:
 
 Thanks Mike!
 
 I've left some comments on the patch.
 Just out of curiosity, since now alembic can autogenerate foreign keys, are 
 we be able to remove the logic for identifying foreign keys to add/remove [1]?
 
 Salvatore
 
 [1] 
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/heal_script.py#n205
  
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/heal_script.py#n205
  
 
 On 1 December 2014 at 20:35, Mike Bayer mba...@redhat.com 
 mailto:mba...@redhat.com wrote:
 hey neutron -
 
 Just an FYI, I’ve added https://review.openstack.org/#/c/137989/ 
 https://review.openstack.org/#/c/137989/ / 
 https://launchpad.net/bugs/1397796 https://launchpad.net/bugs/1397796 to 
 refer to an issue in neutron’s “heal” script that is going to start failing 
 when I put out Alembic 0.7.1, which is potentially later today / this week.
 
 The issue is pretty straightforward,  Alembic 0.7.1 is adding foreign key 
 autogenerate (and really, could add more types of autogenerate at any time), 
 and as these new commands are revealed within the execute_alembic_command(), 
 they are not accounted for, so it fails.   I’d recommend folks try to push 
 this one through or otherwise decide how this issue (which should be expected 
 to occur many more times) should be handled.
 
 Just a heads up in case you start seeing builds failing!
 
 - mike
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-03 Thread Joshua Harlow

Ben Nemec wrote:

On 12/03/2014 02:45 PM, Sean Dague wrote:

So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.

I think that should be reverted, an oops release put out to fix it, and
then deprecate for 1.6.


+1.  That was definitely a no-no.


If oslo libraries are going to include config options, they have to
follow the same config deprecation as that's a contract that projects
project up. Otherwise we need to rethink the ability for libraries to
use oslo config (which, honestly is worth rethinking).


I don't see how that would help with this sort of thing.  Instead of one
project mistakenly removing an undeprecated opt, you would have dozens
potentially making the same error, which would also then make their
available configuration options inconsistent with all of the other
projects using oslo.messaging.  That way lies madness.


Isn't this the way most other libraries that don't use oslo.config 
operate? Aka, the API they expose would follow deprecation strategies 
that libraries/apps commonly use. It has always been sort of 
tricky/hidden (IMHO) that the usage of oslo.config is really a part of 
those libraries public API.


Example that shows what people might do:

# Using oslo-config as the API
def a(cfg):
  if cfg.b:
print(hi)

# Using an actual kwarg
def a(b=False):
  if b:
print(hi)

Now to deprecate the kwarg using function there needs to be some kind of 
warning logged when 'b' is provided that recommends the new name (say 
'c'); this is similar to what the oslo-config using API also has to do 
but I feel it's less obvious and easier to break; since it isn't clear 
from the function definition this is happening since the function still 
gets just a 'cfg' object, and this just gets worse if u continue passing 
around the cfg object to other functions/methods/classes...


Basically the only way to really know that someone is using 'cfg.b' is 
by grepping for it (which makes the API very malleable, for better or 
worse; it also seems to make it harder to use tools like sphinx that can 
interpret function pydocs to denote functions that have depreciations 
and such...).


IMHO it doesn't seem like the larger pypi/python world has gone to mad 
(aka those projects, apps, libraries, others that haven't used oslo.config)?


But maybe I missed all the mad people or I'm in the crowd that is mad 
and I can't tell ;) To me the inconsistency that you state is a 
policy/people problem and need not be addressed always by oslo.config 
(but could just be addressed at say review time).


I know not everyone agrees with this, but it's useful to think of 
different ways and at least think about them...





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


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


Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

2014-12-03 Thread Anita Kuno
Whoops too many mailing lists.


 Forwarded Message 
Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for
Additional Meeting for  third-party
Date: Wed, 03 Dec 2014 17:25:05 -0500
From: Anita Kuno ante...@anteaya.info
To: openstack-in...@lists.openstack.org

On 12/03/2014 03:15 AM, Omri Marcovitch wrote:
 Hello Anteaya,
 
 A meeting between 8:00 - 16:00 UTC time will be great (Israel).
 
 
 Thanks
 Omri
 
 -Original Message-
 From: Joshua Hesketh [mailto:joshua.hesk...@rackspace.com] 
 Sent: Wednesday, December 03, 2014 9:04 AM
 To: He, Yongli; OpenStack Development Mailing List (not for usage questions); 
 openstack-in...@lists.openstack.org
 Subject: Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for 
 Additional Meeting for third-party
 
 Hey,
 
 0700 - 1000 UTC would work for me most weeks fwiw.
 
 Cheers,
 Josh
 
 Rackspace Australia
 
 On 12/3/14 11:17 AM, He, Yongli wrote:
 anteaya,

 UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for china.

 if there is no time slot there, just pick up any time between UTC 7:00 AM to 
 UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and dinner.)

 Yongi He
 -Original Message-
 From: Anita Kuno [mailto:ante...@anteaya.info]
 Sent: Tuesday, December 02, 2014 4:07 AM
 To: openstack Development Mailing List; openstack-in...@lists.openstack.org
 Subject: [openstack-dev] [third-party]Time for Additional Meeting for 
 third-party

 One of the actions from the Kilo Third-Party CI summit session was to start 
 up an additional meeting for CI operators to participate from non-North 
 American time zones.

 Please reply to this email with times/days that would work for you. The 
 current third party meeting is on Mondays at 1800 utc which works well since 
 Infra meetings are on Tuesdays. If we could find a time that works for 
 Europe and APAC that is also on Monday that would be ideal.

 Josh Hesketh has said he will try to be available for these meetings, he is 
 in Australia.

 Let's get a sense of what days and timeframes work for those interested and 
 then we can narrow it down and pick a channel.

 Thanks everyone,
 Anita.


Okay first of all thanks to everyone who replied.

Again, to clarify, the purpose of this thread has been to find a
suitable additional third-party meeting time geared towards folks in EU
and APAC. We live on a sphere, there is no time that will suit everyone.

It looks like we are converging on 0800 UTC as a time and I am going to
suggest Tuesdays. We have very little competition for space at that date
+ time combination so we can use #openstack-meeting (I have already
booked the space on the wikipage).

So barring further discussion, see you then!

Thanks everyone,
Anita.



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


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-03 Thread Kevin Benton
What you are proposing sounds very reasonable. If I understand correctly,
the idea is to make Nova just create the TAP device and get it attached to
the VM and leave it 'unplugged'. This would work well and might eliminate
the need for some drivers. I see no reason to block adding a VIF type that
does this.

However, there is a good reason that the VIF type for some OVS-based
deployments require this type of setup. The vSwitches are connected to a
central controller using openflow (or ovsdb) which configures forwarding
rules/etc. Therefore they don't have any agents running on the compute
nodes from the Neutron side to perform the step of getting the interface
plugged into the vSwitch in the first place. For this reason, we will still
need both types of VIFs.


 1 .When the port is created in the Neutron DB, and handled (bound etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.

This is backwards. The tap device name is derived from the port ID, so the
port has already been created in Neutron at that point. It is just unbound.
The steps are roughly as follows: Nova calls neutron for a port, Nova
creates/plugs VIF based on port, Nova updates port on Neutron, Neutron
binds the port and notifies agent/plugin/whatever to finish the plumbing,
Neutron notifies Nova that port is active, Nova unfreezes the VM.

None of that should be affected by what you are proposing. The only
difference is that your Neutron agent would also perform the 'plugging'
operation.

For your second point, scanning the integration bridge for new ports is
currently used now, but that's an implementation detail of the reference
OVS driver. It doesn't block your work directly since OVS wouldn't use your
NOOP VIF type anyway.


Cheers,
Kevin Benton

On Wed, Dec 3, 2014 at 8:08 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 Hi there.  I've been looking into a tricky point, and hope I can succeed
 in expressing it clearly here...

 I believe it is the case, even when using a committedly Neutron-based
 networking implementation, that Nova is still involved a little bit in
 the networking setup logic.  Specifically I mean the plug() and unplug()
 operations, whose implementations are provided by *VIFDriver classes for
 the various possible hypervisors.

 For example, for the libvirt hypervisor, LibvirtGenericVIFDriver
 typically implements plug() by calling create_tap_dev() to create the
 TAP device, and then plugging into some form of L2 bridge.

 Does this logic actually have to be in Nova?  For a Neutron-based
 networking implementation, it seems to me that it should also be
 possible to do this in a Neutron agent (obviously running on the compute
 node concerned), and that - if so - that would be preferable because it
 would enable more Neutron-based experimentation without having to modify
 any Nova code.

 Specifically, therefore, I wonder if we could/should add a do-nothing
 value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement
 plug()/unplug() for that value to do nothing at all, leaving all setup
 to the Neutron agent?  And then hopefully it should never be necessary
 to introduce further Nova VIF type support ever again...

 Am I missing something that really makes that not fly?  Two possible
 objections occurs to me, as follows, but I think they're both
 surmountable.

 1. When the port is created in the Neutron DB, and handled (bound etc.)
by the plugin and/or mechanism driver, the TAP device name is already
present at that time.

I think this is still OK because Neutron knows anyway what the TAP
device name _will_ be, even if the actual TAP device hasn't been
created yet.

 2. With some agent implementations, there isn't a direct instruction,
from the plugin to the agent, to say now look after this VM /
port.  Instead the agents polls the OS for new TAP devices
appearing.  Clearly, then, if there isn't something other than the
agent that creates the TAP device, any logic in the agent will never
be triggered.

This is certain a problem.  For new networking experimentation,
however, we can write agent code that is directly instructed by the
plugin, and hence (a) doesn't need to poll (b) doesn't require the
TAP device to have been previously created by Nova - which I'd argue
is preferable.

 Thoughts?

 (FYI my context is that I've been working on a networking implementation
 where the TAP device to/from a VM should _not_ be plugged into a bridge
 - and for that I've had to make a Nova change even though my team's aim
 was to do the whole thing in Neutron.

 I've proposed a spec for the Nova change that plugs a TAP interface
 without bridging it (https://review.openstack.org/#/c/130732/), but that
 set me wondering about this wider question of whether such Nova changes
 should still be necessary...)

 Many thanks,
  Neil

 ___
 OpenStack-dev mailing list
 

Re: [openstack-dev] [neutron] alembic 0.7.1 will break neutron's heal feature which assumes a fixed set of potential autogenerate types

2014-12-03 Thread Salvatore Orlando
Thanks Mike,

I already gave your patch a +2. when the gate is broken there's no time for
nitpicking - those can come with a followup patch.
The patch is now spinning again against jenkins checks. As soon as it's
done we'll send it through the gate - and hopefully get a promotion for it.

Salvatore

On 3 December 2014 at 23:17, Mike Bayer mba...@redhat.com wrote:

 So folks, I had to put Alembic 0.7.1 out as I realized that the “batch”
 mode was being turned on for autogenerate across the board in 0.7.0, and
 that was not the plan.

 So it is now out, and the builds are failing due to
 https://launchpad.net/bugs/1397796.

 There’s some nits happening on the review
 https://review.openstack.org/#/c/137989/, so I’m hoping someone with some
 Neutron cred adjust the patch to their liking and get it merged.I’m
 just the messenger on this.

 - mike



 On Dec 1, 2014, at 5:43 PM, Salvatore Orlando sorla...@nicira.com wrote:

 Thanks Mike!

 I've left some comments on the patch.
 Just out of curiosity, since now alembic can autogenerate foreign keys,
 are we be able to remove the logic for identifying foreign keys to
 add/remove [1]?

 Salvatore

 [1]
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/heal_script.py#n205


 On 1 December 2014 at 20:35, Mike Bayer mba...@redhat.com wrote:

 hey neutron -

 Just an FYI, I’ve added https://review.openstack.org/#/c/137989/ /
 https://launchpad.net/bugs/1397796 to refer to an issue in neutron’s
 “heal” script that is going to start failing when I put out Alembic 0.7.1,
 which is potentially later today / this week.

 The issue is pretty straightforward,  Alembic 0.7.1 is adding foreign key
 autogenerate (and really, could add more types of autogenerate at any
 time), and as these new commands are revealed within the
 execute_alembic_command(), they are not accounted for, so it fails.   I’d
 recommend folks try to push this one through or otherwise decide how this
 issue (which should be expected to occur many more times) should be handled.

 Just a heads up in case you start seeing builds failing!

 - mike



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


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



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


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


Re: [openstack-dev] [Compute][Nova] Mid-cycle meetup details for kilo

2014-12-03 Thread Michael Still
I've just created the signup page for this event. Its here:

https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-14767182039

Cheers,
Michael

On Wed, Oct 15, 2014 at 3:45 PM, Michael Still mi...@stillhq.com wrote:
 Hi.

 I am pleased to announce details for the Kilo Compute mid-cycle
 meetup, but first some background about how we got here.

 Two companies actively involved in OpenStack came forward with offers
 to host the Compute meetup. However, one of those companies has
 gracefully decided to wait until the L release because of the cold
 conditions are their proposed location (think several feet of snow).

 So instead, we're left with California!

 The mid-cycle meetup will be from 26 to 28 January 2015, at the VMWare
 offices in Palo Alto California.

 Thanks for VMWare for stepping up and offering to host. It sure does
 make my life easy.

 More details will be forthcoming closer to the event, but I wanted to
 give people as much notice as possible about dates and location so
 they can start negotiating travel if they want to come.

 Cheers,
 Michael

 --
 Rackspace Australia



-- 
Rackspace Australia

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


Re: [openstack-dev] [Compute][Nova] Mid-cycle meetup details for kilo

2014-12-03 Thread Michael Still
Sigh, sorry. It is of course the Kilo meetup:

https://www.eventbrite.com.au/e/openstack-nova-kilo-mid-cycle-developer-meetup-tickets-14767182039

Michael

On Thu, Dec 4, 2014 at 10:16 AM, Michael Still mi...@stillhq.com wrote:
 I've just created the signup page for this event. Its here:

 https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-14767182039

 Cheers,
 Michael

 On Wed, Oct 15, 2014 at 3:45 PM, Michael Still mi...@stillhq.com wrote:
 Hi.

 I am pleased to announce details for the Kilo Compute mid-cycle
 meetup, but first some background about how we got here.

 Two companies actively involved in OpenStack came forward with offers
 to host the Compute meetup. However, one of those companies has
 gracefully decided to wait until the L release because of the cold
 conditions are their proposed location (think several feet of snow).

 So instead, we're left with California!

 The mid-cycle meetup will be from 26 to 28 January 2015, at the VMWare
 offices in Palo Alto California.

 Thanks for VMWare for stepping up and offering to host. It sure does
 make my life easy.

 More details will be forthcoming closer to the event, but I wanted to
 give people as much notice as possible about dates and location so
 they can start negotiating travel if they want to come.

 Cheers,
 Michael

 --
 Rackspace Australia



 --
 Rackspace Australia



-- 
Rackspace Australia

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


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Sukhdev Kapur
Congratulations Henry and Kevin. It has always been pleasure working with
you guys.


If I may express my opinion, Bob's contribution to ML2 has been quite
substantial. The kind of stability ML2 has achieved makes a statement of
his dedication to this work. I have worked very closely with Bob on several
issues and co-chaired ML2-Subteam with him and have developed tremendous
respect for his dedication.
Reading his email reply makes me believe he wants to continue to contribute
as core developer. Therefore, I would like to take an opportunity to appeal
to the core team to consider granting him his wish - i.e. vote -1 on his
removal.

regards..
-Sukhdev






On Wed, Dec 3, 2014 at 11:48 AM, Edgar Magana edgar.mag...@workday.com
wrote:

 I give +2 to Henry and Kevin. So, Congratulations Folks!
 I have been working with both of them and great quality reviews are always
 coming out from them.

 Many thanks to Nachi and Bob for their hard work!

 Edgar

 On 12/2/14, 7:59 AM, Kyle Mestery mest...@mestery.com wrote:

 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.
 
 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.
 
 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.
 
 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.
 
 Thanks!
 Kyle
 
 [1] http://stackalytics.com/report/contribution/neutron-group/180
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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


Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

2014-12-03 Thread John Griffith
On Wed, Dec 3, 2014 at 2:18 PM, Sean Dague s...@dague.net wrote:
 On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
 Hi John,

 Let me say first off that I 100% agree with the value of the sample config 
 being in-tree. Keystone has not removed it due to similar feedback I’ve 
 received. However, the issue is that *gating* on config changes for all 
 libraries that are included in the sample config is just a process that 
 leads to this frustration / breakage. I have thought about this, and I think 
 the right answer is two fold:

 1) immediately stop gating on sample config changes. I know the cinder team 
 uses it as a “did we break some compat” and “are you changing config” in a 
 patch that could adversely affect deployers/other systems. I don’t think 
 you’re going to win the “don’t change config values in libraries we don’t 
 control” (or even controlled by a separate project) argument. It’s very hard 
 to release an updated oslo lib, clients, or keystonemiddleware.

 2) Implement a check (I think I have a way of doing this, I’ll run it by 
 Doug Hellman and you on IRC) that is programatically checking *only* for 
 in-tree config values.

 Alternative: A non-voting gate job that says “config has changed” [should be 
 *really* easy to add] so at least you know the config has changed.

 This should likely be something easy to get through the door (either the 
 programatic one or the simple non-voting job). This however, needs the infra 
 team buy-in as acceptable.

 I know that most projects have moved away from gating on this since we now 
 consume a lot of libraries that provide config options that the individual 
 server-projects don’t control (it is the reason Keystone doesn’t gate 
 explicitly on this).

 So I think there is a better way. The end game here is you want an up to
 date sample config in your tree.

 Ok, so as a post merge figure out if you need a config change, and if so
 proposal bot that back in. Better yet, publish these somewhere on the
 web so people can browse samples. Maybe even for a few different kinds
 of configs.

The above is what we're going to do (in conjunction with a MileStone
check), thanks for the great input Sean and Morgan.


 Make it part of the release checklist for a milestone that the tool
 which generates the config is run manually and make sure that the in
 tree config is up to date. Which might mean in master it's behind a bit,
 but at least it will be right for any releases.

 -Sean



 Just my quick $0.002 on the topic,
 —Morgan

 On Dec 3, 2014, at 12:44 PM, John Griffith john.griffi...@gmail.com wrote:

 Hey,

 So this is a long running topic, but I want to bring it up again.
 First, YES Cinder is still running a sample.conf.  A lot of Operators
 spoke up and provided feedback that this was valuable and they
 objected strongly to taking it away.  That being said we're going to
 go the route of removing it from our unit tests and
 generating/publishing periodically outside of tests.

 That being said, one of the things that's driving me crazy and
 breaking things on a regular basis is other OpenStack libs having a
 high rate of change of config options.  This revolves around things
 like fixing typos in the comments, reformatting of text etc.  All of
 these things are good in the long run, but I wonder if we could
 consider batching these sorts of efforts and communicating them?

 The other issue that we hit today was a flat out removal of an option
 in the oslo.messaging lib with no deprecation.  This patch here [1]
 does a number of things that are probably great in terms of clean up
 and housekeeping, but now that we're all in on shared/common libs I
 think we should be a bit more careful about the changes we make.  Also
 to me the commit message doesn't really make it easy for me to search
 git logs to try and figure out what happened when things blew up.

 Anyway, just wanted to send a note out asking people to keep in mind
 the impact of conf changes, and a gentle reminder about depreciation
 periods for the removal of options.

 [1]: 
 https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586

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


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



 --
 Sean Dague
 http://dague.net

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

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


  1   2   >